Designing interfaces – Get an impression!

Eva Bettina BetzlerSoftware Developer PetroModAaTC, 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.

AbstractThis 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

PetroMod

Petrel

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 withPetrel style Close button

=> Implementation of C++ classes!

* Minutes from Glenn Lillehammer, Usability Architect Petrel and Ocean, SIS Norway Technology Center (SNTC)

Old version New version

Class: “InfoSeparator”

Class “ExtendedTooltip”C++ with Qt and HTML

C++-header withclass ExtendedTooltipderived from Qt class QLabel.

leave event-pixmap

enter event-pixmap

Qt::PointingHandCursor

Bullet item-pixmap

Light yellow background

Appearance:

III. How to apply UI guidelines?

How to apply guidelines: in theory

Ideal workflow:1.Define your guideline2.Define the interface respecting the guideline3.Do the implementation4.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!

Process Usability ChecklistMinimum Consistency Checklist

B) ProcessesA) GUI style

Unification Users’ needs and requirements

C) SUS System Usability Scale

Objective evaluation

A) GUI styleMinimum 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 calculationHow 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

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 2 Consider function first, presentation later•Develop a conceptual model

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 7 Deliver information, not just data•Design displays carefully; get professional help•The screen belongs to the user•Preserve display inertia 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 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

As an example: UI design rule, Johnson, 2007

Design interfaces – Got an impression?

Thank you for your attention!