Why Gnome, Ubuntu and the like don't understand "usability"
Wikipedia states: "Usability is the ease of use and learnability of a human-made object." What first springs to mind when reading such, is learnability is only important while the user is new to the program, and learning to interface with it. Ease of use is important for the rest of the users life! The concise, decisive mannerCompanies or projects spend a great deal of time, effort and research to find out what's the best way for the user to interact with a program. Then, they make that the only manner of communicating with the program. Obviously, for documentation, this is the best manner possible. Refer to the recent discussion we just had in LXer-forums about documentation for some rants. And that's only one thread of a whole bunch of them about failing documentation. If there's only one way to do things, it's easy to document.Also, it's easy for a software company to develop their source code, as there will be only one way of interfacing they'll have to code, support, update and fix in the feature. To me, it seems like this is the way Unity and Gnome are evolving. Gnome has the 'human interface guidelines'. To me, they read a bit like the Gnome-Bible of how to do things. That's OK, as it says clever things. I'll return to it later on. Most important: This principle meets the first part of usability: Learnability. It's easy to learn something when there's only one way to do your job. Especially if experts picked the easiest way for you. The sloppy, legacy-honouring way of doing thingsUsually, this is where the mess starts. I'll take my beloved AutoCAD* as an example. In the old times, one drew by entering commands in the command line interface, and entering coordinates and angles. Then came the mouse, so you could click in the raster as well where you wanted the line to be. But the CLI was still functional.Then probably came tracking, where you could snap to certain existing points. But also snap to certain angles, or only orthogonal. Of course, all this behaviour could be changed or turned off if the user decided so. Menu bars could be old style fixed to the outlines of the window, but also float, and users could change this. Of course - again - the CLI remained functional, but by default it disappeared. Easy to put it back in place though. Also, probably everybody knows AutoCAD because it's one of the only white-on-black programs. But less people may know you could easily change that setting. And you could alias your own commands in a plain text-configuration file. You used to be able to write LISP-macros. Probably one of the only things AutoDesk ditched. They ditched it in favour of VisualBasic. Later on, some kind of smart snapping - which I didn't like - arrived, highlighting where you were going, displaying angles more clear while moving. But I was used to the CLI - which still was there after all the years! - so I turned the smart thing of and happily kept using my CLI. Which of course begged the question: "Why was the smart-thingy I didn't like on by default?" Probably because a whole usability team at AutoDesk know their users, and decided that was the best and smartest way to do things! But AutoDesk knows their users. So they also know there are people who are quicker and more productive with the CLI. So they gave their users choice. For example, you can change which points your mouse snaps to via radio-boxes, but also by means of entering a kind of 'binary' value. The 0's are "off" and 1 is "on", and then you combine them. Convert the binary value to a decimal one, and that one you can use. Actually, it's how "chmod" works, for 'old skool people' like me. At first, it seems unnecessary complex remembering bit values. So, in the beginning one only uses the approachable radio boxes. But once one found a mode which one likes most, it's easy to remember. And instead of clicking through 10 menus and turning on / off tons of radio boxes, one can easily enter "osmode=2144" and be all done with it! Now imagine the AutoCAD help file. You search for "How to draw a line". The help text displays. It says: -You can draw a line using the CLI and coordinates, but CLI has to be turned on, -You can draw a line using a raster to snap, but you should turn the raster on, and set the raster space to the correct value, -You can draw a line using the mouse and are able to click everywhere if the raster and snap is of, -You can draw a line and snap to existing points, where you define which existing points you want to snap to, but snap has to be turned on, -You can draw using only certain angles. It varies however if orthogonal is on or off, and if polar is turned on, mind which snap-angles you defined, -You can draw using the smart snap / tracking feature, of which you can change settings, and by the way: This approach is default. Now, suppose you're an ACAD-n00b. The above description of the most basical thing in AutoCAD - how to draw a line - would almost certainly scare you of! Learnability is really 'bad'. And so is usability, as a result using Wikipedia's definition. But if this really was the whole story, competitors would do it different. Now enter Solidworks, something more from the nineties I'd suggest. It's 3D, while ACAD mostly is 2D, meaning a "whole different era". What does it have? Tons of legacy ways to do things! I use it almost every day, but I can't hardly remember all the way to do things. I can use the menu, change said menu. When I finish a command with left mouse click, or select a plane, a "smart adaptive" in-place menu appears immediately at my arrow, so I don't have to move to a menu. But I can call the same adaptive menu using right mouse click, if the left-mouse one was automatically hidden after three seconds. I can use the right-mouse button to do mouse gestures - of course gestures which I can map to the commands I like. I can make keyboard shortcuts. But I can also set up my 6 axis motion controller; think of it as a real expensive advanced joystick without a stick, of course very configurable. And I can map certain 'special'-keys of the motion controller to certain commands. Those are in turn even adaptive to which "creation mode" I'm in. If I'm in a part, assembly, sheet metal, or whatever: there's a different menu showing up! That's not all. When doing macros, I can simply record key strokes and menu clicks. But I can also do them in VBA, or C#. But if I'm not into those languages, I can also choose C++ or even plain C. Can you imagine how pure hell it must be to write documentation for it? Or to maintain such software? To help a user which is confused because he switched from the keyboard to the mouse halfway a command, and wanted to finish with a mouse gesture? Probably, if I did my job of explaining these things well, by now you can. Then why all those efforts? Colliding visionsBecause - after all - learnability, or approachability is only half of the story. "Ease of use" is the other. Like the AutoCad example shows: For me, it may be easier to use the CLI. For someone else, it may be easier to use the newest and smartest bleeding edge interface. It changes from person to person. And moreover: It changes depending on how much you use the program! Surely, when one starts learning AutoCAD, the first time one draws a line it will probably be done from the mouse-button in the standard button-menu displaying a big fat line. But if one uses it everyday, it's kilometres of mouse traveling!Also, the Gnome interface guidelines state if the "undo" button sometimes doesn't work, better remove it from the program. Well, on a daily basis I use a program with an untrustworthy flaky undo function. But whenever it functions, on those rare occasions, it saves me minutes not having to start over! I'd rather have something flaky than nothing at all. So, learnability may be 'orthogonal' to 'ease of everyday-use'. That's something which is sometimes lost in these discussions. Approachability is not equal to usability! Recently, I tread to learn vi. It's really, really hard. On the "learnability"-component of usability, vi scores really sub-zero. But then, if you discover great commands like the global function 'g', how to use registers and macros, you really learn cool stuff. And you're really orders more productive. Probably the same as learning C# or VBA. Both of which I still don't master at all, even if multiple times getting my hands wet with VBA. But I know, if I master them, I can do great things and avoid the human having to do boring, repetitive and error prone tasks. One would almost conclude learnability and ease of use are almost complementary: Programs which are among the most 'easy' to use for daily users, may be the hardest one to learn! And those who are easy to learn, may be a nightmare to use everyday. Now, putting both components of usability and both above approaches 1) and 2) together, let's see if we can reconcile: ConclusionUsability really depends on how much the user will use the program. And it depends if the user easily adopts to new shiney great ways of doing things. Or on the other hand stubbornly continues to use the seventies-way of doing things, like yours sincerely. Who by the way was born about a decade after said seventies, which goes to show how effective some seventies-interfaces were. If you use software for hours and days consecutively, it's not a big problem it's hard to master and a hell of a job to learn. No problem if the help looks 'scary', because the program is so flexible. Because eventually, all that confusing flexibility will save time. However, for those programs one only uses from time to time, like say - for most people - retouching photos, it would be better to take the first approach. Now say, Gnome or Unity, or maybe Apple or whatever adopt only 1): Then those who use it for hours a day and for several days a week will probably feel like their usability was not a concern. However, if programs like AutoCAD or SolidWorks only adopt 2): Then there's a huge threshold for people to start using the program. It's really almost impossible without a multiple-day training! If Linux only adopts way 2), the usual complaining is the result: "It's to hard to learn, the help is not complete, there are bugs, I need the CLI to do things!" In the ideal world, a program would have a Lite / learning mode, which enables for any task one only one way of doing things. It should come with matching "lightweight"-help, which only displays the most easy way to do something. And then the user can put the program in "advanced" mode, progressing from way 1) to 2). However, that would be a monstrous task. So, those who develop user interfaces could probably better take into account how much the average user may use something. And - hopefully - have several apps to do tasks: Notepad for those who only once in a while type texts and change configuration files. Vi for those who do it hours a day. Image viewer for those who only view some photos, and stuff like GIMP/Photoshop for those not minding learning Scheme or using it day in, day out. Paint for those only drawing a box once in a week, and AutoCAD / Solidworks etc. for those who do it daily. Also: "Which users do you aim for?" If you aim at those who normally wouldn't touch a computer, learnability is more important than everyday-ease-of-use. If Ubuntu wants 100 million users, they have to attract lots of those people. Hence, they emphasize on learnability. And not those pesky types with rectangular 16:10 eyes who spend hours a day behind a desktop, like yours sincerely. If Apple or some company want to create a media consumption device where the user only rarely has to 'interact' because most of the times they're consuming information, of course way 1 is much better, as there's far less overhead and confusion. Now, for those LXer types who in this 'mobile-hype' world swear the desktop will not die and desktop programs will remain relevant, way 2 is much better. When you switch between the two paradigms, some conflicts may arise however. Which explains why a Gentoo-user would probably not be happy with an iPhone, et vice versa. In all honesty: I'm pretty satisfied with the result of my contemplation myself. Now, next time if there's a flame-war about the direction Gnome or KDE is going, or if Windows or Mac OS X is easier to use: you my dear reader know how such a flamewar can be resolved. Namely: By taking into account how much a user uses certain features. Only by means of taking into account how much they use it, and how much time they want to spend learning / using it, would it make sense to discuss usability - of any software project or program. Recently I joined the bandwagon of blaming the ones dumbing down interfaces. Of course because ranting is fun. Especially when you can join a whole gang of ranters. But probably also because I use software multiple hours a day, and also use it to create and change lots of information. But taking a closer look at it, both ways have their value. When I were to invest my money, it sure as hell wouldn't be in desktops or liaised companies. And when I were to learn new programming languages, it wouldn't be 'legacy desktop programming' languages. Of course, when a program changes from one way of interfacing to the other, conflicts occur, but that doesn't have to be the end of it. Because eventually there will always be both the people new to certain or all software, and people who use software day in day out, so there will always be software for both type of people. Given enough volunteers, patience and participation we'll all be able to happily sing Kumbaya together** - and live will be great. ed 16-07-11: OK, I forgot to add my explanation of the bold title, but I hope you got it by now: Gnome and Ubuntu really, really understood the 'learnability' component of 'usability'. And they did a great job when it comes to that part. When it comes to learnability, other projects can really take an example. But the other part, ease of everyday use, it seems they lost that aspect out of sight. So, they only did usability 'half'. Still a terrific job, but still half. * "beloved" refers to the software, NOT the behaviour of the company! AutoDesk - just like Dassault, PTC, Siemens and those other CAD-programs offer their users lots of choice, as long as it's Windows. You're on UNIX? Bad luck. Microsoft successfully lobbied all those companies into ditching UNIX, because otherwise I can't explain how those companies support 10 different ways of doing things - but not UNIX ** Thanks - my fellow LXerers - for learning me this phrase! |
|
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| Actually Usability != Learnability (at least for some) | stw | 14 | 3,431 | Jun 22, 2011 6:36 PM |
| You lost me... can you dumb it down a bit more...??? | masgeeks | 10 | 3,140 | Jun 16, 2011 6:30 PM |
You cannot post until you login.