Re: fundamentals of the gnome user interface




> a few of my classes have dealt with psychology; i think it's important
> to introduce gnome programmers to some basic psychology of learning
> before allowing them to create a medium to be learned (namely, a gnome
> app). therefore, i propose the following be included in the fundamentals
> of the gnome user interface. this proposition is not meant to be
> included verbatim in the user interface style guide but discussed and
> reworded for conciseness. everyone please respond.

A good approach.

> 
> people who use tools generally take one of two approaches to learning
> its use:
> 
> 1.) "browsing." this approach is generally used by people who need to
> use a tool to complete a specific task but are not required to master
> its use to increase productivity. an example of "browsing" would be a
> typewriter user who looks at the letter printed on each keycap to
> determine which one to press to achieve the desired result. although a
> user can often become quite skilled at quickly finding the appropriate
> key locations as they become accustomed to using them, they will never
> be able to type more than about 30 wpm due to the limitations of using
> one or two fingers and having to see the letters on the keycaps in order
> to use them. this person expends the least amount of time figuring out
> how to operate the equipment, completing the task they need to complete
> and not thinking further about the potential of his tool. he is a
> productive person because he completed the task with the tool at his
> disposal in a short amount of time.

Keep the ceiling in mind, as well -- The QWERTY keyboard layout was
originally designed to -impede- the user's ability to type -too quickly- ,
and in doing so, jam the heads of the typewriter. 

In my book, that move sucked. Rather than cripple the user's capability to
type quickly, i'd be more inclined to find a better way of building a
typewriter -- so that the heads *cant* be jammed, even when typing
quickly. 

The same should go for any style guide. Construction guidelines for user
interfaces should NOT be written in such a way as to dumb-down the user's
ability to utilize a specific tool. One button mice, and single-tasking
OS'es are the hallmarks of that mode of thinking. *hint hint*. :) 

> 2.) "memorizing." this approach is used by people who need to use the
> tool regularly to produce several similar desired effects in a minimal
> amount of time. this person needs to use this tool as efficiently as
> possible to maintain high productivity. an example of "memorization"
> would be a touch typist who can type over one hundred words per minute
> on a typewriter by looking at the source document, rather than at the
> paper output or at the keyboard. this person has spent a long time
> becoming very familiar with his tool, makes maximum use of each of his
> ten fingers, knows the layout of the keys subconsciously so he does not
> have to waste time creating a new association between a control and its
> desired reaction.

We worked on this with InSight for a short while.. Working on a
standardized set of icons the user could assign meanings to, and
interconnect like legos to form somethign resembling a crude macro
language. The idea was, that people could record their actions, describe
them symbolically, and just "build" their actions into a program.

I like your idea. Underestimating or ignoring the user's capacity to
remember is a grave mistake -- Also, keeping a mind to reducing the number
of "layers" a user must plunge through to accomplish a task is very
important.

> gnome application developers must honor each of these two approaches to
> tool usage. although the tool must be ultimately "discoverable" by
> people in group #1 through use of clear and easily self-explaining
> controls (more about those in a later post), they must also allow quick
> access to these same controls through the most efficient means possible
> for those in group #2 who take the time to learn them and desire to use
> them productively as a matter of routine.

Amen.

Bowie




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]