Apps DB round 2

[Jeremy Newman]

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
[e-mail].

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:[e-mail]
|_|____|_/_/|_|_|___,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

[Francois Gouget]

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         [e-mail]        http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux

[Jeremy Newman]

> -----Original Message-----
> From: Francois Gouget [mailto:[e-mail]]
> 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:[e-mail]
|_|____|_/_/|_|_|___,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

[James Hatheway]

> > 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

[Jeremy Newman]

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:[e-mail]]
> > > 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:[e-mail]
|_|____|_/_/|_|_|___,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

[G.LeeJ]

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>

[Francois Gouget]

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         [e-mail]        http://fgouget.free.fr/
     We are Pentium of Borg. You will be approximated. Division is futile.

[Ian Pilcher]

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.

[Peter Bortas]

"Jeremy Newman"  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.

[Jeremy White]

> 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

[Patrick Spinler]

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

Apps DB Round 3

[Jeremy White]

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

Apps DB Round 3

[Marcus Meissner]

> 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