EppsNet Archive: Web Development

Some Links

30 Oct 2013 /

HealthCare.gov’s Account Setup: 10 Broken Usability Guidelines

McKayla Maroney Was Doing The “Not Impressed” Face At Age 8

Most Popular Paintings & Photos From Getty’s Online Art Collection

The Tweeting Bra Versus Breast Cancer

HTML5 Date Tag

21 Dec 2012 /

I learned something interesting about the HTML5 date tag. Look at this calendar dropdown:

HTML5 date tag

Here is the sum total of code needed to make that happen in a Chrome browser:

  1. <input type="date" />

That’s it! No Javascript, no CSS. Programmers these days have it easy.

How to Lose Your Job : A Fictional Memoir (Part I)

4 Sep 2012 /

Because of the huge productivity differences between good programmers and bad programmers — 10x? 28x? More? — my biggest leverage point as a development manager is my ability to hire people.

At my last job, we had an HR Director named Lucy. In every one of our annual Employee Satisfaction Surveys, Lucy’s group had the lowest scores in the entire organization. Nobody liked or respected her.

She was, however, close with the CEO, which made that irrelevant.


Lucy’s friend Kathy Slauson runs the Slauson and Slauson recruiting agency, so that’s where we got our programming candidates, who were mostly terrible.

The Slauson agency doesn’t specialize in IT candidates, although they do have a “technical recruiter,” who unfortunately knows nothing about technology.

They don’t bring candidates in for in-person interviews. They take whatever candidates give them in the form of a résumé and they pass the résumés along to clients like me in hopes of being paid a fee.

  1. Candidates send résumés to Slauson.
  2. Slauson sends them to me.

What value does this add over candidates sending résumés directly to me? None.

Slauson doesn’t qualify candidates. They don’t map abilities and skills against the requirements of a position. They add no value to the process, and I had to screen all the résumés myself, the same as if I’d just bought them from a job board.

When I saw that Slauson was just going to throw résumés at me, I asked them to please add a short write-up, indicating why they thought each candidate was a good fit for the job.

What I got was write-ups like “Candidate is good with Technology X,” where Technology X is something I indicated as a job requirement.

When I asked “How did you assess that the candidate is good with Technology X?” they would tell me “We asked him.” Or “It’s on his résumé.”

In other words, “Candidate is good with Technology X” meant “Candidate states that he’s good with Technology X. Unverified.”


(If you’re wondering at this point why an HR department would funnel good money to a recruiting agency for doing nothing, go back and reread the part where I mention that Kathy Slauson is a personal friend of Lucy the HR Director.)

Money to burn

I said earlier that Slauson has a “technical recruiter.” She was in the office one afternoon and handed me a résumé.

“He doesn’t look like an ASP.NET programmer,” I said after looking it over, “which is what we’re looking for. For example, I don’t see any C# experience.”

“It’s right here,” she said, pointing at the résumé where it said this: C++.

If you’re not a programmer, you might say, well, easy mistake to make. C# (pronounced C-sharp, like a musical note) and C++ (pronounced C-plus-plus) are both programming languages containing the letter C followed by one or more symbols.

But whereas C# is the primary programming language for web development on the Microsoft platform, C++ is a lower-level language used for system development. Nobody does web development in C++.

Not surprisingly, a high percentage of Slauson’s candidates bit the dust in the initial phone screen with me, because the phone screen was their first encounter with someone whose programming knowledge was non-zero and could possibly tell a good programmer from a bad programmer.

According to Kathy Slauson, that was totally unacceptable. She thought that because she had an in with the HR department, we should be hiring every candidate she sent over, qualified or not, and paying her for the privilege, which is the way it worked before I arrived on the scene and screwed up the process.

Money and whiskey

She was always very polite to me in person, assuring me that she was doing her best to improve the quality of candidates, but behind the scenes, she was telling Lucy the HR Director that I shouldn’t be allowed to interview candidates anymore.

(That information was never supposed to reach me but it did.)

Think about that: we had a recruiter telling our HR Director that a manager shouldn’t be allowed to interview their candidates. (The fact that I no longer work there tells you which side of the issue Lucy came down on.)

Kathy also told Lucy that the candidates I was rejecting were perfectly good candidates because after I turned them down, they were being hired at other companies.

Imagine that!

Of course they were being hired at other companies. They were being hired by companies with lower hiring standards for programmers. The best thing that could happen with some of those candidates is for them to be hired by competing organizations.

Do you think Amazon or Google worry that candidates they turn down get hired somewhere else?

(No, I wasn’t trying to match hiring standards with Amazon or Google. I’m just saying that it wasn’t my goal to be the employer of last resort, or to be able to say, “If we don’t hire ’em, nobody’s gonna hire ’em!”)

Everyone I hired was an order of magnitude improvement over the people they replaced.

I like to work with talented people. I’m not trying to get rich and I don’t have a career path. I’m trying to learn and get better and contribute to my profession.

If you give me a job where I’m responsible for hiring people, I’m going to hire the best people available, and decline to be force-fed unqualified candidates by a friend of the HR Director.

To be continued . . .

ideasspotter: 75 Startup Tools and Apps

Posted by on 23 Jul 2012

Mobile Site vs. Full Site

13 Apr 2012 /

From Jakob Nielsen’s Alertbox:

The basic ideas are to:

  • cut features
  • cut content
  • enlarge interface elements

3 Laws of Usability

11 Oct 2011 /
  1. Don’t make me think!
  2. It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.
  3. Get rid of half the words on each page, then get rid of half of what’s left.
— Steve Krug, Don’t Make Me Think

Why In-Page Navigation Links Matter More Than Menus

8 Oct 2011 /

Before you spend hours debating with your colleagues and clients on how your menus should look, there’s something you should know. Users spend more time with in-page navigation links than they do with menus. In fact, some users don’t even look at menus. What users look at is page content. And that’s where they often go to navigate.

One firm has experienced this many times with users in their eyetracking research.

Web Governance: Becoming an Agent of Change

13 Aug 2011 /

It’s about pointing out risks, shining a light on organizational denial, overcoming resistance, and facilitating constructive discussions about change. . . .

We’re facing a stark choice right now: keep whining or start leading. . . .

You might be thinking: “There’s no way I can do this. I’m a designer, developer, or copywriter, not an organizational change maker!” But we can do it, and we should. Because nobody else will do it for us, and if nobody deals with the problem, we won’t be able to do great work.


15 Dec 2009 /

“What kind of work do you do?” someone asks you.

“I’m a web developer,” you reply.

“How interesting! What site do you work on?”

“It’s just a small site. You wouldn’t have heard of it.”

“Oh I’m on the web a lot. I may have seen it. What’s it called?”

In a barely audible voice, halfway between a mumbling cough and a coughing mumble, you say, “DogPoopBags.com.”

“Ha ha ha — for a second there I thought you said DogPoopBags.com. I . . . uh . . . oh, sorry.”

Twitter: 2009-12-13

13 Dec 2009 /

Infomaki: An Open Source, Lightweight Usability Testing Tool

30 Nov 2009 /

Infomaki is an open source “lightweight” usability testing tool developed by the New York Public Library to evaluate new designs for the NYPL.org web site and uncover insights about our patrons. Designed from the ground up to be as respectful of the respondents’ time as possible, it presents respondents with a single question at a time from a pool of active questions. In just over seven months of use, it has fielded over 100,000 responses from over 10,000 respondents.

User Surveys on the Web

28 Jan 2009 /
Look me in the eye
Then tell me that I’m satisfied
Hey, are you satisfied?
— The Replacements, “Unsatisfied”

What is a reasonable target for user satisfaction with a web site?

We did a user satisfaction survey last year and found that 14 percent of respondents felt that our web site didn’t measure up to their expectations.

This year, we have an incentive goal of reducing that number to 8 percent, not based on evidence that any web site has ever achieved a number that low, but based on the opinion of the company that did the survey that anything over a 10 percent dissatisfaction rating is always bad.

Or to flip it around, we’re trying to achieve a 92 percent approval rating.

I wish we hadn’t set the bar quite that high. I don’t want to be a pessimist but not only is that considerably higher than, say, Google (at 78 percent — and what’s not to like about Google?), it’s also higher than Santa Claus, crack cocaine and oral sex . . .


Things That Pop Up and Poke You in the Eye

23 Jan 2009 /

We’re discussing whether our organization will use a popup user survey on our web site . . .

Tired of Pop-ups like this one?

“I propose doing the survey without the popups,” I say. “That’s why browsers have popup blockers, because people don’t like popups. A popup is like a poke in the eye. I don’t like it when things pop up unexpectedly and poke me in the eye. Whenever that happens, I make sure not to go back to that place anymore.”

Unfortunately, no one picks up on the “popped up and poked me in the eye” motif because I was then going to chide them for their junior high school mentality.

“I had a teacher who used to say that,” a young woman says. “‘It’s better than a poke in the eye with a sharp stick.'”

I say, “I used to work with a guy who said, ‘You can’t beat that with a sharp stick.’ Why would the stick have to be sharp if you’re going to beat someone with it? You’re really just looking for something with a little heft to it.”

The same woman says, “I had a boyfriend who used to say, ‘You’re not going to hold that over my shoulder, are you?'”

“You have abysmal taste in men.”


I wasn’t able to persuade the team to abandon the popups. The argument in favor was that a lot of web sites use popup surveys so how bad can they be?

I worked for a dot-com consulting company during the boom and bust of that industry. The whole thing was based on the notion that everyone else is doing it so it must be a good idea.

The subsequent implosion of the entire industry disproved that theory rather dramatically.

Since then, I try to stay open to the possibility that even though a lot of people are doing something, it still may not be a good idea . . .

Thus spoke The Programmer.


2 Feb 2008 /

Be careful what you wish for . . .

Web comic

High Failure Rates on the Web

29 Nov 2003 /

. . . when public website users perform simple Internet tasks, they’re successful two-thirds of the time on average. In other words, users fail 35% of the time . . .

Six sigma tolerates no more than 3.4 defects per million manufacturing opportunities; in contrast, the Web generates 350,000 defects per million interaction opportunities. The difference between the two quality levels is a factor of 100,000.

The only reason the Web works at all is that people are flexible and persistent enough to try again when their first attempt fails.

The good news, I suppose, is that the opportunity for improvement is virtually limitless.

Thus spoke The Programmer.

After the Gold Rush

20 Sep 2002 /

Best one-sentence explanation of how the dot-com boom killed professional practice in the software business:

Improving operational efficiency is not a priority during gold rushes.

Different Drummers

14 Jul 2002 /

In high school, I was in the school orchestra. There were no auditions; it was just a class you could sign up for, independent of whether or not you had any musical ability.


And when a student with no musical ability signed up for the orchestra, what transpired was something like this:

Director: What instrument do you play?
Student: I don’t really play an instrument.
Director: You’re in the percussion section.

There were three or four of us in the percussion section who could actually read music and play it, so it was kind of depressing that it was mainly a backwater where musical illiterates were sent to bang on cowbells . . .

I recollected my days as a high-school percussionist today when one of our tech leads — tech leads — pulled up some javadocs and announced that a method we were using was “depreciated.”

Now if this cretin is not familiar with the term “deprecated” — which he certainly should be — but since he isn’t, you’d think he might at least be capable of reading or sounding out his own language.

But no such luck there either.

Ever since the dot-com boom wiped out the hiring standards for the software business, this is what’s become of a once-noble profession.

Clang! Crash! Boom!

Thus spoke The Programmer.

ArsDigita, Vita Brevis

1 Mar 2002 /

I was a big fan of the original vision of this company . . .

Radical Notions Debunked!

21 Nov 2001 /

The big controversy at the office this week was a “radical” idea offered by one of our developers regarding data collection with a series of web-based forms.

The idea was that rather than just pouring the data into a relational database like everyone else does, we’d build up an XML tree, essentially a gigantic (in this case, ~200K) string, and pass that around from form to form.

The advantages of this, if I understood correctly, would be to simplify the data model design and eliminate the need for table joins.

Of course, it also violates every known rule of efficient data access and ratchets up the processing requirements by several orders of magnitude, but that didn’t stop one of the development managers from throwing his full-fledged support behind it.


I TA’ed undergraduate software engineering classes for a year at USC, and every so often an underclassman would advance some “radical” theory on how a programming problem ought to be solved, unaware of the fact that their proposed approach had actually been discredited 15 years earlier.

That’s okay . . . by the time they completed their degree, they usually had a much better understanding of the history and foundation of their discipline.

But the advent of web development has brought us a new generation of programmers, many of whom have not had the benefit of a formal education in computer science, which leads to sophomoric programming strategies being proposed by “professional” developers . . .

Thus spoke The Programmer.

A Bad Review

26 Oct 2001 /

Resemblance to persons living or dead is statistically probable.

Name: Snopes, Flem
Title: Software Development Manager

Developing Others
Flem was not effective in giving team members an opportunity to be successful or to do high-quality work. The project development process was limiting and frustrating.

Rating: Did Not Meet Expectations

Good work ethic. Big problem here is that Flem didn’t seem to see how poor project outcomes were a direct result of anything he did or didn’t do. He seemed to feel that he was a victim primarily of bad technology, as well as bad clients, bad luck, bad karma, etc. And while there were some unavoidable setbacks on the project, as there are on any project, Flem didn’t seem to see the human decision points in the process where he could have made a difference.

Rating: Met Some Expectations

Change Management
Flem was slow to react to changing circumstances. He took a “stay the course” approach and continued
to pursue strategies long after they had proven ineffective.

Rating: Did Not Meet Expectations

Flem is an articulate communicator but does not seem to be effective in reporting bad news to
clients and upper management. He has a “can do” communication style that unfortunately keeps people in a state of total denial about what’s actually happening. As a result, what could have been modest setbacks, had they been acknowledged as such and dealt with, escalated into full-blown breakdowns.

Rating: Met Some Expectations

Customer Service/Responsiveness
Flem was probably overly responsive to customer requests, with a resulting boomerang effect. He took client requirements at face value and did not provide the kind of risk management one would expect from a responsible professional. As a result, most of the client’s investment in web development was wasted on non-productive activities.

Rating: Met Some Expectations

Flem maintains a positive attitude when things aren’t going well. Unfortunately, his projects never seem to be going well. He failed to fulfill the main role of a project leader, which is to monitor plan vs. actual and to take action as needed to bring the two closer together. In some cases, a project manager fails to observe that a project is veering off course, but I don’t think that was the case here. I think Flem just failed to act on that observation.

Rating: Met Some Expectations

Performance Effectiveness
Flem did not establish any sort of professional quality standards for the project, resulting in a considerable waste of time, money and human potential. He did not demonstrate the ability to effectively steer a software project.

Rating: Did Not Meet Expectations

Problem Solving/Judgment
Flem advocated a fairly random approach to problem solving. When dealing with system errors, rather than attacking root causes, we took some random action hoping that would fix the error. Sometimes it did, although we didn’t know why. Sometimes it didn’t. Sometimes it introduced a new error. This is an area where a technical leader needs to take a stand and do the right thing.

Rating: Did Not Meet Expectations

Team Orientation
I think Flem’s failure to establish professional quality standards had a disheartening effect on the team. People will work hard to achieve excellence, but not if they see that management places no value on it.

Rating: Did Not Meet Expectations

Technical Expertise
Flem has some very good technical skills, but did not exhibit a good understanding of the full range of technical options, risks and tradeoffs involved in developing a web application.

Rating: Met Some Expectations

Thus spoke The Programmer.

Next Page »