Difference between revisions of "Interface Conception & Design"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(52 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<accesscontrol>UIE,,</accesscontrol>
{{Template:TemplateUIE_Activities}}
{{Template:TemplateUIE_Activities}}
<div style="float:left; width:70%; margin-bottom:3em;">
<div style="float:left; width:70%; margin-bottom:3em;">
From early drafts to productive use, each interface is designed and visualized using interface '''[[GUI Prototyping|prototypes]]''' to provide an outlook on the solution at an early point in time.
Short iteration cycles enable usability evaluation right from the beginning. Optimized information architecture and navigation can be designed in close cooperation with users, making usability more predictable.
== Introduction ==
== Introduction ==


Line 10: Line 13:
== Pattern Library ==
== Pattern Library ==


[[Image:rz_grafik_4.png|right|275px|UIE-Process ]]
[[Image:g593.png|right|275px|UIE-Process ]]


Within the institutes of the Max Planck Society there are many different needs for new or improved software solutions. It is almost impossible to build individual GUIs on top of them.
Within the institutes of the Max Planck Society there are many different needs for new or improved software solutions. It is almost impossible to build individual GUIs on top of them.


Interfaces developed by UIE use basic patterns, based upon a style guide for web applications. As far as possible, new services are built on reusable components, so that new interface elements will be implemented along with proven ones. Every component has a defined pattern, CSS definitions and (JavaScript) behaviour and is documented in detail.
Interfaces developed by UIE use basic patterns, based upon a style guide for web applications. As far as possible, new services are built on reusable components, so that new interface elements will be implemented along with proven ones. Every component has a defined pattern, CSS definitions and (JavaScript) behaviour and is documented in detail.
'''Establishment of an Architecture (See Picture from Bottom to Top)'''
#Structure: Starting with abstract representation of an pattern
#Visual Design: Styleguide definition for the pattern
#Development: Definition of reference-HTML snippets
#JSPF side: Integration of snippets
'''Introduction of a Pattern Taxonomy'''
#[[User_Interface_Patterns#Organizing_Layout_and_Display|Organizing Layout and Display]]
#[[User_Interface_Patterns#Navigating_Functionality|Navigating Functionality]]
#[[User_Interface_Patterns#Display_Data|Display Data]]
#[[User_Interface_Patterns#Navigating_Data|Navigating Data]]
#[[User Input]]


== Application Style Guide ==
== Application Style Guide ==
Visual design guidelines are a crucial aspect for interface design. It can provide user experience, identification and acceptance. Colors, fonts, positions and dimensions on the one hand reflect cultural and organizational identity. On the other hand they need to serve the interface's limitations of screen display.
In effect properties are not chosen by personal likes but to provide orientation, separate important from details and leverage the visual communication. At this point in time dynamic aspects are proposed and discussed as well.
[[Image:color.png|center|Color Grades Example]]
== Interface Concepts ==
Interface concepts are done during requirements phase and specification phase. They deal with dynamc aspects of the interface, because they can't be visualized in a sufficient manner by prototyping.
== Interface Drafts ==
A first approach or suggestion for a new GUI. This is done by prototyping and available as screenshot with comments and explanations.


== Prototyping ==
== Prototyping ==


[[Image:prototyping_screenshot.jpg|right|275px|UIE-Process ]]
[[Image:prototyping_screenshot.jpg|right|275px|UIE-Process ]]
Before implementation starts an interface is shaped by prototyping first with a prototype application called AXURE. Prototyping reveals a lot of questions to be answered either by functional specification implementation design or interaction. It saves interface development from tedious and time consuming trail and error approaches.  
Before implementation starts an interface is shaped by [[GUI_Prototyping|'''prototyping''']] first with a prototype application called Axure. Prototyping reveals a lot of questions to be answered either by functional specification implementation design or interaction. It saves interface development from tedious and time consuming trail and error approaches.  


Prototypes are very close to the application and can even be tested with users before development starts.
Prototypes are very close to the application and can even be tested with users before development starts.
Line 28: Line 57:
All interfaces coming up are generated as static html pages:
All interfaces coming up are generated as static html pages:


[https://zim01.gwdg.de/repos/smc/trunk/04_Design/03_GUI_Design/03_Prototyping/HTML-Prototyp/13_Searching/index.html Example]
[https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/Prototypes/R4/index.html Example]


They do not contain any valid HTML, CSS or JS. Prototypes meet the following demand:
They do not contain any valid HTML, CSS or JS <ref> [http://en.wikipedia.org/wiki/JavaScript Wikipedia on JavaScript]</ref>. Prototypes meet the following demand:


# Visualization and discussion of new approaches/ideas
# Visualization and discussion of new approaches/ideas
Line 38: Line 67:
# Documentation
# Documentation


Prototypes are generated with Axure RP Pro. Please mind that Axure prototype files of current Releases can not be opened in older versions.  
Prototypes are generated with Axure RP Pro.<ref> Axure RP is a wireframing, rapid prototyping, and specification software tool aimed at web and desktop applications.</ref> Please mind that Axure prototype files of current Releases can not be opened in older versions.
 
[[Media:Axure_Errors.doc|Issues in R5]]


=Abstract Prototype (optional)=
'''Abstract Prototype (optional)'''


Abstract prototypes should reflect the main motivation, intentions of a certain user/user group and reflect a rough workflow, based on the motivation. the APT should visualize the user goals and the relevant information entities needed to reach the goal. The abstract prototype should not make any suggestions on the user interface or page flow, and should be media-independent, as much as possible.
Abstract prototypes should reflect the main motivation, intentions of a certain user/user group and reflect a rough workflow, based on the motivation. the APT should visualize the user goals and the relevant information entities needed to reach the goal. The abstract prototype should not make any suggestions on the user interface or page flow, and should be media-independent, as much as possible.
Modeling an APT should help to focus on the user, his motivation/intention and his specific interests while acting. An APT is a visualization/cognitive tool to support further detailed use case specification and detailed functional prototypes.
Modeling an APT should help to focus on the user, his motivation/intention and his specific interests while acting. An APT is a visualization/cognitive tool to support further detailed use case specification and detailed functional prototypes.


=Definition of Functional Prototype=
'''Definition of Functional Prototype'''<ref>[http://www.agilemodeling.com/artifacts/essentialUI.htm http://www.agilemodeling.com/artifacts/essentialUI.htm]</ref>
 
Functional prototypes visualize all GUI elements, as precise as possible. Dynamic aspects of roles and dependencies are not covered:
 
# Necessary/important pages that appear to the user
# Page flow (optional), where dynamic aspects can not be covered


Functional prototypes visualize all GUI elements, as precise as they appear after implementation:
'''Structure of Prototypes'''


# all necessary/important pages that appear to the user
The first page carries the name of the functional part. It shows a rough flow of important interface actions. On the bottom of pages you can find a general note about the page. Yellow note stickers contain specification text.
# the page flow (optional), where dynamic aspects can not be covered


=Structure of Prototypes=
== Expert Interviews ==


The first page usually carries the name of the functional part. It shows a rough flow of important interface actions. The flow is not meant to rebuild the complete behaviour of the application. It shows:
Expert interviews are conducted to get a better understanding of one specific working process and how it can be organized/reorganized within the interface. A very domain specific knowledge is needed to understand interface requirements better. Functional aspects come additionally and can not be separated from interface needs.


*What actions are triggered: '''orange text'''
'''Requirements of Expert Interviews'''
*What happens on the same page and what not: '''<page>'''
*When and on which pages messages appear: '''msg'''


Each other [https://zim01.gwdg.de/repos/smc/trunk/04_Design/03_GUI_Design/02_interface_conception_and_design/02_01_Prototyping/HTML-Prototyp/13_Searching/index.html parent page] of the tree refers to a use case with the corresponding name. It carries the rough flow of the case to see which pages the user enters and leaves. [https://zim01.gwdg.de/repos/smc/trunk/04_Design/03_GUI_Design/02_interface_conception_and_design/02_01_Prototyping/HTML-Prototyp/13_Searching/Advanced_Search.html Child pages] contain graphical interfaces.
{|{{Prettytable}}
|-
!bgcolor = #eee |Participants
|
1
|-
!bgcolor = #eee |Supervisor
|
1 - 2
|-
!bgcolor = #eee |Equipment
|
<ol>
<li>PC</li>
<li>Internet connection</li>
<li>Interview agenda (provided by UIE)</li>
<li>Audio recording device (provided by UIE)</li>
</ol>
|-
!bgcolor = #eee |Duration
|
2h - 4h
|-
!bgcolor = #eee |Results
|
Document with protocol of interview. Prototype draft.
|-
!bgcolor = #eee |Steps
|
<ol>
<li>Introduction</li>
<li>Q & A (Questions and Answers)</li>
<li>Summary</li>
</ol>
|}
* [[Expert_Interviews_2007/Easy_Submission_Summary|'''Summary of the expert interviews''']]


On the bottom of pages you can find a general note about the page. Yellow note stickers contain specification text.
==Surveys==


These attributes are used to provide interface development and development a clear description of how the interface should look/work.
To get a better picture of how users approach web application's interfaces surveys are done. They could give answers where metrics do not:


[[User Interface Engineering Survey|'''Summary of 1st survey September 2011 (MPDL internal dry run)''']]


==References==
<references/>


</div>
</div>
 
[[Category: User Interface Engineering]]
[[Category: Interface Conception & Design| ]]

Latest revision as of 13:48, 20 April 2012

From early drafts to productive use, each interface is designed and visualized using interface prototypes to provide an outlook on the solution at an early point in time. Short iteration cycles enable usability evaluation right from the beginning. Optimized information architecture and navigation can be designed in close cooperation with users, making usability more predictable.


Introduction[edit]

An implemented interface is based on a process that starts with rough ideas drawings varieties and discussions. The more approaches are available right at the beginning of conception the more quality and innovation can be expected for the forthcoming interface solution. Quality is gained through iteration cycles with users. At this point in time the process is an evolutionary one. While development is not affected good and bad can be separated using sketches, paper prototypes or even high fidelity prototypes. The more promising an approach is considered the more detailed it will be shaped.

In the end each major interaction is considered and can be visualized for interface development. Creating and reducing variety step by step is a task which mustn't affect development because it needs precise direction to implement.

Pattern Library[edit]

UIE-Process

Within the institutes of the Max Planck Society there are many different needs for new or improved software solutions. It is almost impossible to build individual GUIs on top of them.

Interfaces developed by UIE use basic patterns, based upon a style guide for web applications. As far as possible, new services are built on reusable components, so that new interface elements will be implemented along with proven ones. Every component has a defined pattern, CSS definitions and (JavaScript) behaviour and is documented in detail.

Establishment of an Architecture (See Picture from Bottom to Top)

  1. Structure: Starting with abstract representation of an pattern
  2. Visual Design: Styleguide definition for the pattern
  3. Development: Definition of reference-HTML snippets
  4. JSPF side: Integration of snippets

Introduction of a Pattern Taxonomy

  1. Organizing Layout and Display
  2. Navigating Functionality
  3. Display Data
  4. Navigating Data
  5. User Input

Application Style Guide[edit]

Visual design guidelines are a crucial aspect for interface design. It can provide user experience, identification and acceptance. Colors, fonts, positions and dimensions on the one hand reflect cultural and organizational identity. On the other hand they need to serve the interface's limitations of screen display.

In effect properties are not chosen by personal likes but to provide orientation, separate important from details and leverage the visual communication. At this point in time dynamic aspects are proposed and discussed as well.

Color Grades Example

Interface Concepts[edit]

Interface concepts are done during requirements phase and specification phase. They deal with dynamc aspects of the interface, because they can't be visualized in a sufficient manner by prototyping.

Interface Drafts[edit]

A first approach or suggestion for a new GUI. This is done by prototyping and available as screenshot with comments and explanations.

Prototyping[edit]

UIE-Process

Before implementation starts an interface is shaped by prototyping first with a prototype application called Axure. Prototyping reveals a lot of questions to be answered either by functional specification implementation design or interaction. It saves interface development from tedious and time consuming trail and error approaches.

Prototypes are very close to the application and can even be tested with users before development starts.

All interfaces coming up are generated as static html pages:

Example

They do not contain any valid HTML, CSS or JS [1]. Prototypes meet the following demand:

  1. Visualization and discussion of new approaches/ideas
  2. Technical evaluation
  3. Functional evaluation
  4. Usability evaluation
  5. Documentation

Prototypes are generated with Axure RP Pro.[2] Please mind that Axure prototype files of current Releases can not be opened in older versions.

Abstract Prototype (optional)

Abstract prototypes should reflect the main motivation, intentions of a certain user/user group and reflect a rough workflow, based on the motivation. the APT should visualize the user goals and the relevant information entities needed to reach the goal. The abstract prototype should not make any suggestions on the user interface or page flow, and should be media-independent, as much as possible. Modeling an APT should help to focus on the user, his motivation/intention and his specific interests while acting. An APT is a visualization/cognitive tool to support further detailed use case specification and detailed functional prototypes.

Definition of Functional Prototype[3]

Functional prototypes visualize all GUI elements, as precise as possible. Dynamic aspects of roles and dependencies are not covered:

  1. Necessary/important pages that appear to the user
  2. Page flow (optional), where dynamic aspects can not be covered

Structure of Prototypes

The first page carries the name of the functional part. It shows a rough flow of important interface actions. On the bottom of pages you can find a general note about the page. Yellow note stickers contain specification text.

Expert Interviews[edit]

Expert interviews are conducted to get a better understanding of one specific working process and how it can be organized/reorganized within the interface. A very domain specific knowledge is needed to understand interface requirements better. Functional aspects come additionally and can not be separated from interface needs.

Requirements of Expert Interviews

Participants

1

Supervisor

1 - 2

Equipment
  1. PC
  2. Internet connection
  3. Interview agenda (provided by UIE)
  4. Audio recording device (provided by UIE)
Duration

2h - 4h

Results

Document with protocol of interview. Prototype draft.

Steps
  1. Introduction
  2. Q & A (Questions and Answers)
  3. Summary

Surveys[edit]

To get a better picture of how users approach web application's interfaces surveys are done. They could give answers where metrics do not:

Summary of 1st survey September 2011 (MPDL internal dry run)

References[edit]

  1. Wikipedia on JavaScript
  2. Axure RP is a wireframing, rapid prototyping, and specification software tool aimed at web and desktop applications.
  3. http://www.agilemodeling.com/artifacts/essentialUI.htm