Re: Searching for applications



On Mon, Dec 13, 2010 at 1:52 AM, Milan Bouchet-Valat <nalimilan club fr> wrote:
> What "high maintenance"? With a Keywords field, each app should just list
> the main words that come to mind when looking for it, there aren't hundreds
> of them: photo, photos, camera, cameras, possibly manager, album, gallery.

I think the high maintenance part is that “camera” and “webcam” are
different, when they should be synonymous (with an overlap between
categories) if we want consistent search results. I'm afraid of
expecting every localization team to worry about globally consistent
keywords for each application on an individual basis, and I'm worried
about making application developers repeat themselves more than they
already do.
(Granted, the source language is the one that has too many synonymous words).

> As s translators, we do more painful things than correctly translating
> this kind of list and check there are no language specifics to add. A
> translator comment explaining this is enough.

I am glad you're here! Having the translation perspective is very
helpful, because I can only really guess at it myself :)

> Sure, stemming would make the list less ridiculous, but one would have
> to find an algorithm that works for all languages and doesn't take too
> much processing power (e.g. doesn't walk over the full dictionary).
> Porter's could be a good candidate as it's available as free software in
> Snowball[1]. But is it worth the result?

Thanks for pointing out Snowball.
Come to think of it, all the new application search things do instant
search, so stemming shouldn't be a major issue in English at least
(and probably most others, if my limited language knowledge is
accurate…). Once good results appear, it's probably safe to assume
people will stop typing rather than continuing to add suffixes to
their words.

> Showing a category would be confusing: for now, we only show individual
> apps. We could show the list of apps that are in a category that matches
> the keyword, but apps can as well add "photography" as a keyword: that's
> more flexible and hasn't real drawbacks.

I'm thinking categories would map to keywords. So, developers just
list some categories, which they have already done for the most part
(with some bugs here and there). Things usually have multiple
categories (like “GNOME;Development;Debugger;” and
“GNOME;GTK;Graphics;Scanning;”), and just a few of those are directly
exposed to the user. The full list of known categories is in the
FD.org desktop menu specification [1].
All the user sees is that searching for “camera” gives Shotwell,
though there may be a case for showing the list of keywords (with
matches underlined), too.

I do agree there is still a strong case for application-specific
keywords. For example, the categories don't cover everything (Notes,
Todo and Tasks, spring to mind). Empathy might want a list of common
protocols it (hopefully) supports and a game might want an abbreviated
version of its name. That kind of thing probably _should_ be solved by
an open-ended Keyword field. However, I think for the bulk of this
stuff it would be good to start with what we have already in order to
make the transition to search seamless :)


Dylan


[1] http://standards.freedesktop.org/menu-spec/latest/apa.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]