Multi-User TiddlyWiki

TiddlyWiki MU is what I’m calling – in the absence of an official name – an effort within Osmosoft to pull together a bunch of work into something that will be very useful in the enterprise and beyond. You could also call it “tiddlywiki as a service” or “multi-room tiddlywiki”. Similar to Wikia or WordPress MU, you can spin off a new multi-user instance with a “single click”. This is “MU” in the sense that there’s already a TiddlyWeb-backed TiddlyWiki product (TiddlyWebWiki). The value-add of TiddlyWiki MU (or whatever it ends up being called) is that you can make a new instance of such a thing without being a system administrator and without going through the effort of building it on the server. This is exactly like the way WordPress MU lets you spin off a new blog without having to set up a new instance of WordPress on the server.

In addition to the ease of spinning off new instances, there’s an important side benefit from this architectural pattern: synergy. From a user’s perspective, they only have one URL to remember/bookmark/share/link; once at that URL, the system can helpfully guide them through the different instances they have access to. Also, it would be possible to make content that’s used across different rooms. For example, give each user a private bag of tiddlers and they could use it to set their global preferences (with the right UI).

The whole thing is an open-source server, so an enterprise can just download it, deploy it, and let a thousand flowers bloom as users spin off new instances and do what they will. The really important thing here is that tiddlywiki is not just a wiki, but a framework for web apps. Room admins can easily perform customisations like changing the stylesheet; or go so far as coding up Javascript plugins to radically alter look-and-feel. More importantly, they can update the room’s recipe to include a bags of tiddlers sitting elsewhere on the system. That bag might be the TiddlyDocs system for instance, if they are interested in collaborative document publication, or it might be TiddlyGuv if they want an open-source governance system. They can then fine-tune those systems according to their own needs.

Here is a rich user story (a rich user story is like a regular user story, but it deliberately includes detail that a “pure agile” developer might object to as “getting ahead of yourself” , You-Ain’t-Gonna-Need-It, or unverifiable; while those objections are valid reasons not to use the story as a direct input to coding or task breakdown, and while rich visions are inevitably too premature to turn out into accurate forecasts, they do help to prove you’re heading in the right direction, to motivate user-centric developers like myself, and to illustrate what you’re doing to people outside the project) …

(cue dream sequence)


Jimmy is a moderately experienced TiddlyWiki user and wants to make a room for the enterprise’s music club to collaborate on compositions. So he logs into TiddlyWiki MU, hits “New Room”, and creates a room called “musicians”. He then sees the new room – a vanilla TiddlyWiki with a list of users down the side: currently, just Jimmy, with an Admin icon beside his name. He ignores the “Invite Users” button for now so he can concentrate on setting up the room. The groups wants to put out compositions as collective anthologies, so he decides TiddlyDocs will form the basis of this room. Thus, he clicks on “Manage Room” and a lightbox appears. It shows him the technical detail of the room on one side of the dialog – the bags that make up the room’s recipe. And on the other side, he can search and browse for new bags. He navigates to “tiddlydocs” bag and hits the “Add” button beside it. It now appears on the top of the room recipe.

Dismissing the lightbox and reloading, the “musicians” room is now a vanilla TiddlyDocs. He clicks on the backstage button on the top of the page and edits a few tiddlers – SiteTitle, SiteSubTitle, and ColorPalette, to give the room its own identity. He also needs a way for the participants to enter musical compositions. Luckily, he already has a standalone TiddlyWiki for music composition, with a Music plugin in it. From backstage, he pulls up the Import dialog and uploads the Music plugin from there. For each imported tiddler, there’s a dropdown showing the bags he can import it into (“musicians-config”, “musicians-comments’ etc). He indicates it should go in the musicians-config bag. On reloading the page, he finds something is broken – he can’t add musical notes from the TiddlyDocs editor. It’s time to call a friend …

He clicks “Invite Users” and up pops a modal dialog where he enters the email address of Dwight Doomore, a TiddlyWiki expert he’s fortunate to know. He checks the “make this user an admin” box and in the optional message area, explains the problem he’s having. Dwight clicks on a link in the subsequent email and he’s up and running inside the slightly broken “musicians” room. Donning his cyber-shades with Matrix-like precision, he proceeds to create a new plugin tiddler and monkey patches the Music plugin functionality so it plays nicely with TiddlyDocs. Then he tests it by writing up the first new composition, pulls up the user admin panel to remove himself from the room, and replies to Jimmy that it’s all taken care of.

Pleased with the result, Jimmy writes a few compositions, re-arranges them using TiddlyDocs’ tree control, and adds a little text. Instead of using “Invite Users”, he just mails his colleagues the URL of the “musicians” room. They each visit the URL, indicate they wish to join, and a few days later, Jimmy jumps into the user admin panel, where he can accept their requests to join. Now they can all work together on different documents within the one room, and TiddlyDocs provides enough functionality to control how the final copies will be published.

Six months later, the first “enterprisey musicians” composition book is printed and bound.


A single TiddlyWiki MU server has the capacity to facilitate a thousand stories like this, each of them with its own unique characters and quirks. There are plugins for voting, blogging, commenting, structured writing, quizzes, graphics, social bookmarking … it will be fun to see how users deal with all that. Most likely, it will follow the usual pyramid structure:

  • Many users will just create a vanilla room – plain old (multi-user) tiddlywiki. Of these, some will just make it a private scratchpad for themselves and never invite anyone at all.
  • Some users will make the room become a vanilla edition of a specialised application for their group to work on. e.g. collaborate on publication-ready docs with TiddlyDocs; collect and annotate websites with Scrumptious; brainstorm and vote on innovations with New Ideas.
  • A smaller number of users will customise the config tiddlers; pull in extra plugins; build new room-specific plugins; or attempt to combine multiple bags.
  • An even smaller number of users will have to deploy a standalone customised server, perhaps deploying a customised edition of TiddlyWiki MU with certain server-side plugins and configurations. This is the kind of thing you might do if using TiddlyWiki MU for a hardcore, full-fledged, 110% uptime, supported to the teeth, enterprise web app. You’d perhaps run a pilot on the regular TiddlyWiki MU server and then perform a (relatively effortless) migration onto its own dedicated server. Or a power user might just hand-configure a TiddlyWeb instance from parts. (This is where we get into “TiddlyWeb as a generic RESTful server” territory.)

The first case is already well-supported by other wiki platforms, so it’s nice and all being open-source and TiddlyWiki-based, but not really the killer app. The second is really the sweet spot when it comes to optimising user experience in the short term. We’ve spent a lot of time at Osmosoft thinking about how to deploy “TiddlyDocs” as a standalone package. That’s still interesting, but I think it’s a lot more interesting to ask how to deploy TiddlyWiki MU as a standalone package, and then let users go into web app and make a new “TiddlyDocs” instance with one click. The third case is supported by the general TiddlyWeb model and doesn’t need any special optimisation at this stage.

[There's a thread about some of this stuff on the mailing list, so I've switched off comments to keep the conversation in one place.]

Tablets this Time Round are Different, Really

Convincing argument that it really is different this time round, compared to the days of “pen computing” and windows tablet edition at the start of the decade.

Microsoft always loved the stylus, but most people hate it. Apple and others understood that actually touching the screen is far more appealing than using some funky pen. And touch requires an entirely different user interface, which Microsoft was unwilling or unable to build into Windows until Windows 7. The casual observer might believe that the usability difference between pen and touch is small. But using a pen is an unnatural act, one that until very recently only a tiny minority of people ever engaged in. The psychological payoffs for using a pen on paper are the tactile feel of the paper, the instant feedback of the trail of ink and the physicality of stacks and files and binders of paper notes. Pen-based computer systems don’t offer any of those payoffs.

Touch is one of seven reasons cited. Others include the rise of e-readers, HD video on demand, app stores, and mobile-specific operating systems like Android.

A further reason would be improvements in soft keyboard technologies. That a soft keyboard could work, as on the iPhone, was a surprise to many; we probably won’t see those funky projected keyboards taking off any time soon. While some will say the tablets aren’t for performing serious work, everyone needs to type occasionally, at least to perform a web search.

Another reason is battery improvements, though we’re still a long way off from being able to play HD video, surf the web, and chat on skype, simultaneously and all day long.

Great, now we have all the reasons in the world. Unfortunately, we don’t have the CrunchPad anymore and the Apple rumour is just that. Will tablets really take off? For all the arguments, there remain some unanswered questions.

Most important, the form factor; although lighter and thinner than ever, they are still awkward to hold, maybe awkward enough for only geeks to love and certain professionals to tolerate. This is an area where Apple surprise us just as they did with the MagSafe power adaptor. It was innovative, unexpected, useful, intuitive, and a product of the physical world rather than the digital world. They’ll do well to repeat that feat with some kind of stand for the rumoured tablet.

The other thing is connectivity. I can’t see these taking off in a big way unless they ship with a 3G sim card, like the Kindle. We’re finally entering an era of more SIM cards than people and it makes a whole lot of sense – at least among retail consumers – to treat bandwidth like oxygen, instead of having to bash wifi into working for us. It’s true that wifi itself works well these days – the client detects the type of encryption and asks for a password. The problem comes when it’s restricted, i.e. a hotel has to give you a special password or you have to pay for it via a website. That’s where the friction comes, and it gets even worse with these systems that proxy everything and kill the session when you leave the browser (say, to send a tweet from a twitter app). Many of us will still need wifi as bandwidth isn’t ready for high-end uses like HD video – and also while data roaming charges remain stiflingly high – but a built-in sim card is the only way forward as the default mode of connectivity. I’m currently paying £7.50 per month (~ $12) for 3GB/month download, and came with a new USB modem. At a rate like that, it’s a no-brainer for tablets.

What’s New in On-Demand Javascript? ScaleCamp Presentation

These are the slides from my ScaleCamp presentation, covering various techniques for various styles of On-Demand Javascript, including Script Islands, “async” and “defer” attributes, and library support.

One of the interesting things at ScaleCamp is that many of the folks there are dealing with third-party advertisers and analytics providers. This leads to very different on-demand Javascript drivers from those of us mostly dealing with enterprise web apps. If you’re a small fish in a big pond, you’re pretty much held hostage to the script tags of leading advertisers and trusted analytics companies in your industry; if they serve the script slowly, it blocks your page from loading and therefore messes with user experience. That’s why some of these new techniques are so critical, notably the dynamic async script tag technique the Google Analytics came out with at a very timely moment, just a couple of days before this presentation.

Design Pattern: Script Islands

“Script Island” is what I’m calling a design pattern I alluded to here. The pattern is to embed Javascript in your HTML like so:

  1. <script id="greeting" type="x-deferred-script">
  2.   alert("this is my script - it's eval'd on demand");
  3. </script>

When the page loads, the browser should say “I don’t know what ‘x-deferred-script’ is, and therefore ignore the concents of the script tag. You eval it manually later on, using something like eval($("script#greeting").html()); This is similar to Google’s trick of embedding Javascript in comments, but has the additional benefit of keeping Javascript where it should be, in a script tag. This way, it plays nicer with code editors (e.g. Vim happily handles syntax highlighting) and analytical tools. (Technically, those tools should probably do the same as browsers and not treat anything inside a script tag as Javascript, but fortunately for us, they do.)

Script Islands are useful in the following situations:

  • With a complex web app – lots of Javascript – where you want it to load quickly and without lots of processing or round-tripping back to the server. Sometimes, it’s a better user experience to load the lot in one go, show something, and eval() the rest of the Javascript once the basic app is running (perhaps in anticipation of a separate “page” or another part of the application). This is a special case of Predictive Fetch; it makes sense Google would use (a variant of) Script Island for the mobile edition of GMail, where round trips to and from the server are expensive.
  • With a single-page application (SPA) like TiddlyWiki, where all the code is inside the HTML file. Each of the script islands is a separate module, and a microkernel is responsible for loading the scripts according to different rules. For example, the scripts might contain “depends” attributes to declare they depend on other scripts, so the microkernel sequences the script loading. Or another scenario might be that the user has some control over which scripts get loaded; instead of deleting the other scripts from the file, you keep them around in case the user wants to repackage the SPA, with a different set of scripts.

BTW I originally used <script src=""> to trick the browser into not evaluating the script tag’s innerHTML. Thanks to Jeremy for coming up with the more elegant alternative of a type=x-tiddler (which I stated above in the more generic form type=x-deferred-script).

Happy Birthday, Blog

It’s five years and a thirty-seven minutes today since I hammered out those momentous first words on this blog:

FP! Garbles to ya! Doh, forgot this was my own blog for a second!

I started the blog primarily as a space to host podcasts. How irony!

It’s been a blast. Great way to reflect on things, get feedback, etc etc, you’ve heard it all before about blogging anyway, but it’s true. Thanks to everyone reading this.

I must especially thank James Robertson, whose talk at SPA 2004 helped explain what blogging is really about.

Update: Digg celebrates its fifth birthday. I never noticed Digg started the day after this blog. If only I’d added voting …