[RELEASE] New OXP List

[mcarans]

It's not your machine - it said Ver before which was shorter.

There would have to be a key for this column above the table in order to reduce the column to one character.

The key would be C=Compatible with latest Oolite version: Y(es)/N(o)/U(nknown)

maik's idea is for this to be similar to the old Version column such that on new Oolite release, the column is set to U(nknown) initially. Authors and/or others update it to Y or N for their OXP once they know whether or not it works with the new release.

How do OXP authors feel about this?

[maik]

It's a work in progress. But why only include valid OXPs in the list? The idea is to indicate which ones have not been validated to run on the latest version ("U"), which ones have been and work ("Y"), and which ones have been and don't work("N").

So when the next Oolite version rolls around, all is reset to "U" and people can test and update to "Y" or "N". The labels "works", "Y", "N", "U" are of course open to debate, feel free to suggest something else.

I think that this information is more useful than having the Oolite version number as it were before because this only tells us that the latest oolite version an OXP has been tested is a go. It doesn't tell us if the OXP has been tested on a later Oolite version and found to not work and thus needs fixing. At least for orphaned OXPs this would be good to know.

[maik]

I just rebased the compatibility column on the Oolite 1.74 announcement date on Berlios, meaning that all OXPs that were released on or after 2010-06-15 received a "Y" (compatible), all OXPs that I personally use and feel that are working also received a "Y", all OXPs that had already been marked with a version lower than 1.74 in the previous incarnation of that column received an "N" (incompatible), and the others received an empty space, which I think is more intuitive than an "U".

Now everyone else please update the blanks

[Thargoid]

Without wishing to throw a spanner in the works, what about OXPs that are compatible with 1.74.2 but not 1.74? With bugfixes etc in the minor versions (plus perhaps some new JS functions) there may be OXPs that either don't work properly or don't work at all with lower minor versions.

For examples trumbles don't work in 1.74.0, so something like Trumble Treats won't work in the older version. There may well be others that need JS bugfixes in .1 or .2

Before this goes too far it may be worth being more explicit with stating 1.74.2 rather than 1.74.

[Smivs]

Good work, Maik. That's looking much better, and is far less enigmatic!
It's coming together really well now.

[maik]

Without wishing to throw a spanner in the works, what about OXPs that are compatible with 1.74.2 but not 1.74? With bugfixes etc in the minor versions (plus perhaps some new JS functions) there may be OXPs that either don't work properly or don't work at all with lower minor versions.

For examples trumbles don't work in 1.74.0, so something like Trumble Treats won't work in the older version. There may well be others that need JS bugfixes in .1 or .2

Before this goes too far it may be worth being more explicit with stating 1.74.2 rather than 1.74.

Good to know! But that begs the question if we have to reassess all OXPs even for minor version updates?

Edit: I just updated the explanation to refer to 1.74.2

[Thargoid]

Re-assessment shouldn't be necessary. It's normally OXPs work with .x+1 that didn't with .x, rather than the other way about.

Unless of course the minor version update breaks something rather than fixing it

[maik]

Alright, time to call it release candidate 2.

Release Notes:

• - The "OXP name and description" column has been made flexible in width so it always fills up the space that remains after the fixed width columns take their place. Text can flow over into the next line. This allows users who use smaller resolutions to see OXP descriptions in their entirety without horizontal scrolling but means that there is no limit on description length anymore. This will be dealt with when description length gets out of hand by shortening them appropriately.
  
  - The "version" column which gave the latest Oolite version that an OXP is compatible with has been changed to a compatibility flag in the "C" column, stating whether an OXP is compatible with the latest Oolite version, is incompatible, or has not been tested.
  
  - There are two new symbols that can be used in the description: an indication that an OXP is a large download (see Famous Planets for an example), and an icon that shows further descriptive information in a tooltip when hovering the mouse over it (see Feudal States for an example).

Please continue commenting, this has been most helpful to further advance the usefulness of the new OXP overview table.

[maik]

I added an entry to the table which uses 145 characters selected according to the average letter frequency and the average word length (5 characters) in English.

I am now trying to think of a backstory for a possible OXP entitled "Lorem Ispum Dolor"

Why don't you do fan fiction instead?

[mcarans]

Excellent. Looking good.

As the "C" column cannot be shrunk, I suggest that the extra space could be used for the |big=y icon (for those OXPs whose download size >xMb where x is currently 5 but can be changed).

[maik]

Excellent. Looking good.

As the "C" column cannot be shrunk, I suggest that the extra space could be used for the |big=y icon (for those OXPs whose download size >xMb where x is currently 5 but can be changed).

I just added the icon to that column as well, so we have a comparison of the two options now. As I already mentioned in the PM, I don't think the icon belongs there and prefer it to remain in the description column if we need it at all. And I'm still not convinced of the latter, bearing in mind that we're working on an overview of OXPs (I know I'm repeating myself). Can those who really think we need it please stick up their hands/tentacles/fins so we get a better idea about this?

[Killer Wolf]

okay, here's a thought, dunno if it's poss on wiki but how about an "onMouseOver" thing - when you hover over the name link to the OXP it pops up a little box saying "uploaded ddmmyy, Vx.xx" or whatever? that way we got more space to describe the OXP etc and the other info is only shown if you're interested in it.

[maik]

okay, here's a thought, dunno if it's poss on wiki but how about an "onMouseOver" thing - when you hover over the name link to the OXP it pops up a little box saying "uploaded ddmmyy, Vx.xx" or whatever? that way we got more space to describe the OXP etc and the other info is only shown if you're interested in it.

Yes, it is possible. Maybe not on the name but at least on an icon. It just doesn't allow for sorting by the data you don't put directly in the table anymore (e.g. upload date).

What would be your suggestion about the contents of the mouseover and the impact on the table?

[mcarans]

As I argued before, download size can be elsewhere like Box.Net or the wiki/web page, but if a number of people really want this, I have an idea (don't know if it is a good one but will float it anyway).

Make the C column which cannot be shrunk: "C D"
The key for D is D=Download > xMb (Y/N)
(with default of N)

As people would only be interested in compatible OXPs, this would allow sorting by download size. (ie. Y N vs Y Y) You could even have A: 0-2Mb, B:2-4Mb, C:4-6Mb or some other breakdown.

The big question is: is this necessary given the download size can be put elsewhere - as maik said - show of hands please.

[Smivs]

It might be a useful feature to include an indicator of download size, but as been pointed out this information is usually offered at the time of downloading.
The main benefit of including this info in the table is to, in some cases, avoid people wasting a little bit of time going to a download site and only then finding the OXP is 'too big'.
Another way of handling this would be to add the download size just after the link in the summary column. I have added the download size to my 'Accessories' OXP on the table as a demo. What do you think?