Linked by Nicholas Blachford on Wed 11th Aug 2004 07:53 UTC
Editorial 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.
Order by: Score:
v Look who is saying this and ask who pays the piper?
by ASHLB on Wed 11th Aug 2004 08:14 UTC
RE: Look who is saying this and ask who pays the piper?
by Winton Renson on Wed 11th Aug 2004 08:36 UTC

Are you sure you commented on the correct article?

DLL hell
by Yamin on Wed 11th Aug 2004 08:46 UTC

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.

CLI usability
by Artem on Wed 11th Aug 2004 09:09 UTC

"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.

v Typo (please correct)
by nda on Wed 11th Aug 2004 09:33 UTC
The best thing he said
by logicnazi on Wed 11th Aug 2004 09:54 UTC

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.

usability
by tlc on Wed 11th Aug 2004 10:09 UTC

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.

RE: The best thing he said
by Isak on Wed 11th Aug 2004 10:17 UTC

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...

Menu bar at the screen top
by Serge on Wed 11th Aug 2004 10:30 UTC

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.

Nothing about AI
by Peter on Wed 11th Aug 2004 10:30 UTC

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.

nice
by Julian on Wed 11th Aug 2004 10:48 UTC

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?

Fitts law and menus
by omnivector on Wed 11th Aug 2004 10:53 UTC

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

HID vs. Control
by Anonymous on Wed 11th Aug 2004 11:31 UTC

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.

Usability People
by infosoph on Wed 11th Aug 2004 12:38 UTC

"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.

Power Users
by logicnazi on Wed 11th Aug 2004 12:41 UTC

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)

Companies vs. OpenSource
by logicnazi on Wed 11th Aug 2004 12:47 UTC

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)

repeated developer!=user FUD
by Anonymous on Wed 11th Aug 2004 12:50 UTC

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/

Usable File Heiriarchy Exists
by Pierce Lopez on Wed 11th Aug 2004 13:14 UTC

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/

v usability
by lambie on Wed 11th Aug 2004 13:27 UTC
Hmmm
by Inglorion on Wed 11th Aug 2004 14:05 UTC

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.

how about
by hobgoblin on Wed 11th Aug 2004 14:14 UTC

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 ;)

RE:Look who is saying this and ask who pays the piper?
by Anonymous on Wed 11th Aug 2004 14:23 UTC

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."

Problem with the unified script language
by renoX on Wed 11th Aug 2004 14:55 UTC

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).

"assumes users are idiots"?
by Anonymous on Wed 11th Aug 2004 14:58 UTC

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.

Case insensitiveness, how?
by renoX on Wed 11th Aug 2004 15:05 UTC

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!

RE: DLL hell
by jeff on Wed 11th Aug 2004 15:06 UTC

@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.

It's called AmigaOS
by Justin Smith on Wed 11th Aug 2004 15:47 UTC

Dude, you've perfectly described AmigaOS. You don't know what you're missing.


Wow, usability discussions!
by usario clave on Wed 11th Aug 2004 16:58 UTC

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...

RE: Wow, usability discussions!
by Julian on Wed 11th Aug 2004 17:41 UTC

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

How about Squeak?
by Ed on Wed 11th Aug 2004 18:00 UTC

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

The myth of the power user
by matt on Wed 11th Aug 2004 18:06 UTC

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 8x8 icons on his browser toolbar, while a newbie has 5 16x16 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 8x8 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.

case-insensitive is buggy by design
by Anonymous on Wed 11th Aug 2004 18:17 UTC

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.

re: article
by matt on Wed 11th Aug 2004 18:21 UTC

"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.

Other interesting links
by Anonymous on Wed 11th Aug 2004 19:50 UTC

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.

Re: The myth of the power user
by logicnazi on Wed 11th Aug 2004 22:28 UTC

<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)

RE:Case insensitiveness, how?
by Anonymous on Thu 12th Aug 2004 00:17 UTC

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

What does grep mean?
by Anonymous on Thu 12th Aug 2004 01:06 UTC

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

RE: What does grep mean?
by Serge on Thu 12th Aug 2004 01:53 UTC

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.

Applications!
by John Nilsson on Thu 12th Aug 2004 02:37 UTC

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.

RE: DLL hell
by Yamin on Thu 12th Aug 2004 05:06 UTC

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.

Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by drsmithy on Thu 12th Aug 2004 11:34 UTC

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.

Comments
by drsmithy on Thu 12th Aug 2004 12:08 UTC

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).

Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by John Nilsson on Thu 12th Aug 2004 17:39 UTC

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.

Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by drsmithy on Thu 12th Aug 2004 20:18 UTC

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.

Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by John Nilsson on Thu 12th Aug 2004 22:54 UTC

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.

Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by John Nilsson on Thu 12th Aug 2004 23:03 UTC

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.

Deductive logic (sarcasm)
by Kalle Vahlman on Mon 16th Aug 2004 08:56 UTC

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.