AnEasyInterface

ThoughtStorms Wiki

GrahamLally (writing in response to my stuff on CroquetOperatingSystem / SmalltalkNeedsANewUI) :

Not sure that making things "simple" is alone justification for "progress". Real functionality needs to be a). simple and, most importantly, understandable to start with, but then needs to b). allow the user to perform activities without constraint. So you have a scalable interface that meets the needs of both newbies and power users. Currently, for instance, Windows does the former extremely well, and *nix does the latter. However, "next-generation" solutions should not concentrate on one particular extreme. A different paradigm might be used, but it should still allow for this scalability.

The web interface is now so popular partly because it is simpler than, say, command lines, but mostly because 1. it restricts the interface, but to one that the user is comfortable with and 2. everyone has software access to it. However, it does not scale well - a simple example being using webmin interfaces to administer a box versus editing of config files. The former makes sense if you're starting out and are unfamiliar with config files, but the latter is faster when you know what you're doing. Other common functions, such as linking data, editing data, etc etc, would be relatively simple under a Wiki-based approach, but could be a lot simpler and a lot faster under a drag-and-drop system.

It kind of depends what you're used to, and right now, everyone knows what the web does. (There are still plenty of people that aren't necessarily comfortable with browsing, and for them, even a Wiki-based approach would be just as confusing as a desktop GUI.)

– graham.

I agree that there will always be a need for two different kinds of interface : one for naive users and one for expert users. The difference, as I see it, is that naive users are those who don't have an internal model of the system (or some metaphorical interface to it) Thus naive users need that model represented explicitly - one control (checkbox, textbox, button or menu-item) for each action they need to perform - so they can read the functionality of the system from the interface. The interface decomposes complex ideas into a sequence of self-evident steps.

Expert users, on the other hand, do have an internal model of the system and remember it's capabilities and some way of refering to each of them. Thus they can enter commands which include references to multiple actions, composed grammatically.

Neither of these approaches is inherantly "simpler" or "easier" than the other. Both offer advantages to their respective audiences. (That's not to say that there can be better, easier and simpler examples of both kinds.)

I do think that in general there's a bias to equate "easy" and "user friendly" with the naive interface. I think this is wrong, but understandable because there are more naive than expert users in the world.

There are a couple of interesting (and I think related) problems.

Is there a middle way? Can we take advantage of a bit of both? Or is that a chimera which will appeal to no-one?

How can we enable the transition from naive to expert use? Are naive users getting locked into naive interfaces, so that someone who's been using one for years, is still working laboriously, when they could, by now, have learned a far more concise way of achieving their task?

I've never seen a good middle-way interface, but I think I've seen clues towards it. Such an interface must allow multiple actions to be composed so that complex things don't have to be done by exhaustive manual manipulation. But, at the same time, your options and state should be readable from the interface.

Here are some helpful things that are moving towards that.

Auto-completion. On the Linux command line obviously. Also I've been using Microsoft studio recently (!!!) and it has auto-completion of function calls.

:MS Studio also impressed me in that when you write a call to a method in the same class or module, the argument signature appears floating above your cursor, so you can start writing the method without looking back to remind yourself what arguments it takes and order they come in. I've found this very helpful as my short-term memory for this kind of thing is lousy. Maybe other IDEs have this too?

: Autocompletion is something which supports both complex composition (you are composing a complex instruction linguistically) and reading from the interface (it's suggesting what can come next)

: While I'm being nice about Microsoft. One thing they always got right was that everything in a properly written Windows program can be controlled from keyboard shortcuts. And you can always read what the keyboard short-cut is because of the "underline the letter" convention on the menus and button names.

Wiki and wiki-markup

: Wiki, like all web-pages, allows application and documentation to be seemlessly mixed. Pages can fire off functions, while at the same time documenting those functions. Wiki can implement a wizard-like interface, where you navigate through a task in simple steps. At the same time wiki allows you to compose your own control panels and views to speed up the access to the functions that mean most to you. (See WikiAsUltimateUserConfigurableApplication)

Absolute and relative addressing of SpreadSheet cells. The old convention of starting with absolute references to cells, and then hinting with the $ sign that these addresses were relative seemed very powerful to me. I could prototype a calculation, then generalize it across rows. I guess another example is when you copy the look of piece of bolded, Ariel, 24 point text into a new style.

: thought ... do spread-sheets still do this $ thing, or do they just guess these days?

: (See more on ConcreteToAbstract)

Debate

No need to think of naive and experts seperately

: I agree that there will always be a need for two different kinds of interface : one for naive users and one for expert users.

I don't think that was what Graham was saying - and I would certainly disagree. There isn't a need for two different interfaces. For example Photoshop can be used by artistic illiterates like myself to do basic tasks, and by expert users to perform tasks that (to my naive eyes) look like magic.

It is possible for interfaces to scale from naive to expert if designed appropriately. You don't have to have a different kind of interface for the two user groups.

I think you might be being a little to focused on tasks based on manipulating text (all your examples are text based). Not all tasks are text based and, importantly, not all languages are text based either.

Coders have tendency (and I include myself in this :-) of looking at everything through text-based interfaces since that's often how they interact with the world.

: I do think that in general there's a bias to equate "easy" and "user friendly" with the naive interface. I think this is wrong, but understandable because there are more naive than expert users in the world.

How are you defining "easy" and "user friendly" - I think they must be different from the concepts in my head for the second sentence to be true :-)

I agree I'm biased towards text. That's because a linguistic interface is the only thing I can think of that avoids direct manipulation of objects / options one-by-one.

As far as I can imagine (not having a photoshop expert to observe here right now :-), expert use of Photoshop is probably about knowing where all the obscure options are, and having a mental model to predict their effect. Does it also involve knowing higher level ways of manipulating a number of options at once?

I'd love to see a GUI that allowed composition of multiple activities, say by painting them on top of each other. Or that allowed mixing commands as though mixing colours on a palette. – PhilJones

Yes some of Photoshop's top end does involve higher-level manipulations. For example you have direct access to a "history" of the operations on an image. You can use this both as a view to undo multiple operations, and a way of taking a group of operations and customising them into stand alone functions.

However, this is unrelated to the point I was trying to make :-)

A well designed GUI enables a user to easily migrate from the common options to the more complex ones as they need them - so a single GUI can support both beginner and expert usage.

You're making the assumption that an expert interface means that you have to have these higher level abstractions. Is that always true?

Defining an expert as "somebody who needs a linguistic interface", and then saying that only linguistic interfaces can support experts, seems like cheating to me :-)

– AdrianHoward

What is expert mode?

Thanks, this is helping clarifying things in my own mind.

I guess what I'm saying is this :

becoming an expert in a domain generally involves achieving a higher level of abstraction. You understand (and can manipulate) general principles behind things. You summarize large chunks of complex ideas with special vocabulary (or gestures)

I think an interface that supports experts should therefore have some recognition of this and support for the higher level abstractions that experts need. And an interface that supports the transition from naive to expert user, should support the user's learning curve about these abstractions, and

I don't think that this support needs to be linguistic. I accept that being able to go into your history in Photoshop and pull out a sequence of transformations as a macro is an example of this. As are macro-recording facilities in word-processors and SpreadSheets. Word styles are another example.

However, non-linguistic access to higher level operations is pretty feeble. In most of these recording cases, if you need to edit or perform some other transformation on the macro, you revert to writing code. I don't know what happens in Photoshop. Is there a scripting language?

So this is an area of UI design I think is a) under-investigated and b) very interesting. How to support this transition. How can the UI help the user up the gradient.

There may be two approaches to this :

** we can find other non-linguistic ways of representing high level transformations. (Eg. a mixing pallette for effects, where you prepare a blend of 30% blur, 40% highlight, 30% increase contrast etc.)

** we recognise that ultimately, the high level will require linguistic manipulation and we try to smooth the path of the naive user this point. For example I think our current GUIs train people to be pathalogically averse to any non WYSISYG elements or text representation. People today are afraid of the kind of markup which was standard use on a word processor 20 years ago.

** Maybe we could make the transition easier if we stop trying to hide the linguistic component. Imagine if Photoshop had a command line always at the bottom of the window. Which showed the linguistic representation of every action (just as the box at the top a browser shows the page URL). Tutorials may encourage users to set parameters in this line, to get them used to working there ocassionally. Then as the user moves to higher level transformations she notices that remembering the command is easier than three layers of pop-up menus. (Although she is always given the choice of the latter.)

– PhilJones

To summarise your summary :-)

You propose:

becoming an expert in a domain generally involves achieving a higher level of abstraction

an interface that supports experts should support higher level abstractions

non-linguistic access to higher level operations are currently pretty feeble

Some things to consider:

What higher level abstractions does an expert user of a supermarket checkout machine have over a beginner?

I used my great-grandfathers woodworking tools when I was a kid. He was an cabinet maker. I made go-carts that fell apart after a week of abuse. He (I assume - never met :-) had a great deal of abstract knowledge that I lacked relating to working with wood. Yet we could use the same tools.

– AdrianHoward

OK, the craft thing. You're right that there are some domains of expertise where tools don't support expertise. And expertise is embodied. The nervous system automatizes and a collection of routine actions get chunked. Guess this is the case with supermarket checkout expertise. However, this is an impoverished domain. Once you've basically got your speed up, there's no-where else to go to improve the "art" of checkout operation.

The woodworking example (as with painting, plastering etc.) is more interesting. One idea is that these are a collection of implicit body skills, like checkout operation but in a richer domain. Right now, I can't think if there's something else. But it maybe that there are some tools which can't br tailored to naive or expert users. (Compare musical instruments where all expert adaption must be by the user)

– PhilJones

Rather than saying that there are some tools that cannot be tailored for both naive and expert users (which implies a lack in the tool) perhaps you should consider the idea that there are some tools that don't /need/ to be tailored for naive and expert users (which is saying something about the tool design and/or the domain).

– AdrianHoward

What is Linguistic?

I also think you need to be a little careful with your use of "lingustic". Which, according to Webster's is:

: Of or pertaining to language; relating to linguistics, or to the affinities of languages.

So sign-language, body language, speech, signals, etc. are all included under the term. What you seem to be talking about is much closer to text-based programming language... or am I misunderstanding you?

– AdrianHoward

: maybe a better word would be grammatical. Anything where symbols can be composed according to grammatical rules, and where the way they're combined affects the meaning. This would certainly include sign-language and speech. But I might not accept that non-grammatical signalling systems are really languages at all. Despite what the dictionary ... Oh!!! I just fell into your trap, didn't I ;-) By asserting that the definition of language is grammatical compositionality, and having previously said that an easy interface needs to support expertise through compositionality and abstraction, I've ended up defining an expert as "somebody who needs a linguistic interface", and then saying that only linguistic interfaces can support experts Damn! You're good, Howard! So for my claim not to be vacuous, I need to define "language" independently of "expert thinking" and I can't use "compositionality" in both cases.

: Or maybe I can. Higher level abstraction requires compositionality of several thingies, they could be symbols, gestures, modes, functions, operations, circuits, widgets, whatever. I'll define "linguistic" as something which allows the grammatical composition only of symbols (however these are understood) . So I allow that there may be compositions of others types of thingies which are not symbols but which count as higher level, more abstract expert knowledge. And a non-symbolic, non-linguistic interface could capture them.

:: Here is an example for non-symbolic composition: Car mechanics have a wide variety of tools at their disposal, as many different tools as they can afford, generally (this is in part a signal of their expertise). Some special-purpose proprietary tools are only useful for a particular make and model of car. However, beyond a certain point the sheer number is overwhelming, and a compositional approach is used instead. The most common of these tools is the box-wrench, which have many differently sized heads that can fit into a generic socket, one or two handles (which can be adjusted to ratchet clockwise or anti clockwise), and several extensions, u-joints, and other attachments designed to convey force from the handle to the head through different angles and distances. – MichaelBernstein

: Let's see if I can try to think of a concrete example. Here's one, though it's not very original or interesting. Imagine an application controlled by dragging data objects around a desktop and and dropping them on a number of control icons. A version of this interface optimized for naive users will put the control icons in fixed, well classified positions. This supports naive users finding them (the icons are where the manual says they are, and grouped by conceptual similarity.) However, an expert might use several sequences of operations she reglarly carries out. And, in fact, it would be more convenient for her to re-organize the layout of the icons to support these more easily. If the interface allows her to explore and reorganize the layout of these icons (in a comfortable way) it's supporting her expertise. Ideas about the higher-level abstracted notion of tasks are represented by "composition" in that activity spaces are composed out of arrangements of icons. But this isn't "linguistic" because nothing is composed out of symbols.

: (NB: I'm aware that this kind of user configurability isn't very popular with some Human Factors people. But I suggest that's because most human factors measurement techniques are aimed at naive and general users rather than experts. They'd probably have a hard time measuring what was right about the organization of the tools in your great-grandfather's workshop too. Maybe there's a connection here to our discussion of the production line in ProductivityOfKnowledgeWork. Maybe interfaces aimed at the naive users are, by definition, for non-skilled (or deskilled) workers. Expertise demands that pertinent knowledge (including of the ideosyncracies of the user and her work context) are put back into the system.)

– PhilJones

Understanding of easy

In general I think we have to be very careful about over-general assumptions about what is easy and what is complex. One of my favourite phrases when dealing with somebody in any specialised domain is "You're not normal". Phil - you're not normal. Neither am I. We're both deeply techie coders who've been playing with computers since we've been knee high to a grasshopper. Our view of the world and what is complex and what is simple is skewed. Our view on what methods and techniques there are to solve problems are skewed. We always have to remember that.

– AdrianHoward

: Hey, just because you're in a minority doesn't mean you're not right. Earlier on I said it was natural that UI Designers focussed on naive users because they're in the majority. By definition experts are not normal. But that doesn't mean we shouldn't design interfaces to teach and support expertise. My gripe is that UIs provide no migration along that path and are locking users into a begginers' mode of operation.

– PhilJones

The point I was trying to make (and obviously failed ;-) was that because you and I are programmers we tend to view tasks through programmer eyes. When I come across a problem that can be solved using programming techniques I do so. I find writing programs simple - but this may have nothing to do with whether programs are actually the simplest solution for a particular problem. It also may have zero relevance to the "naive" / "expert" divide.

If I write a program to solve a particular problem is it because:

writing a program is the best solution

there isn't support for a non-programmatic solution (but a non-programmatic solution may be possible)

I find writing programs simple (but there are equally effective non-programmatic techniques)

The answer is probably "It depends on the domain". However I suspect that more things fit into the second two categories than you think ;-)

– AdrianHoward

Even if we agree, why not support experts who could use a specialized interface?

Been following the thread a bit, thought I'd jump back in :) Actually, this should probably be a different page... I'm not going to comment on the differences between users, but rather ask: Is there a niche for designing interfaces focused even more around functionality than currently exists? By this, I mean that instead of taking the functionality of computers and trying to shoehorn it into a simple interface that is easy to pick up, we actually look into a system that makes any arbitrary task easy once you know how. This would entail a steep learning curve, but great reward.

Still a bit unclear. OK...

Current text-based CLIs are born out of a non-graphical era more through necessity than design.

This approach is hard to learn for people not used to it, hence graphical UIs (although people still struggle with Windows)

But those who do use it are proficient and can achieve complex tasks very quickly.

Current Interface design is towards making things simple.

Why not look into making things faster to perform, once you know how to do it?

The grammatical/linguistic approach is the obvious example, but there are a hundred other ways to use a keyboard, assuming that we're sticking with the

legacy input device. Control codes and keyboard shortcuts are examples of both how the field could be evolved, and how interfaces can offer a secondary path of user advancement, but the former is what I'm on here. Could you use meta-commands to control information and data flow, maybe in the same way as we use pipes in nix to flow information from command to command? For instance, you choose the data you want to process, whether it be a file, text stream, image, etc, and then hit a series of control codes to perform a series of actions on it. Something like that. You could undo your actions, branch them and have different flows, etc etc. I think there's a lot of unexplored potential for making computers faster* for those who have the time and motivation to learn how to do so.

Thoughts?

– graham.

Rather than adding more and more features for the mythical “power user”, or swing to the other end of the spectrum and dumb-down the interface for the mythical “average user”, smart developers are learning that good defaults and elegant interface design makes software better for everyone to use, regardless of their level of experience. - [The http://www.actsofvolition.com/archives/2004/april/theriseof The Rise of Interface Elegance in Open Source Software]

– AdrianHoward

(See also FreeSoftwareInterfaceStories)

Actually I don't know how good his argument is. Basically he says :

a) Sometimes good design means removing cruft and unnecessary options from interfaces

b) there aren't power users and average users.

a) Sounds OK, but seems a bit trivial as he doesn't actually offer any deeper theory of how to recognise which options are cruft. Options which aren't used much? Options that average users don't need? What?

b) his argument is just that a power user on one piece of software isn't necessary a power user on another. Well, duh! But the fact that PhotoShop expert isn't also an Emacs expert doesn't have the slightest implication for whether PhotoShop expert's UI needs are different from PhotoShop newbie's UI needs.

– PhilJones

If (a) is a trivial observation why do so many people seem to miss it on a regular basis? Look at all the places where applications develop by the accretion of features over time and become an unusable mess :-) I think it's something that bears repeating.

I disagree with your (b). He's not arguing that there are no power/average users. He is also not arguing that power users in one domain are not power users in another.

As I read it his main argument was that the novice/expert divide doesn't have to affect the UI. You can create applications that support both groups equally well.

– AdrianHoward

I read this as saying "why not support expertise anyway?" I suspect there could be a market for this. Just as Apple branded themselves as an interface for "creative" people. And Linux is partly understood as an interface for "techie" people. (Of course Adrian as an Apple loving techie will disagree :-)

: Not at all :-) Apple has a history of branding itself as producer of products for "creative" people. However, this doesn't mean that they're not useful for other tasks too. (I also think this has changed a bit recently. Apple has been paying a lot more attention to pushing its hardware and software at technical people. Whether this is a deliberate ploy or just another turn in Apple's developer love/hate cycle I'm not sure.) – AdrianHoward

Nevertheless, I think now the market should be big enough to sell suped-up powerful interfaces to self-styled experts.

Graham's example makes me think of games, where we find the opposite phenomenon to my "naive lock-in" : GrognardCapture.

Why in games? Presumably because games are things people do for fun and are willing to invest time in learning. Something similar seems to happen in some music software (complicated and made worse by trying to look as similar to old analogue equipment as possible. Even drawing the fucking screws on the control panels.) Maybe music downloading software could go this way too.

Ok, and here's a page for fantasizing about TheUltimatePowerInterface.

– PhilJones

https://robhaisfield.com/notes/removing-gui-elements-as-the-user's-skill-level-increases