Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[No QA] Update Offline UX docs #10480

Merged
merged 5 commits into from
Aug 22, 2022
Merged

[No QA] Update Offline UX docs #10480

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
3b9885d
fix pin button
puneetlath Aug 22, 2022
2dc33af
Invert headings to be biggest to smallest
puneetlath Aug 22, 2022
a6ddef2
Add examples to each pattern
puneetlath Aug 22, 2022
8c59cac
Nest responses to flowchart questions
puneetlath Aug 22, 2022
0be3c6d
Fix table of contents
puneetlath Aug 22, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 39 additions & 38 deletions contributingGuides/OFFLINE_UX.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,17 +1,17 @@
#### Offline UX Patterns
# Offline UX Patterns

### Contents
* [Motivation & Philosophy](#motivation-&-philosophy)
* [UX Pattern Flowchart](#ux-pattern-flowchart)
* [Answering Questions on the Flow Chart](#answering-questions-on-the-flowchart)
* [Description of the Patterns](#description-of-the-patterns)
## Contents
* [Motivation & Philosophy](#motivation--philosophy)
* [Description of the Patterns](#descriptions-of-the-ux-patterns)
- [None - No Offline Behavior](#none---no-offline-behavior)
- [A - Optimistic Without Feedback](#a---optimistic-without-feedback)
- [B - Optimistic With Feedback](#b---optimistic-with-feedback)
- [C - Blocking Form](#c---blocking-form)
- [D - Full Page Blocking](#d---full-page-blocking)
- [A - Optimistic Without Feedback](#a---optimistic-without-feedback-pattern)
- [B - Optimistic With Feedback](#b---optimistic-with-feedback-pattern)
- [C - Blocking Form](#c---blocking-form-ui-pattern)
- [D - Full Page Blocking](#d---full-page-blocking-ui-pattern)
* [UX Pattern Flowchart](#ux-pattern-flow-chart)
- [Answering Questions on the Flow Chart](#answering-questions-on-the-flow-chart)

### Motivation & Philosophy
## Motivation & Philosophy

Understanding the offline behavior of our app is vital to becoming a productive contributor to the Expensify codebase. Our mission is to support our users in every possible environment, and often our app is used in places where a stable internet connection is not guaranteed.

Expand All @@ -20,7 +20,7 @@ The most important concept to keep in mind while reading this document is that w
<hr />
Example: Pinning a chat

When a user clicks the pin button <img style="height: 10px; width: 10px;" src="./assets/images/pin.svg"/> on a chat, two things should happen.
When a user clicks the pin button <img style="height: 10px; width: 10px;" src="../assets/images/pin.svg"/> on a chat, two things should happen.

1. **API Request:** We send a request to the API to ensure the change is saved in the database. This way the chat is pinned on all the user's devices, and will remain pinned even if they leave the app and come back.

Expand All @@ -38,9 +38,9 @@ The example we just looked at is nice and simple, but some actions should not us

To handle problems like this, we have developed offline UX patterns and guidance on when to use them. Every feature of this application should fit into one of these patterns.

### Descriptions of the UX Patterns
## Descriptions of the UX Patterns

# None - No Offline Behavior
### None - No Offline Behavior

There’s no specific UI for this case. The feature either looks totally normal and works as expected (because it doesn’t need the server to function) or the feature looks like it did whenever connection was lost.

Expand All @@ -50,7 +50,9 @@ There’s no specific UI for this case. The feature either looks totally normal

**How to implement:** Use [`API.read()`](https://github.com/Expensify/App/blob/3493f3ca3a1dc6cdbf9cb8bd342866fcaf45cf1d/src/libs/API.js#L53-L55).

# A - Optimistic Without Feedback Pattern
**Example:** The `About` page.

### A - Optimistic Without Feedback Pattern

This is the pattern where we queue the request to be sent when the user is online and we continue as if the request succeeded.

Expand All @@ -60,16 +62,17 @@ This is the pattern where we queue the request to be sent when the user is onlin

**How to implement:** Use [`API.write()`](https://github.com/Expensify/App/blob/3493f3ca3a1dc6cdbf9cb8bd342866fcaf45cf1d/src/libs/API.js#L7-L28) to implement this pattern. For this pattern we should only put `optimisticData` in the options. We don't need successData or failData as we don't care what response comes back at all.

# B - Optimistic WITH Feedback Pattern
**Example:** Pinning a chat.

### B - Optimistic WITH Feedback Pattern
This pattern queues the API request, but also makes sure that the user is aware that the request hasn’t been sent yet **when the user is offline**.
When the user is online, the feature should just look like it succeeds immediately (we don't want the offline UI to flicker on and off when the user is online).
When the user is offline:
- Things pending to be created or updated will be shown greyed out (0.5 opacity)
- Things pending to be deleted will be shown greyed out and have strikethrough

**Used when…**
- the user needs feedback that data will be sent to the server later
This is a minority use case at the moment, but INCREDIBLY HELPFUL for the user, so proceed with cautious optimism.
- The user needs feedback that data will be sent to the server later. This is a minority use case at the moment, but INCREDIBLY HELPFUL for the user, so proceed with cautious optimism.

**How to implement:**
- Use API.write() to implement this pattern
Expand All @@ -84,7 +87,9 @@ When the user is offline:
- We also need to show a Red Brick Road (RBR) guiding the user to the error. We need to manually do this for each piece of data using pattern B Optimistic WITH Feedback. Some common components like `MenuItem` already have a prop for it (`brickRoadIndicator`)
- A Brick Road is the pattern of guiding members towards places that require their attention by following a series of UI elements that have the same color

# C - Blocking Form UI Pattern
**Example:** Sending a chat message.

### C - Blocking Form UI Pattern
This pattern greys out the submit button on a form and does not allow the form to be submitted. We also show a "You appear offline" message near the bottom of the screen. Importantly, we _do_ let the user fill out the form fields. That data gets saved locally so they don’t have to fill it out again once online.

**Used when…**
Expand All @@ -95,18 +100,22 @@ This pattern greys out the submit button on a form and does not allow the form t

**How to implement:** Use the `<FormAlertWithSubmitButton/>` component. This pattern should use the `API.write()` method.

# D - Full Page Blocking UI Pattern
**Example:** Inviting new memebers to a workspace.

### D - Full Page Blocking UI Pattern
This pattern blocks the user from interacting with an entire page.

**Used when…**
- blocking READ is being performed. This occurs when the data that a user sees cannot be stale data and the data can only be displayed after fetching it from the server (eg. Plaid's list of bank accounts)
- blocking READ is being performed. This occurs when the data that a user sees cannot be stale data and the data can only be displayed after fetching it from the server
- the app is offline and the data cannot be fetched
- an error occurs when fetching the data and the user needs instructions on what to do next
This should only be used in the most extreme cases when all other options have been completely and utterly exhausted

**How to implement:** Wrap the component you're working on in a `<FullPageOfflineBlockingView>` component.

### UX Pattern Flow Chart
**Example:** Getting the list of bank accounts the user owns from Plaid (an external service).

## UX Pattern Flow Chart

The following flowchart can be used to determine which UX pattern should be used.

Expand All @@ -117,32 +126,24 @@ The following flowchart can be used to determine which UX pattern should be used
The numbers in this section correlate to the numbers in each decision box above (the diamond shapes).

1. Does the feature interact with the server?

If you're changing an existing feature, you can open the network tab of dev tools to see if any network requests are being made when you use the feature. If network requests are being made, the answer to this question is YES. Note: Sometimes you may see requests that happen to fire at the same time as the feature you're working on, so be sure to double check.
- If you're changing an existing feature, you can open the network tab of dev tools to see if any network requests are being made when you use the feature. If network requests are being made, the answer to this question is YES. Note: Sometimes you may see requests that happen to fire at the same time as the feature you're working on, so be sure to double check.
If you're making a new feature, think about whether any data would need to be retrieved or stored from anywhere other than the local device. If data needs to be stored to or retrieved from the server, then the answer is YES.

2. What type of request is being made?

If there's new data being saved on the server, you're making a WRITE request. If you're retrieving existing data from the server, you're making a READ request. If both things are happening, that's a WRITE request.
- If there's new data being saved on the server, you're making a WRITE request. If you're retrieving existing data from the server, you're making a READ request. If both things are happening, that's a WRITE request.

3. Is it OK for the user to see stale data?

Example: The payment method list. We don't want the user to see a payment method that we no longer support, not even while the payment methods are being loaded from the server (or while the user is offline). Therefore, we answer NO, which leads us to the blocking UI. This way the user won't see stale data while we load the payment methods.
- Example: The payment method list. We don't want the user to see a payment method that we no longer support, not even while the payment methods are being loaded from the server (or while the user is offline). Therefore, we answer NO, which leads us to the blocking UI. This way the user won't see stale data while we load the payment methods.

4. Is the UI a form?

An easy way to tell if something is a form is to try and find a submit button. If a submit button is present or if the user is filling out form inputs, answer YES to this question.
- An easy way to tell if something is a form is to try and find a submit button. If a submit button is present or if the user is filling out form inputs, answer YES to this question.

5. Can the server response be anticipated?

Answer NO if there is data coming back from the server that we can't know (example: a list of bank accounts from Plaid, input validation that the server must perform). Answer YES if we can know what the response from the server would be.
- Answer NO if there is data coming back from the server that we can't know (example: a list of bank accounts from Plaid, input validation that the server must perform). Answer YES if we can know what the response from the server would be.

6. Is there validation done on the server that can't be done on the front end?

If there is some validation happening on the server that needs to happen before the feature can work, then we answer YES to this question. Remember, this is referring to validation that cannot happen on the front end (e.g. reusing an existing password when resetting a password). For example, if we want to set up a bank account then our answer to this question is YES (because we can’t suggest to the user that their request succeeded when really it hasn’t been sent yet–their card wouldn’t work!)

This question can be tricky, so if you're unsure, please ask a question in the #expensify-open-source slack room and tag @contributor-management-engineering.
- If there is some validation happening on the server that needs to happen before the feature can work, then we answer YES to this question. Remember, this is referring to validation that cannot happen on the front end (e.g. reusing an existing password when resetting a password). For example, if we want to set up a bank account then our answer to this question is YES (because we can’t suggest to the user that their request succeeded when really it hasn’t been sent yet–their card wouldn’t work!)
- This question can be tricky, so if you're unsure, please ask a question in the #expensify-open-source slack room and tag @contributor-management-engineering.

7. Does the user need to know if the action was successful?

Think back to the pinning example from above: the user doesn’t need to know that their pinned report's NVP has been updated. To them the impact of clicking the pin button is that their chat is at the top of the LHN. It makes no difference to them if the server has been updated or not, so the answer would be NO. Now let’s consider sending a payment request to another user. In this example, the user needs to know if their request was actually sent, so our answer is YES.
- Think back to the pinning example from above: the user doesn’t need to know that their pinned report's NVP has been updated. To them the impact of clicking the pin button is that their chat is at the top of the LHN. It makes no difference to them if the server has been updated or not, so the answer would be NO. Now let’s consider sending a payment request to another user. In this example, the user needs to know if their request was actually sent, so our answer is YES.