Real-world appdb

[Scott Ritchie]

On Mon, 2005-02-07 at 01:16 +0100, Holly Bostick wrote:
> I had forgotten the precise URL directly to the appdb, so I had to
> start from the main site, which brings me to my first useability
> complaint: too long a trail to get to the app I'm looking for.
> 

First of all, thank you for writing this letter, it's immensely helpful
to people who so rarely get actual user experiences.  This is an
important point - it's kind of hard to make use of the AppDB, hence
there isn't much incentive to contribute to it.  One thing I would
definitely suggest is making the link more prominent on the WineHQ page
- "Applications" should be replaced with "Applications Database" in the
sidebar, for example.

> I had to go through 4 links just to get to the main application page.
> First, the sidebar link from the main site to the appdb front page. This 
> front page is useless to me (and imo, fairly useless overall), since the
> majority of the "Gold" and "Silver' apps so prominently listed I already
> do/would use the native alternatives for in the case of winzip, p7zip, 
> Paint (Paint??! it's barely useful under Windows!), SimCity, IE, Excel, 
> ACDSee, Money, Frontpage/Dreamweaver, and Ant Movie Catalog. Others I do 
> not use at all, either because I have no use for them, in the case of 
> Powerpoint, Access and Visio, or because they are "special interest 
> programs" as in the case of Warcraft and Age of Empires (I play games, 
> but not those).

We're currently struggling with just how to list applications anyway.
Currently those are the ones showing up since they're the only
maintained apps with non-garbage maintainer ratings.  I would second the
suggestion of moving the top rated apps off the front page to a much
nicer page, and replace the space they take up with some general AppDB
instructions as well as redundant links to the common features, such as
a listing of all the major/minor categories of applications.


> If such a summary was provided on the main application page, I would not
> mind so much having to go to yet another page (fifth link, now) in order
> to find specific details on possible issues with the particular 
> *version* of the program I'm trying to install/run.
> 

One probably hard to do but extremely helpful change would be to make it
so that only apps with different major versions listed them.  There's no
reason clicking Icewind Dale should dump you into a window where you
have to click Version x again.  In fact, most apps don't even have
differences between the versions as far as Wine is concerned, so really
it should only be an exception where a user has to pick a version (such
as with Internet Explorer)

My recommended solution to this is to make the AppDB automatically
forward you to the page for the only version if there is only one
version for the application.  Requesting a new major version of an
application should then be funneled through the same process that adding
an application is.  For apps I currently maintain that don't really have
differences between versions, I currently write "All Versions" as the
version number where my howtos are and then delete any extraneous
subversions.

> 1.4b) more importantly, I do not know what the responsibilities of a
> "maintainer" are-- much less a "super maintainer". There is no link on
> that page as to what this means (not even a little question mark with a
> tooltip popup), and no indication as to whether actually clicking the
> button will go to an "intermediate" page which explains what it is, or
> just sets your login as the maintainer for this app (since I have 
> specifically had to log in in order to enable this button in the first 
> place, it's not an unreasonable assumption that that might occur).
> 

I was going to do a writeup on this, but I got a bit scared away by the
lack of HTML templating in AppDB itself.  I don't know PHP, heh.

> Since I didn't know what would happen, and didn't know if I wanted to or
> was capable of fulfilling what might be a committment (how much do I
> need to know about the program? How much do I need to know about
> programming? Do I need to have a version of Windows available to know
> how the program runs there, so I can compare it to how it runs under
> Wine?), I did not click the button, so the apps will remain unmaintained 
> for the time being (or they won't be maintained by me, anyway).
> 

I would highly recommend assuaging this point by putting some friendly
text encouraging users to post comments on the page.

> Weirdly enough, going to the version page for the application offers me
> the opportunity to be a "regular" maintainer-- so, what, that means I
> would be a maintainer for that specific version, whereas "super 
> maintainer" means that I'd be maintainer for all versions, like some 
> kind of 'team leader'? I'm not sure that either makes sense to me as a 
> user, nor that it is a logical setup generally, at least for games, 
> which usually should not be run at lower versions if a patch (which 
> increases the version while repairing errors) is available. So there is 
> in some ways no reason to maintain version "1.0" when no one should 
> actually be *running* version 1.0 other than immediately after install, 
> and then only for the 5 seconds before the user has installed one or 
> more patches (after which they will be running a higher version). 

I agree emphatically..  Just as the distinction between different
versions is often unneeded, so too is the distinction between maintainer
and super maintainer.


> I'd really like to see forums or at least some kind of PM system so that
> the users of the applications could reliably communicate with the
> maintainer for the benefit of both parties. I see that Planescape:
> Torment (another game I have running under Wine, without issue;
> http://appdb.winehq.org/appview.php?versionId=437 ) has a maintainer,
> but his name is not a mailto: link, so I can't contact him (afaik) to 
> advise him of any new information I may have discovered short of posting 
> a comment myself... which is fine if it's new information (assuming that 
> my comment fits into the organizational structure of the db so that 
> following users can find it easily), but if it's an app-specific issue 
> that I want his help with, it's a waste of space (insofar as such a 
> comment provides no real information to other users searching the 
> database except a confirmation of the issue), and the appdb as it is 
> gives no assurance that the maintainer will see the comment anyway.
> 

The goal should be for users to use the AppDB as a support forum.
Currently, I suppose App maintainers are supposed to read the problems
people have from posts, write up howtos addressing them, and delete the
posts once the issue is solved.  This should certainly be made more
clear, such as in that hypothetical maintainer document.

> Comments should also require the specification of the Wine version, the
> distribution under which it is used, and the type of install
> (self-compiled from source, distribution repository package, or Wine
> distribution package; I have visions of a radio button) to be attached
> to the comment, as new users often don't know to include this
> information, but it's pretty hard to answer many questions without
> having this information (so one has to ask, which wastes time and space).
> 

This is on the todo list I think.

> Somebody's going to say I should write a FAQ myself and submit it as a
> patch, aren't they? Yes, OK, but let me finish this mail first ;-) .
> 

Hey, it's how I got started contributing, writing letters like this and
then making fixes myself, heh.  More usability help is always needed,
and I hope we can at least see another letter from you in the
future :) .

> 1.7) Descriptions are really not very useful, for several reasons. Still 
> focusing on Icewind Dale (since that's the page I have open in the
> appdb atm), here's the Description for the version page:
> 
> "Description
> CD Release. Runs from a modified Baulders Gate engine. Notes from that
> game would help here as well."
> 
> But there's no link to said notes, nor are the relevant notes copied
> from that page and posted as an addendum, so even though this particular 
> description does contain some useful information (for once), it's not 
> even a lead, but only a suggestion of a lead. Big help.
> 

A short briefing on "what to put in the description" for maintainers and
app submitters would be nice, but at the moment we don't even seem to
have a standard for what that should be.  Perhaps we'll bring it up in
IRC.



> 2.1) Only one version (the original version, although there is a 2.01
> patch), but whatever; according to the description, I am supposed to be
> able to install this, as long as I have an insanely old version of Wine
> (the original description was penned by someone installing under
> 20020904!), which I don't.
> 

Seems like a regression!  Darn!  We might have caught it and fixed it
long ago if we had a maintainer for it, but there are significant
obstacles for that to happen, as you point out.  This is indeed
important, and again your contribution is highly valued.


> 3.3) ..what the..???!!! There is no comment! Is the description being
> counted as a comment? In any case, there is absolutely no information
> whatsoever for this application (I don't call "Description:
> Program for burning CD Especially to make clones of original CD\'s"
> information), and there are Zarro bugs found in Bugzilla (of course; I'm 
> not even certain if Bugzilla is even linked to and indexed with the 
> appdb in that way yet).
> 

Linking bugzilla with AppDB is a nighttime fantasy of mine.  I imagine
one day being able to browse to an App (say, Fallout 2), read that it is
rated silver and should install fine, and then see a friendly list of
links to bugs in bugzilla that cover the app.  I'd like to see the
Fallout 2 page, see the nice silver rating telling me I can install it,
and then see a link to the bug "Fade in/Fade out effect can run very
slowly".  I'd also like to see this same bug linked in Fallout 1's page,
since it affects both, and I'd like to be able to list which bugs affect
these apps as the application's maintainer.  Then my user's could go to
the page, get the help and warning they need, and also follow the link
to the bug to maybe vote for it, offer insight, or learn what a required
patch might do.

Indexing bugzilla with AppDB would also make it a lot easier for
bughunters to know which bugs are more important - they could simply
look at which apps list them as important.  Currently, all of this is
done very ad-hoc, and bugzilla is rather underused and feels like a
jungle for application specific problems; formalizing AppDB into
bugzilla would be an amazing leap forward.

On a side note, the AppDB accounts should be the same as the Bugzilla
accounts.  That way one can register with the AppDB, go to his app, find
that his bug isn't listed, and file it all in one nice easy go.  He
could also be informed when the bug is fixed and he can try out his app
again.

> Anyway, I'm terribly sorry this was so long, but it seemed past time to 
> offer some input on actual useability issues in the midst of all
> this discussion. The appdb does "work" as it is (I can navigate it, read 
> the entries, etc); I assume that it will "work" when/if adjusted, both 
> in terms of code, and with the addition of active maintainers. But it is 
> barely of any *use* whatsoever as it is, and it's not clear to me 
> whether the proposed redesign and/or increasing numbers of active 
> maintainers will improve the db's practical functionality for users, for 
> whom I feel this complex and difficult to maintain database should be a 
> primary resource, from which they can both receive and offer assistance 
> in an organized fashion. Or have I misunderstood the function of the 
> appdb entirely?

No, AppDB's function is not to be useless and frustrating, heh.  Again,
your input is extremely valuable, and I thank you for taking the trouble
to register for the list and write up the letter.

Thanks,
Scott Ritchie
wannabe usability guy