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