On 9/10/20 2:47 PM, Ancor Gonzalez Sosa wrote:

[...]

First question: what approach should we follow for the menu bar?

[...]

Menu proposal 1 https://github.com/ancorgs/yast-storage-ng/blob/menu_minimal/README.md

Menu proposal 2 https://github.com/ancorgs/yast-storage-ng/blob/menu_classic/README.md

Menu proposal 3 https://github.com/ancorgs/yast-storage-ng/blob/menu_explicit/README.md

We have to decide on the general approach, not on every detail. Some entries could be relocated or renamed afterwards.

I like them all equally. But I would go for 2 or 3 because they allow us to simplify the buttons below each table. See below. I appreciate how explicit and easily discoverable is everything with the proposal 3. But I'm a bit concerned about its scalability for the future. Option 2 is also nice. I find it less obvious, but it offers more room for future growth. Although the fact that we already have a miscellaneous menu for stuff that doesn't fit anywhere else (currently called "actions") worries me a bit. So it's a tie between 2 and 3 for me.

[...]

Second question: what to do with the menu-buttons below the tables? (check the appendix below if you don't know what are we talking about)

Option 1. Remove them as all the functionality is already in the menus.

Option 2. Keep them as they are.

Option 3. Use simple buttons with only a small set of actions.

I clearly prefer option 3 here. The current menu-buttons are overwhelming. The interface would be much more guided if we select only two or three actions that we consider to be the common ones for each device type and we present them as normal buttons. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 9/10/20 1:47 PM, Ancor Gonzalez Sosa wrote:

Menu proposal 1 https://github.com/ancorgs/yast-storage-ng/blob/menu_minimal/README.md

Menu proposal 2 https://github.com/ancorgs/yast-storage-ng/blob/menu_classic/README.md

Menu proposal 3 https://github.com/ancorgs/yast-storage-ng/blob/menu_explicit/README.md

We have to decide on the general approach, not on every detail. Some entries could be relocated or renamed afterwards.

I guess the options #1 (having only general actions that do not fit at any specific place) and #3 (a full list of actions per technology) are less common, so users probably are not used to them. On the other hand, option #2 makes the actions over a device less discoverable. For example, image you are over a disk and you want to format it. Which menu would you go to in #2? And when you want to create a new partition table? You have to navigate through the menus to find it. With the option #3, I would directly go to the "Hard Disk" menu. Having said that, I have to admit that using a menu bar in a kind of "new" way (like option #3 does) is not the best solution from the UX point of view. Maybe a menu bar is not the best widget to offer a list of actions per technology. So, finally I have to vote for 2 here.

If we decide to take proposal 1, then we are done. No second question. If we take 2 or 3, which both include options that are "contextual" to the device currently selected, we have another thing to decide...

Second question: what to do with the menu-buttons below the tables? (check the appendix below if you don't know what are we talking about)

Option 1. Remove them as all the functionality is already in the menus.

Option 2. Keep them as they are.

Option 3. Use simple buttons with only a small set of actions.

Here, I clearly vote for 3. IMHO, having too many buttons does not help at all. It makes the UI more complex. The real challenge is to find the good buttons to keep. Regards, Iván -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Hi all! On 10/9/20 13:47, Ancor Gonzalez Sosa wrote:

Some time ago, we decided to make several changes in the Partitioner UI. Check this section (or the full document if you are interested enough) for more details:

https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md#ag...

We are currently working on adding a new menu bar, but we have two decisions to take. We would like to have some feedback from everyone in the YaST Team and also from SUSE UX experts, so I'm sending this to both Ken and the yast-devel list.

For those that are not that familiar with the current UI of the Partitioner, I added some kind of appendix at the end of this mail to refresh minds.

First question: what approach should we follow for the menu bar?

After some discussions, we have three proposals. I created three branches in the yast-storage-ng repository so you can play with them. For the less technical users (downloading the repo and running the demo may not be trivial), I'm open to create videos or have a video-call to show them in action.

Menu proposal 1 https://github.com/ancorgs/yast-storage-ng/blob/menu_minimal/README.md

Menu proposal 2 https://github.com/ancorgs/yast-storage-ng/blob/menu_classic/README.md

Menu proposal 3 https://github.com/ancorgs/yast-storage-ng/blob/menu_explicit/README.md

We have to decide on the general approach, not on every detail. Some entries could be relocated or renamed afterwards.

If we decide to take proposal 1, then we are done. No second question. If we take 2 or 3, which both include options that are "contextual" to the device currently selected, we have another thing to decide...

Having read the full thread, I vote for the option #2 here and...

Second question: what to do with the menu-buttons below the tables? (check the appendix below if you don't know what are we talking about)

Option 1. Remove them as all the functionality is already in the menus.

Option 2. Keep them as they are.

Option 3. Use simple buttons with only a small set of actions.

...option #3 here.

If we choose option 3. Selecting a disk would only show "Edit" and "View Partitions". But not the options to create/clone partition tables (the menu bar should be used for that). Selecting a partition would show "Edit" and "Delete", but not resizing or moving. And so on.

What's your view on the topic?

Cheers.

And now, the appendix about the current UI, only in case you need it:

We offer many actions per each device (editing, resizing, deleting, etc.). For that we have menu-buttons right below all the Partitioner tables (there are too many actions, they don't fit as regular buttons).

Not all the actions make sense for all kind of devices (for example, you cannot delete a hard disk or format an LVM volume group). So every time a new device is selected in the table, those menu-buttons change to only offer the actions that make sense for that type of device.

In the System table that contains all the devices, there are also additional buttons for general actions like "Rescan Devices" or "Configure". They have never belonged there. In the tables of a particular technology (like RAID or Volume Management) there are buttons to add new devices of the corresponding type.

Cheers again.

-- David Díaz González YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 9/10/20 2:47 PM, Ancor Gonzalez Sosa wrote:

[...]

First question: what approach should we follow for the menu bar?

After some discussions, we have three proposals. I created three branches in the yast-storage-ng repository so you can play with them. For the less technical users (downloading the repo and running the demo may not be trivial), I'm open to create videos or have a video-call to show them in action.

Menu proposal 1 https://github.com/ancorgs/yast-storage-ng/blob/menu_minimal/README.md

Menu proposal 2 https://github.com/ancorgs/yast-storage-ng/blob/menu_classic/README.md

Menu proposal 3 https://github.com/ancorgs/yast-storage-ng/blob/menu_explicit/README.md

We have to decide on the general approach, not on every detail. Some entries could be relocated or renamed afterwards.

Thanks everyone for the feedback. It seems pretty clear that menu#2 was the chosen one, so we are implementing this (the link includes several details and screenshots): https://github.com/yast/yast-storage-ng/pull/1125 Some labels and options may still change, but we have really put a lot of effort into making the behavior useful and consistent, which is harder than it looks in several Partitioner screens. Check the end of this mail if you are interested in the details.

[...]

Second question: what to do with the menu-buttons below the tables? (check the appendix below if you don't know what are we talking about)

Option 1. Remove them as all the functionality is already in the menus.

Option 2. Keep them as they are.

Option 3. Use simple buttons with only a small set of actions.

Here, option 3 was the clear winner. So we are also starting to work on that. We will make sure the menu and the simplified buttons arrive at the same time to Tumbleweed. That's for the announcements. You can stop reading if you are not interested in further details about the challenge of designing the right menu. We had hard times deciding how the menu should be organized and how it should work in many of the Partitioner screens. Everything is trivial for main screens that are basically a list of devices. Like this example with the RAIDs list. https://paste.opensuse.org/view/11343458 The actions in the "Modify", "Go" and "Actions" menu clearly refer to the device currently selected in the table. Same happens to "Add -> Partition" that would create a new partition (if possible) in md0 (which is the entry currently selected in the table). But now imagine this situation in which the user is in the "Used Devices" of the md0 RAID device. https://paste.opensuse.org/view/3670783 The actions of the "Modify" menu refer to the device selected on that table of used devices. That is, sdb1 or sdc. The enabled options in "Go" are "Overview", "Used Devices" and "Partitions". That's equivalent to the three tabs the user can see. That is, the menu will take you to the corresponding tab for the md0 RAID. That makes sense, but it's different to the scope of the "Modify" menu. The "Actions" menu has the same scope than "Go". That is, the actions are applied on md0, not on the device selected in the "Used Devices" table. Taking into account the kind of actions present in each menu, that what makes more sense. We really tried to ensure that. By the way... what should be the scope of "Add"? If the user clicks in "Add -> Partition" should it create a new partition in sdb or sdc or should it create it in the RAID? In the current implementation it refers to the same device than "Modify" (ie. the device selected in the table). As said, I really believe what we have now is close to the best solution that can be achieved with menu#2. That being said and without any intention of re-doing the voting, I have to mention that such situations were exactly the reason to propose menu#3. Its advantages may not be obvious at first sight, but with menu#3 there would be no ambiguity and the user could decide whether he want to apply the action on the selected device of the table (using the corresponding "Hard Disk" or "Partition" menu) or on md0 (using the RAID menu). Again, I'm not saying we should go for menu#3. I'm actually overall satisfied with the version of menu#2 implemented at https://github.com/yast/yast-storage-ng/pull/1125 Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org