Disclaimer

This lecture explores an interaction design for a citizen science web application to operate offline. By “operate offline,” I mean a web application that functions (at least partially) without an internet connection for extended time. The design expressed in this lecture is intended as an example of a design process. It does not express all the potential designs possible for the application scenario nor does the application scenario expresses all the potential applications or tasks that a citizen science user may perform.

General Design Process

Because our goal is to develop a general interaction design and not a specific design, we will only develop the design in the abstract. We will express the general problem of offline use in a problem scenario. We will then iterate the design through the stages of task analysis, interaction diagram, technology constraint concerns, interaction model consistency and finally from experience. At each step will consider alternative designs and evaluate the design alternatives and evolve the design.

 General Citizen Science App Problem Scenario

Our citizen science user discovers a citizen science web app on line that they might like to use. The citizen reads the home page and explores the website. The citizen decides to participate in the project and use the web app. Because the citizen science project is focused on the environment, the general protocol for the project is to explore the outdoors with the app, sight a potential observation, create the observation using the app, and finally save the observation. Creating the observation, the citizen takes photos, logs the location, enter text and make selections. During the excursions to the outdoors, the citizen may want to reference the saved observations and possibly edit the observations. Eventually the citizen returns home and visits the website again.

Task Analysis of the Problem Scenario

The abstract task analysis should only express the topmost level tasks

1. Study the web app <- online
2. Travel outdoors <- offline
3. Discover potential observation site <- offline
4. Create observation <- offline

i. Make photo <- offline
ii. Log gps <- offline
iii. Enter text <- offline

5. Save observation <- offline
6. Reference observation <- offline

i. Search observation list <- offline
ii. Select observation <- offline
iii. View observation <- offline

7. Edit observation <- offline

i. Replace or delete photo <- offline
ii. Edit location <- offline
iii. Edit text <- offline

8. Return Home <- offline
9. Visit Website <- online

 

Methods:

• Steps 3 – 7 can occur multiple time, but steps 4 and 5 must follow in sequence, meaning an observation must be created before it can be saved.
• Steps 5.i – 5.iii can be performed in any order multiple times
• Steps 6.i – 6.iii must in sequence
• Steps 7.i – 7.iii can be performed in any order multiple times
• Steps 1, 2, 8 and 9 must be sequence, meaning the citizen must first visit the website, then travel outdoors, only once outdoors can the citizen discover a potential observation and then create an observation. Although the citizen does not have to discover create and observation they can only return home after going outdoors. We assume the citizen finally visits the website again.

Admittedly, the tasks after returning home, visit website, is not detailed specifically because we do not want to assume the design.

Note that analyzing the tasks in the problem scenario has revealed tasks “search observation list,” “select observation” and “view observations” which were not explicitly expressed by the scenario.

I have augmented the standard simple task analysis with the annotations, online/offline. This is to clearly indicate what tasks are performed with an internet connection and tasks without a connection. It will also assist us with the interaction diagram.

Interaction Diagram for General Problem

 

User		Device		Server
		ONLINE
Visit website	—>	Request	—>	Receive request
Study website	<—	Display	<—	Respond
		OFFLINE
Travel outdoors
Discover obs
Create obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Reference obs	—>	Receive input
Study	<—	Display
Edit obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Return home
		ONLINE
Visit website	—>	Request	—>	Receive request
Study website	<—	Display	<—	Respond

The interaction diagram only illustrates the top level steps. To make clear online and offline use, the interaction diagram also indicates the state of the device, off or online. The interaction diagram makes clear after returning home that the observations reside only in the device. Our goal is for the server to receive and store observations in a database so that the scientist and other can view the website and study the observations.

We can anticipate some solutions by extending the interaction diagram. I think that there are basically two general solutions. The device can automatically upload the observations.

Interaction Diagram for Automatic Upload

 

User		Device		Server
		ONLINE
Visit website	—>	Request	—>	Receive request
Study website	<—	Display	<—	Respond
		OFFLINE
Travel outdoors
Discover obs
Create obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Reference obs	—>	Receive input
Study	<—	display
Edit obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Return home
		ONLINE
Visit website	—>	Detect saved obs		Receive request
		Upload obs	—>	Receive
				Save to database
StudyWebsite	<—	Notify	<—	Respond

Another possible solution is to have the citizen initialize the upload instead of the device automatically uploading the observations.

User		Device		Server
		ONLINE
Visit website	—>	Request	—>	Receive request
Study website	<—	Display	<—	Respond
		OFFLINE
Travel outdoors
Discover obs
Create obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Reference obs	—>	Receive input
Study	<—	Display
Edit obs	—>	Receive input
Study	<—	Display
Save obs	—>	Save
Study	<—	Confirm
Return home
		ONLINE
Visit website	—>	Request	—>	Receive request
Study website	<—	Display	<—	Respond
View obs list	—>	Receive
Study	<—	Display
Select upload	—>	Upload	—>	Receive obs
				Store obs
Study	<–	Notify	<—	Respond

Comparing the interaction diagram, we can clearly see that the user initiated upload requires significantly more interaction from the citizen. We might immediately decide that the interaction design solution should prefer the automatic upload design. We should not be so rash and should delineate pros and cons of the potential solutions by referencing usability principles.

Usability Comparison between Automatic or User initiated Upload

Design Solution	Pro	Con
Automatic upload	Less user interactions Less screen space	Lack of user control Lack of visibility of upload function Minimal of feedback Minimal robustness Suspect synthesizability Lack of mapping No affordance
User initiated upload	User control Visibility of upload function Possible feedback Possible robustness Possible synthesizability Mapping Possible affordance	Less user interaction More screen space (?)

Note that words like “Lack” and “Minimal” indicate severity of  usability violation. The word “Possible” indicates that the design could lavage the usability principle.

Although the list of cons is much longer than the pros for the automatic upload design, we should not reject it out of hand. Counting pros and cons is not a legitimate measure because the pros and cons are not equal value. We should investigate and analyze them.

The critique that the user initiated upload design uses more screen space is weak because the list of observations is already required for the offline use. The user initiated upload design gives the user more control while the automatic upload design gives the user no control.  The most sever usability violation of the automatic upload design is that the difficult with synthesizability, meaning the user might not form a proper model for the interaction. Imagine that the user has been out in the field collecting a long list of observations which they can see while the device is offline, but the minute that the device is back online the list immediately disappears. I suspect that the user will not form a correct model for the interaction and become confused and even suspect that the observations are lost.  Consequently for this problem scenario, I propose that the user initiate design is better.

I do not believe that user initiated upload is always the best design for the transition from offline to online use. The best designs depend on the problem scenario and the model that the user might have for the interaction. Consider the problem scenario where the user is using the app in the city walking from the subway to the street. As the user walks in the subway the app is offline but when the user emerges from the subway and is on the street the app is online. The user may not even be aware that the device has broken connectivity. We may suspect that the user has a model for the interaction that assumes the app is always connected. Then the automatic upload design is the preferred design. In fact, there is a phase for this design paradigm called “design offline first” which cautions the designer that the app may not have continuous connectivity so it is best to design from the start assuming broken connectivity. Our design paradigm is different. We expect that the user will use the app for extended periods knowing that there is no Internet connection. If that is the case then we should design the interaction such that it consistent with the model that the user has for the interaction. I call this design paradigm “design for intended offline.”

Citizen Science Offline Interaction Design Summary

Besides the interactions that are typical of an online web app the offline use requires at least two additional interactions:

• viewing a list of observations stored on the device
• submitting or uploading the observations to the server

But a list implies additional interactions, the user should be able to edit from the list.

• delete an observation from the list
• edit an observation in the list

The design requires only one additional view which is a list of observations.

Technology Concerns

After making the general design decisions, we should contemplate constrains that technologies impose on the design.

App Caching

The Application Cache API provides all the functionality for caching the app so that views can be stored on the device offline.

http://www.w3.org/html/wg/drafts/html/master/browsers.html#appcache

Considering this technology suggest some constrains. Because we cannot store the entire database on the device, we should not expose pages whose goal is to access the database. We can store all the pages that are primarily static. Example list of pages that we could and should cache are:

• Home page
• Create/edit/view observations
• Observations stored on the device
• About page

There is an additional design constraint imposed by this technology that I only learned from experience. Caching the app takes time; it is does not happen instantaneously, so it is advisable to have a notice on the home page stating the status of the app cache and the version of the app cached.

Storing observations

LocalForage API provides most of the functionality required to store the observations on the device while offline.

https://mozilla.github.io/localForage/

It is built on top of IndexDB, WebSQL and localStorage

• http://www.w3.org/TR/IndexedDB/
• http://www.w3.org/TR/webdatabase/
• http://dev.w3.org/html5/webstorage/

The basic model for interfacing with the storage is as a map (key-value pair). This poses some challenge storing the images. We need to read the file from the camera and convert it to a string. The File and FileReader API provides the technology for this function.

• http://www.w3.org/TR/FileAPI/
• https://developer.mozilla.org/en-US/docs/Web/API/FileReader.readAsBinaryString

We still need to consider the design of the storage, meaning the key and value pairs, but that is beyond the scope of this study. But the design of your map can have impact on the interaction.

Creating Observations

We want to have access to the device GPS while offline. The GeoLocation API provides this functionality.

http://dev.w3.org/geo/api/spec-source.html

The only constrain that this technology imposes is that the user must be aware that the browser will ask for permission to access the GPS. Each browser behaves different and has different interfaces for interacting with the settings of the permissions. All that the app can do is alert and educate the user about the need to grant permission.

We also might want to take photos or make audio recordings. The Media Capture API provides this functionality.

http://www.w3.org/TR/html-media-capture/

The constraint that this technology imposes is that 4 clicks are required to take a photo on the phone.

1. Click the button in the app to take a photo
2. Select the app to use to take the photo
3. Click the camera shutter
4. Click approve

Four clicks for a single photo is excessive, but I have not figured a design around this constrain

Citizen Science Offline Interaction Design Detail Summary

Offline  interactions

• creating an observation
• viewing a list of observations stored on the device
• submitting or uploading the observations to the server
• delete an observation from the list
• edit an observation from the list

The design requires pages

• Home page
• Create/edit/view observation pages
• Observations stored on the device list page
• About page
• Instruction page

The home page should have a notice or alert of the app cache status.

Either the home page or the create observation or instruction page should alert/educate the user about offline use and GPS permissions.

Reconsidering the Interaction Model

Identifying Interaction Model Concepts

Compared to an app that is designed to operate only online, the app that is intended to operate offline has introduced a new model for the user to understand. The model is storing or saving observations on the device and later uploading the observations to the server. This requires the user to understand concepts and requires from us to find proper labeling for buttons and menu items to encourage synthesizing the interaction model. There is a concept that is implied by our model. This concept is recognition of offline and online.

Interaction Concepts

• Offline/Online
• Saving observation on the device
• Uploading observations to the server
• List of observations stored on the device

Considering Labelling and Button Locations

Storing on the Device

When the user is offline they can only save the observation on the device. The create observation will have a button to save the observation, how should it be labeled?

• “Save” – this may be confusing because the user are accustomed to it meaning “save to the server.” This may be overcome, if a different word is used for uploading or submitting to the server. To be safe, I suspect that a new word should be used for saving to the device.
• “Save to Device” – this may be too long of a phase to use on a mobile device.
• “Store” – this is a short word, but still may be confusing and it has to letters in common with “save.”
• Any suggestions?

Uploading to the Server

Later when the device is online, the user will have to click a button to upload the observation to the server. What should the label of the button be?

• “Save” – although this word is common for many web apps, this may be confusing. I think that better is to use a new label.
• “Save to Serer” – this maybe too long.
• “Submit” – this is a new short word.
• “Upload” – this is a new short word.
• Which is better? Any suggestions?

In addition we should locate the upload button.

• In the list of stored observations
• View observation page – Locating the button on this page is motivated by our suspicion that the user may want to view the observation details before uploading. In this scenario we do not want the user to have to return to the list page in order to upload because the user may not be able to identify the observation in the list.
• Edit page – Consider the scenario, the user view the observation details and then decides to edit. After editing the user is ready to upload the observation.
• Probably all three pages – this is probably the best design

List of Stored Observations

What should be the menu item in the navbar for this page?

• Unsubmitted – I do not much like this word
• “Stored” or “Stored Observation” – this is appropriate if we have a “Store” button on the create page.

Offline/Online

We should probably give the state of the device. What are the states of the device?

• Offline
• Online
• Login – We may consider that Login is a third state. It is consistent with a hierarchy of functionality that the user can access: Offline < Online < Login. I do not have experience with this model.

Although my experience is that users understand the meaning of offline and online, we should explore alternative labels:

• Connected/Unconnected – Longer, and could give the wrong message in a social website.
• Any others suggestions?

Where should the on-offline status show?

• On the home page
• create home page – This is appropriate because this is when the user is probably most concerned about the status.
• list of stored observations – This is appropriate because this is where the user must know the status and would help to explain why some functionality is not available.
• In the navbar – This might be appropriate because the user might need to know the status on all the pages. But, navbars have limited space and there might not be enough room.

Interaction Model Consistency

Another consideration is the consistency of the interaction design.

Offline/Online Interactions

What should be the difference between the interactions when the app is online compared to offline? Offline the user

1. Create observation
2. Store observation
3. View list of stored observations
4. Upload observation

While typical online use would be

1. Create observation
2. Upload observation

Consistent design would dictate that online interaction should be identical to offline use, but that is ridiculous. The offline interaction has twice as many steps as the online interaction. When the user become experience with the app they will probably want the online creation of observation to be streamlined. But this same experienced user has also become familiar with storing the observation on the device and fine occasions to create the observation online but to delay the upload for later. Consequently, I suspect that the best interaction design should offer both interactions this implies a set of rules for what button should be offer on the create/edit/detail pages

Device Status	Observation location	Buttons
Offline	Device	Store
Online	Device	Store and Upload
Online	Server	Upload (and Store?)

Revealing Offline and Online Functionality

How should we reveal online and offline functionality? For example should an online feature show when the device is online or should they be “grayed” out? I believe that there are three ways to reveal features.

• Invisible, meaning the feature does not show if the state of the device does not support the feature.
• Grayed, meaning that the unsupported feature shows but is grayed out or not functional.
• Empty, meaning if that the page or list is empty.

There are several factors that influence which design technique to use.

• Security – Meaning for security reasons, we might not want the function to show. For example administrated menu items problem should not show on the navbar because that would alert the potential hacker what features they could access.
• Layout – Graying out maintains the layout. Not only does this make it easier for designers to layout and debug the layout, but also it helps users. Users learn faster where the potential feature is accessed and it helps explain the state of the device.
• Increased interactions – Bootstrap has the ability to indicate that button is inactive, but the user must click the button or hover the button. This implies extra interaction for the user to learn the accessibility of features.
• Screen Space – The empty or grayed design consume more screen space then the invisible design. On a mobile device, screen space may be a big concern.

My guidelines are that Security prompts all other concerns; so administrated features should never be shown to the public or ordinary registered users. In fact, I think that it is appropriate that the administrative pages have a slightly different style from the public pages.

The general guidelines on desktop applications are that menu items including drop downs are grayed and buttons are invisible.  I think that mobile devices can follow the same guidelines. This is particular important in the navbar because it effective brands the website. But when the menus and dropdowns are long then we might consider the advantages that the invisible design offers to shorten menus and dropdowns.

I think that empty pages or list are appropriate but there should be a notice clarifying the status.

Considerations from Experience

Creating Observations

Observing citizen using citizen science apps I have noticed a few cases of user creating an observation in the field and then navigating away from the create observation page without storing the observation. In the field, this can be a costly mistake. In the best case, it implies the user will have to reenter the observation, but it can also mean that citizen has lost of the observation without the ability reenter the observation because they have returned home before the notice the missing observation. This scenario suggest that when the citizen navigates from the create observation, they get a dialogue alerting them that they have not stored the observation. The dialogue can have buttons “Store” and “Continue” and after clicking either button the browser is redirected to the page that user requested in the navbar. It might be that experience user might become annoyed with the extra click so there should be a check box “do not show this message again” and a session variable associated with the setting of the check box.

Offline/Online Login

There is an implicit concept that we have not discussed. Who is the creator of the observations stored on the device but not yet uploaded? From their conception, mobile devices were considered personal. Processing the device implied ownership.  But smart phones users do sometimes loan their phones. (I suspect that might become less common because NIF and features like google wallet have enabled smart phone to be used like a credit cards.) So should we assume that the owner of the device is the creator of the observations stored on the device? This would save some user interactions because they would not have to login to upload their observations. If we were to implement this feature then the login and password would have to be stored in cookies, which is not very secure if the phone is lost. Browsers can autofill and better design for security then we can. Consequently, I suggest that we model ownership as while the observations are stored on the device then they belong to the device. Users must login to upload the observations and at that time they become owners of the observations stored on the server.

Late Addition

Just as there are two version of saving, “store on device” and “upload to server”, there should also be two types of delete, “discard from device”, “delete on server”.  We probably need a “cancel” button for edit observation.