Table of Contents

Analysis

Legend: issue to be checked for each developed action/dialog new feature important note advantage disadvantage

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 [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
• 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

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.

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