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.)
Expanding market? (Score:5, Insightful)
Re:Expanding market? (Score:5, Insightful)
My most recent example? I decided on the advice of a friend to try Fluxbox a few days ago. In fluxbox, pretty much all configuration of happens inside a context menu. Fluxbox was definitly designed for technical users, but that doesn't change the fact that this is *terrible* UI design. Why? let me count the ways:
- Error prone: if you move the mouse the wrong way, you have to drill through several levels of submenu to get back to where you want to be. Similarly, when you activate a menu item with a submenu, you have to drag the mouse straight across the current menu horizontally until it enters the submenu, then drag up or down to the item you want. If you do the natural motion (drag diagonally directly to the desired item), the mouse will almost invariably cross another submenu first, forcing you to go back and re-activate the menu you wanted.
- Bad choice of widget for the type of action necessary: Incrementing or derementing transparency levels as a menu item!? It takes ~20 clicks to go all the way from opaque to fully transparent.
- Slow: In keeping with the previous comments, actually making this menu system work takes time and concentration. Fluxbox devs and users may think they're cool for having 'every option at your fingertips', but actually getting to those fingertips takes longer than if they had brought up a conventional window with sliders and buttons.
There are a set of utilities that provide conventional GUIs for configuring these things, but they are quite incomplete feature-wise, and suffer from their own ugly interface problems. In addition, you have to restart fluxbox to see the changes. Things done in a preferences panel should take effect instantly, which gives the user the ability to experement easily, giving them, in effect, more control.
There's been a lot of research done on how menus should work, and submenus really slow users down. A lot. For this reason, Apple's UI guides recommend that under no circumstances should you ever have a submenu inside another submenu, to eliminate this nasty nesting.
Just because you or I are technical users doesn't change the fact that there are other interfaces for this functionality that are faster and more forgiving.
Re:Expanding market? (Score:3, Insightful)
One of the advantages of open source is its ability to put the consumer ahead of profit.
This is bordering on nonsense because, though OSS has that "ability", strictly speaking, it certainly doesn't have that *tendency*.
On the contrary, companies that pursue *profits* are more likely to be interested in consumer usability because all profits come from the consumer.
What OSS does is put the developer's needs ahead of those of consumers. If there is no profit to be had, then it has to mee
Arthur Dent: Have you got a solution? (Score:3, Funny)
- The Hitck-Hikers Guide To The Galaxy.
Moo (Score:5, Insightful)
Personally, i like to ask the users what they want to see. Let *them* draw the screens, then merely implement it. A three-tiered approach is best, where called for. The backend should be design and implemented according toi a decent set of guidelines and rules, and the frontend should be completely designed by the user. The middle teir is where the magic should happen, even using a nasty hack here and there.
Ultimately the disparity between those who code software, and those who use software is a big problem. Perhaps a recognition of the separate group will go a long way.
The Simpsons (Score:5, Funny)
Re:The Simpsons (Score:3, Interesting)
Some of his idea were good.
Bigger drink holder.
Better viewability.
That's Useability stuff.
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.
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:Moo (Score:5, Insightful)
You think developers know nothing about usability? That is nothing compared to users ignorance.
Your suggestion, while noble sounding, is a recipe for a design where every whim a user ever had is encoded as a button that does just that, nothing more, resulting in a Million Buttons design.
Users are moderately competent at designing an expert interface but utterly incompetent at designing a beginner interface. (So are most developers, so that's not a horribly user-hostile thing to say.) And note I mean moderately literally.
The problem is, first and foremost, that people need to understand what usability is. Here you are with a +5 comment on Slashdot and you seem to think its just a matter of drawing screens. You evidently have no clue. It goes way beyond that. It is a matter of making software easy to use.
What is Usability [useit.com]? "We Don't Need Usability, We Already Listen to Customer Feedback" (at the bottom) [useit.com].
** Users should not design UI ** (Score:3, Insightful)
Instead you need to understand that Feature requests are symptoms of goals. If you follow up a particular feature request or screen widget with 'Why' you'll be able to design a UI that actually meets their needs, instead of something that they think will meet their needs.
ps developers shouldn't design UI either. That's why we have user researchers, information architects,
A good book (Score:5, Informative)
It's a collection of 20 or so stories about where human factors problems caused injuries and, in many cases, death. Poor documentation, unclear designs, and poor handling of expected user situations (for instance, the reactor technician being pinned to the ceiling by a control rod because there wasn't a safety stop to prevent supercriticallity) is serious business.
There's more to usabillity and human factors then just 'that guy is too stupid to use linux', it can literally be the difference between life and death.
Re:A good book (Score:3, Informative)
Yes a technical problem, but of different nature (Score:5, Interesting)
Re:Yes a technical problem, but of different natur (Score:3, Insightful)
Re:Yes a technical problem, but of different natur (Score:5, Insightful)
It doesn't. I'm an architect and I regularly observe UIs that have no sense to them whatsoever. Open Source acts usually as a meritocracy and I've never found a coder who was willing to redesign his entire application because the UI sucked. It's not a chicken and egg problem (as other posts around seem to indicate) since the UI always comes last.
I once considered starting a project that designed application interfaces for tasks that were needed in hopes that some coder would come along behind and actually write them. (I had a great idea for a clock that doubled as a date/location/world time zone applet.) But we have no influence. UI is considered like the body molding tacked on to American cars half way through a model's life to re-energize sales. It's never considered as an integral part of the design the way someone Porsche does.
Re:Yes a technical problem, but of different natur (Score:5, Insightful)
Perhaps there is an unspoken rule in the community that "easy user interfaces" = "simplistic programming" and perhaps that causes one to lose points in the open source "meritocracy"?
I really like your idea of designing interfaces for tasks and then developing the code to support the interface next. It implies that the user's need is defined first by the design of the interface. This locks the programmer into coding in a way that meets the user's need exactly as specified by the UI. It's a shame that didn't take off . . . But perhaps that doesn't leave enough creative freedom for the programmers to feel the project is "fun" enough to work on.
The Palm Pilot Example (Score:3, Interesting)
Re:Yes a technical problem, but of different natur (Score:3, Insightful)
My feeling is that the useability issue will be solved once UI implementation doesn't require any significant coding. At that point, users with ideas about how UIs should be done will work on projects.
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:Yes a technical problem, but of different natur (Score:5, Informative)
It represents many years' worth of HID research. It's not the end-all, be all of HID, but it's one helluvalot better than nothing.
usability problems aren't just technical problems (Score:4, Insightful)
Too many open source developpers think of themselves as GUI experts. Until developpers are prepared to give up their egos and admit that while they may be shit-hot kernel coders, they know jack-shit about GUI development, open source will be stuck with poor usability. Unfortunately everyone seems to have their opinion on GUI development, and somehow believe that their opinion is right, despite having no training whatsoever in usuability engineering (does this remind you of how everyone is a 'pop psychologist', and a 'pop computer language expert'? -- it should).
Until developpers understand that GUI development is hard, and that it's also a science with reputable metrics, and until GUI developpers are put on the same footing as other developpers in projects, open source will continue to have poor usability.
Apologies for being so harsh on the open source world, but that's the reality of it, and we need to face that fact.
Re:usability problems aren't just technical proble (Score:3, Insightful)
Somebody mod this AC up, please. He is stating a simple fact, which most coders will admit - most coders can't design UI. Is there proof of this? Not exactly, I guess. But I know in my experience that I'm so into the architecture of most technology I use that I have very little idea anymore of what "hard" and "easy" are for a regular user. When a friend/coworker comes to me with a problem, I'm frequently surprised at the problem's existence at all. The solution to me seems intuitive. Yet at the same time, I
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:Usability (Score:4, Insightful)
The problem is, that there are many cases where a seemingly minor UI change to the program would downright destroy the backend. For example (and it's a crappy one, I know, trying not to overcomplicate it...) Take a look at how the clipboard works. You can copy one item of infromation on it at once, and take one item off at once. As an end user, I don't understand why I can't copy text from notepad on it, then copy an image from paint, and then paste the text I had into Word, and paste the image I have back into paint. Obviously all the changes needed would be to know what I want to paste. Problem comes when as a programmer I now have to figure out what to paste where. Text into notepad, that's easy... but what about Word... now what, image or text? Okay, lets ask the user... oh wait, I can't, because I'm not able to do any UI in another program (hypothetically here...)
Yes it can be solved, but from a user point of view, it's minor, and from a programmers point of view it is damned complex and not worth the trouble. Let the user do two copy operations, instead of me having to write and debug thousands of lines of code that is trying to assume what the user wants (and the user will bitch about if I get it wrong anyways). Add to that most OSS developers are doing this for free, and are not going to want to rewrite their backend just for a seemingly minor UI change, which isn't going to make everyone happy, just a few people who complained.
What some people find intuitive is complex for others... there is no happy median... there will always be UI's that are not liked by some... there is no perfect UI design out there... and very few people willing to try and find it, especially for free.
Re:Usability (Score:3, Insightful)
When there are subsequent copy operations without pasting, move the buffer to a new file and display a UI to select items from it.
It's actually a great example. You don't give users what they want--you figure out their problem, and then come up with the best solution for it.
Re:Usability (Score:4, Insightful)
And that's precisely why we usability folks advocate designing the UI at the *start* of the development process, so usability is there from the get go and programmers won't have to re-write zillions of lines of code.
Unfortunately, designing UI before writing code is seen as heresy by the Unix Culture that dominates Open Source, often being referred to as a "proprietary" development methodology. And this is one of the big reasons why Open Source usability sucks.
system versus apps (Score:3, Insightful)
I just gave my father a Linux machine as a present. He is not a computer ignoramus. He's a lawyer, but he used CP/M for years, and is at least conversant with the idea of using a command line. The biggest problem he's running into is that I gave it to him configured for 8-
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 p
Until people start taking human factors seriously (Score:4, Insightful)
Your average linux-using developer thinks that everyone else is as smart as he is, and that command line interfaces are a good thing. The GUI is seen as a fisher-price interface for retards.
We need to get rid of this way of thinking. Software should be like a vending machine. You press a button, and it does exactly what its supposed to.
Linix and Windoze have set back the cause of usable software about 20 years!
Re:Until people start taking human factors serious (Score:5, Insightful)
Open source is full of people that are completely out of touch with reality. The people who are involved in OSS have outright contempt for those who 'merely' use the software
This is insightful? It's pure crap. There are certainly people who wrote OSS who do have contempt for the "mere" users, just as there are plenty of people who write commercial software who have contempt for the users. In general, though, developers of end-user applications, whether OSS or commercial, feel no such thing. They want their apps to be usable, because it's really cool to have lots of people using your stuff. That doesn't mean they know how to make software usable, of course. Wanting to and knowing how are different things.
Very bad example, though. The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily. The above is an excellent demonstration of the difference between ease of learning and ease of use. The UNIX command shell is extremely powerful and easy to use, but it is not necessarily easy to learn.
An easy to use interface is one which makes it possible to accomplish the desired tasks quickly and easily, without unnecessary steps or wasted motion.
An easy to learn interface is one which allows the user to accomplish the desired tasks without training (or significant effort to figure out how). Note that this concept is fundamentally different from ease of use in that while ease of use is an absolute (for a given task set), ease of learning depends heavily upon the user's other experiences and is achieved mostly through similarity.
These two axes of ease are nearly orthogonal, although they often seem to be somewhat opposed to one another. There are plenty of examples of apps (particularly in the Windows world) that are easy to learn but hard to use, and lots (particularly in the UNIX world) that are hard to learn but easy to use, but there are also a precious few that are both easy to learn and easy to use (many of them in the Mac world, actually). And there are an unfortunate number that are both hard to learn _and_ hard to use (Easily found on any platform). I'm sure if you think about it for a moment, you can come up with examples in all four categories.
Re:Until people start taking human factors serious (Score:4, Insightful)
It's a good example, but not for the reasons you are thinking. GUIs don't do this because it's a completely uncommon task. (If anyone actually cared, it would be easy to add a "save as text" button somewhere in a filemanager.)
However, the CLI Fanclub can't get past the the idea that a GUI is crippled because it can't do the stuff nobody really wants to do anyway. They are completely confused between the concept of a "user" interface (make everyday tasks easy) and a "programmatic" interface (be infinitely flexible).
(Now someone's might come at me about how they use grep/find 300 times a day, but do they really do that more than simple directory browsing or copying random files from point A to point B?)
I think the original poster was being a little extreme, but you do get the idea that Unix Filemanagers are developed for "other people" and not for "us" or "everyone".
Re:Until people start taking human factors serious (Score:3, Informative)
It's a good example, but not for the reasons you are thinking. GUIs don't do this because it's a completely uncommon task.
I disagree that it's at all uncommon. I think it's very common. The reason end users don't demand it is because it's foreign to their way of thinking about computers and how to use them. I've seen people many times searching through a document, looking for some word and then writing something about each location. About the only thing unusual about the example is that it presumes t
Re:Until people start taking human factors serious (Score:3, Insightful)
ls -la |grep foo > foo.txt
[...] The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily
Agreed, it's fantastically usable - if you know what the hell any of that means. Of course, that means that if you don't know the first thing about ls, it isn't particularly usable.
I've ranted before about trying to print double-sided from a Linux/KDE machine, spending half an hour reading man pages, and finally booting up a Windows box and clicking a r
Re:Until people start taking human factors serious (Score:3, Insightful)
What I could never understand was why, for the love of $DEITY, couldn't we have both? You can go straight to a command line, and I can play with my pointy-clicky button things
I think that's where we're headed. The trend with OSS stuff seems to be that every feature is provided at three levels: A CLI interface, for shell users, a GUI interface, for GUI users, and a library, for programmers (and, incidentally, used by both the CLI and the GUI interfaces).
We may not be getting there fast enough, but I t
good graphic designers (Score:3, Insightful)
Graphic designer != user interface designer (Score:5, Insightful)
User interface design is wildly different from graphic design. As a matter of fact, there are probably more industrial designers that would do a better job of doing software user interface design than graphic designers.
I'd say that a lot of awful websites out there were due to people with traditional publishing and graphic design experience trying to apply old knowledge to the Web and failing.
no one has enough money for $oftware. (Score:3, Insightful)
Like they have enough money to keep up with Adobe and Apple? The designers I know are bummed out that they can't afford the software they were trained on in school. Introducing your favorite graphic designer to free software would be the biggest favor you could do for them.
Oh yeah, doing a little free design work is one way for an up and coming designer to get exposure. They don't need to write howtos
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.
How Sourceforge/Bugzilla can help usability (Score:3, Insightful)
A way that software might support this behavior would be the ability to create "usability reports" and file them in Sourceforge or Bugzilla, and have bugs that simply refer to elements in them.
We use the users in designing (Score:5, Insightful)
Why? Because then to operate the machine, each of the users hands had to hold down a separate button making it nearly impossible for the user to inadvertently reach into the machine while it was running.
At first I thought it was a silly thing to do that would insult the operator's intelligence (who would be stupid enough to reach into a compactor while it was running?) But one of the operators confided that it was a great idea because after being burned out from working a couple of double shift days in a row, he didn't want to loose his hand from a simple operational oversight.
The operational interface was well recieved because we gave the users ownership in the design process. I think that the same should apply in designing software UIs.
Re:We use the users in designing (Score:3, Funny)
What, that wasn't the point of your post? I see.
KDE, Gnome, Linux... (Score:4, Insightful)
Re:KDE, Gnome, Linux... (Score:4, Insightful)
For me, the best way to really learn Linux is two get a second computer and put Linux on it (if you're really adventerous, put it on your only computer, but I wouldn't recommend that). Don't dual (or as I call it "duel") boot, because you'll always fall into the trap of "I know how to do this in Windows, so I'll just use that". There's still that temptation with two computers, but IMO, it's not as bad since you still have the Linux one up to use. Gradually, you'll learn more and more about Linux and how it operates (it actually is fairly logical and intuitive -- just not the same as Windows).
You may want to use something like Putty [greenend.org.uk] to ssh to the Linux computer from Windows and use both at the same time. You'll learn about Linux while using the more comfortable (for you) Windows GUI.
One other thing to remember -- you can't hurt the Linux computer while you're not root (unless, as root, you give your user account permission to hurt it). So don't be afraid to poke around (especially in places like
Personally, I don't think Linux has as many usability problems (at least not in general) as people claim. After all, most Linux softare is OSS, and most OSS developers actually use the software they're developing. So, the developers are the users. In that case there is tremendous user feedback and interaction in the development of OSS. It may not be usable for everyone (it may not even be usable for most people), but it is usable for someone. For example, gcc is a very difficult to use program. In fact, most developers rarely execute it directly, except for very simple compilations. Usually, the gcc command line is built by make through a Makefile (at work, we use imake to make exceedingly complex Makefiles from Imakefiles). Some compile command lines can be dozens of terminal lines long, and would be difficult to type in by hand. But gcc (and other compilers) are powerful tools intended only for experts. They really aren't intended for average users, and thus don't need to be usable for them. But they are usable (or usable enough) for developers, and work exactly as developers want.
I think most of the perceived usability problems with Linux (and KDE/Gnome/etc) are because of different expectations by the users. KDE and Gnome are certainly very usable (I only run Linux at home now). But different expectations lead to this perceived "crisis" in usability that can apparently be fixed (I'm not sure it can ever be completely addressed). While some tools could use improvement (especially integrating with hardware), there are a lot of tools that do have good (or at least usable) interfaces.
Anyway, sorry for the rant
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 w
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: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. T
Maybe we should be taking hints from games. (Score:5, Insightful)
Why haven't desktops and apps incorporated advances from here? Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are. Also, how do they handle things similar to launching apps? Well there's a sidebar full of big easy to distinguish one click icons, and a set of tabs at the top that switches what set of icons is displayed by type (units, buildings, etc). Seems pretty easy to figure out to me. Want to quickly get back to the thing you were last working on? You can designate hotkeys with ctrl+number an then pressing the number jumps back to it. Some RTS's have seperate select and change focus but all seem to use a similar hotkey system.
One of the things that keeps me happier with windows than linux is the at least moderate effort at standardized interfaces. Most apps of simlar types have similar interfaces and I don't have to relearn all the terms that someone decided to use THEIR names for. Every time I see a custom media player or something with this horrible neo-future interface on windows I cringe, because it's such a bad idea. I don't want to spend time relearning how to use a media player just so it can look cool, I want to watch media with it. On linux it seems every app suffers from this "I want to look unique" urge, or a complete lack of asthetic design whatsoever. So your choices are pretty and confusing or ugly and confusing.
Re:Maybe we should be taking hints from games. (Score:3, Informative)
I think it's just you, but let's take a look.
Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are.
The goals of C&C are not that of a desktop. You can do C&C-style virtual desktop stuff by just having an enormous virtual desktop under xorg -- move your mous
It's funny but... (Score:3, Funny)
Someone once told me "The two required qualities of a successful programmer are laziness, and hubris."
Consistency vs. Flexibility (Score:4, Insightful)
In an open source world everyone can customize the software to suite their needs so you sacrifice Consistency and Usability for Flexibility. Advanced users are happy but novices loose out.
If you want to improve usability in Linux or other open source projects you need to put someone in charge of the UI. Linus is the de-facto gatekeeper of the kernel but the UI seems to be fair game for just about anyone.
(A Former MS UI Guy)
Consistency (Score:3, Insightful)
This alone would help greatly. When a user downloads a stable build binary he should never see a menu that doesn't work or a radically different approach to a task that doesn't fit with the rest of the app. CVS snapshot builds and testing builds are a different ballgame.
Also Stable builds need to be clearly marked as such and stressed as the "polished" version.
Re:Consistency (Score:3, Insightful)
Frankly, I've found commercial software to generally be worse off with v1.0 releases. There are lots of pieces of OSS that slowly climb the ladder towards version 1 for a *long* time.
We Need Scalable UIs (Score:5, Insightful)
The biggest challenge to scalability is creating inuitive metaphors or abstractions between the human interface (i/o modalities) and underlying digital constructs that does not get in the way of the power-user. Apple's early OS effort were great for the novice, but derided by more experienced users - the UI was not scalable in the upward direction. In contrast, Unix/DOS/CPM was fine for power-users, but it arcane command interface made it not scalable in the downward direction.
I suspect that the answer will be concepts like Mac OS X that combine GUI and CLI elements. But even OS X is not as scalable as one might like because it is really an intuitive Apple GUI grafted on to a separate powerful *nix CLI core. Although novice Mac users can "graduate" to the command line, the transition is not smooth -- using Finder does not teach one how to use ls, cd, mv, cp, rm, etc. Rather than being scalable in a continuous sense, Mac OS X offers interfaces at two different scales - the intuitive GUI and a separate power-user CLI.
Perhaps future OS/app UIs will be truely scalable -- early GUI use will seamlessly teach the user and help them slowly become more powerful users. Developign scalable UIs will require contributions from both novice-oriented usability experts and power-oriented developers. It will require forethought and coordination so that the disparate elements of the system are "consistent" without being inflexible.
D'oh - dumb article, solveable problem (Score:5, Insightful)
Ten things you can do to make your program at least tolerable for end users:
Re:D'oh - dumb article, solveable problem (Score:3, Insightful)
Have command buttons that describe an action, whenever possible! "Save" and "Don't Save" is one hell of a lot better than "OK" and "Cancel"! If you name the buttons after actions, the user doesn't even have to read the dialog most of the time.
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.
Usability resources (Score:4, Informative)
From the article:
Bulls***.
There are numerous books and resources on usability. For example:
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)
What about common sense in UI design ? (Score:4, Insightful)
1) don't clutter things closely together; provide the proper spacing between elements of the gui. KDE/Gnome severely violates this rule.
2) use soft colors. Harsh colors make the user tired very soon.
3) Use bitmaps and labels that have a clear meaning to the user, not to the developer.
4) Be consistent with interfaces. The File menu should be there to open/close files; Ctrl+S must save the current document etc. There are lots of established conventions that work really well.
5) group similar things together (similar by concept).
There are really good sites with lots of examples of what or not what to do. But I don't think it is extremely difficult to make a GUI. All that is needed is plain common sense. I am a programmer, but people never complained about my GUIs.
We should be able to solve this (Score:3, Insightful)
I have found the very best programs are those built into two parts; namely, the command line part and the GUI wrapper part. Take a look at the SGI Indigo Magic desktop utilities and programs for very good examples of this. Of particular note is their software manager application. The command line is 'inst'. It is text based and can do everything from a terminal. The GUI portion is 'swmgr'. It simply wraps around 'inst' and presents a good interface.
The nice thing about this is the choice the user has. Running remote on low bandwidth, or want to script something? Use the text only portion. Perhaps a number of advanced operations need to be performed, such as new installations, or upgrades that break the GUI. Also use the text version.
Have a nicely running box and just want to organize and manage some software, perhaps install something new. Use the GUI and perform the task with ease.
Don't like the GUI? Well, write another one that does what you want in ways you want it to. Nothing breaks as a result and you don't have to talk with the people who wrote 'inst' in the first place.
Sure there are exceptions, like OpenOffice.org, so lets set those aside for a moment. I am not sure how well this approach would work for a large application like this.
However, most of the little programs people want to use are easily done in two parts. Doing this splits the work in that the geek developers can get the technical part done. Nothing really gets in the way of their innovation because they can leave the equaly hard GUI development to others.
Distributions, and corporations can build GUI interfaces that make sense without having to directly involve the core developers of the project.
Seems to me this fits in with both UNIX and FS/OSS core ideals.
Re:We should be able to solve this (Score:3, Insightful)
Sure for some of these things there are worka
Maturity (Score:4, Funny)
They have a pill for that sort of thing now, you know. Technical problem indeed.
Speaking Heresey (Score:4, Insightful)
Many have you say, "Linux isn't any harder to use than windows/mac." That my friends is a lie. Still many more of you say, "Linux is almost there!" Again, I say that is a lie. I know! I have been using Linux since 1994. It has suckethed in the past, and it sucketh today. Has it improved, yes, but it is still quite bad. While I can only speak for the state of GNOME, I can say that it is actually becoming harder to use in the name of useability. How you ask? Why the file chooser dialog has no filename entry. Support for typing filename or URIs, things that have been included in everyone of the filechoosers ever developed is hidden under arcane keystrokes and even then lack the support of 2.4. Abilites that distinguished the GNOME desktop from others have been removed in recent years inorder to make it "more intuitive", which is merely a synonym for "poorly cloned in the broken in the way of Redmond".
The linux user experience is one of confusion and inconsistency. Applications don't look the same. Applications don't behave the same. Applications having improper interface criteria ("Edit|Preferences"? Why would I look for configuration details in the same menu that I use copy, paste, and search the text in?) Installing packages leaves them unconfigured, or configured with broken defaults. Too many times, the user is forced to enter commands at the terminal, or edit cryptic configuration files. Things that should be automatic aren't.
I postulate that this situation could be be resolved with a two pronged approach. First, a distribution that doesn't try be the One True distribution with every conceivable package in it. It should have one desktop environment, one office package, one media player, one emailer, et cetra. In short, one and only one of every software type. This simplifies package configuration, and enables almost complete autoconfiguration.
Secondly, all the user applications must be tightly integrated. There shouldn't be a mixture of say Gtk, GNOME, wxWindows, and Motif applications. All applications be of the same toolkit and of the same desktop enviroment. This will help make the user experience more cohessive. Unfortunately this isn't enough either. There has been developments in some of the required software that seem to be actually detremental to the user experience. Either a new enviroment will need to be developed (*bleh*) or perferably patches against an existing enviroment/applications developed. (Think Ximian, only not based on a cult personalities.)
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.
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.
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.
There's no such thing as 'intuitive' (Score:3, Insightful)
To achieve usability, I find that it is much better to focus on a few things:
1. Simplicity. It helps a lot if the application simply does what it says on the packet. Please note that simple is not the same as 'not advanced' - it just means that it does what you expect it to do. An electric drill is simple, even though it is a complex piece of mechanics - a Swiss Army knife with toothpicks, saw blades, compass and that pointy thing you can't figure out what is, is not simple, even though it is just some bits of metal stuck together.
2. Extensibility. When you have learned the basics it should be possible to add things in one way or another. Again, the function of an electric drill can be extended little by little as the owner gets more competent and/or wants to do more.
3. Discoverability. It shouldn't be necessary to learn-by-guessing a new ideographic script in the form of icons. This means there has to be documentation and a help system - and preferably one that isn't limited to some moronic context sensitive help. It's amazing so often you need to do something out of the immediate context.
4. Configurability. Quite contrary to common belief, people actually want to be able to customize and configure far more than developers want to let them. Yes, in the first few hours too many options may be intimidating, but very soon people get over this and want to make changes. Some applications manage this by providing more than one configuration interface - one simple, where the system sets a lot of defaults, and another where you have full access.
Some might think that these things conflict with each other. Like, how can it be simple, if the user can configure a million parameters? Well, provide sensible defaults, of course, so people are not forced to learn everything at once - but another thing to remember is, that a simple tool is also one that is adequate for the task - if you have to configure something that by nature is complicated, then the tool has to give you access to that complexity. As Windows so abundantly illustrates, it can get very complicated if the configuration tool is inadequate; and in Windows you often come across the sort of tool that is too simple, but at the same time cumbersome to use, where it would have been so much easier if only the configuration has been kept in a simple text file, and you could use a simple editor.
Comment removed (Score:3, Interesting)
Re:not really (Score:5, Insightful)
Open Source stuff could leverage that familiarity by create exactly the same sort of interface with all the advantages and disadvantages it provides because that would at least be familiar to the Joe Average user.
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 p
Re:not really (Score:5, Insightful)
Why is it that the first reaction of some people here is to make an excuse?
A UI that is intuitive to navigate is getting more and more important. The reason why Windows is and has been the way it has been since its conception is tha commercial companies don't like to rock the boat. I'm sure MS has come up with tons of ways to improve the Windows UI, but implementing these changes may in their eyes, upset too many customers who are used to it. I still remember certain people getting upitty when the taskbar and Start button were added in Windows 95.
Free software, OTOH, has quite a bit more maneuvering room in this area.
For GUI applications, the UI layout is can no-longer be considered by programmers as the sole kindom of the {Photoshop|GIMP} guy sitting over there and pass all worry of it on to him or her. Just as programmers want good APIs in their code, the Human -> Computer "API" is just as critical to good and satisfactory program and user function.
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.
Re:not really (Score:3, Interesting)
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:5, Insightful)
No, I assume what he means is that if MS, with all its resources, has a hard time in the only area where they seem to make a serious effort, then it must be a difficult task.
Another issue I think needs to be discussed is the way people's biases influence UI design. Some people, especially younger users, seem to think GUI==good automatically, and thus, the more eye candy a UI has, the better it must be. Conversely, they think that a less graphical interface is automatically primitive, and that anyone who criticizes excessively flashy interfaces must be an old fart pining for the days of punch cards. Such people will see lots of eye candy and get a warm fuzzy feeling, and will think that UI is "easier to use." Even though all the stuff just gets in the way, and he has to go down through 4 or 5 levels of menus and/or screens to do the simplest thing.
Unfortunately, such people seem to dominate UI surveys, and UI designers get the message. The result, for me, is endless frustration as the UI keeps trying to "do things for me" and I keep having to hunt some setting down in the dungeons of the preferences editor somewhere to turn off yet another annoying feature.
Speaking of which, does anyone know how to tell XP to stop rearranging menus and/or hiding half of the options? That's such a PITA -- who the hell thought of such a moronic thing?
Re:not really (Score:5, Informative)
http://www.microsoft.com/windowsxp/downloads/powe
[OT:] I also really, really like the desktop manager. Virtual desktops are one of my favorite features of Linux and it's really nice to have at work.
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:5, Informative)
Most likely a flawed "usability study" which said people want less complexity. But taking something complex and leaving it complex while hiding the options to be "discovered" at some random future time is not really reducing the complexity: it's increasing it.
To speak practically, here's what I do every time I install XP (I'll be thorough since I've already done it, so I'll just list the options the way I like them which shows the most information):
Right-click on taskbar, Properties.
Right-click on background, Properties.
Hit WindowsKey+E (to start Windows Explorer).
That's all I can remember, but then there are also settings within applications that you'll want to remove, such as in Outlook XP, select menu item Tools, Customize, Options tab: check "Always show full menus". Other applications will have similar settings.
I hope this helps. I would bet that these are all Registry entries somewhere; perhaps if I have some downtime (ha!) I'll make a .REG file out of these so the next time I set up a machine or VM I can just double-click the .REG file and be done with it. Enjoy!
Re:not really (Score:3, Informative)
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
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
Re:not really (Score:3, Insightful)
Agreed, way too many programmers make excuses.
A good, basic GUI interface is not hard, it is easy. Too many programmers won't even spend the hour it takes to design. They incrementally add cruft for months and then wonder why the hell everybody complains about their program. It is a real shame the number of freeware programs out there where the programmer spends months on the code and seconds on the user interface. What a waste.
All they need to do is keep in mind one simple fact:
Will the naive, lowest
Re:not really (Score:5, Insightful)
No matter how shity Windows is, one thing you can't argue is it's ease of use.
Anyone from a five-year-old to a WWI veteran can sit behing a Windows PC and be browsing the Internet and checking mails in no-time. (mind you, i'm not arguing the risks of this)That is what OSS should try to learn: simplicity. Average users like it simple and straight-forward, and IMHO that's *one* of the reasons for windows success.
--Just as important, the average user is by now used to the Windows interface, and it wouldn't be that bad of an idea to give them the power and strength of OSS with a windows-like interface which they are more comfortable with.
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:3, Insightful)
That's what the Start Menu is for. Not to mention apps don't "open on the left" any more than they "open on the right".
Microsoft maximizes windows to full-screen. Apple maximizes windows just large enough so that you can see everyt
Re:not really (Score:5, Insightful)
Most companies I work for as a contractor consider the UI design as an afterthought, an unwanted burden, or a mere exercise for the programmer who was assigned the interface screen. The development managers have been hardnosed pragmatic guys who see no sense in spending their budget on any 'needless' items like psychology and design of a proper UI. These clowns also see no sense in developing state diagrams for the control flow on interfaces. The result is often interfaces that have unlearnably convoluted navigation. This is just unforgivably bad design practice. Sometimes I have to state chart the UI to prove that the interface is broken and bad. I often see interfaces that dynamically change their functionality - same screen, but buttons and selectors come and go depending on the state, new navigational connectivities invisibly appear and disappear - all of which confuses the hell out of users.
See, a user first encountering an interface has to build a mental model of meanings of objects, control flow/states, and navigation. Your goal as a designer or programmer is make the UI design easily learnable and usable. That's both a science and an art.
I've also seen far too many UIs employing flashy objects that interfere with the readability. I don't care if a button looks like a 3D gem, if I can't read the friggin text label quickly and easily under the gloss, it's a failure. Yet I've seen $6 million corporate software with unreadable browser-based interfaces apparently designed by a 16 year old Web designer with attention-deficit disorder.
Visual readability, learnability, ease of understanding navigation, three major rules.
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: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 do
Artists aren't necessarily usability experts... (Score:5, Insightful)
What is needed is a consistent, predictable interface across all of a desktop's apps. In practice, this is a lot harder than just making it look pretty.
Re:Evolve (Score:5, Insightful)
Skinning has done more to ruin usability of applications than anything else the last 10 years. Skinning has absolutely nothing to do with usability, it's purely visual customization.
Throwing out the menu/window paradigm is a very bad idea, as you get rid of the only thing the user will be able to re-use from other applications in yours.
I haven't read the article yet (on my way there now), but the parent poster has no idea what constitutes good UI, and shouldn't be modded up. I assume the article has more sane advice.
And yes, IAAID (I am an interaction designer).
Re:Evolve (Score:5, Insightful)
Artists give us interfaces like ATI's TV recording software. All flash and no function. The more artistic freedom an app gives to skin designers, the more time I have to spend squinting at the cryptic emblems and trying to click on the 3-pixel-wide "play" button. Look at an old version of Windows media player (before v6), and marvel at how much easier it is to use than WMP 9 or Winamp 5. It uses the same widgets as the rest of the desktop, so you don't have to spend any time at all trying to decide where to click to activate each button. Artists understand what looks good, but very few of them have a grasp of what's easy to use.
It's better to write everything for a standard set of GUI widgets, and provide a mechanism for theming those standard widgets to look cool. That way, all your apps look consistent, and you can change the look-and-feel without having to re-learn all the interfaces.
Re:Evolve (Score:4, Insightful)
Presentations went through a similar trend. Thanks to Powerpoint (mostly), the emphasis shifted from conveying the essence of your ideas simply and succinctly to making things pretty. It really was due to the laziness of audiences: if your slide had lots of colors, then it must be good -- they weren't really paying attention to it anyway.
My advisor got into that trend. It started when he told one of the grad students to add some color to the slide, which was a block diagram. "What color should I add?" was the somewhat sarcastic response. It didn't matter; any color would do, as long as it was exciting. (No, there were no differences between the blocks that could be expressed by color.) Then he had some of our undergrads do some presentations. One guy went wild, throwing in pointless animations and sound effects that did nothing except show off his Powerpoint skills. But then the advisor started encouraging this from everyone.
Fortunately, most people didn't go for the over-the-top stuff, but they still would do things like put shadows on boxes in block diagrams, even if that meant using smaller boxes, and therefore smaller fonts for the text. So who cares if the people in the back can't read your slide -- it's pretty!
Some of the best presentations I saw, BTW, were by someone who was giving an extemporaneous talk, and was drawing diagrams with a single marker on a clear sheet.
Re:Evolve (Score:4, Insightful)
When contemplating a paint or sculpture from Picasso, you may be there and think for minutes trying to understand what Picasso was thinking while doing this paint/sculpture.
So, I don't really think you really mean artists, but rather than designers. That's not quite the same.
Re:Evolve (Score:5, Insightful)
Usable doesn't mean pretty. Pretty doesn't mean usable. Artists can add aesthetic polish, but if they don't know anything about usability, they'll just make the problem worse. Look at Kai's Power Tools or the various other applications that try to look happy or fun but end up being totally non-standard and difficult to use.
Skins are not a solution to usability. Skins are a punt. To me, skins represent everything that's wrong: the software developers doesn't feel like spending the effort to time on design and doing usability testing, so they throw on a skin system and let the user deal with it.
How many users actually go create their own customized skins? And most skins out there usually cater more to aesthetics than utility.
Plus, there's the perpetual problem where every application has its own skin, and nothing is consistent with anything else. If necessary, global themes should be used for personalization; per-application skins are a mess.
Good lord, no. Please, please don't reinvent GUI widgets. Lack of consistency is one of the problems, especially in the OSS world where there are a zillion and one widget toolkits. Do you want a dozen different textboxes where some of them allow copy/paste and some of them inexplicably don't? Or maybe some of them can't handle Unicode, or maybe some of them don't have keyboard shortcuts to select text, or who knows what else.
Standardize. Stop bickering, stop wasting time reinventing things, and then everyone can focus on real usability issues.
Re:yeah, look at xcdroast... (Score:5, Funny)
If there is one thing in this world that doesn't need useability improvements, that would be it...
As the quote goes:
"The only intuitive interface is the nipple, after that, it's all learned."
Re:yeah, look at xcdroast... (Score:3, Informative)
It's not actually true - some babies have to be taught to suckle.
Pretty much all of them need some training, in fact. The rooting response, which is what causes them to seek the nipple when something touches their cheek, is instinctive, as is the sucking action once they're in place, but they have to learn how to latch on to the nipple effectively. They actually have a much easier time with the longer artificial nipples, a real breast requires them to open their mouth very wide and to place their lips
Re:Common User Access (Score:3, Informative)
Horrible idea (Score:3, Insightful)
This sounds quite reasonable, and honestly, I probably would have tried something like this if I hadn't seen what it does.
It's actually quite a horrible idea.
The problem is that much of the time, very popular applications make interface mistakes that then get propagated.
For example, Microsoft regularly "b
Re:The real issue at stake here? The File System. (Score:3, Insightful)
What you're commenting on is the Unix vs Microsoft way of handling files/folders. And if your argument is intiutivity: take a look at Mac OS X, it's also based on the / structure. Some things a