System Settings Alpha Graphic Redesign
OpenPublic

Mock History

Mock Description

Hi team,

Instead of using a PDF, I will use Pholio for a set of PNGs for every screen in the current System Settings but with a redesign. I consider this redesign still in Alpha and I would like to get suggestions on what could or could not work.

Please note that I have broken a few current HIGs that we use. This is intentional. I am pushing for a method to present data and likely our current HIG is different than this iteration.

Please focus your comments on these areas

Organization
Simplicity
Labels

Other elements that may be off, misaligned, wrong icon, wrong button, etc. can also be discussed, but it is not the main objective of this version. I welcome constructive comments.

There are a very large number of changes, so older changes are hidden. Show Older Changes
romangg mentioned this in T7279: Printers.
romangg mentioned this in T7258: Device Actions.
romangg mentioned this in T7299: Digital Camera.
romangg mentioned this in T7259: Removable.
leinir added inline comment(s).Oct 27 2017, 4:51 PM
leinir added a subscriber: leinir.
Inline Comments

Perhaps this could be at the beginning of the list, rather than the end? Otherwise it would very easily end up outside the view... In principle, though, i like having this in the view :)

mart added a comment.Oct 30 2017, 1:17 PM

so, to explain the idea i had to reduce visual noise and the " frame in frame" effect, i did a quick and dirty edit in gimp of the window:


applying this to other applications, for reference, for instance to dolphin, which some little visual imperfections drive me really crazy:

tough it has more line separators (sorry, those are my thing, they do bring a lot of semantic value) it looks way cleaner and with way less frame in frame effect (dropping that one pixel rounded border in some places may be quite useful) and making every element look way more well-aligned
I don't know how to codify this to be an universal, but i would like to have it more central to at least kirigami apps (which follows this so far) and all qml-based ui, which new redesigned kcms would be

romangg added a comment.EditedOct 30 2017, 3:30 PM

The Dolphin mockup looks good. But the KCM one looks somewhat confusing. Elements belonging to each other are not visually related anymore (the list view and the rest of the KCM). Maybe it's just because of the sidebar being white as well. But there is also the problem that not all KCMs have a list view, and then their design would differ greatly from the ones with a list view.

Mockup of the last working version with larger margins and rearranged buttons:

mart added a comment.Oct 30 2017, 4:16 PM

hmm, my attention is pretty much taken by the gap there and the step the two rows of buttons do...
perhaps if the row of buttons is still aligned with the others it would look better...
and if the margin around the view is not fixed, but whatever to make the white edges in the view fixed, it could have its why...

mart added a comment.EditedOct 30 2017, 4:33 PM

here an example of the view resized in two possible size, one which the thumbnail size matches exactly the available space for the number of columns, and another one that doesn't
margins of the white area always stay fixed, those around are flexible.


of course it will need adaptation on the mobile version, as there there should never be margins around the view

januz added a comment.Oct 31 2017, 1:07 AM

The grid with margins is the best IMO. It's the best use of screen space (and it looks better than the others) . I totally agree with the frame-in-frame problem (I wish dolphin looked more like your mockup!), but I think that adding too many lines can also end up adding visual noise.

In your mockup you can remove the line between the grid and buttons, since the color change is enough to separate them. The separation line in the header isn't necessary either IMO, since it's only going to be 2-3 elements there. I took the header idea from
@ngraham's mockup for Discover, I think it could work well here too.

Also added some more padding in the buttons area.

januz added a subscriber: ngraham.Oct 31 2017, 1:07 AM
mart added a comment.Oct 31 2017, 3:46 PM

actual implementation of the proposal with flexible lateral space

I love it! Shall we move to the next phase?

That's really nice, @mart.

I also really, really like the Dolphin mockup posted up-thread. It looks so clean and sleek. The hard separation between the content, header, and footer is especially effective.

mart added a comment.Oct 31 2017, 4:09 PM

well, there are two mutually exclusive designs at the moment which are being moved forward which should be chosen from, basically the last couple of screenshots and like last januz comment.
personally, i think my latest screenshot is the "easiest" to implement, but the other option (which i still don't know how to solve a bunch of problems) looks more modern

one thing i would like to know before moving forward, is how both options would look in the case an item view is mixed with other content that is inline in the page (like in the mockups, fonts, virtual desktop, desktop effects...)
especially what happens in edge cases, who resizes who and when gets a scrollbar, how things scroll...

I have to say I'm not a huge fan of the screenshots posted at the top of the thread--the proposed total visual redesign. It seems like we would be throwing out a lot of work and all the embedded lessons learned and bugfixes accumulated over the years, and it looks like... well... it looks like Windows 10. :-( This modern depth-less totally flat interface trend is really not well suited for the desktop IMHO. It will look "stale" in a few years and we will be yet again on the treadmill of visual redesigns. My vote is for incremental improvement on what we've already got, which is really nice and has a timeless quality to it, like it's got more immunity to the UI fashions of the day.

IMHO the biggest improvement we could make to System Settings would be better grouping of settings and categories into fewer, more intuitive locations. Right now a lot of settings that seem logically grouped are scattered across many different KCMs, and many names are not very descriptive ("e.g. "Desktop Behavior" could encompass basically anything). I can propose something later tonight or in the coming days.

Thank you for your comments. @mart I have some mockups where this is the case and there is a mix of edge to edge content with other controls. I didn't think it looked bad honestly but feels a bit out of place. I can post something on it later tonight.

@ngraham I hear you, this is one of the reasons why I have also tried to implement shadows to provide depth. However, inventing a new UI is definitively much harder than taking elements from one that is already created. Likes and dislikes can be hard to manage and at this point Plasma needs a syse that is able to keep up since we have left the design aspect long back in the years for it. I am hoping that we look beyond the looks of it and focus, as I mentioned in the very first part of this thread, organization and functionality. The skin can change, but the organization needs to be there. Let's focus on that for now and then worry about the colors and the rest ;). I don't want to overwhelm our devs either thinking that they have to change looks that much at the moment.

mart added a comment.Oct 31 2017, 8:01 PM

ok, so let's make it final the "pure grid" one wit the version of the flexible spaces around the grid view.
we can then start with a mixed one and see how it works there

let's do it!

abetts added a comment.Nov 1 2017, 4:21 PM

Ok, the second stage of this redesign might be a little easier, it is aligning labels, shrinking comboboxes, and others to the center. Putting labels or "titles" on the 1st third of the space while the rest of the elements are on the 2/3 to the right. I will add a mockup to explain this.

Thank you,

Andy

mart added a comment.Nov 3 2017, 3:20 PM

as part of the work of other kcms which have a form layout, a layout component in kirigami which would be used for it https://phabricator.kde.org/D8641

Love it.

can we have install from file and Get new Theme on the left and the Size thing right align to the preview selection frame?

Could you maybe add a rough mockup of this suggestion? Just for more clarity. Also, we discussed some time ago that it would be ok for the "install" from file to be in Discover and that GHNS would "also" be in discover. What do you think? Should we do that or keep "install from file" in the same window where the themes are?

The mockups are nice, although there is a part I do not particularly like: all of them have a lot of empty areas, which means they are planned for big screens. By just scaling the pictures so that fonts had normal size, I get a window higher than my 15'' 16:9 laptop! :)
Also, I am concerned about those designs on mobile... Is the spacing supposed to scale? How would the 2-level drawer look on a phone? Could you picture those?

I highly doubt that we will turn this work into a mobile app in the same way. We are not close to that discussion yet. Empty space works best in desktop. It allows people to focus. To cram every corner of the interface with a lot of data is also very challenging for finding your way. I can definitively review the margins. As of right now, we don't have a lot of work going into this project so I prefer to address this question once there is more development into it.

I see your point, I am just afraid of the opposite effect: the general structure of current settings has even more mobile in mind that the proposed one. And as there currently is not much development on that side, I am trying to not let it slip out of the way completely, as this year could well be our last chance to jump into mobile.

mmustac added a subscriber: mmustac.Feb 1 2018, 6:23 AM

I am kind of wondering if KDE needs to include the following KCMs at all:
T7302: Connection Prefs
T7303: SSL Prefs
T7304: Cache
T7305: Cookies
T7306: Browser Identification

Please correct me if I am wrong about this but from my understanding the only application which made use of this was/is konqueror...
And if it is so then it does not have to be included int the global system settings but instead in the application settings itself.

The kcms are included in KIO but from my point of view they can be dropped

Agreed. These aren't needed systemwide.

davidedmundson added inline comment(s).Feb 8 2018, 10:45 AM
Inline Comments

I want to have a button to configure the keyboard shortcut for krunner.

It'll expose what krunner is in a clear way, make it obvious what these settings are for, and we can tie it in with the defaults button

ngraham added inline comment(s).Feb 14 2018, 8:29 PM
Inline Comments

We should take the opportunity to solve a major usability problem: the lack of a simple slider to choose the pointer speed. All other OSs do this, but we have a baffling text field called "Pointer Acceleration" instead. We should make that a slider and put it up near the top.

Everything under the Advanced header and below should not be visible by default; there's too much stuff. It should be collapsed under a disclosure triangle or a clickable header, similar to what's proposed in https://bugs.kde.org/show_bug.cgi?id=389803

Single/double click settings belong elsewhere, as they are not mouse-specific. Touchpad and touchscreen users are impacted by this setting, too.

FYI, I was going to take on the clock for the next release. I've got some questions

Inline Comments

If the battery is flat, and the computer boots up with 1st Jan1970, I'd have to click the next arrow 48*12 = 576 times.

I can either do something like the current "<<" and "<" buttons

Or I can copy the plasma calendar UI, which switches mode when you press on the month name. It might need some icon to make it more obvious.

Should I have a text entry option?

will this be a spin box? (the one with the arrows to move forwards/back

I need a checkbox to enable NTP. (set date and time automatically)

When this is checked, should I disable or hide the calendar and clock?

I'm assuming I'm keeping the current

Area | Region | Comment table here

I don't think it's possible to use the codes like here

In the UK, we are either on the code GMT or BST
(CET, CEST for the EU people) depending on whether it's summer or not you wouldn't explicitly chose between them.


Some places do the map selection (calamares for example). Is this a good idea?

progwolff added inline comment(s).Feb 15 2018, 12:31 PM
progwolff added a subscriber: progwolff.
Inline Comments

This looks strange to me.
It's unclear what happens if I set the default font here. Will all other fonts change? Or will it have no effect at all if for example the menu font is set so something else? This was a little clearer in the current implementation, where this was hidden behind a seperate button.

In my opinion this could either be dropped, or we could add a button behind each font selector instead, saying "apply to all".

Maybe add a font preview, similar to that in https://phabricator.kde.org/M112/412/ ?

It could help to have some visual hints here on what settings will look best. See discussion in https://phabricator.kde.org/M120

I like those suggestions. I would probably not move the previous, however, since they are already loaded in a different screen. But maybe, what would be helpful is to use a menu that showcases the font in some way. For example, like this:

FONT PREVIEW IDEA

What do you think?

progwolff added a comment.EditedFeb 19 2018, 4:03 PM

@abetts The font itself has already a preview in the font chooser. This is okay for me. What I meant to have a preview for is what elements a font is used for. For example it is a little unclear what "small fonts" is used for unless you apply the settings and try it out.
But I'm not sure how a preview for this would look like either.

I wrote these comments on October 23rd, but they got stuck in a draft. I can't seem to delete them. A couple are still relevant though.

Inline Comments

In the original, "Activating Windows" is a section title, along with Raising Windows and Multiscreen behaviour.

Multiscreen behaviour is missing here, both separate screen focus and active screen follows mouse.

Hover delay missing here

Is the name of the desktop only visible when editing it?

"Delay focus by" is an attribute of the activation policy, not of focus stealing prevention.

In panels using this pattern, I think the + slide should be first so that if there are more slides than can be seen without scrolling, it is still apparent that there is a way to add another item.

I'm guessing these icons appear on mouseover? How does one discover what they mean?

argonel added inline comment(s).Feb 20 2018, 10:22 PM
Inline Comments

This strikes me as odd. In Applications > File Associations a conventional tab control is used, but on this one there's an orphan button way down at the bottom.

broulik added inline comment(s).Apr 22 2018, 1:41 PM
broulik added a subscriber: broulik.
Inline Comments

Do we really need this?

There isn't any trace of this in KIconThemes and Plasma Icon surely doesn't honor that.

This slider needs to be associated with icon type below, right now this makes no sense

What KCM are your comments about @broulik ?

I had some comments about the date & time KCM mockup, I followed that up on https://phabricator.kde.org/T7248 as here has quite a lot of cross-talk

abetts added a comment.Jun 3 2018, 8:26 PM

@hein Can I ask to please list the changes we have decided on that require that I update the mockups? I know we have a few, but I am not sure that I know all of them. @ngraham Can you point those out to me as well please? I will work on a smaller KCM mockup subset to show the updates.

Inline Comments

@hein worked on this KCM. No need to use this specific mockup for guidance.

ngraham added a comment.EditedJun 4 2018, 2:21 AM

I went through them all and I have the following observations and rcommendations:

There's a design inconsistency: grid items seem to have buttons that appear on hover, but many mockups also have a Fine tune button that presumably does the same as clicking on the inline Edit button. I think we need to sort out which approach we want to use for everything. I would generally advise against the inline hover button approach because having now implemented it in several KCMs, we can see the following drawbacks:

  • The inline buttons get in the way of clicking on the actual item itself; it's easy to accidentally click on an inline button instead!
  • it's difficult to distinguish the inline buttons from the content, especially for grid items that are very visually busy, like in the Icons KCM. We can't have them appear over a dark overlay as depicted in the mockups because then the content of the item itself is obscured right at the moment when the user is focusing on it.
  • Not discoverable; most users don't wave their mouse around to look for hidden UI elements the way weirdos like us do
  • Not touch-friendly for users of convertible laptops; there's no concept of "hover" with touch

My recommendation is to rethink this paradigm to improve usability and discoverability.

Icons > Advanced (https://phabricator.kde.org/M112/408/) - No longer needed, already implemented inline without needing a different page

Screen Lock (https://phabricator.kde.org/M112/397/) - needs a redesign; the whole Lock Screen Wallpaper section is not implementable as two text fields; there needs to be room for a big grid view of wallpaper images for users who use a single image or a slideshow. Also, "Keep screen locked on resume" needs a better label; it's not obvious that "resume" means "resume from suspend". And from a user's perspective, what's the difference between that and "Enable screen lock", anyway? Needs some more design work IMHO.

Task Switcher > Alternative (https://phabricator.kde.org/M112/390/) - What does this actually do? Does anyone know? Is it still needed?

Window Management > Window Behavior (https://phabricator.kde.org/M112/385/) - This whole thing seems totally overwhelming; there's way too much going on there. And I think it will be impossible to avoid making this need to scroll, which we're trying to avoid. Most of this stuff is super advanced functionality that probably shouldn't be exposed so directly. I would put most of this stuff behind an Advanced button. May need a redesign.

Shortcuts > Standard Shortcuts (https://phabricator.kde.org/M112/382/) - Instead of having a list view of categories and a list view of shortcuts for the selected category, could we just have a single list that shows all shortcuts within internal sections or headers? I feel like this would be visually cleaner and also make it much easier to browse for shortcuts.

Startup And Shutdown > Desktop Session (https://phabricator.kde.org/M112/379/) - Something tells me "Turn off Computer" shouldn't be an option for what to do on login. :) The list box in "Applications to be Excluded from Sessions" needs visible controls for adding and removing apps.

Personalization > User Manager (https://phabricator.kde.org/M112/372/) Let's keep the UI to create a new user as an actual button instead of the text "New User" within the user list.

Applications > Default Applications (https://phabricator.kde.org/M112/363/) - another example of the dual-list paradigm not being optimal IMHO. Given the small number of items that will appear in the left list, I'd suggest removing it and presenting all that stuff in the main view.

Applications > Locations (https://phabricator.kde.org/M112/365/) - I feel like this should be hidden on an "Advanced" page for another KCM. Everything here is super nerdy and very, very infrequently used by anyone.

Accessibility > Accessibility (https://phabricator.kde.org/M112/361/) - Another example of a huge long list that's visually overwhelming. I think we may not be able to get around the need for tabs here.

Settings > Connection preferences (https://phabricator.kde.org/M112/352/) Too nerdy to be generally applicable. This used to apply to Konqueror back when Konqueror was KDE's flagship web browser, but Konqueror is now unmaintained, so instead it generally applies to KIO's own rarely-used network I/O operations. Consider hiding on an "Advanced" page".

Settings > SSL Preferences (https://phabricator.kde.org/M112/357/) - Same.

Settings > Cache (https://phabricator.kde.org/M112/356/) - Same.

Settings > Cookies (https://phabricator.kde.org/M112/355/) - Same.

Settings > Browser Identification (https://phabricator.kde.org/M112/353/) - Same.

Settings > Connectivity (https://phabricator.kde.org/M112/350/) - a completely useless KCM. Recommend deletion instead of porting. See https://bugs.kde.org/show_bug.cgi?id=164283

Bluetooth > Devices (https://phabricator.kde.org/M112/447/) - I think there's room to merge this KCM with Bluetooth Adapters (https://phabricator.kde.org/M112/448/) and Bluetooth Advanced Settings (https://phabricator.kde.org/M112/449/). Each one has only a very small amount of stuff in it, so there's definitely room on the page.

Input Devices > Mouse (https://phabricator.kde.org/M112/445/) - Most of these settings are inapplicable to the new Libinput version; the mockup should be a redesigned version of https://phabricator.kde.org/file/data/5reksg7cofdcbrcpavjx/PHID-FILE-kjjw4zv565zkd4pestpd/Screenshot_20180318_223047.png

Input Devices > Touchpad (https://phabricator.kde.org/M112/443/) - Same, though no mockup is necessary since I've been guiding the design in line with these general principles so far in https://phabricator.kde.org/D13141

Multimedia > Audio and video (https://phabricator.kde.org/M112/432/) - This KCM is super technical and very difficult to understand. It definitely needs a redesign, but I'm not sure exactly how.

Power Management > Activity Settings (https://phabricator.kde.org/M112/426/) - Recommend merging this KCM with either the general Power management KCM, or the Activities KCM. A KCM with only a single radio button seems like a waste.

abetts added a comment.Jun 4 2018, 3:14 AM

I got plenty to do! Thanks Nathan.

roberts added a subscriber: roberts.Jun 6 2018, 7:48 PM

FWIW, I agree with @ngraham here, interactive elements should be visible in the view at rest. Buttons appearing on hover violates the principle of least surprise, makes selection unpredictable, and raises cognitive load.

abetts added a comment.Jun 6 2018, 7:52 PM

I agree, the user doesn't know what to expect.

Fuchs added a subscriber: Fuchs.Jun 6 2018, 9:06 PM

@ngraham

Task Switcher > Alternative (https://phabricator.kde.org/M112/390/) - What does this actually do?

It lets you define an alternative task switcher where you can set the presented options independently.

Example use case: you want one switcher to go through all windows, with a thus more compact layout, and one switcher which only goes through windows on the current activity (or virtual desktop, whatever you use), which can have a bit more of a big, preview layout.

This way you can assign a keyboard shortcut to both and have one for each use case.

Does anyone know?

Yes

Is it still needed?

Yes, I think so. Imho in an ideal world

  1. it would not allow 2, but rather n alterantives, since there are people who might have e.g. 3 use cases (all windows, all of current VD, all of current activity)
  1. It's definitely for power users, so I'd only show it if a user added an alternative on purpose

If the current system (kwin, that is) allows arbitary, I'd say give users an option to add (and therefore also remove) alternatives. If the hard limit is two, I'd say give the users a button to add one and only show the second set of controls (in a tab or via a dropdown on top like with the new mouse/touchpad kcm or whatever) only if the user chose to have two of them.

hein added a comment.Jun 6 2018, 9:33 PM

Andy Betts, [07.06.18 06:20]
and yes, I was asking if you could help me track those KCMs where we introduced changes to the mockups

Andy Betts, [07.06.18 06:20]
Hopefully it is not a huge list?

Eike Hein, [07.06.18 06:21]
I'm not sure. I'd suggest going over the Phabricator KCM reviews (the ones I can think of right now: Language, Icons, Launch Feedback, Colors, Widget Styles, Cursors, etc. - maybe more). In terms of components, we have a new "Grid" style KCM and a new "List" style KCM and we figured out how we want to do draggable lists and we made FormLayout with its various abilities (reflow, clickable sections, etc.)

Eike Hein, [07.06.18 06:22]
So now it's about "If I had to do the design with these components, I would ..."

Eike Hein, [07.06.18 06:22]
So for example take the Keyboard KCM, which is now going to reuse the new "Draggable list" component/pattern we made for the Language KCM together - in the mockups, the Keyboard KCM is actually just blank, the mockup has no content

Eike Hein, [07.06.18 06:22]
There's probabl other cases where we didn't know the answer at the time, where we have a more solid idea now

Eike Hein, [07.06.18 06:24]
The process has been: Make initial mockups -> Consolidate ideas and come up with reusable components for consistency between KCMs and now it needs to continue with -> update mockups to reflect new components

Eike Hein, [07.06.18 06:25]
And this cycle will probably continue as we identify the need for new components, make them, ...

Eike Hein, [07.06.18 06:26]
Maybe @kbroulik also has an opinion here since he was one of the people who expressed frustration with aging mockups

Andy Betts, [07.06.18 06:30]
Oh this is good information

Andy Betts, [07.06.18 06:30]
Can you copy this into the ticket?

Andy Betts, [07.06.18 06:31]
Just so I can review after work?

Andy Betts, [07.06.18 06:31]
Please? :D

Thanks @Fuchs. Even if KWin doesn't support an arbitrary number of switchers, I think we should consider this "additional task switcher" feature to be for power users and maybe hide it behind an Advanced button or something.

@Fuchs

it would not allow 2, but rather n alterantives, since there are people who might have e.g. 3 use cases (all windows, all of current VD, all of current activity)

That is a really good idea! That would be a really nice feature.

@ngraham

Even if KWin doesn't support an arbitrary number of switchers, I think we should consider this "additional task switcher" feature to be for power users and maybe hide it behind an Advanced button or something.

I think the most important improvement would be to design the interface such that the option becomes easier to understand. If you didn't understand what the configuration did then many users probably will not understand it either. Moving it behind an Advanced button may be a fine idea but not as a substitute for making the configuration easier to understand in the first place.

Totally agreed. A better way to explain the feature is also definitely needed here.