This heuristic can be used for all devices which makes use of orientation modes.
Do you know PAOLO? He is a nice guy, as long as you don’t interfere with his expectations:
(Update: Also have a look at his brother: PACO)
Portrait, Audio, Objects , Landscape, Overlay
Does it support different display modes? How does the app (application) handle them?
“The trick is to keep the experience consistent in each view, allowing for a seamless user experience when switching views.” (Quote)
Look at the example given at the website, the color palette looks okay in landscape, but in portrait it takes up a lot of the available space.
Some apps explicitly decide on one kind of mode.
*This has benefits for the developer:
– UI elements are created for one mode, e.g. “Open” is always at the same place.
– The arrangement, field size, font and order of elements don’t need to be checked as how they look in the other mode. Less developing and/or design time is needed.
– Better overview (“guiding”) of how the user will use the program (paths).
Let’s assume there is a user story which consists of only four action buttons: >>> Open, Change, Save, Close <<<
A) For one mode (p=portrait), there is one path (regular use, no tester mind involved).
Open (p), Change (p), Save (p), Close (p)
B) With two modes (p=portrait, l=landscape), there are 16 paths:
– Each single action can be executed while the device is either in landscape or in portrait mode.
– The combination of actions can be done in either mode: “Open” in portrait, turn to landscape, then “Change”, turn back to portrait and “Save”, last turning and “Close”.
*This also has disadvantages:
– It takes away from the user experience.
Users use the device in any orientation they like. The majority (?) of apps enable this specific user experience, which is a unique selling point of the device.
– Inefficiency, wasting of potential: Sticking to the “wrong” orientation (depending on the app and its purpose). Example: Sticking to portrait mode might not make use of the “wider” landscape screen.
Does it support audio? Can it be muted? Can it be adjusted? Can it be adjusted with the device volume sliders? Does it bring its own volume control? If yes, can both be used together? Using the device volume slider moves the app volume slider? Can it be automatically adjusted? E.G. when phone calls come in? When overlays happen? Can it handle headsets or other jacked in audio devices (stereo set, car jack?)
This is at the moment a kind of placeholder for me. I am thinking of the developed structure, the code, the files it installs on the device, but also new ideas which might come up.
Same as in Portrait, needed the “L” letter to make a nice heuristic word
What is overlay? Overlay is the message pop up of one app, while the user is in another app.
Does it support overlay? What other common apps use overlay, that will *most likely* pop up? Skype? Facebook? Other chat tools?
How does it handle the overlay? Could there be data loss for the user, when the overlay happens? Is there a choice for the user to ignore the overlay? Is there a timeout for the overlay? What happens, when the timeout comes? Will the overlay disappear? Or come back in x minutes?
Hint: How to make a iPad if you don’t own one: iPad Testing Ideas
Origin: The idea started on twitter (24th September 2010) with a question from @Siggeb: “I am testing a new cool Twitter client for the ipad;) give me some test heuristics .” At time i quickly sketched PAOLO and now i found the time to fill it with some life.