Difference between revisions of "User Interface Analysis"

From EUDP
Jump to: navigation, search
(How)
(How)
 
Line 14: Line 14:
 
*    [[Class Diagram]]
 
*    [[Class Diagram]]
 
*    [[Use Cases]]
 
*    [[Use Cases]]
*    [[Function Analysis]]  
+
*    [[Functionality Analysis]]  
  
 
'''Process'''  
 
'''Process'''  

Latest revision as of 11:21, 12 November 2019

What

User Interface Description

How

The dish

User Interface Description

Ingredients

Process

First, determine what type of interface the future users can use: Web-interface, traditional program windows, special designed interfaces, etc.

Select the Use Case with the largest amount of user interaction. Build some kind of prototypes - typically, the prototypes do not contain any functionality, but only show the interface.

Write a scenario to "play" with a user representative. The scenario should contain interactions and system reactions as a real user and system would interact and respond. Prepare manual insertion of data in data fields, or print a number of copies of the user interface filling in the data manually or in some other way fake a system response.

"Play" a user session in cooperation with representative(s) from future users. Note all feedback and change design until the user representative(s) are satisfied.

Repeat if necessary with a number of user interfaces representing different use cases - still with a high degree of customer or user representative involvement.

Rewrite any Use Cases that may have shown not to be complete or correct understood.

Consider any changes in the Class Diagram and State Machine Diagrams and redraw as necessary.

Include the final prototype examples into the documentation.

Why

User Interfaces are typically an area where the customer or others representing the future users of the system-to-be can relate to with more enthusiasm than any other area within system development. Users can seldom be abstract and think the system-to-be, when it is not at all defined. The user interface is the gate to data kept in the system. How data are kept or how data are manipulated is often not at all interesting for the user. What is interesting is the way the users can access the data. Hence the User Interface Analysis is typically done in cooperation with the user representative.

As described the User Interface is the users access to data in the system. It is through the User Interface the user can read, update or perform calculations on the data.

The first and most important issue is to determine how the user can interact with the system. Is it through web-pages, an ordinary program window, through a special designed display and buttons, etc.

Web-based services have become more and more important leaving the customer free to choose the operating platform for the users. Web-interfaces can be established on a number of platforms ranging from special designed systems - even handheld - to standard desktop computers. By using web-interfaces and a careful implementation, there should be no limitations as to type of browser and computing environment the end user uses.

Ordinary program windows are very effective, when the users always use the same platform to access data in the system. If the customer can declare that a specific platform always is available for the end user, it is probably the most effective interface to data. But remember limitations are introduced by requiring a specific type of hardware and operating system.

Specially designed displays and buttons are suitable for embedded solutions, where the system for example controls some type of electrical or mechanical system. Be careful in the design and build prototypes early in the process enabling the users to test it.

Prototyping is probably the most effective way to get feedback from end users. With modern Rapid Development Tools it is possible to build examples of the user interface rather quickly and change the design while discussing with the users.

Often when discussing interfaces with the users, the developer gains insight into details that are not covered by ordinary Use Case Analysis, because the Use Cases tend to be too abstract for the user - it is a theoretical description of the usage. On the other hand, the developer can hardly build prototypes without some level of Use Cases to start with. The developer therefore experience that the process has to iterate quite a number of times between user interface design and use case analysis and even the class diagram changes as the insight gets deeper.

A fine way to get users response is to set up a scenario where the developer and the user representative can "play" situations almost like a real user and system would interact and react. Do not waste much time on preparing program responses, it is quite effective to print a number of copies and write "system responses" on the copies. Keep the prototyping as simple as possible.

Example

Power production.jpg

Daily

Weekly

Monthly

Yearly

Click on one of the links to see power production for different time periods.

Scenario: Let the user click on the links and change the graph accordingly.