Ideas for complex storage visualization

[Vojtěch Trefný]

I'm currently trying to find a way how to visually represent complex 
storages (LVMs, RAIDs) in the blivet-gui[1] (and in the future for 
anaconda too).

------
TL;DR version: Help me find a way how to visually represent storages, my 
current ideas[2] sucks.
------

Even a simple Fedora installation on machine with a single harddrive can 
produce quite a complex storage -- installation using encrypted LVM 
results into seven devices with four level deep structure (luks-physical 
volume-volume group-logical volumes).

The challenge here is to create a simple graphical representation of 
this situation (and of course also not so standard storages with LVMs 
over RAIDs and other weird configurations) that would be easy to 
understand and could fit into application window[3] (leaving space for 
other widgets).

I'm currently using system similar to GParted -- colored rectangles with 
child devices "embedded" into their parents -- a little like rectangular 
contour map -- 
https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation1.png
It looked like good idea but I think it is too complicated and hard to 
understand with more "layers".

My second idea is derived from GNOME Disks -- 
https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation2.png 
(just a mockup created using Gimp). Problem is it would need extra space 
for some basic information (name, size...) and it would be worse for 
more storages with more layers.

The idea I like the most is using tree-like visualization -- 
https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation3.png 
-- it can show the whole complex structure of the storage, unfortunately 
it would never fit into the window.

The result is I have three options that I don't like and I'm not able to 
come up with something new or better. So I hope somebody will come up 
with some amazing solution. Feel free to share all your crazy ideas and 
thoughts.

Vojtech T.

--
[1] http://blog.vojtechtrefny.cz/blivet-gui
[2] https://vtrefny.fedorapeople.org/blivet-gui/
[3] https://vtrefny.fedorapeople.org/blivet-gui/blivet-gui-window.png

[Máirín Duffy]

Hi Vojtěch!

On 11/18/2014 10:57 AM, Vojtěch Trefný wrote:
> TL;DR version: Help me find a way how to visually represent storages, my
> current ideas[2] sucks.

So, I'm not saying these are awesome, but they are alternatives and 
maybe food for thought - when we first did the design for the UI rewrite 
we went through a lot of iterations about how to visualize storage - 
IIRC we had to throw a lot of them out just because the widgets didn't 
exist really and we wanted to keep things simple at first. (feel free to 
correct me if I'm wrong)

Anyway these are rough unvetted mockups and subject to suck, that being 
said:

1. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

This one is a combo of a cascading list (physical device > partition > 
details) where the details pane gives you a baobab style / circular 
diagram of the selected physical disk. Also tabs at the top let you 
filter by type of device.

Cons: This doesn't give you a visual overview of all storage - just the 
selected physical disk. Those slices can get pretty tiny too depending.

2. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

Again we have tabs at top to filter on type of device. Main nav is a 
list of devices. Right pane has configurable details and then another 
list of the members of the selected physical device.

Cons: not really visual at all, just another idea on how to divide up 
the screen.

3. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

Let's call this one collapse-expand funkytown. The UI pattenr here is 
accordion panels.... each physical device gets a panel, and when 
collapsed the panel has a bar chart diagram of the space utilization on 
the device. When expanded (as sda is in the mockup) then you get a 
little config panel; click on the partition to switch what you're 
configuring. This needs a lot more iteration, so it's mostly brain food 
and not a readymade solution.

4. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

Let's call this one deep dive, lol. This just follows a file manager 
pattern. You go down and back up the tree through the breadcrumb at the 
top. Maybe paired with left sidebar nav that shows the full 
expandable/collapsible tree this could be made useful??

5. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

Instead of a breadcrumb bar, a dropdown to switch between physical devices.

6. 
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...

This one is just weird. It's sort of a cascading list set up, but the 
entries (partitions) in the middle list are colored differently based on 
state, and their height is different depending on their size relative to 
other partitions.

I'm doing a lot of tight deadline / last-minute hacking on the new 
fedora website for the next 2-3 weeks, but when that gets out I could 
maybe dive through some of my data visualization books and maybe we 
could brainstorm some more?

One more thought - treemapping - but I don't know, I find them kind of 
hard to read. https://en.wikipedia.org/wiki/Treemapping

~m

[Vojtěch Trefný]

Dne 18.11.2014 v 18:10 Máirín Duffy napsal(a):
> Hi Vojtěch!
>
> On 11/18/2014 10:57 AM, Vojtěch Trefný wrote:
> > TL;DR version: Help me find a way how to visually represent storages, my
> > current ideas[2] sucks.
>
> So, I'm not saying these are awesome, but they are alternatives and 
> maybe food for thought - when we first did the design for the UI 
> rewrite we went through a lot of iterations about how to visualize 
> storage - IIRC we had to throw a lot of them out just because the 
> widgets didn't exist really and we wanted to keep things simple at 
> first. (feel free to correct me if I'm wrong)
>
> Anyway these are rough unvetted mockups and subject to suck, that 
> being said:
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> This one is a combo of a cascading list (physical device > partition > 
> details) where the details pane gives you a baobab style / circular 
> diagram of the selected physical disk. Also tabs at the top let you 
> filter by type of device.
>
> Cons: This doesn't give you a visual overview of all storage - just 
> the selected physical disk. Those slices can get pretty tiny too 
> depending.

The baobab style actually looks good. Right now I'm showing information 
for one selected disk too[1] and users works with only one disk at time.
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> Again we have tabs at top to filter on type of device. Main nav is a 
> list of devices. Right pane has configurable details and then another 
> list of the members of the selected physical device.
>
> Cons: not really visual at all, just another idea on how to divide up 
> the screen.
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> Let's call this one collapse-expand funkytown. The UI pattenr here is 
> accordion panels.... each physical device gets a panel, and when 
> collapsed the panel has a bar chart diagram of the space utilization 
> on the device. When expanded (as sda is in the mockup) then you get a 
> little config panel; click on the partition to switch what you're 
> configuring. This needs a lot more iteration, so it's mostly brain 
> food and not a readymade solution.
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> Let's call this one deep dive, lol. This just follows a file manager 
> pattern. You go down and back up the tree through the breadcrumb at 
> the top. Maybe paired with left sidebar nav that shows the full 
> expandable/collapsible tree this could be made useful??
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> Instead of a breadcrumb bar, a dropdown to switch between physical 
> devices.
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/...
>
> This one is just weird. It's sort of a cascading list set up, but the 
> entries (partitions) in the middle list are colored differently based 
> on state, and their height is different depending on their size 
> relative to other partitions.
>
> I'm doing a lot of tight deadline / last-minute hacking on the new 
> fedora website for the next 2-3 weeks, but when that gets out I could 
> maybe dive through some of my data visualization books and maybe we 
> could brainstorm some more?

No problem, blivet-gui is now in early development still missing lot of 
core features so better visualization could definitely wait (some 
visualization is there and works).
> One more thought - treemapping - but I don't know, I find them kind of 
> hard to read. https://en.wikipedia.org/wiki/Treemapping

Ok, that is really weird. I think this would make the storage harder to 
understand :)
> ~m

[1] https://vtrefny.fedorapeople.org/blivet-gui/blivet-gui-window.png

[Máirín Duffy]

On 11/18/2014 10:57 AM, Vojtěch Trefný wrote:
> TL;DR version: Help me find a way how to visually represent storages, my
> current ideas[2] sucks.

One more thought - I find baobab's rings chart really intuitive to 
understand... you could even start it at the level of all devices.

~m

[Gene Czarcinski]

On 11/18/2014 10:57 AM, Vojtěch Trefný wrote:
> I'm currently trying to find a way how to visually represent complex 
> storages (LVMs, RAIDs) in the blivet-gui[1] (and in the future for 
> anaconda too).

Please do not forget to address (deal with) btrfs.  Besides single 
device btrfs-volume with multiple subvolumes, you can also have a 
multi-device btrfs-volume configured as raid0/1/10 (and real soon now 
raid5/6).  While recovery with raid1/10/5/6 currently leaves a lot to be 
desired (to say the least), it will be there "real soon now" and should 
be handled.

Gene

[Vojtěch Trefný]

The visualization part is same for btrfs (sub)volumes and raids/lvms. 
But blivet-gui currently supports creating btrfs volumes including raid 
levels and managing subvolumes (currently partly broken). Still lot of 
features is missing but I'm working on it.

VT

Dne 18.11.2014 v 21:24 Gene Czarcinski napsal(a):
> On 11/18/2014 10:57 AM, Vojtěch Trefný wrote:
> > I'm currently trying to find a way how to visually represent complex 
> > storages (LVMs, RAIDs) in the blivet-gui[1] (and in the future for 
> > anaconda too).
>
> Please do not forget to address (deal with) btrfs.  Besides single 
> device btrfs-volume with multiple subvolumes, you can also have a 
> multi-device btrfs-volume configured as raid0/1/10 (and real soon now 
> raid5/6).  While recovery with raid1/10/5/6 currently leaves a lot to 
> be desired (to say the least), it will be there "real soon now" and 
> should be handled.
>
> Gene
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[David Cantrell]

On Tue, Nov 18, 2014 at 04:57:45PM +0100, Vojtěch Trefný wrote:
> I'm currently trying to find a way how to visually represent complex
> storages (LVMs, RAIDs) in the blivet-gui[1] (and in the future for
> anaconda too).
>
> TL;DR version: Help me find a way how to visually represent
> storages, my current ideas[2] sucks.
>
> Even a simple Fedora installation on machine with a single harddrive
> can produce quite a complex storage -- installation using encrypted
> LVM results into seven devices with four level deep structure
> (luks-physical volume-volume group-logical volumes).
>
> The challenge here is to create a simple graphical representation of
> this situation (and of course also not so standard storages with
> LVMs over RAIDs and other weird configurations) that would be easy
> to understand and could fit into application window[3] (leaving
> space for other widgets).
>
> I'm currently using system similar to GParted -- colored rectangles
> with child devices "embedded" into their parents -- a little like
> rectangular contour map -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation1.png
> It looked like good idea but I think it is too complicated and hard
> to understand with more "layers".

Quick request/comment.  No embedded colored rectangles, unless it
supplements another system.  Or really, do not make it so I cannot see what
is on my disk.

http://www.colourblindawareness.org/colour-blindness/living-with-colour-visi...
> My second idea is derived from GNOME Disks -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation2.png
> (just a mockup created using Gimp). Problem is it would need extra
> space for some basic information (name, size...) and it would be
> worse for more storages with more layers.
>
> The idea I like the most is using tree-like visualization -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation3.png
> -- it can show the whole complex structure of the storage,
> unfortunately it would never fit into the window.
>
> The result is I have three options that I don't like and I'm not
> able to come up with something new or better. So I hope somebody
> will come up with some amazing solution. Feel free to share all your
> crazy ideas and thoughts.

[Adam Williamson]

On Tue, 2014-11-18 at 16:57 +0100, Vojtěch Trefný wrote:
> I'm currently using system similar to GParted -- colored rectangles with 
> child devices "embedded" into their parents -- a little like rectangular 
> contour map -- 
> https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation1.png
> It looked like good idea but I think it is too complicated and hard to 
> understand with more "layers".

One thought I have on this (just the one! That's all I got!) is the
'children and parents' view is possibly the wrong way to go about this.

Any way I try and think of representing it in a way where you drill down
a single Correct sequence - presumably drives to containers to volumes,
or something - winds up not being right for all cases, and a real pain
to try and represent consistently.

I definitely prefer the approaches of Mo's which give up on the idea
that you can always start from one view and drill down the same basic
'flow' to wherever you're trying to get to, and instead accept that hey,
maybe sometimes you want to look at partitions on disks, sometimes you
want to look at volumes in containers, sometimes you want to look at
members in sets. I guess I'd sort of expect GUIs for those situations,
and then links of some sort between the flows - when you're looking at
partitions on disks, you can see when a partition is a member of a
container, say, and switch to an appropriate level of the 'containers'
view.