Designing interfaces – Get an impression!
Eva Bettina Betzler
Software Developer PetroMod
AaTC, Aachen, Germany
August 2014
Designing interfaces – Get an impression!
© 2014 Schlumberger. All rights reserved.
An asterisk is used throughout this presentation to denote a mark of Schlumberger.
Other company, product, and service names are the properties of their respective
owners.
Abstract
This presentation will give you a brief impression of UI designing.
The first part explains what UI design guidelines are, and why understanding human
cognition is vital for creating guidelines that result in satisfying user interfaces.
The second part is about necessay C++ classes for the adoption and integration of
PetroMod, Schlumberger’s software suite for Petroleum Systems modelling.
The third part explains how to apply guidelines in an easy and realistic way.
PetroMod is used as an example.
Hopefully, I’ve picked out three aspects that you will find good to know when
designing your interface and its rules as well as useful when it comes to applying the
rules.
Overview
I. What are design guidelines and why do we need them?
II. C++ classes for the adoption/integration of PetroMod
III. How to apply UI guidelines
IV. Appendix: one well known UI design rule
I. What are design guidelines and why do we need them?
Design guidelines: what and why
What they are not: they are not actions – to be done
What they are: they are goals – to be achieved
Guidelines = No actions, but goals!
Why we need them:
• Make the software easy to use
• Bring it close to the users’ needs and requirements!
Goals – an example
Goals from the SLB product Petrel UI Guide
• Easy, simple, intuitive and standardized
• Aesthetic and modern
• Highly interactive and efficient
• Ergonomic
• Enjoyable!*
* “Das Gehirn lernt nur, wenn es Spass hat.” (The brain only learns when it is having fun.), Prof. Dr. Dr. Manfred Spitzer, German psychiatrist,
psychologist and neuroscientist, Medical Director of the Psychiatric University Hospital in Ulm, Germany, founder of the Transfer Center for
Neurosciences and Learning (ZNL). A graduate of the University of Freiburg, worked at Heidelberg, Harvard and the University of Oregon.
Where do design guildelines come from?
Different authors* – but quite similar guidelines!
Somehow strange?!
No! Guidelines are based on human psychology, how people
• Perceive
• Learn
• Reason
• Remember
• Convert intentions into action
*Many authors had at least some background in psychology.
Example 1: Perceptual priming
What do you see?
Example 1
“What you see is what you expect.”
Example 1
Now try NOT to see the dog! => Perception biased by experience
Example 2: Perceptual priming
Fold napkins. Polish silverware. Wash dishes.
French napkins. Polish silverware. German dishes.
=> Perception based on current context
Our perception is biased!
Perception is dependent on
• Our experience
← Past
• The current context
← Presence
• Our goals
← Future
Our vision is optimized to see structures!
"The whole is greater than the sum of the parts“
Gestalt principles*
• Proximity
• Similarity
• Continuity
• Closure
• Symmetry
• Figure/ground
• Common fate
* Gestalt psychology is a theory of mind and brain formed in Berlin early in the 20th century. The idea is that the brain sees things as a whole.
Example 1: Proximity
Proximity occurs when elements are placed close together.
They tend to be perceived as a group.
Proximity: rows vs. columns
Example 2: Closure
Closure occurs when an object is incomplete or a space is
not completely enclosed. If enough of the shape is indicated,
people perceive the hole by filling in the missing information.
A circle, a triangle …
Example 3: Figure/ground
Figure-ground refers to the relationship between an object
and its surroundings. There’s always figure or an object that
'stands out' against an undifferentiated background.
M.C. Escher: Figure/ground-ambiguity
Conclusion
Conclusion:
• Avoid ambiguity!
• Be consistent!
• Understand the goals!
=> Designing with the mind in mind*
These were just very few examples of how people perceive.
Don’t’ forget: it’s also important to know how we learn,
reason, remember and convert intentions into action.
* Jeff Johnson, “Designing with the Mind in Mind. Simple Guide to Understanding User Interface Design Guidelines”
II. Adoption/integration of PetroMod to Petrel:
Necessary C++ classes
Schlumberger’s software Petrel and PetroMod
Petrel E&P Sortware Platform
PetroMod Petroleum Systems Modelling Software
Petrel – a software platform!
PetroMod - Application overview
An example: PetroMod software suite
PetroMod was the product of the German company IES
which was aquired by Schlumberger in 2008.
The look & feel should be adopted to the GUI style of
Schlumberger’s platform Petrel.
A style guide has to be developed, based on the Petrel UI
Guide.
Design guidelines are applied afterwards.
Petrel’s and PetroMod’s Lithology Editor
Petrel
PetroMod
Best of both worlds!
Defining priorities - quick wins* for a “Petrel’ish” look
• Petrel capitalization
• Petrel drop-site control
• Petrel info separator
• Petrel tooltip help
• PetroMod unit layout
• PetroMod Auto apply dialog with
Petrel style Close button
=> Implementation of C++ classes!
* Minutes from Glenn Lillehammer, Usability Architect Petrel and Ocean, SIS Norway Technology Center (SNTC)
Class: “InfoSeparator”
Old version
New version
Class “ExtendedTooltip”
C++ with Qt and HTML
C++-header with
class ExtendedTooltip
derived from Qt class QLabel.
Appearance:
Light yellow background
enter event-pixmap
leave event-pixmap
Qt::PointingHandCursor
Bullet item-pixmap
III. How to apply UI guidelines?
How to apply guidelines: in theory
Ideal workflow:
1. Define your guideline
2. Define the interface respecting the guideline
3. Do the implementation
4. Evaluate
How to apply guidelines: in practice
At least on paper!
In theory there is no difference between theory and practice
… but in practice there is.
Very often you define your guideline afterwards.
Challenges for the adoption of PetroMod
•
•
•
•
•
•
•
More than 30 different applications
6 different product groups
Diversity of requirements
Crosslinks between applications
Unification of GUIs and workflows
Additional: alikeness to Petrel is wanted
Last but not least: further development should be
interfered as little as possible
How to approach?
Be familiar with Petrel UI Guide
Capture PetroMod’s apps as-is state
Summarize requirements of different product groups
Practicability – Effort – Priorities: Checklists for easy and
realistic realization
• Creating a detailed description of significant UI elements
• Complete common C++ classes/libraries, ensure usage
• Revisions of existing applications
•
•
•
•
How to apply guidelines easy and realistic?
Use checklists!
A) GUI style
Minimum
Unification
Consistency Checklist
B) Processes
Process
Usability Checklist
Users’ needs and requirements
C) SUS
System Usability Scale
Objective evaluation
A) GUI style
Minimum Consistency Checklist
- Easy & realistic realization: Checklist!
- Detailed description of significant UI
elements
- Alphabetical order
- Product champion acceptance vs.
”Under progress”
- Colored background to recognize
priority of UI element
□ Checked?
B) Processes
Process Usability Checklist
- Evaluates workflow
- Supports design, implementation,
review
- Considers user (precognition, tester/
developer/geologist)
- Evaluates learning, usability
- [Consider Petrel*]
- [Proposes improvements*]
* Just the first 10 questions were coming from the original SUS questionnaire.
C) SUS System Usability Scale
•
•
•
•
Developed by DEC
ISO standard
High-level objective view of usability
Is the process: not acceptable, acceptable or excellent?
SUS score calculation
How to calculate the SUS score:
• First sum the score contributions from each item (each
item's score contribution will range from 0 to 4)
• For items* 1,3,5,7,and 9 the score contribution is the
scale position minus 1
• For items 2,4,6,8 and 10, the contribution is 5 minus the
scale position
• Multiply the sum of the scores by 2.5 to obtain the overall
value of SUS
* NB: there is a difference between the odd (positive) and the even (negative) questions!
Appendix: one well known UI design rule
As an example: UI design rule, Johnson, 2007
Principle 1 Focus on the users and their tasks, not on the technology
• Understand the users
• Understand the tasks
• Consider the context in which the software will function
Principle 7 Deliver information, not just data
• Design displays carefully; get professional help
• The screen belongs to the user
• Preserve display inertia
Principle 2 Consider function first, presentation later
• Develop a conceptual model
Principle 8 Design for responsiveness
• Acknowledge user actions instantly
• Let users know when software is busy and when it isn’t
• Free users to do other things while waiting
• Animate movement smoothly and clearly
• Allow users to abort lengthy operations they don’t want
• Allow users to estimate how much time operations will take
• Try to let users set their own work pace
Principle 3 Conform to the users’ view of the task
• Strive for naturalness
• Use users’ vocabulary, not your own
• Keep program internals inside the program
• Find the correct point on the power/complexity tradeoff
Principle 4 Design for the common case
• Make common results easy to achieve
• Two types of “common”: “how many users” vs. “how often”
• Design for core cases; don’t sweat “edge” cases
Principle 5 Don’t complicate the users’ task
• Don’t give users extra problems
• Don’t make users reason by elimination
Principle 6 Facilitate learning
• Think “outside-in,” not “inside-out”
• Consistency, consistency, consistency
• Provide a low-risk environment
Principle 9 Try it out on users; then fix it
• Test results can surprise even experienced designers
• Schedule time to correct problems found by tests
• Testing has two goals: informational and social
• There are tests for every time and purpose
Design interfaces – Got an impression?
Thank you for your attention!