1cs 338: graphical user interfaces. michael czajkowski, drexel university. lecture 11: orchestration...

1CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.

Lecture 11:Orchestration and Flow

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University. 1

Productive software = Productive Users

Harmonious frame of mind. Flow: Complete absorption on an

activity. Where have you acheived flow?– Writing a document?– Working on a car?– Programming?

How did you get there? What would take you out of flow?

Harmony and Flow


Helping create flow

Users have to have their own motivations.

However: software should be a tool. Software doesn't control you. You

control software.– We're not slaves to the machine!

To create flow: Transparent interaction.– Interface is not a visual artifact!


Following Mental Models

Remember what a Mental Model is? Each user of any interface will examine

the behavior of the interface to understand how it would work, ergo the user expects the interface to behave a certain way when using functionality not previously used.

Can you think of certain Mental Models?– Doctors vs. Hospital Clerks on Patients– Soldiers vs. Generals on Enemy Movements– Pilots vs. Ground Control on Planes


Direct, Don't Discuss!

Do you want a computer engaging in long winded discussions with you?– “Your blah blah blah has spotted a blah

blah in section blah blah of class blah blah. This caused a memory leak at blah blah blah which caused your program to blah blah blah. More information on this blah blah blah?”

Probably NOT! Software isn't human, so why does it

try to act like it is? Its a tool, like a hammer or car.


Direct, Don't Discuss! (cont.) Another thing, modal dialogues:– “Your <incrediably complex technical term>

has an incorrect version <incrediably complex technical term> because YOU haven't downloaded the <incrediably complex technical term> within the past <incrediably complex technical term>.”

Did we lose a war here? Software shouldn't be telling us of its

shortcomings, and its problems unless absolutely vital. It should never demand!

Dialogues: Bad idea! They seem to demand.


Keeping useful tools close by

Tools tools tools, and more tools. Today's software provides a LOT more functionality over yesterdays.

Likely: Tomorrow's will do more! Tools are good to show at the edges

of a window. Tools best belong as icons, pictures

inside of palettes and toolbars. Important Fact to Remember:

GROUPING


Modeless Feedback Modeless: Don't interrupt, but provide

information in a subtle manner.


Modeless Feedback (cont.)

Provide information on edges.


Orchestrate

The User shouldn't even be aware that there is a computer in front of them– Do this, and you get an A+ grade interface!

Orchestration: Harmonious Organization

There are no hard guidelines– 5 buttons here, 7 maximum icons there ...

Remember: sometimes Style Guidelines help.

And it is sometimes obvious:– 73 buttons on six toolbars at the top of the

window. Probably not good!


Finesse: Less is More You want more for less, don't you? Everyone does, its the catch phrase of

materialistic society. Users are humans who live in this society.

They will expect more from the design and get it all done with less space and effort.

A “gaggle” of windows and tons of buttons and tools less frequently used isn't finesse.

Removing File Open, Save, Save As Dialog and instead allow user to perform any of these operations on an explorer shell: Finesse!


Distinguish possible from probable For all i, Ai = true where i=0 to n and An+1

= false. For i from 0 to n+1:– A1 + A2 + A3 + A4 ... An-1 + An + An+1 = false.

But typical humans don't reason like this. They see odds, probabilities. In any large number of n:– A1 + A2 + A3 + A4 ... An-1 + An + An+1 = true!

Don't pretend that just because some unlikely behavior is possible it is probable.

Ex: “Do you want to save Changes to document” after working on it for hours.


Another thought to consider: Learning Software that adapts and finds the obvious. Think about the Junk Mail filter in Mozilla 1.4– Starts out dumb, learns as you use it more.– In the end: It knows probably what Junk is!

Don't repeat the same dialogs over and over again when the choice is almost always the same.– Examples: Save when Close, Spredsheet delete.

Instead: Save dialogs for later, and design solutions for these unlikely events:– Instead: Temporary file, separate hidden buttons.


Provide Comparisons Sometimes exact technical data isn't

needed.– You have 3,212,123KB free– or even: You have 11,231MB free (today)

Provide rough estimates:– People don't want exact information all the

time– “Give me a ball park figure” is more frequent,

an estimation of what is going on.– Allow detail to be available, but not prevalent.

Use graphics to show number estimation, usually pie chart or bar charts work well.


Try to use Graphical Input

Just like they say in Missouri, “Show me!”

Many people rely on graphic descriptions of ideas for conveyment.

Sometimes it is easier to show a computer what you want by graphically providing it.

Sketch it: DENIM, SILK Draw it: Visio, PowerPoint Hand draw it: Whiteboards, Pen input Find the artist within your user!


Reflect the program's status. Computer programs can be:– Busily working on processing a lot of data.– Needing vital information from the user.– In a state of idleness, ready and waiting.

As you might suspect, the human User uses body language all the time to understand what is going on. So the computer should play along:– Status bars, colors changing from start to

finish.– Getting input from the user without

interrupting.– Cursor blinking, mouse in “hand-icon” mode.


Avoid that unnecessary reporting! Don't burden the user on the details of

what is going on behind the scenes. It may alarm them to something very normal.– Your database has been successfully modified.– Attempt connection to the main server.

Everything is all and well, unless it really is not all and well.

The program should do all the dirty work and issue reassuring clues that everything is OK.

Programs should do most of the work without the user nod, we're beyond this technology problem now!


Don't report Normalcy in modal format!

“This alarm will sound every 5 secondsunless something is not OK.”


Avoid blank slates Interfaces shouldn't interrogate you or ask

permission to do everything at the start! Can the notion of “where do you want to go

today”, try starting: “here's a good place to be today”

Users might prefer the program to take a guess at what it thinks is right, and then modify that guess to perfection.

At this point: Interface asks forgiveness! Use templates, previously created document

styles, previous sessions with the interface. Not necessary to reason, just statistically

guess!


Command invocation vs. Configuration The interface should allow users to

command it without specifying details of those commands.– “Check my e-mail” vs. “Specify server,

specify username, specify password, blah blah, ...”

Let the user configure when they need to, but don't constantly ask for information that may not have changed.– “Print document” in Microsoft Word, should

always print to the same printer and never ask for most users. Sometimes a “Print Setup” is needed, but simple “Print document” is just that!


Asking Questions vs. Providing Choice Interrogation places the interrogator

in the superior position. The interrogated party is in the inferior position.

Those in charge ask the questions, those who are not must provide the answers.

Computer interfaces are tools, just like a car or a hammer: They don't ask you, they should serve you!

To serve you better: provide choices in a modeless, non-badgering sense.


Asking Questions vs. Providing Choice For instance: Choice can be a good thing

when presented in a toolbar or combo box.– Small number of icons, and text options.

Choice can be bad when constantly demanding responses:– Do you want fries? Do you want to super size?

Do you want lettuce? Do you want coke? ...... Users don't like questions because they

bring up bad qualities that exist in disliked people:– Ignorance, forgetfulness, weakness, lacking

initiative, unable to fend for itself, fretful, overly demanding.


Hide the ejector seat levers Don't put functionality that:

– Is rarely ever used at all– Only ever used in an emergency– Causes irreversible action– Causes drastic interface change

into places where they can easily be accessed.

Definitely not good for beginners! Puts the user in a seriously bad situation

where they have to deal with consequence of hitting that should-have-been-blinking-red button.

Hide these ejector seat levers!

1cs 338: graphical user interfaces. michael czajkowski, drexel university. lecture 11: orchestration...

Documents