I finally found some time to create a mockup of the new Kopia UI I’m thinking about and would like to hear your opinions and ideas on this matter.
The big change I’m thinking of doing would be to merge Snapshots and Policies into one tab, where there’s a tree view on the left and properties for a selected tree item on the right.
The tree has:
Repository root - which is where you can see and edit global policies
Local Filesystem - which is a directory browser with all local files and directories
Hosts - which let you see and define per-host policies
Users - which let you see and define per-user policies and see all snapshots and path-level policies that belong to the user
Now the idea is that you’d select an item in the tree view and the right hand side would populate with:
all snapshots of that selected item (whenever it makes sense), and for each snapshot there will be a Browse option where you can mount, restore or simply browse the contents in the app
policy definitions attached to the selected item - with ability to edit them in-place in a more condensed way than today
context-sensitive actions (for example to create a snapshot of a local directory, delete policies, estimate snapshot size, possibly more etc.)
There will be some kind of search functionality on top (not pictured here) to quickly find things by name, user and host, just like today when looking at snapshots.
The mockup was literally created in 30 minutes and I don’t know how to use the tool so many basic things are missing, but would like to hear your opinions and more ideas on this topic.
This seems quite good to me and more similar to what I was expecting when first using the app.
I would assume of course we could still mount a particular snapshot as a drive letter? Also it would be nice to be able to continue to simply browse through existing snapshots based on time (current UI)
I will say, I’m relatively mid skilled person, but I’d be more focused on the backup user interface (creating, configuring, schedulers) vs the "what you’ve got"interface.
The backup interface is quite… Simple and it seems to be designed to be used by fairly skilled people.
Simple example, the regularity of snapshots is currently defined by how many seconds. So I need to pull out a calculator and work out how many seconds of I just want at most, one thrash if the filesystem and network daily.
(Furthermore, I don’t think I have the ability to force this daily occurrence to be only at 2 am)
Etc.
Fundamentally though, from what I’ve observed over using it for 3 or 4 hours, evaluating it. It seems robust and I like it a lot.
I am assuming that the local filesystem is basically a tree of the filesystem on disk, and not a tree of directories/files snapshots in the repository based on your description (that is to say that the Local FS is basically an explorer to browse the files currently on disk). If this is the case, I think that this is a bit confusing, after all the root is the Repository. From the users perspective, the repository contains FS items (files/dirs) the user took snapshots of, so the tree should should show those items, and not what’s on the disk right now.
Additionally, I don’t think that FS items that are in snapshots should be mixed with those that aren’t. It’s a cognitive burden to browse through those to reach some directory that is buried deep underneath, and potentially on different paths. Instead, I think ‘Local FS’ can be another root level entry that contains a list of FS items not in the repository, so that users can browse through those and add stuff to the repository. FS items that are already in the snapshot list can be coloured in this tree to indicate that it’s already on the snapshots, and the user can ignore them safely. I suspect that for most users, once they have a list of items they want to snapshot, this tree won’t be used much. This way, the Repository tree will be compact and clean.
In the ‘Repository’ root entry, there should also be a ‘Run all Snapshot’ button (or something similar) button to snapshot all paths that are in the repository. I currently have like 20 different directories I am backing up, and I am following a manual backup scenario, so it is rather cumbersome to go click on each entry individually. I suspect that such a use case will be common, so I think that such a functionality will be quite useful.
I agree (if I understood correctly) with @stpr that showing disk folders and snapshots in the same window is confusing.
Are there just folders which are backed up? Or all of them showing the ones in a policy “colored”? how could you access snapshots of a deleted folder then?
I am assuming the left tree is used to browse your local filesystem to access “backed folders”, maybe this isn’t the case.
I like the idea to see policies “merged” with inherited properties. But after configuring a backup, you don’t access the policies that much; I think they cold continue in their own “page” accessible through a button next to “snapshot now” button (maybe aligned right).
I completely agree with the multiple comments on how confusing that navigation sidebar could be, depending on how it’s organized / implemented.
I think the safest route is to separate any sort of live filesystem view from viewing the contents of your backups. It might be best to only show the live filesystem in a completely separate area / dialog / pop-up when a user wants to select/change a backup source. That “choose what you want to backup” dialog itself could be shown 100 ways from calling on the default OS file browser to something like a tree-view with checkboxes (my fav for backup software).
In the context of this current UI mockup, I think any tree-style browsing should be repository-based: the navigational root is the actual root of the repository and we should only see files and folders in the tree as they exist in the most current snapshot. To handle files/folders that only exist in previous snapshots, use filtering checkboxes to allow a user to toggle their view on and off. Use colors or icons to indicate the difference between an up-to-date file/folder, existing in the most current snapshot, and a file/folder that only exists in previous snapshots. Selecting a folder or file will show a list of versions (snapshots) available to browse or restore directly. That “Show Unique Snapshots Only” filter would hopefully be smart enough to work at the level of the file/folder selected in the tree cause that would help put a bow on the logic of this restore experience.
This method could be a huge time-saver for certain restore scenarios and for many, a mentally “cleaner” process - this is file backup after all, not a system image where we’d want a list of dated snapshots to roll back to - we’re much more likely looking to recover an older version of a file we messed up or deleted than to restore the state of an entire repository to a specific timestamp (…but if your brain thinks best in timestamped snapshots, you could still just select the root in the file tree, choose your snapshot, and browse or restore as we can in the current UI).
I can imagine a UI that combined everything, allowing you to navigate your live filesystem, while also choosing what you want to back up, and see what data is already backed up, AND what versions of each file are available to restore, but it would have to be well executed to avoid confusion. If I made it myself, for my own brain, such an all-in-one approach might be awesome… for me. Hand it to someone else and it might not translate to how they like to work, making it confusing or even leading to lost data. Making something that multi-purposed that also speaks to a broad audience could be difficult and time-consuming so my vote is for keeping things isolated and clean.
The UI changes will likely need to be punted to the following release as it’s too big of a change to implement in one shot. For the 0.9 I’m currently focusing on low-level improvements (repository structure for better reliability, data safety and long-term supportability) and don’t want to block the release on UI.
BTW. I’d really appreciate if a person (or two), experienced with React and Bootstrap and/or web design could help with development and prototyping of those proposed changes. Even better if they could become long-term maintainers for the UI codebase, improve it and take it in some new and exciting directions. I’m not really a UI or usability expert myself, which is probably obvious here…
