Here's my two cents: #1 is interesting as it finally explains why the buttons are below the table __ The menu has the context of the app only. Buttons have the context of the selection within a table Users are more used to #2. It would require less time to learn the general concept. The menu has the context of the app as well as selection, depending on the menu item. The buttons below the table should, at least theoretically, not be needed at more. #3 would probably be best for power-users who want RAID, Bcache, etc. For "normal" users I think this would be suboptimal as their use-case would then require them to understand the buttons below the table in context of the selection (and little else - the menu is mainly just confusing to them). As for removing the buttons or not, we should keep the TUI in account when making these decisions. Personally, I think #2 with no buttons below the table might be the best option. Regards, Ken On 10.09.20, 14: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... 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. 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. -- Ancor González Sosa YaST Team at SUSE Software Solutions Kenneth Wimer Head of UX/UI Design Products and Solutions M: +49 173 5876891 E-Mail: wimer@suse.com

On 10. Sep 2020, at 16:18, Ancor Gonzalez Sosa wrote:

On 9/10/20 3:59 PM, Kenneth Wimer wrote:

...

Here's my two cents:

#1 is interesting as it finally explains why the buttons are below the table __ The menu has the context of the app only. Buttons have the context of the selection within a table

Users are more used to #2. It would require less time to learn the general concept. The menu has the context of the app as well as selection, depending on the menu item. The buttons below the table should, at least theoretically, not be needed at more.

#3 would probably be best for power-users who want RAID, Bcache, etc. For "normal" users I think this would be suboptimal as their use-case would then require them to understand the buttons below the table in context of the selection (and little else - the menu is mainly just confusing to them).

Not exactly. You probably didn't fully get the idea of menu 3. It's pretty similar to #2 except for the organization of the options. It's also contextual to the selection (menu entries enable and disable based on it). So with #3 you neither need the buttons anymore.

The problem I see with #3 is that, in addition to exposing complicated concepts as main menu items, the main menu items themselves would become disabled often depending on selection.

Admittedly, this is the menu that is harder to understand with a static screenshot. You probably need to see it in action to get the idea.

Yes, that is kinda what I thought as well. For someone who doesn’t see YaST every day it’s hard to imagine.

...

As for removing the buttons or not, we should keep the TUI in account when making these decisions. Personally, I think #2 with no buttons below the table might be the best option.

In fact, the TUI is my main motivation to keep a simplified version of the buttons below the table. The menu bar looks less convenient without a mouse. With the buttons, the most common actions would be just a couple of [tab] away from the table selection in the TUI.

Hehe, that is exactly what I was thinking 😊

Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

-- Kenneth Wimer (wimer@suse.com) Head of UX/UI - Products and Marketing SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

On Thu, 10 Sep 2020 14:47:39 +0200 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

Hi, for me the best one from options is 2.

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...

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 would vote for option 3. This small subset should be the most common actions, so in ncurses it will be fast. ( and also in qt when you want to use keyboard shortcuts ). Josef

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.

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 2020-09-10 14:47, Ancor Gonzalez Sosa wrote:

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

This is too minimalistic for my taste. It only moves very uncommon operation to a different place.

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

Clearly this one. I like that "Add" is now unambiguous, so it's always clear WHAT will be created. That had been a weakness in my first approach. Now it even fits for categories where several different things could be created, like in an LVM: The user can choose between adding a new volume group or adding a new logical volume. That's good. Everything else is context-sensitive, so it's absolutely clear what will happen: "Edit" and "Delete" always affect the currently selected item, "Delete All" affects all visible items. This option is the best compromise between conciseness and completeness, yet it is clear at every moment what will happen. I like this one.

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

This is much too overwhelming. Not only are there WAY too many toplevel menus, most of them are also completely out of place most of the time. Depending on what you selected in the tree on the left, only ONE of those technology-specific toplevel menus ("Hard Disk", "RAID", "Bcache", ...) makes sense at the same time, all others are either completely disabled at the top level (which would be very odd and very unusual), or all menu items in them would be disabled. The latter would be a UI desaster: A user would have to click through them all to discover what menu items are currently available. This completely defeats the purpose of having menus: It would make life harder for the user, not easier. Do not offer stuff that is unavailable. When I am in the "LVM" view, don't bother me with Btrfs or RAID; I'll be busy figuring out what I can do / have to do with my LVMs. Don't flood me with menu items that are all unavailable because they are irrelevant right now. Also, I miss the "Configure" menu that would lead the user to the more exotic storage technologies like iSCSI, FCoE etc.; they would probably have to be in another toplevel menu that would look even more out of place in this setup. Besides all this, consider the NCurses case. It would be a tight fit even in English even right now. And then consider languages that need more screen space like French or German. And consider that we might have to add more technologies in the future that would require new similar toplevel menus. This is clearly a killer argument all by its own, even without the usability concerns above. Kind regards -- Stefan Hundhammer YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 9/17/20 11:14 AM, Ancor Gonzalez Sosa wrote:

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.

Good news in this regard. Iván came with an idea for a small change that would resolve all the inconsistencies in the menu that I explained at the end of my previous mail. Even more, it would also solve the previous open discussion we had in January about which tab should be opened by default when navigating the left tree[1]. It even makes easy to introduce the changes we want for subvolumes. Since I learned in this thread that some ideas are not properly explained with just a couple of screenshots, Iván and myself took our "innovation time" last Friday to prepare a working prototype you can see in action here. https://www.youtube.com/watch?v=TboQjH2Bi-g I really think it's a leap forward in terms of consistency of the Partitioner UI. What do others think? Cheers. [1] https://lists.opensuse.org/yast-devel/2020-01/msg00014.html -- Ancor González Sosa 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 21/9/20 7:35, josef Reidinger wrote:

On Sun, 20 Sep 2020 23:36:11 +0200 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

On 9/10/20 2:47 PM, Ancor Gonzalez Sosa wrote: 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. Good news in this regard. Iván came with an idea for a small change that would resolve all the inconsistencies in the menu that I explained at

On 9/17/20 11:14 AM, Ancor Gonzalez Sosa wrote: the end of my previous mail.

Even more, it would also solve the previous open discussion we had in January about which tab should be opened by default when navigating the left tree[1].

It even makes easy to introduce the changes we want for subvolumes.

Since I learned in this thread that some ideas are not properly explained with just a couple of screenshots, Iván and myself took our "innovation time" last Friday to prepare a working prototype you can see in action here. https://www.youtube.com/watch?v=TboQjH2Bi-g

I really think it's a leap forward in terms of consistency of the Partitioner UI. What do others think? Hi Ancor, at first let me say that you should videos more often, it really helps to explain things.

Indeed! the video has helped me a lot to understand the prototype better. Thanks!

In general I like approach, it looks good. Just three small notes:

- nested table has a bit strange indentation in the qt ( I expect less space on left for nested elements )

I agree.

- I also would like to see how it looks in ncurses ( not all, just to get impression, so one two screens are enough ) - It is a bit strange that "View Details" is in Device and not in "View" menu. I expect "View" -> "Details" ( or "Device Details" )

I have mixed feelings here. On the one hand, I agree with Josef: "View" -> "Device Details" is where I'd look for that information at the first attempt. On the other hand, I understand that you placed under the "Device" menu because it is contextual to the selected device and the "View" one is for access to more general views, isn't it? Anyway, displaying such pop-up when doing a double-click on the device would be nice too.

good work Josef

...

Cheers.

[1] https://lists.opensuse.org/yast-devel/2020-01/msg00014.html

-- 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 21/9/20 9:16, Ancor Gonzalez Sosa wrote:

[...]

...

...

- It is a bit strange that "View Details" is in Device and not in "View" menu. I expect "View" -> "Details" ( or "Device Details" ) I have mixed feelings here. On the one hand, I agree with Josef: "View" -> "Device Details" is where I'd look for that information at the first attempt. On the other hand, I understand that you placed under the "Device" menu because it is contextual to the selected device and the "View" one is for access to more general views, isn't it? Anyway, displaying such pop-up when doing a double-click on the device would be nice too. Yes, double clicking in a device should likely open that dialog. I forgot to mention that in the demo (I really tried to keep it below 3 minutes). And that kind of small details about a certain menu entry can be easily solved. If I would have called the option "Show Details" or "Description", nobody would have notice anything strange. ;-)

True. "Device" -> "Show details" looks better. Thanks!

Cheers.

-- 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