Software Usability As A Technical Problem 551
An anonymous reader writes "Let's face it. Poor user interface design is a big problem in software today, particularly in the Open Source world. A recent article on NewsForge addresses this problem from the perspective that software usability is a technical issue that Open Source developers can and should face and conquer, just as we have conquered other technical problems that have stood in our way." (Slashdot and NewsForge are both part of OSDN.)
FC2 (Score:2, Interesting)
Evolve (Score:1, Interesting)
Common User Access (Score:1, Interesting)
Yes a technical problem, but of different nature (Score:5, Interesting)
Re:not really (Score:2, Interesting)
However, on my freebsd machine, ion [cs.tut.fi] is very nifty. It lets me keep the windows tiled but makes it much easier to swap between windows too. Plus, it's designed to be used entirely with a keyboard, as opposed to most window managers where mousing with the odd keyboard shortcut is expected.
Usability (Score:5, Interesting)
Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.
Exactly. Submit it as a bug. This is the first thing. Many of the people who work on OSS projects realize that there is a usability problem. However, nobody wants to do anything about it. It seems that many developers do not consider usability issues to be a defect in the software. As a person who is *very* interested in usability of software (part of my degree), I have to disagree -- issues with usability is a MAJOR defect. It's the reason that many people will not turn to Linux/OSS options. They are scared by the command line. They don't like it when menus in one program do not match up with menus in others. I can't say I blame 'em! (Well, I like the command line, but that's a byproduct of me being a nerd.)
As a backup to my previous statement, I am constantly submitting usability bugs to projects when I find them. However, I am constantly ignored. WHY? There are so many things that could be improved upon and made easier so it's more appealing to the users. Why do you think Microsoft products do so well? People recognize them. They know where stuff is. There's no guesswork needed.
And, yes, some OSS projects do this very well. Mozilla products (Firefox, etc.) are very well designed. There are minor usability flaws, but nothing that isn't easy to figure out.
Personally, I would love to sit down with a team and work through usability issues. I would love to have someone actually show some interest in fixing these problems. However, it seems that, too many times, these issues are discarded for ones that are more technical. And, of course, the usability issues will come up again later. It's a pretty vicious cycle that needs to be stopped. If only someone were willing to do it.
(BTW - I realize I could code these changes myself, but I do not have the necessary skills to do this. Otherwise, I would.)
Re:Evolve (Score:2, Interesting)
I mean: right now most OSS has lots of skins and different possible interfaces, but most newbies don't even know how to switch them on. And that's because the software isn't intuitive.
Say you want to add a new remote printer: it's no use that the menus were designed by an artist, have several combining colors and so on, if you don't even know were to start from.
What the community needs to start paying more attention to, is the non-geek user who would rather have it simple and straight-forward than full of options he/she doesn't even know what they mean, and how to set them.
OSS is counter-intuitive, and even though it is making great progress, it still has a long way to go.
Recommend-a-newbie (Score:4, Interesting)
This is the secret to open source stuff: drawing on the community skill. This method is just in a non 'programming-skill' oriented fashion
If you get a Chilean developer to have his grandpa, who has no stereo vision, have half a look at it, then there'll be lots more important feedback, at least after Babelfish has done its work.
Re:not really (Score:5, Interesting)
Finding an interface that will make all your users happy, is next to impossible. I would guess that SOMEONE likes the way each app looks, but not everyone. Linux actually is a step ahead of Microsoft in this regard, due to the fact that a lot of window managers (Kahakai is nice, and we are hard at work on Aegis) are now scriptable, not to mention the basic customizations that have been around forever. While average joe doesn't know how to script up a sweet desktop, distrobution makers can whip out several different setups, and let the user switch between them, rather than the windows way of forcing their interface down your throat.
A lot of times when I first lead people to Linux, I figure I might as well give them Gnome or KDE figuring it will be more intuitive for them. From what I've found though, people are actually much more excited about interfaces like *boxes, once I lead them in the direction of how they can edit the settings and etc. While the big windows-like interfaces may make the transition easier for some, I think a lot of people are very happy with the ability to set up their own, "new and different," UIs.
Its because developers are running the show (Score:5, Interesting)
When i ponder what makes Microsoft so successful (aside from the questionably legal business practices) is that their company is not ruled by the developers but by the PHB's of this world. Microsoft invest considerable effort into researching what people are actually doing with their computers. Say what you want about them, they are actually pretty good about listening to their customers when it comes to features. By contrast, Linux developers often concentrate on scratching thier own itches which ultimately only appeal to like minded individuals. I could list several things right now that are not easily possible in Linux right now.
I write software for a small company, and we are very blessed to have a very technically less-literate person on our staff. He is our functional expert and he gives us a lot of great feedback on our UI's. Open source projects should never underestimate the value of such a person.
Re:not really (Score:3, Interesting)
Re:OSS has no user interface problems (for me) (Score:2, Interesting)
I am sick of hearing "I'm not a normal user." It is true that most users are not software developers, however there is a very wide range of users, with a very diverse range of needs.
What this means is that people who call for "similar applications" and "uniform experience" are just kidding themselves. The software I use and write works *very* well for me. Is pandering to a specific audience a problem? Or am I obliged to write software that I can't use?
Developers: It's all about the freakin' Users! (Score:5, Interesting)
"Personally, i like to ask the users what they want to see."
EXACTLY! Sometimes the users don't see the Big Picture and have old habits they want to keep around, but more often in my experience it's some boneheaded developer's choice to squander resources to "improve" an interface without ever actually investigating whether the users will get any improvement at all.
On my latest project (in-house application) I've actually had to go head-to-head with our senior developer (not a software engineer) over how the interface should look and work, me going to bat for the users.
The users of the new application want it to look and function in a manner that suits the way in which they need to operate day in/day out. Simple, straightforward. I prototyped it for them and they loved it.
Our senior developer then told me no, we're going to do it using MegaSuperKewl WizBang crap, something the users were fundamentally opposed to (it would actually tangibly interfere with the way they use the data in production).
I'm hardly junior myself - 11 years fulltime S.E. - and figured screw it, I'm not going to watch this abomination progress unchallenged. I arranged a meeting between the users, the senior developer and myself. The conversation was hilarious. I asked him to explain to the users how his design would improve their productivity. Let your imagination run wild and you'll come close. The users won in the end, but it was hard fought
But then the same week I had to argue, yes ARGUE, to store constants to be shared across applications in a common header file. The same fellow argued it would be much easier to hardcode it in each application separately. A heated 20-minute meeting later, I get to store the constants in a common header file.
I *WISH* I was making this stuff up. My life is a Dilbert strip.
Re:not really (Score:3, Interesting)
Well, well. A rather pompous statement with no supporting argument. Not to mention that I disagree with you.
I don't find it slow, and it can be customized.
I have my desktop organized the way I organize my wooden desktop. Who are you to "guide" me?
Re:KDE, Gnome, Linux... (Score:2, Interesting)
Same thing happens if you rent a car, the controls might be positioned diffrently with the sole exception of what you use to drive (steering, pedals, shifter).
Design to emulate old behaviours is good for products that want to remain decidedly outdated. Usuability is not the same as backwards behaviour compatible. While providing some sort of emulation is good it deprives you of developing something with it's own soul. Apple seems to understand this, OSS im not really sure.
Re:Usability (Score:3, Interesting)
OK, the problem is that your bug is probably going to land on the desk of the dork who thought that "smbUmount" was a good idea to begin with.
No, it's going to land in the bug database, where many people will see it, including not only that original "dork", but also plenty of other people who are able to fix it, at least some of whom won't agree with the "dork". Further, even if the "dork" marks the bug as "wontfix", it will stay in the database, and additional reports opened about the same issue will pile up. Eventually, someone will realize that something needs to be done.
The reason I mention this is because the parent post is basically discouraging people from submitting the bug report because it may not do any good. But it certainly will do some good, even if it doesn't directly result in a fix. So please, report bugs!
And, if you really want your reports to be effective, provide a patch, as well. Or, in this case, it would be almost as good to simply provide a better name, along with an explanation of why it's better.
How boring! (Score:3, Interesting)
Listen, as someone pointed out: if there's a usability problem, fill in a bug report. This is OSS real force.
We are all a bit lazy. If something don't fits your needs, fill in a bug: it is like black ink on your dress, you HAVE to have it fixed, or what sort of programmer are you?!
Moreover, I think that's still the same old story: who says "command line is good enough for everyone, and if you don't like it, it's a problem of yours" versus "mouse is beautiful, why should I use that keyboard? It'll bite me, if I touch it!"
Well, I'm for: keep them both. For example, I noticed that in Kdevelop you haven't key accelerators when debugging your code. This is a problem for me, so I'll fill in a bug report, and I'll point it out.
See Emacs: you have menus, you have toolbars. Me, I spent some time learning the keyboard shortcut, and I never ever touch the mouse anymore! That's fine for me, and that's fine for the newbie, because the UI is there to help him.
As always, FS is about freedom, expecially to choose. And since we are here to get better, if you want it "your way", speak with the right people (the devs), don't just complain! OSS is about community, take part in it, don't just sit on the bench criticizing.
(Sorry for the awful english)
Re:not really (Score:2, Interesting)
I guess it could be said that I'm a PC neat freak. I try to keep clutter to a minimum. I can't stand too many things in the system tray. Theres usually never more than 3 icons in it - Asus Probe, Winamp, and ICQ (which I never leave open too long, only use it when I have to.)
Re:D'oh - dumb article, solveable problem (Score:1, Interesting)
Disagreed. I want my key combos. They should never be the _sole_ means of accessing something (except, perhaps, the degenerate case of one-key ones like t to insert a t character.). And to maximise discoverability, they should be shown next to the menu item.
Everything must be accessable through the menus.
Agreed. While we're at it, amiga style menus where one can select multiple things without closing and reopening the menu would be nice in more apps. Probably patented in the US though...
People blank out on the 500ms they're thinking about the control key combo
I just don't think apple's research is right in my case. That's half a second. I just don't take that long. I checked. Might be true for combos not often-used, I guess.
But if I had to go to a File->Open menu each time I press C-x f in emacs, I'd go mad. Total time to decide to open a file and then press the keys to do so is about a half second. (I just checked, with my brother timing me)
But with a menu, I need to think about going to the menu, then think about navigating it. That just disrupts my train of thought more, so I'd use the keyboard even if it did take me half a second to remember "C-x f". (and it doesn't, it's apparently burned into the "Flash ROM" of muscle memory, must take at most about 100ms if you don't include the thought "hey, I'm gonna open a file". (And in fact, it's burned in with the control key beside A, so I'm screwed on strangers' keyboards with the control key in the new, wrong, place and caps lock where control should be)).
never, ever use keyboard toggles that don't have a permanently visible state on screen.
Agreed. Thank God, or maybe RMS, for the Emacs modeline.
Microsoft gives fish, Apple taught to fish (Score:3, Interesting)
Apple once held up the idea of the user never having to read a manual as a goal for their software.
Apple's now-unfortunately-defunct help system (Apple Guide) was what I consider to be one of the best UI creations in the desktop world. Microsoft took a "wizards" approach, where they slap a basic interface up to allow the user to accomplish a simple task. Often, if this was what the user wanted to do, they could accomplish the task quickly. Unfortunately, they had no idea what was done in the "regular" interface to accomplish this task. Their knowledge did not transition to the regular interface, they did not learn how to do something very similar but different from what the wizard allowed, and sometimes they couldn't figure out how to accomplish the a particular element that they could manage through the wizard in the regular interface. In short, Microsoft gave the user a fish.
Apple Guide was a much, much better design for the user in the long term, though it might be less immediately satisfying. Instead of popping up a wzard that hid the regular interface, Apple Guide walked the user through accomplishing a task *with the regular interface* so that they learned how to use the regular interface. This is much slower the first time or perhaps two times, but after that the user knows how to accomplish his task using the regular interface. It is much easier for him to become an "expert" with the software, and he requires less technical support in using the software.
Re:not really (Score:5, Interesting)
It's not that Macs are more effective; Windows users can probably be very effective after enough repetition. The difference is that Apple tries to take out the need for additional movement and memorization.
For instance, Microsoft puts icons on the left, directly behind where most Windows open, so you have to minimize or hide those windows to access your icons. Apple puts icons on the right and in the dock, so when you have a window open, you can still double-click on your icons.
Microsoft maximizes windows to full-screen. Apple maximizes windows just large enough so that you can see everything in the window, so that you can still get to things behind the window.
Microsoft doesn't have a standard for keyboard shortcuts(alt-f4/tab to quit/switch apps, ctrl-x/c/v/z for cut/copy/paste).
Apple does have a standard for keyboard shortcuts(apple-q/x/c/v/z/,/h/tab for quit/cut/copy/paste/undo/preferences/hide/switch apps).
Microsoft has application preferences in some weird menu generally named "Options" somewhere off to the right, and Preferences isn't generally named anything. Apple has application preferences in the exact same place on the screen regardless of application:
You're probably very effective on Windows, but(and I know I'll get flamed for this), Using a Mac requires less thinking. With the Mac OS, Apple has always tried to make an operating system that gets out of your way and lets you do your work, and they've done a pretty good job.
Re:not really (Score:4, Interesting)
Has anyone considered that the reason OSS interfaces suck is because there is no incentive to do better? This stuff is free, stop complaining. If you want quality, then pay someone for a better version
I would agree with this concept 99% of the time. Guess UI isn't one of them (for the most part). Yes, in a corporate environment for a specialized app, customization is good. However, for basic apps and those that reside primarily is userland, needing to modifying UI is a bad thing.
The problem for me is understanding what users want. (I don't write the code, but I do chose or modify as needed.) Best meaningless example I can think of is a friend of mine. He wanted the cheapest possible computer to read e-mail and write simple papers for some classes he was taking. Set him up on a $50 box with Linux. Linux was no problem. The mozilla e-mail thing he loved (as it was way better than the LotusNotes mess he had to go through at work). He played with every word processor type thing I could find, and he hated them all. While he rarely used WinWord at work, and definitely didn't need any of the features it offered, it was what he wanted. He settled on AbiWord, used it for a while, then forked over the cash for Dell with MS Office. (And MS compatibility wasn't even an issue for these classes.) Used the thing for all of six months, wrote his handful of basic papers, and hasn't touched the computer since.
Now, tell me, how can usability studies help?
"Copy what they already know":
A) doesn't improve use for future users
B) near immitation isn't good enough
UI is a strange monster. People like different things, and a general purpose PCs make things all the worse, as different environments have different "bests" e.g. the person writing the novel, the person writing the newspaper article, the person writing the magazine article, the business person writing the memo, and the student writing the term paper should, in theory, have different needs.
Now, open this concept up to all the different apps and work place settings and home situations. Getting the "best" is basically the same as merging hundreds of images of pretty girls to form the perfect woman.
I am a jerk on the topic of UI. Find the best app for the job, and tell the user to suffer if they don't like the UI. Just like finding a wife -- you may not want to look at her every day after day after day after day, but that doesn't mean you should get a divorce just 'cause you think she should be better looking.
And that's all I have to say about that...
Re:not really (Score:2, Interesting)
You're probably not doing your monitor a favor by turning it off and back on frequently. It doesn't matter if it's a CRT or an LCD, it's probably better not to turn them off while you're away for 4 minutes taking a leak.
Also, if you have IDE harddisks, most of them are designed to be turned on and off at times - If you compare the specs for SCSI server disks and IDE disks, you'll find that the number of startup/shutdown cycles they are specified for is an order of magnitude larger for IDE drives (and even more for notebook drives), while the run time is usually smaller. In some cases, you actually do them a favor by turning them off at times as some clean the gunk off the heads in a special area where the heads rest - some IBM SCSI harddisks had a firmware patch to spin down and back up every few days for a similar reason if I am not mistaken. So unless cron and syslog turn it on after a few seconds anyway, you can just as well let it spin down during lunch.
Re:D'oh - dumb article, solveable problem (Score:3, Interesting)
Microsoft's "Start" button is particularly bad, because it's not quite at the screen corner. If it were, you could click it without looking.
Re:not really (Score:5, Interesting)
It exposes a lot of interface options that are hard to adjust otherwise.
This reminds of a critique I read in a recent Slashdot story a day or so ago. The argument went that editing "arcane config files" (not my quotes) is somehow less superior than neato dialog boxes with checkboxes. Your comment illustrates the often overlooked fact that even an average Windows user has probably discovered that most Windows settings (or name-your-favourite-program's settings) are deliberately obscured from view or otherwise inaccessible, and short of spending inordinate amounts of time burying one's nose in the registry and rebooting, or depending on a utility/shareware program to offer bits and pieces of what's missing, there's not much one can do.
Yes, plain ascii is accessible as the nose on your face, and is as easy to edit as a letter to grandma, but more to the point, when considering "usability" I think it's entirely fair to factor in how much effort is expended by a user trying to figure WTF the program is doing (or worrying about what was done or wasn't done to that user's system) given that the source isn't available, the developer is definitely not available, and the "nice looking" documentation was written by committee so as to not confuse the user with too much information. Equally fair, are questions along the line of "Isn't there something I can type on a command-line that will allow me to skip this Start Menu and multiple property sheet click-throughs so I can get on with it?"
Most of would have trouble using up all our fingers trying to count those applications we consider to be "slick" or "professional". That said, trading borked or confused menus and odd aesthetic choices on a program we downloaded for something more slick but strips the user of control is a false economy. It's also a royal pain in the ass. Considering that Microsoft is often viewed as the standard bearer, I wonder what the usability experts hired by them to come up with the endless procession of such winners as "personalised menus" would say if confronted in person with the unwashed masses shouting cries of "How do I turn this sh*t off?!!"
Adobe, I've always believed, can do no wrong when designing their apps. Yet at the same time, I find myself turning to ImageMagick where possible to accomplish what I need and saying "No, but thanks!" to their emininently usable interface. Goes to show you can't please everybody all the time. Myself included, if that's not obvious enough.
Re:not really (Score:3, Interesting)
No, it was found (again through usability studies) that a better way was to make it look unique enough that people recognised it was new, but intuitive and obvious enough that people were able to use it easily anyway. This is the approach Gnome is taking - whether you think they've been succesful or not is a different argument for a different time ;)
Re:Yes a technical problem, but of different natur (Score:4, Interesting)
There are already a lot of replies to this post saying "no definitely not, OSS developers are all elitest ignoramuses" because it's easy to sound insightful when criticising, but really what they're saying doesn't stack up. It might have been right 3 years ago but the improvements made since then have been staggering.
A lot of software has been rewritten or redesigned with usability being core. Example: grip [nostatic.org] was deemed a lost cause as far as UI went, so Sound Juicer [burtonini.com] was written instead. XMMS was deemed fundamentally flawed so Muine [gooeylinux.org] and RhythmBox [rhythmbox.org] were written. Gnome has adopted a pervasive HIG and while it may have a few rough edges still it's arguably more consistent than both Windows (hands up if you read the Windows HIG - thought not) and even Apples (brushed metal or aqua - what mood is Steven in today?).
Today, if you want, you can get software that's had well thought through usability. That doesn't mean everybody uses it, but it's certainly available to those who want it.
Now, there are some big remaining usability issues in free software but these tend to be structural/architectural. For instance Linux software installation is frequently very difficult and it's not easy to solve without a great deal of engineering [autopackage.org].
On Windows the GIMP user interface isn't anywhere near as good as on Linux, despite the GIMP 2 itself making great strides over the 1.2 release in absolute terms, the different (arguably worse) Windows WM model and UI paradigms aren't accounted for and there aren't enough Win32 Gimp developers to give Gimp/Win32 an excellently integrated UI. Or at least, not rapidly.
This is more a side-effect of the Gimp being most popular on Linux and the core developers all using Linux though, rather than any fundamental insight into the nature of open source. I've seen some pretty crap ports to Windows UI from commercial companies as well - for instance, the laughable QuickTime 4 which not only made zero effort to integrate with the host operating systems UI but also committed quite a few usability sins like the thumbwheel.
Re:not really (Score:3, Interesting)
In KDE, you have Control Center in |Preferences| menu, which you use to control almost all of your desktop manager settings. Most of those settings come with auto-preview, which lets you check the appearance before you hit the 'Apply' button.
Gnome does the same and does it on the fly, as you click through different options.
As we all know, both managers are fully user configurable, unlike Windows one.
However, the whole usability issue cannot be looked at through 'look&feel' of the user's GUI. In all three managers mentioned above (and this applies to Mac OS X too), the problem is basic paradigm on which they were all built - windowing environment designed by (arguably) Xerox for immensly less complicated systems, where you could see almost entire system tree in a single window. Today's babies are a bit different and I think that somebody needs to come up with entirely different approach to how we do actual work using certain apps (search for and edit documents, attach them to emails, retrieve useful info from the Internet, catalogue and play multimedia and so on). What different way? Well, I have no idea, that's what we use geniuses for, isn't it?
Re:not really (Score:3, Interesting)
See, that's one problem. Dumbass developers who think that either the way it's done is crappy, or that WhizBang NewWay is the way to go.
The user interface is NOT the same as code. There are often better and better techniques to do things in code. However, people themselves don't think differently (Apple slogan aside). They haven't thought differently for a few thousand years. So stop inventing new ways to display the same stupid thing, and start admitting that what's been written about UI design is valid!
It actually applies somewhat to code as well. I can't count the times these crazy, out-of-control developers I work with come up with some insanely complicated mechanism using EJB's, databases, and discovery protocols to do something simple, like read a config file. It's like some kind of chest-beating session -- "My code-fu is better than yours!" High-schooler crap. And then when it breaks as it always does, it takes weeks to find out why. Asshats!
Another problem. Developers are coders. They know how things work. Users are not coders. They do not know how things work. This is a fundamental disconnect between the back end and the front end. For a back end developer to design the front end requires the developer to achieve a kind of quiet zen state where they forget what they know. And despite what you may think, forgetting something is difficult to do, as difficult as asking your average WalMart WageSlave to do some calculus.
So the idea that most developers can create a decent user interface is laughable, especially when the answer they give to most questions are pithy, asinine comments such as "Use the Source!" and "RTFM, luser!" That there is a question at all should be a clue.
I know, I'm not giving any answers. Somehow we do need to attract UI-savvy people to Open Source. I don't know how.
But if any developer wants to try, and at least temporarily to shut down their arrogance for the user interface as mere eye-candy, maybe they can buy (yes, BUY, don't give me crap about how open source developers can barely afford to eat; maybe they should concentrate on living instead of coding) a very nice book on user interface principles: The Essential Guide to User Interface Design: An Introduction to Gui Design Principles and Techniques [amazon.com]. It's a good read, and it teaches you what UI elements serve what purpose, when you should use them, how UI elements should relate to each other, and how to design the overall UI.
It's USD 55. Deal with it, or go back to high school and get a job.
--Rob
Re:Its because developers are running the show (Score:3, Interesting)
you need a team of professionals
I disagree in part. I've seen a number of large projects with dedicated, trained UI groups that managed to totally stuff up the user interface. User interfaces designed by committee can be just as bad as user interfaces designed by developers. I'm not sure what the silver bullet is but it's not throwing a horde of UI designers at it. Possibly the best thing to do is is to get a small number of gifted people and leverage/replicate their work massively, as Apple has done. That's the nice thing about software; somebody needs to do it once and then it can be easily copied a million times.
---
It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA abuse.
I feel for you. (Score:5, Interesting)
The user where data entry where they never looked at the screen, much less the keyboard. we're talking about 100's of pages a day of entry.
This software engineer had created an application that was almost completly mouse driven. The tabbing wasn't in any order, you had to use the ouse to drop down to any option, to select were the document is sent to, etc...
They went from 100's of docs a day to dozens.
The software engineer always blamed the users, and said what he did was 'standard'.
I went in, fixed the tab order, and assigned keystrokes to all the options. The same keystrokes that had been used on the previous app.
It took me a week, when the engineer found out, he blew a gasket. Screamed at me, mostly at my back, since I don't tolorate that behaviour, then up to the Sr. Managment team.
When I got thir, he had them all convinced that I had broke the app, made it unusable, and it would takes "years" to fix it.
So there I am, looking at a Sr.VP, a Jr VP, and an HR person. I'm not stupid, I know what they had in mind.
The converstaion went like this:
VP: "Did you make all these changes to the application?"
Me: "yes"
VP: "did you consult the engineer?"
Me: "yes, he said that the mothod they were using was a 'standard'"
VP: "I think you may have stepped out of bounds"
Me: "excuse me, I need to use your phone."
[Calls the data entry manager]
"hi brenda, I'm here with some VP's, can I put you on speaker phone?"-"Great"
ME: "Brenda, what was the user average per day for document input before the new system"
Brenda: "About 700"
ME:"And what was it last month?"
Brenda: "about 80"
Me: "I see, and what was it last week after the new changes went in?"
Brenda: "I haven't finished the report, but I'd guess about 700"
Me: "Thanks Branda, that what I needed."
The VP excused me. later i the week I got a promotion to fill the former engineers position.
The point of this story? User interface is for the user. Give them what they need, to do what they want.
You should hire me, we could fight the good fight together.
Re:The Simpsons (Score:3, Interesting)
Some of his idea were good.
Bigger drink holder.
Better viewability.
That's Useability stuff.
KISS : Keep It Simple, Stupid (Score:2, Interesting)
Slashdot is a pretty good example of this (no I'm not using it as a way to be moderated up). Initially you can simply use it for information gathering. Everything recent is one one page, the left hand column has the basic method of reducing the mount of information into simplified "Sections". As you may know, (or maybe not you may be a new reader here) you can reduce the amount of useless information by creating a login, and setting your preferences to see the information you want on the main page and limiting the comments you see on articles to those (for example) moderated level 3 and above. If you want to get more complex, try responding to articles and getting modded up. If you want more complex try getting submissions published!
Another example I have seen recently is Adobe Photoshop Elements which is picture editing software. I use primarily the first 4 menus of this software for my photos. My brother, an artist and an owner of the full version of Photoshop, used the first 4 and remaining menus when building the graphics for his website that I maintain on my computer. The simple items are near the front (to the left) and the more complex items are to the back.
A more embarassing example was when I had my Non-techie wife testing a new version of my brother's website I was building. I had put in some fancy Javascript tricks I found at Dynamic Drive [dynamicdrive.com] to bring up larger pictures of the thumbnails within the same window to "simplify" the user experience. When she used these pages, she found them more complex and less useable because they were inconsistent within the realm of a web page. Needless to say I ended up ripping out all of the Javascript and creating 40 new pages to simplify the interface. My even less technical mother approved of the new site with the Javascript removed.
Re:not really (Score:3, Interesting)
I've had lots of conflicts with one of my former managers over this issue. And both of us were very good interface designers in our ways.
As a developer, I always think of my users, and I try to develop a package that will be easy to use the third time you use it. A little challenging to get the hang of, but accomplishing any task is both fast and easy once you get the hang of it. Generally, things I build are things that will be used daily by those that will be using it, so I think this is the most appropriate thing to do.
However, the managers have a different priority, and it's dollar driven not quality driven: They want the person that's going to sign the cheque to find it easy to use and follow during a board meeting demonstration. This means hiding all the power of the app and holding the users hand, because most of the time, the one using the app doesn't do any of the nitty gritty work in the business and doesn't know what's going on in the day to day lives of those that do.
It all boils down to knowing your user. If you've gotten "authority figure" status in the minds of the person paying, use my approach and let them find out later how much more productive it makes their workers. Otherwise, shut up, use my former managers approach and get paid.
This is assuming that you're the sort that cares about your users, of course.
Usability Problems: Why Linux can't win (Score:3, Interesting)
Poor user-interface design was what kept me away from using Litestep as my Windows Shell replacement I couldn't just drag things where I wanted them, but instead had to go in and edit some configuration file. Expose users to settings in different graphical menu systems - that's what they were designed for.
I myself know that I have a great sense of usability when it comes to wetware-software interaction (I, Robot reference ripped). It's unfortunate that I don't have all the necessary skills to help a project. Would love to do some free design/consulting work for a project, though, if I was taught how to do the whole design process.
Here's a crap ui design from KDE (Score:2, Interesting)
In konqueror, highlight some text and do a Ctrl-C to copy it. Open up kwrite or gedit and do a Ctrl-V. Simple copy and paste. Now, do the Ctrl-C in konqueror (or kwrite, etc) and open up a konsole and do a Ctrl-V. What happens? NOTHING. OK. Now in that konsole highlight some text and do a Ctrl-C. What happens? NOTHING.
If you want to copy text from a konsole and paste it into virtually any other app, you need to highlight the text, right click the mouse, select copy, and then you can paste into kedit, kwrite, gedit, abiword (whatever) with Ctrl-V.
To do a paste into a konsole from virtually any other KDE app (or Gnome app for that matter) you do the proper Ctrl-C to copy but then, in the konsole you need to right-click the mouse and select paste.
What. The. Fuck. Is. Up. With. That? What genious figured it would be a good and smart thing to do to completely bork the standard within-environment key bindings used in virtually every other KDE app for konsole? Granted, the Ctrl-C/Ctrl-V keys don't work for xterms either but then, and xterm isn't a KDE app. Oh, and yes, the easier mouse-driven way to do it is to simply highlight the text in whatever and then middle-mouse-click to paste but this only works with three-button mice and even then, not universally (it doesn't work on my laptop).
How about all Gnome/KDE developers sit down and make ALL the Gnome/KDE apps work exactly the same amongst themselves: agree on standard keybindings and stick with it for ALL apps. A konsole should use ALL the same key bindings as kwrite, kedit, kate, kword, kopete, etc, etc, uses. I cannot address Gnome much as I do not use it and do not know of any idiosyncrasies along this line...
Getting rid of "configuration" (Score:3, Interesting)
Printing, for example. You should never have to "configure" a printer. When you try to print something, you should be offered a list of available printers. The system should find them. If the system doesn't have the tools to find printers, why should the user be expected to do it? Maybe you have buttons like "look for more printers", or "ask neighboring machines for help finding printers". But the user should not be typing in IP addresses or installing "drivers".
Yeah, this takes some programming work. But it saves the user work. That's the idea.
Re:not really (Score:2, Interesting)
As for your examples.. I agree that personalised menus are about the worst idea seen in years. NO one likes to have their stuff randomly disappearing on them no matter how infrequently they use it.
The command line/start menu one -- only if you find one of the folk who are actually still migrating to a GUI these days.. I've never heard of anyone who doesn't use Linux or similar 99% of their lives asking how to type a command line. While click-through "Wizards" are often much longer than they really should be, they're still far preferable to most people than having to memorize/lookup and (correctly) type a 100+ character command line.
As for Adobe, I don't know much about their other products but Acrobat reader is (in my opinion) just terrible. It defaults to page-at-a-time so that it jumps an entire screen if you scroll one line too far. It won't let you close a standalone window if there are any PDFs open in a browser. It refuses to load half the time (has a frozen copy stuck in memory that you have to ctrl-alt-del to kill). Randomly decides to zoom in to usually 150-200% for no good reason, even when you're using the hand (scrolling) tool.
And I've recently found that the search within a browser window at 800x600 (what I'm stuck with at work due to crappy monitors) cuts off the results box with no scrollbar to get to it. I'm sure I could go on if I felt like it. I really hope their non-free programs are better designed.
Oh and lets not forget the documentation. Actually lets do so. Almost all software documentation (OSS included) is pretty much entirely useless except as a reference for someone who's done it before and just needs a refresh.
The Palm Pilot Example (Score:3, Interesting)
Not all coders hate usability... (Score:2, Interesting)
Making a subsystem robust, flexible, and easy to use is a very similar challenge to making a good user interface. Both are hard but not unsolveable problems--you just have to spend some time thinking before you rush to start coding.
While it's not good to design the UI last, it is possible to design applications with a hard wall between the "guts" of the application engine and the GUI--besides being a good software design principle, this allows multiple GUIs to be created, and would make it easier for people like you to contribute to OSS projects.
Another point that has been already made but needs reinforcing--artists are not designers! (and most "web designers" are not designers either) The GUIs at work that I've seen that were dominated by an artist are often worse than the programmer-designed ones--lots of pretty borders that take up valuable screen real estate, hand-built art bits to make every screen different from every other one in slight ways, button schemes that only work with four-letter text labels, etc, etc.
Anyways, if you want to perservere, and you have access to a Mac (as I think you might if you're an architect), is to install the developer tools that come with OS X (called Xcode in the current version). There is a tool called "Interface Builder" that lets you design user interfaces by dragging buttons around and making connections, that can actually form GUI prototypes that can even have limited functionality. If you made an awesome looking "dummy" application and put it up somewhere along with a well-thought out control flow diagram or other document, I bet some programmer might say "hey, that would be really cool if it worked" and add the neccesary code. Hell, I probably would! ;)
Re:not really (Score:1, Interesting)
How often do you support thousands of users on Windows desktops who call the help desk because they can't figure out how to drag their taskbar from the side of the screen back to the bottom? When asked (and I did ask on the various calls I went out on out of curiosity), the vast majority of users tell me that they appreciated the smaller menus. They could find what they always did that much quicker. Those who didn't like them were the (much smaller number of) people who were knowledgable about the app- or at least thought that they were.
I don't think that it's a misguided study in even the mildest sense. The vast majority of users, especially on Windows machines, are not power users and have no desire to ever be power users. Exposing that complexity to those users by default is a silly UI design decision.
Rather, the default option should be the simplified interface with an easy access switch to go to the more advanced/complicated/"power user" interface. Which is how MS has done it. Which is an intelligent design decision. Honestly, I'm not sure why it hadn't happened long, long before now.
The power users are the ones who will be more able to flip the "complexity switch" in the interface anyway. It only makes sense to offload the impetus of switching away from the default to the power user when the majority of users are not power users. Many to the few and all that.
Oh, and as somebody else mentioned, you forgot to make "explore" the default folder option. Unless you're replacing the shell, I s'pose.
Interesting reading on the topic:
Andrew Sears and Ben Schneiderman, "Split Menus: Effectively Using Selection Frequency to Organize Menus", ACM Transactions on Computer Human Interaction Vol. 1, Iss. 1
Ah, heck. The entire journal is interesting, really.
"The importance of usability in the establishment of organizational software standards for end user computing" by Michael Morris and Andrew Dillon in the International Journal of Human-Computer Studies 45 is also an interesting read.
FLOSS Can't Solve All Technical Issues (Score:3, Interesting)
FLOSS is a really good development model when the software can be incrementally written in a distributed manner. Linux works because the majority of work in the kernel is in maintaining the drivers; small and independent chunks of code. Debian works because of packages; without packaging, Ian says Debian would never have succeeded.
Projects that require a big bang from a small group of people do sometimes occur with FLOSS but it's much rarer. And I think those projects are far less successful. The last example I can think of was the DRI; it took a small team of very dedicated people to invest a lot of effort before there was a result. The barrier to entry (the knowledge required to contribute) with the DRI is very high so progress is slow. It's not possible to just jump in and fix something small. You have to spend ages learning how it all fits together.
In my mind, the way to solve the "UI problem" with KDE and GNOME is to figure out how to break the problem into smaller independent chunks. Then just sit back and allow the distributed model of development take over. 1000s of programmers each contributing 10 lines of code has the same coding power as 10 programmers contributing 1000 lines each but it's only possible if the problem can be broken up into 1000 independent chunks.
Maybe UI design isn't one of the problems that can be broken up that way.
Comment removed (Score:3, Interesting)
Re:We Need Scalable UIs (Score:1, Interesting)