Edit panel error scenarios
Launched - Jul 2020
Overview
-Simplifies the editing of block volume
The goal of this project is to simplify the editing of block volume within Oracle Cloud Infrastructure. The way to simplify the editing experience is by combining all the separate action buttons on the block volume detail page into one unified edit panel. User can then go to one single place to edit everything. It's kind of like "all-in-one" shopping experience.
-Why error scenarios become challenges here?
There are two types of API here. One is called synchronous call, the other is called asynchronous call. Synchronous calls can return error messages immediately after users submit information. Asynchronous calls, however, require backend processing time before error messages are returned - from as little as few minutes to as long as 24 hours. The edit panel contains both synchronous calls and asynchronous calls on the same panel.
Team
Oracle Cloud Infrastructure,
Block Storage Team
Role
UX Designer
Collaborations
PM, Engineers
Duration
Feb2020 - May2020
Background Knowledge
-What is a block volume?
Generally speaking, a block volume is a virtual hard drive in the cloud. Technically speaking, it is a detachable block storage device allowing users to dynamically expand the storage capacity. Learn more
Before The Change
Each action button at the top represents a feature that users can edit. For instance, clicking "Edit" button pops out a dialog editor to rename the block volume; clicking on "Resize" pops out a dialog to change the block volume size, etc. While the UX design is straightforward, it creates significant scalability issue: as the number of features increase, buttons no longer fit into the screen.
Also notice the "assign" backup policy link is located in the metadata box, not in the top action button line, resulting in users' needing to hunt to find where to edit what. Organizing everything in one place would simplify and expedite editing.
The following screen exemplifies the user experience after clicking each of the action buttons shown.
After The Change
Combining all functions into a single edit panel simplifies its appearance. Now there's only one edit button on the screen.
Name
The name of the volume
Compartment
Where the volume stores
Volume Size/ Performance/ Auto-tune
Size & Performance
Backup Policy
How the volume is backed up
Problem
Different types of API calls on the same page
- How should we display error messages?
There are two types of API calls, synchronous and asynchronous calls. The difference between them:
Synchronous Calls
Return error messages immediately after submission.
Asynchronous Calls
Require processing time before error messages are returned after submission.
Therefore, after a user hits "Save Changes" button, there's a possibility that synchronous API calls can return error messages immediately while asynchronous API calls are still processing in the backend. How should the UI handle these situations?
Error Scenarios
Scenario 1:
Users Only Edit Sync Calls
Error message returns immediately after users click on "Save Changes" button, users clear errors before proceeding
Scenario 2:
Users Only Edit Async Calls
Users click on "Save Changes" button, panel closes, back to the block volume detail page. Users wait for the API to process while doing other work in the console. Success/ error message pops out on the screen when API is done processing.
Scenario 3:
Users Edit Both Sync Calls and Async Calls
The most complicated scenario.
1) Any sync call fails: Show error messages immediately under the fields while the async call section is greyed out. Users clear the error messages for sync calls before submitting the form again. When users submit the form again, the async call section might still be greyed out or back to live depending on how long users have stayed on the panel for. If the async call section is still greyed out, the success/ error message of async calls will pop out later in the console.
2) All sync calls pass: It is the same as scenario 2. The edit panel closes upon users click on "Save Changes" when every sync call passes. Users will wait for async calls' success/ error message in the console.
Scenario 4:
Users Re-enter "Edit Panel" While Async Calls Are Still in Process
The async call section stays greyed out until the backend API has done processing.
Final Screens & User Flows
Scenario 1:
Users Only Edit Sync Calls
Form Validation
When users edit any of sync calls (name, compartment or backup policies) fields, if these fields have form validations (e.g. number out of range), it will show immediately as users finish typing.
API Validation
When users finish editing all sync calls and hits the “Save Changes” button at the bottom, the fields are now sent to API and are validated at API level. Two possible outcomes result:
1) Succeed (every field passes)
The panel closes, taking users back to the block volume detail page
2) Fail (any of these fields fails)
An error message appears directly underneath the field. Users edit error messages until all error messages are corrected. Click on
“Save Changes”, panel closes, back to the block volume detail page
Scenario 2:
Users Only Edit Async Calls
Form Validation
When users edit an async call (i.e. volume size, performance or auto-tune), volume size format can be immediately validated as users finish typing.
API Validation
When users edit volume performance or auto-tune performance
Scenario 3:
Users Edit Both Sync and Async Calls
The most complicated scenario.
Form Validation
When users edit anything that has immediate form validation (name, compartment, volume size or backup policy), the validation appears immediately as users finish typing.
API Validation
After users edit both sync calls and async calls, and hit “Save Changes” button:
1) Every sync call passes, panel closes, back to the previous page. Users wait on the previous page for async call results. It’s similar to “Scenario 2 - API validation" except here, sync call changes have been saved.
2) Sync call error returns immediately while async call area is greyed out so users can correct sync call error before proceeding.
Scenario 4:
Users Re-enter "Edit Panel" While Async Calls Are Still in Process
Occurs when users immediately re-open edit panel after editing async calls.
- END -
THANKS FOR READING
