[RELEASE] New OXP List

Commander McLane · Post by **Commander McLane** » Tue Sep 21, 2010 12:28 pm

@ mcarans: make the comparison. Open the wiki sandbox table and your sandbox table in two tabs in the same browser window, then switch between them. You will see the the courier font is consistenty wider and therefore uses more space and produces a longer table than the balanced font. Therefore it is counter-productive to what you want to achieve.

Post by **Disembodied** » Tue Sep 21, 2010 12:43 pm

Courier is a monospace font, i.e. all the letters are the same width: I think this is why mcarans is suggesting using it, so that you'll always know how wide X number of characters will be. I don't think that's a huge problem, though: if we pick a number that gives roughly a line-and-a-half on (say) an 800-pixel width screen, then there should be enough wiggle room in the spare half-line to avoid anything going over 2 lines long.

mcarans · Post by **mcarans** » Tue Sep 21, 2010 1:44 pm

Disembodied wrote:
Courier is a monospace font, i.e. all the letters are the same width: I think this is why mcarans is suggesting using it, so that you'll always know how wide X number of characters will be. I don't think that's a huge problem, though: if we pick a number that gives roughly a line-and-a-half on (say) an 800-pixel width screen, then there should be enough wiggle room in the spare half-line to avoid anything going over 2 lines long.

Yes, I think this is a good way of doing it, but as I keep mentioning, we will need some people to volunteer to check the table at the decided resolution and talk to OXP authors.

If noone is assigned to do this, it won't happen as people viewing the wiki will assume that someone else will sort it out. So would some volunteers like to step forward?

Commander Smivs · Post by **Smivs** » Tue Sep 21, 2010 3:12 pm

mcarans wrote:
So would some volunteers like to step forward?

I'll cut them down to size

mcarans · Post by **mcarans** » Tue Sep 21, 2010 5:58 pm

Thank you Smivs. Any more volunteers?

I thought a bit more about OXP version. Sorting by OXP version would not be very useful (would it?) and authors can put version in the OXP Name and Summary column.

So maybe just delete the Version column?

Re: release date column, anyone got any objections to removing the day?

Following Disembodied's idea, is one and a half lines @ 1024 ok? (I think that is about the present length)

maik · Post by **maik** » Tue Sep 21, 2010 6:43 pm

mcarans wrote:
Thank you Smivs. Any more volunteers?

I thought a bit more about OXP version. Sorting by OXP version would not be very useful (would it?) and authors can put version in the OXP Name and Summary column.

So maybe just delete the Version column?

Re: release date column, anyone got any objections to removing the day?

Following Disembodied's idea, is one and a half lines @ 1024 ok? (I think that is about the present length)

I don't think the version number is too useful on the overview page. As you said, you can't sensibly sort by it so I would have to wade through the list to find my 50 odd OXPs and know my OXP version numbers or hope that they are part of the OXP file name and compare with the list in Finder (Explorer for you Windows guys). Not what I want.
IMHO it's enough to have it on the OXP detail page.

Regarding the date: year and month are not always sufficient. Even during the few weeks where we were working on the proposed table I updated an OXP release date more than once. This would get lost if we omit the day.

So what about the Oolite version? It is useful once we have the next Oolite version. Everyone who feels reasonably sure about upping the compatibility of an OXP to match the new Oolite version can do so. That way we relatively quickly get an overview about which OXPs still need to be tested (kind of a triage helper) or which ones actually don't work. To make the column usable like this we could try another way: Call it "compatible", meaning whether it is compatible with the latest test version of Oolite or not, and have yes, no, unknown as values. So once a new Oolite version comes out, set all values to unknown first, then update the ones that do work to yes and the ones that do not work to no.

Thoughts?

BTW, good idea to put the intended character limit in the column header!

maik · Post by **maik** » Tue Sep 21, 2010 6:49 pm

mcarans wrote:
Volunteers, please come forward to be ramble assassins.

Happy to help. Like brevity.

mcarans · Post by **mcarans** » Tue Sep 21, 2010 7:03 pm

maik wrote:
Regarding the date: year and month are not always sufficient. Even during the few weeks where we were working on the proposed table I updated an OXP release date more than once. This would get lost if we omit the day.

Ok sure. It's only 3 characters anyway.

maik wrote:
So what about the Oolite version? It is useful once we have the next Oolite version. Everyone who feels reasonably sure about upping the compatibility of an OXP to match the new Oolite version can do so. That way we relatively quickly get an overview about which OXPs still need to be tested (kind of a triage helper) or which ones actually don't work. To make the column usable like this we could try another way: Call it "compatible",
meaning whether it is compatible with the latest test version of Oolite or not, and have yes, no, unknown as values. So once a new Oolite version comes out, set all values to unknown first, then update the ones that do work to yes and the ones that do not work to no.

Y, N and U - nice & simple

maik wrote:
BTW, good idea to put the intended character limit in the column header!

It would be approximate given we're not using a fixed width font, but ok.

maik wrote:
Happy to help. Like brevity.

Thanks a lot!

maik · Post by **maik** » Tue Sep 21, 2010 8:35 pm

mcarans wrote:

maik wrote:
BTW, good idea to put the intended character limit in the column header!
It would be approximate given we're not using a fixed width font, but ok.

Sure. But probably good enough. 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. It seems to fit when the full window width is about 1280px (Safari 5 on OS X 10.6).

zevans · Post by **zevans** » Tue Sep 21, 2010 10:18 pm

maik wrote:
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"

mcarans · Post by **mcarans** » Wed Sep 22, 2010 8:31 am

maik wrote:
mcarans wrote:

maik wrote:
BTW, good idea to put the intended character limit in the column header!
It would be approximate given we're not using a fixed width font, but ok.
Sure. But probably good enough. 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. It seems to fit when the full window width is about 1280px (Safari 5 on OS X 10.6).

I'm running Firefox on Windows at 1280. Your new line overflows by the following characters: vwwwy y. With the version column changed to Y,N,U, probably 140 characters would make a good limit. The |ext is available for those rare cases that really need more.

[EDITED:]
Can someone change {{{ver|}}} to {{{work|}}} in http://wiki.alioth.net/index.php?title= ... ction=edit

Please copy the table wiki text into a text editor and find replace |ver=1.74 to |work=U and change the title of the column to Works or Compatible then copy the text back.

We can then go through and update all OXPs known to work to Y.

maik · Post by **maik** » Wed Sep 22, 2010 10:51 am

mcarans wrote:
[EDITED:]
Can someone change {{{ver|}}} to {{{work|}}} in http://wiki.alioth.net/index.php?title= ... ction=edit

Please copy the table wiki text into a text editor and find replace |ver=1.74 to |work=U and change the title of the column to Works or Compatible then copy the text back.

We can then go through and update all OXPs known to work to Y.

Done.

mcarans · Post by **mcarans** » Wed Sep 22, 2010 11:06 am

Thanks. Are we going to have blank for unknown or U for unknown?

The column heading I guess we can reduce to C or W and explain it above + reduce the width of the column to add a few chars to the OXP Name and Summary column.

maik · Post by **maik** » Wed Sep 22, 2010 11:58 am

In the table source it is set to "U", but I guess the row template needs to be adjusted to display the work parameter instead of the version parameter. Let me fix this... done

Commander Smivs · Post by **Smivs** » Wed Sep 22, 2010 12:28 pm

This is starting to look weird!
The word 'Work' doesn't fit so I can only see 'Wor' and therefore the 'U's' are totally out of context. I'm not sure most people would understand this system anyway. This is on my main computer, the old Windows box is being Windozy at the moment so I can't check it on there right now.
Surely if we are now only including 'valid' OXPs in the list, this column has become redundant, and can be removed. The OXP release/update column gives a good idea of up-to-date-ness anyway. Also this frees-up two or three more characters for the description.