Sunday, April 20, 2008

A "unix" UI rant

I think I'm finally getting the hand of the Unix/Linux mentality.

For years, now, I've maintained that trying to use Linux was about as much fun as a visit to the dentist. I think I'm finally starting to get it, though.

You see, Linux, in general, has a terrible UI. Not only that but it has been incredibly slow to improve. I fully expected, back in 1999, that'd this problem would be completely solved by now. With the massive rush of ex-apple programmers and general interest it shouldn't be too much effort to fix up Linux to be usable by people unwilling to dedicate several years of their life to learning it. yeah...

So anyway, today I managed to install a piece of software that was obviously programmed by some unix-type. I'm so proud of myself. It only took me two tries. The second try I approached it with the idea that 1) the programmer expects me to know about how everything and 2) put no thought into user interface.

Fun facts:

1) You needed to tinker with a config file that came with its own syntax.
2) The client and server concepts were backwards (*my machine* was the server and I had to ssh into the other machine and tell it connect to *me* so I could use it).
3) Security by insanity - do I know your login name? Yes? Ok, I'll talk to you. I mean, at least you could pretend it was a password; that's what it acts like.
4) The configuration was such that you needed to add two configuration entries to do something that really only needs 1 (for the most common use case). If you only added one configuration line your mouse cursor became trapped on the other screen. oh no!

The thing that really gets me though, is that once it was configured it actually works. I mean, there's nothing wrong with it! No stupid, bugs or miss-features it does what it was supposed to do. It's really a shame that this great software is hiding behind such a terrible interface.

Want to try it yourself? (the software or configuration odyssey. I'm not picky) The software is called synergy. It's purpose is to allow you to use a second computer, with a second screen as if it were really just an extra screen for your main computer.

You see, I run a PC most of the time, but I also have a mac that I want to use. I don't want to keep switching keyboards and mice, though. I'd rather just be able to mouse over to the mac screen and use it like that.

Those familiar with VNC can think of it as setting up VNC session on a monitor hooked up to a different computer. Synergy works better than that because isn't of using VNC to display the remote screen on your computer. You just use the physical monitor attached to other computer's and send your mouse and keyboard command are sent to it.

This works great if you have the two computers sitting on the floor next to you.

Now if you'll excuse me I have to flick the mouse over to the Macs screen because the screen saver has come on again..

Ok, so it has one (known) bug:
"The Mac OS X port is incomplete. It does not synchronize the screen saver, only text clipboard data works (i.e. HTML and bitmap data do not work), the cursor won't hide when not on the screen, and there may be problems with mouse wheel acceleration. Other problems should be filed as bugs."

Tuesday, April 15, 2008

OpenPro Computer - A mac clone!

Apparently Psystar is making macintosh clones. The OpenPro Computer model looks familiar. Oh yes, the case is the Antec P182. Essentially that same as my home PC's P180. Good choice.

Monday, April 14, 2008

"UI is the root of all evil" or UI is hard

A friend pointed this one out to me. It's an article about the dangers of not considering the GUI when doing development.

http://blogs.pathf.com/agileajax/2008/04/the-user-interf.html

In the context of my previous blog posting, think of it as what could happen if the UI design is late and your design process is not agile. :-)

(planning is good)

Sunday, April 13, 2008

Cooper vs extreme programming

I was at last year's SD Best Practices conference at Boston. One thing I remember was the two times I heard programmers complain about Alan Cooper's views on UI design.

The complaints were both by programmers directed at the aspects of Interaction Design which are incompatible with extreme programming.

First off, I've never been a big fan of extreme programming.

I believe that a great number of programmers have a code-first-think-about-it-later approach to programming. I believe this mentality is a big barrier to creating large, scalable, long-lived software. I find it disturbing that someone would actually advocate a process that actually *encourages* more of this.

I met 3 programmers at SD Best Practices that took extreme programming to mean absolutely no design. As if thinking ahead was banned outright. Talking to them brought to mind scenes from 1984 where instead of being banned from remembering, you were banned from thinking ahead. I don't buy it. To plan is to think ahead is to avert disaster. Imagine trying to build a building or plan a trip or save for retirement without thinking ahead! The extremist extreme programming mentality is that the future so uncertain that all planning is futile. This is only a very coarse approximation of what extreme programming actually advocates but what extreme programming actually advocates is complete overkill in most projects anyway.

At any rate, the Interaction Design (as explained by Copper) conflicts with XP (extreme programming as explained by Kent Beck) in at least two ways.

1. XP advocates user involvement in the design process. You ask the user, you give them a prototype, they tell you what's wrong, repeat until convergence.

User Interaction design says "don't ask the user!". The rational is that users don't know what they want! UI design is hard and should be done by a trained, professional Interaction Designer.

2. XP advocates short iterations and an iterative methodology that takes into account learned mistakes as the project progresses..

User Interaction mandates that the Interaction Designer do the design more or less in one shot, up front.


These two methodologies are not directly comparable. Not only are they trying to solve different parts of the software engineering problem but they are coming from a different set of assumption about what sort of environment they are operating in.

Interaction design is all about user interface design. It does mention how to go about developing software except where software development intersects user interface design. Doing design up front is a good idea with user interfaces because 90% of GUI design is optimizing for the most common cases. You either know what the common cases are or you have to go out into the field and observe the users at work.

The net result of this process is usually a design that is highly optimized to how people work. As with any highly optimized system, GUIs can have a large amount of cross cutting features; that is features that are interdependent. As a result of this, a small change somewhere could change the nature of the GUI completely. Adding one extra click or a pause or adding a step can have a huge impact if that case is common. As a result, user interfaces should be thought of as one holistic piece.

Consider this example: Radiologists look at X-rays and diagnose problems like broken feet and arrows piercing the head. Their workflow (simplified) is 1) load image 2) dictate image 3) next image. I've watched them at work and they work fast. They average about 2 minutes per case. If we had a workflow that added 1 extra click somewhere to that workflow we would have added somewhere around 7 * 60 / 2 =~ 200 clicks. Multiply this by the number of radiologist at work and that tiny, little design decision has single handedly caused hundred of cases of repetitive strain injury! You can do a similar time base calculation. if your extra click requires the user to think about what to do next.

This may seem trivial to some but we've actually had certain minimum workflow standard written into our contracts with some of our clients because they are sick of vendors pushing an extra click on them for no reason.

I've always viewed XP's desire to bring the user into the design process and have them practically design the UI as a first order approximation on how to design a GUI. XP's assumption about having continuous access to a user (or group of users) is very a-typical, in my experience. Also, users are very bad at vocalizing what they want of need:

http://andrewtrumper.blogspot.com/2008/02/why-ui-design-is-import-in-apis-and.html
http://headrush.typepad.com/creating_passionate_users/2005/09/listening_to_us.html
http://www.joelonsoftware.com/articles/fog0000000356.html

etc..

My favorite users-don't-know-what-they-want story comes from when I was developing a piece of image-burning software. The idea was that this software would be for burning X-ray (or other modalities) series to CD. We knew what sort of users we wanted to target. We thought we knew what they wanted in the software, since we had this big feature list. The only question remaining was what should the "GUI look like?". I looked at the feature list and the target user and I couldn't match them up in my head. I just couldn't believe that the users we were targeting really wanted this big complicated GUI. I decided to ask for an on-site visit. Before the on site visit I'd prepared a list of questions that I wanted to answer. These questions were about whether a certain features were desired or not and about the relative frequencies of various occurrences.

I was curious about what they'd tell me if I just asked them my questions point blank. Did you need this feature? yes! My test users wanted every feature, expect that ones they didn't understand. Did this edge case happen frequently? no! How often? Once every 6 months of so.

I then observed them for three hours. During the three hours each one of the edge conditions happened at least once. They also never needed the extra features. It turned out that the software they were using had the features I was asking about. However, even in cases where they should have logically used these features, they didn't because it wasn't worth the effort to configure them! AGH! I came away from this with a better, streamline GUI and the notion that users (at least these users) had no clue what they wanted.

The second major point of disagreement between ID (Interaction Design) and XP (extreme pornography.. I mean programming) is the use of iterations.

As I've mentioned ID isn't about how to build the thing; it's about the GUI. Nothing is stopping you from using iterations to build the big-bang-GUI. In fact, in my practical experience, you have to start building before the GUI is completely ready because it takes so-freaking-long to design the GUI. Yes, by all mean do iterations. Not doing iterations is silly. You might want to stretch out your iterations longer than the ones suggested by XP, though. XP mandates uber tiny iterations (1 week). With such iterations you're actually under-valuing planning.

Planning is good! Over planning is no so good. Being forced to over-plan then stick with that plan is extremely bad. In my experience, excellent planners (or planner *teams*, rather) can plan two months in advance with a good degree of accuracy. Good planners are about a month and ordinary, mere mortals can plan a week or two if they practice at it. All these estimates depend on the context, of course. Your planning horizon can vary tremendously depending on the problem, the degree of familiarity and the skill of the planner.

My favorite planning story is the time we planned out our "roaming preferences" feature. Essentially we managed to plan out about three months of work and have that plan executed with little or no change within 5% of the estimated number of hours. Hurrah! A hole in one! Then, in the next iteration, we tried to plan out 1 month of work and both the major aspects I was responsible for were completely wrong.. Luckily both things that we got wrong were wrong in opposite directions. One took 4 times longer than I though and the other tool about 1/10 the estimated time. The reason for this was that we had to make a modification that changed where the bulk of the work went so it's not really a co-incidence. We actually knew this was high risk going into it since we were modifying old code we didn't know very well.

Remember to include the risk component in your time estimates and proposed designs!

So, iterations are a way of mitigating against the risk of planning errors. They do this by scheduling points where the design and progress of a project can be re-evaluated and adjusted. The downside to short iterations is that it can artificially limit you to a fixed design horizon. Limiting your design horizon can introduce costly refactoring or code scaring. For a real-life analogy of the dangers of under planning, consider the joys of mountain biking with your eyes closed. Ouch!

Using super short iterations on a project with no risk is silly. Using super long iterations on a project with high risk is silly.

None of this has to do with GUI design. Even if your GUI design is low risk, other aspects of implementing that design might be high risk. The length of iterations for a project is a programmer thing. Interaction designers do their GUI thing and programmers mitigate against their potential errors and their own by having short iterations. The two do not conflict because they are tackling different aspects of the problem. The only major change for XP people is that the GUI design is done by someone else and becomes lower risk. (In practice, politics and errors affect this somewhat)

I like to say that even if you're not doing iterations the best way of actually these implementing these big designs is by making use of iterations.

In my mind, ID (Intelligent Design .. I mean Interaction Design) and XP do not conflict. ID is a way of creating a better GUI. XP is a set of techniques for mitigating against the troubles brought by changes by embracing them.

bye.