Difference between revisions of "Interface Conception & Design"
(52 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{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: | [[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 | 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:// | [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. | ||
'''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'''<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 | |||
'''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 == | ||
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''' | |||
{|{{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''']] | |||
==Surveys== | |||
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 |
Latest revision as of 13:48, 20 April 2012
APPLICATION AREAS |
---|
|
PROJECTS |
Research- and Metadata Handling Corporate & Interface Design (under Rework) |
edit |
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]
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)
- 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
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.
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]
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:
They do not contain any valid HTML, CSS or JS [1]. Prototypes meet the following demand:
- Visualization and discussion of new approaches/ideas
- Technical evaluation
- Functional evaluation
- Usability evaluation
- 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:
- Necessary/important pages that appear to the user
- 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 |
|
Duration |
2h - 4h |
Results |
Document with protocol of interview. Prototype draft. |
Steps |
|
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]
- ↑ Wikipedia on JavaScript
- ↑ Axure RP is a wireframing, rapid prototyping, and specification software tool aimed at web and desktop applications.
- ↑ http://www.agilemodeling.com/artifacts/essentialUI.htm