As this is just a mock-up, none of the links are live. In the “Information”
box at the top, the headings would be category links (they would take you to a
category page like in Wikipedia, which would list all of the members of that
category), as would (some) of the values. (E.g., clicking on “operational”
would take you to a list of games categorized as operational.)
Please don’t make any judgments about this based on the markup you see if you go to “edit”. It is extremely grotty right now; a live version would have all of this extracted into a template so that anyone creating a page for a module would need only to fill in values for keys.
I would appreciate comments on the following things in particular:
Does this include all of the information we want it to include?
Does this include information we want not to include?
Is the information presented in an understandable way?
Also, since the the wiki is just a test wiki at the moment, feel free to try
making your own, or trying to improve this one.
The immediate thing that stands out to be missing vs the current site is the
player contact info. Names are there but their email links are not (unless
you left that out deliberately)
Another concern though somewhat off tangent is the presentation of the
overall website.
With this wiki, the phpbb forums and the main site itself we have 3 distinct
looks. That gives off the impression of slapstick design (i.e not good).
As a new user that comes along and seeing this inconsistency, I’d have to
wonder about the actual program itself (and they haven’t even hit
docuxxxx…ssshussh! ). Impressions count and that’s the first one they
are going to get
I copied the player names from the TLD Players page on the current web
site, but wasn’t logged in when I did it. If you do that, you don’t see
any contact information. Leaving that out was not deliberate.
I was planning to create (or have someone create) a common style for the
whole site; right now, I’m only trying to nail down the content.
First off, let me give my general impression, which is that this is a
better presentation order than the current pages.
Most of the information is there. The only thing missing is perhaps
some small note about the subject matter or other description. Also,
there should be a link to any other resources, but that should
probably go down with the module information.
What I particularly like is having the module download files near the
top of page, since that is really the “meat” of the module page. It
is the part that players will most want to get to, since that’s where
they actually get the module. Making that easy to find is a really
good idea.
I might try to make the top block a little shorter, perhaps by going
to two columns for the key-value pairs. That would leave vertical
room for the short description. Either that or add a paragraph for
the description to that top block.
I think the guiding principle, which it seems you are following, is
to put the items that are most in demand up front and easy to find.
Is the Topic field in the info box not enough? I struggled with how much
general game info to include here, as one one hand our purpose is not to
provide a game encyclopedia, but on the other it would seem a bit spare
not to give any such information.
That was exactly what I was going for. Glad you noticed.
For me, the height of the info box is about one line-height taller than
the picture of the box top. Mabye your fonts are a bit larger than mine?
No, it matches the image size for me, too.
But then I wondered if the image size was too big.
However, making a boxtop smaller would render it unreadable, so I
tried to think of other things to do with the vertical space.
I thought the most reasonable would be one of the following:
±-------------±----------------±-------------------+
| | Publisher: … | This game covers |
| | Year: … | the key battle of |
| IMAGE | Scale: … | the western area |
| | Players: … | … |
~ ~ ~ ~
~ ~ ~ ~
±-------------±----------------±-------------------+
±-------------±----------------±--------------+
| | Publisher: … | Scale: … |
| | Year: … | Players: … |
| IMAGE ~ ~ ~
| ±--------------------------------+
| | This game covers the key battle |
| | of the western area … |
~ ~ ~ ~
~ ~ ~ ~
±-------------±----------------±--------------+
It’s definitely good to have everything on one page. Having the Files up top is good.
I’d put a space for a general description somewhere below the Info box, though. Like Thomas’s second example, I think people will want some space to describe the game or put announcements of new files. I don’t think the Notes line in the Module Information section is prominent enough. It took me several scans over the page to even notice it was there.
There’s only enough room for a one-word Description for each file. Most files on the current site have about a 5-word description, so I’d give that more room. And for that matter, might as well spread out the Filename/Description/Size/Date/Compatibility columns some more, instead of scrunching them up on the right half and leaving all the white space on the left.
Regarding player contact information, of course having the names without addresses is not useful at all. The current site hides email addresses from non-logged-in viewers to prevent email address harvesting by robots. Can we do that with MediaWiki? In any case, Players and Contributors should be treated the same.
What’s the prupose of having a general description?
I was thinking we’d use a special version of the “Recent changes” page for
tracking new files.
If there were more than one sentence, it would be more noticeable.
The columns are sized to their contents. If there were a 5-word description
in the Description column, it would be wider than is is now. Also, I’ve
noticed that many descriptions on the site are needlessly verbose—e.g.,
the word “file” occurs often in them, but how often is it informative?
The point of that is so that the text in the version number row clears all
of the columns.
For an example of what this looks like if we don’t do it that way, look here:
I’ve had a look at what’s involved here, and there four things to harmonize:
phpBB
MediaWiki
Bugzilla
custom pages
phpBB, MediaWiki, and Bugzilla all support skins, so the task is finding
or creating skins which are uniform across them. I expect that MediaWiki
or phpBB will be more complex to create a skin for than Bugzilla, so
what I’m thinking of doing is finding a MediaWiki skin which is close to
what we want and then creating phpBB and Bugzilla skins to match. The
CSS for the custom pages would be some subset of the CSS which was in
the skins.
What it does is convert the contents of mailto links to their corresponding
HTML entities (including the “mailto:”!).
This would make email addresses visible without logging in, which is a
change from the way it is not, but it would still defeat any address
harvester which was looking for mailto links or ‘@’ or any such thing.
Logging in to see the addresses also fairly easy to defeat. It would take
a moderately sophisticated address harvester to recognize addresses hidden
in this way, and there are so many addresses out there which are not
obfuscated at all that I doubt it’s worth the trouble for the harvesters.
The entire extension is in the Code section of the page.
These are neither clickable nor copyable.
Those are just asking for abuse, and prevent people from using their
preferred email client.
I don’t like the EmailAddressImage solution. Pretty painful since it’s not even copyable. Guess I’d rather go with the EmailObfuscator, although I doubt it would do much good. Surely the harvesting bots know enough to decode any HTML entities in the pages they download. I kind of get the sense that the harvesting battle is lost in any case, as it seems impossible to keep your address away from spammers these days.
For the template, I still think a more prominent general description is useful. On the existing site, people use it to distinguish between different adaptations of the same game, or to describe a self-published game, or even to advertise for helpers. Of course, it’s easy to add some text to the wiki page, so it doesn’t absolutely have to be in the template.
I’m not so sure about that. If you need to harvest a hundred million
addresses, then decoding every HTML entity just to see if it turns a string
into an email address is going to be a significant cost. My guess is that
they’re not even bothering to parse the HTML properly, they’re just doing
something like grepping for ‘@’ or ‘mailto’.
I wanted to substantiate this by having a look at some email harvesters,
but there seem not to be any open-source ones available for inspection.
If we really wanted to settle this, I could set up a page containing some
plain-text addresses and some HTML-entity-obfuscated ones and then see if
the obfuscated addresses receive spam when the plain ones do.
I would say that trying to keeping your address away from spammers isn’t
even the right approach. I’ve been using this address since 1998 and I’ve
never made any attempt to conceal it from spammers, because I don’t want to
forgo the benefits of people being able to contact me. 'uckelman@nomic.net’
occurs on thousands of times on pages pages I host myself (mainly list
archives), without even counting all of the occurences on pages I don’t
control. As a result, I would be surprised if there is any spam list which
doesn’t have my email address on it. Nonetheless, I get almost no spam in my
inbox—this month, I’ve seen two pieces—due to good filtering, both at
the mail server and mail client levels.
I think real question is whether it’s worth my time to write a custom
extension to get exactly the same behavior we had before.
I agree with you that ISP filtering of spam is good enough these days that we don’t need a custom solution. Put in the obfuscator and call it good enough.
). Impressions count and that’s the first one they