On 09/20/2018 01:04 PM, Ancor Gonzalez Sosa wrote:
On 09/19/2018 01:45 PM, Ancor Gonzalez Sosa wrote:
On 09/19/2018 01:29 PM, Kenneth Wimer wrote:
Hi Ancor,
Judging from the gifs, the two line approach seems to work well in regards to noticing the buttons change but it feels hierarchical, as if "Add Raid" is the main function and the others are sub-functions of that.
Perhaps I can join a call tomorrow and we could discuss the details?
That would be great. See you tomorrow (Thursday) at 11 AM at https://jangouts.suse.de/#/rooms/2025
The conversation just took place. Here are some notes for those interested.
First of all, this is a really though subject. We are still unsure what is the best solution and what could be the users' response to the changes. So the best we can do is try out some things and see how they work in the mid-term.
About removing the dots =======================
We will keep them for the time being. After all, the lack of space shouldn't be a cause for ignoring a style guide.
Is still true that the style guide is outdated and doesn't match 100% the partitioner approach. And it's also true that the style guide is already being ignored in many YaST modules. But let's try to remain true to the guide as long as we can do it.
We also mentioned the possibility of using the "…" character, that only eats one space in ncurses. But we are quite scared about the i18n consequences. Or do you guys believe it's a valid way out?
About grouping buttons ======================
We concluded that having a menu-button for "show", as suggested in the section "Possible improvements 3" of the gist didn't look like a good idea.
Also having a menu-button for "add" feels kind of wrong, since it would group actions that work over the whole set (like adding a new RAID or a new VG) and actions that refer to the currently selected entry (like adding a partition to the selected RAID or adding an LV to the selected VG).
Menu-buttons for "delete" and "edit" seems to make more sense. Specially the latter. Having a "Edit" menu button would allow us to resolve the current ambiguity about the meaning of the word (sometimes it means formatting, sometimes it means jumping to the list of partitions...). It would also match a typical UI expectation - an "edit" menu containing a list of possible actions on the selected element. And last but not least, "edit" is basically the only menu-button that makes sense to all elements in all tables.
About adding a second line of buttons =====================================
This have both pros and cons. In the "Hard disks" section could be too overwhelming, but in general it looks like a valid approach for "advanced" sections like RAID and "Volume Management".
Conclusions / result ====================
It was a rather long conversation full of insights and side-tracks, so I may be skipping important information. But I feel I have enough information to propose a prototype. Stay tuned for that.
Find below a link to a gist with a possible idea that tries to use: - (1) menu buttons for grouping actions that are similar/related - (2) two lines to separate general actions from actions to be performed on the selected item. About (1), today during the conversation it became obvious than grouping the "Add xxx" or the "Delete xxx" actions in menu-buttons made little sense. That's grouping by the name of the button (both start with "add", so let's group them!) rather than by their meaning/scope. So the grouping is actually different to everything we had suggested before. Some decisions/grouping may look strange at first glance when thinking locally about a concrete screen. But I hope they are justified by looking at the consistency of the big picture. And I hope the weirdness can be mitigating just improving a bit the wording of the buttons. So here is the link: https://gist.github.com/ancorgs/5e5fd016eb7db7413a1972d52f9ae913 Please provide (at least) feedback or (desirably) alternatives. During next sprint (starting next Monday) we will start implementing the most promising idea (whatever it is) to see how people reacts to it. Cheers. -- 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