Table of Contents
Table of Contents |
---|
Analysis
Info |
---|
Legend:
|
Current Status Analysis
UI Design/Usability Perspective
Metaphors
- admin central
- dialogs
- editing in preview mode (only)
- paragraph - dialog - template relationship
- 4-clicks to edit
Disadvantages
- not robust against errors
e.g. setting a wrong value in the filter config can completely corrupt the whole instance
- missing context
- page structural view vs. content editing view (single page); context is lost when opening a new window
Technical Perspective
Disadvantages
- no standard framework used
- "diverged" control implementations
e.g. a control is extended multiple times, to perform a single change one has to edit multiple files
- no code/model/style separation
- limited extension functionality (tree/list views only)
- highly increased maintainance time
Users & Use Cases
Knowing the user is one of the most important thing when developing a user interface. When designing the interface or when we're taking any decision we should consider the following user roles and their characteristics.
Editor
Characteristics
- usage intensity: layman, little experience
- usage frequency: regularly
- application domain knowledge: none
Tasks
- creating and editing pages/contents
- website
- organizing content (uploading, moving, etc.)
- website
- documents
- data
Manager
Characteristics
- usage intensity: medium experienced
- usage frequency: regularly
- application domain knowledge: none to little
Tasks
- reviewing, publishing/rejecting changes
- configures website sections / mappings between website <-> data module
- configures access restrictions (partly)
Administrator
Characteristics
- usage intensity: experienced
- usage frequency: sporadically
- application domain knowledge: little
Tasks
- configures server infrastructure, subscriptions, mail settings etc.
- installs/configures modules
- configures access restrictions
Developer
Characteristics
- usage intensity: expert
- usage frequency: regularly
- application domain knowledge: advanced
Tasks
- configuring templates
- adding/altering functionalities
- integrating other systems
- ...
Business Goals and Intentions
Main technical goals:
- maintainability
- extensibility
- customizability
Interface design related goals:
- usability (also see DEV:next section@Usability goals)
- contextual working
- hide non-necessary features/functions
- or "show most important functionalities only"
- preserve context
- error robustness
- support learning
- built-in help
- contextual working
- user experience ("joy-of-use")
Usability goals
Usability in general
Controls need to be visible, with good mapping their effects, and their design should also suggest (that is, afford) their functionality. (Donald A. Norman)
Generally usability goals can be categorized in three ways:
- effectiveness
- efficiency
- satisfaction
Basic Principles of Interaction Design
Task Reasonableness
The user should be able to perform his tasks effectively and efficiently.
Availability
- location transparent: browser based system
- avoid/indicate session timeout
Usefullness
- every dialog should hold an appropriate amount of interaction points
- e.g. replace "OK"-only dialogs with status messages (which might disappear after 30 secs. automatically)
Comfort
- show all necessary information
- show links to related sections
- show help topics
Clarity
- supported by interface design (colors, balance, etc.)
- don't show actions that are not required
- always indicate navigational context, therefore use breadcrumb
Self descriptiveness
Is the purpose of the software system perceptible?
It should be possible for the user to recognize the application's data model
There are different ways to provide information...
- as feedback
- on request
- as additional descriptions
Several questions give a hint on the fact if the user is able to perceive the applications state. Those entral questions are:
- where am I?
- "context, context, context"
- what can I do here? where can I go to and how do I get there?
- context sensitive actions/function bars, means that the icons available on the function bar depend on the current selection
- dialogs have clear outcomes
- how did I get here?
- highlight navigation path
- use breadcrumb to indicate navigation path
- even use fade-out effect for last-clicked element
Assessability
Assessable is if the user...
- ...dictates the navigational path
- gets indications for flow constaints appropriately
- modal dialogs
- wizzards
- use steps
- for intermediate steps use "Next" as button label, the last one is labeled with "Save"
- print a message that clearly states if an action can be aborted or not
- ...dictates how fast he passes the navigational path
- allow aborting an action
- ...can decide how he want to access information
- provide multiple navigational alternatives
- browse the menu/trees/lists by using mouse/keyboard
- use short cuts
- use address bar or breadcrumb
- use specific URLs; conflicts with AJAX behavior
- provide multiple views
- list/gridtree
- preview with inline editing
- the UI should indicate
- that specific data can be viewed differently if appropriate
- that regardless of the selected view, the underlying data is the same
Checklist
Are the usable functionalities (in current context) obvious?
- there shouldn't be functionalities that first have to be discovered by (right-) clicking everywhere
- there have to be well-defined places where all possible functionalities can be found/accessed from
- use disable/enable, highlights dependent on the user's current selection to define the context
Is the current application status observable?
- give the user feedback
- loading/progress bars
- introduce a general place for messages (like "caution", "error", etc.) / status bar in normal applications
Is the current application status interpretable?
- indicate if an action will most probably takes a while to be finished
- use an animated item to indicate that the system is still working
- indicate subsequent dialogs by "..."
Does the current application status signal allow a comparison to the users intent?
- percentage bar for huge uploads
Some features (not only GUI related) might help making the application assesible:
- scripting console (5)
- fail-safe mode (5)
Expectation Conformance
Consistent dialog behavior
- if a (modal) dialog has only one outcome, disjunctive UI controls have to be used
e.g. don't use tabs for link selection but radio button list or drop-down control instead
- same labels always indicate the same action
- keyboard shortcuts are used consistently
- a user sees when a conversation/action/screenflow ends
e.g. a save button always ends the conversation, which is indicated by closing the window
Conformance to the users' characteristics
- consider frequency of usage and software system's experience
Conformance to generally accepted conventions
- use metaphors; try to apply desktop application metaphors
Checklist
Are the results of an action foreseeable?
- give visual feedback when changes from in-place editing are saved
- hitting dialog's buttons either triggers validation messages or close that dialog, returning to exactly the state in which the application was before
- use "..." conequently if hitting a button triggers a dialog to show up
Failure Tolerance
Avoid errors
- auto-completion
- converters/formatters/advanced controls (e.g. date selector)
- input validation
- check not only syntactical but also semantical checks
e.g. setting a wrong class for a filter can destroy the whole instance entirely
Signal errors
- provide appropriate messages if validation fails
Provide measures to resolve errors
- tooltips
- show help links context sensitively
Customizability
Customizability is important since we want to increase the efficiency of the application's users which have different experiences on how to work with a software system.
Editors most likely use the mouse to interact with the system. However, expert users might prefer keyboard shortcuts or different window arrangements to perform there task.
Customizations regarding the task that is to be performed
- provide scripting support
Customizations accounting the user's experiences
- user preferences
- provide alternative views
e.g. developer prefers trees or even writing XML files instead of clicking through the UI
e.g. inline editing vs. tree editing
- provide alternative navigation options
e.g. address bar vs. clickable menu
Learning Support
- provide descriptions in dialogs
- tooltips/context sensitive help
- help/documentation links
- re-new knowledge
- tip-of-the-day
Software/Hardware Constraints
Deployment Platform
Info |
---|
Note that it is out of the discussion to switch to another deployment platform with the next release. However, we should discuss different deployment platforms because choosing the underlying technology (JSF vs. Webservices) might have impacts on the options regarding deployment scenarios in the futute. E.g. using JSF will prevent us from (easily) developing an alternative a rich client UI on top of that technology. |
Browser based software system (HTML/JavaScript based)
- simple updates
- scalability
- development experience
- user acceptance/experience
- editing the website directly in the final site design is a good, successful mapping
- usability loss
- bad performance / higher latency
- long response times (user feedback)
- no multitasking (for a single user) / no backgrond task processing, except when fully supporting multiple browser windows/tabs
- not very error robust
- use of browser back/forward button could loose to data loss
- session timeout might cause data loss
- browser/platform incompatibilities
- feature constraints
- no undo support
- limited keyboard support
- limited drag'n'drop support
Compatibility
compatible with Webservices approach
compatible with JSF approach
Desktop application (e.g. Eclipse Rich Client)
Comparison to the browser based approach.
Info |
---|
Legend: means also supported; means even better supported; not or not that good; even worse |
- updates
- scalability
- development experience
- user acceptance/experience
- mapping
- usability
- performance / latency reduction
- error robustness
- platform compatibility
- feature rich
- undo support
- full keyboard support
- full desktop drag'n'drop support
- native look & feel
Compatibility
compatible with Webservices approach
not compatible with JSF approach
Web based rich client (Flex/Air)
- updates
- scalability
- development experience
- user acceptance/experience
- mapping
- usability
- performance / latency reduction
- error robustness
- platform compatibility
- feature rich
- undo support
- enhanced keyboard support
- basic desktop drag'n'drop support (using Adobe Air)
Compatibility
compatible with Webservices approach
not compatible with JSF approach
Software Requirements
Client-side requirements
- browser compatibility: Internet Explorer 6+7, FireFox 1.5+2, Safari 2+3, Opera 9
Server-side requirements
- Java 5
- Servlet 2.4/2.5
Environmental conditions
Metrics (current system)
Some metrics to approcimate the size of the current system:
- more than 45 dialogs
- two structural components: tree, list
- two navigational components: accordeon, context menu
- ~19 controls
Project Runtime
Approximately ~50 work days (including technology evaluation):
- analyses (40%) ~20d
- evaluation (15%) ~8d
- prototyping & test (15%) ~8d
- implementation (first sprint) (30%) ~15d