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: [email protected] To contact the owner, e-mail: [email protected]
