Re: Simple Search interface

[Aaron Turner <aturner@linuxkb.org>]

On Tue, 14 Dec 1999, Jason Pincin wrote:

> I don't like this for two main reasons:
> 
> 1) It makes looking for an application 'almost' like searching for an
> answer.  Who knows how someone put the name of the application into
> the DB?  The substring matching could get pretty complex... but I

Difficult?  Why?  I mean how many ways are there of spelling "apache" or
"sendmail"?  One last I checked :)  Also the beauty of this system is that
I don't even have to know how to spell a specific app.  I can find pine
just by typing "email".  This is MUCH better than ordering things
alphabetically which gives you no indication of the apps purpose.

It does assume either SQL or PHP can do their sub-string matching case
insensitive (like perl).  And if we limit the query string to two words,
which is reasonable, it puts a reasonable load on the server and reduces
the complexity for the user (remember this is the simple form!). If we
can't do it in SQL, I'll admit that there will be a bigger CPU load for
the page, but I think it's worth it.  Remember, we can always get
bigger/faster/more hardware.

The point is we don't need to be complex with the search string matching.
Just take the word or two they provide and find all the apps/cats that
have that substring in them (case insensitive).  For each app that
matches, find it's parent cat.  Then for each category you have (via
direct match or parent) list all the apps below them.  There's no
substitution, fuzzy logic, etc needed.  Actually that would defeat the
purpose because advanced matching generally increases the number of hits
which is the opposite of this.

Also I'm pretty sure that to get down to 30 or so choices, people are
going to have to drill down a lot more than one level.  Just think of the
different types of applications on Freshmeat, then factor in all the man
pages.  No, people are going to have to drill down at least 3 - 5 levels
to get 30 apps listed.

> admit is DOABLE... I just feel it would be used less if people had to
> 'search' for there app, and THEN 'search' for there answer...

I think we already make people "search" for the app first, then search for
the answer with the drill down.  One major problem with the drill down
system is that we may not categorize something where Joe thinks it should
go.  Hence he drills down and does a search and comes back empty because
it's been excluded by the drill down.  Don't get me wrong, I think the
drill down is VERY powerful and VERY important.  But's its not the
end-all-be-all.

> 2) Another page load.  This is the biggest.  In order to build the
> list, it requires Another Page Load.

I bet that if you want to count page loads, that people are fewer pages
away from the answer on average than a pure drill down solution like you
suggest.

> I don't think this is THAT big of a deal.  I actually like Dan's
> suggestion of just making something like a 3 row select box so the
> user can easily scroll through the list... or type the first letter of
> the app to get to that section of the list and do only a short scroll.

I don't remember Dan's suggestion off the top of my head, but as I
understand you this isn't nearly as powerful as my suggestion.  It also
means that if I'm looking for a tool to fill a job rather (joe wants the
most secure MTA) than a specific application (postfix), I can't use the
simple interface becuase it doesn't take into account the Categories like
my solution does.  Also it sounds like it will require JavaScript or
DHTML.

> Also - remember... the list is only going to be really large on the
> first page.  As long as we make drill down easy... people aren't going
> to have to wade through it all the time.  If I even click on ONE sub
> category to drill down to before I start looking for the app, I've cut
> my choices by anywhere from 1/4 to 3/4... depending on how many top
> levels we have.  The Application list may be 600 on the top level, and
> a mere 30 ONE LEVEL down.

Freshmeat has 44 sub-categories under Console.  22 under daemon.  19
development, 10 Gnome, 12 KDE, 7 web, and 48 X.  Then there are then 2 to
200+ applications under each sub-category.  We will have many more Apps
than that.  I don't think for a minute that the simple drop down can scale
to that level.  Showing anything near 600 applications on the first page
in a drop down is completely pointless and will only fustrate the end user
who doesn't understand our categorization.  We might as well force them to
drill down a few levels before offering the Application dialog.

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net

> On Tue, Dec 14, 1999 at 02:05:09PM -0800, Aaron Turner wrote:
> > 
> > I've been thinking a lot of how to impliment the Applications dialog in
> > the simple search page.  I think everyone agrees that the current drop
> > down list doesn't even begin to scale as we add applications.
> > 
> > The main problem is most solutions require JavaScript, DHTML, or the like
> > which Lynx doesn't support.
> > 
> > So I talked to our master web developer here at Vicinity about it and did
> > some brainstorming.  Here's what we came up with:
> > 
> > Since each application is known in the SQL database, we can create a
> > dialog which allows them to either type in the Application name or type.
> > A name would be like apache, pine, netscape, etc.  Type would be like web
> > server, email client, web browser, etc.  We then do a substring match
> > against the KBObjects:ObjectName field.
> > 
> > We then return back to the user a dropdown list of the matches but also
> > the other applications in the same category.  Example:
> > 
> > Joe types "Apache".
> > 
> > We find Apache in the "Web Servers" category.  We then find the other
> > applications in the Web Servers cat, and return as a drop down:
> > 
> > Apache
> > Netscape
> > thttpd
> > Roxen
> > etc.
> > 
> > Joe could also type in 'email' and we would find the following categories:
> > 
> > Email servers
> > Email clients
> > 
> > and return in the drop down:
> > postfix
> > qmail
> > smail
> > sendmail
> > pine
> > elm
> > mutt
> > netscape
> > etc.
> > 
> > The advantage of this is that it's completely server side, so it would
> > work even on Lynx.  Comments?