Slashdot Mirror
What Makes a Good UI?
OSXCPA asks: "While there are plenty of OS business apps from accounting to ERP, they seem to share a common failing with "commercial" software - the user interface is terrible! Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it? For the techno-elite, drooly-gui may not be a priority, but I am working on a project (OS) where I have to show real savings (in task performance time and reduced data entry error) on a specialized accounting system via better UI. Am looking for some inspiration. Any ideas? Projects? Books?"
by Jef Raskin
u maneinterface/
http://www.jefraskin.com/forjef/jefweb-compiled/h
It's a book that can help you look at interfaces in a different way, with some measures you can make, and some guidelines that an be helpful. Maybe going all the way is not feasible immediately, but it can gie some insight on the subject.
Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it?
Google
The biggest problem I have with programs, is the way they make you hop all over to input data. If you can just go from input box to input box, flowing continously, then its a good UI design.
Who cares about looks, I care about functionality, well, I guess I do care about looks somewhat, take proxomitron's default colors when it came out, ICK. The user interface is perfect as a program goes.
But back to flow, nothing bothers me more than something taking away attention when you are working, pop up boxes, something that takes focus away from your work. I think this is why so many people like ratpoison, windowmaker, icewm, you can do your work without the distractions.
ok, do I really need Internet explorer to pop up and tell me when my download is finished? When I'm in the middle of typing an email? No. Stay out of the way. Stealing focus, or making a user hop around is biggest problem in UI design IMHO.
Vim.
No, don't laugh.
Its base set of commands is simple enough, and its effective.
For example, take 'd'. 'd' is for delete. 'dw' deletes a word, 'dd' deletes a line, 'd$' deletes until the end of a line.
'y' is copy. 'yw' copies a word, 'yy' copies a line, and 'y$' copies until the end of the line.
'c' is to change. Guess what 'cc', 'c$' and 'cw' does.
Moreso, 2dw deletes two words, as 2yw copies two words, etc.
Once you learn how one set of commands works, and you know another command, you probably know how that command works and how to use that command to extend the commands you currently know.
For example, /string searches for the next occurence of 'string'. Guess what
d/string and y/string does.
Sure, vim might not be the easiest UI to learn, but I seperate 'ease of learning' from 'ease of use'.
Just my $.02
PS: This post composed in vim. (Its my default editor for w3m)
Simple, but not restricting. Allow me to pull out the complexity if i need to. However, dont bog me down with 100 steps. (
Whatever you end up reading, I suggest you get some real users to sit down in front of it and test it. You need to be sure that the end user understands what you mean by what you say.
For instance, in this posting, your use of OS for Open Source instead of OSS for Open Source Software was mildly confusing because in the specialized world that is IT, OS, by convention, usually refers to Operating System. If you'd sat down and tested with a focus group, you might not have made this error ;)
Seriously, though, you'll get the best UI you can design if you just sit down with the end users and let them show you what makes sense for them...
Also try usability guru Jakob Nielsen's site Useit. Although mostly focused on web design it s a good read for anyone designing interfaces.
Thanks for browsing at -1
Please vistit my blog: www.framtiden.nu
Make a program that even one dummy could use and only dummies will use it!
It is not easy to create a software that is fully functional and intuitive at the same time. If you are searching for ERP, my bet is Navision. [currently Microsoft Business Solutions - Navision]
'nuff said
Good interface: Microsoft's Anti-spyware. My mom gets it.
Bad: Sybot Search & Destroy. I still think it's strange.
Good interface: SmartFTP. Makes perfect sense.
Bad interface: Filezilla. Different from the UI of every other (successful) FTP client out there.
Good UI: Google. So good that all other search engines basically adopted their interface.
A good UI can contain a ton of options, but doesn't crowd or confuse the user. Only the common options are immediately available. The mouse OR keys can accomplish most tasks alone. The menus are logical. The widgets are where they are supposed to be. The fonts fit the system. The images aren't crappy and dithered. The interface doesn't behave in unexpected ways (sudden resizing, etc). Users don't get frustrated (meaning, it doesn't steal control of your session.
Most importantly, don't underestimate the power of simplicity.
- Ability to manipulate data by dragging the category tiles around
- Formulae written in a reasonable facsimile of English
- Automatic identification of cell data collision
- Pretty simple scripting language
From 1992-1996, it was the only "spreadsheet" I would use. Too bad it could not migrate past Windows 3.1.You should really check out Joel On Software . His articles on user interface design are right on the mark. Specifically, you might want to read his User Interface Design for Programmers book (available mostly online, free).
Just sit back and watch the movies ...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
-- Simon
For desktop UI, I actually open up a few MS apps and just look around for ideas. Say what you will about MS (this is /., so I am going to get nailed for this), but they usually do a pretty good job with a standardized layout. Lately I have also been inspired with Firefox and Thunderbird and have incorporated a couple of inspirations from those apps into a project I am currently working on.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
I second the suggestion of "User Interface Design for Programmers". It is a brilliant book that covers most of the suggestions already made here. The book is short and very readable, and succinctly gets across the good and bad of UIs, plus how to go about testing usability effectively.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Testing + observation + refinement + more testing.
;-( As a result, probably most of the UI's I've designed are mediocre -- not bad, not wonderful either. With one or two exceptions maybe.
Not that I've ever had the budget to do something like that.
With respect to "sitting up and taking notice"; I've been experimenting with gnutella clients as part of my quest to locate a copy of the original Hitchhiker's radio series. If you look at Sharezaa, they have a skinnable user interface with a default skin that is graphically elegant. It has nifty effects like alpha blending on dialogs that are definitely "sit up and take notice" features. However, I ended up settling on Gnucleus for my task because it was easier to use, even if it was graphically cruder. It doesn't matter because I intended to run the thing minimized anyway.
The point is not to start a religious war between Sharezaa and Gnucleus users -- whatever works for you, works for you. Nor is it to start another rant about excessive use of chrome -- I've used up my lifetime allotment of rant time on that already. The point is "sitting up and taking notice" might not be the right metric for a good user interface.
A good UI (like anything else that is hard to acheive) embodies tradeoffs between somewhat conflicting priorities. People who don't understand this get hung up on one property, like "it has to be intuitive". However, they really mean two things by this: it has to (a) be easy to locate functionality and figure out how to use it and (b) it has to be easy and efficient to use. These are really in essence two different requirements; the only time they are the same is when a user is just familiarizing themselves with the application. While both these priorities can be accomodated in a UI to some degree, eventually you reach a point where you have to trade one off against another.
The same goes with innovation. We have reached the point in UI design where people come to our applications with the baggage of years of past experience. Therefore, while we could think of a better way to do things, we have to take into account the existing knowledge and skills of the user base. Again we have two conflicting requirements: to create a user interface specially suited to the tasks supported, but to exploit the existing knowledge and skills of the users. The best innovations then tend to be simple, and give users the ability to do more with their existing skills. In time, these become part of the baggage they take to future applications. Examples I've seen over the years: tabs on web pages; the three pane design for email browsing.
There are countless other examples of conflicts: a user interface needs to be pleasing to look at, but not distracting for example.
It doesn't help that people paying for systems usually don't have much design savvy. They tend to think of these things as ends that can be pursued independently. Managers tend to think you can strive for ultimate excellence in each area. The fact is that excellence comes from striking an exquisite balance between opposing needs.
One of my junior kung fu brothers once asked: what makes a kung fu master? The way I would answer this is this: a master is somebody who does nothing by accident and does everything with a good purpose. If he kicks you in the leg, he wasn't aiming for your solar plexus. If he steps to 30 degrees, he wasn't reaching for 45. If there is some kind of funky nuance to the way he does a certain move, it is not an accident.
The same can be said for masterful UI designs. If there are quirks in the design, they represent a deliberate choice that serves a real purpose.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I don't know about you making a good UI.
I can tell you suck at programming though. =)
but you're probably a winxp kinda guy...
Common places to look:
- Anywhere involving the mouse. Operations like selecting or cutting and pasting are very time consuming, and open to a huge degree of errors.
- Anywhere involving manual communication between programs. "The cron job emails this file to me as an attachment, then I save it and import it into Excel to run this macro."
- Anywhere that the human is acting as calculator. "I click in this field and then I type today's date."
- Anywhere there's a handoff between humans. "I start the server, email Jim to tell him its up, and then wait for him to tell me whether there are bugs he wants fixed."
- Manual touch points that don't need to be there at all. "I generate the newsletters, which takes like 10-20 minutes, and then when that's done I upload them to the test server."
In short, if you are trying to improve efficiency, then your human is your weakest link and your job is to minimize your human's input into the system. Whittle down their input to the bare minimum that cannot be accomplished by the computer itself, and then do the rest for them.Note very importantly that this implies there is one major audience that uses your product for one primary thing. We're not talking about something like a Microsoft Word that is used generically by a universe of different people. You said you have to optimize productivity, which implies that you have some control over hacking away at features that do not impact productivity.
www.HearMySoulSpeak.com
I nominate LyX. It's not that different from the WYSIWYTYMG interface of Word, WP, OO Writer etc., but the differences stand out and makes you notice them and learn why they are there. And the main difference is forced consistency, normally a good thing when writing documents.
It does need to upgrade its look, though.
Quite a good book on what not to do. Kind of like a checklist of mistakes to avoid.
Gui Bloopers. Also I dislike Swing - but the Java Look and feel design guidelines are ok. Apple, and gnome have similar documents.
A good interface is one that works as you expect it to: it defaults to things that you wish it defaulted to; it suggests you're making an error only when you're actually making one; and it keeps the easy things simple while also scaling gracefully for more complexity.
Unfortunately, the first line is key: it must work as expected. What you expect of it as a developer is different than what you users will expect of it; and even different users will expect different behavior depending on their own computing background, and how they relate computer use in general to the physical world. Don't laugh: everyone, even experienced users, think of their data as discrete files with words, not as 1s and 0s that are scattered throughout a few platters of HD. That is, we all operate the computer depending on some abstraction from it's electrical reality.
Your goal, then, would be to survey your users--not hypothetical ones, but real users that this app will be designed for--to learn how most of them expect certain behaviors to behave. IE: when you close the window, does the quit the application? does tab or return change fields?
I offer that doing this correctly is hard: most users don't think about their computer use any more than they think about the act of typing. But you have an advantage in that you'll be developing an application for a closed market, so you can identify the expectations of the users, rather than trying to anticipate the expectations of the world wide market of anonymous consumers.
--
$tar -xvf
Something that doesnt have animated paperclips or dogs.
... This is not meant as a slight to developers. Those who are intimately aware of how every detail of the program works cannot shift perspective and see it from the point of view of someone who neither knows nor cares about the inner workings. I've spent 15 years designing systems to be used in a manufacturing environment. Saying that any problems are due to lack of user training is a cop-out, one that will kill follow-on business. Industry has the operators they have and are not going to start hiring special people and paying them more to run my systems. It's just reality.
I'll give what I think are the biggest UI traps:
1) UI's that expose all the capabilities of a system. This is not good UI design, in fact it is lazy UI design. What you need to do is understand how your users are going to do with your system, and present them with as few choices as possible. Example: If you have a screen for looking up Customer records, and further allow it to be customized to show various fields, and further allow it to check or uncheck any field, you can end up with a screen that does not show the Customer ID (because it was accidently turned off). From the developers point of view you are adding functionality. From a user's point of view there is now a way to accidently render the screen useless, or at least annoying.
2. Beware of allowing users to customize (Wow - there goes my Karma...) Customization is fine for stuff you play with, but in a professional environment it is much more important to have consistency. It is important that people can walk away from something for a week or a month, and come back and get to work right away. It is important that telephone support can make assumptions about what the user is seeing. Floating toolbars, menu items that come and go with frequency of use, frames that can be moved from top to bottom, all of these make it difficult both for telephone support and for people who are "backups" i.e. they were trained once and only use the system every so often.
3. Don't be afraid of busy screens (Damn - there goes the rest of my Karma) Professionals get used to the layout and appreciate having all the information right at hand. (This makes number 2 - consistency - especially important). So err on the side of putting as much useful information as will fit. And prune mercilously anything that isn't useful or required. Don't you hate it when you go to a bank or an airline check-in counter and see the attendent typing endlessly, screen flipping, all at the speed of light, but... why exactly do they need all that commotion?
4. Keyboard shortcuts, labeled and encouraged. The mouse is great for a lot of things, but speed is not one of them.
5. Remember your audience. Are they people who sit in front of the screen all day, using your application as their primary function, or are they several times a day users who simply need it to perform a vital function but just want it to work and go away? Even if it is the former, what about their backup's or the third shift people? In any case, present what they need immediately and clearly and leave off the fluff and BS.
6. Most important. Remember that your application is not what the people do. It is a tool that helps (or hinders) them in doing what they do. A tool should not be their primary focus. The task is their primary focus. Whether a carpenter or developer, any time spent fiddling with a tool simply means less time to spend actually doing the task.
No, and neither will you. The sign of a real good user interface is that you don't notice it, you just use it.
The problem is that it takes a lot of very hard work to get that far and most application developers (Open source as well as commercial) don't bother and/or lack the skills to do it.
My opinion? See above.
A good UI is one that does not cause to you sit up and take notice at all. A good UI is one that lets you sit back and get your work done, without making/allowing mistakes, without making you do anything repetitive, allows fast work, and all this without getting in your way.
Now creating this interface is often difficult. It is worse because sometimes the best UI for novices is different from the best one for experts. A novice needs a easy to learn interface, while the expert already knows it and just wants something that gets the work done fast.
Example: An accountant needs more power from from an accounting package than the average Joe. (yet the average Joe needs to send everything to an accountant once in a while!) "Joe" doesn't know how double entry bookkeeping works, and shouldn't have to learn. The accountant needs to know and use it.
I had to write a report on this topic for a programming class last semester. This article was quite helpful... if you haven't heard the microwave analogy, then you're still thinking inside the box.
m l
http://www.asktog.com/basics/firstPrinciples.ht
Vanya's Law: "In any culture without irony, fart jokes will be the highest form of humor."
I have heard others say that: The only truely intuitive interface for us humans is the nipple.
Almost everything applies to sceens, too.
--dave
davecb@spamcop.net
In my limited experience userfriendliness is about presenting the UI that the user expects. what this boils down to:
- Same look-n-feel as the OS.
- Multiple ways of doing the same thing. (menu, right-click context, shortcut keys, CLI)
- Lot's of help and documentation, and easy access to it. Pressing F1 should always result in relevant help. But a help button should be there too, hovering should give a short description, and preferably wizards should be available for most tasks.
- Consistence in and between different parts of your application(s). For example OK/Cancel should be in the same order everywhere. Tab-order of buttons should be logical.
- Correct analogies to "real world" examples. When creating a tool for electrical-engineers, know what tools they use and how they look.
- Don't give the user to much choices at the same time, split into multiple windows if choices get above 3-6 works for me.
- Don't bother users with stuff that can be automated.
- Minimize the amount of work a user has to do to accomplish something.
- Allow the user to configure settings, but provide sane defaults.
In short:
Just read the different UI guides that are around, and rigoriously adhere to them. Next to that try to use good methaphores and try to make life easy for your user.
- Next to that I find that pretty pictures can make your application be percieved as "more professional", but "pretty" is somewhat subjective. People think of themselves a professional and want their software to give them that impression.
RogerWilco the Adventurous Janitor
iTunes (all of the iLife apps, actually), Excel, Jewish Calendar...
Actually, if you're a Mac user, you're accustomed to sitting down in front of a new app and instantly grasping it. For whatever reason, the sensibility that that is important has never taken hold in the Windows world, let alone in Linux.
The gem I encountered recently, though, is Windows/Linux: HelixTree for genetic analysis. Not trivial, but given the complexity of what it does, an incredibly intuitive UI.
What I'm listening to now on Pandora...
There are two distinct issues to consider, and they are often directly opposed to each other. The sorts of things you want to make it easy for first time users to grok are often the very things you need to get rid of if you want experienced users to be fast & reduce errors.
Want raw speed and accuracy? Do it in text mode, make everything accessible from the keyboard (or even better, the twenty or so keys of the "ten-key" pad). It will take operators a while to get up to speed, but when they do even the average operators will be two to five times as fast as the very best operators of a mouse and kitchen-sink GUI. And their error rate will be much lower.
On the other hand, be prepared to fight off attempts (every year or so, in my experience) to replace it with a "modern" interface that looks pretty even as it kills productivity.
--MarkusQ
Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it?
But that is most emphatically NOT the point. The interface I like best is the interface I don't notice. Hyperlinks are a good example - you just click on a word and you go. No wizzy effects. No colored buttons.
If you want an interface that brings real benefits, look what you can remove, not what you can add.
Sean Ellis
Follow OfQuack's antics on Twitter.
Vim isnt modal. It ahs one mode: command mode. You enter text by postfixing the 'i' command with your text and then ESC to finish the 'i' command. Simpel as tath.
I am taking a class in Software Engineering and Chapter 4.12 (Interface Design Principals) in the book is all about UI, with suggestions on consistency, choice and order of words in menu, icons, etc. It might not be the most comprehensive, but it should give you a great start.
1 74225X/qid=1108739673/sr=8-1/ref=sr_8_xs_ap_i1_xgl 14/002-8239742-6614463?v=glance&s=books&n=507846
http://www.amazon.com/exec/obidos/tg/detail/-/020
"Project Based Software Engineering: an Object-Oriented Approach"
General Guildlines Section:
1. Be Consistent
2. Provide shortcuts
3. Offer useful, meaningful feedback
4. Design a beginning, middle, and end for each sequence of actions
5. prevent catestrophic mistakes
6. Verify Deletion tasks
7. Allow easy reversal of most action
8. Make user focus on task, not interface
9. Do not rely on user memory
10. Display only currently relevant information.
Realize that this is just how the section starts... there is a lot more in there.... You can probably check it out at a University Library.
--Dave
A good UI should be infinitely configurable. A good example of what I think is a very bad UI is Aqua, the famous OS-X interface. It's even worse than the Windows interface. Look through how much trouble you must go to make a black background! And I'm not even talking about window behaviour etc. The Windows interface is a bit better, but the one I like best is fvwm2. It takes quite some time to figure out how the configuration file but then you can do absolutely everything.
-- Cheers!
Agree very much. Specially point 2.
Another one is to get rules about data documented, and keep on asking, when they say "and then I know that this record is bogus, so I ignore it"
In short, if you are trying to improve efficiency, then your human is your weakest link and your job is to minimize your human's input into the system. Whittle down their input to the bare minimum that cannot be accomplished by the computer itself, and then do the rest for them.
Spoken like a true non-user. The human is not the weakest link, the human is the one getting the job done. The machine is there to serve the user, not vice versa. If the user's needs are to have two buttons to click repeatedly, George Jetson style, throughout the day then that's the interface you need (I do a lot of manual QA stuff that's exactly like that). If the user needs a thousand knobs and dials, then you need to figure out how to organize those knobs and dials. It's not your job to tell the user to get out of the way and not worry their pretty little head while the computer works its magic.
I can't even get the engineers here to design a George Jetson interface properly. You'd think the button that everyone pushes literally several hundred times a day would be one they could make a little bigger, right? Nope, the point of the whole app is apparently about precise aim, not productivity.
I am no longer wasting my time with slashdot
Text.
Seriously.
I have used it as a reference many times when working on Windows programs.
antipaucity
Although readline has a somewhat substantial learning curve it's my favorite UI. Using bash I can honestly say is a pleasure.
There\'s no place like ~
...the interface from Minority Report. The protagonist (aka Tom Cruise) pointed at things on the screen and waved them to where he wanted them to go. Here's a web page describing the interface.
Tired of "pointing and clicking"? Then move beyond GUI to a whole-body user interface WBUI (da-buoy). Some videogames already interpret users' motions (Sony?). Why can't this be adapted to more mundane tasks? Add a voice recognition function for new text or commands. How cool would that be?
to err is human, to forgive is divine, to forget is... umm...
Oh, I wouldn't say that's true at all. I think that by eliminating the redundancies, wait periods and other spaces were error creeps in, you free up the more important resource - human expertise - to be applied the way that it should. QA is a great example. If because of all the manual effort that you have to do you can only properly QA 10 bugs a day, but by optimizing some of those areas I can get you up to 30 bugs a day, didn't I just make you better at your job? I didn't lessen the value of properly QAing the system, nor did I lessen your input into finding and fixing bugs. I just made the system more efficient for you to do it in.
I didnt say the human is the weakest link. I said the human is the least efficient part of the system. If you need a thousand knobs and dials then I don't want to take those away from you. But if I discover that 90% of the time you're only using 3 of those knobs and the other 997 are for very rare circumstances, you can bet that I'm gonna move them to another page. Otherwise there is a portion of your time spent scanning for the right button out of a thousand, and a portion of time spent in error, which does not need to happen.
www.HearMySoulSpeak.com
UI are just a form of communication after all, and could be thought of in terms of protocol implementation. A mentor (of sorts) years ago in a standards working group addressing communications for support systems proposed that a comm. protocol design should consider four aspects. (1) Syntax specify symbols and their arrangement. (2) Semantics specify how symbols are interpreted. (3) Intra-message context specifies the 'rules' for using symbols within a specific message format(i.e., reg. expressions). (4) Pragmas (otherwise called "Shared Knowledge"), this is the toughest to tie a meaning to, and yet is the essence for effective communication. Basically it deals with commonality of experience. This is the point to which above the discussions point and contains the answer to the original question. This is the principle that the UI designer is designing to... . In other words, ask the potential users what they what to do!
Bruce Tognazzini's site.
He founded the Apple Human Interface Group and acted as Apple's Human Interface Evangelist. He's also written two books on UI design.
I'll throw in a vote for OmniGraffle and OmniOutliner, OS X software from the Omni Group. They both nail what they are supposed to do so well. It is simply a pleasure to use either one of them. I use OmniGraffle at least once per day to draw diagrams for my classes and exams, export them to pdf, and import them to my LaTeX docs. OmniOutliner is a wonderful structured writing tool with simple text input and manipulation.
I believe that a key to good UI design is allowing the extensive options and a high degree of control over the software through both a graphical user interface, and a command line interface.
With GUI design it is important to not throw up to many options at once but provide a rich and complete set of options but place the most commonly used ones on main screens, and then put lesser used ones on "advanced" or "expert" screens. Organise and categorise options and cofiguration settings, and features and make them all easily accessible, but with most commonly used ones most prominant. Include a toolbar with commonly used features, then on the menu bar you can include the commonly used options and advanced options in "advanced" menus and submenus. This way, the average user isnt bombarded with options, but the user if they desire can set the more advanced options and features if they wish. The software should give users complete flexibility and control as possible and let them configure everything, but only if they want to. If all the user wants to do is jump right in and start doing what the software is supposed to do, they should be able to do so and the software should use reasonable defaults. The idea is to give the user the choice and freedom, if the user wants to control every aspect of the program, they should be able to do so, but if the user just wants to start using it withonly having to make a bare minimum of choices, they should also be able to do so. You can give users both. The program should be as simple or as complex as the user wants it to be, and allow the software to work the way the user wants it to work rather than enforcing limitations and restrictions on the user.
The command line interface allows for the programs features to be more easily scripted and integrated into other programs and as well eisier remote ssh and command line access to the programs features for those who desire it. Agian, no one is forced to use it as it is an advanced feature, they can still use the GUI, but it is there if someone wants to use it.
Here is a great rule of thumb when designing a UI: No one wants to use your stupid flipping application. Once you get past the ego trip of 'my app is in front of everybody, it must be shiny and say something cool about me', things go much better.
The UI should get the heck out of the way and let the user do his work. Things should be intuitive. Use the right control for the right job. Be consistent between screens. Watch how your users do their job, and use your system. If there are unnecesary clicks because focus goes to one control when they really use another control, fix it!
Sometimes, it is necessary to design a form that a five-year old cannot use. When this is true, include helps and hints (tooltips for quickies), some type of pop-up when longer help is necessary.
Most important: Sit with your user and watch him do his job. Feedback is so important, but how you get the feedback is more important. If you solicit feedback, you will generally get a million stupid suggestions, and the important ones won't get brought up.
Identify your power users. These are the ones who figure out how to break your app, who give you the ten ways to improve your product (and generally have good throughts -- not, "the background color should be puce"). Talk with them, thank them for their input, follow up when you have incorporated your changes, ask them if the changes were what they had in mind.
Keep your audience in mind. For lower-skilled workers, I keep things simple and avoid complicating the process. I put a higher emphasis on warning if things 'don't look right' to the computer. For higher-skilled workers, I give the user more autonomy, and less hand-holding.
Most of good UI design revolves around knowing your user base and communicating with them.
There are a ton of books that talk about the nuts and bolts. But good people skills is what seperates the code monkeys (who have three times more coding skills than me) from the successful software engineers.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
When you start the application, or create a new entry, the cursor should automatically show up in the first field. Then once you start typing, the focus should never jump to another field mid-word.
Aside from the security issues, this is why I can't use IE.
I didnt say the human is the weakest link.
Yes, obviously, I did. I see my own post. What I meant was that in relation to mr. snorklewhacker's comment that I was not intending to suggest that the human was the weakest link in getting the job done, just in getting it done efficiently. If the measure is getting the job done, then the human of course is the most important bit. If the measure is the efficiency in which it got done, then the human is the weak part. Clearer now?
www.HearMySoulSpeak.com
i'd say go even one step farther. hire a person who specializes in HCI (human computer interaction). i know a bunch of people who have graduated with phd's in psychology that have gone to industry as hci people and do this exact thing. they may be a bit expensive, but they are really good at their job. they'll save you a bunch of time, they already know where to look for problems. plus they can speak to both the developer and the user in their own languages. if the submitter's goal is to develop a custom UI for a specific job, then general rules (like those from joel, or apple, or gnome, or...) will not work, you need to taylor the ui to this specific job, and an hci person will do that most efficiently.
While I am a strong Open-Source-Software user myself, I've found that quite often some of the biggest points of contention between the users and developers come with UI design/enhancements. If it's a programmatic bugfix the developers are happy to fix it, but if it's a UI/usability fix/change most developers seem to get their hackles up.
Developers of projects like the GIMP make a UI have long ignored user requests for things like an IDE environment, and when pushed both the developers and power users alike tend to get contentious.
Of course GIMP is just one example, many programs are like this. In the case of having something simple like an IDE, how hard would it be to simple allow an option to turn it on. It would satisfy both new and power-users, and put an end to many a flamewar...
Beware of allowing users to customize (Wow - there goes my Karma...) Customization is fine for stuff you play with, but in a professional environment it is much more important to have consistency.
I agree for different reasons. I dislike emacs because I can customise it in endless ways, but it isn't set up remotely adequately be default. I could spend ages learning how to do this, but an editor is just a means to an end.
I guess that I should bugfix my abbreviations, the issue at-hand with GIMP was more for an MDI (with a parent form) interface, not an IDE (Integrated Development Environment).
> Get clipboard. Stand over shoulder. Watch
Great post, thanks very much for writing it!
The beauty of the things you're suggesting is that most of this stuff can be fixed with a few lines of code. It just takes someone who cares enough to actually watch the users and see how they work.
The Army reading list
ALl of ed's commands are single letters. What could be easy to remember than a single letter?
a appends text. c changes lines. Simple!
And the error reporting is second to none! If your command contains an error, ed helpfully prints "?" to your terminal. No memorizing what 200 different error messages mean, all you need to remember is "?". Isn't ed great?
Don't blame me; I'm never given mod points.
And have some way to turn off anything automatic.
I despise MS Word for one specific reason.
I don't think that I have ever created a document in it that didn't get messed up somewhere along the line when Word decided to "fix" the formatting or bullets or some other element. This invariably leads me to waste five minutes figuring out what went wrong. This is also why I still like Wordperfect, where "reveal codes" would let you delete what didn't work.
The point though is that Word almost never manages to guess what I want, and consequently is annoying as hell.
OpenOffice is better, but there have still been times when I just about gave up on it - why would anyone default to pasting URLs or e-mail addresses as clickable links in a document which will be printed on paper? It just makes no sense.
Which leads me to my second point. Let me turn things off. I especially would love one checkbox which would disable all formatting of e-mail addresses, URLs, and anything else that programs want to underline or turn green.
Three Squirrels
MS Windows Calculator.
-- $G
As long as you design from data linked to actually users performing actual work, the UI design should become transparent.
I would recommend Designing the User Interface as a good starting point, as well as Contextual Design as a great way to learn how to gather actual user data.
While it is true that everyone has their own individual UI preferences, designing the UI to function well based on actually data instead of what the designers feel will work always provides the best UI. You need to find out how the user actually does their work in order to design a UI that helps them perform it.
I was given to believe that there are textbooks on UI design, much the way Mac goes about it. It tells you left-to-right cognition, widget distances among the few. And the most critical piece being mapping functions built into the software into the user interface.
And I'm bound to ask, does slashdot have a good UI in any of these terms. Sometimes people just start habitually getting used to UIs and stop complaining.
Just the place you've already visited probably is Amazon A9 link on Xerox PARC and their UI work.
No Greater Friend, No Greater Enemy! (Lucius Cornelius Sulla)
IBM has a good set of guidelines.
s h/561
http://www-306.ibm.com/ibm/easy/eou_ext.nsf/publi
Nielsen has published ten high-level heuristics for making a good interface. You can use it as a checklist.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
You said: ...I can customise it in endless ways, but it isn't set up remotely adequately be default. I could spend ages learning how to do this, but an editor is just a means to an end.
Excellent point. Even for those who have the time, energy and understanding to customize everything, it is not necessarily now they WANT to spend their time.
There are good UIs, which follow all of the official look and feel requirements. There are efficient UIs, which allow users to work at their maximum speed. Do not confuse the two. They may not and most often are not the same.
My wife works in accounting and is extremely fast at using one of those printing calculators. However, the user interface in her accounting software make her mouse or tab between fields, greatly reducing her speed of entering data. It looks nice, but is difficult to use quickly. The interface for DOS applications was often much more efficient than their Windows counterparts because it allowed the users to keep their hands in place and reduced hand/arm movement to just finger movement. Compare that with having to reach for the mouse all of the time.
Here are some quick guidelines for improving data entry speed in applications:
1) Minimize hand movement for numeric entry and forward navigation through numeric fields by encouraging use of the numeric key pad.
2) Minimize hand movement for character data entry and forward navigation through character fields.
3) Try to keep fields of similar data type in order (where appropriate) to facilitate use of #1 and #2.
4) Allow the use of the mouse but don't require it unless you absolutely have to. This can be aided by selecting field types which allow the most efficient entry of the data such as text entry for a date instead of a calender popup. If your hand is already on the keyboard, keys, even hot-keys, are faster than the mouse.
This all boils down to reducing the amount of motion required to perform a task. Generally speaking, reducing motion increases speed. As for inspiration, take a look at some of those efficient DOS apps and see if you can use the same keystrokes in a GUI version. You get bonus points for combining that efficiency with UI look and feel requirements.
Years ago, when I was a customer service peon, we telnetted in to a server to access customer information. At some point, they rolled out a reasonably well-done GUI app to replace it.
The surprising thing is how much people bitched about it. Non-geeks actually preferred the console app to the pointy-clicky one, partly because it was a change from what they were used to, and partly because what used to take a couple keystrokes now took three or four moues clicks.
Looking at the other posts, you'll get lots of good advice to make sure that the UI is easy to learn, doesn't require users to think too hard, and undergoes user testing and revision. But since this is presumably something that people will be using every day, make sure that people also have the ability to get their stuff done quickly: common stuff should be accessible quickly, and there should be keyboard shortcuts.
I think we're actually in violent agreement here: When the interface gets in the way instead of helping, you lose efficiency. By being the most critical component of productivity, that productivity gets lost if the human isn't served by a proper interface. I sort of made a knee-jerk response to the perceived attitude that "dumbed down" is somehow better. Unfortunately, I do actually get to see that philosophy in action fairly often, and often it's hidden behind neologisms like YAGNI (You Ain't Gonna Need It -- a glib way of dismissing requirements used by the exponents of a methodology that pretends to be responsive to them)
I am no longer wasting my time with slashdot
DEC VAX.
Perferably emulated under Windows.
You may laugh but it is to-the-point, simple to use and with the emulator the user can have a windowed environment.
DEC databases,b-tree, c-tree, whatever, built in the 80s still run business critical systems today. They are accurate, staff use them without any problems. These days a business-oritntated database promotes itself as being 'extensable' but if you get a life cycle of over 3 years you're lucky.
IT consultancy gone mad. Two-bit programmers learn object-orientated programming and SQL at university 'Computer Science' courses. Fantastic, interesting stuff. But them they reinvent a wheel re-creating a system which already existed but 'adding a nicer GUI and greated extendability'. Examples:
1. 'User-firendlyness': A user wants to run a pre-existing report. Is it better to load a lightening-fast console, press 2 to get a report menu and 3 to choose the report, or is it better to load a slow windowed application click on 'reports' menu and choose the purple and green icon. Indifferent? Then why is it better to create a new system? Plus the users will have to be trained on the new one. If you really want to have a windowed system a WM can be strapped on to an existing code base, it is not necessary to reinvent the wheel. 2. 'Stability': DEC VAX as stable, a computer in my office which runs business-critical accounts has been 'always on' for over 5 years. SQL server stable? Oracle stable? See next point...
3. 'Breaking a nut with a beautiful yet powerful diamond tipped auto-targetting smashing device which very few people seem to know how to use': Why not use a nut cracker? In finance, my field, object-orientated programming is fantastic, models are always evolving, we can re-build a module to increase speed sophictication and add more to add scope, no OOP would mean someone would invent it. Is it necessary to have OOP to calculate cash flows and valuations... *buzz* no! Legal and accounting regulations change now and again meaning an update is necessary, but trade-off 0 development time (because a system is in place) plus a little refining, against creating an entire new system from scratch! The analyst who rebuilds a complex project from scratch is one who must ask hard if it was necessary or they're trying to fit something into their ideological framework, which leads to:
4. Insufficient developer skill. Even if the project is well defined and management is good, you still need people to program intelligently. C-tree is pretty efficient and straightforward once the initial work of understanding the data is carried out - the effort is front-loaded. SQL is the reverse: the language is dead simple as is understandingthe data, the trouble many programmers have is writing efficient algorithms, I often see a procedure with a subquery iterating many times on the results of an intial query (often with a new database connection being made every query!) when some simple (for someone who knows it) refinement of code would increase the speed 100 times+. SQL and relational databases dumb down programming as many dumbed-down people join the profession and poor quality results. THis applies to the Perl-monk who writes 95% of a complex system in a day and can't be bothered/forgets what they've done and cannot decypher the code they wrote themselves. It also applies to (earlier point) programmers/developers who cannot see past OOP: sometimes OOP is a poor choice not for a simple project but a complex one, the best example I can think of is array programming, many OOPers just don't get it and write damn slow inefficient code and are unwilling to learn any other skill.
Quite a rant, I apologise. I suppose I mean, look at your own abilities, are you reinventing a system because the existing one doesn't fit in your skill set or is there a genuine need? If the need really is genuine then perhaps you don't have to reinvent the system, just add a partial GUI when users click on menus o
I've been searching for a website that would just show screenshots of "pretty" UI (something like this. Screens from well done semi-futuristic movies, where they spend all their time on UI, would be nice.
You quitting proves that the karma kap worked. The most annoying of the whores shut up. --CmdrTaco
... This is not meant as a slight to developers. Those who are intimately aware of how every detail of the program works cannot shift perspective and see it from the point of view of someone who neither knows nor cares about the inner workings.
It might not be meant as a slight, but it is one. It's also wrong. Developers can be good judges, but it requires them to do work. They actually have to sit down and understand what the users are trying to accomplish. Then test their own apps.
Saying developers are poor judges is as much of a cop-out as the earlier post that said UIs couldn't be uniform because users are eratic. If you work on windows, tell me, where should you always be able to find a button to close the current window? If it's not there or doesn't work, then you know a bad UI. What you are describing are developers that design applications to manipulate data, not one that performs a user function.
BTW, I agree with you on user customization. I have a special place for most authors of 'skins'.
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
UI's that expose all the capabilities of a system. This is not good UI design, in fact it is lazy UI design.
:-)
A UI that doesn't let you access all the capabilities of a system is a broken UI. Think about it. If I write a program that can sort a list of numbers in either ascending or descending order, but only provide an interface allowing an ascending sort, what the heck was I doing coding the descending code in the first place?
This doesn't mean that the main screen of the UI needs to access secondary and tertiary functionality, but you need to provide some interface for the user to all the functionality.
Beware of allowing users to customize...
Customization is necessary for most ERPs, simply because no two enterprises have the same needs. If I have been using 9 digit SKUs for the last twenty years, and your software only allows 7 digit SKUs, then your software is going to cause me problems. I've actually encountered this exact scenario at work, where we have one database whose sole purpose is to translate old part numbers into the new part numbers used by our new inventory control system.
More generally, some level of customization is necessary for ALL software simply because no two users are alike. That doesn't mean you have twenty pages in a tabbed dialog for all the little tiny tweaks a user can do. Rather it means that the software has to be flexible enough to accomodate more than the mythical average user.
Don't be afraid of busy screens...
I've seen your screens. And I want to scream every time. While I do want all related necessary information on the same screen, I don't want ALL information on that screen. Based on some screens I've seen, it's almost like some developers have never heard of the "next" button, or expect you to have 1280x3076 monitor.
Dialog design is like writing. As a famous essayist once told me, the key to good writing is to take as much away as you can. Ditto for dialogs. Take away as much as you can. This doesn't preclude "advanced" buttons or multi-paged dialogs, of course.
Keyboard shortcuts, labeled and encouraged.
I absolutely agree. There is this CAD I use that only has keyboard shortcuts for the most common actions, with no way to customize [!] additional shortcuts. The more I improve using this CAD the more frustrated I get with this lack of functionality.
I also agree with your last two points as well. That's three out of six, so I guess that makes one of us only half right
Don't blame me, I didn't vote for either of them!
You said: A UI that doesn't let you access all the capabilities of a system is a broken UI.
If you add the word "necessary" in there somewhere, I would agree with you. I'll give you a real world example: Print orientation in industrial inkjet printers (these are the kind that write the date on the bottom of coke cans - not anything like a Deskjet). Because these printers are non-contact, you can't predict ahead of time which direction the product will go past the printhead, whether it is upside down, and whether it is printing on the inside of something transparent in order to be read from the outside. There are 3 different parameters that give you all the 8 different combinations, and 7 of the 8 could be used in the real world. The traditional way is to give the user control over all three parameters and let them try to figure it out. The better way is to let them print a test message, then select the way the print acutually printed. The code figures out the settings that correct the orientation. More work for the coder, but much easier for the operator. When this second method was implemented it was considered by many to be an amazing leap in the printer technology, when in fact, the printer hadn't changed at all. Sold a lot of printers though.
The important thing is to understand what the end user wants to do, and present it in a way that makes intuitive sense to them. It is oftentimes more difficult to code, but it is really the only right way to do it.
Yes, I make a habit of stopping by the manufacturing floor to see how the guys are doing and if there is anything that annoys them or something that they wish worked differently.
If I don't stop by, they never approach me with requests, but when I actively seek them out, I get feedback about changing a comment, making a test longer, shorter, bigger buttons, etc.
I am fortunate to be able to do this I think, because my boss doesn't really know what I am doing, so I can take time to learn PHP/mySQL and add new features and apps to our corporate intranet to improve productivity, in a relatively short period of time, but lots of other guys figure they don't have time to do it, and so nothing ever gets any better.
> I make a habit of stopping by the
> manufacturing floor
Sir, I salute you. You're right on the money - an on-site customer is the best thing you can have.
> I can take time to learn PHP/mySQL and
> add new features and apps
I found myself in a similar spot once and wrote a several Java apps which were deployed using JNLP. None of them were ever spec'd out or anything beyond a "it'd be cool if we could do blah", but they were all widely used and made folks very happy. And I got to learn some nifty stuff... good times!
The Army reading list
You haven't really disagreed with me. You've merely given me an example of a UI that provides access to a capability. Printing the test message *IS* the user interface for the print orientation.
The only reason I brought up this point is that there's currently a trend to hide away functionality from the user. I vehemently disagree with this philosophy. Advanced or complicated stuff would be better served by partitioning it into a different interface (an "advanced" dialog, or a tools submenu, or a scripting interface, etc). Writing the code and then never letting the user make use of it is utterly pointless.
Don't blame me, I didn't vote for either of them!
So, before you even think about the UI, work out what people will be doing with the software. What things are they trying to achieve? Be specific. (This is where use cases can be very helpful.)
Then you can look at a UI, and judge how best people can do those things, with the UI getting in the way as little as possible.
So your request for a flash, impressive UI is pointless: the best UI will be one that you're not even aware of! And one which seems completely obvious -- but only after you've seen it...
Ceterum censeo subscriptionem esse delendam.
Please think of the children: Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?
Not the definitive answer to your question, but food for thought...
[o]_O
Kudos also for Quickdraw, an object drawing library built into the OS where you can actually do WSIWIG in whatever app, move the draw/text objects into the clipboard and then later out into another app and still be able to edit, and to the printer without missing a beat. I really miss that when playing with Linux, the graphics boundries are well divided between screen and printed output. Again with OSX the push to raster images sure makes for a much larger footprint with all the pretty (bitmap) buttons and such.
Next is AppleWorks, Microsoft has nothing on the intuitive nature of this gem, want to make a database? no problem, draw a picture (with drawing tools)? no problem, merge the drawing into the database? no problem. Write in the word processor, graph on the spreasheet, merge the spreadsheet into the WP, slick as all can be. Though if you read Apple's comments it soulds like they are re-writing into iWork and it is uncertain if it will remain as flexible (or maybe it will be moreso?) Either way, AppleWorks get's alot of bad press because no one ever really looks at what simple power it gives the user.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I have been an accountant for over ten years and most of the software I have seen is indeed awful.
I would like to see a UI where navigation is done via hyperlinks rather than the MS button/drop down box model. Also push most of the processing to the server and keep the client as thin as possible...accounting departments are always last on the list for PC upgrades. I am currently stuck using a Lawson setup where it takes longer for the GUI to switch from the report launcher screen to the output screen than the actual processing of the report. That's a flaming joke...
"Lack of technical competence coupled with the arrogance of power, as usual, leads to no good end."
There are also a lot more things you can do with physical devices than you can do with a GUI.
There is not a single widget that annoys me more than the twisty-knob, and the only reason I can see for its existence is that some UI people who spend more time talking about how to use computers than they do using computers think that we need to have twisty-knob widgets because real devices have jog dials and volume knobs and the like.
The "UI should mimic real life" idea was obviously designed by people who don't realize just how different "four articulated fingers with an opposable thumb" is from "tiny little clicky arrow."
I've been using Macs since I was 10, and although I never learned how to write code, I used to sit at my Mac for hours and study the interface of the OS and various programs. I'd click on the buttons and all the other widgets just to see how the program had been designed to "do things." As a result, I've become somewhat of a UI nut - I think I have a pretty good sense of what makes a good or bad interface when I see one. I can pick out specific details of what parts of a UI don't work well and why they don't work well (as well as parts that do work well), and I become genuinely pleased when I find an app. with a really well-designed UI (I also rant and rave to myself about the bad ones sometimes).
I wish I could name some old apps that would be really good examples for you, but it's been so long I can't remember (plus it's late and I'm tired), so you'll have to just try them out yourself and see what you think. (Oop! One off the top of my head - ClarisWorks. It wasn't perfect, but it was really nice to use in some ways.)
Go buy an old used Mac or two somewhere and load System 7.1 onto one. Play around with it and with various apps until it seems to you that you really have a good feel for the system of logic used by the programmers who designed the UI - why they made things the way that they did. Then load System 7.5.5 onto it. Figure out how it's UI is different from 7.1. What changes do you like? Why are they an improvement? Why do they make the user's experience better? What changes are not so good, and why do they interfere with the user's experience? Then do the same with 7.6.1, 8.1, 8.6, and 9.2.2. As you upgrade the OS, remember to look at new versions of applications and note the changes in the designers' thinking there, too.
Once you've done that, there's an excellent series of articles on ArsTechnica which detail the evolution of Mac OS X, a good portion of which are devoted to the user interface, usually what John Siracusa doesn't like about some of the UI changes in OS X (some of the information on the underlying structure of the OS is really fascinating too). In the above link, scroll down to just above the Table of Contents to find a list of articles reviewing OS X starting from Developer Preview 2 (personally, I'd read them chronologically). This link will take you to his review of OS X 10.3, which contains links to the 10.1 and 10.2 articles in the first paragraph. He brings up some really interesting points about the UI design of OS X, and I tend to agree with much of what he says.
Of course, this is not to say that the classic Mac OS (or OS X) and associated applications are the end-all-be-all of user interface design, but I do think that the classic Mac OS and some of the programs for it had UI designs that were very, very good - certainly worth learning from. The interface for OS X is good in ways, and does have some improvements over the classic Mac OS, but I personally think that there were some aspects of the classic Mac OS UI design mindset that were left behind which were worth saving.
I've also heard over the years about some legendary user interface research done at Apple "in the old days," but I've never really taken the time to look it up or see if it's publicly available. But, if you can manage to get your hands on that, I would think it would be a very valuable resource for mulling over the concept of interface design. I certainly would browse through a copy if I had it.
I hope this helps you in the future, if not on your current project. To do everything I've suggested would take a while, so it probably wouldn't help you on this one. But I think that if you do it, it will help you with any UI project you do for the rest of your life.
Apple's Human Interface Guidelines is a great place to start. They cover a wide range of issues, many of which you wouldn't initially even think about.
Specialist Mac support for creative pros, Melbourne
Iwasn't trying to disagree with you. I was merely pointing out an example of what I considered (and thought you would also) of a positive example of hiding functionality.
Here's a more direct one: In a similiar vein the group responsible for developing the UI for a higher resolution printer was working on a windows driver and the corresponding application. They exposed every single Windows option for font control. I can't remember all of them now but there are many choices that you certainly don't even get in Word. This interface terrified and overwhelmed users (fortunately it was only an alpha). But the developer couldn't see it. 'If they can't understand it, they should take the time to learn it.' For the labels these operators were creating, they simply did not need these functions. We cut out most of the choices (and made the remaining ones much more intuitive). Industrial UI is all about speed, clarity and easing the frustration factor. Line operators have twenty things they are watching and setting up. Learning how to anamorphically resize print is a ridiculous waste of time.
It's not that they would never use it, it's that it would cause only trouble - "My print keeps changing in size - it spreads out'. Well, spreading print can be caused by mechanical problems, product handling problems, and by electrical problems. We would end up with a $125/hour service call (or one we eat under warranty) because someone on a different shift accidently created a format with some weird spread out font. I RAN service. I would bet my last Lorna Doone that this would be responsible for unnecessary service calls much more often than it would actually benefit someone.
Who is the user? In the case of your font options, it's you the printer device driver author. Not the consumer. To take a more generic example, exposing ever ioctl command to the user via a KE control panel would be supremely silly, but as a developer working with that device, I sure as heck want to know what they are.
This isn't hiding functionality, it's layering it.
Don't blame me, I didn't vote for either of them!
in answer to your question The first Gui that made me sit up and take notice was kinetix 3d studio max for digital animation the majority of work was done utilizing all three mouse buttons scrolling and ctrl and alt holding plus you could always access thing more than one way -jsin
When we set out to design our latest web application where I work, I patterned it after some of the GUI concepts found in Microsoft Money 2000 and Windows XP. I had noticed from using these applications that business processes were presented to the user as clear tasks. Instead of OK buttons, I was seeing "Add New User" buttons. Things are getting more descriptive with paragraphs of instructional text and clear dialog titles. I think our new application ended up being more usable by following some of these general approaches.
It wasn't until a couple weeks ago that I realized Microsoft had coined the term Inductive User Interface to describe the design. This article introduces the concepts and gives some crude useability testing results.
Interface Hall of Fame
Interface Hall of Shame
Whenever I design a UI I always think "what would the lotus notes designers do?" and then make sure I do nothing like that.
Input error. Replace user and press any key to continue.
Biggest thing I see:
Do you want to exit? OK. || CANCEL.
Don't let your users figure out what it means.
Do you want to exit? YES. || NO.
Make your dialogs logical questions with logical answers.
Colin Dean Go a year without DRM
So they're going to "clean their cocks" huh? Please stop advocating for the rest of us as you appear to be getting a lot of things wrong here. Youre advocacy makes the rest of us look bad.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Personally, may I recommend a keyboard such as the IBM ultranav. It has the integrated trackpoint, which is brilliant, since I never need to take a hand off the keyboard to use the mouse. (Yes, I have an external mouse for graphics, but I rarely use it otherwise). The result is that it is dramatically faster to use.
I found the trackpoint so wonderful on my thinkpad that I bought an external keyboard with one for my desktop!
However, I *hate* the inbuilt touchpad, and the fact that the trackpoint doesn't come with a scrollwheel. Well, with a bit of hackery, it does now. Effectively, I have a 3-button mouse, with a scroll wheel implemented via a 4th button, and XF86's "emulate wheel" option. The 4th button is constructed from a chopped up 5 button + wheel usb-mouse, and a 4066 analog switch. Circuit diagram on request.