JavaScript for.Net Developers The things you need to know Pavel Kolev .
Arthur Fink Page 1 Thinking about User Interface Design for OpenEdge GUI for.NET (or any other...
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of Arthur Fink Page 1 Thinking about User Interface Design for OpenEdge GUI for.NET (or any other...
Arthur Fink Page 1
Thinking about User Interface Design
for
OpenEdge GUI for .NET(or any other environment)
by Arthur Fink www.ArthurFink.Wordpress.com
Arthur Fink Consulting www.ArthurFink.com © 2008 by Arthur Fink
Arthur Fink Page 2
Thinking
User
Design
Arthur Fink Page 3
Programming
Designing
Listening / Seeing
Arthur Fink Page 4
My promise
You'll learn guidelines for visual design of modern user-friendly OpenEdge applications
combining rich full-featured controls into simple easy to use applications.
Not a “paint by numbers” toolkit !
Arthur Fink Page 5
Moving to .NET is a re-write
Opportunity to rework whole concept
Not a one-to one screen replacement
Make sure UI gets better – not worse!
Arthur Fink Page 6
A “old” program that was easy to use
Arthur Fink Page 7
Only got harder to learn
Arthur Fink Page 8
And the paid version even harder
Arthur Fink Page 9
Our process
Careful observation of user tasks and goals
Real user role in design and testing
Consistent and clear visual standards
Careful selection, styling and use of all .NET controls and other components.
Arthur Fink Page 10
Designing user interfaces that work
Arthur Fink Page 11
And that don’t confuse
Arthur Fink Page 12
Interfaces that are simple and direct
Arthur Fink Page 13
Which knob controls lower left burner?
Arthur Fink Page 14
Small changes can make a big difference
Arthur Fink Page 15
Fear of change – and blindness to the gain
Arthur Fink Page 16
Listen to users
Arthur Fink Page 17
Automation anthropologist at work
Arthur Fink Page 18
REAL client is the user.
What does the user need?
Not what does the client think user wants.
User need to be part of design process.
How can user be in control?
Arthur Fink Page 19
Users need simplicity
Easy to learn
Easy to use
Easy to enter data
Hard to “mess up”
Arthur Fink Page 20
Keep it simple,
No extra data or control
Not everything visible at once
Rarely used features rarely visible
User in control – can drill down
Arthur Fink Page 21
Clear labels
Arthur Fink Page 22
Which way to room 1512?
Arthur Fink Page 23
A sign that might work
Arthur Fink Page 24
Offer a clear message users need to hear!
Arthur Fink Page 25
Don’t hide your controls
,
Arthur Fink Page 26
Don’t hide your controls
,
Arthur Fink Page 27
Don’t just mark the hazard; eliminate it!
Arthur Fink Page 28
Not "Error" messages – positive hints
Arthur Fink Page 29
Instead of this rebuke
Arthur Fink Page 30
Encouraging feedback – sounds and sights
Saving project ..... Saving project ....… Saving project .......... Saving project ............. Saving project ................ Saving project ...................
Arthur Fink Page 31
Consistency IS for us
One way to do things
Common view from screens, paper forms, reports
Same terminology
Ideally the same code is behind each
Arthur Fink Page 32
Optimize for the common cases
Simplify the most common input case.
Unusual cases may take more key strokes.
Arthur Fink Page 33
Allow mouse OR keyboard (when possible)
Hand movement mouse to / from keyboard takes time
(Exception to “one way to do things” rule)
Arthur Fink Page 34
Microsoft Health Common User Interface
Arthur Fink Page 35
A medicine list (from MHCUI)
Arthur Fink Page 36
Prescription (Rx) form (from MHCUI)
Arthur Fink Page 37
Rx form – filled in (from MHCUI)
Arthur Fink Page 38
Standards for consistency (from MHCUI)
Arthur Fink Page 39
Visual standards (from MHCUI)
Arthur Fink Page 40
Visual standards applied (from MHCUI)
Arthur Fink Page 41
Display order for medications (from MHCUI)
Arthur Fink Page 42
Distinguishing similar data (from MHCUI)
Arthur Fink Page 43
Choosing the right control
Not necessarily the fanciest
Learning curve vs. power user features
Arthur Fink Page 44
The right control
Accepts simple direct input
Offer clear unambiguous display
Does require computation or conversion
Doesn’t have many un-used options.
Arthur Fink Page 45
The right control (continued)
Can’t be replaced by something simpler.
Invites easy use (clear affordance)
Is easy to use; hard to mis-use
Has unobtrusive but clear operation
Arthur Fink Page 46
The right control (continued)
Doesn’t make user “think” at all
Has common visual style with other controls
Is visually attractive, and easily readable
Is often familiar to user (from Word, Excel, etc.)
Arthur Fink Page 47
Using the controls right (or not!)
Arthur Fink Page 48
Using the controls right (or not!)
Arthur Fink Page 49
This window looks clear
Arthur Fink Page 50
A confusing window
Arthur Fink Page 51
The confusion here can be dangerous
Arthur Fink Page 52
Progress (OpenEdge) has the tools . . .
Arthur Fink Page 53
Lots of tools . . . !
Arthur Fink Page 54
But . . . you still need to design
Arthur Fink Page 55
The purpose of type is to be read
Arthur Fink Page 56
A system that really works
Allow quick, easy, accurate data input
Provides prompt and helpful feedback
Lets the user feel in control
Isn’t hurt by user “mistakes”
Arthur Fink Page 57
A few more guidelines
Don’t interrupt users, or tell them that something worked.
Don’t provide information users can’t use.
Provide “undo” for any destructive action.
Design the interface before starting to code!
Arthur Fink Page 58
Time for your questions, your concerns
? ? ?
Arthur Fink Page 59
Extra slides (if there is time)
Arthur Fink Page 60
The client’s initial screen (!)
Arthur Fink Page 61
Cash register screen – design idea #1
Arthur Fink Page 62
Cash register screen – design idea #2
Arthur Fink Page 63
Cash register screen – design idea #3
Arthur Fink Page 64
Cash register screen – design idea #4
Arthur Fink Page 65
Cash register screen – design idea #5
Arthur Fink Page 66
Cash register screen – design idea #6
Arthur Fink Page 67
Cash register screen – design idea #8