I’ve wanted this from every project-management system I’ve ever used: A “Relevant after” field that hides items from all default views until a trigger (e.g. date, or other task completion).This would let me brainstorm todo items without being annoyed by clutter that isn’t relevant yet.For example, I handed in a draft of my Master’s thesis on Monday afternoon. My second reader told me, “OK, I’ll read it Wednesday morning and get back to you.”As of that moment, I have a new todo item: Either deal with her feedback or remind her that I need her feedback. This new task is not relevant to me until Wednesday except when planning other tasks to be done that day. And I know how you feel about software that gets in your face with irrelevant shit.
Archive for the 'Design and Usability' Category
Google Calendar Labs has introduced a new feature called “Free or Busy,” described as “See which of your friends are free or busy right now.”
You make a list of people who’s status you’d like to see, and a widget on the side displays their current calendar status based on their privacy and sharing settings.
It’s a neat idea, but in my opinion the calendar is the wrong place to view this information. I use my calendar to see what I should be doing or to schedule things for later, not to check up on my friends. If I want to see what a friend is up to right now, I’ll check their instant messenger status, or maybe Facebook or Twitter. I already manage my friend lists in those applications.
Instant messengers are still the best tool for distributed presence information. This free/busy widget would make a great instant-messenger plugin.
- They’re the underdog with a slim chance. They’ve got guts.
- The Bird’s Eye view is awesome and useful without being creepy.
- The photo of the day is consistently gorgeous.
- The image search sidebar is a genuine improvement over Google’s interface.
- The temporary search history is useful without being creepy.
Apple has made a big deal of “Cover Flow”, a way of visualization and manipulating a collection of images.
It started in iTunes as a way of visualizing album covers.
It’s pretty but not useful. I don’t mentally sort music by album and it’s a clumsy way to cue memories.
Then, they introduced Cover Flow as a way of browsing files in Finder.
Again, it’s nifty but not useful. Large images of folders and icons of file types don’t help much.
Now, they have Cover Flow for browsing my internet history in Safari, and it’s brilliant.
I remembered reading something about making my own bagels. The history search made it easy search the text of pages that I had visited. The large images made them easy to remember. This combination made it possible to find the bagel recipe I want to try. To top it all off, the whole thing is gorgeous. Safari 4′s history visualization with cover flow is phenomenal.
Microsoft billionaire Charles Simonyi disappeared from the public eye years ago, muttering about changing the way people program. He founded a company called Intentional Software which largely kept quiet and seemed to do nothing. It turns out you should never trust a silent genius billionaire—as evidenced by a demo they gave at a domain-specific language conference.
Here’s the video on MSDN. The most interesting part is roughly between 31 minutes and 41 minutes.
Here are some tantalizing screenshots I took from the demo:
A close friend asks,
Can you recommend/lend a good book on software UI design? Managing a
redesign of UI? Rolling out new UI to existing users?
The Little Computer Scientist answers,
- Paper Prototyping by Carolyn Snyder: About designing and evaluating UIs using paper
- The Design of Everyday Things by Don Norman: High-level design principles
- Don’t Make Me Think by Steve Krug: Specifically about designing web interfaces. Very short.
- Human-Computer Interaction (textbook) by Dix, Finlay, Abowd & Beale: Fairly deep. More stuff on Ubiquitous/CSCW/Groupware-type stuff than most people care about. But good stuff about doing ethnographic studies.
I don’t own, but strongly recommend:
- User Interface Design for Programmers by Joel Spolsky: Takes a “bare minimum you need to know” approach targeted at programmers. Partially available online (http://www.joelonsoftware.com/uibook/fog0000000249.html). The full version is worthwhile.
- The entire archives of useit.com by Jakob Nielsen. Free, and easily digested in small chunks. I’m subscribed to the newsletter and read new articles as they come along.
- GUI Bloopers by Jeff Johnson: Learn by (often hilarious) counter-example. Super-readable.
Honestly, I just don’t think UI design work is that hard. Learn a few foundations like Hick’s Law and Fitt’s Law, learn a handful of heuristics like seeking consistency and simplicity. Then just prototype alternatives and test, test, test on real people.
On managing a redesign of a UI and rolling it out, I don’t have much. Jensen Harris managed the Microsoft Office 2007 redesign and rollout. He documented a lot of thinking and decisions at http://blogs.msdn.com/jensenh/. That’s as real an experience as it gets.
A large number of (what I consider to be) design errors:
- Amazon has a list of books I’ve already bought from Amazon. It also has a list of books I intend to buy, courtesy of my (large) shopping cart. It also has a list of books I have no interest in, due to my clicking “Not Interested” where appropriate. Yet, throughout the site, it continues to recommend books from all three categories.
The Little Computer Scientist’s recommendation: Amazon’s recommendation engine should not recommend books I already own or books that are already in my shopping cart.
- I keep many books in my “Saved for Later” section of the Shopping Cart. It’s my “intend to buy when I have time to read” list. Every so often I bump a few books into the Shopping Cart proper and buy them. The UI for the “Saved for Later” does not support searching or efficient browsing. Furthermore, when I look at a book listing, there is no hint if that book is already in my cart.
Recommendation: Allow searching in a cart. When I make a change in the cart, it should not cause a full page reload, nor lose my place in the paginated list. Integrate the cart with book listings, such that a listing for a book warns me if the book is already in my cart.
- Amazon maintains a taxonomy of books. It allows a user to “Browse by Category.” But many books are in the wrong categories. There is also lots of overlap. For example, The Black Swan and The Adobe Photoshop CS4 Book for Digital Photographers top the Computer Science category. The Adobe Photoshop CS4 Book for Digital Photographers tops the Software Engineering category under Computer Science. What?
Here are the categories for Adobe Photoshop CS4 Book for Digital Photographers:
- #1 in Books > Computers & Internet > Programming > Algorithms > Digital Image Processing
- #1 in Books > Computers & Internet > Computer Science > Software Engineering > Information Systems
- #1 in Books > Computers & Internet > Digital Photography & Video > Adobe Photoshop
In an earlier revision of this post, I accused Scott Kelby, the author, of cheating the system, because I believed authors chose their categories. I shouldn’t have jumped to that conclusion—this is entirely Amazon’s fault.
DrProject, del.icio.us, and others
Del.icio.us just deliberately breaks password saving on its sign in page by specifying autocomplete=off in its form.
I hate it when coders put effort into features that degrade the experience. You actually have to try hard and spend time to break the browser’s password-save feature. It doesn’t help anyone.
- WordPress recently redesigned their interface. Presumably they tested it and found some advantages. Yet they have ignored the #1 rule of human-computer interaction: Responsiveness is king. The new interface is noticeably slower than the old one. The old one was already slow.
Responsiveness lets users make mistakes without consequences and therefore without fear. Responsiveness allows experimentation, which gives a UI discoverability. Responsiveness compensates for many other design errors. Responsiveness is the most important UI principle in the world.
- If I don’t give a post a category, it is placed in the Uncategorized category. If I later give it a category, it remains in “Uncategorized” as well. This is wrong. Posts should only be in Uncategorized if they’re uncategorized.
- Switching between the Visual and HTML views of the blog post editor loses whitespace information. Whitespace operations should be preserved between the two views of the same post.
A corollary to Don’t Put Reset Buttons on Forms.
Reset buttons save time in a tiny minority of cases. Actually, I can’t think of any good uses for reset buttons, but I’m sure they’re out there. I’m sure there’s some person out there who looks good in white pants, but I’ve never seen one. Maybe in Australia. Yet people who really ought to know better persist in wearing white pants and people who really ought to know better still put reset buttons on forms.
API designers, take heed. Insofar as an API makes some end-product designs easy and other designs hard, it should make good designs easy and bad designs hard.
The ”API” of HTML makes reset buttons as easy as Submit buttons. Reset buttons are usually bad design. Trouble lurks.
The Wandering Programmer wants to make a volunteer application form for his super-awesome conference in Vancouver. He comes across an HTML forms tutorial and sees code for a reset button. It’s easy. The Wandering Programmer puts a reset button in his form. Why not?
On the eve of the application deadline, The Dawdling Student painstakingly fills out a well-crafted application, full of witty turns of phrase and intriguing commentary on the scintillating world of academic conferences. The seconds hum along to the deadline, but the Student broods over each word before finally! It is time for submission. By now it is near midnight and the Student’s hourly double-espresso is beginning to wear off and in a twitch the RESET button is struck, just millimeters away from the goal, and all is lost.
A long time ago, many programmers worked late nights to bring their boring crufty Desktop Applications to the Web. Most of the Web copies were worse than the Desktop versions, just as you might expect. But some of the Applications were easier to use!
In the world of Desktop Applications, platform makers like Microsoft and Apple created wonderfully rich, powerful and complicated widgets programmers could use in their software. They made it easy. And Programmers used them, often when they shouldn’t. Then, the Horde of Hapless Users came along and were confused.
When the move to the web happened, the Programmers found it difficult to copy their complicated widgets. They were forced to express their programs in simple controls. When the Horde of Hapless Users came to the Web applications, they were not confused any more. The simple Web programs were better than the complicated ones they replaced.
Programmers will go with the grain of an API. The API of desktop application makers make it as easy to use complicated widgets as it is to use simple widgets, so programmers sometimes use complicated widgets when a simple one would be better. The grain of HTML makes it easy to stick a Reset button on your form.
An API designer should always think about the grain of the API.
The student volunteer application form for ICSE 2009 contains seventeen form fields. At the bottom, you find this:
Why would anyone want to clear out seventeen fields worth of information?
There’s no reason.
But someone might miss “Send” and click “Reset” instead.
It just so happens that HTML makes it easy to put in Reset buttons. Lots of people do, just because. It’s a bad reason. Just because you can, doesn’t mean you should.
As it turns out, Jakob Nielsen, user interface expert extraordinaire, agrees.
Alternate title: Procastination Sunday Afternoon
Let’s say you want your computer program to know about locations.
What are you building?
A simulation for an assignment.
What programming language should I use?
Python. I want to learn Python better and I’ll visualize the simulation in Nodebox, which I’ve used before.
What location format should you use?
Latitudes and longitudes. The real application would involve mapping these; the mapping tools I’ve used understand latitudes and longitudes. Six decimal places gives me 1 metre accuracy.
Should I make a class to represent locations, or just use something simple like tuples of floats?
Use a class. You can do some simple validations and unit tests. Good defensive programming.
What should the class be called?
‘location’. It’s not important enough for me to go learn Python naming conventions right now.
How should the class represent the data?
Python properties seem to be the “new” way of doing basic data in Python, I’ll use those. Lesson learned the hard way: Must remember to inherit from ‘object’ when using Python properties or else they silently don’t work.
Should arbitrary numbers be allowed as latitudes and longitudes or should they be restricted to the degree ranges that maps actually use?
Restrict. I might as well have the class guarantee latitudes between -90 and 90, longitudes between -180 and 180.
Should the class validate its inputs and reject bad input or fix them up to be valid?
Validate and reject. “Be liberal in what you accept” is bunk.
Should you test your validations?
Might as well. I want to learn how unit testing works in Python.
Should you include an operation to move a location?
I guess so.
Should it be named or should you overload addition?
Lat/lng pairs act like vectors in some ways, but I don’t want to go there. I’m not curious to know about Python operator overloading right now. I’ll keep it simple and just call the operation moveBy.
Should there be one moveBy for Latitudes and one for Longitudes, or keep them together?
I’ll keep them together, the alternative would be annoying.
Should both arguments be mandatory?
No, I’ll make them optional named arguments.
What happens when moveBy wants to move a location outside the range of valid latitudes and longitudes?
If I validate, then one call to moveBy could be valid while another identical call was invalid based on internal state of the location. That’s undesirable. I guess I’d better have moveBy fix up the location. It’s not that complicated: I just move the current lat or long into the positive domain, add the parameter modulo the range of allowed values, and adjust the new lat or long back to being centred on 0. This will be error prone, though, I’ll want to test it thoroughly.
You’re using floating point numbers internally; successive small moveBy calls could introduce numerical inaccuracies. Should you take steps to remedy this?
No, I don’t care enough about numerical stability here and I would have to work hard to learn what needs to be done.
Should you really have made a mutable data container? Are locations really mutable? It’s weird to use them as hash keys now, maybe you should have used an immutable pattern. If you make it immutable, operations like moveBy just become factories for new immutable locations.
I’ve already built and tested this class. It’s not worth changing over now. Besides, mutable is probably more efficient.
I don’t know why I was so unusually introspective of my own thoughts during this time, but there it is.
The development of usable web applications still requires some platform-specific customization.
Software developers know that they can save work by making web applications instead of desktop applications. People use computers with Linux, Mac OS X, or Windows. The same web application automatically works on all three operating systems, but a desktop application needs special attention.
Some people think that web applications don’t need any customization for different operating systems. They feel that following Web-specific conventions is enough. I disagree. Here is an example of a situation that requires customization.
There is a recent trend in web applications to enable keyboard shortcuts. For example, pressing Control-B in GMail makes text bold and Control-I makes text italic.
Individual operating systems also have keyboard shortcuts. For example, on most Windows applications that edit text, Control-B makes text bold and Control-I makes text italic.
This is a problem because these keyboard shortcuts aren’t consistent across operating systems. For example, on Mac OS X, pressing Control-B moves the caret back a character, Command-B makes text bold and Command-I makes text italic.
Web applications need to respect these differences to be usable. I use Mac OS X, so I expect Mac OS X keyboard shortcuts to work even in web applications. Usable web applications need platform-specific customization.
(Specific problems: When I use Mac OS X, in GMail, Control-B should move the caret back a character, Command-B should make text bold and Command-I should make text italic. In WordPress, when the Post Title edit box has the focus, Control-A should move the caret to the beginning of the line and Control-E should move it to the end.)