Computers are complex systems but it’s a mistake to assume they need to be complex to use. However, usability is not as easy as it may first seem. It is a different discipline from software development lacking the strict logic or having a “right way”. There are only differing requirements and differing collections of guidelines. Making things easy is difficult.
I’ve used a number of operating systems over the years and it’s obvious that some systems get usability right more than others. It’s also obvious that you need usability people on your team if you want to get it right, I’ve never seen a programmer driven OS (volunteer or paid) produce usability to the same level as companies with usability people.
Usability is paradoxically, not an easy subject. It doesn’t have the mathematical background of computing, so there is no one correct or incorrect way to do it. It strikes me as something between art and science, about putting the right things in the right place, not over complicating things, simplifying where necessary and moving more complex or less used options out of the casual users way.
The people developing a system often have very different requirements and preferences from those who will be using it. Developers are a different kind of people from normal users, they like technical stuff, they like to be in control and have many as many configuration options as possible to allow optimisation, they will often have very good memories for detail.
Users tend to be be pretty much the complete opposite of this, but that is not to say they are any less intelligent, that “user” may be performing brain surgery on you one day. However due to these differences software developers do not generally make good usability people, they can make software usable for themselves but that may mean it’s completely unusable for casual users.
“Programmers do their work but once, while users are saddled with it ever thereafter.” – Jef Raskin
There is no “perfect” usability as not everyone works the same way. Trying to force a method of working on users is likely to backfire. Witness the outcry some users made about Gnome when they switched to a spatial nautilus. A spatial browser does not work well with a deep file system hierarchy, unfortunately many users have exactly that and consequently had problems with the system.
All users -even developers- get used to ways of operating, even if something new is better, the fact they are used to the old way means there will always be resistance to change, a chunk of the complaints about the recent changes in Gnome will be for this reason and this reason alone.
Of course the advantage of creating a new platform is that there are no existing users to complain when things change. Of course this means migrating users from another platform will have difficulties but this is only the case if that’s what you want to do, what is the point of building a new platform to do the same as all the others?
More or less options
One approach to usability is to simplifying everything by removing options, this strategy assumes users are idiots and in my opinion is more likely to annoy users due to lack of options than help usability. Just because someone doesn’t know about the inner workings of an computer does not mean they are an idiot. Usability is not about “dumbing down”.
Removing options or flexibility for the sake of it may make things easier to use, but it also makes for an inferior product. On the other hand adding too many options is only likely to confuse users.
Gnome and KDE respectively are taking these approaches, the end result being Gnome is annoying some advanced users (to the point that the spin off project GoneME has started) while KDE is confusing for casual users (or at least the control panel is).
OS X has plenty of options but they are not thrown at you all at once, many are hidden behind “advanced options” buttons and such like, it manages to be both powerful and easy to use. Different companies and projects have been copying the Mac for years simply because it looks so good, nobody seems to have ever matched it’s usability though.
Sometimes adding complexity actually helps usability. Try editing a sound on a early 90’s synthesiser, then try the same on a 70’s synth. The 90’s synths used a minimalist approach with only a few buttons to navigate a wide variety of different controls, consequently they were a compete pain to use. The 70’s machines put all the controls on the front panel and allow direct access. Initially these were frighteningly complex just to look at but once learned were very easy to operate. Today modern “virtual” synthesisers have gone back to allowing the same 70’s method of operation.
Human Interface Guidelines
There have been many human interface guidelines published over the years and there are numerous basic rules and guidelines (i.e. keep things consistent).
However, as I said there is no one “right way” and as if to back up this even the user interface experts don’t agree with each other, you don’t need to read much to see the term “the experts are wrong”.
I briefly discuss some specific Human interface ideas here but there is much more out there though and I have included a number of links for further reading at the end. There’s also links to the “User Interface Hall of Shame” which has numerous examples of how not to do interfaces. There is also a “Hall of Fame” but it is notably smaller.
ROS Guidelines
The ROS (Ruby Operating System) [ROS] has an ultra minimalist approach to usability guidelines, there’s only 4 of them. They say a user interface should be:
- Easy to learn
- Efficient
- Easy to remember
- Satisfying and pleasing
Despite the abject lack of details it’s remarkably easy to find applications or systems which break one or more of those rules.
The Proximal Interface
One of the most advanced yet seemingly little used concepts in usability design is that of the Proximal interface [Proximal]. The idea is to build an interface which in effect becomes invisible, the user just gets on with their job and the interface is there to facilitate that.
The idea of direct manipulation is used so rather that selecting an object then picking an option from a menu, you can do some operations directly by grabbing or moving the object, the options can be increased by holding a modifier key. Drag and Drop is a perfect example of direct manipulation.
The proximal interface of course includes a number of principles to use when designing user interfaces, these include:
- The principle of graded effort – the most common or most important options should be very easy and direct.
- Distinguish what object the mouse is over and where exactly it is clicked to allow different direct operations.
- The principle of the left hand – Use the left hand to qualify operations (i.e. Left-shift & click).
- Treat a mouse operation as a process, i.e. other operations can happen during the process.
- The principle of visual cues – we remember where we put things, the system should not reorganise them without good reason.
- The irreversibility principle – destroying data (i.e. deleting) should take more effort than creating it.
I think it’ll be a long time before we’ll see mainstream systems based on these principles though some applications already seem to follow similar principles (e.g. the vector graphics component of Gobe Productive on BeOS). BeOS itself had drag and drop extensively throughout the system.
Interface Arrangement – Fitts’ Law
Usability goes beyond the capabilities and arrangement of software. It also applies to the layout of controls on screen, Fitts’ law is an often quoted law of interface layout design [Fitts] but originally had nothing to do with computers.
Developed in 1954, Fitts’ law applies to random selections of targets in 1 dimension using the human arm, It defines a relationship between size of target, distance to target and speed of acquiring the target.
Computer interaction is really quite different from this, it’s in 2 dimensions, common movements are not random and there’s mouse acceleration. It’s a wonder how anyone came to apply Fitts’ law to computers.
Some use Fitts’ law it to justify placing menus at the top of a screen as opposed to directly on windows, the rationale is that even though the menu is further away it has effectively “infinite” size since it is at the top of the screen. It may be infinitely high but the menu item is not infinitely wide, the actual aim point is no bigger on the edge of a screen than it is on a window. Fitts’ law would suggest that the menu should really be on the window as your mouse is likely to be closer to it (this assumes Fitts’ law applies in 2 dimensions).
This also does not take account of mouse acceleration which makes aiming at a specific point on the edge of a screen almost impossible from any significant distance (apart from the corners where your pointer invariably end up). Yet despite this, placing the menu at the top does seem to be better, how can this be so?
I can only conclude there are other factors at play:
- Muscle memory will have an impact since the menus are in the same location for every program.
- The mouse acceleration means you can get the pointer to the top of the screen very rapidly.
- Once the mouse gets to the top aiming is only horizontal, controlling a mouse in one dimension is easier then controlling it in two.
Getting to the top of the screen is a flick of the wrist, this only gets you to the rough area. Once you are in the rough area getting to the specific menu is then very quick. It’s a two stage process and Fitts’ law applies does indeed apply to both, individually.
If the menu is not at the top aiming has to be in 2 dimensions and this is more difficult. Try drawing an exact circle quickly, this is very difficult. Try drawing a circle quickly with a mouse, it’s even harder and acceleration only accentuates the errors. Aiming a mouse is difficult enough in two dimensions but acceleration means you’re likely to overshoot, making aiming even harder.
This does not mean putting menus or controls on windows is somehow unusable (you can click on a web link can’t you?), but if you have high mouse acceleration it does make getting to them can be slower than points on the edge of the screen.
However, it’s still not that simple, it may well be the case that with low mouse speed / acceleration it is better to have the menus on the window – try moving menus around and changing mouse speed, at a low mouse speed moving around the entire screen is quite a chore.
I don’t believe Fitts’ law it is the be-all and end-all some seem to describe it as but it is a useful guideline none the less, though the differences between the original law and modern computer interfaces need to be taken into account, as do individual user preferences.
Usability Everywhere
Usability is not just about the GUI, it should apply to everything, even the command line. English (or other natural language) commands have been around since MS-DOS and probably even before that. IBM have had a slightly cryptic but very easy to use shell for decades. However the concept of usability appears to have completely passed by the common Unix shells where bizarre acronyms abound making them all but impenetrable to the casual user. What exactly does “Grep” mean?
Command lines are very useful tools and they are in many cases better suited to tasks which would be difficult to represent well in GUIs. However, there is no reason they should be so complex as to require a reference book to use them, they should be available to all users, experience on other platforms has shown this can be the case with a well designed naming scheme.
In our new platform I’d like to see a shell with the power of bash but with commands such as “list”, “remove”, “search” etc. There’d also be an extensive help system for using the commands. The system should boot with a GUI as standard so this should be used to enhance the console, displaying options, help etc. Unix users may scoff at the idea of a system booting with a GUI by default but many different desktop systems have been doing this for a very long time with no ill effects. Just because X can be flakey does not mean other graphics systems are the same.
Another thing Unix geeks are not going to like is the removal of case sensitivity [Case], it is yet another hangover from the past, serves no useful purpose and is a potential source of confusion, so why have it? Google and other search engines are by default case insensitive, they’d be a pain to use if they were not. I would however keep keep case preservation.
A sensible naming scheme should also apply to the file system structure, it could be organised beginning along the lines of:
- /System – OS files
- /Applications – 3rd party applications and libraries
- /Home – All user files in here
The user and system files are separated to simplify backing-up, to backup or move your files you just copy “/Users/My Name” to the desired destination (something else I’d fix is the ability to use spaces in file names).
When a user downloads an application it and it’s libraries should be automatically moved to the relevant applications area, this should be indicated to the user along with the application’s global settings (i.e. type of app, who can use it etc.) so they can be changed.
Program Installation
Installing software should be a quick, painless operation, the installer should not assume the user has an internet connection. If the application requires libraries which are not included in the system they should be supplied with the install medium, be that CD, DVD, zip or binary. Under no circumstances should the system (and especially not the user) have to go looking for additional files or “dependancies”, it may be OK if you are supplying software to geeks who like to roll their own but not if you also intend to target casual users.
Users and programs should be forbidden from changing system components. Changing components leads to problems like “DLL hell” where a program installed system library can cause program or even system failures. Malicious programs can also get in and change Libraries causing problems. By preventing users and programs from changing OS components any program which is installed can expect a specific environment in which to run and can test against. As indicated in the previous part of this series even if something could change a system component the system would automatically replace it.
Of course DLL hell can still happen when 3rd party libraries are involved. This could be avoided by allowing multiple library files with same name but different version. If one program wants version X they get version X, at the same time a different program asking for version Y can get Y – without conflicts (Microsoft .net can do this). Additionally the system should search for libraries in case they are in the wrong place.
Useable Development
Usability should even apply to development. Computer programming should not be a black art only practised by those in the know.
Many of the different platforms available in the 1970s / 80s had a version of BASIC supplied with them and many programmers started on them, unfortunately this is an example of a good idea which has been discarded. I would do the same and include a language for users along with examples and instructions to help them get started.
This would be the “default” language which could be used for everything from just playing around, shell & application scripting as well as full applications. The default language would not preclude the use of other languages of course but having a standard language would encourage development and if it’s an easy enough language may even encourage non-programmers to try it out. I would most likely use Python for the default language as it has the specific aim of ease of programming and can be used for all the purposes I mentioned.
There is no logic in having different languages in different parts of the system unless there is a pressing need for them, there would be no other shell scripting language supplied for instance. Being able to program multiple parts of the system with a single, easy to use language will in my opinion, be highly beneficial. Again this is only by default, it would still allow other languages to be installed and used.
There would of course also have a default “performance” language such as C++ or Objective-C for normal developers in which I expect the majority of applications would be developed. I’d also like to see a good implementation of Java but I’d like to see it’s rich class library be made available to the rest of the system.
Conclusion
Today usability is an important part of any system but it is far from perfect and hasn’t even reached some areas. A new platform would give us the ability to spread usability into every area making the computer truly a tool for everyone, but not a tool which will can be sabotaged easily or accidentally.
It’s easy to believe all the computer can do is what it can do today, but each new platform brings with it new possibilities and new applications. In the next part we go into how you would actually use a new system and the new flexible GUI I’d include.
Something missing?
This series is not meant to be a definitive description of the state of the art in any given field, I don’t know everything and don’t pretend to. If you know of technologies I’ve not mentioned that would be appropriate feel free to them in the comments.
References / Further Reading
[ROS] Ruby OS Interface Guidelines [Proximal] The Proximal Interface [Fitts] Fitts’ law [Case] Case Sensitivity [HI Resources]Gnome HIG
Apple HIG
Cornell University HIG
Summary of The Humane Interface
Nielsen Norman Group HIG
User Interface Hall of Shame
User Interface Hall of Fame
Previous parts of this series
Part 1: Hardware
Part 2: The OS
Part 3: Security and Files
© Nicholas Blachford July 2004
About the Author:
Nicholas Blachford is a 33 year old British ex-pat, who lives in Paris but doesn’t speak French (yet). He is interested in various geeky subjects (Hardware, Software, Photography) and all sorts of other things especially involving advanced technologies. He is not currently working.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
http://www.joelonsoftware.com/printerFriendly/uibook/chapters/fog00…
Are you sure you commented on the correct article?
Yeah, that all seems to be nice to solve DLL. Keep different versions of the file for applications which use it. The problem with it is that it kind of makes having shared libraries pointless. I mean with the exception of core system libraries, each application might as well just keep its own copy of the stuff. If it was built using V 1.0 of some DLL in mind, how is it going to know that V 2.0 will break it? It can’t. So unless the user goes and updates the software to get an update of the software, which in turn changes the software to restrict the use to V 1.0, it might as well have just kept its own local copy of the DLL.
I wonder if that reads correctly?
One idea which could fix this is to have the system maintain a repository of all shared DLLs. When application X requests a DLL, the system checks which DLL it should give to application X. This mapping could be updated online, or by the user. This would be complex as of course how is the user going to know which DLL is good and bad for the application. Unless its done in a nice way like everytime a DLL is updated, the ‘state’ of each applications DLL mappings is saved. So if you suspect a DLL problem, you can easily revert to the known good copy.
Lastly, its possible this was done in a previous part. But what about more ‘agents’. I mean we are talking a next gen OS. I want an agent that learns that when my pc boots in the morning, and I launch firefox, i’m checking OSnews
It should help me out on that. We need mo clippy. Maybe just little suggestion boxes on what it thinks you want to do and doens’t actually take action….yet
Ideally, computers should be something we can talk to (like star treck), to be truly usefull, you down’t need to know or care about what’s in that black box anymore than what’s under the cars hood. OS’s and user interfaces should be invisible, the whole reason for complexity is that computers are still primitive and we have to support the likes of MS. I doesn’t help that MS has made a lot of money selling OS’s and software that is complex and changes needlessly all the time…the only people served by such methods are MS and the billions of companies/individuals that help out the computer clueless.. a truly smart PC would eliminate this forever (or reduce it a lot), but where would all those surplus prgrammers/consultants go then?? The current situation is simply bad for the user and we all pay for it by having these primitive systems that change every 2 seconds for no good reason other than greed.
“In our new platform I’d like to see a shell with the power of bash but with commands such as “list”, “remove”, “search” etc.”
man alias
An interesting article. He doesn’t like combo-boxes, and neither do I. Another of my pet hates in MS ‘UI innovations’ are spin boxes – they’re just a really dumb way to have to enter a number.
I personally don’t find it much easier to whip the cursor up to the top of the screen with mouse on a Mac, compared with the KDE’s menu per app window approach that I normally use, but perhaps I have better mouse coordination than the average user. Mac screens have got bigger and so you would need to use more mouse acceleration than you used to, which might make the mouse feel ‘over geared’ for other uses.
I liked the menu system on NeXTStep best – by default the menu for the current app was at the top left corner of the screen, and the menu items were underneath each other, not left to right horizontally. I don’t know if there are any usability ‘laws’, but I find it easier to drag down through a menu than drag across.
You could more the menu to anywhere you like and it would stay there for that specific app. Or you could configure the menu position globally for all apps. Also you could right click on the two button mouse, and the menu for the current app would appear at the mouse position. Submenus could also be torn off and positioned anywhere on the screen.
was that there is no one right way to do a user interace. Yet The author ignores hiw own invective when talking about the user/developer user interface distinction.
Users and developers do want differnt things out of a user interface unfortunatly they both want convenience and ease. A comprimise UI, especially one that hides options in advanced configs, will inevitably comprimimise the power, or ease of use of one of the two classes of users.
Hidding advanced options from the basic user inevitably makes them less convenient for the power user. Trying to design a consistant UI for two modes (basic and advanced) will necesarilly not be optimal for either. Some advanced features, like being able to control most programs through a text window, need to be built in everywhere if they are to exist at all (try for instance reconfiguring microsoft word from the dos prompt).
Most importantly I think these attempte to design a system that works for both the power user and the neophyte overlook a *very* important fact. What matters to most ‘power users’ is *feeling* like they are control not just being in control. It is the feeling of mastering an arcane and powerfull command set which they enjoy in essence they enjoy exactly what the users dislike. How else do you explain the many souls who still pinned for DOS after various versions of windows arrived. Windows offered strictly more power than DOS (all sorts of protected mode options to use on programs etc..) but many people still prefered DOS just because of the way it felt.
As a consequence we should quit wasting our effort building unified user interfaces. Linux development (I single out linux because it is the only open source OS making a significant play at the everyday joe user) should make one simple ‘user’ desktop interface and one ‘power user’ desktop. Besides this notion of progressing to the power desktop would grab at alot of people.
First and foremost I don’t agree programmers and usability don’t mix. Actually it’s what separates a good programmer from a sloppy one in my opinion. I’m sure if you let some programmer code an application and the interface is nice and clean, the source code is very well structured too. As you mentioned in the article, making a usable interface is an art, but software design is an art too, like architecture. Anyway this is my personal view. I enjoy designing software more than actually coding it.
Next, usability covers two things in my opinion. The first thing is when you first start an application you should be able to directly find your way arround. In other words, the interface should be intuitive, easy, clean, consistent, etc. This is what is traditionally thought of when talking about usability and this is what commercial software is usually better at, because they have the usability teams as you mentioned.
The other aspect of usability is allowing the user to learn new things, allowing him to manipulate more and more, in theory until he reaches the source code level. This is what free software is better at, because it’s against commercial interest to open up a document format or use a human readable format for example.
I think both aspects are equally important to allow people to learn using computers.
Then about the cli, if there’s one thing that needs polishing in the unix shell it’s the way to pass arguments. Some want one dash, others two, some use whole words, others just one letter, some put the input files first then output, others the other way arround, some use “-R” for recursion, others “-r”. It’s stuff like this that got the cli its geek-only reputation.
There is no such thing as a ‘power user’. I consider myself very experienced in computers, I’m a developer and I often use the command line. This would probably put me in the “Power User” category.
Does this imply that I must have 200 options to control every possible aspect of my music player, when all I want is for it to play some songs while coding. The “Power Users” category doesn’t exist! If I was forced to configure everything down to the last pixel, then I wouldn’t get much productivity done on the computer, and I could just as well been watching TV, or doing something other.
I believe that many so called “Power Users” agree with me. But of course there will always be people who don’t.
Just my thoughts…
I bought a Mac recently and find that the best thing about the menu bar location at the screen top is that:
– With multiple apps or windows, there is only one menubar visible at a time, and this reduces the strain on my eyes trying to find the top of the current window.
– My eyes now automatically zero in on the same menu bar position for all apps/windows. This has become automatic and saves me time.
The mouse movement itself takes about the same time for both menu bar locations The real benefit is on the eyes and the brain. We are creatures of habit. The user interface needs to be predictable above all.
Artificial Intelligence could learn from users habits and simplify their life. Use of AI would improve a lot the whole Human-Computer interaction. I, the user, should never have to do something I can trust the computer to do. Take for example installing the apps… why should I bother downloading, configuring, compiling an application? Why should I even manage the updating if I don’t wanna? If I trust the providers of my App all this should happen when I sleep. What I’m talking about is not an utopia thing, it is already implemented:
http://zero-install.sourceforge.net
too bad that is seldom used.
A very nice article. Could you probably put in links to the other three articles at the end of the first three articles, so one can easily find the whole series after discovering one article in google?
I wrote a rather lengthy explination on why the menu-at-the-top (like mac) is more efficient. It includes some handy screenshots and good explinations.
http://otierney.net/comment.php?newsId=30
Ive used just about every type of user interface I can think of, Win. Mac, Unix, Palm, BeOS.. even afew expermental ones.. The best ones are Panther, BeOS, and Gnome. Overall I think like the new versions of Gnome the best. It isent the “most usable” however it provides good usability and more control than the rest.
WindowLab is kinda a neat idea too.. but I havent used it too much.
“I’ve never seen a programmer driven OS (volunteer or paid) produce usability to the same level as companies with usability people.”
While this may be true, and many of the principles laid down in the article may be useful, this is only one small aspect of usability…The author has basically summarized many broad discoveries that “usability people” have made over the years, but software and OS usability requires constant testing of interfaces in order to achieve better usability for everything from the choice of labels used in menus to appropriate amount of configurability. Usability is a moving target that requires more effort than simply taking accepted standards at face value and calling it a day.
In a response to my post someone else claimed that there is no such thing as a power user. To a great extent this person is right, but not because there aren’t real differences in UI preferences but because the term is a misnomer. The reason I put quotes on the term in my original post is because having the ‘power user’ UI preferences has nothing to do with actually being a power user.
Really the difference in UI preference is just an asthetic one. Unfortunatly, since it is *often* (though not always) computer geeks who prefer the arcane powerfull interfaces it has been saddled with the term power user. This labeling causes all kinds of problems as UI preferences get very caught up with issues of pride and ability.
While there might be a correlation there certainly is no necessery relationship between the UI preferences and the ability of the computer user. Equally good programs differ on whether they prefer a nice clean gui IDE or the arcane lisp macros of EMACS. While at the same time plenty of know-nothing kids (like myself in the distant past) preferred DOS to windows.
At the end it is simply an asthetic disagreement. It is much like the issue of whether chinese should be represented in a phonetic alphabet or it’s traditional pictorial form. You can list reasons forever why the phonetic form is more usefull but it won’t deny the fact that the pictorial form might have more tradition/beauty. There isn’t any need to develop some hybrid in-between language nor convert the admirers of one to the other. I just want people to recognize the same thing in GUI design (the distinction I mention is probably only one of many UI preferences…it just seems the most obvious)
Also, in line with my other comments I think it is inappropriate to critisize opensource software for being ‘less useable’ or similar. The fact of the matter is that they are developing software for a differnt market so it shouldn’t be surprising they end up with differnt solutions.
Does anyone here really believe that linux would be just as succesfull with the geek/nerd crowd if it was super simple to use. Like it or not many people take pleasure in mastering a difficult interface for even a minor or hypothetical increase in power. Once we realize that the ‘power user’ is more about the interface asthetics than actual power hopefully it will become clear that opensource software doesn’t represent a more powerfull system just waiting for a good user interface. Rather it is charachterized by delibrate design choices to cater to the asthetic sensibilites of the ‘power user’ (though not perfectly…..and of course there are some attempts to make it usefull for the average joe as well)
While the article as a whole is pretty good it’s sad that it continues the unfortunate tradition of usability related articles to claim the myth of developers being a different kind of people as some kind of truth.
Nothing could actually be farther from truth if people actually take a look at the actual situation. And the actual situation is that while developers can be biased regarding the software they develop, they still use the overly majority of software as users just like any other user. Additionally even the distinction between ‘pro’ and ‘newbie’ is an artifical one since in today’s world of an ever increasing mass of information and an ever increasing rise of complexity people, both ‘casual’ users and ‘developers’ have areas which they have good knowledge of, are able to easily handle etc. and other areas where the exact opposite is the case.
For me true usability eventually boils down to a working communication between developers and users: the developer has to communicate well the purposes of his apps, and the users have to give good feedback on how they’d expect those purposes to be handled interface wise.
And as an addendum for the list of links, KDE has a user inferface guideline as well at http://developer.kde.org/documentation/standards/kde/style/basics/
Has anyone heard of Gobolinux? It (successfully) makes linux work in an intuitive file heiriarchy – /System /Programs /Users (I think, don’t know the specifics at this time). Also, programs go under /Programs/foo/1.2/ so different versions are kept isolated (then simlinked in to a common directory). Check it out at http://gobolinux.org/
I take an interest in usability, and so I read this article. I like it up to “Usability Everywhere” (especially the comment about there not being one right way is good – although the suggestion that there is one right way in software development is a bit misguided).
I don’t know where the author gets his belief from that DOS has natural language commands but UNIX does not. As far as I can see, DOS commands are similar to and often identical: mkdir, cd, rmdir, echo, and pipes are all the same; rm/del, ls/dir, cp/copy are different, but it’s debatable which language is more intuitive. At any rate, you can easily get make_directory, remove_directory, etc. under either system, but in the end it will only cost you more typing.
The real differences in the command line as provided by DOS and typical UNIX environments all fall out in favor of UNIX: command and filename completion, history, manpages, apropos, which, locate, … All these could be installed on a DOS system, but (apart from the GNU/FreeDOS system I once built) I’ve never seen any DOS or Windows system that had them.
After the command-line bloob, the author continues about how libraries should be distributed with software and have working versioning. I think distributing (non-standard) libraries with software is a good idea for software that is distributed on CD or some other medium that can conceivably be used by people without other access to the libraries. If you are distributing the software off your website, you can just make the libraries available from there too. As for versioning, UNIX-like systems that I have seen all have it worked out: simply appending the version number to the name ensures that the app gets a version compatible with the one it was linked against, and allows different versions to coexist peacefully. DLL-hell seems to be pretty much a Windows-specific problem, possibly rooted in the fact that Windows hasn’t always properly supported long filenames.
Software installation is indeed a bitch if done the traditional UNIX way. The solution is simple: do what everyone else does and install your package in its own directory. Make some symlinks from standard locations to files in your package directory, and done. Then again, software installation works a lot better on the UNIX-like systems that I have used (especially Debian) than on some supposedly more usable systems.
I completely agree with the author that having a programming language with your system is a Good Thing, and, in fact, most UNIX systems ship with one. However, I think there is no good reason why there should be separate languages for shell and programming (See http://inglorion.net/documents/essays/shellprogramming/ for an unfinished article on the topic). The only systems I have ever seen that had this right are LISP machines, but any system based on a language that is fast enough for programs and easy enough for shell commands (a lot of popular languages fail the latter requirement) would do. I am curious what .NET/Longhorn will be like.
we go the star trek way? touchscreens and so on rather then the old fashion mouse? that way we see button, press button, something happens.
then there is allso what functions to hide and what functions to show. this is a real problem as some people may want that function readily available but others find it useless. problems is that while they can customize their own computers interface, when the move to someone elses they will find it totaly unfamiliar.
hmm, i would if we should make personal computers realy personal. as in body computers. the main body, the one with wifi connector, bluetooth for input and output devices, storage and the cpu itself should be about the size of a overgrown ipod:) then you have some sort of input device (maybe some sort of gesture glove or similar) and a output device (a small hud device consealed as a set of sunglasses or near sunglasses maybe). then there have to be a way for the bodycomps to exchange data over wifi (and by extension the net) so that one can cooperate and find nearby devices for use, the apple system should be nice here. need to print? move into range of a printer. need to show someone else what your working on. tell the person to have his bodycomp go into a kind of display mode so that what you do on your bc is mirrored on the display of his bc.
point is to make the computer truly personal. problem tho is battery life
As they saying goes, there are statistics, statistics and dammed lies.
Is that how the saying goes?
“There are three kinds of lies: lies, damn lies, and statistics.”
While I agree that having a unified script language in the OS is good, I think that there is a problem: Python or Ruby interpreters are not good ‘shell language’: ls | wc -l doesn’t mean anything in python or ruby interpreters.
And the various shells (sh, ksh, bash..) are not good script language.. But we need both!
So with the ‘unified script’ language design comes a constraint: having an interpretor of this language which is as usable as current shell, something which is difficult to do, as it does not exist currently (as far as I know).
One approach to usability is to simplifying everything by removing options, this strategy assumes users are idiots and in my opinion is more likely to annoy users due to lack of options than help usability. Just because someone doesn’t know about the inner workings of an computer does not mean they are an idiot.
It seems like the author has a chip on his shoulder about this. Why does it “assume users are idiots”? A good interface balances a healthy level of control with some smart simplifications. Only 5% of what your computer can do is used by 95% of users, while only 5% of users use any of the other 95%. So a good interface designer will make the most-often-used 5% jump to the foreground, leaving the remaining 95% accessable through the more arcane recessesses of the interface, or maybe only accessable through command-line, special utilities, or 3rd party apps.
Simplification is not the enemy. Stupidly simplified or over-simplified interfaces will meet with frustration, but accomplishing simple tasks should be simple.
You said that you want to have a case insensitive (but case preserving) command line, (same as MacOS).
Just keep in mind that it is something complex to do, as case management is complex to do in a multi-language set up: do you consider that é and E are also the same thing?
No, it isn’t such a stupid question to ask as if I’m not mistaking in some language the uppercase variant of é is E and some other the uppercase variant of é is É.
I believe that case management depends on the language used, so this gives the problem: how the OS knows the language used for naming the files? Does it depend on the localisation?
If yes, then you may have some script which fails depending on the user localisation!
‘case insentiveness’ must be possible as MacOS has done it, but it is *not* simple!
@Yamin, I wouldn’t go as far as to say that allowing side-by-side sharing of dlls invalidates the usefulness of shared libraries. I do however see your point especially dependancies on large libraries. Maybe the real problem is bulky libraries. So what I’m saying is that say for example libary such as GTK was broken up into 100 different seperate library files. Now when one library file was updated it would only cause applications that depend on that specific library to adjust. So if that file was only used directly by other GTK libraries, it wouldn’t require any external applications to be updated.
Another solution off the top of my head would be to provide version compatability information with libraries. So with each new version of a library released it could include information about the oldest version that it maintains compatablity with. This way as long as applications are in a specified compatability range they can all use the same library. This method of using version compatability range could even be more useful if applied directly to methods, functions, classes or other constructs within a library. This way applications which only make use of classes within a library that have maintained version compatability could still use an updated library which contains some compatability breaking features. These such version compatabilities and dependencies should all be maintained by the system or package manager so that as soon as a library is going to be updated dependencies are checked to see if it breaks any compatablity with existing apps. If so two things can occur, either the new copy of the library is installed side-by-side with the old one or the user can be prompted to update the dependant applcation.
In a sense, with object oriented libraries it seems that seperating each class into a seperate file with it’s own versioning information would work out the best. However maybe there is a performance hit when you have to load seperate files for each class thats used.
Dude, you’ve perfectly described AmigaOS. You don’t know what you’re missing.
This is a great step – people in the computing field (outside of Apple and Amiga fans) talking about usability. Back in the day, usability meant having a green screen and a keyboard that works. Now it means something that’s easy to use for non-domain experts.
Realistically speaking, there are two user types: domain experts and non-domain experts. Domain experts = people that require high-density information and quick access to commands/features. Non-experts = low density information, easy to find information.
The conflict is pretty obvious, but resolving it isn’t. With a domain expert interface, the user can see massive amounts of information, lowering the cognitive load. But that comes with a front-loaded cost: becoming an expert, usually with lots of training. With a novice interface, lower-skilled and trained people can use it, but possibly with less speed/skill/reaction time.
The challenge of UI design is to figure out which users are the primary ones and write to them. Good designers can also provide an interface easy enough for non-domain experts but accepted by domain experts, something that’s happened in airplane cockpits over the years.
One great example of a failure of the above would be the BMW iDrive system, which substituted a novice (though cluttered) interface with a domain-expert (and massively simplified) interface. BMW took a cluttererd visual field and reduced it, but in doing so put more cognitive load on the driver.
They could have used touchscreens instead, but didn’t (presumably for cost reasons). It’d be pretty interesting to read the iDrive story, as somewhere along the line there was a failure to communicate.
Anyway…
Realistically speaking, there are two user types: domain experts and non-domain experts.
Often lazyly reffered to as “power users” and “newbies”, which is problematic because:
1.) There is no such thing as a “power user”
2.) No one wants to admit being a newbie
Since we’re having such a wide open discussion of computer use paradigms, I was wondering whether anyone following Nicholas Blachford’s series and this thread have opinions about the eventual “every day use” suitability of highly factored, late bound, behavior-defined object oriented language+operating system virtual machine entities such as Squeak (www.squeak.org) and its emerging distributed visualization extension, Croquet (www.opencroquet.org)?
(This is, once the Squeak VM were made more thread safe than it is now).
It seems to me that many of Nicholas’ hardware and exokernel ideas might well suit the viability and scalability of such rich environments, where users are empowered to be spontaneously creative in the ways they can extend the functionality of their applications and even the operating system under it (which is creatively factored into hotswappable parts).
— Ed
A “power user” may use features a “normal” user doesnt, but that doesnt mean anything from a design point of view.
The goal of a well designed interface is to make simple things thoughtless, difficult things easy, and impossible things possible. The first is actually the hardest, believe it or not, and something that applications designed for “power users” totally miss out on.
for example, a “power user” will have fifty 8×8 icons on his browser toolbar, while a newbie has 5 16×16 icons. fitts law tells us that the time to acquire a target is a function of the distance to the target, and its size. so that means it takes the newbie significantly (and consistantly) less time to hit those five buttons, then it takes the “power user” what the “power user” gains from not having to navigate through the menus for something like “new window” is more then lost by consistantly taking longer to hit the 8×8 icon for “Back”. (note that this has nothing to do with agility with the mouse, its a relative thing)
this is just an example of how catering to a power user decreases overall efficiency. how much do you think when you turn on a light, or open a door? these interfaces require no concious thought to operate, showing that they are very well designed. now, imagine mirroring such kinds of interfaces in the computer world, would that not be beneficial to everyone, including our power user?
a few points.
rarely used features should be in menus and submenus only, there is no reason for them to be on toolbars.
applications should run fine out of the box. a casual user should _never_ have to go hunting for a configuration dialogue. this is accomplished through intelligent defaults.
config panels should be *simple*. if the defaults are sane, then the user will only go hunting for a preference every once in awhile, so options need to be easy to find without all kinds of crud that only five people in the world will ever user. a great example of this is firefox. Tools->Options gives you a very clean and well orginized config panel that does *not* implement everything from about:config.
and the most important of all, consistancy everywhere you possibly can put it. even if your application works different from every other app ever made, at least make sure it works in a similar manner accross the board. an experienced mac user can go onto a mac and is instantly familiar with every application installed. that is solely cause of the apple human interface guidelines being both mature and widly accepted. every app looks, acts, and is operated using the same principles. in such an environment, learning time goes down dramatically.
What is uppercase? What is lowercase?
Well. that would depend on your language!
George makes files Foo and FOO, since the O is
not an uppercase o in his language. Then Mary
comes along and tries to edit Foo. In doing so,
she destroys FOO. (her editor writes to a temp
file, then renames it — this avoids having a
half-written file in case of a crash)
Now consider simply looking up these files.
You can’t hash the filenames or put them in
a tree, because filename order and equality
will vary by language. All searches are linear.
BTW, many shells offer case-insensitive filename
completion. This works, because the shell only
has to serve one user at a time, and thus only
needs to handle one language at a time.
Also, spaces sure do work in filenames. They’re
evil, but they work. Use quotes or the backslash.
“Fitts’ law would suggest that the menu should really be on the window as your mouse is likely to be closer to it (this assumes Fitts’ law applies in 2 dimensions).
This also does not take account of mouse acceleration which makes aiming at a specific point on the edge of a screen almost impossible from any significant distance (apart from the corners where your pointer invariably end up). Yet despite this, placing the menu at the top does seem to be better, how can this be so?”
the distance to the object is infinate in one direction on the screen edge. move your mouse in that direction and you will alwas hit it. that limits aiming to two directions, instead of four on a “window menu”. to aim you have to slow down mouse acceleration, which means aiming is something to be reduced or made easier wherever possible. now, if a target is of an infinate size, mouse acceleration is irrelivent. unfortunately, that only applies to the pixel under the mouse, which makes contextual menus pure genius. however, infinate in one or two directions makes acceleration irrelivent in those directions, so the effect you get is slightly less then a contextual menu, you still have to aim but you have reduced the effort required by half.
the reason people dont use the menu at the top of the screen is the same that gnome doesnt use spring loaded folders. apple has a patent on it.
http://webcast.berkeley.edu/courses/replay.php?prog=40&group=57&dat…
http://webcast.berkeley.edu/courses/replay.php?prog=40&group=57&dat…
It’s interesting that a long time ago, we succeeded in making “usable power”, but at a certain point in time, we decided that power is unusable, so we will hide or remove it by making programming artificially more difficult.
<BLOCKQUOTE>
A “power user” may use features a “normal” user doesnt, but that doesnt mean anything from a design point of view.
</BLOCKQUOTE>
This has been a constant refrain from many developers but I simply don’t think it is consistant with the rest of your positions. After you make this claim you go ahead and insist that a user interface should be designed in a way guaranteed to screw over a domain-expert (I really liked the post suggesting this term rather than power user…much better description).
<BLOCKQUOTE>
rarely used features should be in menus and submenus only, there is no reason for them to be on toolbars.
</BLOCKQUOTE>
<BLOCKQUOTE>
config panels should be *simple*. if the defaults are sane, then the user will only go hunting for a preference every once in awhile, so options need to be easy to find without all kinds of crud that only five people in the world will ever user. a great example of this is firefox. Tools->Options gives you a very clean and well orginized config panel that does *not* implement everything from about:config.
</BLOCKQUOTE>
The point isn’t that complicated. If you design your system to only present the common options then the advanced options will be difficult to access. This principle will also guarantee things like error messages and primary help/information screens are sparse on uncommonly used technical information. Domain experts would have to use tons of more motions (going through the advanced menu or similar) to get the same work done.
Someone will suggest we can fix this problem by options for domain-experts. However, a UI which you need to go around and set 100s if not 1000s of settings to use is hardly a good interface. The mistake here is too assume that the domain-experts don’t want things to work the way they like the first time and don’t care about efficency in their operations. Quite simply either the first level of interface (say the options out of the file, edit etc.. menu which show up) presents a huge wealth of complicated options or it doesn’t. One user prefers one style and the other prefers the other.
Perhaps you will suggest that a few global options could switch between the domain-expert and the non-domain expert. However, I hardly see how this would work. Differnt design choices are necesscitated when giving the user a few simple options or many complex options (to give a highly simplified example one wouldn’t use a pull down list for 100s of options…when one wants thousands of options (picked at once not through sub menus) you better use keyboard input).
Any reasonable attempt to make a domain-expert mode and a non domain-expert mode is going to *really* produce two seperate UIs. One simply can’t hope to maintain consistancy in interface across such a fundamental differnt way of interacting with the computer. It would end up something like having a command line and a GUI way to do things (by the way I really like this double development model and think it needs to be preserved into the gnome days even if CLI isn’t the domain expert alternative).
Perhaps this position would be less contentious if we talked about it in terms of graphics programs. Clearly some graphics users want thousands of options immediatly availible and you wouldn’t want to give microsoft paint this interface or the other program microsoft paints interface. Now of course the domain-experts in graphics are differnt than those in operating systems but if you believe they exist in graphics why not in operating systems.
(On second thought domain-experts might not be that much better a term. It still implies a difference in skill/knowledge not a difference in asthetics)
In Dutch you have the letter IJ which some consider one letter and than should be put with the y and some consider to be made of of I and J and than you should start with i.(most consider it i&j so you wont get in to much trouble) But i bet there is a much better example of a letter that is said to be a form of one of the 26 standardletters in one language while another language says that it is another standardletter
grep means grep. There is not really a real world word for the program before the it was named grep. (The closed real world words are search and find but they are used for programs that do something completely different and are not real fits for grep). You also have to consider that in the world market any language you will choose will be spoken by only a minority of the market. So will you name every program different for every different language market (and be included on my personal hitlist) or will you just use english which 50% of the market does not understand. And in the latter case Why bother at all when most people wont be helped anyway
ps. There is also the political angle. When you don’t really use english you will not have problem with language nazi’s that will complain about not using theirs because you just can say that it is just a combination of letters and that it has nothing to do with english
http://www.hyperdictionary.com/computing/grep
Yes it’s meaningless, but it now conveys a very precise meaning that ‘search’ ‘locate’ ‘find’ do not have; is ‘search’ searching files, pattern within files, or the web?
Searching text using regular expression is a new function, and a neologism is acceptable.
Here we go again…
Why should a new system even allow such horrible things as applications?!?
The ONLY motivation for collecting a large amount of REIMPLEMENTED functionallity in an application is to hinder code reuse. IOW bad design.
DLL’s are by definition code duplication. If the system strictly forbade code duplication dll hell wouldn exist. System componets should not depend on other system compontens, it should only depend on a data format, which component that provides the data should be of no concern.
A way to achive this is to use OO as the main system design, while by my definition inheritance is also code duplication, object composition is not.
Jeff, the porblem with using things like version support numbers is precisely how would the DLL know it broke compatibility. It would require too much coordination between apps and DLLs. In an ideal world, the contract (function, API) would remain good and DLLs would not break. The developers of a DLL might think they have maintained compatibility, but they don’t know of application X which does something weird they didn’t take into account.
Without a big registry, the best solution is that used by windows. A common set of system DLLs. Everythign else is provided by the app.
Why should a new system even allow such horrible things as applications?!?
This is an excellent point. However…
The ONLY motivation for collecting a large amount of REIMPLEMENTED functionallity in an application is to hinder code reuse. IOW bad design.
DLL’s are by definition code duplication.
Uh, no. DLLs are by definition code *reuse*, the complete opposite.
If the system strictly forbade code duplication dll hell wouldn exist.
DLL hell exists *because* of people trying to avoid code duplication.
System componets should not depend on other system compontens, it should only depend on a data format, which component that provides the data should be of no concern.
If you want to minimise code duplication, system components have to rely on other system components.
For example, unless you want to duplicate the code in a standard file selector in every single “application” (and “applications” must exist programmatically, even if they don’t in the UI) then you need a “file selector” component – and every “application” that needs to select files will rely on that “file selector” component.
Trying to force a method of working on users is likely to backfire.
THat’s not quite correct. Trying to “force” a method of working on users who are already used to another methodology is likely to backfire.
There’s a substantial difference between those two things.
One approach to usability is to simplifying everything by removing options, this strategy assumes users are idiots and in my opinion is more likely to annoy users due to lack of options than help usability.
Most users don’t care about options, they care about results.
More people will be happy if your media player has an interface they can use immediately than will be happy if it is “completely skinnable”.
The ROS (Ruby Operating System) [ROS] has an ultra minimalist approach to usability guidelines, there’s only 4 of them.
[…]
This is a bit like saying:
Modern law has an ultra-minimalist approach to justice:
* Respect each other or else
The proximal interface of course includes a number of principles to use when designing user interfaces, these include:
[…]
I think it’ll be a long time before we’ll see mainstream systems based on these principles though some applications already seem to follow similar principles (e.g. the vector graphics component of Gobe Productive on BeOS). BeOS itself had drag and drop extensively throughout the system.
Pretty much every modern GUI is built around those principles. Some (MacOS) have been doing it longer than others (Windows), but they all implement numerous examples of everything you list.
Yet despite this, placing the menu at the top does seem to be better, how can this be so?
I can only conclude there are other factors at play:
[…]
The “other factor” is the other half of Fitt’s Law – target acquisition time.
Locating the menu in a window is (comparitively) a time-consuming affair. First you have to identify the relevant window, then the top of the window, then you have to move down far enough to locate the menu, *then* you have to actually move the mouse pointer to the right place vertically (the first part is just visual acquisition, not moving the mouse).
After this point, the comparison is basically identical – but as you can see the menu-in-window approach gives the menu-at-the-top approach a big head start.
There are situations, of course, where this target acquisition time is neutralised by having to move the mouse significantly further to the single menu bar – most notably in multi-monitor situations (why OS X still doesn’t put a menu bar at the top of each screen I don’t understand).
The most optimal menu arrangement, in terms of access time, is a pie menu centred on the current cursor position, activated by a mouseclick. Of course, it’s also got some seriously negative discoverability issues, but for non-newbie users that’s not a problem.
Command lines are very useful tools and they are in many cases better suited to tasks which would be difficult to represent well in GUIs. However, there is no reason they should be so complex as to require a reference book to use them, they should be available to all users, experience on other platforms has shown this can be the case with a well designed naming scheme.
Very few users perform _any_ actions that would benefit from the advantages a commandline offers, let alone perform them regularly.
A sensible naming scheme should also apply to the file system structure, it could be organised beginning along the lines of:
[…]
If usability is your goal, the file system structure – from a UI perspective – shouldn’t even exist. It should be completely managed behind the scenes by the OS. There shouldn’t even be a method of accessing the “filesystem” for anything except low-level programmatic housekeeping.
Installing software should be a quick, painless operation, the installer should not assume the user has an internet connection.
There shouldn’t even be “applications”, from a UI perspective. Users should deal with “documents”.
“Installing” these “applications” shouldn’t require anything more complex than a drag & drop or a context menu with an “install” item (which does nothing more than copy the appropriate files to the appropriate places *without* presenting the user with any dialogs or the like).
Uh, no. DLLs are by definition code *reuse*, the complete opposite
Ok, I was a bit fuzzy on that point. It isn’t code duplication. It is duplication of concerns.
For example, unless you want to duplicate the code in a standard file selector in every single “application” (and “applications” must exist programmatically, even if they don’t in the UI) then you need a “file selector” component – and every “application” that needs to select files will rely on that “file selector” component.
I don’t belive that “applications” must exist. A system needs ONE fileselector/manager. I like nautilus.
Ok, I was a bit fuzzy on that point. It isn’t code duplication. It is duplication of concerns.
I’m still not quite sure what you’re trying to say. Again, DLLs are an effort to avoid as much duplication as possible. If you eliminate them, then the shared “resources” they provide must be duplicated by anything that needs it.
I don’t belive that “applications” must exist. A system needs ONE fileselector/manager. I like nautilus.
From a UI perspective, they don’t. However, somewhere in the system the code that provides the functionality to open word documents, JPEGs, MP3s and the like must exist – it is that code that is the “application” and it is that code which the user will “install”.
The file selector was perhaps not the best of examples since it’s only really relevant to an application-centric UI. Consider, instead, the code that draws the UI components like buttons and scroll boxes – unless you want that code to be reimplemented by everyone who writes an “application”, then it hsa to be in a shared library somewhere.
The file selector was perhaps not the best of examples since it’s only really relevant to an application-centric UI. Consider, instead, the code that draws the UI components like buttons and scroll boxes – unless you want that code to be reimplemented by everyone who writes an “application”, then it hsa to be in a shared library somewhere.
I have been thinking about this alot lately. What I think is needed is “One UI to rule them all”. That is everything connected to user interaction is controlled by the same system component. Systemwide MVC in a sence.
Stric serive centred applications, like games, don’t fit in this paradigm though… yet =)
In the case of file data acess.
1. The user requests acess to a file through the file manager.
2. The filemanager identifies the file type.
3. The default view component for the file type is loaded. In old system this would be an application. In this design it’s only a rendering engine.
4. In many cases the default view component (ie, the gecko engine) is rahter generic and needs another data type (ie xhtml). The systems finds an apropriate transformer component that transforms the data into something the view can handle.
I can imagine handling everything as xml, or keep the everything is a file.
In the file paradigm the datafile would be transformed into a filesystem before the view comes into play.
What is all comes down to is small transformation centric components, and a system to connect them all.
Another example, a game of chess (to return to the file handler part): Instead of spawning a chess process through the menu a chess game file is created. When this file is acessed a UI component to handle that file is the view. Now there is no reason to save the game state, the system will handle this automaticly.
somewhere in the system the code that provides the functionality to open word documents, JPEGs, MP3s and the like must exist
But they don’t need an UI, only an API.
If we take
“[Usability] strikes me as something between art and
science, about putting the right things in the right place, not over complicating things, simplifying where necessary and moving more complex or less used options out of the casual users way.”
and
“One approach to usability is to simplifying
everything by removing options, this strategy assumes users are idiots and in my opinion is more likely to annoy users due to lack of options than help usability.”
and use some deductive methods, we get (roughly)
“Usability is removing options, which annoys users”
so, considering the following:
“GNOME has removed options”
“Spatial Nautilus has annoyed users”
we could say that the GNOME people were right all along.