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

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-05-23 8:25:16
Message-ID: BAY7-F34KtzsSWLeSLx000342bf () hotmail ! com
[Download RAW message or body]

>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.

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'm still fiddling with that a lot, trying to find a way to display it 
properly.

> > 3) A pane for the Navigation Panel in Konqueror (or the universal 
>sidebar)
> > which can access those same plugins, but with more options displayed 
>than
> > the applet.
>
>Really needed!
>
>
> > 4) A large program which ties together access to all these plugins. Have
> > the interface in the style of Kontact and have a large option set for 
>each
> > search tool there. This was somewhat inspired by Sherlock on OS-X, 
>although
> > I've only seen two screenshots of that, so I can't say it was very 
>strongly
> > inspired by it.
>
>I tried Sherlock on a friends computer and loved it. Really great idea.
>
>
> > 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.

> > Some of this (particularly a file dialog redesign) would be a very large
> > change and probably not appropriate until KDE4.
>
>sure.
>
>Maybe the sidebar and the sherlock-like app could be added as a complement,
>but the "engine" must be available.
>
>
>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.

>= 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.

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.

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.

>= 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.

>	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.

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 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.

>	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.

>== 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.

>	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.

>	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.

>== 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.

>== Search Dialog ==
>	I don't like it.

Yeah, as I said at the end of that section, I don't either. I just have this 
urge to have something like that, but no matter how I lay it out, it's ugly 
and messy.

>== 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.

>
>=> 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.



Thanks for the well-thought-out reply.

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/

_______________________________________________
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]