A CoPilot Story (Pt 6): Designing Versioning
Continuing the story
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
5. Designing The Service & Application Catalogue
6. Designing Versioning
Defining Narrative
If a user is alerted to a problem in their application, rolling back to a previous “known to be working version” is a quick way to rectify this problem.
Key Performance Indicators (KPIs):
- The user should intuitively understand how to deploy different versions of their application
- The user should easily be able to understand the changes between versions of their applications
- If there is a problem with a user’s application, rolling back to a previous version should be an quick intuitive next action, and easily achievable
Identifying relevant personas: two personas, from our identified four, were identified as being relevant to this story:
Other persona’s were either identified to carry out this action in the CLI (Daniel) or wouldn’t carry this out in anycase (Jim).
Conducting Background Research:
Rolling back to previous versions was an early requirement stipulated to us from the client as it’s a staple of any infrastructure/application management platform. Because of this a great deal of inspiration could be taken from other platforms.
Heroku implemented a “Roll Back” CTA within the Activity Feed for their application.
Digital Ocean implemented a feature called “Snapshots” that are user defined and save the state of the application at a certain point in time. A user could then choose to re-deploy this snapshot at a later date:
First Workshop
In this first workshop we tried to get as many ideas as possible in sketch form. These are presented below.
Through this sketching session it was clear that everyone was settling on a GitDiff (a before and after view of the code changes making up the application) to illustrate changes in the application and a great deal of inspiration was taken from GitHub for people’s sketches.
Creating A Prototype
Following the sketching session, wireframes were first created in Sketch, and then a prototype was created to be used in future testing sessions.
First Round Of Testing
After running through a couple of testing sessions with users, the following feedback was collected:
- Users required more information regarding state changes
- Users needed more information on what would happen to their data when rolling back
- The current, live version of the application should have been on the left of the screen, instead of the right in the GitDiff view
- A common question: “if I rollback the whole project, does the whole app reprovision or only those services that have changed? Would that therefore make my application inaccessible?
- A common question: “can I create a new version from a copy of an older one?”
It was clear that more work needed to be carried out in terms of communicating to the user more about the previous versions of their application and the user flow in general.
Second Workshop
A key finding from these sessions was that it was highlighted that there could be hundreds of previous versions of an application and that the current method of interaction to go between these versions (a horizontal slider) is not the best interaction method to deal with this. Furthermore, the product owner was also concerned about the GitDiff view hidden from view.
Our sketches below present some possible solutions to this.
Creating A Consolidated Master Sketch
The above sketches were concentrated into a master sketch that reflected a general team decision on the direction that this design should take.
On a side note: at this stage an idea was to present three GitDiff’s on the same page. This would show the current selected version, with the previous version on the left, and then the next version on the right. However, upon reflection this was deemed to be too complex when putting this design into wireframes. The idea of three GitDiffs could be revisited at a later date.
Creating Second Prototype
This new design implemented the versions in a vertical format with more information, and the ability to deploy a past version in the proceeding step.
Internal Presentation
Upon presenting this prototype internally to the team, it was highlighted that not enough information was available to the user on past versions from the list view: especially on the changes that had occurred from version to version.
Furthermore, it was explained that the button copy of “View and Deploy” was confusing in terms of presenting two different calls to action, and presenting additional steps before a user could deploy a past version.
Another iteration was needed before user testing!
Creating Third Prototype
A new prototype was created that included information on the services, and their related field(s), that had been changed or added from version to version.
The two call to actions in the previous prototype were split and CTA “View” was changed to “Diff” to better explain what a user should expect on the next screen.
Second Testing Round
Although not the focus of the last testing session of CoPilot (as of the publication of this post), two users did interact with the versioning prototype and one major piece of feedback was that user’s desired to know whether a previous deploy was successful or not.
Next Steps
This prototype needs to be user tested with more subjects so the sparse feedback collected so far can be validated.
Lastly, it has also been suggested that the GitDiff view could be illustrated in an accordion, with the GitDiff view to the current version being by default viewable. This could be an interesting split test in the future if there are adequate resources to do so.
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
5. Designing The Service & Application Catalogue
6. Designing Versioning
