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