Meet PACO for iPad

This heuristic can be used for all devices which makes use of orientation modes.

Do you know PACO? He is the senior brother of PAOLO:

NEW: Introducton of Communication aspect

Portrait, Audio, Communication, Overlay

Portrait:

Orientation is one of the big features of the current device generation.

Portrait, portrait upside-down, landscape left and landscape right are “strongly recommended”:

Important: It is strongly recommended that your application support all orientations. This includes portrait, portrait upside-down, landscape left and landscape right. iPad apps that require an orientation must support both variants of that orientation.

Link: http://developer.apple.com/library/ios/#qa/qa1588/_index.html

 

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:

Path	Open	Change	Save	Close
1	p	p	p	p
2	p	p	p	l
3	p	p	l	p
4	p	p	l	l
5	p	l	p	p
6	p	l	p	l
7	p	l	l	p
8	p	l	l	l
9	l	p	p	p
10	l	p	p	l
11	l	p	l	p
12	l	p	l	l
13	l	l	p	p
14	l	l	p	l
15	l	l	l	p
16	l	l	l	l

– 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.

 

Audio:

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?).

 

Communication:

The communication part of the heuristic is from Tobias Geyer (@the_qa_guy); he mentioned it in a comment, but it is definitely worth to be included; kudos to him.

– How does your application behave if the network connectivity suddenly drops? Will the user loose data; will the app crash or hang?

– Will the app recommend a user to download a 5 MB feature pack when they’ve only got GPRS coverage or will it wait until they’re logged into Wi-Fi?

– What about the server side of things? Will it cause problems if the IP address of your device changes between requests?

– How does the app behave in airplane mode?

– Does the communication have to be secure – and if yes: is it? Think of network sniffers, proxies …

– Is the app using the network connectivity economically? Does it cache data locally or is it requesting everything from the server? Not everybody has unlimited network traffic.

– Is it possible to make your app work with a test system or are all requests hardcoded to your production system? This will affect testability a lot…

 

Overlay:

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 an 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 that time I quickly sketched PAOLO and now I found the time to fill it with some life.