Slashdot Mirror
Software Usability As A Technical Problem
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.)
Windows has a rather counter intuitive interface, and I'm sure it is rather well funded. The menu is very slow to navigate, and can't really be customized. The desktop is clutter waiting to happen.
Isn't this synonymous for saying that the market for computer software has grown so much that all sorts of people are using it?
I are winner
Well i think it is true but companies like red hat did some pretty good stuff like their blue curve theme for Gnome, I mean I love Gnome, I love the spatial nautilus (in term of usability it is just a dream for me) but the default theme for Gnome that i got in Slackware was a drawback in comparaison.. I love bluecurve
How is this much different from this article posted just four days ago?
Ford Prefect: No, but I've got a different name for the problem.
- The Hitck-Hikers Guide To The Galaxy.
The OSS community needs to attract artists to the OSS movement. Attract artists. Hand over your tools to their creativity and allow them to go wild. Write your software so that it can be expanded with skins, and visually re-configured ad-nauseum by the user. Throw out the existing menu/window paradigm and think beyond what you've grown accustomed to. Write your own GUI widgets instead of dragging and dropping something from your existing library. A technical solution doesn't need to guide the application to a solution of usability ... but it should provide enough flexibility so that the users can evolve the application to a usable form that fits precisely their personalized needs.
I had to walk a newbie through it's UI the other day to burn an ISO - damn, talk about a UI that needs an overhaul. don't get me wrong, it's all I use when I need a GUI burner, and I'm responsible for burning all of our code and apps for distribution, so I like it, bu tit could use some...useability.
But don't get me started on the apps we produce...blech!
BFCB@$
free ipod and free gmail!
Software should be designed, not just coded. And interface must be part of the design.
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.
Have you read my journal today?
All of the technical skills in the world are useless if the programmer doesn't understand what people want (or at least would like). ... machines that people use everyday, such as TV remotes and their "Recall" button (kinda like alt-tab), can teach us things).
However, it is very expensive and difficult to really understand how people use things. The solution, I think, starts with taking user-friendly interfaces from other products (and not just software
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.
I subscribe to the tenant, "Your application should look like the standard applications in your environment." If you are in windows, make your application menus like Microsoft Word as much as possible. I seem to remember IBM came out with a standard called Common User Access which essentially boils down to this.
I am a user of software, and the interface I've come to use more than any other for my professional work is vi.
From my perspective, OSS has no user interface problems. The interfaces I use are first rate - mostly that's why I use open source software. A good UI is something that can only be judged from the needs of the people that use it.
I'm assuming by "attract artists" you mean hire artists to create the user interface, not leave the interface up to the user.
I are winner
Linked article seems more like a rant to me. There are usable applications under KDE (and it seems the whole rant is about KDE, rather than other WMs). In my experience there are perfectly usable and - dare I say - simplistically beautiful UIs for many applications, such as k3b, firefox and thunderbird. In fact, I've yet to see a more user friendly application than k3b. Kudos to its developers.
Caesar si viveret, ad remum dareris.
See KJofol/Winamp3, and Trillian among others. You've got dozens of very beautiful skins for your apps that are a bitch to actually use. Visual beauty while nice does not a usable app make.
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.
The author alludes to the real problem with usability and open source when he comment about egotistical mailings on the newsgroups.
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.
but I think that far and away custom commercial RAD built apps have the worst interfaces I've ever seen in my life - and this is most of the software people are using at work. COTS closed source software generally has a pretty polished UI, but everything i've ever seen built with RAD tools sucks so bad they couldn't ever sell it on the shelves. I'm not talking about nit picks like interface clutter or where the "File" menu is, but about shit like "make sure you put a trailing "@" sign on all time sheet queries run not on the current month" type crap or queries that fla because there was a "rogue whitespace" in the input (yeah you all know what I'm talking about). I'm talking about horrible kludges in the back end that seeped into the UI because people are just plain fucking lazy. How come no one ever complains about this stuff? From where I sit, this sort of shit makes the UI problems of OSS look like a non-issue.
Most Free Software actually has a very well designed and thought out UI, it's just designed with people who are willing to read in mind.
I like this quote from the article:
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.)
No really. I have an itch. I write some code to scratch it, however the hell I see fit. If you want to use it, go ahead, if not, don't, I don't care.
Now where the hell do you get off telling me how to scratch MY itch?
My day job is writing windows software, and I can tell you that usability is not something that can be unilaterally called a technical issue. Some usability issues like response time and the ability to access various features through more than one interface (e.g. menu, keyboard and context menu) can be stated as an issue and specifically checked off as completed. Engineers like this kind of thing. Other usability requirements like "good menu layout" and "clear feature separation" can't realy be quantified like that, which makes them difficult to manage.
Let's talk about applications. One glamourous example is GIMP.
In my job I do a lot of technical documentation and I like when my work is pretty and easy understood.
I know I can get almost any task done with Gimp, but I also know that if I use Gimp I dont get my work done - simply because the interface is too difficult.
There's nothing wrong with advanced interfaces but rocket scientists should not have to have the skills and experience of Technical witers in order to document their project.
The issue is not that those people don't exist -- it's figuring out how to attract them to projects. This goes two ways: a) code monkeys need to figure out how to incorporate their input, and b) they need to figure out how to join up with a project and contribute in a meaningful sense with something other than patches.
OTTOMH (off the top of my head) perhaps one way is to create "team of two" submitters. Pair a UI coder closely with a UI "critical thinker".
Comment removed based on user account deletion
A nice, usable, set of GUI guidelines for OSS would be positive for the adoption of linux by the wider community. But that doesn't mean it's necessary. Sometimes I think OSS developers/users/zealots forget that it doesn't matter how many people turn away from closed-source software, it is the fact that some people get a benefit from it. I think that the best solution, at least from my point of view, would be to create a standard framework for coding applications, that would then allow all users to use a drag-and-drop interface to connect to the various features of the application. Sure a default layout would be provided, but all elements could be easily moved around and connected/disconnected from the backend without ever seeing the code. This might be too much to ask for at the moment, but I think it would be a step in the right direction.
I agree with the overall objectives outlined in the article -- a respoitory of usability recommendations, teaching tools and manuals, etc -- one thing that open source development offers is the ability to get user input early in the process. Open source development tends to be more incremental and open to review at early stages, and this offers the ability to get early user involvement.
I'm responsible for the IT department at my company and have had ideas for certain tools in mind. The developers are excellent and can put together something usable. However, by involving end-users early in the process, we've been able to develop applications that are tailored specific to the industry's needs. Not only the direct end-users, but potentially offering the applications as services to customers.
Open source has a better potential to evolve more usable applications IF (and that's a big IF) developers can target communities of end users early in the process and seek their "non-technical" input. Some of the larger projects out there (and I won't name names) suffer usability issues precisely because they do not have that kind of end-user interaction; they tend to be fiefdoms of a select group of developers who know how to code, but lack experience with diverse groups of end-users. Even those users with little coding and systems knowledge can be quite beneficial to making software usable by the masses, precisely because they lack technical expertise.
are when software has multiple, seemingly redundant menu options, and when software behaves in an unexpected and (relatively) unexplained manner. I base these observations on my mother, who has difficulty programming a microwave. She's not by any means an unintelligent person, she's just not technologically inclined, and some of the things that we Geeks absorb and automatically 'get' give her more trouble than my teenage siblings.
I wholeheartedly subscribe to the theory that if my (mother|grandmother) can use it without any more assistance than usual (troubleshooting and the like), it's a generally well-designed product.
Maybe I missed the point, but this seems to be an article that says, "This is the problem we all know about. The solution is to fix the problem."
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!
i speak this from experience: there are 2 kinds of good graphics designers: 1) those who have a real job; and 2) those who work a starbuck (or other coffee shops) Those who have a real job, make way too much money to care about OpenSource stuff. And those who work at coffee shops don't have enough time/money to spend on OpenSource stuff. Both of these types don't have time to write HOWTOs on good User Interface design.
Consensus is good, but informed dictatorship is better
Does anyone know of any applications that are nativly voice activated (other than games)? It would be kind of cool to have "voice activaited dialing" in a browser to go to your bookmarks, or lets say a voice activated calculater. Once those apps become more standard, we can think of doing more complex tasks.
who | grep -i blond | date cd ~; unzip; touch; strip; finger; mount; gasp; yes; uptime; umount; sleep
Stuff that matters.
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.
[% slash_sig_val.text %]
The article rips on someone who named a menu item captioned "smbUmount"... no doubt it's perfectly usable for the guy that wrote it. Why would he stop and "fix" it?
People who want to scratch their itch in ways you'd like to watch are rare, companred to people who just want to scratch in front of you. We'll have to avert our eyes from much of hobby-written software forever.
"Consider yourself a member of a virtual corporation with Mr. Torvalds as your Chief Executive Officer." - Linux Advocac
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.
Hmmm, RTFM eh ... reminds me of RTFA. You must be new here. Otherwise you should know that people don't RTFA. Hence, your comment gets modded as Offtopic. Remember, moderators are very, very quick to use Offtopic the second they don't understand something.
Next time, remember to quote the section of the article you are refering to. Like this:
Discussions on our usability email lists are noisy, full of anecdotes and not so humble opinions. We cannot tell each other to RTFM (read the fine manual) because there isn't one.
Saying that this block is 'from the article' or something doesn't hurt, either.
Peace out.
I've tried to switch over several times, and I just can't do it. KDE and Gnome get better and better, but they are still so different from the Windows I've been using for the past 14 years. I always have the same problems: I can't find things, wizards don't work properly forcing me to go to HOWTOs and the command line/conf files, and theres not enough integration between the window managers and X. I'm quite technically competent and I get better and better with Linux everytime I try it, but for the average user or your mother/grandmother there is still so much work to be done.
Yeah, nobody pays any attention to interface these days.
give up completely and retreat utterly into total nerdery. :-)
I am a developer myself, so this post is in no way meant to offend developers. However it's true that developers (generally) do not see things the same way that most users do.
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.
Blender And Linux Fan
In the Inkscape project, a lot of attention is placed on usability. As just one example, there are a HUGE number of keybindings for every important command. More importantly, but harder to quantify, is that the 'workflow' has a nice feel to it; as one user put it, "when you need some capability, it's just there where you expect it to be; someone else has obviously been there before me." There's several reasons that I think we've had some successes on this count. First, one of the core developers puts a *great* deal of thought into usability and how he can make it easier for him to use; he is a professional artist as well, and uses Inkscape on a daily basis, so he's definitely scratching his own itch here. Second, we place a lot of importance on what users suggest. We treat usability issues as no different than any other bug, and when a user has an issue trying to get the app to work smoothly and intuitively, we try to address that. This let's us take advantage of the adage "with enough eyes, all (usability) bugs are shallow". Third, we avoid pre-judging suggestions and instead encourage trying out ideas in the codebase. Instead of debating whether a feature would or wouldn't improve usability, we simply apply the patch into the development tree and let everyone try it out. Fourth, we include detailed tutorials with the application, and I think that's helped a lot at explaining how to use the program and what some of the obscure terminology means. Tutorials are a lot more palatable than a dry reference manual, especially when nicely illustrated with SVG drawings. :-)
Bryce
Is it just me or are video games way ahead of other apps on user interface? These days most people can pick up a game and given the general type (fps, driving, rts, rpg) have a pretty damn good guess at the interface. It's not that the game authors have agreed on a standard interface for each genre, it's that they've figured out the things that frustrate new gamers the least so they enjoy the game more with less manual reading. When was the last time you had to read a game's manual to actually jump in and play it? I mean just the basic playing around, not the detailed stuff.
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.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
It's alot easier to take a well designed software and give it a pretty GUI later on when priorities better permit than it is to take a pretty looking software and make it well designed after the fact.
if the user doesn't like the interface, just beat them!
Apple's Human Interface Guidelines is a good place to start, and is online for free.
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.
-- Cerebus
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)
Remember Homer's car?
Forget thrust, drag, lift and weight. Airplanes fly because of money.
I feel that part of this problem is that the colleges (and the students and most everybody) do not feel that any of that stuff is necessary - a "roundedness" in education is no longer what people want. They want a degree that gets them a job making money. Of course perhaps that's the way it's always been and I'm just getting old.............
Vote Quimby!
The OSS community is fragmented, and values "do it yourself" too highly. Developers don't ASK for designs (other than skins and icons), and they ignore any interaction designs you offer them. I'd like to see that change, but honestly, I see little hope. There are very few people who can both design for the user AND implement the design.
[
Actually most users have an idea of what they like/dislike in a UI... I like to encourage users to criticise things like the layout of buttons, how to do stuff, etc. If someone does the wrong thing because a step is ambiguous, or worse can't work out what to do next, that's a UI bug, and should be fixed (and remember even the command line has a UI... used by different people perhaps but their input is just as valuable).
Over time the complaints/suggestions drop off as most people are happy with the way things work (take careful note of the experience of new users as they can often bring up things that you've missed).
OSS helps here as you can release development/prerelease code every couple of weeks an tweak until it's right. Commercial projects are often tied to release schedules so can't do this.. but then they have the money to hire profesisonals.
The real key to Good UI design is consistency. Many open source projects have unfinished features, differing UI conventions and throw the user curve balls. This can be expected for testing and non stable releases. However any release labled stable build or 1.0 and so on should have a clear consistent UI and NO I repeat NO unfinished features.
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.
The real question in my mind is how badly the open source community wants to attract the average user. Admittedly, it'd be wonderful to have everyone in the world using a more stable O/S, but that would cut down on tech support calls :)
Truth is, I don't want everyone using Linux; it leads to more probelems than it's worth. I believe it was one of Chrysler's engineers who said the Viper isn't an easy car to drive, which is good; not every 12 year old out there could steal one.
What software needs over anything else is complexity levels. For example, may the software out-of-the-box easy to use with no more then 10 features to get the basic job done. Then, once the user gets comfortable, they can get more granular options buy toggling to more advance settings.
The idea is to prevent "Feature shock" when using a new program. Yet, have it flexible enough for a user that is comfortable with a progrma and would like to explore into more option that are availabe but yet not enabled by default.
Note: ICQ takes the philosphy into account rather well with it's GUI.
Life is not for the lazy.
The people who are involved in OSS have outright contempt for those who 'merely' use the software and think that everyone should want to type things like to do their job - and that if they don't they're mindless idiots that aren't worth considering the opinion of.
...before it can compete in usability with commercial software.
The company I work for, generally sees Open Source as a good thing. But very often we choose commercial solutions just because they offer as a far better usability than those available for free.
Few months ago we tested OpenOffice.org against MS Office. We found out that OO.org was significantly slower than MSO, when running on not-so-modern hardware. Our users also found many problems in normal day-to-day usage. For example creating a document with a working table of contents was quite difficult for many of our users. With only a few clicks they usually managed to totally screw up their document.
Also OO.org sucked really bad in compatibility with MS Office. Almost all Word and Excel-documents our clients sent to us during that testing period, were displayed wrong. Only those with no embedded objects, pictures and tables, were displayed correctly.
I'm not trying to bash OO.org here. I'm merely trying to point out that it still needs a lot of work to become as good as MS Office is.
Attracting them isn't neccesarily enough. I like you, am more or less just a user. Are hard core coders going to listen to us? Look at the Gimp. It's an unintuitive disaster as far as UI. I've heard of people wanting to fix it, but the core team doesn't want it to be "fixed".
if people with money were provoked by the lack of perfect applications, it would be fixed. The thing is that perfect applications include high class usability or they in their own are "use-less".
..in sovjet russia
People with money can only afford making use-less applications as they will be able to sell complimentary usability improvements and training services as add on, but making the applications to include the perfect usability from day one for free in open source will kill the income and open source will be fatal to their economy.
yes the apps will be widespread and all users will be happy, but only until the vendor goes bankrupt, cause they've made it a financial problem to the provider and not the user.
mozilla firefox+thunderbird is a little bit different. usability is top notch. but mozilla is not just a browser, its a framework for applications, and making the applications will be tougher, this is where things cost money. follow the money, works every time.
my 2c.
"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.
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.
There is no need to use a SlashDot sig for SEO...
For the record part of my job is usability where I work, I do some architecture and software development also.
First All developers should read either "Inmates are running the asylum" or "About face 2.0" from Alan Cooper (Add Crossing the Chasm from Geoffrey Moore as an extras) The books go over why application desing including Microsoft/Apple etc, is so poor. And the techniques created to solve it.
The key he talks about creating user personas and scenarios. These are two key things to making applications usable the first personas is about knowing your user. You create the personas to identify all the characteristics of your user, including personality, quirks etc. The next scenarios, this is the scenes of how users will use the system.
I personally use scenarios (since learning about them in a graduate class) drawing cartoons scenes for how a user currently uses a system. This allows you to see the manual procedures and figure out how to improve them.
But one of the books shortfalls include the fact that not everyone can reach the "eureka" point to create a new interface, or iterface metaphor. Steve Jobs once said (paraphrasing) "To develop a better product you must not only be a good designer, but also understand the user to where you can replace them"
If you want to get better, the things to think about is not "how do we make a better start button" or "how do we name things so they are understandable" or even "what colors should I use" but "What is the goal of my user..." And the "wizard" interface I think annoys people more than anything else, how many times do you think you answered all questions, went to get a drink only to come back with another question to answer, but what are good ideas then..
Two quick examples for file management the goal of using a file manager is to find a file (often there are second goals aka opening it, copying it etc, but lets just look at finding) If you are searching for files, although a hierarchical system is the way we store information most people don't think in a structure with folders. Most people think about "I wrote the document about...." or "I was working on it yesterday...." - Ok now for all the geeks who said well the user should name the document so they remember, or you can sort by date... you don't grok it. I should go to file-open and say "show me all documents i worked on last week" or say "show me all documents about the sucess of cell phones" and see that list.
The second thought the goal of using a word processor is to put down my thoughts on disk. First Anything I type in I most likely want to save, and often most of the older version i would like to see. If I close word, it should save automatically, if i did not save it, don't ask me. and also, save everything in a format in the file with all versions.
Believe me this is the tip of the ice berg. Cooper is one of the people who i think is moving in the right direction and his books detail a lot of things wrong. The first step to me would be sitting down and watching a newbie work, watch him work on his current OS (Windows, Apple etc) and then watch him in a work in Linux. Get to know their goals, and then build the interface for them.
The author lost all credibility there. I've found OSS to have unbelievably superior interfacing to most other software (excluding the UI wonder that is OS X).
Next thing they will tell us that BeOS was laggy.....
With constant advances in speech recognition, I wonder why this technology is so slow to integrate into the operating environment. What would be wrong with incorporating speech recognition. "Mozilla, go to google, search for boobies"
A friend of mine went through alot of effort to get his racing wheel to be able to control his mp3 player, so he could just spin the wheel with his foot from his bed and not have to get up to change tracks.
:P
Someone once told me "The two required qualities of a successful programmer are laziness, and hubris."
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
I really don't get why more developers aren't eager to create much more powerful user interfaces. Personally, I consider something not finished if it doesn't have as much power as I can pack into each simple button and operation. I *enjoy* making stuff both simpler and more powerful. That is the real challenge.
Right now, I'm working on creating a new type of development tool in which a working app consists of different types of 'blocks' are dragged and dropped into place and connected graphically with with 'pipes' via the graphical editor. Imagine data as a fluid moving through a pipe with 'decision' logic blocks, 'display' blocks, 'input' blocks and 'output' blocks to regulate and direct its 'flow'. A real working app looks a little a computer flowchart. Sure, an app created this way is less efficient than one coded in assembly but I want to create something that will let 6 year-old-kids create a working gui app on their computer and I don't get why more developers don't want to go in that direction. The hardware is getting much more powerful every year and yet the design and configuration of software seems to reflect the hardware capabilities from 10 years ago. I would rather have software that pegs an Athlon64 CPU and needs 2+ gb of memory if it provided the ability for people to do new things with computers that they cannot do now.
Having a huge variety of "skins" available does absolutely nothing to help make a UI user-friendly. It's only eye-candy, nothing more. I can have as many cool looks to WinAmp as I want, but none of them let me fundamentally change how I use the program, make the buttons bigger, alter how I select music to play, etc.
Make it easy to find out how to use the program. Intuitiveness is largely a myth, but discoverability isn't.
Here are my pet peeves:
(1) Context menus. Don't make entries disappear, dammit! Ghost them out. That way the user knows the thing is possible, even if it's not possible "right now". And you can learn their position.
(2) Icons (or 99% of all icons, anyway). Cryptic little pictures that might be meaningful to you, but mean jack shit to me half a world away. Except for _very_ well established standard pictures, you'd better put words next to the picture (and no, tooltips won't do). KDE menus and toolbars, at least with "text under icons" are _easy_. Humans invented language for a reason. Use it. GUI does not mean "no text". I prefer KDE to MacOS X mainly for this reason. Admittedly, I have a 1600x1200 display and don't have to worry much about real estate availability, but it is SO much easier to learn to use new KDE apps than Mac OS X apps because of this.
(4) Affordances. Make it clear that things are clickable. A simple bevel frame around a button might be ugly to you for some reason. But then make a prettier button, don't try and disguise the _fact_ it's a button and supposed to be clickable! This is the #1 sin of many a "skinnable" UI skin. Perhaps unlike many, I don't necessarily disagree with skinnable UIs. But then the skin needs to be designed for discoverability as well or better than an ordinary GUI!
(5) Undocumented "Registry" or text files for "advanced" configuration. The thing about such databases (_including_ plain text files, BTW), is that you lose discoverability. You don't know what strings are valid and what strings aren't as values. Editing text files is easy, and in some ways I like it, but NOT if it's not fully and clearly documented what values are valid and what they do.
So what's the problem with the GIMP's UI, and how would you fix it? I've never had any problems using it myself, except maybe for keeping the correct menu up when navigating the huge right-click menus in the image windows.
What apps and OSes need is scalable UIs - UIs that scale as the knowledge level of the user grows. A total novice, non-technical, casual users should be just as comfortable and productive as a hard-core, 80-hour-per-week developer. This has not happened yet because there are two distinct camps in UI development. Profits in the mass market drove closed source, mass-market software to create useability on the low-end. The natural interests and abilities of its contributors drove open-source to create useability at the high end.
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.
Two wrongs don't make a right, but three lefts do.
First step might, just might, be to drop the condescending crap like "Your average linux-using developer thinks that everyone else is as smart as he is".
Everyone else is as smart as he is.
> The OSS community is fragmented,
Actually they are united in sustained braindamage from using bad Unix GUIs for many years, and the almost universal belief that GUIs are "inferior" solutions for "other people".
Details such as good menu labels are just that, details. They have to be worked out, but first the structure of the program must support the goals.
Usability testing is a fairly good way to spot errors in desing, but tends to bring up problems in learning the program. It doesn't need to be fancy, get a user and ask him/her to accomplish some goals. We practived it with videotaped paper simulation. No large numbers of test users are needed. After 5-10 users (even less for small applications), the problems that are brought up start looking the same.
The are design patterns such as "give user an idea of the whole when looking at a part of a document (or whatever)", an example being the scrollbar that hints about the current position and the length of a document. A good book would cover these.
Designing good UI is not something that can be learned in 5 hours. I agree some good free (as in beer) book would be good. I think usability is a problem for open source, because even if an "expert" would give usability comments on a project, there is no guarantee anything significant will happen (and restructuring a program is significant). OSS people generally don't like to be told, "look, you have to code like this". I think the expert should be prepared to code himself, or better, that leading OSS developers would themselves be educated on usability and able to desing good software from the beginning.
A) Gnome/KDE/Microsoft have HIGs as well.
B) You can go to a Mac board and find numerous places where Apple ignores/violates thier own HIG.
C) The "deep" problem is how to design an application around the tasks the user needs to accomplish. A HIG about button spacing, menu design, etc doesn't really help you there. iTunes, for example, is a lot more than MP3 + HIG.
Ten things you can do to make your program at least tolerable for end users:
Building a really good UI requires a lot of time and experimentation.
A little knowledge does go a long way though - I'd suggest reading the Humane Interface(Jef Raskin), About Face 2.0(Alan Cooper) and The Design of Everyday Things(Donald Norman) for a start. They aren't bibles, but they contain a lot of ideas and ways of thinking about UIs that aren't obvious otherwise.
My favourite UI quote (from About Face 2.0) - "However cool your interface is, less of it is always better."
But to get a better UI would mean like ...., talking to users. Yukky.
From the article:
Bulls***.
There are numerous books and resources on usability. For example:
but discoverability isn't.
I don't agree that discoverability is necessarily a good thing to hold up as a high goal. I think that it tends to compromise other, more important things.
The most discoverable interfaces that I've seen (and obviously, this is an extreme case) is in graphics software produced by HSC/Metacreations. For example, in KPT Convolver, doing various things in the software periodically "unlocked" new features if it found you using related features. The problem? It was a pain for people that just wanted to use those features.
Microsoft puts a large emphasis on "discoverability" (much as Apple (used to) put emphasis on "intuitiveness"). I've largely been unhappy with the interfaces Microsoft has come up with. The problem is that they tend to de-emphasize the quick finding of an interface element for those people that *know* what they're looking for. For example, I know one person who wanted to run their "disk clean up" suite. The only way he knew how to invoke it was the obviously discoverability-oriented method of filling up the disk until a warning came up.
(1) Context menus. Don't make entries disappear, dammit! Ghost them out. That way the user knows the thing is possible, even if it's not possible "right now". And you can learn their position.
Moving context menu items is a bad idea. Sounds interesting, yes, but as can be seen from Microsoft's failed "smart menu" metaphor, learning something that can be re-used and everywhere is more important than the time that it would take if there was no learning and we were just trying to minimize seek time each time we use a feature. Do not hide menu items, do not re-order them.
(4) Affordances. Make it clear that things are clickable. A simple bevel frame around a button might be ugly to you for some reason. But then make a prettier button, don't try and disguise the _fact_ it's a button and supposed to be clickable! This is the #1 sin of many a "skinnable" UI skin. Perhaps unlike many, I don't necessarily disagree with skinnable UIs. But then the skin needs to be designed for discoverability as well or better than an ordinary GUI!
This is an interesting problem. Apple heavily considered this in their UI design, and thanks to the fact that they did so, people that copied Apple interface design largely had good interfaces for a while.
When the web came along, there were suddenly a huge mass of people, many of whom were graphic artists (not *interface designers*) who thought that "flashy" was appealing and equated to good interface design. And they made many, many clickable things that were not obviously clickable (the imagemap was one of the more commonly-used tools here). This is a pretty high sin in GUI design, where the goal is to quickly present all the available options to those people that are not yet familiar with what they are.
The solution came in the form of a technical fix -- rollovers. The designers could just make everything that could be clicked animate or change when the mouse rolled over it to designate it as clickable. This was a *terrible* UI convention, since it meant that in order to get a full listing of choices, one had to pan the mouse back and forth across the screen. Furthermore, the constant flashing and animation was extremely distracting -- normally, changing state on the screen is *rarely* used in UI, so that it may be reserved for cases where attention is immediately required, or where there is only a single point that requires attention that must be quickly located. The flashing cursor, for example.
Microsoft, in their "the operating system is like the web" days, when they were inextricably tying MSIE to Windows and worried about Netscape, unfortunately put some web designer type in charge of their UI design, and designed that rollovers would be *great* for toolbar buttons. They hid the dark outlines around the buttons that *used* to be the visual cue for something being clickable, and only made it visible w
May we never see th
Dare to point one, or is it only typical slashbot karma whoring ?
Attention Linux Wankers: You aren't "smart" because you have memorized commands, can edit your fstab, or installed Gentoo.
OK, I tried, nobody's listening. The "Unix Elitist" attitude is just a bit of braindamage that everyone is going to have to work around.
I have seen this interface used occasionally before (a Linux audio package, forget the name, and in Spreadsheet 2000).
It's largely useful when the main point of your application is configuring data flow, when the programs being written are fairly short, and when many people will look at your program (and thus an easily-read visual representation is valuable).
May we never see th
The first thing about simpler user interfaces is to change thinking from 'what features does this software have?' to 'what does the user want to do with it.' combined with 'who by the way will be the user of that software?' Once you have that in mind, it gets much clearer. You don't need any designers or usability experts. Sometimes, common sense is all you need.
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'll see the same user perform other tasks that seem clunky to me without any issue. I'm happy to admit - I should not be designing a UI. I don't have the training, and the more I learn about everything else, the further I get from "normalcy".
The NewsForge article flatly contradicts my opinion, yet offers no evidence whatsoever. It's nothing but cheerleading. "They say we need experts to design usable interfaces! I say we just need to try harder!! Rah! Rah! Rah!" Go on, write some HowTo's, file some more bug reports. But the whole point of the AC's comment (and mine) is that you have no point of reference for your solutions. The FOSS model is powerful, but it needs to face up to its limitations as well as celebrate its strengths.
It has to be the tenth article about OSS and usability that I see in a couple of months (and at least two were mentioned here on ./).
:)
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)
42.
No matter what you do or say, it is not a technical or engineering issue, inasmuch as car driveability is also not (mainly) technical.
You may need a technician or engineer assistance, but the main variable will always be "man" and not engines.
Start from wrong end and see how difficult is to proceed; start from the person and it's almost like skating down a hill... see my "No, no, no" comment on the linked Newsforge article page.
Good design (of anything, not just UI's) is actually not that hard.. once you get the trick.
.. I agree, that could be a good starting point too).
The trick is to keep things as SIMPLE as possible, while still making them flexible.
Another trick is to make design EGOLESS. The goal of good design is *not* to make the user think "wow, this guy is a great designer". The goal is to make the user not think about the design at all.
Both of these, for some reason, seem so difficult for the average developer (OSS or otherwise). I myself have only lately tried to unlearn all my bad habits and while I still have a long way to go, but I am impressed with the results so far.
Here's a tip: start with an EMPTY interface/screen. Think what is the SINGLE MOST IMPORTANT element. The "focus point" of the screen. The entire purpose of the screen. Put that element on the window. Now STOP. Don't add any more elements. Now write the code that supports that feature (keep the code as SIMPLE as possible as well, though that's a topic for another story).
Example: Maybe you're designing an MP3 player like iTunes.. what's THE most important part of it? My vote: the "play" button. It's a music PLAYer after all. The person is going to want to run the program and hit PLAY. (You might say, hey, why have any buttons at all, just start playing when it starts
So write a program that has a big play button, and nothing else. Hard-wire your favorite song in the program.
Now you might need a STOP button. But wait a minute.. do you really? Is there a *simpler* way to the music? That's right.. make the play button turn into a stop button when the music is playing (we aren't dealing with a physical thing here, the button can change).
Etc. etc. If you go very slowly and make a huge effort to NOT add new things, you will have a better UI design than the guy who crams all sorts of crap into the interface because "he thinks somebody might need it".
It's so much easier to fix a simple design that's broken than a complex one.
After you use your design for a while (you *are* using it yourself I hope), you'll feel "forces" that tell you what you need next. Maybe you absolutely positively need a way to load new songs. Maybe after trying to avoid for a week, you really need a rewind button. And so forth. Add new elements SLOWLY and make absolutely sure all errors are handled gracefully, all text on the screen is simple and clear, and confusing things are explained.
Simplicity simplicity simplicity. That's 90% of good UI design, the rest is experience which you may or may not gain in time (if not that's okay, someone else can come and fix the details in your simple design).
There isn't a word in any of Gimp's menus/buttons/actions/whatever that makes ANY sense to someone who's not already intimately familiar with software of that type.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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.
People who write code control OS projects -- understandably enough -- and other non-coder skill sets like documentation, lawyering, and UI design are second-class and after the fact or omitted completely.
Understandable because coders get you through times of no UI designers better than UI designers get you through times of no coders (apol to FFBros).
Coders are essential to having a project at all. Yet non-coders are essential to having a good project; or at the least, to getting a project out from behind the "geek curtain" and onto the desktop.
But convincing coders to share power will be very difficult.
To use a Ted Nelson analogy, how were camera operators ever persuaded to give up control of movie making? Answer I bet, probably not "persauded"; probably told by the guys who put up the money. Similar to commercial sfwr from good houses like Apple, where interface design is involved from the start because Steve says so.
********* below the fold **********
A very interesting persuasion situation. The coders are "doing fine" designing the interfaces just as they always have, and open source popularity continues to grow. The coding-driven social/political mechanism is in place and "working".
Sort of a prisoner-dilemma -- why take the much bigger risk of an unproven project structure for indeterminate gain?
Except that "doing fine" and "working" may be limited and self-fulfilling -- who knows how much better open source might be doing if interface design and other non-coders were a more equal partner in the projects? And one could in fact argue that open source penetration on the desktop is now interface-limited and will grow ever more slowly, having already saturated the subset who are willing to put up with coder-designed interface.
Probable that open source will never fully crossover to the desktop until doc, law and design are initial full participants in projects. Which will involve new way of organizing projects. In which UI critics will also have a place.
Any examples of or suggestions for alternate OS project organizational schema more friendly to non-coder contributions?
User interface design is one of my pet-peeves about computers these days (be it Mac OS, Windows, or Linxu--I use all three regularly). Every where I look I see bad design that doesn't need to exist. And it annoys the crap out of me that people won't put forth the extra effort to get it right. So here's a little rant on the subject.
As a computer science graduate student, I recently took a course entitled "human-computer interface." This course (at Eastern Washington University) was not really about how to make a GUI "look good" but how to make an interface (from something as simple as the knobs for the burners on your stove to a modern web browser) actually usable. One of the things I learned is that no matter how good programmers like myself think they are, they really don't know much about designing interfaces. There's an intense amount of work involved with it, and a lot of it is outside the fields most programmers typically work in (in particular, there's quite a bit of psychology involved).
There's a lot more to the human-computer interface than just how the interface appears visually. You also have to consider things like the mappings between intended actions and actual results, how easy it is for a user to determine how to perform an action, how easy it is for a user to determine the state of the system, how easy it is for a user to determine the results of their actions, and so much more.
One of the things I see all the time is interfaces that are designed for programmers and other techie types. Just because I know how to write my own Linux kernel modules doesn't mean the typical user of Program X does, so don't make the program require that knowledge unless absolutely necessary. Design for the lowest common denominator, not the greatest. If you make a program easy to use for the average user, then it will be easier for everyone to use, even yourself. (Remember: think of the average computer user (or person in general) and remember that half of the population base is dumber than that average person .)
There are two books I think most people should check out for more information on design and :
The Design of Everyday Things, Donald A. Norman, ISBN: 0-465-06710-7. Goes into much detail on design in general and why it is important, the process of good design, and offers great advice for improving designs and the design process.
User Interface Design for Programmers, Joel Spolsky, ISBN: 1-893115-94-1. Practical user interface design advice for programmers, for those too lazy to read Norman's book and learn more on your own (shame on those of you who would only read this book!). Also check out his blog "Joel on Software" at http://www.joelonsoftware.com/.
Finally, I'd just like to say that regardless of what most Slashdotters think of Apple, they tend to get the interface on their products right because they realize the importance of good design and are willing to spend the extra money, effort, and time to get it right. And this is a large part of the reason their products consistently win design awards and sell very well despite their market share. Look at the iPod for example, and compare it to any of the other hard drive-based MP3 players out there. Are any of them as easy to use? Don't think so. Are any of them as pleasing to look at? Again, didn't think so. Does it have the richest feature set out there (I'm looking at you, Ogg Vorbis supporters)? No, but it's still the largest in market share by a large margin. Because it's easy to use and you don't feel like beating it to a small pile of broken circuit boards at the end of the day because it was too frustrating to use. (No, Apple is not perfect and they do design bad interfaces and products, but they seem to be head and shoulders above most everyone else in their industry.)
Oh, and let me
I will back my own post up :-)
:-)
I am the perfect example of what I am talking about. I can code mathematics algorithms really well. That's what I am trained to do. I used to think I knew how to make GUIs as well. Then I got over myself
Now I freely admit that I haven't got a clue about building good GUIs. As the parent to this says I have become so involved in the technical ideas of my discipline, that I have no real idea what is and is not normal/intuitive etc anymore.
I can no longer look at GUI design with "outside" eyes, only with the eyes of someone entrenched in my own way of doing things.
I'm sure smbUmount made sense to the person that added the feature, but the problem is obviously that it only makes sense to the person that added the feature. But that's not even the problem -- the problem is that the UI process stops there. Further, maybe the problem is not that the UI process stops there, maybe it's that UI at this level is a development process at all.
Coders have always wanted to add something cool, then needed to put it somewhere so that a user can get to it. From the coder's perspective, the interesting part is done when the cool feature is done, the UI is just the plumbing between the user and your coolness.
If you want to turn this into a systems problem (which I think is a good idea from a consistency and usability standpoint), maybe the trick is to realize that coders will always be coders, and to make it possible for them to get the plumbing without just hanging something on a menu or inventing yet another command line parameter. Seems like we've figured this out to some extent with respect to loading drivers, so maybe we need to treat applications and features like UI drivers and make it so that you can't load your piece without providing the meta-data that the UI loader needs to put your UI where it belongs?
Maybe that would give someone a chance to design a consistent presentation, do some meta-data checking when application loading is attempted, and even automagically generate a feature request when an un-localized app is loaded.
Or not. I dunno. Seems like the choice is either bite the bullet and do it, or design the system such that you can ask someone or something who knows what they're doing to do it for you as easily as you can hack in something ugly by yourself.
Can this be done on a system level? What is the largest extent to which it is done already? Any notable successes or failures? Maybe you start with this premise and treat the other problems that pop out the other as the engineering problems?
It is not just a problem in the OpenSource world.
Either the writer is ignorant of the proprietary software business, including windows, or intends to mislead the reader and reinforce the "Open Source Is Bad" propaganda.
Many windows apps, including those from Microsoft have terrible graphical front ends which frustrate the user's efforts to use the application and too often wastes time. Often the front end is so bad that I wonder whether it was deliberately designed that way to torment the user.
And many programmers arrogantly force users into doing things the programmers' way.
(And then there are the "smart apps" which do their damndest to second-guess the user and often do things wrong or alter data without notice. Those who produce such atrocities should be hung by their tongues and whipped with a very high quality SCSI cable--but that's another subject.)
Many open source apps are indeed designed the same way. The interface is poorly designed, incomplete, or just plain broken.
What makes open source different, though, is that one can use the source and make the interface better, unlike windows and other proprietary stuff.
And, unlike Windows, support--if it exists and you can get to it before you collect Social Security--is not going to tell you that the software you paid for is sold as-is and since you bought it, it's your problem and if you want it fixed, then buy the next version--if it ever comes out.
I stopped buying windows apps because of vendors' attitudes. The last crap software was from MIPS, the business forms company in California before their software division was spun off into a separate company, who told me flat out that it was my problem (and implied that it was my fault) that their check printing software only pretended to do anything. Thanks to that statement from both their support and sales people, we no longer have any business dealings with MIPS. And there are many others we no longer deal with because of the same attitudes--such as SCO!
I prefer open source free/shareware that I can try first to ensure it works, is not crap, and is not a pain to use. If it works, I pay for it. I have no problem at all paying for stuff that works.
"ls -la |grep foo > foo.txt"
Well, how would you perform this task in a gui?
Using win2k, I can use the find button and do the
ls -la | grep foo
but you can't copy and paste the outputs into a text file (I have no idea how to automate the process either, though I suppose it's possible).
You're right that some people have a bad attitude about GUI-only types, but GUI bigots don't recognise that a GUI is a handicap for some tasks.
while a one-button system might work for a device, it does NOT make for good software. You have just demonstrated a very good reason why actual UI designers are an absolute requirement if OSS is going to move forward: even if you try to think of a good UI, and dont write any code at all, you wont know when to stop. You'll create crap.
;)
Good UI design doesnt come from the ass, it comes from working with things, talking to others who work with things, and improving apon them. OSS should be perfect for this, but we dont have any place for people to make UI suggestions, and we dont have UI designers who would be able to read, filter, and combine those ideas.
Nobody can come up with a good user interface. Everybody, on the other hand, that's a different story. The trick is finding out how to get everybody.
When you're talking about writing code, it's simple enough: It's open-source, send a patch.
When you're talking about using the product of that code, it's an entirely different matter: people who send patches probably shouldnt be trusted with their UI suggestions in the first place
-- 'The' Lord and Master Bitman On High, Master Of All
I don't know about you guys, but I have spent quite some time to make my Linux environment, including all the applications I use, fit my needs. Which is perfectly well possible with most (open source) software, by choosing themes, colors, backgrounds, menu-structures, panels, panel-utilities, toolbar-layouts, et cetera.
A lot of (less-geeky) people just can't / won't / should not do this kind of stuff. Therefore, I think this probably a job for the system administrators or distribution makers.
Open source programmers: Just make your program as flexible as possible (Like XUL)!
System administrators (with help of GUI experts) should make the GUI to fit the needs of their specific user group!
So, in the article, he mentions that many of these open source projects have a lot of "noise" (discussion) on the list. There are a number of Human-Computer Interaction analysis techniques which are based around discussion, but in a slightly more formal way. A first step the OSS projects could do is try to formalise their discussions a little, to make them more productive rather than just noisy.
For example, the Cognitive Walkthrough technique could be adapted to be done over the mailing list. A contributor who believes he has identified a useability issue could post a cognitive walkthrough analysis of the problem, which can be discussed and refined, and then used to come up with a reasoned solution, rather than a hacky fix.
Similarly, Cognitive Dimensions of Notations provides a common vocabulary for analysing the usability of software, and keeping the discussion to analysis using its terms helps to make sure the conversation progresses to a conclusion, rather than degenerating into noise.
If discussion and co-operation is what you're strong in, at least make it work for you.
Will
Everybody says how difficult it is to design the proper gui. I think that if a little common sense is applied, then guis can be functional and pretty at the same time. Here are some tips:
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.
- Not supporting resizing windows. I'll take resizing over skinning any day. It _really_ helps productivity if you can see all your information at once.
- Not using standard controls. They may be boring, but they get the job done and everyone knows immediately how they work. With skinned interfaces the controls are always a surprise. Even such simple things like closing the application may cause a hunt for the right "thingie" to click.
What is needed, instead, is to reevaluate the ways the standard controls are being used today. Quite often this will turn out to be sub-optimal. So look at your application. Is there any use of jargon? Are there context-sensitive helpbuttons? Does the help text actually explain the consequences and backgrounds of each choice, instead of just repeating the label on the button? How many clicks does the user need to change anything in the application, and can that number be decreased (if you have to select from a menu, then click a tab, scroll a list, click another tab, and then press "advanced" chances are you can improve usability). Is the window layout predictable? How about the consequences of pressing specific buttons? Are related controls grouped together? Are there redundant controls? Are inappropriate choices ghosted out? Is the layout visually pleasing? How about the colors?
But most importantly...
USE YOUR OWN APPLICATION. If something feels annoying to _you_, imagine how other people experience it! "Its fine if you know how it works" doesn't cut it anymore, we now have the technology to do considerably better than that!
Paul Robinson <Postmaster@paul.washington.dc.us>
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
Declarative, Interfaces. NOW
"Especially in the open source world"? No, I don't think so.
Aside from The GIMP, I can't think of a single featureful piece of (GUI) open source software (let alone commonly used pieces) that is "difficult to use" compared to many, many windows applications. Nero comes to mind, as does mIRC. I'm sure there are others, but I've not really been using Windows for years, and these are simply observations I've made by seeing others use their computers.
Both open source and closed source have their best-of-breed, and I'd say that the useability of Open Source apps is at least on par with that of closed source for this category. The lesser-known projects of open source would be, I'd recon, many times better than those of closed source. Many horribly designed, yet popular, projects on downloads.com come to mind.
If this arguement is made on the basis of console application useability, someone simply needs to shut the fuck up. It's not even a functional paradigm comparison. GUI tools serve an entirely different functionality type than console tools.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Actually, I did indeed start using Win3 (actually Win2 first) just because. I wanted to try something new, and I could get it for nothing by copying floppies from work. So I did.
Win95 I got the same way, except it was by copying a pre-release build CD from work, again to try it. I liked running more than one program at a time, but since I'd already gotten used to SunOS (unix by any other name) at my previous job, running more than one program well was something I knew could happen. Win95 ran them badly. No worries about copyright violations, when I was done kicking the tires I erased them and put Linux on the PC. It ran very well indeed.
I agree with you that capitalism leads to evolving products, simply because peoples tastes change constantly. What satisfies today is tomorrow garish or not good enough any more. You would like the writings of Ludwig von Mises. www.mises.org An economist who got exactly what you're saying.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
"As the quote goes:
"The only intuitive interface is the nipple, after that, it's all learned.""
If it wasn't? It would at least be the one interface, all males would be willing to learn.
to...
..
The new GTK dialogs absolutely SUCK.
hmm. constructive criticismon this crappy gtk 2.4 file selector: case insensitive sort the files, show some indicator of wether a file is a file, or a directory, and what type of file it is, filter for different types of files, rename "Filesystem" to something that makes sense (like 'root' or '/'), need a way to show hidden files/directories.. the system i'm on doesn't HAVe a cd-rom or floppy drive, yet those entries can't be removed
and put the resize/title bar back on top, where it is with every other window in the system
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Switch from windows to mac os, and you will find yourself in the same predicament of "having to read documentation".
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.
May we never see th
Bad UIs are not a problem puculiar to OSS. Good UIs are very rare across the board. From military accounting and maintenance software, to expensive commercial point-of-sale systems, to Fuji and Kodak digital print kiosks, UIs almost universally suck.
True.
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.
May we never see th
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Odd, it appears that > doesn't get translated to > inside <ecode> tags...
Guess I should have previewed.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I think there are plenty of people with those skills who would like to help out. The issue is that they would need to learn to code and become familiar with the internals of the project before they could actually change things as systems are done currently.
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.
"a good ui forms around the user"[1]
Body Glove GUI:
Wife: Does this make me look fat?
"not forceing the user around the gui."
Sadistic GUI:
Torturer/Developer: I said you're going to take this Form Field, and like it! Now bend over!
[1] The GOOEY in Demolition Man. Who needs airbags?
A) Gnome/KDE/Microsoft have HIGs as well.
Yes, and they may or may not be decent. No one knows, cause no one reads them. Apple's, on the other hand, are actually read.
B) You can go to a Mac board and find numerous places where Apple ignores/violates thier own HIG.
They are the Human Interface Guidelines, not Human Interface Laws. No one document can describe with absolute certainty how each situation must be handled. A good designer will take the guidelines as a starting point, and apply them to an overall vision as appropriate.
C) The "deep" problem is how to design an application around the tasks the user needs to accomplish. A HIG about button spacing, menu design, etc doesn't really help you there. iTunes, for example, is a lot more than MP3 + HIG.
And now your true colors show - you clearly have never even read Apple's HIG. The document does more than talk about button spacing (although that's there) - it also talks about the big picture. Now go read a bit and educate yourself before spouting off again.
Three major issues with voice:
1) Background noise. I have to ask people to repeat things in noisy environments, and I'm an organism that's very well adapted to speech recognition with stereo inputs and spatial processing. It's tough to expect a computer to do better. Existing computer interfaces are good for anything except an evironment where everything is violently shaking, perhaps.
2) Strain of continued use. I can type all day. Talking continuously all day long is a burden.
3) Ability to localize signal. If I'm using my computer with an interfact that broadcasts all over a shared medium (like aurally over a room where everyone must use the same environment to broadcast sound and listen), I run the risk of distracting other people, interfering with their own computer's speech recognition, and I run the risk of privacy issues (as people can *listen* to what I'm doing). I can pack people in a conference room and let them type on laptops -- having them all speaking would be very annoying.
May we never see th
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.
Although we can agree that designing a really good UI is hard and may involve non-OSS people like designers and psychologists, that doesn't excuse the numerous bone-headed decisions (like "smbUmount" above) that OSS developers consider "quick and dirty".
The real UI problems with OSS software come from the fact that hardly anybody bothers to do real usability tests - with real users - before the software is released.
User Interface design is just paying attention to the things that people say about the program. The more pissed they get, the better the feedback and the more room for improvement.
1. Use natural language words. No rn, ds, ect..
2. Add tons!!! of documentation. You can't have too much documentation.
Graphic designers generally suck at user interface design.
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.
May we never see th
"ls -la |grep foo > foo.txt"
....
I can do that in the Mac OS X finder no problems. Go to the 'find' menu, type 'foo' into the box. Wait a few secs and up comes a list of the files with foo in their name. Select all, copy, and paste into textedit.
Damn that's so hard
Now just to really push the point home. I had never done the above operations before I read this post. I read the post, and just did the intuitive thing in the OS X finder, and poof it worked!
ls -la |grep foo > foo.txt
I'd be facinated to hear exactly how you think this kind of incredibly flexible and quick-to-use functionality could be exposed in an easier-to-use manner.
Especially since a few modifications can make this vastly more powerful (say, use ls|grep foo|xargs grep shaman to search for all files containing "shaman" with "foo" or "bar" in their name. This sort of thing would take much more manual effort under, say, Windows.
May we never see th
"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.
"
Actually I would like to see this happen. Why? Simple really. How does evolution happen? By the long, hard, painful process of weeding out all the bad designs. How does learning happen? Through the long, hard, painful process of weeding out all the bad decisions. The silver lining is that in the end, people will both have a better design than they started with, and a healthy respect for the people who do, do this for a living.
I agree, everybody (with the exception of the really clueless moron) is as smart as the Linux developer, many people are just lazy.
Every generation has had things progressively easier for them, due to the increases in technology. As such, people tend to become a bit lazy. People nowadays are used to having things handed to them on a silver platter, with no effort at all.
(A bit off-topic here)
That's not to say that using a computer should not be easy. But at the same time, when you drive a car, you need to know to change the oil every so often, and fill up the gas tank, why shouldn't you have to know how to update your anti-virus software or secure your PC?
-- Joe
Are there any good guides or something for someone who is completely unfamiliar with that stuff. I can use MSPaint more easily than GIMP and then the little of Adobe that I've seen. I've been offered help with Adobe, but I'd like to learn on open source since their interfaces are different.
That is a nice bit of interface work, but it's also a single very simple instance of what can be done with *IX command line.
May we never see th
Very bad example, though. The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily
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".
Business. Numbers. Money. People. Computer World.
a "roundedness" in education is no longer what people want. They want a degree that gets them a job making money.
Screw both roundedness and job training. I say study what you like.
May we never see th
Anyone ever actually tried installing this thing? XDirectFB? I have been using various builds of unix for about ten years now and I still find this one of the most unfathomable processes available in software. :/ I had more trouble getting this going than setting up a full samba 3 domain with an LDAP backend and net rpc vampire setup from windows domain controllers all tested installed and working perfectly.
I think it's more an issue with the documentation, in that particular project though, it's just *not* there...
README
See docs for install
docs/install.txt
get cvs and build.
Like, wtf? :)
"Standardize. Stop bickering, stop wasting time reinventing things, and then everyone can focus on real usability issues."
What's a fake usability issue?
It's not the FOSS developers' contemptuous attitude towards end-users that bothers me.
What really bothers me is that they are as contemptuous as they are of end users while *simultaneously* yelling "world domination", proclaiming "Linux is perfectly ready for the desktop", and lobbying governments to force their software on the very end users who they treat so miserably.
That's what really bothers me.
Ergonomica Auctorita Illico!
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 that only a single line of context is required.
Really, I think the way most end users think about how to use computers is a negative result of the document-centric model. They don't think of data as really manipulable, because they're used to looking at a document surrounded by icons and menus that define the totality of what can be done with it. I don't know that that's really correctable without an inordinate amount of education, but I think that it's fallacious to look at the features provided by common apps and assume that anything not in the list isn't something people do often. It may very well be something they don't realize they can do, or wouldn't understand how to use effectively if it were given to them. But something that would be useful if they had it and understood it.
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).
I use both GUIs and the CLI, bouncing back and forth all day long, using each for the tasks for which it's best suited. I don't think either is inherently better for all common tasks (and, of course, the CLI excels at many uncommon tasks which aren't worth coding a GUI for).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
A whole lot of problems that GNU/Linux has today, and basically, always had, can't be solved at the UI level alone, the problems need to be solved at a lower level, namely for example the kernel itself.
Just take 'mounting' as example, no matter of UI goodieness will make the process of mounting floppies or CD-Roms intuitive, easy and problem free. People will always end up with jammed cd-drives, due to locking, floppies that get ejected before the write is finished and stuff like that as long as they need to mount their drives.
At the kernel level however the whole process of mounting can be made drastically easier with things like supermount or mtools (not kernel level, more kernel-circumvention level), the whole problem of mounting things almost automatically fades away. However supermount still hasn't made it into the standard kernel and so many people are still stuck with the process of mounting and inferior GUI workarounds that try to more or less automatically mount stuff, but more often just end up throwing cryptic error messages at the user.
Another case would be application installment. With for example MacOSX installing a application can be as easy as a drag&drop, on Linux however systems people have to learn what RPM, DPKG, tar.gz, what their distri is and other stuff like that, there are dozens of ways to handle software installations. No GUI in the world can burn this down to the easy of use of drag&drop installations. Here a standard for cross-distri, relocatable software packages is needed.
There are a whole lot more of these issues where the problem of the UI is a direct consequence of problems at lower levels. Doing a serious improvement of the 'Linux-UI' would require joint forces on pretty much all levels, from kernel, filesystem hierachie to KDE and Gnome. It would also mean to just throw some things out of the window such as the current filesystem standard or at least hide it pretty well in the GUI as Apple does.
Cool your jets dude. The point is that you can have all the "big picture" guidelines in the world, but it's not going to create usable software until the developers actually understand the issues and model the problems correctly. (Or since we're talking OSS, just copy someone else's.) A HIG by itself does nothing to fix bad UIs.
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-bit color, and now he can't figure out how to get it to work with 16-bit color. I haven't been able to solve the problem for him over the phone, either. He doesn't need help using Mozilla; it's basically the same UI as IE. He doesn't need help with AbiWord; it's the same as every other word processor.
For me as a Linux user, the big frustrations are all things that are the fault of the system, not the fault of the person who wrote the end-user GUI apps. Some programs (e.g., Pan) only fully support the control-C/control-V style of cut and paste, while others (e.g., Emacs) only support the traditional X-Windows version. The lack of standardization of the interface is a system-level problem.
Another example is shared library hell. It's not the fault of the person who wrote a GUI app that the latest version of the Pango library wants its data files in a different place than the old one, and gives a misleading and worse-than-useless error message. Printing is another example. How many people do you know who boot into Windows every time they need to print, simply because setting up printing on Linux is too much of a hassle?
There are many layers of software below the application level (libraries, X, the kernel), and the problems are almost all down there, not at the app level. That shouldn't surprise anyone, either. There is no centralized authority to tell people how to write Linux apps according to certain guidelines, and the people writing libraries don't have a boss to tell them, "No, goddamn it, you are not allowed to break binary compatibility twice in a month!"
Find free books.
I subscribe to the tenant, "Your application should look like the standard applications in your environment." If you are in windows, make your application menus like Microsoft Word as much as possible.
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 "beta tests" new interface elements for the next version of Windows in Office or MSIE. People consider that "since something is in Office, it's okay", they promptly duplicate it. This has led to duplication of a lot of interface mistakes on Windows. These include "smart menus" that reorder themselves, progress bars that move in non-minimum increments, animated icons to indicate ongoing tasks, rollover-highlighted toolbar buttons, wizards, multi-row tab bars, etc.
Also, many times behavior in one place is not appropriate in another. If you are using an interface guideline book instead of other software to help you choose what to do, at least the reasoning behind each decision can be included attached to the behavior to assist you in knowing when that behavior should *not* be used. For example, the classic MacOS flashes a menu item several times after it has been selected. This is not eye candy, but to help allow the user to determine which item has been selected, and to correct from errors in choosing the wrong item. If you simply saw this behavior, and were writing a game with custom widgets, you might think that *every* clickable item should flash several times after being clicked.
There should be a set of interface guidelines in place desktop-environment-wide that are sufficient to usually determine how to do something. This has worked well for Apple (who used to be King of User Interface), and is currently being used for GNOME and KDE.
May we never see th
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 for anyone.
Friends don't help friends install M$ junk.
I would like to throw out a couple of observations here:
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.
Blogging because I can...
Alright Mr GUI bigot, here is a command line I typed last time I was at work:
grep StrangClass_name::open *.cppThe above was done on a MS windows machine! Tell me what the windows way of doing that is. And don't point me at a different IDE because that only solves the problem when I'm programming. (Not to mention I happen to like vim) Try this one
grep phil jan_sales*
where (for whatever reason) there is more than one file. Pipe that into another file so you can figure out what phil did. Oh sure, a good order tool will do that, but that is a completley different tool from the IDE you just made me learn above. Suddenly you have given me two tools to learn where one worked before. (granted I could, and GUI tools are quicker to learn if done right, but order tools rarely are done right) Once I take the time to learn grep I can do a lot of complex things in the unix model. I can do even more if I learn regular expressoins.
As an example, I recently put in a simple infix calculator for a textbox on a GUI (I looked high and low for an existing Java impl, but I think the fact that it's an assignment in every CS101 class accounts for its scarcity...). I stopped where the parsing was easy; I know _I'm_ not going to put in the wrong format. It's not for lack of knowing how an intuitive UI should behave--I consider myself an expert; I just don't feel like busting my hump solely for the "good of mankind".
File system and file handling.
I've just recently migrated to Linux because it provides much better stability, and the whole $0 issue is great too.
My biggest problem with linux is two-fold.
First, the file system is extremely counter-intuitive. I am an old DOS user from the early 90's, and frankly, I like to deal with my file system in a more physical manner, being able to determine which drives have which files, etc.
If I could say: "Well, my system files are in the system folder on the second partition of my primary master hard drive" rather than. "Well, I guess they're in / ?" I would be a much happier user.
Second, the directory structure, installation methods, and many file handling methods don't make a lick of sense to a lot of end users. It would be nice to know exactly which folder does what, have predetermined directories for installed programs (Along with the ability to install them for all users right off the bat!)
I picked up the GIMP in about 5 minutes, once I managed to FIND a decent manual, but not only are GOOD manuals hard to find, the very way everything is set up is extremely counter-intuitive.
The solution? Make not only interfaces intuitive, but the underlying sub-structure. With proper organisation, it would make migrating between Windows and Linux much easier, plus Linux has the capability of being FRIENDLIER and MORE ACCESSIBLE than Windows if care and attention was put into making Linux "Make Sense."
This seems to be the theme of much of this discusion, but it's bogus. KDE's interface is far more consistent than M$'s and anyone can use it's elements. The result is going to get better not worse.
I just don't get the issue. The author pulls his hair out because of one menue item in Konqueror that I've never seen? It's like saying you can't live in a mansion because there's a dead rat in the yard. Sure, the problem should be fixed, but the it's trivial and has nothing to do with the whole user experience.
Free software already has a better user interface than M$ does. Here's a list of the kind of consistency that KDE gives me that other software does not:
Sure, developers should strive for "usability", but saying that they don't is an unwarranted slap in the face. Users of all sorts have been losing out on M$'s junk for years now.
Friends don't help friends install M$ junk.
I disagree that it's at all uncommon. I think it's very common
It's pointless to argue this issue. However, if your software is really "designed", at this point the GUI Nazi would step in and say "Yes it is", or "No it isn't" and the software would be designed around that point. The issue with Unix GUIs is that nobody wants to accept being on the losing side of that argument, so the CLI is for "us" and the GUI is for "the little people". [As a gross generalization, anyway.]
Really, I think the way most end users think about how to use computers is a negative result of the document-centric model
OK, if you are planning some long-term comeback of the CLI over the GUI as the predominant mode, there's not much to talk about because it doesn't really solve an immidate problem. (Such As: I should be able to copy a list of files from Explorer to Notepad.)
However, I do agree that there's a lot of really big issues with searchability and data manipulation that aren't being solved very well. But a lot of that has to do with the data being stashed behind RDBMS frontends, in groupware, or in impenetrable Office software formats. Such as it is, Unix tools like find/grep aren't the real answer either.
Business. Numbers. Money. People. Computer World.
games have a very specific need for there interface, a home computer will have many more needs.
The Kruger Dunning explains most post on
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 was deemed a lost cause as far as UI went, so Sound Juicer was written instead. XMMS was deemed fundamentally flawed so Muine and RhythmBox 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.
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.
Erm, the same is true of Photoshop. These are apps designed for people who want to do advanced graphics rather than mess around, of course it's going to have advanced terminology. That doesn't reflect on OSS vs proprietary usability, it simply reflects on the types of apps Gimp and Photoshop are.
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 radio button marked "Double Sided". All because someone thought that sticking a command line in a pretty box with an OK button makes it usable. No, dammit, give me radio buttons.
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 (and maybe watch the command change as I do it, and just maybe learn something about lpr...)
Well the main problem with OSS is that because most of the code is volunteer basic so parts that are not fun to program will often put put aside hoping someone will like it. Good interface are not fancy graphics. Good interface programming takes a long time often much longer then the actual part that meets the program specs. Good Interface has to prevent people from doing the wrong thing and make it easier for them to do the right thing.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
A couple of example problems in the Gimp 2.0 UI:
The Open Image dialog requires double clicking in the Folders list and there is no open Folder button. Users are not mind readers and should not have to be a detective. Double-clicking is not intuitive to most users and this is likely to be a show stopper.
On startup it comes up with a mess of useless, confusing options, all irrelevant to the only two (count them, 2!) common options of creating or opening a new image. This is a systemic problem in gimp, displaying non-available options. Gimp should never display anything that can't be used. At the very least it should grey them.
While I respect what the gimp designers have done (a lot!), and while gimp isn't even close to the worse UI programs out there, the gimp designers need to think much more in terms of naive users and standard user interfaces. Whether they like it or not 95% of (attempting) gimp users are naive. The designers should put their naive friends and relatives in front and see how far (and how slow) they get, without prompting. Judging by my neighbour it won't be far; all she wants to do is resize (making it possible to email over dialin) and crop her digital photos and scans. As a bonus making it easy for the naive user will often speed up the common workflow of the experienced user.
---
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.
They have a pill for that sort of thing now, you know. Technical problem indeed.
Shop as usual. And avoid panic buying.
The problem with good UI is that it is a blurry field. Straight out coders can't do it, straight out graphic designers can't do it. Instructional designers can get closer, but a person needs a combination of all three to design decent UI. But that is not enough. What is needed is serious user testing. I can't stress how important testing with novice users really is to create quality UI, and it doesnt happen ANYWHERE near enough on open source/linux projects.
I see many people say 'OSS UI design sucks because graphic designers won't work for free'. Actually, in my experience, graphic designers can be even worse UI designers than coders. Many cannot grasp the concept that their pretty designs actually have to be interacted with, not just looked at. The number of times i've had graphic designers design me an interface to implement that is completely unusable - or even impossible to create... well, its a lot.
Now, don't get me wrong, coders suck at UI too, but for other reasons. Coder/hacker/geek types generally do not want to spend time developing a UI they do not need - particularly on OSS projects they are doing in their spare time.
As they are advanced computer users they do not require their UI be abstracted away from the core functionality through the use of metaphor and pretty buttons. Most are quite happy to pipe together big complex shell commands or manually edit complicated configuration files in vi/emacs/whatever. In fact many get enjoyment out of this sort of lower level hackery (myself included).
This translates across to GUI's developed by coders also. They want highly advanced, very customisable and extendable interfaces, and many don't particularly care if they are butt ugly - as long as the functionality is accessible (see slashdot (not to mention most linux apps)).
The problem is novice users don't want this. They need to have their hand held. And they get scared when functionality is not abstracted enough for it to not be 'too computery'. If a novice user sees anything remotely techy, they get scared they will break something. They want 'folders' and 'recycle bins' and big friendly buttons. They want UI conistency between different programs. And they want computers to handle all the details - not to have to wade through loads of options and settings.
Unfortunately, this is what pisses most techy people off about windows. I personally hate it when windows does things without me telling it to, or hides functionality behind layers of UI crap.
These two crucial, core differences between the wants & needs of linux users/developers vs windows users is by far the biggest hurdle in preventing linux becoming a desktop OS for the masses imo. Getting geeks to create UI's usable by the masses is hard. Getting everyone who codes a linux app to do this, and to use consistent UID throughout them is damn near impossible.
I like reading history, although I am by no means an expert, and I have noticed one thing: Change does not happen quickly. When it does happen quickly, it is equally quickly undone and we return to the earlier state or near the earlier state.
I think that the article's author is expecting change to happen quickly and this is a mistaken belief. You cannot change a whole community quickly, there is a lot of inertia. How do you tell someone who til last week has been your best coder that they are doing things wrong?
Microsoft started its secure computing intiative 2 years ago, we are only seeing some fruits of that now. News from Iraq, the newly elected prime minister is alleged to have executed 6 insurgents personally, echoes of Saddam.
meh
From a useability perspective, it's not a conflict, but two groups who want to access information in different ways. If you have the time/money/know-how design a CLI into your GUI (or vice-versa). That way if I haven't played NetHack for a while, I can use pull down menus for commands until I'm 1337 enough to remember how to eat a lizard corpse on my own.
I'm just amazed that this topic hasn't been taken over by fools (note, I'm not talking about the thread originator or myself here) who seem to think that UI is not important, or must be done by those who give a damn and nobody else needs to bother.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Uhm, most software music players now have a combined play/pause button, instead of 3 play/pause/stop buttons. That's because somebody finally said, hey, wait a minute, why exactly do we need three buttons when one will work?
Same reason a lot of web browsers have a combined stop/reload button.
I started working at a company a few years back. When I got there, the developer had written an application to replace the users 'green screen' interface.
;)
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.
The Kruger Dunning explains most post on
We need to be developing software that has an interface that is initially simple, but can be more complex if needed.
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 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.
You can lose something that is loose, so tighten the loose item so you don't lose it.
B) You can go to a Mac board and find numerous places where Apple ignores/violates thier own HIG.
They are the Human Interface Guidelines, not Human Interface Laws. No one document can describe with absolute certainty how each situation must be handled. A good designer will take the guidelines as a starting point, and apply them to an overall vision as appropriate.
While I am a Mac user and like most of Apple's designs, methinks you are placing too much faith in Apple's designers. They didn't get into the Interface Hall of Shame for nothing.
They are just as guilty as anyone else of making things look shiny at the expense of usability. There are many other examples: for instance, in the OS X help system, if the toolbar is hidden, so is the search field. It's pretty confusing for a new user to see "enter your question in the field above" when there is no field there.
They have also given several applications a brushed-metal appearance that do not warrant it (cough Finder), and in many cases this is ugly, a waste of screen space, and a detriment to usability. Brushed metal is only for windows that represent an interface to a specific piece of hardware, and IMHO should never have been there in the first place.
The list goes on: AppleWorks is the epitome of a "bad Carbon port" and trashes several parts of the HIG; iChat, while shiny, is very difficult to use for normal text chats. I use Adium instead: it has its own usability problems, but since it's open source, I can fix those (and have done so in several cases). It also doesn't waste so much screen space as iChat. iCal is terrible: slow, kludgy and full of nonstandard controls.
The list goes on. I still prefer Apple on the whole to either XP or *nix for usability reasons, but they're far from perfect...
I hereby place the above post in the public domain.
Now you may want to call me a heretic, a troll, and a baiter of the flame, but listen my brothers and sisters to what I am about to speak none the less.
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.)
You are absolutely correct. It therefore falls to the authors of new interfaces to find the nearest non-geek and ask *them* to test the interface, just as it befalls the developer to have someone not involved in the project development review the documentation.
It also falls to the authors of interfaces to be consistent. X Windows, for example, had all these bits of interface whackiness depending on the author's whim and on the particular manager. Bad, bad, bad, bad, bad, not because it does not grant freedome, but because it badly breaks consistence between similar programs written by the same author in subtlely different environments.
Uhm guys... I don't want to sound rude or anything, but I think the UI factor in Linux needs some improvement.
./install.
I've been a linux user for 3 years. And things like these still make me like to give my head a whack!
1. Sharing printers and folders. Average users (from windows background) worst nightmare! In windows you just right click the printer icon or the folder and click on share.
2. I don't get it why changing screen resolutions can be such a headache. Like, when you resize from a 1024x768 resolution to a 800x600 resolution, the desktop doesn't resize and rearrange itself (unlike windows). I have to admit, changing resolutions is much clearer nowadays to do, rather than the old days when one uses the CTRL-ALT + keys. Average windows users will get a culture shock on this one.
3. Some interfaces on some programs just are plain ugly. GIMP is a striking example, and can be frustrating at times. I can use photoshop almost straight out of the box without any help from the manual.
4. Application packaging. Guys, as much as I like apt-get, and front-ends like synaptic, the average user (from the windows world), has a mindset of just popping in an installation cd, and the program just runs. Or just downloading the file from the net (like winzip, etc.) and run setup.exe. I rather like the installation package of OpenOffice - just extract to a directory and run
5. Applications have inconsistent menu layouts. I like mine simple and direct to the point. I like the menu interface of mozilla.
6. A good interface linux distro is pclinux, a live cd based on mandrake. I like the control center - it's simple and has good layout. It gives the average joe (windows background) control of his system without being intimidated by the command line. I showed it to some people and they immediately felt at home with it. They changed the ui of most software (icons, etc.) to make it look consistent across the distro. It just makes it easier!
I like the OSX interface - clean, simple, direct to the point as well.
I like to show off linux to people, but if the ui doesn't improve, well, I have really a hard time getting them to use it.
The problem with useability can be summed up with one word : magic.
The user wants the computer to magicly do want he wants, not what he says. And to magicly present THE option he's interested in, without traversing a few menus first.
The geek with no patience on the useability issue wants useability to magicly appear - possibly after using some "silver bullet" useability automation software feature. Useability in many cases is 90% of the whole effort, as has been pointed out elsewhere. It doen't come cheap or magicly. Its a hell of a lot of work to get right.
Summary: useability is work to provide and work to use; ain't no magic.
Hmmm. That's pretty neat. Maybe I should get a Mac.
Although the points other posters have made about the usefulness of a fully programmic interface do stand.
--Grandparent
"You can go straight to a command line, and I can play with my pointy-clicky button things (and maybe watch the command change as I do it, and just maybe learn something about lpr...)"
And the buttons (with commands that show up in the comand box) can be added individually, so you can go to whole libraries of them and pick and chose and add and delete them.
cat blah1
ls blah2
dir blah3
del blah4
etc.
You mean the "fools" who don't really care whether Open Source software displaces Microsoft and makes its way on to every single PC in the world?
Yes, if you wish for absolutely everyone to use Open Source software, you'll have to worry about GUI design. But there are plenty of people who feel just fine using vi and command line apps and so on, as long as they work well, and they rightfully don't care what order the Yes and No buttons come in on Gnome popup dialogs.
Personally, I think that pushing for every piece of open source software to be usable by everyone is quite foolish. But then, I'm generalizing as much about your point of view as you are about the opposing view.
I've come for the woman, and your head.
No shit. I have seriously been thinking about getting my masters in design from a school like the institute of design at IIT (http://www.id.iit.edu/) because I've got the technical background and I'd love to be able to make a lot of programs actually worthwhile, and not many engineers are willing to go that route. I think usability is probably a huge factor in adopting software, probably more so than reliability (which is a reason I believe windows was popular even when it was crash-prone.) If you want to see your stuff get popular you have to be willing to cater to the non-technical crowd.
However, if your software is really "designed", at this point the GUI Nazi would step in and say "Yes it is", or "No it isn't" and the software would be designed around that point. The issue with Unix GUIs is that nobody wants to accept being on the losing side of that argument, so the CLI is for "us" and the GUI is for "the little people". [As a gross generalization, anyway.]
Makes perfect sense to me. As you implied, the average user doesn't need all the infinite flexibility typically provided by the CLI app, so the GUIs will, and probably should, be less featureful. In practice, the GUI development is driven by end-user requests (I contribute occasionally to three different KDE applications that are very end user-oriented, so I'm giving you that perspective), so the features that most people want get into the app, and the others mostly don't.
Whether this approach works as well as or better than the GUI Nazi depends on the quality of the GUI Nazi.
OK, if you are planning some long-term comeback of the CLI over the GUI as the predominant mode, there's not much to talk about because it doesn't really solve an immidate problem.
I don't think that will ever happen. GUIs are too useful and make too much sense for too many applications. For some applications, they're really the only reasonable option. For example, I can and frequently do use the CLI and imagemagick to manipulate images, but there's no way imagemagick could possible be a substitute for something like the GIMP. There's lots of other stuff I prefer GUIs for, as well, even stuff that's not inherently visual.
That said, there are many things that are easier to do from the command line, particularly anything that benefits from being done in batches.
However, I do agree that there's a lot of really big issues with searchability and data manipulation that aren't being solved very well. But a lot of that has to do with the data being stashed behind RDBMS frontends, in groupware, or in impenetrable Office software formats. Such as it is, Unix tools like find/grep aren't the real answer either.
They're not perfect, but grep and its more powerful friends are tremendously useful for searching stuff like this, given some helpers apps, plus the flexibility of the command line to pipe and chain things.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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, interaction designers, ui designers, etc. Even if someone is able to code and to design (very very rare) there is a significant conflict of interest between design and implementation.
"two things I've seen do this, therefor most do it and it is a good thing", nice logic.
-- 'The' Lord and Master Bitman On High, Master Of All
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 think that's where we're going.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
For a _simple_ application which has few, well understood modes of operation (music player, web browser, maybe an Acrobat work-alike... and that's probably it) skinning is a nice touch.
A user will immediately expect to find a few common controls, it's a matter of finding a few of them (good skins will be intuitive). The rest of the more complicated parts of the interface should be nestled in a dialog or context menu that does not change with the skin... this is what Winamp 2 and XMMS did, and I think these are excellent applications of skinning.
On the flip side we have Windows Media Player, mplayer, and Nero, these are far too complex application to have their UIs skinned.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
please note this doesnt mean hitting play when something is playing shouldnt pause, or hitting pause when something is paused shouldnt play, I was only calling you an idiot.
-- 'The' Lord and Master Bitman On High, Master Of All
No, I don't think there's any lack of desire to write good interfaces. Developers want their apps to be used and enjoyed. A large user base gives you more bragging rights than anything else would.
It's more a matter of: making a good interface is *hard*. And it's not like commercial software is much better -- I've spent the last few weeks beating my head against SAS, which couples a hideous relic of a programming language with usability that makes GIMP or the Debian installer look like iTunes.
Most open-source projects are designed by a single developer, with usability feedback from his girlfriend. The most important thing for good design is serious testing with a good number of naive users, and that's extremly difficult to do for a single hobbyist developer.
What I'm listening to now on Pandora...
Find someone unfamiliar with your application. Then explain what its purpose is. "You use this to configure a printer so other computers can use it"
The set up a web cam on them and record them using your application.
Afterwards play it back and ask for the users comments as you go.
I notice you paused for a long time at this point...
Or, why did you go into that other menu? etc.
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
I'd have to wholeheartedly agree. Until a few years back, you could only use it to connect to one server at a time. I still have no idea how to make it connect to more than one server at startup. I thought chaining together perform actions on connect might accomplish the task, but it seems to go 'round in circles that way. If left alone it would be an infinite loop. I've resorted to the now poorly named xchat for this windows machine.
Scripting in mIRC is done via a custom built scripting language; xchat uses python and perl modules (and presumably others). I'd been a mIRC user for years, it was certainly head and shoulders above the free and runs-on-Windows crowd I'd tried. Trillian tanked on large channels -- join a channel with a large number of users (#debian on openprojects, perhaps), and the damn thing would slow to a halt, with the list of names in the channel slowly growing. As best as I could surmise, someone was using a vector to store the names of people in a sidebar, and rather than doubling it, was adding just enough space for the newly parsed name. I haven't tried since; you only get one first impression, people!
When I first tried xchat, it was on an elderly sparcstation running TWM, I believe. This was about three years ago. Very antiquated. The interface was ugly and not very explanitory at all. If you want a new user nightmare story, you need look no further than xchat 1.x and the detach window button. Bewilderment will follow. Thankfully xchat2 is around, and far friendlier Buttons make sense, its far more difficult to detach a window, and the settings are more explanitory. Its not perfect, but its leaps and bounds.
I guess thats enough venting/ preaching at the choir. The only thing left to do now is let the console irc junkies flame without compassion.
I Browse at +4 Flamebait
Open Source Sysadmin
The biggest reason why Windows has a definite edge over Linux in terms of adoption is because of its user interface for configuration. For example: In Windows, if I want to add something to my startup sequence, all I have to do is add it to my aptly-named Startup folder.
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.
...I am proof that intelligent beings are not always intelligent...
Yes! Why does no one talk about visual perception, motor control, and psychology? Is there some unwritten law which states that we must not talk about the heart of the matter? I personally have just moved to Linux and fully intend to stick with it indefinately. I have used DOS for many years and am switching for political reasons as well as the lack of sound card drivers. I always thought that the command line was a graphic. It certainly is a visual phenomenom to me. As a professional artist, I find the command line suits me much better than the "windows" interface, because it doesn't bombard me with tasteless colours and shapes which are ofensive to me. I can easily accept text because I've learn't to read it a long time ago. The meaning of the colours and shapes is a mystery to me. Since I don't understand them, I'm asuming that either I am stupid, or the writer of the program is mixed up or simply doesn't know how to communicate visually. Moving to Linux, I decided to use the GUI to help me learn the system and get more comfortable with it before I actually tried to tackle the complexity of the UN*X command line. This has been EXTREMILY difficult! The reasons for this can be found in my particular psychology and sensory perception. Although I have Post Polio Syndrome and a touch of autism, I beleive that there are many people with a similar sensory and psychological disposition. Here is what I have found difficult: 1. The scattering of information all over the page, rather than in some neat order. 2. The need to visually follow the mouse pointer. I am very poor at hand eye coordination, and it is a mystery to me why it has to be an essential part of using a computer. 3. The lack of regristration between the mouse and the screen. I find it impossible to control without watching the screen closely. The same movent of the mouse does not land the pointer in the same place every time. I rely heavily on physical memory in order to function in my daily life. Regular mice require me to learn a skill set which is probably not even good for me since it causes so much confusion. I can do extremely acurate movements, such as play a violin in tune, but I can't get a mouse to work the same way. I am lost. 4. The lack of choices. The windows interface is basically a multiple choice system. This can be very confusing to some minds. I was poor at that in school, prefering to simply suply the right answer. The other problem with multiple choice, is that they are not presented in a simple to read list, but rather scattered around. The third problem is that they always leave out so many choices. They are never complete! What's the use of something which isn't finished? For example, three different people who have been using my computer, could find no way to write a file to a floppy in my current distribution (debian). If there is something to click on somewhere, three people who have each been using computers for years, could not find it. These are just a few things which I thought were relevant to this discussion. I do hope that the entire computing community gets over this current "fashion first" mentality and starts to consider things from a more realistic perspective.
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...
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
You can't solve the problem, because you don't have the skills to do it.
It's NOT a technical problem. It's a problem of DESIGN, which is different. So OSS programmers can make some kick-*ss software, but most people are not going to be able to use it unless someone gets humble fast and says, "Oh f*ck, I don't know how to design ANYTHING because... I'M A PROGRAMMER! I need a DESIGNER!"
I know it's hard, and it takes a project leader with almost saint-like patience and humility to let his/her project be co-designed from conception to completion by someone who knows close to nothing about programming, but that's the only way. You're not a designer so just suck it up, and if you want your software to be popular, and useable by people, make sure a user interface designer is on your team and do what they tell you to do.
Also understand that you are going to have to do almost double the amount of work you would normaly have to do to get a good interface. Don't get mad at your designer... It takes a lot of work. You will have to grit your teeth and do strenuous amounts of work to get something that satisfies your designers' requirements. Don't bitch about it, just do it. That's how it works. It's hard, and yes, most of the work is going to fall on the programmer(s).
But in the end, the reason why Open Source hasn't taken over MS is because of the UI and the marketing. Linux? Most people can't use it. I mean, I've used *NIX, and I hate it. Most people do. In fact, most people don't even bother to learn it enough to hate it. What non-programmer is going to commit 300+ commands to memory just to search and type and use email. Uh, yeah.
So don't be so full of yourself. You can't do everything well. Beg, borrow, or pay a designer, do the work, and watch people actually start using your sh*t.
Then you can get an open source MARKETER and start REALLY doing some damage to MS.
I wrote a number of script files a while back. These were programs that did useful work. They ran from the command prompt, so there were no press-button dialog boxes. But the coding was such that i could easily redesign the input sequence on a user-basis, to match the different worksheets. The results were still the same, but the input and output were redesigned to match each section's needs.
The whole idea of user interface design, is that it should be obvious to the user, from standard techniques (eg /? options), exactly what is going to happen.
Some user designs are good, but there is an intrinsic flaw in the design. Consider the desktop. The idea that the screen is a place to start things from is good. But it's more suited for a single-tasking system, since there is no way of recovering the screen once it is overlaid. The problem with this is because the desktop is not listed as a running task.
Suppose, parallel to the desktop, there is also a running task that has the desktop in a window. This would bring on demand, a desktop to the front whenever the user wanted it, and the windowed nature of it would indicate that it was not the only running task.
Using a system menu, such as Microsoft's taskbar, is good, in so much as it is always available to launch and notify. But there is a limit to how much real-estate one can afford for this.
One can go for really tiny windows, like the Office taskbar from Office 4.3. This was a little array of icons, about the size of the title window, that sat in unused space in the title. I use bbar.exe in this way. It takes very little real estate, and coupled with popsel, gives one a multi-menued task-bar.
The idea of running tasks as separate icons is not good: i would rather have a drop-down list, with sublists for sub-windows.
OS/2 - because choice is a terrible thing to waste.
Right now, I have found a interface feature which i believe would benifit natalus (the windows/mac file browsers too, but they are not of my concern). I realized the need, and thought of the idea. Now did i implement it? Hell no. I'm not about to spend all that time searching through the natalus source code, and coding in my idea, just to have it not be compatible with the next release.
What did I do? I wrote a letter, stating my idea, and am sending that...
What will become of this idea? well i sent a letter, and theres a good chance that the first person wont like it, or wont catch what i was intending if i didn't write my letter elegantly.
If anything happens to it, the next probability is that it gets passed to a bunch of developers, who will argue wether it is the optimum.
What's the alternative? Well, what if the visiable objects were accessable via a scripting language? A language that i could build a new interface to my applications on the fly, as it was running? This is what i've been waiting to see from gnome since i first heard of gnomes CORBA base. guile-scheme (the GNU choice for "extention langage" - see http://www.gnu.org/software/guile/guile.html)
But my point of this article is not to prop scheme. It's that by makeing interface design easier to change, that you'll get more moddifications & testing by the users.
Beyond just having the hooks in the scripting language, the next step in reducing teh cost of makeing new interfaces would be to have a builder for all the commonly implemented components. This wouldn't let you do everything you could want (and most of what I usually want) in a interface, but for some people who just want to move a button, this would be a godsend to the end users that can't even figure how to use a interpeted langauge.
Think of building the interface as a activity of the end user, not something to find your optimum interface via sets of prefabricated rules.
Some people would disagree with you that installing software in everything besides Windows or MacOS is as difficult as it was, like 3 years ago.
And keep in mind GIMP on windows is using GTK-Win32... if you're going straight through GTK (which is the GIMP Toolkit, after all) you're going to be limited by GTK's widgets and GUI metaphors. There is some attempt using native widgets with a special GTK theme only for Win32, but that's not quite the same thing as a native app which doesn't care about the toolkit.
You'll also find that QT apps in Windows have a definite "QT feel" to them: ever use Metis?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
People keep *saying* this, but no one ever explains themselves. I think a lot of the trouble is people have the old Photoshop muscle-memory and it does not translate well into GIMP.
Here's a hint: Painting tools, Layers, Channels, Paths, and their options exist as floating toolbars. Everything else (selection operations, resize, color space and filters) is accessible via right click.
THAT'S IT!!!
God...
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
"I agree, everybody (with the exception of the really clueless moron) is as smart as the Linux developer, many people are just lazy."
Often they're just busy. Or have other things on their minds. I'd really have my doctor remembering drug interactions than trying to remember a bunch of arcane text commands for his computer, and I'd rather have him spend his time reading the latest medical studies than learning a new set of commands for every new piece of software he gets.
- Robin
I can't translate that command-line, but it looks like it's just text files... sort by type, then rubber-band all the text files. If it's too long to rubber band, you select the top one, scroll down to the bottom one, then shift-click. You have all the text files selected. Now hit Command-C to copy all the filenames into the buffer. Open up TextEdit (or any word processor) and hit Command-V to paste the info in. Save where you want. I'm primarily a Mac user, but I'm 90% sure this works in Windows as well.
It sounds more complicated but, really, how often do you do that? I've used computers for fifteen years and needed to do that about three times. All of those times, I was able to use the procedure above easily.
What bothers me more is how Windows doesn't calculate folder sizes which makes it impossible to sort a Windows view by size. This was a real pain when, at work, we were asking, "who the hell is using up all that space on the file server?" I finally ended up having to download a shareware program to do this task that's extremely simple on MacOS.
Comment of the year
I am one of the toughest UI and ergonomics critics and have been looking for years to find the perfect computer application interface and have finally found it - Eclipse..
The UI for Eclipse is extremely well designed and though out even so it seems to make Apple developers happy.
Having a application UI framework that is window manager and language independent is exactly what the Open Source community needs to make OS apps easier to use and attract the non-OS users. Unfortunately, such a project would need collaboration between the biggest OSS platform teams but would'nt it be nice.
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.
There should be some way that the "guts" of the application can be completely disconnected from the user interface. Some designer type person should then design one/multiple UIs that can be connected back to the "guts". Programmers don't write good GUIs (trust me, I'm a programmer; everything just ends up falling randomly onto the screen). Designers don't create good GUIs because it is prohibitively hard to then connect those GUIs to the application behind it. If the connection between these two could be made simpler, it would be a boon for usability.
The only people worrying about K's everywhere are in Redmond. Everyone else just wants their camera to work.
Friends don't help friends install M$ junk.
The thing is, this "more powerful" solution only is useful if you've named all your files in a consistent, uniform, properly orthogonal way.
Which is a rare case for most users.
Bollocks.
FOSS developers couldn't generally care less about "world domination", and "contemptuous towards end-users" is not a very fitting description of a person who is doing all that work for nothing on their free time for those same users, you generally don't give gifts like that to person(s) you hate.
Slashdrones - who may or may not be contemptuous, or may or may not be yelling about world domination - are not FOSS developers.
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! ;)
The line: ls -la | grep foo > foo.txt
does the following:
1) ls -la
Lists all files in the directory, showing all file information (that is, size, owner, permissions, access date) and not just the file name.
2) |
'|' (pipe) means take output of one program, feed it as input to the next
3) grep foo
Find all lines with the word 'foo' in it
4) >
Take the output of this program, and save it to a file
5) foo.txt
The file to save it to.
So, you're listing all files in the directory, getting their file size, date, permissions, and owner, searching for the ones with "foo" in the name, and saving that result to a file.
To do this in Windows, you'd have to go to start * search * files and folders
then search for "foo" in the folder you wanted.
Then for each entry, you'd have to right click the file, hit 'properties', and manually copy each line (because size, date, owner are all on separate lines and can't be selected together; only individually) and paste that into a file. (So you started notepad in the middle there, somewhere, too.)
That'd take orders of magnitude more time to do.
And I use grep every day. It's a wonderful tool and once you really get to know its power, especially when you take other program outputs (listings of ANYTHING can be piped into it), you can really search for and actually *FIND* information quickly.
One ideea that will fix this and many other problems is mega widgets. Pick one cross-platform toolkit and create mega widgets like "Photoshop canvas" or "movie storyboard", "movie timeline" stuff like that, and create the GUIs via scripting (python would be nice)
This way if someone doesn't like the GUI of a certain program... he/she could change it or better yet... pick one from the net.
Right now I'm part of a project where we work just like that. The company I work for have hired a UI consultant that really knows his stuff. He has created a one of the best specialized GUIs I have ever seen. It is then up to us progrmmaer to create the code behind the pretty pictures.
This works extremely well. If/when I get on another project that involves a GUI, this is the method that I will recommend ad nauseam.
My opinion? See above.
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.
I'd have to say that consistency is more important than ease of use... For example if you know clicking on "Tools" will open a context menu that will contain the "Options" dialogue in almost any Windows application that is something you will rarely have to look for. However with open source, software developers sometimes get carried away with their GUIs which results in having to memorize where "that menu" is in every application you use.
All the torrents you could want.
Also, the ability to search inside files for phrases is horribly messed. It *never* finds phrases that I know are in the files I'm searching through.
Ran into that one fairly quickly trying to search through source code files - I'm a bit disappointed at their lack of search type 'fail-over', where if it doesn't recognize an extension, it seems to do nothing, but here's a KB article on the problem.
Binary geeks can count to 1,023 on their fingers
People keep talking about 'intuitive' as if they knew what it was; and most of the time it turns out that it is just another word for 'cool'. A lot of things would be a lot better if application designers would concentrate a little less on making the 'perfect' Fisher-Price look or implementing their own, private 'vision' of how the world ought to function. We have enough primadonnas as it is.
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.
The perception that all software should be intuitive and 100% usable the moment you unwrap the shrink-wrap is an incorrect one & has been created as a result of heavy over-marketing by commercial software vendors in order to generate more sales.
Sure, I accept that if Joe Bloke buys himself a digital camera, he wants to load some software from a CD on his Windows machine, plug his camera into the USB port and start downloading his images to his PC for editing.
But the fact is that the majority of normal users still believe the hype that when you buy a PC, it's no different to buying, say, a TV where all you do is just switch it on and it works. There is no mention by the PC salesman of having to perform regular defrags, keep the OS updated, update virus checkers, install firewalls, etc.
Just because a piece of software takes some time to familiarise oneself with, does not mean that it is unintuitive - if anything, results are far more rewarding when one has put in a little effort to achieve them.
The UNIX/Linux command line philosophy, for example, is frequently targetted for "lack of usability" complaints. However, the fact is that taking the time to understand what programs are on a UNIX system and how to bolt them together in things like shell-scripts means that some very repetitive and boring tasks can be completely eliminated very quickly.
The Open Source movement is not about trying to compete with, or displace, Microsoft - it is simply about doing the right thing which means sticking to open standards that all of us can enjoy (rather than closed standards that we pay a subscription for). Therefore, the creation of cohesive GUIs for software is not the prime concern of the OSS community, albeit that the same are receptive to feedback from users of their software.
Commercial software vendors have to make profits which means listening to their users and rushing their software out to the marketplace - therefore, in the case of Windows software, those same vendors will use the Windows GUI libraries for their software, cutting down on development time and fitting in with the Windows "look & feel".
I'm not denying that OSS software is viewed by some as "difficult to use" - but this should be taken into context that OSS demands a degree of responsibility and time commitment from each user to learn how the software works and to feed back into the developers what the user perceives to be problems with the functionality or layout of the software.
Gentoo Linux - another day, another USE flag.
Default KDE Fonts on MandrakeLinux 10 are blurred at the edges. I cannot read a thing without my eyes starting to hurt. Perhaps someone thinks this enhances usability or something. I have no clue. It does the opposite for me, though (I use Trinitron CRT displays - 15'' and 17'' at home, and 17'' at work). Perhaps there is an easy way to disable the blurring, but, alas, I am a lazy programmer/gamer. I think IceWM does not have this problem :) Perhaps it is the graphical toolkits? AWT also paints crisp clear letters under X. By the way, I am a big Java fan :)
No blurring in the default settings of Windows 2000. There is some blurring on the default settings of WinXP.
That is one of the things I do not like using newer versions of Acrobat Reader for - the first thing I do is try to disable the blurring. I think Acrobat Reader 5.0 had no such problem.
Why, the Ctrl+C option was the worst (lets make windows users happy) feature they ever implemented.
Ctrl+C is break, and it will make lots of you apps break (even under windows).
Konwuror has got the worlds worst cut and past, can't handel HTML, images, anything except plain text and badly.
If you wan't more granular clipboard funtionlaity, I'm writing a kio_slave for the clipboard at the moment, and it should be on kde-apps as soon as it's ready for wider testing and development.
thank God the internet isn't a human right.
So I get to print something off of your pc, after my pc has spent a week searhing the internet.
I've never had to type in the ip address of a printer under linux. (well not for a long time),maybe I've had to pick which driver to use, but then I have to pick which tyres to put on my car, and I suppose I had to pick which printer to buy, so it's not a huge problem.
thank God the internet isn't a human right.
To expand the discussion on interfaces a bit I'd like to mention mobile phones (U.S.: cell phones).
Ericsson had problems with their mobile phone business since around '98, which is approximately when Nokia's business took off.
Ericsson's problems were largely attributed to the really boring design of the Ericsson phones. They fixed a lot of design issues (remember the fix-all-problems T28) but again were unsuccessful. This time because they couldn't keep up with the demand which of course started to let up once the production was up to speed.
Something that in my opinion has always been much worse on the Ericcson phones is the user interface. Ericsson used to hide the games under the "Tools" menu for instance(!). Nokia on the other hand has always used pretty much the same kind of interface but continuously improved it in logical ways. I strongly believe that is a major reason why people have preferred Nokia instead of Ericsson (now SonyEricsson) and other makers during the last few years. I think this is especially true for the last few years when late adaptors (like grandmas, my mother etc.) have started using mobiles.
I have both a SonyEricsson T68 and a Nokia 6610 and boy do I like the Nokia more! I can't stand the interface on the SE!
Die dulci fruere. Have a nice day.
Ok , In Windows, if I want to add something to my startup sequence, all I have to do is add it to my aptly-named Startup folder, fine. But in windows If I wanted to remove something that kept starting up I have to'r entVersion\run
Start up regedit, search for hkey_local_machine\software\Microsoft\windows\Cur
Which, since I'm used to having my hand held so much is quite a daunting task.
Linux configuration UI's arn't so bad anymore, If you do a bit of digging you can easyly get a system with gui configuration on par with Windows.
a href="http://www.webmin.com/"> webmin's good for most things.
thank God the internet isn't a human right.
One component of poor user interface is a frequent lack of easy ways to set utterly common items.
Case in point: I've recently switched from kmail to Thunderbird...and I have yet to find a way to get Thunderbird to open a URL in Firefox. There is *no* way, in options, to tell it to interact with the other half of the same package!
The reverse is true with Firefox: I have to d/l an extension, rather than having one built in, with setups for the half a dozen most common mailtools.
This is *ludicrous*. This will turn off Joe User in an instant.
mark "then there's OpenOffice.slow.as.a.dog"
I like to think I've got enough theory in my head to have a good whack at user-interface design, but of course I'm not going to claim to be an expert. There are two main skills we need for user interfaces in open source software:
The second of these is the easier of the two, and I think most people can make some constructive comments about the pros and cons of a user interface designed by someone else. The first item, however, is the hardest part. To start from scratch like that requires quite a lot of background, and while some developers make a reasonable stab at it, usually by responding to how other developers handled a similar situation, that can't work for all cases.
Until such a time when we have qualified UI engineers contributing to open source projects, I think it's useful to increase the feedback between the two tasks above. The original developer uses some simple UI background to design an initial interface, then throw it to other developers and interested users and invite feedback on the interface specifically. The developers, in their role as developers, will probably point out some inconsistancies with the simple rules they have learnt, but the developers can also take the role of users and see what they find hard to do in the software.
Once that is fed back, the user interface can be refined just like the rest of the software until it's good to go. This refinement process works for the innards of the software, where perhaps the set of people able to make good comments is smaller, but everyone can have a point of view on a user interface because everyone knows what they are trying to do and what's obstructing them from doing it. Of course, we have to remember not to go overboard as some goals will be more "common" than others, but we make decisions like this in software design every day so applying similar priorities to the UI suggestions should come naturally to any seasoned open-source developer.
it would be interesting to see three experts, the best of the best, on each system: windows, OS X, OS 9, linux, Solaris and have them each fulfill common tasks, and see who is fastest. move files, open email program and send mail, write a letter in a word processor etc (including app start).
in my professional life, i have seen unix experts [fantastically ineffective], windows experts [getting slowed down by a zillion wizards], Max OS X experts [good speed], and OS 9 experts [faster than you can look].
i think a large scale study on this would find that there is an absolute, quantifyable speed difference between the systems. ease of use translates to more efficient and less frustrating work experience.
for example, i use my PC 8 hours per day at work, and i appreciate its qualities. but when i have to do work that can be done on my Mac, i will do it there. it's just more effective.
as an example, i just wasted 15 windows minutes because i suddenly decided to clean up my system and remove all old applications and demo versions i never use. i went through the "add and remove software" thing - half the apps in there are no more on the system. ok, fine. others have "critical errors" when removing. can live with that. then i made the mistake to remove "firebird 0.9.0" because i know i am using 0.9.2. whoops, that deleted 0.9.2 instead. foolish me. a system restore (who knows what prefs are stored where...) and firefox reinstall cost about 15 minutes.
how would i do that on the mac? i go through the app folder and just drop the ones i don't use in the trash. done.
at the end of the day, usability (or non-usability) translates into cold, hard dollars.
The role of natural language in a multimodal interface.
In Proceedings of the ACM Symposium on User Interface and Software Technology (UIST), pages 143-149. ACM, ACM Press, November 1992. In ACM DL Ben Shneiderman.
Human Factors for Informatics Usability, chapter 14, pages 325-342.
Cambridge University Press, 1991.
Although the first focuses on natural language, many points apply to CLI, too.
UI != GUI last time I checked.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
QEMM from Quarterdeck. Multi-tasking for DOS applications. Windowing and virtual full screen displays. This existed before the 386, but with a 386 things got much better.
Yeah. I don't really care. I don't use Linux because the usability sucks ass, remember?
What's really interesting, though, is how the CLI usability is just as bad as the GUI usability. Sure it's POWERFUL, but why wouldn't a line like:
dirlist -allvars -find 'foo' -> foo.txt
Be just as powerful and a hell of a lot more readable? The crappy interfaces in Linux go right to the core... that moronic "priesthood of technology" attitude Unix users created for job security. That's NOT the way you design a computer, unless you purposely want to be an asshole. For Linux to fix its interface, it first has to fix its culture. Linux programmers don't write good interfaces because they want to point to some arcane mumbo-jumbo and say "hey, I'm smarter than you because I know what this means and you don't!" Is there any other explanation for Perl?
Some Windows programmers are the same way, but Microsoft seems to have mostly whipped them into shape.
Comment of the year
absolutely. The *IX CLI is very powerful, but the vast majority of users don't need infinite flexibility, and there's nothing wrong with that. You strike me as someone that doesn't think that way, but most FOSS types do.
Yes.
This is why I find Mac so infuriating; I KNOW I can do what I want if the machine would only give me access to the parts I need and twice as many options. The level of frustration created by 'user friendly' design is only made worse by the various cute pictures and noise
I could see this as fair criticism for earlier versions of Mac OS, but I have a hard time seeing how this really still applies in Mac OS X. There's very little in the way of impassible walls put between you and the guts of the system.
- Scott
Scott Stevenson
Tree House Ideas
ooh, a troll; I'll bite.
ok, so your changes are:
1) "la" to "allvars" (fine)
2) ">" to "->" (sure, why not)
3) instead of piping to grep, "-find 'foo'"
And the reason #3 makes it MORE readable, but LESS usable:
Let's say I have a pair of scissors. If you give me napkins, I can cut them up. If you give me paper plates, I can cut them up. Cardboard boxes. My mail. You name it. My scissors can cut up anything made of tree pulp, and a large number of other things too (tin foil, saran wrap, whatever).
So what do I do when I get a letter I want to open? I reach for my scissors and cut off the top.
Now let's say you invented a new type of envelope that has its own letter opener knife attached to it with a chain in such a way that the letter opener knife can only be used against the top of that envelope. That's nice. It makes it more obvious how to open the envelope, since the letter opener's right there.
But it's no more USEABLE.
And what if I have some paper that I need cut in half? Oh, I guess its a good thing that pieces of paper come with little paper-cutting knives attached. Wait, they don't? Darn, Now I wish I had some sort of scissors or knife that could just cut -anything-.
And that's how UNIX is more usable than your suggestion, and Windows, and the Mac, in a great number of ways.
You have a million tools that are all good at doing ONE thing: Listing directories. Searching for lines of text. Etc.
And with each of these different tools, you can create a chain that does ANYTHING you want. You can list directories and find lines.
You can list directories and email the contents to someone using "ls -la | mail someone@somewhere -s 'contents of this directory'"
Should "dirlist" have a -mailto flag? If it has a -find flag, then it should have a mailto flag, just in case you want to email the directory listing somewhere, accordnig to your proposal.
Every tool can't and SHOULDN'T do everything. That makes it UNUSABLE (because dirlist might have -mailto, but printfile might have -sendemailto; different authors might choose different flags). But if I know that ANY output I have, I can just type "| mail someone@somewhere -s 'subject'", then that's more usable. I can just do it. I don't have to look and check "Can this program send its output as an email?" or "Can this program search for lines?". With grep, I can search -any- program's output for lines. With mail, I can send the output as an email to anyone.
OK, I'll grant you that the names of programs are cryptic. ls should be "dirlist". grep should be "findstr". But really, that's the only complaint that I have.
Just because it's not intuitive doesn't mean its not usable. Linux/UNIX's usablity is through the roof and piping is the reason why -- it makes everything a swiss army knife, and nothing a closed device.
(I'll disregard your flaming/trollful remarks about 'arcane mumbo jumbo' and especially perl.. If you'd really like, you can be part of the solution, not part of the problem, and file bug reports saying "rename switch -la to -longformat -allvars", or even patch it and submit the change yourself. Or you could just read a short book on the subject (or even the manual page; that's right, just type 'man anycommand' and it prints the manual for that command, right there.) )
Usability does not mean customizability.
Interface usability has much more to do with improving the efficiency of the user. Which rarely means providing a dozen different options, when none of them actually make it more obvious to a new user how to perform a task.
Windows is _not_ to be taken as a shining example of good GUI design. It violates so many basic principles that I doubt usability (as opposed to the Wow Factor) is even taken very seriously in Redmond. Worse yet, OSS developers seem to take Windows' interface as something to strive for.
There is a some published work on how to produce good usable software -- both online and offline. Many geeks seem averse to learning about it though.
...Since Photoshop 4, when Adobe was just figuring out what their app should look like too. And Paint Shop Pro was just a fancier version of mspaint. GIMP didn't really have much precedence to follow during its pre 1.0 years. GIMP is like GIMP. Photoshop is like Photoshop. Why the fuck should it be any different? GIMP shouldn't try to be a photoshop replacement, that's lame. It should strive to be an raster image processing tool.
(Actually, the difference between GIMP and PS is much smaller than PS and PSP, until recently, IMHO. I couldn't use PSP AT ALL after having learned PS first)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
many short command names have their origins in the teletype days, where saving keystrokes meant saving significant time.
Lasers Controlled Games!
Anyone from a 5 year old to a WWI veteran can sit down at a Gnome
Desktop and browse the internet and check email in no time if someone
sets up their email for them. (The same is true of Windows).
The differences come in when you start wanting to do things like change
the appearance of the UI, tweak mouse scroll rates, set up printers,
etc. Windows is not simpler than OSS or easier to use in these ares,
it's just more familiar.
Further, it's never been easier to use Windows than OSS or *NIX. However,
it's always been easier to START using Windows than OSS. This is because
OSS is usually written by people who need to use the software, so, the
UI is designed from the angle of how do I make it easy to do what I need
lots of times. Windows was not written by people who needed the software.
It was written to make money. When that's the goal, the question shifts
from "how do I make it easy to do common tasks lots of times" to how do
I make it relatively easy to figure out how to do most common tasks once.
Windows and windows applications are generally optimized so that if you
poke around long enough, you can usually eventually find the feature you
want. Windows apps. are also written so that it's not really important
to the initial end result if you think about or plan the structure of
what you are doing.
For example, in Frame Maker, it's virtually impossible to get the result
you want without understanding the paradigm used for formatting paragraphs
and how that is incorporated into the document. You have to understand
master pages, templates, etc. or you have to work REALLY hard to get your
document to look the way you want, and, it becomes virtually impossible
to change.
In Word, structured document styles are an afterthought, and, they're
actually pretty difficult to use, often having far from intuitive
side effects until you fully understand them. However, it's easy to
create and edit a document that looks exactly how you want it without
using any structure. If the document develops any length, then global
formatting changes become a major PITA, but, that's not something people
look at _BEFORE_ they buy the software.
I'm sure there are lots of other examples, but, the bottom line is that
the primary difference in the UI between OSS and Windows is whether it
is engineered for efficient completion of repetitive tasks, or, whether
it is optimized for easy-to-understand initial usage to drive sales.
I think Apple has done an amazingly good job in addressing the tradeoffs
between these two important goals. I think the OSS community could learn
alot from Apples UI design, especially in Quartz and Aqua (I didn't
actually like the OS=9 interface, as I think they ignored the efficient
task completion side all together in that UI).