[yast-devel] A menu for the YaST Partitioner
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 -- 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?
[...]
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
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" <ancor@suse.de> 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 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. 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.
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. 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 10. Sep 2020, at 16:18, Ancor Gonzalez Sosa <ancor@suse.de> 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 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
On Thu, 10 Sep 2020 14:47:39 +0200 Ancor Gonzalez Sosa <ancor@suse.de> 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
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 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 <shundhammer@suse.de> 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/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
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 Sun, 20 Sep 2020 23:36:11 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
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?
Hi Ancor, at first let me say that you should videos more often, it really helps to explain things. 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 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" ) good work Josef
Cheers.
[1] https://lists.opensuse.org/yast-devel/2020-01/msg00014.html
-- 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 <ancor@suse.de> 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 9/21/20 10:03 AM, David Díaz wrote:
On 21/9/20 7:35, josef Reidinger wrote:
On Sun, 20 Sep 2020 23:36:11 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
[...] 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? 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.
Me too. I'm not sure whether that can be tweaked somehow.
- I also would like to see how it looks in ncurses ( not all, just to get impression, so one two screens are enough )
Nested tables in ncurses are not working yet. We are implementing them from scratch. The bright side about that is that we are in full control of the look&feel..
- 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. ;-) 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 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
participants (6)
-
Ancor Gonzalez Sosa -
David Díaz -
josef Reidinger -
José Iván López González -
Kenneth Wimer -
Stefan Hundhammer