Transcript Web: Staying Up-To-Date - Ian Graham's Personal Web Site

Web Application Design
Ian Graham
UofT
http://www.utoronto.ca/ian/
Groveware http://www.groveware.com/
Overview
Definition of Web applications
Examples, and options
Issues for design
Technical
Human
Design steps
Examples of design
What is a Web Application?
Pages as interfaces to back-end
databases
Pages generated from back-end data
Focus is on the first of these:
Complex, rich interfaces
Significant programmatic content beneath
(and controlled by) the pages
Web Application Options
Simple applications
Limited functionality (e.g. search tool)
Full-fledged applications
Full-featured (word processor, document
management, etc.)
Middle-level applications
Web-based interaction and management
Simple Applications
Examples
Search a catalog, database
Send a note, or message -- WebForums
First-Generation Web Applications
Simple to use, easy to implement (example1)
Use minimal set of Web technologies
Limited, specific functionality
Full-Fledged Applications
Complex Client-Server Applications
Workflow, document management,
collaboration; complex applications
Problems/Issues
Difficult to customize/adapt
Clunkiness of Web technology
Hard to build easy-to-use interfaces (Java…)
Middle-Tier Applications
Task-specific applications
More complex interfaces, with multiple
pages, perhaps some scripting
Web-based administration, management
Still only perform a limited set of functions
We will be looking at applications of this type
Design Process Questions
User Profiles
Who are the users?
Regular, or infrequent users? Sophisticated?
Task Analysis for Processes
What are the required tasks
Break down into Web-style flowcharts
Security and Access Control
Establish requirements, priorities
Relation to Web Design
Very similar sets of issues
Focus here is on largely dynamic content,
with Web-based control
Management tools are different
Probably Web-based, and integrated within the
Web application
Interfaces more complex, function-driven
Importance of navigation, clear design is
the same in both
Design Principles
Simplicity
Keep interfaces as simple as possible
Functionality
Make sure function of page, or functions
available on a page, are obvious
Uniformity
Use the same design elements
Design Principles (cont.)
Minimalist
Only show functions that are relevant
Navigation
Provide clear, well defined navigation within
and between functions
Helpful
Explain mistakes, or how to do things
User-Centric Design
Design for Users
Understand their needs, requirements
Understand their knowledge, abilities
Infrequent users -- simpler designs
Frequent users -- more complex
designs, tools
Design Process
Step 1 -- user requirements
Step 2 -- transform requirements into
specifications
Step 3a -- Design of software
requirements
Step 3b -- Web interface prototyping and
testing
Design Process (2)
Step 4 -- Design core components of
application
Step 5 -- Usability testing
Step 6 -- Implement all components
Step 7 -- More user testing, tuning -prepare documentation
Design Process (3)
Step 8 -- Release! Is it finished?
Step 9 -- Ongoing support and training
Step 10 -- Ongoing maintenance and
error analysis
Campus Main Event
Web-based list of campus events
Design criteria
Intuitive use by infrequent, non-expert users
Bookmarkable “views” of events
Web-based posting and event management
Security and access control for management
functions
Viewing Events
Calendar and list views
“printable” formats for some views
 click to navigate between different views
Simple select boxes to define criteria for
events being viewed
(example2, example3, example4, example5, example6)
Calendar Views Interfaces
Simple Interface
Function buttons to the left
“Special” functions on top
Title clearly displayed
Intuitive navigation embedded in the views
(change week, go to specific event, etc.)
User-centric Aspects
Usability tested with real users
Features based on feedback
Print-format views
Bookmarkable reference for future use
Administrative Functions
Require User Authentication
Previous pages show ways to login
Authentication reveals additional functions,
areas of the system, depending on user’s
permissions.
Page laid out to distinguish these new
areas of functionality
Structural Layout
Page-related structure
“Areas” denoted by tab bars
“Generic” functions at top of page
“Area-specific” functions in left-hand button
bar
“Page-specific” functions embedded in page
Management Functions
List Tasks and Task Functions
List “management” areas
List “functions” in this management area
Other functions in page content (reuse icons)
Design Implementation
Selecting “management” area changes the
list of “functions.”
(example9, example10)
Function Implementation
Natural starting, stopping places
Often loops, or recursion
Want to guide the user on each step
Provide help where appropriate
Check for, handle and comment on errors
that occur in user input.
Input convenient to user, not software
Functional Implementation
 (example11, example12, example13, example14, example15)
Loop returns to starting location
Reflects changes that have been done
Confirms that changes took place
Pages with errors are reproduced with
descriptions of problems.
Always is a link to cancel the function
modify
errors
start
input
accept, or cancel
Confirm
Page Design and Layout
This Example
TABLEs to define page layout
Design tries to be accessible
Image buttons have ALT text
FORMs are structured to be tab-navigated
HTML 4 has special attributes to control tab
access sequences and key bindings.
Page Design -- Software
No FRAMEs used
Limits accessibility to visually impaired
hard to navigate
breaks up functional components
FRAMEs are, however, useful in
applications, as they let you place
different functional components in
different frames.
Local Programmability
Limited use of JavaScript
Dynamic validation of input
Popup windows; multiple display windows
Use limited by user base
Need consistent deployed script support
Older browsers present problems
Summary
Simple designs/complex applications
Define task to perform before starting
Design constrained by technical limitations
determined by user community
Further constrained by users
User profiles
User requirements (defined by application)
Web Application Design
Ian Graham
http://www.utoronto.ca/ian/
http://www.groveware.com/
[email protected]