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

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 Direct, Don't Discuss! (cont.) Another thing, modal dialogues: – “Your has an incorrect version because YOU haven't downloaded the within the past.” 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 Modeless Feedback Modeless: Don't interrupt, but provide information in a subtle manner.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 Modeless Feedback (cont.) Provide information on edges.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 Don't report Normalcy in modal format! “This alarm will sound every 5 seconds unless something is not OK.”

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 Command invocation vs. Configuration The interface should allow users to command it without specifying details of those commands. – “Check my ” 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!

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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.

CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University.1 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!