Volume Group Backup
Launched - Jan 26 2021
Overview
The goal of this project is to create scheduled automatic backups to a volume group in Block Storage service (Block Storage service is mainly for storing data in the cloud). The way to achieve it is by applying backup policies to volume groups. The following design process demonstrates:
1. The technical challenges of this project
2. The process to work around the corner with developers
3. Compromise the most ideal design and come up with the best UX possible.
Team
Oracle Cloud Infrastructure,
Block Storage Team
Role
UX Designer
Collaborations
PM, Engineers
Duration
Aug2020 - Oct2020
Background Knowledge
-What is a block volume?
A virtual hard drive in the cloud that stores data. Think about your physical hard drive in your computer, however it is in the cloud. Learn more
-What is a volume group?
A group of block volumes.
-What is a volume group backup?
Backup of all the block volumes inside this volume group.
-What is a backup policy?
A policy that defines when and how to do the backup (eg. every Mon at 5am ).
-What is a region?
A geographic area that Oracle has data center(s) in (eg. Japan East - Tokyo).
Before the Change
Why do we need this feature ?
Currently we only offer users the option to manually back up their volume group. To use this feature, users have to:
1) Go to volume group detail page
2) Go to "Resources" section on the left hand side and click "Volume Group Backups"
3) Click "Create Volume Group Backup" button
4) Follow the dialog and create a volume group backup
It does not offer a convenient way to do scheduled automatic backups (eg. every Mon at 5am).
Scheduled Automatic Backup
How does it work?
In the current console, we already have scheduled automatic backup feature for block volumes. It can be achieved by applying a backup policy to a block volume so the block volume can be backed up on a certain schedule. The volume group just doesn't have this feature yet. Therefore, there's no way for users to apply one backup policy to a group of block volumes at the same time. If users want to apply the same backup policy to a bunch of block volumes, users have to apply one by one manually.
Similar to block volumes, we want volume groups to have this scheduled automatic backup feature as well. In other words, we want backup policies to be applied to volume groups as well. For example by applying Backup Policy A to Volume Group 1, all the block volumes inside Volume Group1 will follow Backup Policy A's schedule to do the scheduled automatic backup every Mon at 5am.
The Problem
The conflicts of two backup polices
The problem is, like I mentioned before, our current console allows block volumes to have their own backup policies. So a block volume might already have its own backup policy before being added into a volume group. However one block volume cannot be backed up on two schedules.
The Solution
When adding block volumes into a volume group, we need to check if these block volumes have their own backup policies or not. If these block volumes do have existing backup policies, we will need to ask users to remove these backup policies before proceeding.
However, if users only wish to group a bunch of block volumes into a volume group without assigning a backup policy to the volume group, we do allow users to add block volumes with existing backup policies.
The Elegant Way to Deal with It
This is the "Create Volume Group" workflow, the only workflow we are going to focus here from the project. In this design, we allow users to add as many block volumes as they want regardless if these block volumes have backup policies or not. Along the way, we tell users which block volume has backup policy on it. In the end, we provide users a unified warning box to "Unassign All" the backup polices. It is a "one-click to unassign all" solution, very convenient.
After users have clicked on "Unassign All" button, "success/ failure" notifications will pop out on the top right corner to inform users whether the unassignment has been successful or not.
Pushback from Developers
API Difficulties
By talking to developers, I learned that the current block volume APIs are all structured separately. We don't have bulk API to remove the backup policies of different block volumes all at once. However if we insist on this design, there is still a way to make it: by looping all these separate APIs together and calling them one by one. It definitely takes longer time to call, thus lowering the performance.
However, it is still doable.
Then what is the real problem?
The real problem is: error scenario. If anything fails in between, there's no way to tell which API has failed. We can only show a generic message to users that something has failed, but we cannot tell which specific block volume has failed. That can be frustrating to users.
What does developer prefer?
Developers prefer to show warning messages separately underneath each block volume, and show all of the warning messages at the same time. The reason is it is easier to code that way. However there are significant UX problems with this approach.
Pros:
Easy to code
Cons:
1. Can be overwhelming if there are 10+ warning messages, for example:
Cons:
2. Hard for users to process all the "Success" and "Failure" messages all at once:
Coming to the middle land...
The Best UX Possible
Unassign one at a time
In the end, I came up with a design that still has overall good user experience and is also implementable at the same time.
That is to unassign one backup policy at a time. When adding individual block volumes, once a backup policy detected on the individual block volume, we will immediately ask users to unassign its backup policies before proceeding.
Like I mentioned before, we only need to unassign individual block volume's backup policies when there's a conflict of backup policies. When the volume group has its own backup policy selected, we will ask users to remove individual block volumes' backup policies. On the other hand, if the volume group doesn't have a backup policy, we allow user to add whatever individual block volumes they want, regardless if these block volumes have their own backup policies or not.
With this approach, we need to break it down into 3 scenarios:
1) No backup policy selected at volume group level
- no need to unassign
2) Volume group backup policy is selected before adding individual volumes
- unassign once any individual block volume's backup policy is detected , users have to either unassign the backup policy or remove the block volume before proceeding
3) Individual volumes are added first before volume group's backup policy is selected
- A guided experience will be provided to instruct users to unassign individual volumes' backup policies one by one until all the backup policies have been unassigned
Scenario1: No backup policy selected at volume group level
Since no backup policy is selected at volume group level, there's no need to unassign any individual block volume's backup policy.We allow users to add whatever block volumes they want, regardless if these block volumes have their own backup policies or not.
Scenario2: Volume group backup policy is selected before adding individual volumes
In this case, users have selected a volume group backup policy before adding individual volumes. Therefore, whenever users add a new block volume into the group, we will check if this volume has its own backup policy or not. If it has its own backup policy (eg. Blockvolume2), we will show up a warning box right underneath that block volume and ask users to unassign its backup policy before proceeding.
We will disable the "+ Another Volume" button and the "Create" button at the same time.
Success
If the unassignment has been successful, a "success" message will show up on the top right corner.
Then the warning box will be removed, the "+Another Volume" button and the "Create" button will be enabled again. Users can continue with the flow.
Failure
On the other hand, if the unassignment has failed, an error message will show up on the top right corner.
The warning box will still be there in case users want to try again "unassignment", maybe this time it would work. However the hint text underneath that block volume will change from "This block volume has backup policy" to "Please remove this block volume from the group before proceeding". In order to proceed, users have to either unassign its backup policy or remove this block volume from the volume group.
Scenario3: Individual volumes are added first before volume group's backup policy is selected
Now, let's take a look at a more complicated scenario. In this scenario, users select individual block volumes first, then go back up to select a backup policy at volume group level.
Like Scenario1, we don't show up any warning sign initially since the volume group doesn't have a backup policy, even Blockvolume2 and Blockvolume4 might have backup policies on them.
After individual block volumes are selected, users suddenly go back up and select a backup policy. We pop a red warning box directly in the "Backup Policies" section to warn users one or more selected volumes below has backup policy assigned. Please unassign these backup policies before proceeding.
At the same time, another "unassign" red warning box will pop out underneath the first block volume that has backup policy on it. This is to guide users to start unassigning one at a time.
Page automatically scrolls down to focus on the first block volume that has backup policy on it. Users start to unassign.
Users move on to unassign the next block volume that has backup policy on it.
Until users have finished all the unassignment, all the warning messages have disappeared. Users are allowed to continue.
Pros:
1. Users focus on one at a time, know clearly what they are deleting (prevent users from blind deleting)
2. Easier to implement and show which one has failed
Cons:
Has to delete one by one manually, not as convenient as "Unassign all" approach
Final thoughts ...
Being a UX designer is ...
An advocator for user
And
A compromiser
At the same time
Often the time ...
We strike the balance between
The most ideal UX
The implementable
In the end ...
We work out a solution
together
