Use correct search bars and use ellipsis whenever needed to follow the KDE HIG
Open, LowPublic

Description

Right now a lot of search field labels throughout KDE software don't follow the KDE HIG and are not consistent with one another.

The labels should use ellipses, meaning that the proper placeholder text is "Search...", not "Search" or even "Search ...".

filipf created this task.Jan 3 2019, 12:48 AM
filipf triaged this task as Low priority.
GB_2 renamed this task from Make search field labels consistent and in line with the HiG to Make search field labels consistent and in line with the HIG.Jan 3 2019, 12:50 AM
GB_2 updated the task description. (Show Details)
GB_2 added a subscriber: GB_2.

Cool!

BTW always make sure to add the groups as subscribers, not just tags. For some reason (maybe a Phab bug?) if you just assign a tag, the group doesn't get notified.

abetts added a subscriber: abetts.Jan 3 2019, 3:46 PM

I support visual alignment!

GB_2 renamed this task from Make search field labels consistent and in line with the HIG to Use correct search bars and use ellipsis whenever needed to follow the KDE HIG.Jan 5 2019, 1:49 PM
GB_2 updated the task description. (Show Details)
ngraham moved this task from To Do to Done on the Plasma board.Jan 11 2019, 5:00 PM
ngraham moved this task from Backlog/Planned to Done on the VDG board.
ngraham moved this task from Done to Work in Progress on the Plasma board.Jan 11 2019, 5:06 PM
ngraham moved this task from Done to Sent to dev on the VDG board.

Coming from D19771. For me is that HIG also confusing...

Since the placeholder won’t be visible anymore as soon as the user types, you should only use it on standalone input elements, not in groups of input elements such as forms.

...but the example above looks opposite to this. Beside make that advice no sense to me.

Use an ellipsis (…) after the text.

There is no explicit mention that this has not to be three dots or even no special char but three dots for some reason.

The labels should use ellipses, meaning that the proper placeholder text is "Search...", not "Search" or even "Search ...".

Is written here on top but is missing there.

There is no mention what is to use "Find" or "Search". In German is it often translated the same, but in English it looks differently.

For my taste would it make sense to set "Pattern" in a search field as placeholder. Perhaps "Regex Pattern" if supported or even "Plaintext Pattern" when not.

The shown example should be Improved, "Max Mustermann" will unlikely have a mail address "john.doe@example.com", but I guess that is related to some unfinished translation.

aacid added a subscriber: aacid.Mar 17 2019, 10:46 PM

Hey, i was sent here from https://phabricator.kde.org/D19773#433272

I have some questions:

  • This task says "labels throughout Plasma" but then I'm seeing patches to Cantor, Okular and other non Plasma software. Is this on purpose?
  • People implementing this task is removing labels for search fields saying that https://hig.kde.org/style/writing/placeholder.html says they have to be removed when there's only one label/text field. Maybe this has been discussed somewhere else, but that's not what i understand from reading that guideline, what i understand is that it says is "don't remove the label when there's more than two fields" which is not "remove the label when there's only one field"
  • Finally, if the guideline really wants to say "remove the label when there's only one field" (let's rewrite it to be more obvious if that's what it means). Are you aware that we're losing the Alt+Key focusing on the text input provided by Label->text buddy functionality? I think it's really bad that we're regressing on this accessibility feature.

Hey, i was sent here from https://phabricator.kde.org/D19773#433272

I have some questions:

  • This task says "labels throughout Plasma" but then I'm seeing patches to Cantor, Okular and other non Plasma software. Is this on purpose?

Looks like someone changed the task title to be more appropriate since you asked this question. I think the intention was always to make them consistent throughout KDE Software.

  • People implementing this task is removing labels for search fields saying that https://hig.kde.org/style/writing/placeholder.html says they have to be removed when there's only one label/text field. Maybe this has been discussed somewhere else, but that's not what i understand from reading that guideline, what i understand is that it says is "don't remove the label when there's more than two fields" which is not "remove the label when there's only one field"

You're right, it sounds like we may need to clarify that a bit. However in general not everything needs to be 100% ironclad and spelled out in blood in the HIG. :) Visual consistency between identical UI elements is its own justification apart from whether or not the HIG formally recommends or requires it.

  • Finally, if the guideline really wants to say "remove the label when there's only one field" (let's rewrite it to be more obvious if that's what it means). Are you aware that we're losing the Alt+Key focusing on the text input provided by Label->text buddy functionality? I think it's really bad that we're regressing on this accessibility feature.

I wasn't aware of this, and perhaps others weren't either. I agree that we shouldn't lose this for the small numbers of text fields that had a buddy set (it really was a small minority). What would make sense to me is to figure out a way for one of the letters in the placeholder text to have an alt-key accelerator that allows you to focus it just like the buddy label did. That way we get consistent visual styling everywhere and we keep this desirable accessibility feature--in fact we actually add it, since the vast majority of search fields did not previously did not have a buddy label before we started this task.

Hey, i was sent here from https://phabricator.kde.org/D19773#433272

I have some questions:

  • This task says "labels throughout Plasma" but then I'm seeing patches to Cantor, Okular and other non Plasma software. Is this on purpose?

Looks like someone changed the task title to be more appropriate since you asked this question. I think the intention was always to make them consistent throughout KDE Software.

It still says Plasma, it's right there on the description

  • People implementing this task is removing labels for search fields saying that https://hig.kde.org/style/writing/placeholder.html says they have to be removed when there's only one label/text field. Maybe this has been discussed somewhere else, but that's not what i understand from reading that guideline, what i understand is that it says is "don't remove the label when there's more than two fields" which is not "remove the label when there's only one field"

You're right, it sounds like we may need to clarify that a bit. However in general not everything needs to be 100% ironclad and spelled out in blood in the HIG. :) Visual consistency between identical UI elements is its own justification apart from whether or not the HIG formally recommends or requires it.

Sure, visual consistency is good. But the thing here is that i first was told that "yes it is a HIG decision to not have labels if there's only one line edit", now that doesn't seem to be "true" anymore and is now "this change is done out of visual consistency". But you know what? It was all visually consistent before this change started happening, apps were all using labels and lineedits.

Anyhow if you want to have true consistency what you need to do is provide a common component people can just reuse. We used to have that back in the day of with https://api.kde.org/frameworks/ktextwidgets/html/classKFindDialog.html but then dialogs became evil and we lost consistency because everyone and their cousin started implementing their own search bars.

  • Finally, if the guideline really wants to say "remove the label when there's only one field" (let's rewrite it to be more obvious if that's what it means). Are you aware that we're losing the Alt+Key focusing on the text input provided by Label->text buddy functionality? I think it's really bad that we're regressing on this accessibility feature.

I wasn't aware of this, and perhaps others weren't either.

My guess is because the person that wrote those guidelines was focused in QtQuick and the buddy feature doesn't seem to be available there (AFAIK).

I agree that we shouldn't lose this for the small numbers of text fields that had a buddy set (it really was a small minority). What would make sense to me is to figure out a way for one of the letters in the placeholder text to have an alt-key accelerator that allows you to focus it just like the buddy label did. That way we get consistent visual styling everywhere and we keep this desirable accessibility feature--in fact we actually add it, since the vast majority of search fields did not previously did not have a buddy label before we started this task.

Users wouldn't be able to see the accelerator once they typed text, so personally i'm not sure how useful this is. But even assuming not being able to see the accelerator half of the times would be ok, i don't see this working unless you find someone with lots of time (and convincing power) to get this accepted into Qt, because otherwise i don't see a way to get this technically implemented, i guess maybe it could be done from the style side? But then we'd be losing a feature to everyone not using "our style" which is also not great.

ngraham updated the task description. (Show Details)Mar 18 2019, 11:44 PM

I'm interested in solving the problem you brought up. We do in fact have a common, re-usable component in the QML side with Carl's recently added component. Creating one on the QTWidgets side would be good too. I'm always in favor of high-level controls with semantic meaning, e.g. "this is a search field" rather than "this is a text field that we happen to be using as a search field by doing all this stuff so it over and over again". Then we can use the same control everywhere and control the behavior and appearance in just one place.

I'm interested in implementing this search field component with a focus sequence. But I have some questions before I start.

Some of the search bar are using QLineEdit and other KLineEdit (from KCompletion), so I suppose this component shoud inherit from KLineEdit. But in that KDE library should I then implement this component? KCompletion doesn't feel right.

I think the only method that shold be overwrited is ->setPlaceholderText(string), there the placeholder is now an mnemonic. It is a good idea?

How should the component be nammed? KLineEdit is already taken, maybe KFocusLineEdit or KPlaceholderLineEdit? ;)

Or we could create an complete Search/FilterBar component, with some setters:

setFocusSequence(QKeySequence *) // set shortcut sequence for the text field (default Ctrl+F)
setLineEdit(QLineEdit *) // so we can use a QLineEdit or a KLineEdit (default value is a QLineEdit)
addOption(QAction *) // if one option inline the option, if not create a menu (default no option)

and some signals:

nextResult()
previousResult()
aacid added a comment.EditedMar 20 2019, 9:25 PM

I don't feel this is the right place to discuss this, seems like the frameworks list (if we want input from framework developers) or the devel list (if we want input from app developers) would be better places.

Anyhow, what i had in mind is something that hides the implementation, it doesn't matter if it's a lineedit, or a lineedit and a label or a lineedit with a dancing cat, it's something that the app developers use and are expected to put on top/bottom of some widget area and it'll provide the searching UI that is fancy at that moment, so inheritint or even knowing about Q/KLineEdits would not be my recommended solution.

+1 for a more abstract, high-level "KSearchField" or whatever. I'm probably not smart enough to implement it so I may not be the right person to propose it (and proposing something is much easier with patch in hand), but you may be right that the mailing lists could be the proper venue when the time comes.

mglb added a subscriber: mglb.Mar 21 2019, 3:15 AM

Are you aware that we're losing the Alt+Key focusing on the text input provided by Label->text buddy functionality? I think it's really bad that we're regressing on this accessibility feature.

Do people use Alt+Key to focus search input field? Ctrl+F shows search panel (when hidden) AND focuses input field, even when the panel is already visible. Moreover, letter in Alt+Key is not consistent between apps, Ctrl+F (or Ctrl+Shift+F) mostly is.

aacid added a comment.Mar 21 2019, 6:35 PM
In T10258#179932, @mglb wrote:

Are you aware that we're losing the Alt+Key focusing on the text input provided by Label->text buddy functionality? I think it's really bad that we're regressing on this accessibility feature.

Do people use Alt+Key to focus search input field? Ctrl+F shows search panel (when hidden) AND focuses input field, even when the panel is already visible. Moreover, letter in Alt+Key is not consistent between apps, Ctrl+F (or Ctrl+Shift+F) mostly is.

With millions of users there, yes, i'm sure people use a feature we added.