[RELEASE] New OXP List

[Thargoid]

Just because an OXP has an old release date doesn't mean it's incompatible with newer versions of the trunk code.

For example both my Welcome Mat and Traffic Control OXPs are compatible back to 1.72 as both have quite simple scripting. But many of my other OXPs (both older and newer than those two) are 1.74 only, due to the major changes in mission offering with 1.74. Neither WM or TC use mission screens, so they weren't affected by the trunk code changes.

So for me a minimum version column at least is needed. As for a maximum version, there is arguably less need for that information. It is rare that an OXP truly is only compatible with legacy versions of trunk code (and not the current test release). Many authors though (including me) use the max setting to limit compatibility problem reports for OXPs used with trunk builds, which is really the only time it becomes a "problem".

[Kaks]

Talking about compatibility, the javascript test oxp is very, very old! It does produce quite a number of warnings & errors, and that tends to give the impression that Oolite itself is actually broken in some major way, something I would tend to disagree with!

[Commander McLane]

Thanks for the effort you've put into this. I think you're on the right way.

Some feedbeck from my perspective:

I am torn about the category and table length issue. On the one hand I find it useful und simple to have only one page with one table. Having everything in the same place has big advantages, no question. On the other hand I also find it convenient to be able to put an OXP into more than one category. This would suggest having multiple tables, one for each category, and an OXP could be put into more than one table. There is also the size issue. One factor which brought about the whole OXP-table-reorganization-idea was that the existing table got too big for conveniently fitting into one Wiki page. Now, with everything back into one table, the Sandbox page already gives out a warning again when you click the edit-button:

Warning: This page is 63 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

Even if I consider that the proposed table is not the only thing on the page, it is still by far the largest, so it is responsible for a good chunk of the 63 kb. I don't know, however, if the Wiki warning is to be taken at face value. Of the browsers currently in use, are there any which cannot deal with pages longer than 32 kb? Of course, with adding new OXPs the table (and page) will only get longer. So how long would we have before again facing the necessity to split the table over several pages?

Another issue: I applaud your efforts in brevity, however I don't think that everything has to fit into one line. Personally I don't see a problem in some descriptions breaking over into the next line. As it is now, the table doesn't fit into my browser window, and I have to scroll horizontally in order to get all information (by default I only see the first two letters of the creator name). Personally I find that worse than having a two-line description (or even generally two-line descriptions).

Apart from these, I think you have come to a sensible solution and this table is a good way to go forward.

[Smivs]

Thanks for the effort you've put into this. I think you're on the right way.

Some feedbeck from my perspective:

I am torn about the category and table length issue. On the one hand I find it useful und simple to have only one page with one table. Having everything in the same place has big advantages, no question. On the other hand I also find it convenient to be able to put an OXP into more than one category. This would suggest having multiple tables, one for each category, and an OXP could be put into more than one table. There is also the size issue. One factor which brought about the whole OXP-table-reorganization-idea was that the existing table got too big for conveniently fitting into one Wiki page. Now, with everything back into one table, the Sandbox page already gives out a warning again when you click the edit-button:

Warning: This page is 63 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

Even if I consider that the proposed table is not the only thing on the page, it is still by far the largest, so it is responsible for a good chunk of the 63 kb. I don't know, however, if the Wiki warning is to be taken at face value. Of the browsers currently in use, are there any which cannot deal with pages longer than 32 kb? Of course, with adding new OXPs the table (and page) will only get longer. So how long would we have before again facing the necessity to split the table over several pages?

The table is sortable, and will also link to the auto-generation feature of the Wiki, so there is no reason why the Wiki page entries for OXPs should not have multiple categories specified, allowing them to be shown in multiple auto-generated lists. Our table is a synopsis, a quick guide to show users ALL the available OXPs in a simple way and on one page.
We are aware of the size of the list. We tested it as thoroughly as we could and found no problems. Specifically it was tested on Linux, Mac and Windows O/Ss and on all popular browsers - Opera, Firefox, Safari, Chrome and Internet Explorer. In fact the IE test was done using IE6 on a really crappy computer running XP, perhaps the worst possible scenario, and it was fine. I really can't believe that any computer/OS/browser combination used today will have any problems with it.

Another issue: I applaud your efforts in brevity, however I don't think that everything has to fit into one line. Personally I don't see a problem in some descriptions breaking over into the next line. As it is now, the table doesn't fit into my browser window, and I have to scroll horizontally in order to get all information (by default I only see the first two letters of the creator name). Personally I find that worse than having a two-line description (or even generally two-line descriptions).

There are several problems with 2-line descriptions...it makes the table far too long (see above) and also compromises the aesthetics. Also, as was explained in the release post, the description is intended to be a 'teaser' to give you the bare basics of the OXP. Detailed descriptions are best left to the Wiki or Web-page for each OXP, where due credit can be done to these. Some of the descriptions we had to abbreviate were longer than some Wiki page entries which is a ridiculous situation. Also we felt it was unbalanced, and even un-fair to give more space to some OXPs and less to others. Also, it will inevitably happen that if we allow some 2-line descriptions someone will want three lines and so on. When you consider one of our primary goals was to keep this as lean as possible, any compromises here will defeat one of the key principles behind the list.
The table layout was designed so that only non-essential information was off-screen when viewed on a small screen or system that has to add a horizontal scroll bar. The vital info (category, name + link to wiki or web page, and description) should be visible without any scrolling.
The table is fixed width, and a narrower table would look silly on larger monitors.

Apart from these, I think you have come to a sensible solution and this table is a good way to go forward.

Thanks for your comments. No system is going to be perfect or fulfill everyones wishes. What we have tried to do is come up with a good, workable solution to a problem, and by and large I feel we have achieved that goal.

[mcarans]

[EDITED]
If you look at Famous Planets, I've done an example where adding the optional parameter |big=y gives an elephant symbol which if you hover over it says 5MB+. This can be easily added to the largest OXPs if people feel this is a reasonable way to indicate large download size.

For longer descriptions, I have added an optional parameter that gives a symbol which if you hover over it, shows another line of text. OXP authors add |ext=blah blah. See Feudal States.

Winston has indicated that he might give Selezen and Ahruman ssh access to the wiki server. They can then install Mediawiki plugins, including one to reset my password I hope. Multiple categories for OXPs would work best with an enhanced autogeneration using plugins I think.

In the meantime, I would like to get the single table released reasonably soon. Regarding splitting the table, that can be discussed and ideas tested in the Sandbox after the single table is released as I'm aware that the longer it stays in the Sandbox the more out of date it will get.

We can create the separate table for broken download OXPs on release. Things like the Javascript test OXP if it is known to cause issues could also go in here.

[Commander McLane]

There are several problems with 2-line descriptions...it makes the table far too long (see above) and also compromises the aesthetics. ... Also we felt it was unbalanced, and even un-fair to give more space to some OXPs and less to others. Also, it will inevitably happen that if we allow some 2-line descriptions someone will want three lines and so on. When you consider one of our primary goals was to keep this as lean as possible, any compromises here will defeat one of the key principles behind the list.

Here I am of a different opinion. I have no problem whatsoever with not all descriptions being the same size. One may take a single line, another one two or three. So what? OXPs are different. I fail to see any unbalancedness or even unfairness here.

The table layout was designed so that only non-essential information was off-screen when viewed on a small screen or system that has to add a horizontal scroll bar. The vital info (category, name + link to wiki or web page, and description) should be visible without any scrolling.
The table is fixed width, and a narrower table would look silly on larger monitors.

My suggestion: If possible, make the complete table 100% wide (not fixed, but browser-window-filling). Then keep the fixed widths for all columns except Short Description. Instead make the text wrappable for that column. The result would be that regardless of your monitor, you would always see the complete table, only the second column would be wider or narrower. It would however always contain the same text, only on a small monitor the text would wrap over into a second (and possibly third) line for some entries. I really can't see any harm in that. I've just tried to see what it would look like, however I failed due to lack of HTML knowledge.

Another suggestion: what about having the short description as first column and the category as second? This would probably make the alphabetic approach clearer.

[zevans]

My suggestion: If possible, make the complete table 100% wide (not fixed, but browser-window-filling). Then keep the fixed widths for all columns except Short Description. Instead make the text wrappable for that column. The result would be that regardless of your monitor, you would always see the complete table, only the second column would be wider or narrower.

I second that. In the day job now I often have to deal with representing complex tables like this in a web-friendly way, so I'm happy to have a go at making it work this way if people like the idea. Makes perfect sense to me.

I'm off to see what new OXPs there are seeing as you've all been busy creatives for the past year by the look of it!

PS Hello. It's been a while. (Don't ask, life got in the way.)

[maik]

My suggestion: If possible, make the complete table 100% wide (not fixed, but browser-window-filling). Then keep the fixed widths for all columns except Short Description. Instead make the text wrappable for that column. The result would be that regardless of your monitor, you would always see the complete table, only the second column would be wider or narrower.

I second that. In the day job now I often have to deal with representing complex tables like this in a web-friendly way, so I'm happy to have a go at making it work this way if people like the idea. Makes perfect sense to me.)

Sure, give it a go. Also, since we're using named parameters in the line template, it is easy to reorder the columns.

[Smivs]

My suggestion: If possible, make the complete table 100% wide (not fixed, but browser-window-filling). Then keep the fixed widths for all columns except Short Description. Instead make the text wrappable for that column. The result would be that regardless of your monitor, you would always see the complete table, only the second column would be wider or narrower. It would however always contain the same text, only on a small monitor the text would wrap over into a second (and possibly third) line for some entries. I really can't see any harm in that. I've just tried to see what it would look like, however I failed due to lack of HTML knowledge.

Another suggestion: what about having the short description as first column and the category as second? This would probably make the alphabetic approach clearer.

We did try 100% table width as opposed to fixed width, and found that it was not always successful. In fact we spent many days trying just about every combination we could think of, and the one we published stood out as being the best compromise taking everything into account.
Having said that, if anyone can improve this, as Maik says, Feel Free.
One thing I will be unambiguous about, though, is keeping the Synopsis (It's not a 'Description', just a brief summary) to one line only. This feature is the key to keeping the table short and under control. When we looked at the existing tables, they had many drawbacks, but the biggest reason by far they were not working well was because of the length of some of the descriptions. We took a decision early on that if the new table was to work in a sustainable way, limiting the Synopsis to one line was the central pillar of the concept. We deliberately added a 'no-wrap' attribute to ensure this. If the summaries get out of control, so will the table.
Frankly, if we go back to multi-line descriptions all we will end up with is a re-working of the old, flawed table we had before. This move would completely undo the main benefits the new table offers, and would, in my humble opinion, be a seriously retrograde step.
To re-iterate, the Synopsis in the table is a 'teaser', a brief summary to give an impression of an OXP. The place for the full description with all the bells and whistles is the OXPs web- or Wiki-page.

[mcarans]

Look at the current alphabetic tables and how awful they look with many OXPs having rambling descriptions.

Open http://wiki.alioth.net/index.php/OXP%27 ... to_%27F%27 and set your browser windows to 1024 width to get an idea of what a netbook user has to put up with. Sometimes you can only see 5 OXPs on the screen at once!

What is wrong with a brief one line teaser in the summary with hovering over the continuation symbol for further information (as in Feudal States) and even more information being on the OXP's wiki or webpage?

Given how the alphabetic tables ended up, why would the same not happen with the new sortable table if there is no limit to the summary?

[maik]

That said, more often than not the huge vertical space that OXPs sometimes take in the current table can be attributed to the one-ship-per-line concept. There are also quite a few cases where there is information in the synopsis that clearly doesn't belong there.

I don't think we have to be dogmatic about the one-line-per-entry rule. Just make it a rule and if there is a an exception then so be it. After all, we can all help tidying up descriptions to make them shorter when the need arises. I guess that we will find that 99% will actually remain a one-liner.

[mcarans]

That said, more often than not the huge vertical space that OXPs sometimes take in the current table can be attributed to the one-ship-per-line concept. There are also quite a few cases where there is information in the synopsis that clearly doesn't belong there.

I don't think we have to be dogmatic about the one-line-per-entry rule. Just make it a rule and if there is a an exception then so be it. After all, we can all help tidying up descriptions to make them shorter when the need arises. I guess that we will find that 99% will actually remain a one-liner.

That's right and the small number of exceptions can use the continuation symbol so that people viewing the table at a lower resolution have a better viewing experience.

[Smivs]

I also have no problem with using the continuation symbol for the odd longer summary, providing the table as viewed remains at one line per OXP.
I don't think this will be necessary though as we managed to condense even the longest of the old Descriptions down to a one line summary.

To give you an idea of what we DON'T want, I've composited two screenshots, on the left is the new proposed table and on the right is the old table which Mcarans linked to above, which is what the new table will end up like if we allow multi-line Descriptions. I think it speaks for itself!

[Commander McLane]

Just to make myself clearer: I think it was the right decision to drop the "Ships" and "Stations" columns. In many cases it was these columns which made an entry row unnecessarily high (in the example above that is true for the 1st, 3rd, and 5th row; and in the 6th row it's the name of the OXP which accounts for an extra line). So the descriptions never were the only culprit.

I also agree with shortening the descriptions. The bunch of information should be located in the single OXP's Wiki page, not in the list. And indeed, sometimes the creators (myself included, look at the last visible entry in the example above) tend to get a little too verbose in praising their "children". Some discipline there doesn't hurt at all.

However, I would be less dogmatic about the "one line only" rule. The reason for this is that there are two issues which have to be weighed against each other:

1. How much of the table is visible vertically. Obviously this was your major concern in finding the new layout. You want many rows to be visible on the screen at the same time, because you find extended vertical scrolling to be tedious. This is a valid concern.
2. How much of the table is visible horizontally. This is my concern. I want the complete width of the table with all columns visible at all times, even on monitors with less than 1440 pixels horizontally. The reason is that it is even more tedious if you have to scroll horizontally for every single row you want to examine.

For readability and usability of the table, for me the second issues weighs heavier than the first. Therefore for smaller monitors (or windows) I prefer the occasional line-wrapping over the mandatory horizontal scrolling.

Now, if I look at all columns it is clear that the "Date" and "Version" columns are always the same width, so they should be fixed, or they would wrap over every single time on a smaller monitor, which looks ugly. The "Category" and "Author" columns, while not always of the same width, are however within a relatively narrow band. It makes sense to fix them at the widest existing entry and assume that we have a reasonable sample of entries, and future entries won't get wider than that.

There remains the "OXP Name and Brief Summary" column, which does vary somehow in width of its entries. So, if we allow it to adjust and wrap, some entries will just stay like they are, only with less white space on the right side. And some entries may wrap over, depending on the monitor size. I think that's the most sensible solution, I only cannot code it off the top of my head.

[maik]

There remains the "OXP Name and Brief Summary" column, which does vary somehow in width of its entries. So, if we allow it to adjust and wrap, some entries will just stay like they are, only with less white space on the right side. And some entries may wrap over, depending on the monitor size. I think that's the most sensible solution, I only cannot code it off the top of my head.

Thanks, I really think we should try this one out and see how everyone likes it. Could someone with some better HTML skills than me please go ahead and do that?