Oolite Bulletins

mcarans wrote:

Eric Walch wrote:

So I still use IE5.1 when forced to use internet from that laptop.

Out of curiosity, how does the table look in IE5.1?

I have no IE 5.1 at work, but I have 5.2 installed that does work with OSX.

At first sight the page looked identical, but on second sight I noticed the sort icons did not show. The icon with extra author names does work though.

At least the layout itself is proper with that dinosaur.

All this talk of table widths almost makes me wistful for the days when the net standard was 80 characters wide...

So, what do we do?

The table as it is has a fixed width of 1080px. However, it doesn't stand alone on the page, but there is the navigation bar to the left which also consumes a certain amount of pixels. I can't count them, but I guess it's about 170. That makes for a total required width of 1250 pixels to view the page without horizontal scrolling. In other words, by default it doesn't work on any monitor with less then 1280 pixels of horizontal resolution. That can't be good. And on bigger monitors it only works if you are viewing it on full-screen, which I never do, because I like to have some visible workspace around my browser window.

Making the font smaller is no solution, it is already smaller than in the predecessor table and hardly readable as it is. The rather long one-lined description column in small print isn't exactly reader friendly in the first place.

I don't understand the obsession with onelinedness. It is merely one of several parameters that make a table usable, and in my humble opinion not even a major parameter.

Commander McLane wrote:

So, what do we do?

The table as it is has a fixed width of 1080px. However, it doesn't stand alone on the page, but there is the navigation bar to the left which also consumes a certain amount of pixels. I can't count them, but I guess it's about 170. That makes for a total required width of 1250 pixels to view the page without horizontal scrolling. In other words, by default it doesn't work on any monitor with less then 1280 pixels of horizontal resolution. That can't be good. And on bigger monitors it only works if you are viewing it on full-screen, which I never do, because I like to have some visible workspace around my browser window.

There is a way to remove the left-side vertical navigation bar by adding a bit of script to the Wiki...pressing f11 will expand the table to the full screen width. I think this may be the answer but will need to investigate further.

Commander McLane wrote:

Making the font smaller is no solution, it is already smaller than in the predecessor table and hardly readable as it is. The rather long one-lined description column in small print isn't exactly reader friendly in the first place.

It's actually a different font, not a smaller one.

Commander McLane wrote:

I don't understand the obsession with onelinedness. It is merely one of several parameters that make a table usable, and in my humble opinion not even a major parameter.

The obsession is not with onlinedness, more to restrict the space available for the summary to limit overlongedness. I do personally think it looks much nicer with one-line-per-entry though, and as we've put a lot of work into this I'd like the end result to look professional.

I have now experimented with it quite a bit. Even with consulting a CSS manual and trying all sorts of things, I can't get the description column to wrap. All I can achieve is to make the third column "eat" it as I make my browser window smaller. Which I find unsatisfying as well.

Smivs wrote:

There is a way to remove the left-side vertical navigation bar by adding a bit of script to the Wiki...pressing f11 will expand the table to the full screen width. I think this may be the answer but will need to investigate further.

As far as I am concerned this is not the answer. Disabling or altering the Wiki format because an entry doesn't fit the format sounds silly to me. The entry should fit into its environment, not the environment cut down for the oversized entry.

Smivs wrote:

Commander McLane wrote:

Making the font smaller is no solution, it is already smaller than in the predecessor table and hardly readable as it is. The rather long one-lined description column in small print isn't exactly reader friendly in the first place.

It's actually a different font, not a smaller one.

Well, it definitely looks smaller than for instance the font in the table above on the sandbox page. And readability is king.

Smivs wrote:

Commander McLane wrote:

I don't understand the obsession with onelinedness. It is merely one of several parameters that make a table usable, and in my humble opinion not even a major parameter.

The obsession is not with onlinedness, more to restrict the space available for the summary to limit overlongedness. I do personally think it looks much nicer with one-line-per-entry though, and as we've put a lot of work into this I'd like the end result to look professional.

I am not in any way denying or degrading the work you have put into it, please believe me. "Looking nice" and "being easily readable/usable" however are not the same thing. At the end of the day only the readable and usable result will be a professional result. And, as I said before, in my opinion the need for horizontal scrolling restricts the usability more than the occasional line-wrap.

i guess we're all gonna argue over columns etc, it all comes down to personal tastes and there's no right or wrong. having looked again, i'd favour getting rid of the date and the version columns.
the version, i've been over earlier - if there's anyone running a version of Oolite that's not the current one, i'd question why? and more to the point, i'd question why would we want to accomodate them? now that sounds harsh, but consider that
(a) lots of people worked damn hard to get the latest version out
(b) the latest version will have new bells and whistles, so why would you NOT want it?
(c) It's free and it's a simple download, so what's the excuse?
support for earlier versions should be in the forum. this table should be for the current release only : Old OXPS that might bug should be checked by the authors, old OXPs that DO bug should be removed until fixed, next OXPs written in trunk should not be officilally listed here till the code makes base.

As for the date, well, who cares? if i'm looking for something i'll be hunting for the name or author, or just browsing descriptions, everything else can come when i click the page and go to the link.

I've made the table the way Cdr. McLane wants it so people can have a look at it. You can see just over half as many OXPs, but all columns even at the lowest resolution (I hope).

With wrapping, there is no limit on text, so I foresee if this format is kept many of the current 2 liners becoming 3 liners, then 4 liners till we have something resembling the alphabetic pages again because subconsciously authors are likely to compete on writing the longest summary so their OXP gets more attention.

It is possible to set the width to 100% to expand the table for larger resolutions, but then OXP authors writing summaries will not see how things will look for Cdr. McLane and others using lower resolutions.

Conversely, I see myself using the date column a lot: When I return even from just a few weeks away from Oolite I want to quickly see which OXPs changed/are new. The version column I could do without. Same for the author column. It's interesting but I sometimes wonder if it is actually more than a vanity column.

Regarding column widths: I'm actually with CMcL here: keep all but the name+summary column fixed and allow the other to grow/shrink horizontally, wrapping around if necessary. Seems the easiest way to accommodate for small to large screen sizes without having to scroll horizontally.

mcarans wrote:

I've made the table the way Cdr. McLane wants it so people can have a look at it. You can see just over half as many OXPs, but all columns even at the lowest resolution (I hope).

I've just had my first look at this. It's not too bad really, the mix of one and two line rows isn't pleasing to the eye, but it clearly addresses the scrolling issue successfully.
It now looks a bit like the old one which wasn't great but I could live with it, so my honest and dispassionate opinion on the look is "Not great but I could live with it."

mcarans wrote:

With wrapping, there is no limit on text, so I foresee if this format is kept many of the current 2 liners becoming 3 liners, then 4 liners till we have something resembling the alphabetic pages again because subconsciously authors are likely to compete on writing the longest summary so their OXP gets more attention.

This, on the other hand I do have a problem with. Mcarans is absolutely right, and the table will end up not only looking a bit like the old one, but acting like it as well.
Using this layout removes the cornerstone of the table's strength and durability, the ability we'd built into it to self-limit. By specifying the width of both the table and columns, we limited the amount of space available for the summaries, thus keeping it in check. Removing this feature effectively dooms it to going the same way as its predecessor. If we do this, it will be a great opportunity lost, and frankly we'll just end up where we started! Might as well just keep the old table.

Edit:- You'll have noticed that I do feel quite strongly about this.
When we started this project I really thought that we had the opportunity to make something better. And I think we succeeded. We didn't always agree on things and I think all three of us would have done something different had we been working on our own. But in the true human spirit we co-operated, collaborated and gave ground when it was in the best interests of the project to do so. And the end result was broadly successful.
There are clearly problems with it, most noteably what I call the 'scrolling problem'. The table is a compromise between many conflicting requirements and there will always be difficulties in situations like this. And whatever is agreed, some will be unhappy. Such is the way of the World.
Rather than rushing to a decision, I think this might be a good time to step back and consider the situation for a short time. I still feel that there is a solution to the 'scrolling problem' that doesn't involve castrating the table at birth.
So I'd suggest sitting on this for a day or two while we look for a solution.
Whether we find one or not, we can then decide whether to either go ahead with the proposed new table, go ahead with Mcarans's new revised table or stay with the old one. This decision would be best made by a Poll of the Members.

Thanks for the change, mcarans, although it was not yet what I meant. But starting from it I could now do what I wanted from the beginning: The table is always monitor-filling, and the second column is flexible. That means that on my setup currently about one quarter of the OXP use a second line. I can live with that.

Please have a look how it looks on your system. And feel free to revert, I just wanted to show what I meant. Actually I first c&p'd the whole table, so we could compare two versions. However, by doing so I reached the edit limit of my system. When I wanted to submit the change, nothing happened and I got a time out error after 30 seconds.

Ok, now look what happens when a new OXP author comes along and writes a long but not overly verbose summary which looks ok at his resolution of 1980 x 1080.

There's nothing wrong with it - it's almost plausible. Are the wiki police going to come get him - give him a cease and desist notice for writing about his efforts?

Let's say that for the first month, the wiki police tell every OXP author who transgresses to shorten their summary. By month 2, the wiki police lose interest after arguments with authors and the summaries creep up in length, first a few words, then a line, then 2 lines. No one can be bothered with it as noone wants to be the wiki police anymore.

Each time, the next guy that comes will writes one word more than the previous author. Until in a year's time, what do we have?

maik wrote:

The version column I could do without.

I agree. It will probably be very difficult to maintain this column when a new Oolite is released. Who will do all the testing for compatibility? Most oxp's will probably be compatible but you never know and the author is not always around.
When a version column is used, it seems better to me to leave the entry blank by default (and not 1.74). Only use that field when there is a know maximum version.

Either because the oxp has an internal requires.plist that defines a maximum version, or because its know to be no longer compatible with current Oolite. That way you won't give false expectations when a new Oolite version is released. Blank just means it should be compatible with the latest Oolite version.

mcarans wrote:

I've made the table the way Cdr. McLane wants it so people can have a look at it. You can see just over half as many OXPs, but all columns even at the lowest resolution (I hope).

Looks great! In contrast to our previous version, it even works on the iPhone

The overly long test entry is a very good illustration of where this could lead though. I don't have a technical solution that prevents it but I favour the table's new flexibility over the old safety net.

A "social" solution could be this: We do have a number of spam assassins, maybe some volunteers could be ramble/prattle/? assassins when things go overboard. Should be ok if there is a gentle reminder above the table that asks people to keep it short, see earlier suggestion above.

A "social" solution could be this: We do have a number of spam assassins, maybe some volunteers could be ramble/prattle/? assassins when things go overboard. Should be ok if there is a gentle reminder above the table that asks people to keep it short, see earlier suggestion above.

I think this will work in practice... that's the beauty of a Wiki. As long as there is a reminder on the page so that if there ever is an edit war, you can decide which edit is closest to the guidelines.

Overly-long entries is one debate and dealing with alternate screen widths is another, and there needs to be a solution to both - looks like widths might be fixed now?

The absence of horizontal scrolling is what really works for me.
Everything else seems nicely functional… I like the idea of ‘prolix police’.