Chapter 9: Software Posture

1. Chapter 9: Software Posture

2. Platform Platform - the combination of hardware and software that enables the software to function • desktop software • Web sites and Web applications • in-vehicle systems • handheld devices • entertainment systems • professional devices Describes a number of features such as physical form, display size and resolution, input method, network connectivity, operating system and database capabilities.

3. Posture Posture - the program’s behavioral stance - how it presents itself to the user May be bold or timid, colorful or drab but should be so for a specific reason A product’s look and behavior should reflect how it is used – not just an aesthetic choice

4. Posture Posture - the program’s behavioral stance - how it presents itself to the user Three primary postures for desktop software: - sovereign - transient - daemonic

5. Sovereign Programs Often the only program on the screen - monopolizing the user’s attention for long periods of time • offer a large set of related functions and features • users tend to keep them up and running continuously • usually used maximized Typical examples: word processors, spreadsheets, etc.

6. Sovereign Programs • optimize for intermediate users – most are only initially a novice user • take as much screen real estate as possible • default to a maximized presentation • use a conservative visual style

7. Sovereign Programs Appearance: - muted colors and texture; user will be staring at the display for long periods of time. - buttons, icons, sliders, rulers, etc. can be small - subtle but rich visual feedback (status bar, caption bar, system state, indicators of various types)

8. Sovereign Programs Feature rich input: - every frequently used feature should be controllable in several ways (direct manipulation, dialog boxes, tool buttons, key sequences) - use direct manipulation idioms that make demands on fine motor skills - use corners and edges of window for controls Document centric applications: - child windows containing documents should be maximized - not all document centric applications should exhibit sovereignbehavior

9. Sovereign Application Program:

10. Transient Programs • temporary in nature ; manipulates a document but only does some very simple, single function • often serves in a supporting role to a sovereign program • since interaction is brief, the user doesn’t • become very familiar with the transient program

11. Transient Programs Appearance: - keep to one main window, controls at the top, not hidden on the side or bottom - boldly designed controls - large buttons with large font legends - needs to occupy minimal screen real-estate - must be moveable - bright colors, animated buttons ok - avoid interaction requiring small motor skills, nothing smaller than 20 pixels - memory of previous size and placement better than any default

12. Transient Program

13. Daemonic Programs • programs that do not normally interact with the user; • serves quietly in the background • - often used for managing processes

14. Daemonic Programs Appearance: - interaction between user and daemonic programs is transient and should use the rules for transient interface design - allow access through an on screen icon or better yet through a control panel program

15. Web Postures Informational Sites - sovereign for frequently accessed sites where content is updated daily - transient for less frequently accessed, cookies for minimal effort to find previously accessed info Transactional sites - sovereign for frequent access, typically work based - transient for infrequent access, personal use on a weekly or monthly basis

16. Design for Handheld Devices • Integrate functionality and minimize navigation • Models should reflect size, shape and articulation of the physical device • Decide whether operations will primarily on-handed or two-handed • Satellite (accessing and viewing information) or standalone (focus on a narrow set of functions) • Avoid use of pluralized and pop-up windows

17. ???

18. Chapter 10: Orchestration and Flow

19. In order to create flow, the software must become transparent FLOW flow - a user’s ability to concentrate on an activity

20. Guidelines to Increase Flow follow mental models - user forms a mental image of how the software performs its task - the mind looks for a pattern of cause and effect direct, don’t discuss - the ideal interaction is like using a tool - interaction with the tools should not include a discussion - direct manipulation is an extension of this idea

21. Guidelines to Increase Flow keep tools close at hand - palettes and toolbars make tools very visible - should be accessible with a single click - info about the current tool should be clearly posted without stopping the action modeless feedback - avoid interruptions for normal feedback

22. Guidelines to Increase Flow harmonious organization / finesse / invisibility - a user interface is an artifact, not directly related to the user’s goals - all elements of the interface should work toward a single goal - avoid flashy gizmos - there are no fixed rules - less is more - group related tasks together

23. Guidelines to Increase Flow possibility versus probability - use the probable choice as a default - actual analysis of user interaction provides the best model quantitative information - give actual numeric values in context - accompany by a graphical representation graphical input - use direct manipulation - label with actual measurements

24. Guidelines to Increase Flow status of program - iconic indicators of what is going on provide templates - something that has a statistically good chance of being correct - provide user with tools for changing it sensible interaction - widgets should behave as their appearances suggest

25. In order to create flow, the software must become transparent FLOW flow - a user’s ability to concentrate on an activity http://www.youtube.com/watch?v=QKh1Rv0PlOQ