[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Gustavo Sverzut Barbieri <gustavo () gsbarbieri ! sytes ! net>
Date:       2004-05-24 4:52:16
Message-ID: 200405240152.16309.gustavo () gsbarbieri ! sytes ! net
[Download RAW message or body]

Em Domingo 23 Maio 2004 05:25, Jamethiel Knorth escreveu:
> >From: Gustavo Sverzut Barbieri <gustavo@gsbarbieri.sytes.net>
> >Date: Sun, 23 May 2004 04:20:34 -0300
> >
> >Em Domingo 23 Maio 2004 01:56, Jamethiel Knorth escreveu:
> > > I was brainstorming about how to better work searching into the
> > > environment, and I had a few ideas. As is my way while brainstorming,
> > > my thoughts coalesced into a large variety of mock-ups and a webpage.
> > > I'm particularly hoping for people to give any comments about the file
> > > selection dialog before I ask about this on a development list.
> >
> >Great! We really need something in this area.
> >
> > > You can look at the full thing at:
> >
> >http://www.csis.gvsu.edu/~abreschm/designs/ubiquitous_searching/index.html
> >
> > > or a short and easy version (which may load slowly) at:
> >
> >http://www.csis.gvsu.edu/~abreschm/designs/ubiquitous_searching/short.html
> >
> > > or you can read a quick overview in this very email.
> > >
> > > 1) Change the quick-access bar in the file dialog to have searching,
> > > then the primary links, then recent locations, and then bookmarks for
> > > that program, making it much more powerful, only marginally harder to
> > > learn,  and  much easier to use (due to searching in the file dialog)
> > >
> > > 2) A search applet for kicker which can access a variety of plugins,
> > > such as local filesystem searching, internet searching, yellow-pages
> > > searching, ebay searching, and other such nonsense.
> >
> >Great. Although your 2 line is too bloated IMHO.
>
> It seems messy to me as well. However, how else does it distinguish between
> what is being searched for? If it only allows searching in one manner, it
> isn't very powerful. There is no way to distinguish, according to the
> search terms, between an internet search and a local search.

I have no solution either.

> It seems cramped when I look at it, but I am not seeing a better way.
> Having the icon pop-up a list of search protocols works to some extent, but
> is very slow, and the purpose of the applet is mostly speed.

I want something that pops up near to the icon, like the clock-calendar thing.
It's 1 click, is it that slow?
	And I mean having the search entry in the popup too. Do you understand? Maybe 
I can try a mock-up...


> I'm still fiddling with that a lot, trying to find a way to display it
> properly.

Good... send your ideas! :)

> > > 5) Search-as-you-type internal to the system menu, to help find items
> > > in what has recently become an abomination.
> >
> >I really DON'T like this one... we should fix the menu, not bloat it even
> >more :(
>
> If the bloat can be solved, even better, but I see no hope of it happening.
> I'm kinda iffy about this one, because it adds typing inside of the menu.
> However, it could be extremely powerful. I'd love to be able to test it.

Yeah, maybe test prove it to be useful. But as I said maybe it's something to 
be added to klauncher? klauncher is used to launch apps, right now it just 
complete names in $PATH, but maybe it can match k-menu metadata?


> >Now comments on your article:
> >
> >= Activity Icon =
> >	I like it, but I really like Apple's idea of display the status in the
> >search
> >entry (like Safari). It's representative and save space.
>
> Yes. Much better idea. I'll revise that soon.
>
> A thought on that: I remember finding the Safari display extremely
> distracting because it changes from white to bright blue, but then the blue
> disappears when the page is done, so it's jumping all over the spectrum.
> Would it still be distinctive enough if it changed color when the action
> started and then shifted back to the normal color? It would look nicer
> because there wouldn't be a big jump upon completion.

Great.
One more ideas: 
	- What about having the text (foreground) color to fade in and out "pulsing" 
while it performs the search. Maybe too eyecandy?
	- In your mock-ups you have a icon (kicker applet, kfiledialog) before the 
search terms... maybe that icon can be animated while searching? It's easier 
to do, not too eyecandy and don't take extra space.


> >= Plugins =
> >	I like the plugin idea, it make possible to extend the whole thing.
> >	However we must agree on a way to present information to the user, mainly
> >how to present the options to the user.
> >		- If we present too bloated interface, users will not understand and
> >avoid using it.
> >		- If we display too few options, users will not have power and maybe
> >avoid using it. Maybe not, but in that case a much powerful engine is
> >needed. 
> >This is a google case. Really clean interface, but powerful search 
engine...
> > but I don't know if it fits here since most of users don't know how to
> >search within a date range in google, many don't even know the '-'
> >operator. (I'm for this kind of power, but must be some visible options,
> >like check boxes, ...)
> >		- If we come with a ultra-new-cool-... interface it will be inconsistent
> >and hard to learn. I really think microsoft will come with something like
> >this in their longhorn so if we can achieve the goal of a regular and
> >standard way, users will like it more.
> >
> >	Ideas on this is really REALLY difficult. Looking at your mock-ups I
> > don't like some... the one I dislike most is the one with plugin options
> > showing up.  If we will go with this, we should agree on how to show/hide
> > available options and do some usability tests.
>
> Those are the problems that were bothering me as well. What I was thinking
> was that we should target simplicity. Require that every search plugin be
> able to handle a search from only a single line of information. Google is
> very good at interpreting what a single string is meant to be, with the way
> it can choose to do mathematical conversions, find an address on a map, or
> do an internet search, all from one line.
>
> So, every plugin MUST be able to function fully with one line of input,
> thus allowing them to be used from anywhere. The added options have to all
> have presets. That makes the search applet work, and it means a user
> doesn't need to give much input if they don't want to.

Sure.


> We need to have many more options available, or you cannot find something
> very specific out of a huge mass of information, which is one of the
> greatest values of searching.

Yeah. As I said above many users don't know how to explore the power of the 
engine, so some kind of interface to enable them to reach their goals is 
need.


> I'd say try to stick to the one-line search interface. The search system
> people are most adjusted to is Google. Let them stay adjusted to it.
>
> I think all of my mock-ups had reasonable defaults, so only one line of
> input was needed. For example, the search sidebar defaulted to searching in
> the current directory and finding files of any type, which is the standard
> search request.

I agree.


> >= Mock-Ups =
> >== File & Directory Dialogs ==
> >	First, just one comment, maybe not that related but here it goes: Isn't
> >the
> >file save/open operations done the wrong way? Maybe a implementation where
> >you can open files just draging or clicking and you don't need to save,
> >maybe
> >just revert. You often save, rarely you close without saving, so makes
> > more send to save always and revert when needed. "Optimize the common
> > case". Maybe
> >have this while the old method is available is fine, since it's in people
> >heads... but changing this behaviour is good IMHO.
>
> If it can be made to work, maybe. Until it is made to work, we're gonna
> need a good file selection dialog.

Unfortunately true :(


> >	I like the idea of smaller icons, but they must be implemented right and
> >slight larger than in 3.2.2. Right now they're too small and there's a
> >horizontal scrollbar (in my case), that really sucks.
>
> Last I looked, they went to the size of 22x22, which seemed to be as large
> as they could get without filling the space too quickly. It puts them a
> step larger than the entries in the file listing, and they are spaced
> slightly. The horizontal scrollbar is a large problem, clearly.

In 3.2.2 they are the same size the entries in file listing, the extra space 
isn't there too and the damn scollbar... although I remember a discussion 
about these issues when gnome people released some previews of their next 
file dialog and someone said these 3 issues were fixed... 
well, they aren't :(

> The main reason I wanted 22x22 for this idea was that it allowed quite a
> few items to fit in the sidebar, which is important for the idea to work
> properly.

I agree.


> >	I also like dynamic devices and the bookmarks, however just add the
> >bookmarks
> >icon to the 3.2.2 default is already good. (At least in my kde3.2.2 there
> >is
> >Desktop, Home, Devices and Network).
>
> I was kinda thinking of changing the bookmark option in the file dialog.
> Currently, it gives a fully-featured bookmark organizer, which is almost
> always overkill in that case. How about this:
>
> Make the bookmark button in the toolbar just a button (no menu). When it is
> clicked, it just adds that as a bookmark for that program. When an item is
> added into the core set of items in the quick-access bar, it is applied to
> all programs. Bookmarks only apply to one program.
>
> That makes having a lot of bookmarks less manageable, but it makes using
> bookmarks faster and easier. Right now, I get the impression they are often
> underused.

I like your idea.


> >	What I really dislike is the search field right there. Sorry, but I see
> > no point in having it there. One can filter the current directory with
> > the location entry. And there are problems on how to present results.
> > Return a tree view? What to do with the top entry which right now shows
> > the current dir?
>
> I was thinking the search option would search recursively from the current
> directory and just list the results, the same as a file search in
> Konqueror. Likely, during a search, the location bar would need to have its
> text changed to "search results" or something.
>
> It would be useful when you know the name of a file, but don't know what
> directory it's in. I do think the usage needs some better planning than
> I've given it. Even as I explain it, the usage seems a little awkward.

This need to be elaborated/discussed a little more.


> >== Sidebar Search Interface ==
> >	I really liked this one. I would like to suggest a better discussion and
> >testing of the UI, but the idea is great.
> >	I rather see icons along with text names in "Search:" combo box.
>
> Definitely. Totally forgot that in the mock-up.

:)

> >	A better visual separation of "Search: [ something |v]" and what to
> >search.
>
> I thought the horizontal line was fairly clear, as I also had it widely
> spaced out, but I am open to another suggestion.

Not sure, maybe different color? put it inside a frame?

> >	Make your lay out an advanced one and have a simpler one, with just one
> >field
> >which is intelligent enought to fill the 3 fields in yours. This is kind
> >easy:
> >		Search for: [ /media/trips Hawaii .jpg ]
> >		Search for: [ ~/Documents Taxes Paid .pdf ]
> >		Search for: [ ./some_dir doc*test .txt ]
>
> The problem here is that it adds a lot of complexity to one combo-box. How
> is the user supposed to know that they can enter all those types of
> information there? My goal was to make the extra options (location and
> file-type) with good defaults so they usually didn't need to be touched.
> Usually, you want to search the current directory. And, my idea for that
> combo-box was that it would have these entries:
>
> Current Directory
> Home
> System Root
> ---------------
> < recent locations >
>
> That way, the most common options are quickly accessible.
>
> Some with the file type defaulting to all, but giving a list. That list
> needs a little work, but I'm not sure how. Last time I was it, the list was
> friggin' huge.

Maybe put it as a editable combo box with the CWD, ~ and /.

But about the whole idea:
	I like the options too, good defaults really helps and in the sidebar there 
is plenty space for them all. However I would go for a one line entry by 
default and have a "More options >>" or something to show them. It's 1 click, 
but doesn't shock users.

	If we support queries as simple as I said it's intuitive, but maybe we can 
have "What's It" or some kind of help somewhere.

	Other way is the options to build the one-line search in real time... while 
user enter info in the specific entry boxes the one-line is filled... this 
way users can learn how to build their own. 
	The problem with this design is the one-line search entry size (horizontal) 
and how to handle when it's full... advance the cursor to match the current 
editing? Make it a textarea? 
	Other problem is the reverse action, type the one-line, click "More options" 
and the specific enties should be filled. Maybe it can call the search engine 
to have it parsed... 

	No real good idea, but I would go with one line search every where since 1) 
it's simple once learned, 2) some places (ie: kicker) have not much place, so 
have one line by default helps to be consistent.


> >	The order shouldn't matter. if no dir is found, use the current dir,
> > which can also be used as in shell ($HOME, ~, ./).
> >	Multiple terms maybe match in some order like this:
> >		- Both in same name as separated words
> >			- In same order
> >			- In other order
> >		- Both in same name, but inside words
> >			- Same order
> >			- different order
> >		- Just one of them
> >	As in Unix extensions is just part of the name, maybe the extension can
> > be handled as the above rule or a special one, at the top which puts
> > .SOMETHING
> >as the last argument, but then match as stated.
> >	Allow regexp to be used.
> >	Maybe handle some keywords: pdf, text, image, picture... These generally
> >are
> >not part of the name, so they can be used with a higher priority to match
> >the
> >file type.
> >	To complete my dream, maybe a date could match the {c,a}time and name :)
> >	Maybe this is hard to implement, but it will kick ass!
>
> It might be neat to have all that available, but I think it only has use to
> a power-user.

I don't got you. First you were pro simple, google-like searchs, then you say 
simple search will just be used by power users?
	Maybe you got me wrong. I was just suggesting matching order for queries. It 
was not something related to UI.


> >== Kicker Applet Search Tool ==
> >	I liked your vertical design and that made me think about the horizontal
> >one.
> >Maybe it's just me, but I don't like to waste space from my kicker.
> > However the applet is cool. But do I need to see the last term I searched
> > every time?
> >I don't think so, maybe we could have just one icon and when hovered or
> >clicked a micro panel pop up and then you enter the terms! This pop up
> >could
> >be exactly the applet you designed.
>
> That's a possibility, although it makes the search bar less present and
> adds a pop-up, which I like to avoid.

Yes, it's less present...
But the popup is something like the clock applet have, when you click it the 
calendar pops up. It's fast and simple.
	Maybe it can be an applet option, if you choose "small" it's just an icon and 
when you click it show the pop up with the same form that would be available 
in 2 line lay out. Otherwise it will behave like you proposed.


> >== Menu Searching ==
> >	I hate it :D
> >	It's not the right thing to do to the menu. I liked the meta data, but it
> >could be implemented in klauncher, don't you think?
> >
> >== Search Program ==
> >	I really like it, but how to present the options must be discussed so we
> >find
> >out something better. I don't like it using buttons to display the
> >sections... however tabs it's too scaring. Maybe the same widget used by
> >sidebar but a horizontal one?
>
> Actually, that is the same widget. I know, it's really non-obvious. I
> didn't add icons into the mockup, so you can't tell properly. Also, when
> horizontal, it's all spaced out for some reason. My mock-up is copied from
> a screenshot of that widget in Kate.
>
> I think that widget needs to have a partial redesign to look a bit more
> like tabs.

Sure.


> >=> Final Note
> >	Gnome's Dashboard (http://www.nat.org/dashboard/) may have some
> > technology we
> >want. It's too way more ambitious than our ideas and it's too intrusive
> >IMO,
> >but worth borrowing some techonolgy and avoid duplicate efforts.
>
> I'll look into it when I get a chance.

Please do, it's something really cool. Too ambitious I agree, but once they 
get it working we can copy basic ideas and have something better ;)

> Thanks for the well-thought-out reply.

You're welcome.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsbarbieri@jabber.org
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]