Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Down with the common interface!

By paryl in Technology
Thu Oct 05, 2000 at 12:32:37 PM EST
Tags: Software (all tags)
Software

A user interface is one that will allow the user to get the most out of a tool as quickly and as comfortably as possible. The UI for a hammer is the handle. Since it hasn't been changed in a few hundred years, I'd say it's a pretty good UI. UI's like this are common in many things, from a car to a kitchen sink. So why is a good UI so hard to find on a computer?


I think the problem is that there aren't many machines with as much capability a computer. Certainly hundreds of thousands of programs. Tens of thousands for many platforms. And so you have this multi-multi-function machine that has an enormous amount of possible tools, and you need to give them a common interface. Why?

Let's use Blender as an example. For those that don't know, Blender is a free 3D modelling/animation/game system.

Since Blender was introduced, people have been annoyed by it's UI. If you don't know what I'm talking about, download it (about 2Meg) and try to do pretty much anything. You'll be absolutely lost. I'd dare say you may not even know how to access the main menu. But then you go to the website and click on the gallery... how did people use such an impossible-to-use program to make such beautiful art? Go look at the tutorials, work on it for a month, and then ask yourself the same question. What's amazing about this software is how well thought out the interface is. Even though the inexperienced user can't figure anything out, the one who has taken the time to learn is able to make very -- very -- beautiful and complex scenes from 'scratch' quickly. All the menus are where they need to be. Almost every function has an equivilent hotkey.

People seem to think that because many different tools exist within the same box, that all of the tools should have a similar mode of operation. The Mac interface and the Windows interface follow this same line of reasoning, that every program should be consistent in it's use.

I say that's wrong. Horribly, horribly wrong.

People are big fans of games. Witness the popularity of the console game world. Nintendo, Sony, Sega. But the interesting thing is, none of the games you play for these consoles have similar interfaces. Play Top Gear Rally, and then go play Zelda. Nothing alike, and yet very easy to use on both counts. But wait, they are two different programs with different UIs, they run on the same 'box', and yet they are easy to use? Following conventional wisdom, that doesn't make sense.

Games aren't the only example though. Automobiles, machinery, washing machines, hair dryers... they all have different interfaces. Those tools with simple functions are easily picked up. Those that are complicated require that you go somewhere to learn how to use them. In fact, just like Blender, you may not know anything until you get at least some rudimentary instruction. And yet we still use those interfaces because they best suit the tool.

Now, after all this rambling, what's my point? Well, why should we concentrate so heavily on interface when we should really be worrying about functionality? The best interface won't rescue the worst program. But if a particular software has a function that is very important to many people and yet contains a difficult interface, they will learn the difficult interface to get at the program underneath. Once they learn it though, the difficulty should go away. And that's the point. It should become the "intuitive" interface. Just as the brake pedal is intuitive once you've learned to drive, so should the UI be after you learn a program.

There's nothing wrong with a well-researched UI. It makes it easier to learn. But instead of tripping on that and making a program that is harder to use than it should be, why don't we as developers strive to make the best interface for our particular project? While it may bug some and it may send some people away because of the difficulty, most will find it invaluable and continue to use it.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Blender
o Also by paryl


Display: Sort:
Down with the common interface! | 44 comments (43 topical, 1 editorial, 0 hidden)
Interesting, but I don't fully agree (3.77 / 9) (#1)
by Mendax Veritas on Thu Oct 05, 2000 at 11:17:55 AM EST

If you're going to tell people to go download Blender, you might at least provide an URL for it. Even without seeing it, though, just based on your description, I think I disagree that "most people" will go through the pain of learning a grossly non-standard, hard-to-learn UI when other programs are much easier to learn even if they may not be quite as powerful.

It also matters whether a program is hard to learn because of poor UI design, or because its concepts are not familiar. To someone who only knows simple paint programs, the Gimp is rather bewildering at first, but that has more to do with the unfamiliarity of its ideas than with poor UI design. (I have minor quibbles with the Gimp's UI, such as its use of so many separate top-level windows, but overall it's not bad.)

More generally, I think you misunderstand the point of UI consistency across applications. There is quite a lot of room for different approaches within the constraints of the common interface. Simple rules like having a menu bar that adheres to certain standards (its location, some common terms, standard places to look for things like Open File, Save File, Cut, Paste, Exit, and Help), and rules for how modal dialog boxes and standard widgets behave, do a lot of good without really imposing any serious limitations on the developer's ability to define the "right" UI for his task.

Re: Interesting, but I don't fully agree (2.66 / 3) (#5)
by paryl on Thu Oct 05, 2000 at 11:41:40 AM EST

very true. I tried, but the system wouldn't take my <a href= reference. I ended up just doing without it. sorry.

In any event, it's at www.blender.nl. Before you assume so much about my statement about Blender, try what I said. You may change your mind.

[ Parent ]

Re: Interesting, but I don't fully agree (3.33 / 3) (#7)
by scjody on Thu Oct 05, 2000 at 12:24:12 PM EST

You need to use <A HREF="[url]">, as shown in the "Allowed HTML" section of the form. Yes, the URL is in quotes. Yes, that's part of the HTML standard.

Also, I recently experienced a problem with links from Mozilla. Use a different browser (e.g. Netscape) if this affects you.. When I get the time, I'll figure out if it's a Mozilla issue or a scoop one.

[ Parent ]
Re: Interesting, but I don't fully agree (4.80 / 5) (#12)
by Mendax Veritas on Thu Oct 05, 2000 at 12:54:46 PM EST

Okay, I've taken a quick look at Blender. Obviously, I haven't had enough time to let it grow on me, but I've seen it and read through a beginner tutorial, so as a professional UI designer I think I'm ready to express a few preliminary opinions.

Once you learn this interface, it will be quite fast. The reason for this has nothing to do with its being, overall, a "good" or "bad" design, but simply that it is a very "flat" one. What I mean by this is that there are very few cases where you have to go through two steps to get to something (e.g., to get to the Open File dialog, you just hit F1, whereas in most programs, you click on "File" on the menu bar, then on "Open..."). One exception to this is that the program is very modal, so sometimes you have to switch modes before doing what you want to do. Most of the time you will probably work in one mode for a while, then switch to another mode for a while, so this doesn't slow you down that much. The modal nature of the program, though, is part of what makes it hard to learn.

Blender has some interesting UI behaviors that are unique in my experience, which probably means that just about nobody will figure them out without a tutorial (especially since F1 brings up the Open File dialog instead of Help -- a gratuitously perverse design decision). The Icon Slider button, for example, is quite bizarre. You left-click-drag on it with the mouse, but it doesn't move; instead, the icon displayed on it changes as you drag. This is how you switch modes (although there is also a separate row of mode buttons that you can click for the same purpose -- an atypically new-user-friendly feature for Blender). I'm not quite sure why this is supposed to be better than a conventional combo box, aside from the fact that it's smaller and doesn't require two mouse clicks (admittedly an advantage, but a trivial one, more than counter-balanced by its unfamiliarity). It is definitely unintuitive, though a user who really wants to use the program will get used to it quickly once they've read the tutorial.

There are quite a number of unintuitive (in the sense of "unfamiliar, and you'd never figure it out without help") things in Blender's UI, many of which could trivially have been done in a more standard way. The act of splitting a window, for example, is accomplished by middle-clicking (God help you if you have a two-button mouse and can't chord or otherwise fake a middle-click) on a window border and then choosing "Split" from a pop-up. The window that has focus then splits. Thus, up to three mouse clicks are required: one to set focus on the window you want to split, one on the border, and one on the popup. In contrast, if a common splitter control had simply been placed along one vertical and one horizontal side of each window, one could simply drag them to split windows. Fewer mouse actions would be required, and the cost of a few pixels at the right and bottom sides of each window would be a small price to pay. (Obviously conservation of visual real estate is not an issue, since the "button window" would have been a menu bar or a floating toolbar in most programs. And of course, all this splitting is only necessary because of Blender's rigid insistence on tiling, as opposed to having floating toolbars, or separate windows like The Gimp.)

In UI design, there is a trade-off between ease of learning and ease of use. Usually one balances the two by making obvious, but not necessarily maximally efficient, ways of doing things, and also providing shortcuts for experienced users, such as keyboard shortcuts and double-click actions. Blender's designers seem to have decided that ease of learning was of no interest whatsoever, and made no compromises or provided standard alternatives for the benefit of new users. Nor have they even bothered to be consistent with common standards even when there was no real reason to do otherwise, as the splitter example above shows. They have a very powerful program, but it's UI is not very well-designed, although it is admittedly very usable once you get used to its many quirks. People once said the same of Lotus 1-2-3, pre-graphical WordPerfect, and many other once-successful products from the pre-"common UI standards" era. YMMV.

[ Parent ]

Re: An important point (4.00 / 6) (#16)
by paryl on Thu Oct 05, 2000 at 01:17:16 PM EST

If all I knew was one or two OS's, I might completely agree with you. What you've said is very well thought out, thanks for that. But I think you missed something that could explain why there are strange differences between Blender and some other UI's.

Blender is multi-platform. It has the exact same interface on Windows that it does on Linux/Beos/etc. The reason that matters is that every OS has a different idea of a consistent interface. If the authors were to standardize on a particular UI because they think most are used to it, Blender would be strong on one platform and weak on another.

Personally, and it's definitely MHO, Blender does a good thing in not catering to the common interface. It's unique way of doing things is a welcome change, and I wish more programs would follow their example. You can tell, once you've gotten to know it, that the designers are also users. They use the program professionally, and so they've evolved the UI to work the fastest possible way for a 3D designer. NaN should be applauded for this achievement.

[ Parent ]

You're right - it's all about tools (3.55 / 9) (#2)
by JoshKnorr on Thu Oct 05, 2000 at 11:19:21 AM EST

The thing about a tool, however, is that it's overall utility is both a function of how useful it is and how much time/effort it takes you to get up to speed on it. (I know I'm not using the correct language, but I hope I'm still getting my point across.)

The great advantage about common user interfaces is that learning time applied towards one application that uses the UI reduces learning time for other apps as well. If I spend X amount of time learning application Foo, when I sit in front of application Bar (assuming they use a CUI) my learning time has been cut by some value Y, where Y is somewhere between 0 and X. (IOW: there is still a learning curve associated with different apps, but it takes less time to achieve the same level of proficiency.) This means more time at a peak level of proficiency, which increases productivity - all other things being equal.

That said, why wouldn't someone want to try to follow a CUI? The last paragraph of the article seems to suggest that if a program is powerful, people will learn the interface regardless of difficulty. Furthermore, it seems to imply that time spent working on the UI is better spent hammering away at the program's purpose. This can be translated as either, "UI should have a lower priority than core functionality, so in case of constraints cut UI first." or, "Can't be bothered to put effort into a good UI when I don't really care about it."

The second interpretation is, I fear, one of the reasons why UI development is so far behind the level of excellence found elsewhere in Linux.

The games point is an interesting one that made me think for a second about something that I hadn't before. The conclusion I came to is that while games in general do not have a specific user interface, particular genres absolutely do. FPS and RTS games, in particular, have very similar interfaces to those in the same genre. Most games these days also give users the ability to rebind keys as they want - and speaking from personal experience, the first thing I do before I sit down in front of my new FPS is remap keys so it plays like good 'ol Unreal. Why learn what some other designer thought I should use when I can use what I *know* I want?



It works a few ways (2.71 / 7) (#3)
by Defect on Thu Oct 05, 2000 at 11:20:46 AM EST

Certain types of programs work very well with standard interfaces. Isn't there a special "MS Office" branding you can get if your program looks and acts like the other MS Office progs? In that case, it works out very well; if i'm hiring an administrative assistant, i want him/her to be able to know one program well but also be able to use others without lengthy learning periods.

But when it comes to programs that cater to a more selective croud where ease of use is critical, then a clever and useful UI works well. Programs i can think of are, of course, any graphics program, games, coding environments, and such, where there is too much to be concerned about to deal with UI annoyances.

Having a good UI is part of what makes a good program, no one is denying that, but it's all part of the development process, if you skip over it, you're program will almost definitely fail. It's like not bothering to put sugar in a batch of cookies, you're just screwing up something you've been working on for a while. To /not/ bother with a good UI would be stupid.

The only places i've seen common UI's is on common programs, and i don't see a problem with that.
defect - jso - joseth || a link
Interface consistency and other myths (3.66 / 9) (#4)
by ubu on Thu Oct 05, 2000 at 11:32:11 AM EST

The main issue involved in interface consistency is that it has been elevated to the paramount position in any design consideration. The one-size-fits-all interface concept has been paraded around, over and over, as the Holy Grail of all HCI engineering.

Historically, speaking, much of this stems from the work Apple Computer performed while researching the issue for its Macintosh systems. Unfortunately, while Apple's research demonstrated that consistency has great value, many have taken the results as proof that consistency is the ultimate consideration in UI design.

The time/effort investment required to learn a unique interface is a one-time investment. By contrast, the time/effort liability involved in using a sub-optimal interface -- for the sake of consistency -- is continuous, a pervasive tax upon the productivity of the user.

The vast majority of users and engineers have an ingrained idolatry that puts consistency on an altar, but it's time for them to quit swilling the Kool-Aid. Real progress in interfaces hasn't happened in years -- Aqua and other useless flashiness notwithstanding.

Ubu
--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
Ease of use versus ease of learning (3.88 / 9) (#6)
by Eimi on Thu Oct 05, 2000 at 12:23:36 PM EST

In some ways, I agree with a lot of what you said. For me what matters most isn't whether I can learn to use a program by the end of one day, but rather how fast I can be with it after a month's practice. That's why I use vim. Frankly I almost get sick when I hear the term "easy to use" because it's almost always misapplied, when "easy to learn" is meant instead. I think the problem, at least in the commercial world, is the way that software is reviewed. A magazine gets a copy of Foobar 2.3, and has a few days to review it. If the author can learn it in that time, it must be "easy to use". Otherwise, it must have been hard, right?

On the other hand, having a common user interface for things that really are common is a good thing. I hate the fact that, for instance, the scrollbars on my xterm are COMPLETELY different from the scroll bars on Netscape, and Netscape's menus don't work the same way as GTK's, etc. What I really want is a higher level language, where a program can say "this box has a scroll bar" and I can configure exactly how that should look. Save differences in UI for things that really should be different (does middle-click paste? Is paste a useful op here, or would something else be more meaningful, etc).

I agree... mostly (3.62 / 8) (#8)
by kubalaaa on Thu Oct 05, 2000 at 12:25:13 PM EST

...with the caveat that Blender does have some big flaws. As you said, you had to spend hours reading tutorials. A truly excellent UI scales with the user. This doesn't mean it has to follow the same standards as everything else, or limit its power, but it should have some sort of hand-holding or tutorial mode where it walks you through things as you learn to do them, and gradually adapts to get out of your way as you learn more. You shouldn't have to spend hours reading a tutorial to learn how to use something.

Nautilus is a good example of this; it has expert, novice, and intermediate modes of interaction which hide some of the complexity from people who aren't ready to handle it. The same can be said of MS Word (*gasp* I know); you may hate the paper clip but it is a huge help and comfort to those just starting out.

It also bears pointing out that Blender is a highly specialized form of software; interacting with a 3D environment is not a common task on most desktops, nor are computers well designed for it, so we shouldn't be surprised that it requires an unusual interface. Opening files and editing text, however, are very common tasks that occur across a wide variety of appllications and should be standardized.

Similarly, the general appearance of dialogues and window layouts can, for most applications, be standardized for great gains in usability. For example, the "OK" button should always be in the same place. And almost all applications (even blender) should have a standard menu bar which lets you do things like quit and open a new file, and an obvious, standardized access to help. The uniqueness of Blender should be a worthwhile exception to the rule, not the norm.

Not for the first time, I think Linux REALLY needs someone pushing standards and guidelines for interface and interaction, it's just that the developer community is too damn hard-headed to accept someone telling them what's best. Well, get used to it, you may be a fine coder but you should defer UI judgements to someone who knows what the heck they're doing.

Too many cooks, not enough chefs.

Re: I agree... mostly (3.40 / 5) (#19)
by itsbruce on Thu Oct 05, 2000 at 02:21:55 PM EST

I think Linux REALLY needs someone pushing standards and guidelines for interface and interaction
I totally disagree. None of the GUI interfaces available for Linux are Linux-specific, all of them run on other Unices. You can make a Linux box look like a Mac or Windows box, after all.

Fact is, end-users learn Interfaces, not operating systems. Tech-heads learn operating systems.

This has too implications:

  1. The task of designing good interfaces is not an OS-specific task.
  2. End-users don't have to know what the operating system is, as long as they see a consistent interface.

--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
Not enough attention to HCI (3.25 / 8) (#10)
by cthulhu on Thu Oct 05, 2000 at 12:33:05 PM EST

I think one of the biggest problems is a lack of attention generally given to HCI (Human Computer Interaction).

Perhaps the bigger question is what is the solution? However, this is a very broad subject. For those interested I would suggest the ACM SIGCHI (Special Interest Group on Computer-Human Interaction) as a good starting place.

I'd love to see more 'in-depth' discussion of the subject here on K5 if anyone's really interested.

As a developer, you can refer to a large body of existing literature on the subject. Many of these academic projects are beginning to enjoy commerial success, such as the evolution of KidSim to ToonTalk, as well as StageCast Creator.

Blender URL (3.40 / 5) (#11)
by kubalaaa on Thu Oct 05, 2000 at 12:52:49 PM EST

I posted this as an editorial earlier. For anyone who didn't catch it, here's the URL to blender if anyone wants to see for themselves:

http://www.blender.nl

Disagree to an extent (4.00 / 6) (#13)
by Delirium on Thu Oct 05, 2000 at 12:56:10 PM EST

I'd have to argue that there's some benefit to having an at least somewhat standardized UI. This doesn't mean that everything has to be identical, just that some common things are in common places. People often cite games as being an example of applications without a standard UI, but I'd have to disagree. Say you want to bring up an options menu - in nearly every game you do this by hitting Esc. If you had to hit ? in some games, o in others, and Esc in others, wouldn't that be a bit confusing? Now of course the in-game interface is customized for each game, but even there the UI tends to converge on a standard for each type of game, simply because it's easier. I like the fact that I can use nearly the same mouseclicks and hotkeys in Age of Empires as I can in Starcraft, and that my controls in Halflife are nearly identical to the controls in Quake 3 Arena.

The same goes for applications - if I want to save a file, I want to be able to find the damn "Save" function without looking for 20 minutes.

So I think the goal should be to have these common functions have common locations, and customize the parts ofo the UI which are truly unique to the function of each particular program and make it truly a better UI. Designing a new scroll bar, for example, when a standard scroll bar would work perfectly fine, is not helpful.

Now it probably seems like I've just said "use a common UI when a common UI is good and a unique UI when a unique UI is good," which is pretty much the case. =P My point, however, is that I'd disagree with the apparent conclusion here that making a program nearly impossible to use without reading a tutorial several hours is good UI. The basic functions of the program should be more easily discernible than that, but conforming to an absolutely rigid common interface, I agree, is not necessary.

One example which comes to mind off-hand is the GoldWave sound editor (for Windows). The basic UI of the program follows the standard Windows UI - I can figure out how to open a file, save one, find menu functions, etc. with a minimum of difficulty. However, highlighting a region works by left-clicking to move the left bound of the region and right-clicking to move the right bound of the region. This breaks the common UI model of clicking and dragging to highlight a region (which most sound editors also stick to), so it may be confusing at first, but it's such an incredibly useful function that it's worth the effort.

So, in conclusion, only diverge from a common interface when you have a good reason to do so. Making an interface non-standard should be considered initially a negative point, and only implemented when the benefits of making that particular bit of UI nonstandard outweigh the inconvenience of it not working like a user would expect.

Of course. (3.71 / 7) (#14)
by Inoshiro on Thu Oct 05, 2000 at 01:09:16 PM EST

While "form follows function" may take longer to learn, you only have to learn once. And once learned you can use the system more effectively and efficiently than any "function follows form" system. Few things lend themselves to desktop metaphors. That's why I think we'll see more interesting UIs for computers in the future. The older people who have closed their minds and decided that learning new things is too hard are going to die of old age soon enough, allowing for proper progress.

I'm happy that Gnome and KDE exist not because we need a "desktop metaphor for Linux/Unix," but because they provide important functionality (DnD, session management, etc). Beyond that, there are many other interesting approaches coming :)



--
[ イノシロ ]
Re: Of course. (3.50 / 2) (#20)
by Pimp Ninja on Thu Oct 05, 2000 at 02:21:59 PM EST

Not entirely true, you know... You have to learn many times, when the UI changes from task to task. That being said, the effort is worthwhile simply because, once you've learned that particular UI, you can now be more productive in the long run... All in all, given good design, a worthy investment of time and effort, no matter how many tools you have to do this for.

-----

If we demand from them without offering in return, what are we but better-
dressed muggers holding up the creative at the point of a metaphorical gun?


[ Parent ]
Reasons for Consistency (4.00 / 8) (#15)
by Simon Kinahan on Thu Oct 05, 2000 at 01:11:36 PM EST

Consistency has become something of a Shibboleth with some people. I remember spending hours trying to make an old Smalltalk app conform to the Windows UI guidelines better than most Microsoft apps. Gah !

However, there are good reasons to promote consistency. Where a user will use several tools together to perform a task, its important that those tools operate in a similar way. The more one tries to follow a "small tools" philosophy, the more important that becomes. Have you every come across a command line tool that tries to interact with you, but you wanted to use it as a filter ? Irritating isn't it ?

There's also the fact that naive users usually do not think in terms of applications, they just think about the computer. When "the computer" suddenly changes the way it interacts with them, they get upset. Thats the philosophy behind Apple's insistance on UI consistency.

Simon

If you disagree, post, don't moderate
Depends on the goal of the end user (3.57 / 7) (#17)
by Thaniel on Thu Oct 05, 2000 at 01:32:51 PM EST

If all you want to do is jump into an image editing program, make a little sketch, save, print, then close it, and you do this about as often as you vacuum under the couch, then you want Paint. The UI is intuitive, simplistic, and gets the job done. In this case the point is to have an ultra-low learning curve so you can do basic stuff easily.

However, if you work as a graphic designer for a 500 employee web development team, and every day you're making fantasticly complex 3D images, then you probably want Blender or 3D Studio Max, etc. Their learning curve looks like the Cliffs of Insanity from The Princess Bride. But, you can do some really amazing stuff with them, once you know how. And although I'm sure it's technically possible to make a 1600 X 1200 image of a chrome ball hanging over an ocean of rippling water in Paint, it'll take you half your lifetime to do it. Even someone moderately skilled can make that same image in less than 10 minutes in 3D Studio Max.

The point of all this is, there's a definite trade off between the learning curve and the power of the product, where power includes the functions it supports and the speed at which you can do complex tasks. One is not "better" than the other, they're just "better" for certain tasks.

But as the original article is pointing out, a lot of companies fail to realize just to whom they're targetting their product, and try to squash everything into a standard Windows UI.

The right tool for the job (3.28 / 7) (#18)
by jabber on Thu Oct 05, 2000 at 01:54:59 PM EST

The keyboard, monitor and more recently the mouse, are all a part of the UI as well, if you think about it. They haven't changed all that much over time, because they work well.

We've tried touch-screens, and they've not really caught-on, except in certain fringe applications (fast-food registers, ATMs). We've tried light-pens and digitizers and tablets; and these have also been moderately successful on the fringe. Same with keyboard variations and the number of mouse buttons. You get my point.

The thing is, outside of a generic set of UI metaphors, such as overlapping windows, icons and pull-down menus there's really too much difference between applications for a unified interface. Applications differ in purpose and functionality, and the ways in which people use them differ as well. You hardly need a keyboard for Gimp, but just try using MS-Word without one.

Application UIs are designed with the usage of the application in mind, consistency with the rest of the OS/desktop is secondary. And this is how it should be - except maybe for a consistent color scheme and widget 'look and feel' - but then again, 'skinning' has pretty much gone completely counter to that idea. An GUI that forces consistency will be seen as Draconian by all but the sheepiest of users, and one that encourages customization will always evolve into a hodgepodge, except in the hands of anal retentives like myself.

Applications in the same genre vary in the UIs, because, frankly, they all do pretty much the same thing - and if they all looked the same way then the only field left for competition would be cost.

So, in effect, the inconsistencies exists so that the users could work in a way they find most convenient, and since people are different, so are interfaces.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

UNIX is a consistent interface. (3.40 / 5) (#21)
by JML on Thu Oct 05, 2000 at 02:53:35 PM EST

This article really echoes the views in a comment I posted recently (of course I was talking about a completely different blender). Nice to see I am not alone in my views.

This brings up another thing that has always bugged me. I view Unix and Unix like systems as all being a consistent interface to a computer. I use Linux and Tru64 in my day to day work, and I think of them as being very similar. When I start using a Solaris or AIX system, they are really pretty much the same. Sure, the admin might have put things in /usr/local/gnu/bin on one machine and /usr/local/bin on another, but that is just a matter of adjusting my .cshrc, and then the interface is the same.

Using the MacOS or Windows is completely different interfaces to a computer. On those systems I have to click on a bunch of stuff to see what files I have, why can't I just type ls? And how do I click a -Slra?

See, a completely different interface to the same hardware and files.

I think this idea of microtuning the interface of different programs to be identical is silly. Sometimes it might make sense. No particular reason why cutting and pasting text in different programs should use different commands. Kind of nice how the cut default in Netscape 4 for Unix/Unix-like is the same as in Emacs. I think the app-defaults file even says something about pandering to Emacs weenies.

Re: UNIX is a consistent interface. (3.00 / 3) (#23)
by paryl on Thu Oct 05, 2000 at 03:08:25 PM EST

d'oh! I never saw your comment. :) Well, I hope this was a good article to post anyway.

That's a really good point about the CLI. I was referring more to GUI's, but the arguments are really the same. The thing that makes it possible for you to put Unix on your resume is the fact that most are very similar in commands, applications and interface. Just imagine if every Unix had a different form of GUI. X here, Y there, Z way over there. Even worse, if they each had their own shell. No grep? Aaaah!

I definitely agree with your point on the basic functions too. I like Ctrl-C for cut. I like Ctrl-V for paste. Those are so ingrained I don't think I'll ever get rid of them.

[ Parent ]

Re: UNIX is a consistent interface. (4.33 / 3) (#30)
by JML on Thu Oct 05, 2000 at 05:21:06 PM EST

That's a really good point about the CLI. I was referring more to GUI's, but the arguments are really the same. The thing that makes it possible for you to put Unix on your resume is the fact that most are very similar in commands, applications and interface. Just imagine if every Unix had a different form of GUI. X here, Y there, Z way over there. Even worse, if they each had their own shell. No grep? Aaaah!

What you are talking about has come about. The "traditional" Unices are really pretty similar, but MacOS X, which certainly is a Unix-like system, has a very different user interface from other Unices. If I were given a Mac with OS X to use, I would have to make the interface consistent with what I am used to. That would mean installing all the gnu utilities, emacs, TeX, and all those good things.

That is really what I meant. I have never really understood the complaint about an inconsistent interface under Unix. It all seems pretty much the same to me.

I think when people complain about this, what they really mean is

  • This interface is not like a different one that I am already used to
  • These two programs don't work the same (of course not, they do different things), and I am too lazy/stupid to learn how to use them both


[ Parent ]
Re: UNIX is a consistent interface. (4.50 / 2) (#31)
by paryl on Thu Oct 05, 2000 at 05:31:17 PM EST

  • These two programs don't work the same (of course not, they do different things), and I am too lazy/stupid to learn how to use them both

    No doubt! I don't want to call them stupid, but they are definitely lazy. You go to the trouble of getting a license to drive, you go to the toruble of learning how to use a new dishwasher, you may even learn to use all the functions of your TV, but you don't want to go to the trouble of learning [insert software title here]. What's sad is how often an IT person runs into this.

    [ Parent ]

  • Cutting and Pasting Under X (3.00 / 2) (#34)
    by kraant on Thu Oct 05, 2000 at 07:23:41 PM EST

    Dudes you've been MSwindowsfied "[cntrl] v" and "[cntrl] c" aren't the standard cut and paste tools for X...

    Firstly there is the middle mouse button...

    Select something.... Position your mouse cursor where you wish to paste press the center mouse button. This will work with almost any x application...

    Secondly there is [cntrl][insert] and [shift][insert] these work happily between xterms a lot of other things even under fvwm... Unfortunatly trying to past something in netscape with [shift][insert] is a sure fire way of crashing it....

    Heh
    --
    "kraant, open source guru" -- tumeric
    Never In Our Names...
    [ Parent ]

    Re: Cutting and Pasting Under X (3.50 / 2) (#35)
    by FunkyChild on Thu Oct 05, 2000 at 10:36:44 PM EST

    The problem with the 'standard cut and paste tools for X' right now, is that the raw X method (middle-click) only works for plain text.

    What you said is precisely why we do need a common interface for things like that. You've just mentioned 3 different ways of cutting/pasting in X, which would be fine, if only they *all* worked.

    It would be nice if the KDE/gnome/whatever people could implement a sort of middle click pasting for other content like images, files etc. But because of how the different Linux DEs try to make things smoother for the Windows users, they've resorted to the CTRL-X CTRL-V method.


    -- Today is the tomorrow that you worried about yesterday. And now, you know why.
    [ Parent ]
    Re: Cutting and Pasting Under X (4.50 / 2) (#36)
    by inpHilltr8r on Fri Oct 06, 2000 at 05:49:51 AM EST

    Dammit, credit where credit's due, {command,control}-Z, X, C, and V for undo, cut, copy, and paste are the original Mac hot-keys. Add S, N, P, Q, and W, for save, new, print, quit and close window, and you have the basic hotkey set that any sane (obscure pun intended) mac application adhere's to.

    (On-topic aside, the (one true mac) debugger, failed to adhere to any of these, yet possesed more power than a mac developer could dream of, indeed, more power than any debugger I've used since.)



    [ Parent ]
    Consistant (2.40 / 5) (#22)
    by westlake on Thu Oct 05, 2000 at 03:05:19 PM EST

    Well, it's pretty hard to come up with a consistant anything these days, especially in the US (I don't know enough to speak for citizens of other countries) With patents and copyrights being given for everything down to the number of times you have to click a mouse to get resluts (watered-down, I know, but that's the gist), anyone wanting to maintain a UI consistant with something alreay existing, then they basically have to run the risk of being sued by half a dozen other people. They can maintain consistancy among their own products (a la the Microsoft hegemony), but industry-wide consistancy is practically illegal nowadays.
    (BTW, someone below mentioned the UI for a hammer being the handle. I wouldn't be suprised if someone has at one point thried to patent even that...)

    Yet another fine example of anarchy in action
    Appliances will solve this! (3.50 / 6) (#24)
    by 11oh8 on Thu Oct 05, 2000 at 03:22:29 PM EST

    I think Blender was used as a in-house tool in a design house in Europe before being GPLed... SO the UI was catered not to computer users at large but to the small group of designers who used it actively (on a daily basis).. They had the time to learn it well and cared more about ease of use rather than ease or learning....

    Also, i agree with the original poster that computers are so difficult to use (and unstable, unrobust, etc) because they are super-multi-purpose machines... They simply do way too much for the average joe... Once computer like appliances become common, i think that a lot of these issues will be solved (or simplified).. A good example is the palm pilot. It has a easy to {use|learn} interface.. It's a quite stable OS due primarily to it's simplicity.... I envision that in the next 5 to 10 years, most people will be using simplified computers that will be able to offer reliability, stability and ease of {use|learning} at the cost of limited capability... and of course, for people like me (computer geek), i'll still be able to use more complicated OSes that offer more choices....

    Basically, there is a compromise between ease and power... A Good UI can offer a little of both without making compromises but that can only help a little.. Once we have more specialized machines, the compromises made can be the ones the intended audiences would like (more power/choice for me.. ease of use for some others)...

    $.02,
    11oh8

    Analyzing the hammer (3.66 / 6) (#25)
    by jblocksom on Thu Oct 05, 2000 at 03:26:08 PM EST

    The hammer in my toolbox is one foot long. It's head is only two of those twelve inches, meaning that the part of the hammer that does something is really only 16% of its major dimension. The weight distribution is the opposite -- the head is far more dense than the handle.

    Now, if 84% of a projects code were invested in the UI, then it would probably have a darn good interface... even if the 16% that actually does something is much more complex.

    JB

    PS: I think Blender's interface is lousy.



    Re: Analyzing the hammer (2.50 / 4) (#26)
    by paryl on Thu Oct 05, 2000 at 03:32:00 PM EST

    Do you use Blender regularly? Have you tried to learn it?

    [ Parent ]
    Re: Analyzing the hammer (2.00 / 2) (#39)
    by Luke Scharf on Fri Oct 06, 2000 at 04:34:25 PM EST

    Now, if 84% of a projects code were invested in the UI, then it would probably have a darn good interface... even if the 16% that actually does something is much more complex.

    How is this relevant? Hammers and computers perform very different functions, so such metrics don't make sense to me.



    [ Parent ]
    Re: Analyzing the hammer (3.66 / 3) (#42)
    by Anonymous 6522 on Mon Oct 09, 2000 at 12:48:44 AM EST

    A hammers handle has a very important function, it acts as a lever so you can hit things with the head harder. If hammers didn't have a handle, you might as well use a rock. If you use a rock anyway, add a handle and see how much better that is.

    [ Parent ]
    Consistency in Game, and other, UI's (3.33 / 6) (#27)
    by Mouse on Thu Oct 05, 2000 at 04:06:53 PM EST

    People are big fans of games. [...] But the interesting thing is, none of the games you play for these consoles have similar interfaces.
    Speak for yourself. Some of the games I have played recently do share many UI features, even though they were written by different companies.

    Examples: "Deus Ex" and "Thief II" use a similar convention for object activation: left mouse button (by default) to use the object you're holding, right button to use the object that's highlighted in the world. That's different from other games I've played. And both these games have a button on the startup menu to play the game's intro movie, which I haven't seen elsewhere. Perhaps these, and other similarities, are not coincidences -- both games are published by Eidos, and Warren Spector was involved in the design of both "Deus Ex" and the original "Thief".

    Second point: Do you think lack of UI consistency in games is a good thing? I find it to be an annoyance that necessitates re-learning a lot of reflexes that I've spent hours practicing in another game.

    Certainly, different games that are designed to provide very different experiences should use UI features that are tailored to their requirements. But having many different ways to do similar things in different games is simply annoying.

    And that is true of any other type of software too.
    -- Mouse

    Re: Consistency in Game, and other, UI's (none / 0) (#41)
    by WWWWolf on Sun Oct 08, 2000 at 09:14:57 AM EST

    Speak for yourself. Some of the games I have played recently do share many UI features, even though they were written by different companies.

    I think Golgotha (by former Crack Dot Com) advertised itself as having "the most Doom / Command and Conquer-like interface you can get" or something similiar. =)

    People get excited when they get this Cool New Game people have been talking of. They want to put the CD in, start the installer, and then play the game. In the ecstacy, they may find referring to the quickstart guide boring.

    Second point: Do you think lack of UI consistency in games is a good thing? I find it to be an annoyance that necessitates re-learning a lot of reflexes that I've spent hours practicing in another game.

    Yeah, I just hated it when I had to spend hours trying to make MechWarrior 3 behave more or less like MechWarrior 2... =)

    -- Weyfour WWWWolf, a lupine technomancer from the cold north...


    [ Parent ]
    The author doesn't get it... (3.90 / 11) (#28)
    by Millennium on Thu Oct 05, 2000 at 04:25:55 PM EST

    Now, after all this rambling, what's my point? Well, why should we concentrate so heavily on interface when we should really be worrying about functionality? The best interface won't rescue the worst program.

    All the same, the best program is worthless if no one can use it. Which is precisely why vi and GIMP aren't more popular; both suffer from awful interfaces, even if their functionality blows the competition away (as a side note, the GIMP 1.1 series is doing somewhat better with its interface, now that they don't make almost all of the menus count on a function you can't even assume your user has or has mastered: namely, the right-click).

    No interface is intuitive right off the bat. But as programmers, we have a responsibility to our users to flatten the learning curve as much as possible. Interface standards aren't there to "constrain creativity." They're there to standardize interfaces for common, mundane tasks.

    For example, let's compare two common Windows programs: Word and Excel. Very different programs, doing very different things, but they do share a few things. Both can cut, paste, copy, and whatever. Both allow the user to enter text, though for different purposes. Both allow the use control over font face, color, size, etc. In fact, these are very common functions that many programs have.

    By standardizing the interfaces to these, learning curves are considerably shortened: if I know how to cut and paste in Word, I can cut and paste in almost any program, right off the bat. I only had to learn the interface for these one time, rather than again and again for each program.

    But programs also do different things. These are where interfaces start to diverge. But they stick to the standards for mundane tasks, and this is a Good Thing.

    Interface standards don't constrain developers. Quite the contrary; they free developers from worrying about interfaces for the common stuff, so they can design good interfaces for the things that make their programs unique. And by doing so, they make their programs easier to learn overall, because a person can jump in and do the most basic things right away, and move on to more advanced concepts immediately.

    A hammer, a wrench, and a screwdriver all do very different things, but you'll notice that the handles all look similar. Again, there's a good reason for it.

    By the way, the interfaces to any two console games on the same platform, if you'll notice, also stick to standards when they apply. You can normally count on Left to move left, Right to move right, Up and Down to take appropriate actions based on the point of view, and Start to pause and maybe bring up a subscreen of some kind. If you're on a driving game, you can pretty much be certain that one of the buttons on top of the control pad (usually the one closest to your right thumb) is the accelerator, and the one right beside it is the brake. In platform games, the button closest to your right thumb usually jumps; in shoot-em-ups it usually fires. So there are standards even in console games, and yet you find these "natural." You know why you do? 'Cause they were standardized.


    What's the fun in being "cool" if you can't wear a sombrero? -Hobbes


    Re: The author doesn't get it... (3.80 / 5) (#29)
    by paryl on Thu Oct 05, 2000 at 04:40:24 PM EST

    By the way, the interfaces to any two console games on the same platform, if you'll notice, also stick to standards when they apply

    Well, your point is kinda useless there. Compare the controller or gamepad to the keyboard/mouse on a computer. Of course they all use basically the same functions. I wouldn't expect the X key to show J when I type it. Certain dedicated keys have certain dedicated functions. Unfortunately, that has nothing to do with the original story.

    If you'll notice, each game has a particular on-screen interface which is different. That's the point. Even though all the menus look different, even though you may navigate the menus differently, they are still easy to use. Perhaps this is because of good design, perhaps it's because the controller is very simple. Whatever the case, my original point still stands: they are different and are still easy to use.

    [ Parent ]

    Re: The author doesn't get it... (3.33 / 3) (#37)
    by Millennium on Fri Oct 06, 2000 at 08:10:32 AM EST

    Compare the controller or gamepad to the keyboard/mouse on a computer. Of course they all use basically the same functions. I wouldn't expect the X key to show J when I type it. Certain dedicated keys have certain dedicated functions.

    And why is that? Because that part of the interface has been standardized more than any other. How else could QWERTY have survived for so long in the US when better layouts are available?

    Unfortunately, that has nothing to do with the original story.

    Does it? It seems to me that it does.

    If you'll notice, each game has a particular on-screen interface which is different. That's the point. Even though all the menus look different, even though you may navigate the menus differently, they are still easy to use.

    Except that they're not really different. The look may differ from game to game, but the feel is almost identical. The first major game with a menu system was the original Legend of Zelda. Its paradigm: a subscreen, activated by pressing Start. You navigated the menu with the cursor and selected the item you wanted to use. You could also view various bits of useful information.

    This system is, with minor modifications, now used in almost every game I can think of that supports menus (the only one I can think of which is truly different would be the Seiken Densetsu/Secret of Mana series, and while the games are great their menus, set up as rings of icons, are most definitely not intuitive). The early Megaman games experimented with a dialog-based interface, but this gave way fairly quickly and hasn't been seen since Megaman 3 for NES (and even the dialogs borrowed many concepts from Zelda, and stayed consistent from game to game).

    The point is, look and feel are two very different things. Feel, however, is by far the more important of the two; look can be changed without affecting anything if the widgets are still identifiable (but the reverse doesn't hold). This is why gaming interfaces seem so natural now; they may look different, but the feel was standardized long ago.


    What's the fun in being "cool" if you can't wear a sombrero? -Hobbes


    [ Parent ]
    Slightly offtopic (3.83 / 6) (#32)
    by aenomie on Thu Oct 05, 2000 at 05:44:17 PM EST

    Am I the only one who is getting more than a little annoyed at the current trend in application specific UI design towards using silly real world object metaphors for certain applications; the best (worst?) example of this being the absolutely inane use of the thumbwheel volume control in the latest version of Quicktime. Also, I noticed while reading Ars Technica's review of the Mac OS X beta that the included MP3 player looks just like a cute little Diamond Rio device Interestingly, these trend seems to be centered around multimedia applications. Practically every software DVD player that I've tried tries to emulate a handheld remote control. To me, this type of thing is very detrimental to UI use and efficiency.

    Re: Slightly offtopic (2.00 / 3) (#33)
    by paryl on Thu Oct 05, 2000 at 05:55:35 PM EST

    The viewer that came with my TV tuner card uses a stupid looking remote control. What's even worse, even when the control is active it doesn't allow numpad input! So you have to actually click 2 then 1 in order to go to channel 21. ugh.

    [ Parent ]
    Why UIs aren't always intuitive... (3.00 / 5) (#38)
    by karnos on Fri Oct 06, 2000 at 04:11:05 PM EST

    I was just thinking about the same kind of thing while at the arcade today. How is it that I never have to read instructions before I play a new game but I have to take weeks to get all the features out of Emacs? The answer is REALLY obvious. There are about ten primitive functions available in most games. Usually less. All the great stuff comes from the sequence or combinations of these primitive functions (like sliding the joystick in a semi-circle and pressing a button for a fireball). These higher level functions take much longer to master and use skillfully. That's why you're not good at 007 the first time you play. Sure, you can do every possible action--you can move, duck, shoot, punch, etc.--but you can't yet synthesize meaningful meta-actions. So, the interface is easy for games at a reductionist level. The interface becomes full of nuances and specificity at a high level. Most computer apps, non-trivial ones anyway, have the same hard interface. In fact, one could argue that the interface is pretty easy for all apps on a low level. There's a keyboard and mouse. The mouse has two buttons. Easy. Again, it's the sequence that one presses all these buttons that illustrates true mastery over the higher level interface. There might be a case for saying that more levels exist in the computer app than the game. In a game there's the buttons and joystick. In apps there's the keyboard and mouse (and haptic bodysuit if you're lucky). In games the next level is overall understanding of the domain and how combinations of buttons and joystick swivels affect it. In apps, there might be two more levels. For instance, a word processor has a rather plain domain of typing and seeing. But there's more function that can arise from the edit menus. And a higher level can arise from creative uses of the text paradigm and the typeface/style/arrangement features. These higher second level functions--the edit menu, etc.--are functions that come from mouse and keyboard functions. And there are a lot of them. And there's no good way to reduce them that hasn't been done. Try to break BOLD down into elemental ops. It's hard. So, when the second level has extra functions, it's inescapable if the true power of the app is to be gained. So, this is getting quite long and I hate thinking so I'll sum up. Some applications are not going to get intuitive interfaces. If something is really powerful, really robust, really cool, it, by definition, must have an array of primitive functions that can't be broken down. This can occur on several levels, too. The end result is a hard interface, but a powerful program that can be used for hundreds of unrelated activites versus the simple one-use of a game.

    Console games have a very consistant interface (3.00 / 1) (#40)
    by ewan on Sat Oct 07, 2000 at 06:58:49 AM EST

    If you write a game for a Dreamcast, a Playstation, or an N64, before it can be released it has to be approved by the manufacturer of the console. Part of their testing system checks the interface against the standard specifications provided to the developer at the start of the process. If the game doesn't conform, it won't be released.

    That's why almost all console games are very easy to pick up and play without reading the manual, the interface has been thought of for a long time over the last 20 years, and the best setup selected as a standard by Nintendo, Sony and Sega.

    Ewam

    Why leave the UI to the programmer? (4.00 / 1) (#43)
    by freakazoid on Tue Oct 10, 2000 at 06:57:17 PM EST

    Why should the programmer control the interface when it's the *user* who actually has to use it? There is no way that a programmer can anticipate all the ways hir program will be used; this is one of the fundamental tenets of programming, and it's why the UNIX paradigm has lasted so long: simple tools that each do only one thing that when combined can do just about anything. The problem is that the UNIX interface is still esoteric.

    What the programmer should be doing is providing a set of building blocks and a set of reasonable defaults for how those building blocks fit together. If the user wants to, s/he can rearrange these building blocks and possibly send the programmer feedback that may improve the defaults that s/he includes with the program.

    The programmer doesn't even need to provide an interface for changing the interface! All we need is a consistent way to define the interface, something along the lines of Glade, but that's capable of handling information flow in addition to just user interface elements, kind of like shell scripts or Labview. Then others can build their own interfaces to modify this interface definition.

    Anyway, just a thought, but I do think this is the future. This is what object oriented programming was *supposed* to provide.

    Re: Why leave the UI to the programmer? (none / 0) (#44)
    by shrub34 on Thu Oct 12, 2000 at 05:15:59 PM EST

    I agree with this view of each tool doing its thing well.

    This idea has me thinking about rewritting some applications such that each "view"(or what ever you call things within a frame), so that I could re-plug it into another application.

    I'm glad someone described this view to me.

    =====
    It's good to see the BSD community forking and execing so many child processes.

  • Comment about editor of Daemon News not attending BSDcon 2000

  • [ Parent ]
    Down with the common interface! | 44 comments (43 topical, 1 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!