one mikro2nd
web2, net3, programming, design, business, and the fundamental nature of spacetime

Invalid Field Feedback Failure    [ design/ ]

Random musing on UI misdesign

A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.

Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)

Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.

Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.

So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.

[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]

Tags: uidesign, designfail, softwaredesign

24.Feb.10  9:22 AM, SAST | Words (324) | 0 Comments | 0 Trackbacks

User Interface Redesigns    [ design/ ]

I love this quote by E. A. Vander Veer in "Why Does Facebook Keep Redesigning?"

typically users aren't considered at all when it comes to software redesigns. I wouldn't have believed this if I hadn't seen it in action on countless projects in several different companies! The attitude is, "We're the experts, we know what you want and need, our redesign is making it better, and it won't take more than a few minutes for you to get up to speed."

This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.¹

Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.

Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.

Like those who thought that adding autoboxing and varargs to the Java language was a value-add...

---

[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!

11.Feb.10  8:16 AM, SAST | Words (347) | 0 Comments | 0 Trackbacks

Software Design    [ design/ ]

"System Design, is one that as a profession we talk about less than I believe we should. It is, in many ways, the most important and most difficult thing that we engineers attempt to do. I believe that we avoid talking about it because it is hard, and seems somehow “unscientific.” There are clearly some designs that are good and others that are not. But the judgment of how good a design is often seems subjective or based on aesthetic principles rather than on the cold hard facts that we are engineers who pride ourselves on forming the basis for all that we do. I hope that this essay convinces some readers that the dichotomy between science and art or engineering and aesthetics is not clear, required, or even desirable. What we do must be grounded in fact, but it also needs to be grounded in taste. We should revel in that rather than trying to cover it up. It makes what we do more difficult, but also much more interesting."

-- Jim Waldo

I've been thinking a lot again, lately, about software design and how to teach it... and about how little there is out there to guide the design of good software architecture...

All part of my Quest After The Heart Of Design for the last 15 years. And maybe (just maybe!) I think I have a useful angle on it that might illuminate a path forward.

I'll say more as I develop the concept.

(And, BTW, Jim Waldo is, in my humble opinion, one of the preeminent thinkers on design alive, and one of the most interesting people I've had the privilege to meet.)

04.Feb.10  9:39 AM, SAST | Words (273) | 0 Comments | 0 Trackbacks

How Do Development Managers Screw Up?    [ design/ ]

Here's a question, much on my mind:

What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?

Answers in comments (or email if you don't want to publicly reveal details) please!

By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.

10.Jan.10  1:35 PM, SAST | Words (137) | 0 Comments | 0 Trackbacks

Word processors    [ design/ ]

If Word Processors are to Words as Food Processors are to Food.... no wonder they're so bloody awful to use!

27.May.09  1:15 PM, SAST | Words (20) | 0 Comments | 0 Trackbacks

Phinal Phormat    [ design/ ]

What idiot made the format() method in java.text.DateFormat? Come on, own up!

For goodness sake! Now nobody can ever make the damn thing threadsafe. Everybody gets to synchronize or lock around the calls to format (and applyPattern and any other state-altering methods.) The whole world has to do the same repetetive, boring, unnecessary work, over and over and over again, just because some fool made the method final.

The same thing goes for the Currency class, which is final with a private constructor. Instances are obtained through factory methods that only understand the standa currecy code. So, if you're planning on writing any sort of Local Currency Trading System using Java, forget about using the Currency class, which would otherwise be an incredibly useful thing to do.

Please, when you're designing a class, don't ever make the class or its methods final unless you have a very, very good reason for doing so. And by very good reason, I mean that it is doing something cryptographic or otherwise incredibly sensitive that really must not ever be overriden.

OK; the argument can be softened slightly if we start talking about classes whose instances come via a Service Provider Interface (as javax.text's classes are) but in many cases all it does is create unnecessary agravation.

I don't believe any of us can see far enough into the future to make methods final, so the motivation for doing so had better be damn compelling.

15.Apr.09  11:22 AM, SAST | Words (236) | 0 Comments | 0 Trackbacks

Invisible Work    [ design/ ]

20.May.08  8:51 AM, SAST | Words (141) | 0 Comments | 0 Trackbacks

Quotable    [ design/ ]

"The Ark was built by one man. The Titanic was built by a team of professionals."

25.Apr.08  7:53 AM, SAST | Words (16) | 0 Comments | 0 Trackbacks