KDE Developer
|
Hi all,
I had put a bit of work in the mouse cursor theme KCM (mostly, porting it to QML) https://git.reviewboard.kde.org/r/123473/ of the various things the discussion went to, is two possible designs for the look. the current: in which the list of themes is pretty much just text, with the preview outside it, vs having completely inline delegates, like the latest status of the QML branch: which wasn't really possible (well it was, but a royal pain in the ****) with qwidgets, but easy now in QML. pros? cons? to be put in the HIG on which one to prefer? |
Registered Member
|
The new design is far better IMO.
Because the preview in the current design is visually outside of the list, I always take some time to remember to understand what I'm looking at. The new design is much clearer and far more logical with the visual cues immediately showing the preview for each style. |
Registered Member
|
I prefere the old one:
+ better overview of the list + less visual influences + fit also for more visual effected modules Thanks for moving the buttons on bottom. I would also move the mouse size on bottom right and the import buttons on buttom left. first install than config. new qml view + all visual information in one list - icon view would be better for visuals than a list view THANKS, THANKS, THANKS for working on the KCM. |
Registered Member
|
I much prefer the direction of the new one. The old one is fine, but is another example of proxy representations and manipulation with unnecessary interaction cycles - a pattern I think it's worth moving away from. (It's also why I prefer the direct manipulation selection mechanics of the desktop grid vs the proxy-based selection mechanics of every other desktop/OS environment).
The second screen shot doesn't do the second design justice because the width of the window is unnecessarily wide. But that's a trivial fix. The ability to more easily compare the cursor themes by simply with each other without selecting back and forth is a big win in my eyes. i.e. Give the user the information they came for with as little interaction cycles as possible. Now the user can see the differences between the cursor themes and the most they'll need to do is scroll. You have my endorsement for the direction of the new design. |
KDE Developer
|
I really like the new design, it takes more care about typography which is in line with what we've been doing to the overall workspace in the past year.
Could that technically sounding "Resolution dependant" perhaps just be "Auto"/"Automatic"? Also maybe the "Remove theme" button should be hidden rather than disabled if it's a system theme. On the other hand having two controls on the right makes it more balanced with the tall content on the left. |
Registered Member
|
why I say that with the old list the overview is better:
thats the modul where you can select the plasma theme. You have the visual in one list but I have always problems to find the name and where the list entry beginn and ende. A view of the GHNS thing. here you can change between two views have a search and useful informations from opendesktop.org. I thing you have an better overview when you have a lot of entries, but the preview is less informativ than in the KCM. So for me a mix between both would be cool I also think that the new qml think is realy cool, I only want to say that when this should be the template for the other modules we should think about all modules. |
Registered Member
|
To be fair, if the name of the theme would be aligned to the left, with proper typography, and with the theme preview under the name (like in the proposed design) it would be a different story. |
Registered Member
|
Long ago I suggested something similar where you can show the theme in action or a more extended preview of what it can do.
|
Registered Member
|
Although I also like the inline preview for its advantage on usability the design guideline is clear: have a preview on top, a selection below, and an expandable area for expert tweaks below. I'm not against the violation of a (probably improvable) guideline but we should better start with a clear design. Andi posted a link to his idea, and adopted to the cursor thing it might look like this:
The preview is very much as it is right now but I broke up all the Oxygen cursor themes into one and allow to tweak the color below which is however collapsed by default. And since having a color tweak might be special to Oxygen the layout is rather to have all Oxygen+Color themes in the list of available themes. Please don't take this idea as a final suggestion. At least I'm unsure how we wanted to handle apply/reset + ok/cancel exactly. And the -/+ buttons for GHNS should perhaps get a label for accessibility purpose. PS: Here is the mockup https://share.kde.org/public.php?servic ... b726f7c810 I created the folder VDGShare > Public > Brainstorm > System Settings and KCMs to collect work on KCMs in one place. |
Registered Member
|
Hi Heiko,
thanks for jump in and sharing the bmml file. Balsamiq Mockups is really cool and fast. As you write we have header description preview, selection and expand edit section as you describe in the HIG (left). Now we discuss if it is better (faster and easier for the user) to have inline preview (right). analysis other kcm moduls I also look at some other moduls how the other moduls work with inline preview and it would be realy an improvement. You can find the result of the research here https://share.kde.org/public.php?servic ... b726f7c810 when the other discussion points are finished I will post the mockups for the other modules as well. But the Inlinie preview works. selection list Shout the Description Name be in the preview or outside the preview. for accessibility I would prefere outside. Also for information I would provide an button but I think it would be realy good to have informations about the selections. so +1 for an INFO button. buttons Inline or outline buttons for remove, edit. For accessibility I would prefere an icon bar on bottom with import, export, remove, edit. When we say Inlinie buttons than the import buttons should also be Inlinie so that there are no additional icons. I know we can say the dev choose but to have an clear vision it would be better for everyone. edit mode Edit mode on bottom with an extend button like in the mockup from Heiko or an additional edit mode window. I'd prefere an additional edit mode window where you only select the different variables, because it is less confuse. When you have an preview that depend on will change on different edit selections it would be perfect. Only the needed information shoulde be shown. |
Registered Member
|
The workflow might be okay, but how do you make sure that we get an acceptable layout? The cursor themes in this example are just a one-column list with lot of white space on the right. If you place picture plus text next to the others the alignment gets lost as a result of different text width. And without text (as suggested in the preliminary HIG) there is no selection possible. I think we can solve the layout issues. But what I'd want to get in the end is something like the current widget style selection. By the way, your "preview" doesn't show the complete set of cursors. PS: Mixing the preview with the selection makes it impossible ugly to show a real preview of tweaked settings.
We have buttons at the bottom to apply all settings (sneak preview: this control should be a menu button which allows to apply to the current or all activities, where the default depends on the KCM), and the question was some time ago if this button should close the dialog (what is the fact in your design). Otherwise we need Ok/Cancel or rather Close to finalize the editing. Reset to undo changes is clear but help is a matter of discussion. What I dislike in your proposal are the fat buttons for GHNS (including export). Very small speed buttons (don't know how Qt calls a button with icons only) should be enough. And I believe it's important where we place those controls since it affects rather the repository than the KCM. |
Registered Member
|
So I have spent some thoughts on this too.
I agree with Heiko that we should stay as close as possible to the guideline, however, we should not force the guideline onto the KCMs only because it's the guideline. I tried to stay as close as possible to the guidelines, however, I changed a few things: 1. The preview area functions as an indicator for the currently use theme and only changes to a preview mode, once the settings are altered. 2. I tried to keep the inline previews that notmart came up with, as they are a big usability improvement IMO. 3. I tired to keep the information density relatively low because of the inline previews. Otherwise everything could look cluttered really fast. I think this system would be still relatively close to the guidelines and fit everything that can generate a preview/is visually presentable. Applied to the mouse cursor KCM I came up with something like this: It's a quick mockup, be gentle I did not bundle different colours of the same base theme together, as I am not sure if that's possible. They certainly are not bundled right now, but if that's possible in future we should definitely go for that IMO. I have made a rough mockup, on how different steps in this KCM's usuage could look: https://share.kde.org/public.php?service=files&t=bf94b248804b75594f48540d63868f42 |
KDE Developer
|
I don't think it is necessary to show all the cursors from the theme. From my pov, it would be enough to choose 4 of them (arrow, hand, busy, text) and show only them. Either in a list, or 2x2 grid.
It can be more compact, while still providing enough visual information. |
Registered Member
|
nice clear and really nice. and when you have an module where you have to edit the used theme you click the more/edit button and the edit items will scroll down over the selection area. cool. +1 |
Registered Member
|
I agree. My main point was to avoid having to click though the themes to get a good impression of what they looks like. |
Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]