Reply to topic

Always place search on the top right side of the windows

-3

Votes
2
5
xpete
Registered Member
Posts
21
Karma
0
OS
I've found some inconsistencies on the way search is done over some KDE application as can be seen on these screen shots:

Dolphin

GetHotNewStuff

Kate

Okular

Telepathy


Some apps have the search on the bottom and others on the top.
Some apps have a "Find" button using some spaces that could be better used as a search input field.
The "extra" options are inconsistent.

I think some changes should be done and added to the KDE HIG:
Always places the search input field on the top right corner. On the toolbar if available;
Make the search field resizable;
Never user a search button on the toolbar;
The "extra" options are showed just bellow the toolbar when the search input is clicked;
Add a stop search button on dolphin. Without closing the options;

The result will be something like this:
Dolphin

GetHotNewStuff

Kate

Okular

Telepathy


A lot more stuff should be improved in Dolphin search and in other places.
Some examples:
Add more options to dolphin search;
Maybe place the search close button on the right side;
Remove the "Close" button on the GetHotNewStuff. Remember there's a button for that on the top right corner of the window;
Replace the "Next" and "Previews" button with just small left and right arrows;
The "System Settings Add-On Installer" bar looks like just a waste of space as it don't add any new information to the user. Remove it or change the text and icon.

Any other place where this should be changed?
Anybody else have better ideas?

UPDATE: New Dophin screenshot and mockup

Last edited by xpete on Sun Jun 23, 2013 4:36 pm, edited 1 time in total.
User avatar Gallaecio
Registered Member
Posts
82
Karma
0
OS
I think it is wrong to consider that both temporal search boxes and static search boxes are the same.

If you propose that static search boxes in the interface are always places in the same place, I agree.

If you propose that dynamic search boxes are handled similar, I agree.

However, you screenshots seem to lead to making dynamic search boxes (those that are not on the interface until you actually enable searches) are made static. And I disagree with that. It is eating up UI space unnecessarily.

Or, if you are suggesting that dynamic search boxes should pop up in the toolbar section, I completely disagree as well. I don’t think toolbars are right for temporal UI elements, and I think there is already some kind of consistency within KDE applications regarding showing those on the bottom of the editor/view. I think Kate guys have done a great job in this regard, and it’s their approach that should be followed for consistency, as their is already used in several applications and is what most KDE users must be used to.

Also, you must have into account that the search feature needs in some applications are quite different from the search feature needs in other. For example, while I would understand having an “Advanced Search” in KDE Telepathy that resembles (or better yet, is identical) to Kate’s Advanced Search, I think the simple search is better of being simpler that Kate’s simple search, as it is now.
xpete
Registered Member
Posts
21
Karma
0
OS
Gallaecio wrote:Or, if you are suggesting that dynamic search boxes should pop up in the toolbar section, I completely disagree as well.

I'am sugesting that the search boxes should always be there. Only the extra options popup when the user clicks the search box.

Gallaecio wrote: there is already some kind of consistency within KDE applications regarding showing those on the bottom of the editor/view. I think Kate guys have done a great job in this regard, and it’s their approach that should be followed for consistency, as their is already used in several applications and is what most KDE users must be used to.

When you are searching for something you expect the results to be shows bellow the search box... Placing the search on top is a no brainer and the obvious thing to do. I see no reason to place it anywhere else. This "consistency" you are talking about needs to be fixed. It makes no sense to have the search on the bottom... It's annoying and not intuitive.

Gallaecio wrote:Also, you must have into account that the search feature needs in some applications are quite different from the search feature needs in other. For example, while I would understand having an “Advanced Search” in KDE Telepathy that resembles (or better yet, is identical) to Kate’s Advanced Search, I think the simple search is better of being simpler that Kate’s simple search, as it is now.

I understand that and I'am not sugesting to add any “Advanced Search” in KDE Telepathy or adding any feature. But some details should be consistent... In Okular there a popup menu with some option that is not consistent with the other interfaces. In Kate there's "Match case" while on others is "Case sensitive"....same features should have same wording and be showed in the same way if possible.
User avatar Gallaecio
Registered Member
Posts
82
Karma
0
OS
Then I only agree about using a common wording.

I think having the search boxes always visible when users may not use them is a waste of UI space. For example, reading any book of A Song of Ice and Fire (or any non-technical book for that matter), you are unlikely to need the search function. It would also be a visual annoyance for those users, contributing to the feeling that the UI is bloated; in general, the lighter the UI the better, specially for new users.

And regarding the position of the search box, top vs bottom, I don’t see it as a no brainer. If you were asking to let the user move it to either place (which could be a solution here), I could agree, but I see not reason that could justify choosing either one over the other. Your argument is like saying that Plasma’s main panel’s task manager should be always on top, as users expect that the tasks they open do so below the task manager. You may, others may not, and I certainly don’t.
xpete
Registered Member
Posts
21
Karma
0
OS
Gallaecio wrote:I think having the search boxes always visible when users may not use them is a waste of UI space. For example, reading any book of A Song of Ice and Fire (or any non-technical book for that matter), you are unlikely to need the search function. It would also be a visual annoyance for those users, contributing to the feeling that the UI is bloated; in general, the lighter the UI the better, specially for new users.

You can say that about all the button on Okular toolbar... and most of them are not used as often as search.

Gallaecio wrote:And regarding the position of the search box, top vs bottom, I don’t see it as a no brainer. If you were asking to let the user move it to either place (which could be a solution here), I could agree, but I see not reason that could justify choosing either one over the other. Your argument is like saying that Plasma’s main panel’s task manager should be always on top, as users expect that the tasks they open do so below the task manager. You may, others may not, and I certainly don’t.


You can't compare this to the task manager in any way... but you can compare this to krunner, Google or any search engine. Do you think krunner results should be showed above the search box (or Google, etc)? I certainly don't.
User avatar Gallaecio
Registered Member
Posts
82
Karma
0
OS
xpete wrote:Do you think krunner results should be showed above the search box (or Google, etc)? I certainly don't.


My point is that I don’t think the search results should be displayed either way, I think any of them is fine, and if there has to be any change, it should be to allow both positions, not to enforce one. If I had my main panel (with the task manager, notification area and such) on the top of the screen, à la Mac, I would want to have KRunner appear in the bottom, and the results would be displayed on the top rather than on the bottom.
luebking
Registered Member
Posts
932
Karma
7
@xpete:
have you ever used kwrite or kate? (or quite some browsers, for that matter)

The reason why this is on the bottom area is that the search input searches the textedit above (and does not add some output), is pretty large (esp. when doing search and replace) and placing anything dynamically north or west is a COMPLETE UI SIN, as it will either cover the document anchor (where "cover" is to be avoided anyway - you want to see what you find) or necessarily shifts the content down/right (under your sight)

You're mixing up a search input field (where more consistency could be useful, yes) like the googlebar in the topright of some browsers with a document finder / filter tool here (stuff that used to be dialogs and is now predominantly on the lower edge of windows, also compare dolphins filter on pressing ctrl+i)
xpete
Registered Member
Posts
21
Karma
0
OS
luebking wrote:@xpete:
have you ever used kwrite or kate? (or quite some browsers, for that matter)

I use search (and replace) on Kate a LOT and it's really annoying. I use browsers since Netscape 4.0 and Opera 12.15 is my main browser... But I always try all browsers as I
do web development.
1st time I saw search on bottom was in Firefox.
Have you ever tried Opera 12.x(or Chrome)? Opera have a search just like Firefox but it's on top and works much better btw.

luebking wrote:The reason why this is on the bottom area is that the search input searches the textedit above (and does not add some output), is pretty large (esp. when doing search and replace) and placing anything dynamically north or west is a COMPLETE UI SIN, as it will either cover the document anchor (where "cover" is to be avoided anyway - you want to see what you find) or necessarily shifts the content down/right (under your sight)

You are saying it covers space on top but it's doesn't cover any space on bottom? If it covered any space it would be the same on bottom or on top...
But it doesn't cover anything anyway. It's not need to shift anything.

luebking wrote:You're mixing up a search input field (where more consistency could be useful, yes) like the googlebar in the topright of some browsers with a document finder / filter tool here (stuff that used to be dialogs and is now predominantly on the lower edge of windows, also compare dolphins filter on pressing ctrl+i)

I'am not mixing anything. Search and filtering is the same thing.
I didnt't knew about "dolphin filter" but on a user point of view it's just duplication of the search feature(but more limited) so it should be merged with the search box.
I only see this "predominantly" on Firefox, SublimeText and some KDE apps... and I don't see a reason to be this way.

Really try Opera before replying and Mac OS X if possible.
luebking
Registered Member
Posts
932
Karma
7
You are saying it covers space on top but it's doesn't cover any space on bottom? If it covered any space it would be the same on bottom or on top... But it doesn't cover anything anyway.


Please read more closely:
I did *not* say "cover space" but "cover content" and that covering content "is to be avoided anyway".

It's not need to shift anything.

Yes, it is.
The search & replace element is as large as three toolbars, the find bar in kwrite still covers a complete toolbar.
So either you waste that space permanently or you cover the content with it or you move the core content downwards when adding it as dynamic (tall) toolbar on the top - this is what recently some message bubbles do and it's *really* nasty.

I didnt't knew about "dolphin filter" but on a user point of view it's just duplication of the search feature(but more limited) so it should be merged with the search box.

Yes, filter the content of the current directory is pretty much the same as searching the filesystem. Sure ... m(
How would you suggest to merge that? Using keysterms?

As long as you're happy with a simple lineedit of limited length for a very basic search that's all fine, but the complex searchboxes of eg. texteditors simply don't fit that concept the least. Sorry if you fail to notice that.
xpete
Registered Member
Posts
21
Karma
0
OS
luebking wrote:Please read more closely:
I did *not* say "cover space" but "cover content" and that covering content "is to be avoided anyway".

I mean the same. Just moving what is on bottom to the top the content covered will be the same... and in mock up it covers less content.
I don't think cover is the right word anyway as it just moves the content up or down.

luebking wrote:The search & replace element is as large as three toolbars, the find bar in kwrite still covers a complete toolbar.
So either you waste that space permanently or you cover the content with it or you move the core content downwards when adding it as dynamic (tall) toolbar on the top - this is what recently some message bubbles do and it's *really* nasty.

My idea is to be dynamic. Right now it moves the content up... the message bubbles are a good idea too as a replacement to the popups... as they keep thee messages in context.

luebking wrote:Yes, filter the content of the current directory is pretty much the same as searching the filesystem. Sure ... m(
How would you suggest to merge that? Using keysterms?

"filter the content of the current directory" is the same as searching the "content of the current directory" by filename... and the search field already does that.
It's just a little slower.
Just add an checkbox to search the subfolders... and remove this "dolphin filter".

luebking wrote:As long as you're happy with a simple lineedit of limited length for a very basic search that's all fine, but the complex searchboxes of eg. texteditors simply don't fit that concept the least. Sorry if you fail to notice that.

The search box can be resizable so it should fix the problem of the "limited length"...
Anyway just moving what is on the bottom of Kate right now to the top will make it much better... and you can keep "complex searchboxes".
User avatar vayu
Registered Member
Posts
70
Karma
0
OS
I like the idea of a consistant interface. I also think that forcing an application designer to something regimented for every application takes away from their ability to tailor the flow for the dynamics of that particular application. The same search spot idea while having some merit also concerns me with regard to screen real estate. My experience with KDE in general is that most of the base apps have a wonderful combination of usability AND configurability. I find the usage of screen real estate is well done, much more so than any of the other DE's I'm familiar with. Everytime I get onto Win7, OS X, or Gtk themed desktops, I lament the amount of room taken up and how many more steps it takes me to my tasks. Please do not mess up my Dolphin or Kate, they are so well done for me.
luebking
Registered Member
Posts
932
Karma
7
I mean the same.

No, you don't.

I don't think cover is the right word anyway as it just moves the content up or down.

Because that is not the "alternative" i pointed to shifting content.
"Cover content" would be more like a dialog, overlaying the actual content.

Right now it moves the content up...

No, it does not. It shrinks the area, but the content anchor (the nortwest corner in left-to-right and northeast corner in right-to-left cultures) remains where it is and that is the important aspect.

"filter the content of the current directory" is the same as searching the "content of the current directory" by filename...

No.

Just add an checkbox to search the subfolders... and remove this "dolphin filter".

First off: searching is not like searching the subfolders. It searches the entire filesystem, starting at a specific node instead of / if you want.
Second: did you notice that the filterbar is some slim toolbar on the bottom while the find toolbar covers nearly your entire screenshot and you want to add even one more checkbox...

The search box can be resizable so it should fix the problem of the "limited length"...

No, because you want to stuff it into the right edge of a toolbar crowded with other icons.

Anyway just moving what is on the bottom of Kate right now to the top will make it much better...

On the contrary - you'll make it shift the content of a texteditor (every line) downward on calling it, ie. the line you're right now looking at moves away and you can follow it whenever you toggle the searchbar.
xpete
Registered Member
Posts
21
Karma
0
OS
No, it does not. It shrinks the area, but the content anchor (the nortwest corner in left-to-right and northeast corner in right-to-left cultures) remains where it is and that is the important aspect.

Ok... true... but it covers content on the bottom... whatever it's on the bottom top it always have to cover or move the content... so there's no big diference.
You don't loose the positional references... and it doesn't go down that much so it's not a problem..

No..

In the user point of view(that's what matters) it's the same.
First off: searching is not like searching the subfolders. It searches the entire filesystem, starting at a specific node instead of / if you want.
Second: did you notice that the filterbar is some slim toolbar on the bottom while the find toolbar covers nearly your entire screenshot and you want to add even one more checkbox...

I don't like the amount of space wasted by the find toolbar.... but my post wasn't about that... anyway i replaced my mockup with one the way i think it should be... or something like that. The checkbox could be placed between the "Everywhere" and the arrow in the previews mockup.

No, because you want to stuff it into the right edge of a toolbar crowded with other icons.

I understand your point but still I think it should be placed there.

On the contrary - you'll make it shift the content of a texteditor (every line) downward on calling it, ie. the line you're right now looking at moves away and you can follow it whenever you toggle the searchbar.

Like i said above You don't loose the positional references... and it doesn't go down that much so it's not a problem.
Have you tried the TextEditor on MacOS X?
luebking
Registered Member
Posts
932
Karma
7
One last try:
-------------
a) Covering content is *always* wrong and never an option. No matter whether on top or bottom. I only mentioned it to explain why contents must not be added on top (since they shift content unless the cover it - what is even worse behavior)
b) whenever something suddenly appears on top, everything below moves downward by at least one line - and even one pixel would be wrong.
"Not that much" is still "Too much". Ppl. using this will usually *not* use their mouse but a shortcut - their focus is still on the text, i usually don't even look at the searchline.
c) IDE searches and search & replace tools simply require space, because they're made for users who actually work on the box and are not just too lazy to scan a paragraph or a word.
d) Apples TextEdit shifts the content by 1½-3 (for search and replace) rows downwards, the search covers the entire width of the window. (Not "right side of the window")
And it is some sort of wordpad for a causal users, usually writing a letter. XCode has the same behavior - and it sucks big time.
Apple also has Drawers and Sheets - that doesn't make them anything sane.
e) It is absolutely not necessary to have those dynamic search facilities at the same location as the static ones.
As long as "dynamic search field: entire bottom, static search box: top right" is kept, it's still consistent.

 
Reply to topic

Bookmarks



Who is online

Registered users: AElfwine, alake, anditosan, Artmessiah, Baidu [Spider], Bing [Bot], edmael, Exabot [Bot], garthecho, geaplanet, Google [Bot], google01103, Horus, inksi, Joif, ken300, La Ninje, lazyit, pedrorodriguez, pvonz, thalesgava, tienhung, VP1986, Yahoo [Bot]