[Kickoff] Make the search field always look like a search field
ClosedPublic

Authored by ngraham on Aug 22 2018, 11:32 PM.

Details

Summary

This patch makes Kickoff's search field always look like a search field, instead of only after you start typing. Functionality remains the same (with the exception of the hidden info display, which moves to underneath the user name)

BUG: 397581
BUG: 398276
BUG: 398278
FIXED-IN: 5.15.0

Test Plan

All functionality still works:

Diff Detail

Repository
R119 Plasma Desktop
Branch
kickoff-search-field-looks-like-a-search-field (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 2135
Build 2153: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes
ngraham added inline comments.Aug 23 2018, 12:42 PM
applets/kickoff/package/contents/ui/Header.qml
153

Oops, this was left over from an earlier idea that I abandoned. Removed.

ngraham marked 2 inline comments as done.Aug 23 2018, 12:43 PM

The fact that the search field in Kickoff isn't permanently visible is a criticism I heard at various exhibitions where I showcased Plasma.

To address the design and aesthetic angle, I see this as the natural next step in refining what "minimalism" means to KDE, which is a microcosm of a larger trend throughout the design world vis-a-vis minimalism:

  1. People go crazy with decorations, frames, lines, colors, highlights, etc
  2. There's a natural backlash against this excessive ornamentation
  3. All of those things are removed in the name of minimalism
  4. This goes too far and destroys the boundaries between dissimilar elements, creating an uncomfortably cold, stark, undifferentiated appearance
  5. A process of refinement takes place where differentiating elements are re-added where appropriate, while preserving the overall minimalistic aesthetic

This patch is in step 5. :)

ngraham edited the test plan for this revision. (Show Details)Aug 23 2018, 12:53 PM
ngraham edited the test plan for this revision. (Show Details)Aug 23 2018, 1:06 PM
ngraham edited the test plan for this revision. (Show Details)

There doesn't have to be one solution and this is hardly an issue where such a hardline approach is warranted. There is nothing cold, stark or undifferentiated about Kickoff and its search bar now. It's just that it's a problem for people who aren't as intuitive with finding their way in a UI. And slapping on a white opaque box with bright blue outer glow just like it was in KDE 4 doesn't seem like preserving minimalism either. It isn't even just about design because there is no need to have that kind of a prominent box sticking out there the whole time if it's not being used the whole time. I can even support you in making the searchbox show up at all times as a default, but I urge you again to please consider leaving an option to have it the same as it is.

There doesn't have to be one solution and this is hardly an issue where such a hardline approach is warranted. There is nothing cold, stark or undifferentiated about Kickoff and its search bar now. It's just that it's a problem for people who aren't as intuitive with finding their way in a UI. And slapping on a white opaque box with bright blue outer glow just like it was in KDE 4 doesn't seem like preserving minimalism either. It isn't even just about design because there is no need to have that kind of a prominent box sticking out there the whole time if it's not being used the whole time. I can even support you in making the searchbox show up at all times as a default, but I urge you again to please consider leaving an option to have it the same as it is.

Sorry, it almost never makes sense to have user-facing options for this kind of very specific thing. I know that change can be a bit scary at times, but design evolves, and we have a theming system for people who don't like the defaults.

Things should look like what they are, and it's generally not considered good design to have the same UI element look different in different contexts. Text fields should look like text fields, otherwise discoverability suffers and the user interface becomes unpleasantly inconsistent.

Also, Filip, I notice that you only just signed up for a Phabricator account 8 days ago and literally 100% of your activities have consisted of objecting to patches I've submitted. We value user input, but it's not very considerate to show up in a developer environment simply to gum up the works. There are always a thousand reasons not to do something. But in all systems, stasis is death. The users' need for stability (which is indeed very important) must be balanced against the system's need for flexibility and adaptability--without which, the system eventually dies or loses its appeal to users, both current and future. I ask that you give me and other developers the benefit of the doubt when we are working on evolving the design. We might not be as dumb as we look! :-)

abetts accepted this revision.Aug 23 2018, 2:31 PM

I like this idea, it is easier to discover.

I've joined partly because feeling some blunders on my skin; I'd like to contribute so that something like the 5.13 media icons thing doesn't happen again (ie. find potential problems for non-Breeze users), but also due to feeling like that some changes get proposed without thorough analysis and without taking into account some arguments, and if they get opposition they just get reposted a few months later. I've also noticed that this has alienated some people and I feel a bit concerned. The posts I've commented here on are the simply the posts that I felt competent enough to comment on and where I saw potential issues; I have no coding knowledge and can't comment on anything beyond the simpler things. If you remember me from Reddit you will find I've had nothing but praise for you. It isn't personal, please take my arguments into account instead of looking at it that way. I'm not a part of KDE nor can I accept any patches so of course I can only be useful if I point out the issues :)

As for this task, I can't say I'm not disappointed with ignoring the arguments presented, but I will leave it to other people to discuss.

Thanks for the kind words. I don't think the objections have been ignored, though:

Objection:

but my question is: is it possible to somehow make a toggle to keep the status quo ie. have no search box? [...] I urge you again to please consider leaving an option to have it the same as it is.

I'm -1 for this, it's not needed to click in just start typing witch is more intuitive. Adding this optional by config?

Response:

Sorry, it almost never makes sense to have user-facing options for this kind of very specific thing. I know that change can be a bit scary at times, but design evolves, and we have a theming system for people who don't like the defaults.

Objection:

Also please note that the clear button functionality is working wrong with RTL layouts.

[Irrelevant to this patch; it's an issue with the TextField itself that should be fixed there.]

Objection:

Heh, flip-flopped back to https://userbase.kde.org/images.userbase/thumb/f/fe/Kickoff_Menu_Style.png/300px-Kickoff_Menu_Style.png till we get the next bug report about how it should be hidden.

The original issue (in Neon/Kubuntu task, not sure) was that Kickoff is not clear if one can search or not, because of text changing. Why not just keeping the current “Type to search” label as is, and move the user@host text up as in the patch?

There is nothing cold, stark or undifferentiated about Kickoff and its search bar now. [...] And slapping on a white opaque box with bright blue outer glow just like it was in KDE 4 doesn't seem like preserving minimalism either.

Response:

[...] I see this as the natural next step in refining what "minimalism" means to KDE, which is a microcosm of a larger trend throughout the design world vis-a-vis minimalism:

More generally, one of the reasons why we have a HIG is so that we can all agree to abide by a series of common rules rather than having to re-argue the same subjective aesthetic matters over and over again. And on this subject, the HIG says:

Application specific theme

Only set a custom color scheme, never set a custom widget theme.

Kickoff isn't an application, but the message is clear: abide by the appearance specified by the global widget theme, and don't apply custom styles to common controls. But that's exactly what Kickoff is doing, in violation of this recommendation.

ngraham updated this revision to Diff 40306.Aug 23 2018, 3:05 PM

Remove FIXME now that it's being worked around with D15021

@davidedmundson, does this look okay now?

Apparently the discoverability of the search field is poor, so it makes sense to make it more prominent. But the cursor should not flash all the time and having it all the time in Plasma blue with bright white background is also problematic. So I would propose the following changes:

  • Show the search field always.
  • No cursor without text.
  • Default color of border without text.
  • Default color background without text.
  • Default text ("Type to search") without text
  • Click in the search field highlights it and makes the cursor appear.
  • Typing highlights it and makes the cursor appear.

This makes the change more complicated. Sorry for that.

So basically, you want it to be unfocused by default, and typing (or clicking in it, obviously) makes it focused.

Yeah Nate, but if you look at your responses they're predominantly on a much higher level of abstraction (e.g "next step", "change is scary") than the issues raised. That's why for me they don't address them completely.

The fact here is that you have a unibody Kickoff and yeah there is certainly a legitimate need to add a box in there. The goal would be to avoid having it stick out too much. The problem right now is that the background is too white and that the outer glow is too strong. Moreover, outer glow is sort of a remnant of Oxygen isn't it?

I still think it's best to have an option, but couldn't we at least make it more subtle?

Example (the corners needs to be rounded):

Yeah Nate, but if you look at your responses they're predominantly on a much higher level of abstraction (e.g "next step", "change is scary") than the issues raised. That's why for me they don't address them completely.

The fact here is that you have a unibody Kickoff and yeah there is certainly a legitimate need to add a box in there. The goal would be to avoid having it stick out too much. The problem right now is that the background is too white and that the outer glow is too strong. Moreover, outer glow is sort of a remnant of Oxygen isn't it?

I still think it's best to have an option, but couldn't we at least make it more subtle?

Example (the corners needs to be rounded):

Well, this is exactly the sort of thing that we can help with as designers. I have trouble explaining technical concepts while others may struggle with graphics. I would consider your proposal from a visual POV. What do you think @ngraham ?

So basically, you want it to be unfocused by default, and typing (or clicking in it, obviously) makes it focused.

True that. With the exception that beginning to type should activate it. A similar field can be found in the SySe. But it has white background always and does not activate automatically when beginning to type (it's activated at the beginning though)

@davidedmundson, does this look okay now?

Code wise, yes.

UI/Concept wide, I don't want to have an opinion either way

@davidedmundson, does this look okay now?

Code wise, yes.

UI/Concept wide, I don't want to have an opinion either way

Thanks Dave

ngraham planned changes to this revision.Aug 24 2018, 2:19 AM

So basically, you want it to be unfocused by default, and typing (or clicking in it, obviously) makes it focused.

True that. With the exception that beginning to type should activate it. A similar field can be found in the SySe. But it has white background always and does not activate automatically when beginning to type (it's activated at the beginning though)

I think Kicker provides what we're looking for: its search field only shows the focus highlight when you're typing or hovering the mouse over it. It's subtle, but effective. I'll see if I can do that here too.

Actually both Kicker and System Settings give their search fields visible focus by default. Kicker does make the field visibly lose focus after you start using the keyboard to navigate through the list of returned items, though. That's a nice touch and I'll do that here.

But maybe we should think through why we're objecting to having the search field be visibly focused in the first place--because in general, the thing that accepts keyboard input should look visibly focused. Rather than violate that principle, let's try to figure out what's making us want to in the first place.

Perhaps the white background and blinking cursor appear too attention-getting in comparison to the rest of Kickoff, which tries very hard to be flat and gray and avoid separators (e.g. between the different sections and the tab bar at the bottom or the header on top). I wonder if we wouldn't feel like the search field was so jarring if there were better differentiation between other elements. For example:

Or perhaps if the list views used a lighter background color:

Just a thought, crude mockups, etc.

Also probably the header area will look better defined if @sharvey's patch to put the avatars inside a circle (D13415) lands.

Why don't we have a simple search icon that indicates that one can search in the kickoff, and once you click on it you get switched to the search layout, where you'll find a note saying you can also search by direct typing, and a “Got it” as many websites does? Youtube doesn’t force a long search input in the channel page.

I believe that we need such a concept in Plasma and KDE apps. Some notes that are displayed only if it’s the first time you are using this, and can be easily dismissed. Even an iteractive walkthorght for filled-with-features applications like the PIM suit.

rooty added a subscriber: rooty.Aug 24 2018, 12:11 PM

Actually both Kicker and System Settings give their search fields visible focus by default. Kicker does make the field visibly lose focus after you start using the keyboard to navigate through the list of returned items, though. That's a nice touch and I'll do that here.

But maybe we should think through why we're objecting to having the search field be visibly focused in the first place--because in general, the thing that accepts keyboard input should look visibly focused. Rather than violate that principle, let's try to figure out what's making us want to in the first place.

Perhaps the white background and blinking cursor appear too attention-getting in comparison to the rest of Kickoff, which tries very hard to be flat and gray and avoid separators (e.g. between the different sections and the tab bar at the bottom or the header on top). I wonder if we wouldn't feel like the search field was so jarring if there were better differentiation between other elements. For example:

Or perhaps if the list views used a lighter background color:

Just a thought, crude mockups, etc.

Also probably the header area will look better defined if @sharvey's patch to put the avatars inside a circle (D13415) lands.

I like the first one, but only if you make both lines of equal length (preferably the length of the line below Search...). I think the idea to emphasize the fact you can search in the launcher is a good idea, but you also don't need a box - you can also just make the "Type to search" message stick around and prevent it from changing to "username@machine (distro name)" because that's confusing to someone that hasn't been using Plasma from the getgo (they're not aware that they can, in fact, run a search).

But yeah imo it looks fine.

I wonder if we wouldn't feel like the search field was so jarring if there were better differentiation between other elements. For example:

Exactly! In your second proposal I don't think the serachbox sticks out, even as it is. At least to me it looks fine. At the same time it is drawing back, albeit not totally, to old Kickoff so there would have to be good designer conceptualization and solution for how to keep it modern.

When I look at Kickoff now and just think narrowly: how can I make the search more prominent and keep designer consistency, what makes most sense to me is to reuse the horizontal blue line we already have as a Kickoff tab selection indicator, and even as the indicators of open windows and plasmoids. These lines are indeed minimalist. Unfortunately that looks terrible:

Not even making it a classic Breeze 1px line feels right, although I guess it's a bit better:

Why don't we have a simple search icon that indicates that one can search in the kickoff, and once you click on it you get switched to the search layout, where you'll find a note saying you can also search by direct typing, and a “Got it” as many websites does? Youtube doesn’t force a long search input in the channel page.

I believe that we need such a concept in Plasma and KDE apps. Some notes that are displayed only if it’s the first time you are using this, and can be easily dismissed. Even an iteractive walkthorght for filled-with-features applications like the PIM suit.

I've had a look at that setup. It's pretty sleek. But we have to consider that YouTube still keeps a full-fledged serachbox on their homepage, and the channel is a less important of a place. So if we apply that to Kickoff, it looks like this:

And then when it's opened it would look like this:

IMO we still haven't solved the problem of it not being obvious that you can search. Maybe having a search icon isn't a bad idea though, but I think we'd still have to make it more obvious somehow:

This was just a little foray into what is possible, nothing definitive or great. In the pictures I've shortened the search box so that there is equal distance from the left and right edge of Kickoff, for symmetry reasons mostly, but also because I am a bit bothered that the Favorites tab is wasting about 60% of horizontal space on nothing and I didn't want to drag attention to the right side. This may be fixed when we get a new Home tab and isn't too important right now anyway.

Of your mockups, I like the last one the best, but nonetheless I'm just not a fan of defining a custom textfield style here; I think we should follow the HIG. If we had a dedicated "search field" control that was more subtle than general textfields, we could use that, but we don't. Until and unless we create one, I think we should err on the side of internal consistency and use the pre-existing textfield control.

I too am bothered by the amount of horizontal wasted space, which is one of the reasons why I proposed T9041: New "Home" tab for Kickoff. But that's a discussion for another phab task :)

Maybe something I can explain, for us designers, is that we have a set of defined rules and guidelines for visual design on KDE and we should strive to first search for an option that is adapted or allowed by these guidelines. If that doesn't work, we could propose other control styles and see if there is willingness in the community to create them. Then we can move forward. You can find all these guidelines at hig.kde.org

Of your mockups, I like the last one the best, but nonetheless I'm just not a fan of defining a custom textfield style here; I think we should follow the HIG. If we had a dedicated "search field" control that was more subtle than general textfields, we could use that, but we don't. Until and unless we create one, I think we should err on the side of internal consistency and use the pre-existing textfield control.

I too am bothered by the amount of horizontal wasted space, which is one of the reasons why I proposed T9041: New "Home" tab for Kickoff. But that's a discussion for another phab task :)

Agreed, consistency all across the UI is preferable to bursts of design ideas in particular places. After the proposal by Safa it occurred to me that maybe we overlooked adding an icon so the minimal change I see that can be done is to add a search icon to the left of "Type to search..." and remove the code that shows the "uname -a" information. Small improvement I'd say, but I don't know if it's enough. If not and if we can't modify the search box style too much, then functionality reasons triumph and the search box as is has to be shipped, but with still keeping in mind the future tasks of perhaps updating the HIG and/or redesigning Kickoff to not be as unibody.

And yep, saw that task, that's what I was referencing! Don't get me wrong, the Favorites tab is great at what it does, but a Home tab as a default tab would be an improvement.

I like the idea of conditionally adding a little magnifying glass icon to the text field to indicate that it's a search field. If other folks are on board too, I can probably put together another patch to add that as an optional feature of the PlasmaComponents TextField (rather than just here in this patch). That way we could also have that for KRunner, Kicker, Application Dashboard, etc.

Meanwhile, what's our path forward here? Are we migrating towards agreement about keeping the current visual style and default focus behavior? Should we separate the header and tab bar from the content area with single-pixel lines? Should we do something else?

Exactly! In your second proposal I don't think the serachbox sticks out, even as it is. At least to me it looks fine. At the same time it is drawing back, albeit not totally, to old Kickoff so there would have to be good designer conceptualization and solution for how to keep it modern.

When I look at Kickoff now and just think narrowly: how can I make the search more prominent and keep designer consistency, what makes most sense to me is to reuse the horizontal blue line we already have as a Kickoff tab selection indicator, and even as the indicators of open windows and plasmoids. These lines are indeed minimalist. Unfortunately that looks terrible:

(deleted screenshot from reply)

Not even making it a classic Breeze 1px line feels right, although I guess it's a bit better:

(deleted screenshot from reply)

I've had a look at that setup. It's pretty sleek. But we have to consider that YouTube still keeps a full-fledged serachbox on their homepage, and the channel is a less important of a place. So if we apply that to Kickoff, it looks like this:

(deleted screenshot from reply)

And then when it's opened it would look like this:

(deleted screenshot from reply)

IMO we still haven't solved the problem of it not being obvious that you can search. Maybe having a search icon isn't a bad idea though, but I think we'd still have to make it more obvious somehow:

(deleted screenshot from reply)

This was just a little foray into what is possible, nothing definitive or great. In the pictures I've shortened the search box so that there is equal distance from the left and right edge of Kickoff, for symmetry reasons mostly, but also because I am a bit bothered that the Favorites tab is wasting about 60% of horizontal space on nothing and I didn't want to drag attention to the right side. This may be fixed when we get a new Home tab and isn't too important right now anyway.

Well, I think the one with the line seems nice, the thinner one of course.
And about the icon, maybe we should just keep it an icon to the right of the user@host label, and that's it? Something like this?

(I was trying to make a video but then bindings failed, so stepped back).
We can add a “Search…” text to that button, or a tooltip (not sure about HIG stuff). But I think that such a button (as is) is more than enough to inform users about the search functionality.

rooty added a comment.Aug 24 2018, 4:52 PM

I like the idea of conditionally adding a little magnifying glass icon to the text field to indicate that it's a search field. If other folks are on board too, I can probably put together another patch to add that as an optional feature of the PlasmaComponents TextField (rather than just here in this patch). That way we could also have that for KRunner, Kicker, Application Dashboard, etc.

Meanwhile, what's our path forward here? Are we migrating towards agreement about keeping the current visual style and default focus behavior? Should we separate the header and tab bar from the content area with single-pixel lines? Should we do something else?

the magnifying glass icon idea is really nice

the box seems like a good idea; the single pixel lines? dealer's choice, personally i feel the separator lines look good in your screenshots but please keep them gray (subtle / easier on the eyes, i personally feel the single pixel icons in breeze are too coarse, so on my rig i swap them out for adapta icons)

P.S. can you please post a screenshot of what it would look like in breeze dark for comparison?

filipf added a comment.EditedAug 24 2018, 10:59 PM

To add more to the analysis, since Kickoff is a plasmoid, what seemed like a good idea to me was to have a look at how other plasmoids are designed (especially with relevance to the elements touched on in this proposal).

The Clipboard plasmoid stood out to me because as another unibody plasmoid, it seems to me like it handles the search box gracefully. I created some pics, this time with Breeze Dark to switch it up a bit:

Behavior: (1) non-selected it doesn't have an outer glow or a colored stroke; (2) when hovered over the stroke inherits the selection color; (3) only when clicked on or typed it does it turn on outer glow and the text selection line blings

Copied into Kickoff it doesn't look too bad (left pic). Since Kickoff is and can be more transparent, if possible what would help blend it in more is to lower the opacity by maybe 15-20% (right pic):

Now as for adding differentation in Kickoff, my observations were:

  • Kickoff isn't actually unibody -> if we look closely, Breeze Dark reveals that it actually places tabs into squares + other tabs such as the Application one already have separators
  • Other plasmoids do make use of separators, adding them would not create a design inconsistency on the whole
  • Although not as common, some plasmoids do also shade certain sections differently (e.g. plasma-pa), so at least what can be concluded is that shading a part of Kickoff differently also wouldn't be unprecedented

This is great! This is pretty much exactly what I originally suggested and yet has some tweaks to make it even better. Thanks for doing this. :) 👍

I really like the last suggestion from Filip. It blends well with the theme.

huftis added a subscriber: huftis.Aug 26 2018, 5:47 PM
ngraham requested review of this revision.EditedAug 26 2018, 7:26 PM

Awesome, thanks for introducing that additional information, @filipf. It seems like we have some inconsistency here in our Plasma search fields; I will summarize:

InterfaceSearch field has keyboard focus by default?Search field visible by default?Search field visibly focused by default?When does it become visibly focused?After gaining keyboard focus, when does it lose it?
DiscoverYesYesNoAfter typing or clicking on itWhen you click on anything else
KlipperYesYesNoAfter typing or clicking on itNever
Widget ExplorerYesYesYesN/A; starts out focusedAfter using the key to move focus to the list
KickoffYesNoN/A; not visible by defaultAfter typing or clicking on itNever
System SettingsYesYesYesN/A; always focusedAfter navigating to a KCM
KickerYesYesYesN/A; starts out focusedAfter you start to navigate the list

It seems like for the most part the interfaces that make the search field invisible or have a different appearance by default are in the minority and are being inconsistent with everyone else. So I'm glad that we generally have consensus that fixing that for Kickoff here is a good idea. I may do the same for the Widget Explorer too; then we'll have 100% consistent visible-by-default search fields!

After performing this investigation and all the accompanying behavioral tests, I realize now that there's a very good reason to keep keyboard focus on the search field even after the list of search results is being navigated with the up and down arrow keys: it's so you can edit your search query even after navigating the list. The only reason why Kickoff doesn't do this is because it has multiple lists that can be navigated between with the left and right arrow keys. Kickoff doesn't do that, so I think we have to keep that with this patch.

So onto the next subject: whether or not to have the search field visibly focused by default, or instead to only show the focus when you click on it or start typing. All of the clients throughout Plasma give the search field keyboard focus by default, even if the visual appearance doesn't reflect this, but we are very inconsistent with the visual appearance: System Settings and Kickoff have it visible and focused by default; klipper and Discover have it visible but not visibly focused until you click or type; Kickoff and the Widget explorer have it invisible until you click or type.

I'll admit that I have a preference for giving the search field visible focus when it actually has keyboard focus. From that perspective, this patch implements that preference, though I'm willing to continue the conversation to achieve consensus, because right now the HIG doesn't say anything about this subject, and it should. In fact it does not address the use case of using LineEdit controls as search fields, or even anything about focus behavior at all.

However, regardless of what we choose, I would like to move towards unifying the interfaces in the above table, because inconsistency in something basic like this is not good. So if we decide to make search fields that have keyboard focus by default not visibly focused until clicked on or text is typed, then we should do it everywhere to maintain consistency. This is another reason why I prefer the shows-focus-when-it-has-focus approach, because deviating from this consistently requires custom code in every client. I feel like we are not really objecting to this concept behaviorally, but rather to the visual consequences of implementing it consistently.

Thoughts?

However, regardless of what we choose, I would like to move towards unifying the interfaces in the above table, because inconsistency in something basic like this is not good. So if we decide to make search fields that have keyboard focus by default not visibly focused until clicked on or text is typed, then we should do it everywhere to maintain consistency. This is another reason why I prefer the shows-focus-when-it-has-focus approach, because deviating from this consistently requires custom code in every client. I feel like we are not really objecting to this concept behaviorally, but rather to the visual consequences of implementing it consistently.

Thoughts?

I agree that our HIG needs to explain focus better. It doesn't really have to be a long HIG about it. It could just be a general rule about the way that fields get their focus. In my mind, adding a visual element that denotes focus is a bit unnecessary, unless you navigate your UI using TAB or this is actually a user with an explicit need to see where the focus is.

My general opinion is that KDE has wanted every nook and cranny to have importance and we reflect that in the UI. Like the Kirigami HIG says, developers need to find the most important controls about their app UI and give those a certain priority. I think we could apply that here and remove the blue circle from the search fields and only make it show when the user is navigating using tab or because of some accessibility feature. I don't think that just because it is present in many areas, that it means it's the better approach. However, I remain open to the general consensus.

I agree that our HIG needs to explain focus better. It doesn't really have to be a long HIG about it. It could just be a general rule about the way that fields get their focus. In my mind, adding a visual element that denotes focus is a bit unnecessary, unless you navigate your UI using TAB or this is actually a user with an explicit need to see where the focus is.

My general opinion is that KDE has wanted every nook and cranny to have importance and we reflect that in the UI. Like the Kirigami HIG says, developers need to find the most important controls about their app UI and give those a certain priority. I think we could apply that here and remove the blue circle from the search fields and only make it show when the user is navigating using tab or because of some accessibility feature. I don't think that just because it is present in many areas, that it means it's the better approach. However, I remain open to the general consensus.

I think we'd need to be careful playing with this. In some cases, I would agree with you that a focus ring is unnecessary--for example around the main content view in Dolphin or Kate: it's obvious where focus is because of the underlined/selected files, or the blinking cursor (respectively). But for small text fields, I think it probably adds value. The important thing is that the user feels confident regarding what will be affected when they use their keyboard. That's why visible focus indicators exist. Our focus indicator is already pretty subtle compared to other platforms. We change a one-pixel monochrome line to a one-pixel colored line. On macOS, for example, there's a huge blue glow.

Also note that if we want to change the focus indicator in Breeze, then we should land this patch as-is and not tweak the focus behavior here or else we may not automatically inherit whatever changes we make globally.

I agree that our HIG needs to explain focus better. It doesn't really have to be a long HIG about it. It could just be a general rule about the way that fields get their focus. In my mind, adding a visual element that denotes focus is a bit unnecessary, unless you navigate your UI using TAB or this is actually a user with an explicit need to see where the focus is.

My general opinion is that KDE has wanted every nook and cranny to have importance and we reflect that in the UI. Like the Kirigami HIG says, developers need to find the most important controls about their app UI and give those a certain priority. I think we could apply that here and remove the blue circle from the search fields and only make it show when the user is navigating using tab or because of some accessibility feature. I don't think that just because it is present in many areas, that it means it's the better approach. However, I remain open to the general consensus.

I think we'd need to be careful playing with this. In some cases, I would agree with you that a focus ring is unnecessary--for example around the main content view in Dolphin or Kate: it's obvious where focus is because of the underlined/selected files, or the blinking cursor (respectively). But for small text fields, I think it probably adds value. The important thing is that the user feels confident regarding what will be affected when they use their keyboard. That's why visible focus indicators exist. Our focus indicator is already pretty subtle compared to other platforms. We change a one-pixel monochrome line to a one-pixel colored line. On macOS, for example, there's a huge blue glow.

Also note that if we want to change the focus indicator in Breeze, then we should land this patch as-is and not tweak the focus behavior here or else we may not automatically inherit whatever changes we make globally.

Interesting. I can change my opinion here. Should we then make sure that all the examples shown in the table behave the same?

Interesting. I can change my opinion here. Should we then make sure that all the examples shown in the table behave the same?

They all do behave the same, they just don't look the same:

  1. Most make the search field always look like a search field, but Kickoff doesn't (which this patch fixes)
  2. Most show the search field when typing will initiate a search, but Widget Explorer doesn't (the search field only appears once you start typing)
  3. Of the ones that have a visible search field by default, half of them (Kicker, System Settings) give the search field a focus ring by default, while the other two (Klipper and Discover) don't.

It seems like we have agreement on fixing #1, which is what this patch does. We haven't discussed #2, and don't need to for the purposes of this patch. We can do that elsewhere. Regarding #3, my preference is to have them all consistently show a visible focus ring if they have keyboard focus. I think we might be able to alleviate possible aesthetic concerns of doing this in Kickoff by adding a few more subtle separator lines. I'd prefer to do that in a separate patch though, for atomicity's sake.

Submitted a patch to make Widget Explorer consistent and always show the search field: D15101. If that patch and this one both land, then the columns two and three in the table above will be entirely full of "Yes" values!

To wrap up, I think this patch is ready for review again, and we'll tackle the separator lines in another patch for atomicity's sake. Does that sound good to everyone?

What's up with the third column "Search field visibly focused by default"?

My personal opinion is it should not have the blue outline just because it looks too strong. But consistency trumps looks. At the moment it's not though from what I read out of the table.

Note that I just landed the Widget Explorer patch, so I'll update the table accordingly.

What's up with the third column "Search field visibly focused by default"?

That means whether or not it has the blue focus ring when it has keyboard focus, but before you're typed anything. In other words, whether or not it shows the fact that is has focus.

My personal opinion is it should not have the blue outline just because it looks too strong. But consistency trumps looks. At the moment it's not though from what I read out of the table.

I tend to agree regarding the appearance of the focus ring, but this is actually a good argument for making everything consistent and using the default behavior, because then we can change the visual appearance of the focus ring in one place rather than in 10.

Aside from that, the outer glow should maybe be reconsidered on the whole. I don't see much of that visual element these days; it was trendy about 10 years ago and really feels like a bit of Oxygen in Breeze. I think just having a colored border when focused would suffice.

I'm working on patches to reduce the visual weight of the focus ring and add some horizontal separators to Kickoff. Those will be submitted as separate patches. Where are we with this one? Are people okay with it in conjunction with the aforementioned visual tweaks? I really don't want to go the route of tweaking the search field only here in Kickoff; I'd much prefer making everything consistent and then changing the visual style of the control itself, so everything is consistent.

Are folks okay with that?

To add more to the analysis, since Kickoff is a plasmoid, what seemed like a good idea to me was to have a look at how other plasmoids are designed (especially with relevance to the elements touched on in this proposal).

The Clipboard plasmoid stood out to me because as another unibody plasmoid, it seems to me like it handles the search box gracefully. I created some pics, this time with Breeze Dark to switch it up a bit:

Behavior: (1) non-selected it doesn't have an outer glow or a colored stroke; (2) when hovered over the stroke inherits the selection color; (3) only when clicked on or typed it does it turn on outer glow and the text selection line blings

Copied into Kickoff it doesn't look too bad (left pic). Since Kickoff is and can be more transparent, if possible what would help blend it in more is to lower the opacity by maybe 15-20% (right pic):

Now as for adding differentation in Kickoff, my observations were:

  • Kickoff isn't actually unibody -> if we look closely, Breeze Dark reveals that it actually places tabs into squares + other tabs such as the Application one already have separators
  • Other plasmoids do make use of separators, adding them would not create a design inconsistency on the whole
  • Although not as common, some plasmoids do also shade certain sections differently (e.g. plasma-pa), so at least what can be concluded is that shading a part of Kickoff differently also wouldn't be unprecedented

I really like this look.

rooty added a comment.Sep 1 2018, 1:16 AM

I'm working on patches to reduce the visual weight of the focus ring and add some horizontal separators to Kickoff. Those will be submitted as separate patches. Where are we with this one? Are people okay with it in conjunction with the aforementioned visual tweaks? I really don't want to go the route of tweaking the search field only here in Kickoff; I'd much prefer making everything consistent and then changing the visual style of the control itself, so everything is consistent.

Are folks okay with that?

+1

ngraham edited the summary of this revision. (Show Details)Sep 5 2018, 8:56 PM

It looks like we've generally achieved consensus on the visual changes. Could folks review D15194 and D15206? As for the focus ring, I could use a hand with this. I tried editing the SVG to reduce the size of the active focus ring by removing the outer lighter line that increases its size, but the changed SVG was just sized back up to the original dimensions and looked even stronger. Am I missing something?

ngraham edited the summary of this revision. (Show Details)Sep 13 2018, 5:56 PM

@davidedmundson Ping! This just missed the 5.14 window.

@davidedmundson ping again. I believe we've resolved the outstanding visual issues and I have addressed all of the technical issues you found, so I will land this for Plasma 5.15 on September 31st if I don't hear any new objections before them.

cfeck added a subscriber: cfeck.Sep 27 2018, 2:28 AM

David is on holidays, so maybe someone else could approve if this is urgent.

David is on holidays, so maybe someone else could approve if this is urgent.

Ah, whoops, didn't know that. No, it's not urgent. I can wait until he returns, then.

davidedmundson resigned from this revision.Oct 3 2018, 7:53 PM
This revision is now accepted and ready to land.Oct 3 2018, 7:53 PM
ngraham closed this revision.Oct 3 2018, 9:51 PM
urohan added a subscriber: urohan.Oct 13 2018, 7:20 AM

Awesome, thanks for introducing that additional information, @filipf. It seems like we have some inconsistency here in our Plasma search fields; I will summarize:

InterfaceSearch field has keyboard focus by default?Search field visible by default?Search field visibly focused by default?When does it become visibly focused?After gaining keyboard focus, when does it lose it?
DiscoverYesYesNoAfter typing or clicking on itWhen you click on anything else
KlipperYesYesNoAfter typing or clicking on itNever
Widget ExplorerYesYesYesN/A; starts out focusedAfter using the key to move focus to the list
KickoffYesNoN/A; not visible by defaultAfter typing or clicking on itNever
System SettingsYesYesYesN/A; always focusedAfter navigating to a KCM
KickerYesYesYesN/A; starts out focusedAfter you start to navigate the list

It seems like for the most part the interfaces that make the search field invisible or have a different appearance by default are in the minority and are being inconsistent with everyone else. So I'm glad that we generally have consensus that fixing that for Kickoff here is a good idea. I may do the same for the Widget Explorer too; then we'll have 100% consistent visible-by-default search fields!

After performing this investigation and all the accompanying behavioral tests, I realize now that there's a very good reason to keep keyboard focus on the search field even after the list of search results is being navigated with the up and down arrow keys: it's so you can edit your search query even after navigating the list. The only reason why Kickoff doesn't do this is because it has multiple lists that can be navigated between with the left and right arrow keys. Kickoff doesn't do that, so I think we have to keep that with this patch.

So onto the next subject: whether or not to have the search field visibly focused by default, or instead to only show the focus when you click on it or start typing. All of the clients throughout Plasma give the search field keyboard focus by default, even if the visual appearance doesn't reflect this, but we are very inconsistent with the visual appearance: System Settings and Kickoff have it visible and focused by default; klipper and Discover have it visible but not visibly focused until you click or type; Kickoff and the Widget explorer have it invisible until you click or type.

I'll admit that I have a preference for giving the search field visible focus when it actually has keyboard focus. From that perspective, this patch implements that preference, though I'm willing to continue the conversation to achieve consensus, because right now the HIG doesn't say anything about this subject, and it should. In fact it does not address the use case of using LineEdit controls as search fields, or even anything about focus behavior at all.

However, regardless of what we choose, I would like to move towards unifying the interfaces in the above table, because inconsistency in something basic like this is not good. So if we decide to make search fields that have keyboard focus by default not visibly focused until clicked on or text is typed, then we should do it everywhere to maintain consistency. This is another reason why I prefer the shows-focus-when-it-has-focus approach, because deviating from this consistently requires custom code in every client. I feel like we are not really objecting to this concept behaviorally, but rather to the visual consequences of implementing it consistently.

Thoughts?

You forgot Plasma Activity Manager search field.

P.S. It is strange when Plasma Widgets has a different version of the same element.

Ah, I didn't even know that the Activity Switcher had a search field. I suspect that @sharvey, the fellow who did most of the work to improve the Widget Explorer's search field, didn't know either.

I agree that it's not ideal for these to be different. We should make the Activity Switcher's search field be like the one in Widget Explorer. @sharvey, since you have some familiarity with that code now, would you be interested in making basically the same change there too?

I can take a look at it. I didn't do anything regarding its visual appearance, just made it appear and disappear at will - by hiding or showing the row it was placed on.

Yeah, and I extended that to simply make it always visible (if it exists; apparently it only does when there's more than one Activity). That's what we want here too.

</me looks up Activities since he doesn't use them>

Let's see what we can do...

I'll make the Activities change a separate diff, since this one's the most epic I've personally encountered.

Ah, I didn't even know that the Activity Switcher had a search field. I suspect that @sharvey, the fellow who did most of the work to improve the Widget Explorer's search field, didn't know either.

I agree that it's not ideal for these to be different. We should make the Activity Switcher's search field be like the one in Widget Explorer. @sharvey, since you have some familiarity with that code now, would you be interested in making basically the same change there too?

It's funny... Frankly speaking, I prefer the way search field implemented in Plasma Activity Manager. It's pretty graceful. More so, search field is needed only on demand (like search in Dolphin file manager or search in the Start Menu of Windows 10).

Anyway, I am not yet a contributor so my words are weightless.

Anyway, I am not yet a contributor so my words are weightless.

Not true! We listen to everyone's input. Unfortunately, it seems you're a little late to this party and the changes are rolling forward...

Anyway, I am not yet a contributor so my words are weightless.

Not true! We listen to everyone's input. Unfortunately, it seems you're a little late to this party and the changes are rolling forward...

:D Seems to be... I did not catch the last train.

ivan added a subscriber: ivan.Oct 13 2018, 5:35 PM

Different search bars are on different levels of usefulness.

Use-cases for searching activities are much rarer than, for example, searching widgets. The current activity switcher UI clearly shows the search button, so there's no problem with discoverability. While the switcher also provides a clickless-UI for people who like to keyboard-navigate.

Ah, I didn't even know that the Activity Switcher had a search field. I suspect that @sharvey, the fellow who did most of the work to improve the Widget Explorer's search field, didn't know either.

I agree that it's not ideal for these to be different. We should make the Activity Switcher's search field be like the one in Widget Explorer. @sharvey, since you have some familiarity with that code now, would you be interested in making basically the same change there too?

It's funny... Frankly speaking, I prefer the way search field implemented in Plasma Activity Manager. It's pretty graceful. More so, search field is needed only on demand (like search in Dolphin file manager or search in the Start Menu of Windows 10).

Anyway, I am not yet a contributor so my words are weightless.

Well people have been complaining that it's not obvious that there is a search field and you kind of also want to be consistent thoughout Plasma. You can't always please everyone though. I plan on releasing a fork of Kickoff without this patch to the KDE Store for the people who either just prefer the philosophy behind the old way or who will suffer a visual regression due to having very transparent or funky desktop themes. So no worries, the beauty of Plasma is that it doesn't lock you into one solution.

urohan added a comment.EditedOct 13 2018, 6:05 PM

Ah, I didn't even know that the Activity Switcher had a search field. I suspect that @sharvey, the fellow who did most of the work to improve the Widget Explorer's search field, didn't know either.

I agree that it's not ideal for these to be different. We should make the Activity Switcher's search field be like the one in Widget Explorer. @sharvey, since you have some familiarity with that code now, would you be interested in making basically the same change there too?

It's funny... Frankly speaking, I prefer the way search field implemented in Plasma Activity Manager. It's pretty graceful. More so, search field is needed only on demand (like search in Dolphin file manager or search in the Start Menu of Windows 10).

Anyway, I am not yet a contributor so my words are weightless.

Well people have been complaining that it's not obvious that there is a search field and you kind of also want to be consistent thoughout Plasma. You can't always please everyone though. I plan on releasing a fork of Kickoff without this patch to the KDE Store for the people who either just prefer the philosophy behind the old way or who will suffer a visual regression due to having very transparent or funky desktop themes. So no worries, the beauty of Plasma is that it doesn't lock you into one solution.

There is no problem here. I just realise my sphere of competence.