Split "change location" into pieces

[ancorgs]

The "change location" dialog added here is a bit too much. #1165

Maybe we could split it in several options like this:

Or have a separate menu for the location:

The "reset" option wouldn't need any dialog.

The "specific disk" action could have a quite simple dialog, for example like this:

The "existing device" dialog would also be simpler than the current one to change location. Maybe something like this.

Closed	Open	No swap filesystems

[dgdavid]

I would start avoiding too many different menu options in tables and focus on making the existing one accessible by keyboard users.

Simplifying the current dialog is, indeed, an interesting idea.

[dgdavid]

I would start avoiding too many different menu options in tables

Saying that because I have the feeling that at the end we tend to complicate the elements in the UI instead of giving opportunity a more simple approaches.

Examples,

Dialogs, tendency is to make them grow with no limits
Tables, tendency is to add more and more elements per row. Or more columns. Or even we have though to add show/hide more content per selected/expanded row. Not to mention that we tend to use them everywhere dangerously walking to a table driven UI.
Tooltips, tendency is to use propose them everywhere for saving space.
So, please, let's try to not fall into the temptation of adding a "three dots menu" per column. I think it would be a bit messy.

Web platform provides a lot widgets, I guess for a reason. Maybe the key is to go for a simplification as you propose in the dialog shown above, splitting the UI in small pieces that can be, eventually, used in different views and/or form and avoiding the complexity of already known complex widgets.

Just a reflection or how.

[joseivanlopez]

Yet another reflection here. I feel we have started abusing of tables. Ideally I would keep only one table (probably for the result). Even the file systems could be defined without the need of a table (saving to have more than one table at sight at the same time), but that is other topic.

For the volume location, I more aligned with @dgdavid at #1165 (comment). I think that having 2 selects is enough. My main (and problaby only one) complain is about the order. I still see the natural way of using it is to select where to put the volume and then how. I cannot select "Mount file system" without knowing if there is any file system in my devices. I need to see my devices first to understand the scenario, and then, after selecting one, to indicate how to allocate.

I like both selects, but I wonder if the device options could have some neesting. For example:

Select device:
  /dev/vdb
      vdb1
      vdb2
  /dev/vdc

[dgdavid]

Yet another reflection here. I feel we have started abusing of tables.

Indeed :(

...
For the volume location, I more aligned with the @dgdavid at #1165 (comment). I think that having 2 selects is enough.

But it is just a proposal that needs to be tested.

My main (and problaby only one) complain is about the order.

I was just making changes on top of the initial proposal of changing the order for the radios/table combo.

I still see the natural way of using it is to select where to put the volume and then how.

Me too, with the selects approaches. I realize about it right after writing the comment. Plus, disabled action has more room for explanation ("/dev/xyz cannot be mounted", for example).

I cannot select "Mount file system" without knowing if there is any file system in my devices. I need to see my devices first to understand the scenario, and then, after selecting one, to indicate how to allocate.

Understood.

I like both selects, but I wonder if the device options could have some neesting. For example:

Select device:
  /dev/vdb
      vdb1
      vdb2
  /dev/vdc

Complicated. We can explore how to make it visually possible, but at the time of writing I believe that it is not possible to do so semantically in a Select. There is no relationship, although we can see if "grouping" is a way of solving it. In other words, something to check.

[ancorgs]

For the volume location, I more aligned with @dgdavid at #1165 (comment). I think that having 2 selects is enough.

I came to my proposal without having seen @dgdavid's one. I'm not sure which one I like more.

My main (and problaby only one) complain is about the order. I still see the natural way of using it is to select where to put the volume and then how.[...]

I'm not so sure. I actually like @dgdavid's proposal as it is. The workflow is somehow similar to my proposal here (first deciding the "what" and later the device).

We may need to explain the options a bit better so the implications in the selection of devices is more obvious, but generally I like it.

[ancorgs]

We decided to re-design the storage proposal. See #1678

In that context, this discussion about "change location" becomes kind of irrelevant (we follow a different approach in the new UI).