Twic I Wishlist

This is a wishlist for improvements to Twic I. It's divided into four sections. Please add suggestions!

Features

These are changes to the technical foundation of the wiki which will affect (and hopefully improve) wikizens' lives.

Documentation!

Appearance

These suggestions are to do with the way Wiki Text is rendered into HTML, and so with the way things appear in a browser.

• When images are displayed, you have the option of providing an ALT attribute. On text-only browsers, the image is replaced with this ALTernative text. On graphical browsers, when the mouse hovers over an image, this text pops up as a kind of tooltip. However, Mozilla/Netscape have broken with this tradition and pedantically adhered to the HTML spec., which is that a popup will appear if a TITLE attribute is provided. Could this be added, even if only to set it as the ALT value? -AM
• Done. I have also added a special bonus attribute to indicate what i think of Mo Zilla and its smarmy standards-compliant ways.
• Means of starting a new paragraph without having to leave a line between them: it's really become a bit of a pain when I forget about this --TL What do you have in mind? If there's something simpler or easier to use and equally portable between different web browsers, we should have it, definitely. I don't think there is, though.
• The tech to make footnotes would probably be insanely complicated, but also fun. --WJR Footnotes would be cool. Yes, they might be insanely complicated, though. There is a school of thought that says that Footnotes Are Evil, though.
• For Wiki Pictures: left/right/centre/size formatting options. Why? -- TA Well, size isn't essential for those of us that have webspace of our own- we can tailor the picture or a copy of the picture to fit, I suppose, but on alignments, purely central aligned pictures leave a lot of White Space- one thing I rather like about HTML is the ability to wrap text around images. Or is there already a way to do this that I just haven't noticed? -- WJR
• Some means of indenting text for starting paragraphs and other cosmetic purposes. -- WJR Did you bring up 'cosmetic purposes' with the specific intention of enraging me? I would like to digress about Form And Meaning, but have spent my bile ... -- TA No, but enraging you is always a bonus... -- WJR Just tested and found that judicious use of tables allows indentation for quotations and the like without any ugly side-effects- good! However, can't see how one could use it for paragraph type indent. -- WJR
• Um, would it be possible, now that we have bold and italic in formatting, to allow for underlining at least for the purposes of headers? --TL Underlining is never ever appropriate in printed text (and before you ask, this counts). Also, on the web, underlining is a visual cue for links. However, keep your hair on for now - real, live HTML headings will be arriving shortly. -- TA
• (Done) Format Wiki Names with spaces between the parts, so they look like normal words. This might bugger up acronyms a bit. The solution is to insert spaces only before capital letters which are preceded or followed by a non-capital letter, so Science Fiction -> 'Science Fiction' but HG Wells -> 'HG Wells' and President Of OUSFG -> 'President Of OUSFG'; or something, anyway. NICE work here, Tom - the 'new look' makes page titles look more 'webpage' ish, not to mention easier to read. Is there any way to set exceptions for things like OUSF Gus and the like when we're creating pages in future, or ought we avoid that format? -- WJR At present, there's no way to make exceptions. There are three possible ways forward (as well as the obvious one way backward): modify the rule used to split Wiki Names up so that thinks like OUSF Gus and S Fnal just work, allow some kind of escape code to be embedded in Wiki Names to override the split-up, or just live with it and write Wiki Names that work with the rule. The first would be ideal, but i can't think of a better rule (suggestions from the algorithmically adept are welcome); i am loath to do the second, as it's messy and leads to some oddness (Would OUSF Gus be considered the same as OUSFG^us or whatever? If not, we have two pages with what appear to be the same name, and if so, we would inevitably end up with both spellings littered about the place.), and it just feels wrong; the last is obviously technically the easiest (do nothing!), and i think 90% of the problems can easily be steered round, but that does leave a number of pages whose names are hideously deformed. I'm not entirely sure what to do. Glad you like it, though. -- TA Well, it's a small number- they all come from the 'conjugation/modification of acronyms' school, and unless we run into anything that actually appears nonsensical because of it, or an easy solution presents itself, I'd vote for option three, since the benefits of the word separation thing we now have outweigh the few oddities. -- WJR
• An icon for the OUSFG Wiki! If anyone out there would like to craft a small (say 64x64, <5 kB) OUSFG icon, it could be plastered all over the pages
• Special URL schemes for ...
• various biological identifiers, such as Uni STS?, Gen Bank?, Swiss Prot?, etc (part of the shadowy Bio Twic I project)
• wiki pages; these could be wiki:FronPage (just like saying Front Page), wiki:FrontPage:23 (a particular version), wiki:WardsWiki.FrontPage (Inter Wiki), wiki:FrontPage@20030114154429 (the version at a particular point in time - that's a way of writing 3:44:29 pm on 14/1/2003, by the way)
• RF Cs? and jargon file entries
• Patents, eg <patent:WO9400046>, which might be rendered as <http://l2.espacenet.com/espacenet/viewer?PN=WO9400046&CY=gb&LG=en&DB=EPD>
• Maybe a Special URL scheme for Acronym Finder? (<http://www.acronymfinder.com/>, eg <http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=SF>)
• A search/jump box on each page, at the bottom (except it's already pretty crowded down there) Could just be on the Recent Changes or Front Page wikipages, where people go to anyway in order to navigate... --TL It would be extremely messy to put random HTML (like forms) on specific pages; Wards Wiki has a sort of way round it, but it's a hack. Having a little search box on every page would be better. As for crowding, well, maybe it's time for a little bit of Home Front On The Wiki around here. -- TA
• User-configurable Cascading Style Sheets might be cool (could use cookies or just pass around as a query parameter)
• Put borders around tables
• Make this good
• How about an accent facility? Now that we have Erdos Number and so the technomancers amongst us are also having to alter spelling to avoid accents. I gather HTML has this facility, but I've yet to find a description of how to write them in it. Twic with accents would be fun. -- WJR
• Recognise paragraphs starting with speechmarks as blockquotes.

Mechanics

These suggestions are to do with the fundamental mechanics of Twic I - things like how pages are linked, methods of navigation, stuff like that.

• Wiki History
• It would be nice if you can see who edited a page/what their changes were. The ability to see the changes to a page is on its way, albeit not for a while; it will come in once there's a versioning system behind the scenes, which is quite a bit of work. Seeing who made the change is harder, as it requires some sort of user identification: Wards Wiki does some stuff with cookies that i'm not wildly keen to duplicate, but it should be possible to, say, have a box on the page where you could 'sign' your edit. Neither of these is really very trustworthy, but that shouldn't matter. There are some wider philosophical issues attached to tying edits to people, though - it may detract from the feeling of wiki as a coherent website (insofar as that exists!). -- TA There are greater things in heaven, earth or cyberspace than are dreamt of in that philosophy. Face it, wiki is so changeable it's got a greater resemblance to a Web Log or a newsgroup than a website per se. Editing it for greater coherence's sake is OK, though. --TL We do need more editing; at the moment, the wiki's a bit like a graffiti wall, with people just spewing stuff out, whereas with some editing, we'd be more like a website, and might even have something that other people might actually want to read in six months' time. Given that we have these two operating modes, and that we only really need who-what-when tracking in conversational mode, i think signatures as we're using them at present are sufficiently good. After all, carefully tracking who said what is not a core mission of the wiki. Also, it would be a real pain in the arse to implement. -- TA
• Versioning ("what was the previous version of this page?", "how did this page look on 23rd September 1962?")
• Visible diffs ("how has this page changed?")
• History mechanisms or backups of some sort were mentioned. Sounds like a good idea --TL
• And how about formatting certain pages (pace Wikipedia) in order that the Front Page, especially as it's the 'jump-off page' now, can't be altered without a particular authorisation? --TL This is something i have occasionally thought about. There would have to be a generalised mechanism for locking pages, with locking presumably under the control of a single administrator (ie me); it's that central control i don't like: it's a Single Point Of Failure? at which incompetence, laziness or malice could really bugger things up. I'd rather find a way to reduce our dependence on particular pages. This is somewhat tricky, though, given that a certain number of pages do have special roles. Perhaps if everyone used their name-page as a homepage, the Front Page would be less important; however, that would probably make the name-pages less like other pages. Anyway, it's a suggestion to think about. -- TA
• Would it be possible to Wiki Name-ify, pace Wikipedia, non-camel-case words which it would be desirable to turn into Wikinames for the sake of clarity and correctness? --TL
• Possibly. This option is discussed under Wiki Name Wrangling. It breaks an ancient and fundamental tradition of wiki, though, and although this is not necessarily a bad thing, i'd want to be really sure before i did it. I suspect there is philosophising on Wards Wiki on this topic.
• Escaping of metacharacters. At present, it is not possible to use an asterisk, underscore, etc in text without generating formatting. Yuo canot escape or evar win!!! -- Jeff K? Whilst this has not been a problem, it is a slight irritation. The obvious way to do this is to use the Universal Standard Meta Escape Character, the backslash. Thus, backslash-asterisk would generate an asterisk, not toggle the boldness. Backslash-backslash would generate a backslash. Backslash-foo, where foo is not a metacharacter, would probably just generate a foo, as if the backslash were not there. This should also be useful inside tables etc, so that you can use vertical bars inside table cells (should you want to do that). This doesn't solve the URL-in-a-list-tag problem, but implementing backslash escapes properly would probably require the same rework of the rendering code that would be required to solve that problem anyway. Or something. (I made a small backspace escaping patch, who needs can apply: http://jikos.cz/~jbohac/goodies/twici_escape.diff ; Jirka B.)
• Escaping Wiki Names should make them plain text, avoiding the need for all that double-underscore business. Possibly, escaping non-Wiki Names should make them links, but this is far more iffy.
• Page deletion and redirection
• Deletion could easily be done by renaming. The best way to do this in the current technical framework would be to rename foo.twici to foo.twici.<timestamp>, so that multiple deleted versions can be retained and easily identified. However, this might conflict with the Wiki History scheme for files.
• More ways to find things; Wards Wiki has a full-text search, which is slow but useful, and a title search, which is 50% as good and 10 times as fast. Some sort of rocket-science based topological analysis would be fun, too (any Comp Scis? out there looking for a final-year project?). Note that Wards Wiki has a Visual Tour thingy, showing diagrams for relations between pages: might this be possible in a simplified form for here? --TL It's the generating the graphics which is a pain; Ward farms it out to another server which runs some graphics stuff, but i'd feel a bit cheeky using it for OUSFG Wiki too. Some sort of more textual thing might be possible. -- TA Now that the static portal page is about to push up digital daisies, can the original 'hop to page' search engine be put on a Wikipage of its own? --TL Note that LP was put off Wiki by the inability to find things on it... --TL
• How about Inter Wiki?
• Some way of getting a list of all the Dangling Wiki Names, ideally with a count of how many times they occur (and ordered by that count)
• Some way of getting a list of all the Orphan Pages? (perh as part of the Back Links Implementation, as pages w/o backlinks are obviously 'orphans')
• Consider having Sub Pages? as on IA Wiki?: <http://www.iawiki.net/IAwikiIA/SubPages>
• Email notification of changes? The correct way to do this would be to RSSify Recent Changes, Local Changes, etc, and then use or build external tools which send email notification of updates to RSS feeds.

Conventions

• Maybe we should have a By Author Convention?. For every author, we have a by-page (eg Arthur C Clarke -> By Arthur C Clarke?). We make one link from the author's name-page, and then link from the pages of books by that author ("A book By Arthur C Clarke?"). We do not link from any other pages, if possible. This establishes a mechanism somewhat like the category system: looking at the backlinks to a by-page shows you all the books by that author. The benefit is a simple and effective mechanism for finding books by author; the cost is more pages, more maintenance, more scope for errors, etc. Anyway, it's just an idea. I think I'm missing something. Can't you just look at the backlinks to the author page to find all the books 'by Arthur C Clarke'? Oh - I suppose this will find other pages mentioning Arfur as well. I don't see that as a huge problem. The other option would be to have a list of books on the author page, as is currently the case for, say, Greg Egan. -- NH Yes, backlinking from the author page works, but will get non-book pages too; as you say, not a huge problem. The list of books suffers from the crippling problem that it needs to be actively maintained. It's far easier to tag book pages than to update the author page. Plus, the author page might be better if it mentioned fewer books - say, if it just pointed to the definitive/typical/best ones or something.
• 'Twould be nice to have some kind of cross-referencing convention a la our trusty MH Zool 's guide to literary SF, but that's just a question of tidying up the backlinks a bit, really --TL Could you expand on this? The idea of cross-referencing is a little difficult for me to think about in a medium where links can be made so easily; it's like talking to a fish about water. Well, for example, could we have different Genre sub-categories so that people would know what sort of theme a particular book in someone's metalibrary fitted into, and could see what other books were recommended as follow-ons, as per IMDB? --TL If you want it, you can implement it. That's the beauty of Wikis. Unless I've completely misunderstood the system, you could just slap Category Homoerotic Quest Fantasy? (or even better: Category Homoerotic? Category Quest Fantasy?) at the bottom of any book desciption that merits it, and you're sorted...
• A page about Wiki Text which defines Twic I's formatting language (with examples etc) and explains the rationale behind various features (showing how they follow from the desire for simplicity, portability and unsurprisingness).
• The Twic I Wishlist page probably needs factoring into subordinate or spinoff pages - it's become a general repository for meta-discussion.
• Now, a Wiki Constitution would truly be a thing to behold.
• Somebody should really clear this page up. That would be me. -- TA Yeah, fucker.
• Duplicate entries about cleaning up the Twic I Wishlist should be removed.

Implementation Details

This section is for invisible technical improvements; if any of these were implemented, users probably wouldn't notice.

• Locking behind the scenes
• Use the First Class Filehandle Trick? and factor opening files into a single sub which can do sanity checks
• Versioning using diff
• Prevent race conditions on edits (locking is not enough; use a hidden version tag) Note that users have actually reported this happening.
• Make Back Links cheaper (see Back Links Implementation)
• Protect expensive searches (or all Meta Data??) from spiders (see Back Links Implementation)
• Use CGI.pm
• Do something more sensible when errors occur; in particular, handle 404s more gracefully. This is not really a technical change, but the end user should never encounter errors due to incorrect input etc, so it's not really user-visible.
• Emit an RSS feed (subtask 1: find out what RSS is; subtask 2: decide how RSS semantics map to wiki; subtask 3: implement it)
• Use relative URLs
• Move config to external files (make sure this is a good idea first); Special URLs would be the toughest (maybe use a TSV? file, with scheme in the first column, then a regexp for the path, then a template for building the URL; might need several templates for different styles of path, discriminated perhaps by how many capturing groups in the regexp capture something)
• Read in as much configuration as possible from external files. This would make deployment and management far easier. Things which could be parameterised: resource limits (?), file root, URL root, key + special pages, file extension (?), HTML templates (nice but hard), picture types (probably impossible), Special URL types + transformations (hard but vital)
• Use Mod Perl??
• Use the buffer library mentioned under Wiki Cache Problem
• Solve the Wiki Cache Problem. Solve it good.
• Suppress the empty em elements produced by use of the double-underscore-escape construct
• Use buttons rather than links for the actions at the bottom of the page; the HTML could look like:

<form method="GET" action="http://urchin.earth.li/cgi-bin/twic/wiki/edit.pl?page=TwicIWishlist">
<input type="submit" label="Edit">
</form>
<!-- or whatever -->

• Perhaps use http://isbn.nu/ for ISBN Special URLs. Good idea. Avoids the whole Barnes And Noble-No Amazon debacle altogether --TL -Update: Aw damn. Isbn.nu is actually run in cahoots w'Amazon. --TL
• Generate the action links from a list of action names, like the key pages list; eg "edit" -> a button labelled "Edit" which points to a script called edit.pl with a parameter page=<thispage>. This would allow the set of buttons to be modified more easily (either from the code, a conf script, or even by inspecting the cgi-bin directory to see what's there, which would be pretty cool).

Dustbin

These are possibilities which were mooted at one point but which now seem to be bad ideas.

• !-escaping of link state (including internally, eg Back Link?!s)
• User Name? functionality, like http://c2.com/cgi/wiki?UserName
• Consider the use of Structured Text
• An obbd Special URL scheme; this would be a reference to a beer in the Oxford Bottled Beer Database. It has the form <obbd:169>, where the number is the OBBD? Beer ID?. which would be entirely incomprehensible/useless to anyone not interested in real ale, Tom --TL Oh, absolutely, but they'd do no harm to such people merely by existing. I admit that i came up with this idea in a beer-crazed frenzy in anticipation of the Oxford Beer Festival, though. It's a feature that would be slightly useful, easy to implement, and a bit of a laugh. I'm probably not ever going to do it. -- TA Phew --TL

Unicode

γιάσου κόσμε

Category Wiki