.fdi files and HAL

[Owen Fraser-Green]

Hi,

On Tue, 2004-06-08 at 08:54, Ikke wrote:
> >   - A scoring system where people can vote on the accuracy of an .fdi
> > file. This scoring could be made on the part of the general public
> > (unlikely, most people will not want to care about this), or on the part
> > of interested parties.
> Indeed, most users won't care. I tought project Utopia, and with it projects
> like Hal, were there to simplify stuff, also for first-time users.
> Ex-Windows users? Did you ever have to enter device information in Windows?
> Or give scores to device recognition? I'm not saying Linux should be a clone
> of Windows at all!!! But I guess users expect the same useability. And this
> is one of the items to work on.
> I don't think it's good publicity if you have to ask the user if the
> hardware is recognized correctly.

As with Nicks suggestion, most of time the user won't be prompted for
anything, the hardware will just work without any user intervention. In
the case where a match isn't found then the user will be prompted for
basic device information. This isn't much different from Windows where
you get chose a type, then a vendor list, then a product list. Except
we'll also offer an "Other" where the user can type the names. With
time, this will occur less and less frequently though as the database
gets complete. Of course it would be best if it could be avoided at all
but I think this approach of kind of forcing everyone to play an active
role is going to be the quickest way to complete the database. To put it
another way, it's the route that's going to lead to the least
interaction for the highest proportion of the time and that's what
matters most.

Regarding the scoring, I was rather thinking of an kind of automated
implicit scoring system. As an embellishment to my previous use case,
let's say that for most of the time, exactly one match is found for the
hardware so instead of a full-on wizard, some info bubble pops up just
to tell the user what the system did automatically for them (it is after
all rather nice to get some acknowledgment that the system's accepted
the device). If there are multiple matches, however, then the system
chooses the one with the highest score - probably just as simple as the
one that's been chosen the most before. If, in either case, the user
doesn't like the selection then they click on the bubble or something to
invoke the wizard. That pops up showing the automatic selection but with
a "This is wrong" button. Next, the wizard can show a list of the
available matches or the good-old DIY option. The user picks one from
the list and the score for that one gets automatically bumped.  

A more elaborate scheme with administrators who can maintain scores
could also exist for the web site but I envisage that 99.9% of the time
the web site will not be the user's channel for browsing/downloading
.fdi files. For the hardware wizards, the word SOAP springs to mind...

> I think we should interact with hardware vendors too. Give them an easy
> interface to add their (new) product's data, convince them why they should
> take care of it,...

That might be nice. Let them be administrators for their own vendor tags
in the web front-end.

Before we get too carried away there are some other important points to
clarify:

- Should such a repository just deal with .fdi files? Or would it also
make more sense to take things to a slightly higher level - e.g.
available drivers, location of firmware (that's always something that
seems to hinder from my wireless hardware from Just Working) etc. All
this though could complicate matters terribly (different drivers for
different kernel versions/distributions etc.etc.etc.)

- Should a more general solution be sought? I've often pondered over the
possibility of similar solutions for other things e.g. plugins for
various applications, themes, mime-type info etc. I'm not suggesting
lumping all these into one super-repository but, rather, implement a
generic repository/query/install solution whereby different repositories
can be hosted separately and the client tools need to be told which
repository to use depending on the class.

- Should this discussion be taken elsewhere? Especially if a more
generic solution is called for. Back over to xdg maybe?

Cheers,
Owen



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal