The new Application DB (http://wine.codeweavers.com/appdb/) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments, and flames [:-)] as possible this week. We need volunteers to take responsibility for updating Apps in the DB. If you would like to help, email the appDB team at appdb(a)codeweavers.com. Areas we need help on: - Add Apps and App Versions. - Comments on Apps - Application Owners (the app db has a privilege system where you can be owner of an app.) - Screenshots (lots of 'em) --- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
On Tue, 12 Jun 2001, Jeremy Newman wrote:
The new Application DB (http://wine.codeweavers.com/appdb/) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments,
A few bad links: * http://www.winehq.com/support.shtml 'Application Database', fourth item in the Documentation column, points to http://wine.codeweavers.com/fom-meta/cache/394.html * http://www.winehq.com/dev.shtml 'Application Database', second item in the Wine Development list, points to http://www.winehq.com/Apps/ Damn, now I'm lost, I can't find my way to the application database anymore. I swear I found a link on the WineHQ site though... Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes: http://wine.codeweavers.com/appdb/appview.php?appId=42&versionId=22 I propose to remove this column and move the screenshot next to 'Description' with an 'align=right' on the table. It seems to work here: <td class=color2 valign=top width='100%'> <table width='100%' border=0><tr><td width='100%' valign=top> <!-- the screenshot starts here, I added align=right --> <table align=right width="128" border=0 cellpadding=1 cellspacing=0 > <tr><td align=center class=color3> <small><font color=white><b> Screenshot </b></small> </td></tr> <tr><td class=color3> <table width="100%" border=0 cellpadding=0 cellspacing=1"><tr><td class=color2> <a href='screenshots.php?appId=42&versionId=22'><img src='./images/no_screenshot.gif' border=0 alt='No Screenshot'></a></td></tr></table> </td></tr></table> <!-- End of the screenshot, Description will be on the same line --> <b>Description</b><br> [description originally by tegel at a site named dubaron.com] <br> <br> I hope it works in all browsers... http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0 * We should ban JPEGs for screenshots :-) http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0 * It would be nice to see who owns a given application (but maybe there's no owner yet).
and flames [:-)] as
No way. You're doing a great job. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux
-----Original Message----- From: Francois Gouget [mailto:fgouget(a)free.fr]
A few bad links: * http://www.winehq.com/support.shtml 'Application Database', fourth item in the Documentation column, points to http://wine.codeweavers.com/fom-meta/cache/394.html
Yeah, Andi put this one up as a holdover until we get the new AppDB up. Once we feel it's ready (soon). We will update all the links on the site, and Andi will update his FAQ to point to the new location.
Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
* We should ban JPEGs for screenshots :-) http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
Ewww, That is a bad shot, but not JPG's fault. It was converted from a GIF, I'll get a better one.
* It would be nice to see who owns a given application (but maybe there's no owner yet).
That's a good idea. We'll add a App Contacts column, so we all know who to ask for help on the app. Man, I hope that does not scare anyone off from being an app owner though. :-)
and flames [:-)] as No way. You're doing a great job.
heh! _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
Yes, unfortunately... Many public places like libraries,etc. still have terminals with 15 inch monitors at 800x600. -James -- James Hatheway james(a)macadamian.com ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. "Software solutions for leading ISVs and e-Business"
OK, you talked me into it. (Didn't take much, did it?). What I will do, is move the Description text underneath the gray rows of app info. That's the area that gets cut off at 800x600. Plus, that will give the URL's and names more room to stretch.
-----Original Message----- From: James Hatheway [mailto:james(a)macadamian.com]
Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
Yes, unfortunately... Many public places like libraries,etc. still have terminals with 15 inch monitors at 800x600.
_ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
James Hatheway wrote:
Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
Yes, unfortunately... Many public places like libraries,etc. still have terminals with 15 inch monitors at 800x600.
agreed......alot of people are simply in a upper crust minority with screens as large as 1024x768 and able to read that res without "squinting" terribly......ie:at "least" a 19" monitor and those aren't cheap for average consumer...although Ihaven't checked prices recently my 21" hitachi is totally adequate ....... I NEVER design without taking into consideration 15"/800X600......because the outcome can be plain nasty. signed minority member <g>
On Tue, 12 Jun 2001, Jeremy Newman wrote: [...]
* We should ban JPEGs for screenshots :-) http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
Ewww, That is a bad shot, but not JPG's fault. It was converted from a GIF, I'll get a better one.
Still, quite often I noticed that JPEG is not very good for screenshots: - screenshots often have large uniform surfaces, e.g. title bar, window background... JPEG tends to render these with weird dithering-like patterns. - it tends to blur fonts. I believe that's because fonts are basically thin lines, which means high frequency, which is exactly what JPEG's lossy compression removes. - if you ever write documentation that is going to be printed, you'll notice that the printed version has very clear smudges all around the text. These smudges are present on the screen too but they are particularly visible when printed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Jeremy Newman wrote:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
This is one of my (many) pet peeves. Just because I have a high resolution display doesn't mean that I'm going to devote the entire screen to the web browser. IMO, web pages should be designed to work without horizontal scrolling in a browser window 600-620 pixels wide (unless there's a really good reason). People using low-resolution displays will be able to use the page in a maximized browser, and the rest of us will be able to actually benefit from our technology investment. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================
"Jeremy Newman" <jnewman(a)codeweavers.com> writes:
I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course).
You can safely assume 600-700 pixels width. No more. I Sure don't run my browser in 1600x1200 just because my desktop happens to run in that resolution. -- Peter Bortas http://peter.bortas.org Roxen IS http://www.roxen.com
You can safely assume 600-700 pixels width. No more. I Sure don't run my browser in 1600x1200 just because my desktop happens to run in that resolution.
Hmmm. You're imposing maximum resolutions without necessarily considering the effects, and the overall design. I believe that the design of the page is such that if you browse with a more narrow browser than the design calls for, the only information 'lost' is a screenshot. This seems like a fairly decent design tradeoff to me. (Of course, if the design doesn't work this way, maybe it should, Jer <g>). Jer
OTOH - I always understood that hardcoding presentation elements into an HTML document was eeviilll, that presentation was to be the province of the displaying agent (browser). -- Pat Jeremy White wrote:
You can safely assume 600-700 pixels width. No more. I Sure don't run my browser in 1600x1200 just because my desktop happens to run in that resolution.
Hmmm. You're imposing maximum resolutions without necessarily considering the effects, and the overall design. I believe that the design of the page is such that if you browse with a more narrow browser than the design calls for, the only information 'lost' is a screenshot. This seems like a fairly decent design tradeoff to me. (Of course, if the design doesn't work this way, maybe it should, Jer <g>).
Jer
-- This message does not represent the policies or positions of the Mayo Foundation or its subsidiaries. Patrick Spinler email: Spinler.Patrick(a)Mayo.EDU Mayo Foundation phone: 507/284-9485
Okay, with all of 3 days worth of data, we've already figured out some problems with the current Apps DB. The structure of the DB is that you have an app, like MS Word. Now, when you're on MS Word, you can see an app description, and people can post comments. Each App can (should?) have sub version records. So, you can have a Word 2K and a Word 97 record. The Word 2K record can contain more info, more comments, and we've also allowed the old 1-5 rating for the specific app versions. However, no one is really using the app versions. A lot of people are submitting an App (like Starcraft), and then just posting comments against the main Starcraft app page, and ignoring the version page. For Starcraft, it seems like we should get rid of the whole version stuff, because Starcraft conceptually really only has one version. However, for Word (and others), it seems to me to be really important to maintain the version distinction/info. Jer and I have kicked around two possible solutions, and I was hoping to see if anyone else had any better ideas. The first proposal was to modify the app's main page so that it would always display the version info of the most recent version of the app. This would be a little tricky, because we'd need to ask people to enter the date of a particular version, but not too bad. The other proposal was to modify the app's main page so that you couldn't post any comments, and we made it easy/obvious to get to the versions page. Thoughts? Better ideas? Thanks, Jer
The structure of the DB is that you have an app, like MS Word. Now, when you're on MS Word, you can see an app description, and people can post comments.
Each App can (should?) have sub version records. So, you can have a Word 2K and a Word 97 record. The Word 2K record can contain more info, more comments, and we've also allowed the old 1-5 rating for the specific app versions.
However, no one is really using the app versions. A lot of people are submitting an App (like Starcraft), and then just posting comments against the main Starcraft app page, and ignoring the version page.
For Starcraft, it seems like we should get rid of the whole version stuff, because Starcraft conceptually really only has one version. However, for Word (and others), it seems to me to be really important to maintain the version distinction/info.
Jer and I have kicked around two possible solutions, and I was hoping to see if anyone else had any better ideas.
The first proposal was to modify the app's main page so that it would always display the version info of the most recent version of the app. This would be a little tricky, because we'd need to ask people to enter the date of a particular version, but not too bad.
The other proposal was to modify the app's main page so that you couldn't post any comments, and we made it easy/obvious to get to the versions page.
Hmm. I think there is a layer of indirection too much. The versions should probably already be shown on the app page itself, it is too confusing otherwise. Or have the toplevel app page just display the ratings and have a speific version edit/rate page, where the browsing user can make changes. Ciao, Marcus
participants (9)
-
Francois Gouget -
G.LeeJ -
Ian Pilcher -
James Hatheway -
Jeremy Newman -
Jeremy White -
Marcus Meissner -
Patrick Spinler -
Peter Bortas