usual live blogging caveats – spelling errors, messy, etc etc
@premasagar is visiting the Osmoplex today (thanks @jayfresh for arranging it) and is taking us through his work on iframes, widgets, and sandboxing. I’ve realised we could perhaps be collaborating as my jquery-iframe plugin is so close to his. Different emphases, but much overlap.
GitHub is where you can see what he’s been working on. Basically, this guy is a guru on all things iFrame. In particular, all the quirks around squirting dynamic content into iFrames, as opposed to pointing them elesewhere using “src”.
QUOTE OF THE DAY
“sqwidget is my tiddly”
BACKGROUND – THE EMBEDDING PROBLEM
In patternesque speak, the basic problem is:
Problem: You want to embed 3rd party content into another site.
Forces:
You want the 3rd party content to have its own style
BUT it will inherit style from the parent page
SOLUTION 1
IFrame
Works great (in fact, I’m using it in my TiddlyWiki playground app, to be documented at some point, and is similarly used in Jon Lister’s TiddlyTemplating.
The problem is you sometimes want the widget to jump out of the iframe, e.g. a ligthboxed video. So …
Basically a CSS reset, but whereas CSS resets will only handle browser defaults, cleanSlate blats everything! This is exactly the kind of thing I was looking for when I was trying to cancel out tiddlywiki styling. In that case, I was flipping the entire page back and forth, so I could just cheat by removing stylesheets and re-add them. (Prem pointed out there’s a “disabled” attribute on style tags – true, so I should really use this instead, assuming it’s portable, which he thinks it is.)
Problems:
- Difficult to maintain CleanSlate library, because new CSS stuff and browser quirks keep coming up
- IE6 and IE7 don’t support “inherit”, so need CSS expression.
- When using Javascript to interact with CSS style properties, e.g. slideDown(), these will override CleanSlate. The solution is to set the “style” attribute with !important, but it becomes an arms race!
- Doesn’t solve iFrame security model
SOLUTION 3
Inject (aka squirt, inject; summary) content into a fresh iframe.
The content comes from the widget site. The sqwidget library injects it. This resolves the tension with wanting independent CSS on the same page. If the sqwidget library is running on the host page, it could even (potentially) lock down capabilities, i.e. do Caja-style sanitisation.
Sqwidget also does templating, using Resig’s micro-templating. (That thing’s getting to be very popular; I’m using it myself in Scrumptious via the UnderScoreJS library after @fnd gave us a talk about them.)
Also, prem is playing around with the idea of a div, with custom (data-*) attribute pointing to the third-party URL. You could put inside it “now loading” and then the script tag will pick those things up and load them.
Various points:
for content-squirting into the iframe, you should be setting doctype, otherwise IE will load in.
There have been a dizzying array of Tiddly* products spun off recently. I’m talking merely about the core infrastructure stuff rather than applications like TiddlyPocketBook. We’re starting to get some convergence within the team, as we’re working on a high-level product called TiddlySpace. It’s basically the manifestation of earlier discussion too.the ideas we were discussing earlier. Similar to WordPress MU or Wikia, you’ll be able to spin off new TiddlyWikis at the click of a button. The server itself is open source, so you can host it in your own enterprise or on your own server. And because TiddlyWiki is nowadays an application framework, not just a wiki thing, spinning off new instances means composing new applications.
Pretty much all the applications we’re working on right now are intended to run on this infrastructure. Many will run in standalone, file-based TiddlyWiki, as well; i.e. the whole server-sidedness and user authorisation is a completely separate deployment concern. Which is an awesome way to develop. I recently realised we’re about the only people in the world who primarily develop file:// based web apps! That they will magically work as multi-user, server-hosted, apps too is certainly a boon for the Tiddly* model.
Anyway, what are all these Tiddly* products Osmosoft’s been working on, and how do they lead up to TiddlySpace? Below is the universe of products we’ve been working on – if all this seems horrendously complicated at first glance, note that most users will only ever see one thing: either TiddlyWiki or TiddlySpace, and even that may be invisible to them if they are using certain high-level applications. Here, I’m just describing the various components we’re working on to pave that path. It’ll all be nice for users. Trust.
TiddlyWiki – This is the original client UI. It’s a web app fitting inside a single HTML file – HTML, CSS and Javascript all together. It can run on a file:/// URI, which means you can store TiddlyWikis on your local drive, a USB drive, or a share drive … or a http:// URI. In the former case, thanks to some very clever and still-obscure browser hacks, you can make edit the TiddlyWiki and save changes. TiddlyWiki is, at its heart, a personal scrapbook, where you can easily gather and manage free-form bits of content (”tiddlers”). However, some of these bits can include CSS or Javascript, meaning that you can actually start building powerful applications with it and using the underlying tiddlers as a kind of scaffolding. These applicatons can be useful for individuals, but we’re still limited to a single user working on their own hard drive. Hence the need for server-side products (see below).
TiddlyWiki 5 – This is a major in-progress upgrade of TiddlyWiki, a complete rewrite, the biggest overhaul in its 5 year existence. There are some much-requested features: follows graceful degradation principle so that the TiddlyWiki5 presents nicely to search engine bots and users with Javascript turned off; includes rich text editing control; SVG graphics; embedded images (with the IE6-compatible MHTML hack); better readiness for server-side integration (e.g. the possibility to track revisions). And yes, all of this in a single HTML file.
TiddlyWeb (low-level) – This is new RESTful server-side component we’ve been building at Osmosoft for persistence, where each Tiddler has its own URI; it’s similar to CouchDB and other NOSQL frameworks; the main difference is it provides extreme flexibility on all manner of things like authentication and storage and presentation formats, and will mostly be invisible to users as we’re building higher-level abstractions on top of it. Also, the underlying data model is that of tiddlers, which means a title, text, list of tags, creation/modification info, and key-value fields (many NOSQL frameworks will have similar document models, but none exactly matching the Tiddler data structure that has always been present in the TiddlyWiki client UI). For most people, TiddlyWeb is best considered as a powerful component further down the stack than what you actually interact with. You’d only need to know about it in detail if you were trying to do powerful admin things, or change the code, on something higher-level like TiddlySpace; or if you wanted to build something equivalent to TiddlySpace; or you were trying to use it in a kind of NOSQL server capacity.
TiddlyWebWiki (low-level) – This is a set of plugins for TiddlyWiki that help it talk to TiddlyWeb. It “hijacks” (intercepts) calls like store.saveTiddler() so that instead of saving to the local drive, it will upload to the TiddlyWeb server.
TiddlyHoster and TiddlyConsole These products will probably converge. TiddlyHoster is a first-cut at the TiddlySpace concept, an inspiring product mostly built by @cdent and cobbling together various plugins. You can try it out now at http://hoster.peermore.com. It’s a fairly direct exposure of the TiddlyWeb bags and recipes model. TiddlyConsole (formerly TiddlyRecon) is similarly a bag and recipe and user mangement tool, with more emphasis on admin usage than that from end-users. We hope the essence of these tools can be incorporporated into TiddlySpace to support power users.
TiddlySpace – This is a higher-level web app, building on TiddlyWeb, to make it easy for folks to spin off new multi-user (or single-user) TiddlyWiki instances. This is really the most important piece, and the one everything’s been leading up to, when it comes to Osmosoft’s mission to get all manner of web apps running inside the enterprise, and will hopefully be just as useful for other enterprises as well as ad hoc groups working on the broader internet. With TiddlySpace, you have an application running at http://TiddlyPocketBook.TiddlySpace.com for example. You click a “clone” button, type in “CameraGuide”, and suddenly you have a clone of that web app running at http://CameraGuide.TiddlySpace.com. The neat thing is that the new space has copies of all the pocketbook tiddlers, which you can happily hack. The application tiddlers are “copied by reference” from a master application space, say http://TiddlyPocketBookApp.TiddlySpace.com, so you will inherit any future changes made to the application. All this sounds complicated, but will be seamless to the user, and is also easy for us to implement while building TiddlySpace, thanks to TiddlyWebs’ flexible bags and recipes model for containment of tiddlers. (See my earlier discussion too.) Pretty much all of TiddlySpace is driven by client-side code TiddlyWiki plugins, connecting to the TiddlyWeb server.
We’ve spent a while talking about the design of TiddlySpace and tomorrow we have a hackday with the goal of getting a v0.1 running.
“”"
I’ve been thinking about how to make money from online content since I launched Fray in 1996. Really, I can’t tell you how many nights I’ve sat up, obsessed with it. It’s been my white whale. And here’s what I’ve come up with: a little bit of advertising works, so long as it’s classy, and sell some paper if you can. But any plan that includes walling off your content from the rest of the web is destined to fail, unless it’s porn of some kind (financial data is a kind of porn).
Why? It’s not because everyone online is a cheapskate. It’s because consuming content offline is still a much better experience. Leafing through a glossy magazine is simply sexier than clicking through a PDF
….
Apple could release a device that makes consuming media fun, is able to show any PDF beautifully (just like the iPod would play any MP3), and offers new media for sale in the iTunes store. If they did it right, publishers like me might finally be able to sell something digital that people would actually buy.
“”"
Powazek is getting at some kind of payment for premium tablet-formatted content. I’m not too sure it could work, but it does make me think about micropayments.
Most of the talk about content is about buying books and subscribing to newspapers. Those are traditional business models applied to the web – paying hundreds or thousands of cents. Even that would be an improvement for publishers, who are forced to rely on ads right now.
But what if Apple took the in-app payment model and applied it to microcontent? Built that sort of thing into the core browser and viewing software? You’d end up with something like Jakib Neilson’s 1998 vision of micropayments (http://www.useit.com/alertbox/paymentinterfaces.html) – and note he’s talking about touch-screen gestures:
“”"
Very cheap costs of maybe less than a cent per page would be invisible in the user interface. If it would cost half a cent to follow a link, then that link should probably be shown in exactly the same way as free links. The time to consider the payment would be more expensive than the payment itself, so the payment should be hidden for the user (except, obviously, for appearing on the monthly statement from the payment service).
Slightly more expensive costs of maybe 1-10 cents per page could be visualized by a simple glyph, a slight color change for the link, or by having the cursor show the cost as a pop-up when the user points to the link. It would also be reasonable for the user’s computer to contact a reputation service to gather information about other users’ experience with the link: If most other users felt that the destination page was not worth the cost, then a dialog box stating that fact should be shown if the user tries to activate the link. If the destination page has a good reputation rating, then it would be a waste of time to show the dialog box, and the user would be taken directly to the page if he or she activated the link.
Expensive pages costing more than maybe 10 cents would always require the user to click “OK” in a confirmation dialog before the cost was incurred.
Very expensive actions costing more than maybe $10 would require a different interaction technique than simply clicking an OK button since users often do so automatically without reading the warning text. An unusual interaction should be employed to make it clear to the user that a major expense was about to be authorized. The figure shows one of our ideas for a way of authorizing a payment: the system would show an image of a check with the cost and payee filled in. The user would authorize the payment by a sweeping gesture across the signature field, which would cause a digitized image of the user’s signature to appear. Ideally, the sweeping gesture would be done by actually touching the user’s hand to the screen, but it would also be possible to use a mouse gesture on systems without a touch screen.
“”"
There would also need to be some settings to cap daily spending and perhaps cap spending on a particular domain.
Will Apple do it? Probably not on Day 1. There’s much more low-hanging fruit. But they do have all the pieces in place to do it some day – they control mobile safari and the surrounding OS, the platform has users’ trust, and most importantly, they can charge micropayments seamlessly.
Will others do it? I hope so. I’d love to see this experiment play out.
Will it work? Yes, I think there’s something here. Powazek says walled content isn’t possible on the web, and his solution is that user’s will pay for a premium view of the content. I’m saying walled content could work if it was embedded into the fabric of the web and it gave you Powazek’s premium view. You could imagine a free, high-quality, article on the league website about tomorrow’s football final. It lists all the players, along with a thumbnail. Clicking on any player will set you back 10 cents – the browser subtly indicates it without obtrusively confirming with you when you click. For the 10 cents, you’ll get a tablet-customised view of your player. It hooks into phone settings – you can save the picture as your screen saver and switch your voicemail prompt to be a recording from the player. (This is much cheaper than it would cost if it were a standalone app today, but the app store itself shows that selling lots of cheap units may be a more profitable strategy than a few expensive units.) And it hooks into other apps – sports geeks can export the player’s stats into their spreadsheet app.
What lives at the URL of premium tablet content, when you’re not viewing it on a tablet? That’s the million-dollar question. On the one hand, you could say nothing, but then purists will argue it’s not part of the conversation and people won’t end up visiting it. Fair point, though I think there could still be enough interest if the landing page is high-quality enough to attract links and search results. On the other hand, the ideal thing is really progressive enhancement: the page still lives, the content is the same, but the tablet renders it. The good thing is the flexibility: website owners could make their own mind up about how to degrade, and the market will eventually learn what’s best.
People will pay a lot for content in the right form. A few years ago, the same teenagers who refused to pay for high-quality renderings of their favourite bands songs, were the same teenagers who forked out big bucks for rubbish-quality ringtones. If the tablet is a fun device to hold and surf, people will pay for tablet-formatted content.
One of the problems with a plain-old subscription model is it goes against the model of the web as a series of interconnected nodes. It’s silo-based. A micropayment model, where any page can charge a fee, might get over this problem. It does still have the grey cloud over it: will users want to constantly be making decisions about what they’re looking at? If nothing else, it might detract from the experience. That’s why the industry might evolve more into a Spotify-style “all you can eat” model. The tablet manufacturer (e.g. Apple) charges users $10/month for “premium web content”; perhaps it’s included in the purchase, depending on how the plan works regarding 3G payments. Of the $10, it keeps $3 for itself and divvies up the remaining $7 equally to the owners of all pages the user visited that month. Users might see a small star icon somewhere while viewing premium content, just so they know they’re getting their money’s worth. 10 bucks a month to see content in premium form on a device you love? Even if the raw content is freely available without the payment, I could see this model working.
Last week saw a confluence of excellent events. In the same week as a house move, it proved to be a week of much learning and little sleep. I’d hoped to do a better write-up, it never happened, a combination of being too busy and new MAC BATTERIES SUCK, meaning the lappy couldn’t last through the whole session. But fortunately, I have some links to point to. Here’s a quick summary anyway, along with the linkage.
Ben is ideally placed to cover the brave new world of web fonts, being a web maker who studied fonts at uni. He walked us through the evolution of font hacks on the web: image with alt tag; CSS background image with text pushed off the page; rendering with Flash (SiFR); rendering with Canvas or SVG (Cufon, TypeFace.js), using JSON-based font spec data. It all leads up to the holy grail: @font-face.
Great, so we have @font-face, but issues remain:
* The foundries – Mark Pilgrim, in no uncertain terms, complains the font vendors are stuck in the dark ages of the printing press, in their resistance to support @font-face. This seems to be changing with WOFF, a web-only format that seems to placate the foundries, who worry their fonts will be stolen. It seems more like a symbolic gesture, since the data could still be converted and in any event the print fonts could still be appropriated, but the foundries are feeling more reassured and making signs they will go along with it.
* Performance issue – Bandwidth issues and Paul Irish’s “flash of unstyled text”, where the user notices the font change once the fancy @font-face font has been downloaded.
* Compatibility – IE has long supported font-face, but with EOT format fonts, and that remains the case. You therefore need both types of fonts, and licenses will generally not give you both.
Social Design Patterns
I was, needless to say, psyched about this. Yahoo! has been the closest thing to a realisation of the inspiring design pattern vision of the mid-late ’90s. Patterns on the web, for both its own employees and the wider community to learn from and evolve. These are social design patterns mined by Christian Crumlish (@mediajunkie), in many respect the closest thing software has to an analogy of building architecture, where design patterns originally came from.
There are 96 patterns in all and I’m looking forward to poring through them. In these patterns are hundreds of people-years’ experience of observing real-world social systems. In my own pattern work, I’ve found it necessary to articulate the overarching design principles behind the patterns. Pattern languages should be opinionated, so it’s a good thing to make explicit your criteria for filtering design features. Christian has followed this model too, and identified 5 overarching principles:
Paving the cowpaths. Facilitating the patterns that are already happening, rather than imposing your own invented process. Also means evolving with your users, ev dogster started as photo sharing but evolved to social network.
Talk like a person.
Play well with others. Open standards, mashups, etc. “if you love something, set if free”
Learn from games.
game UI concepts
designing the rules, but ultimately letting the people who come into the space finish the experience themselves.*
This was an internal conference for BTers in London covering a range of general tech trends, and also being a chance to get together and talk shop. The agenda included talks on Scala, Rails, Kanban, iPhone development, and even a lightning talk from @psd on the horrors and delights of APL.
At the Javascript meetup, a great talk on NodeJS and WebSockets. NodeJS is coming on thick and fast, and Makoto Inoue showed how the technology plays nicely with WebSockets. WebSockets are all about Comet-style interaction, so expect to see a lot more of this combo in the next couple years.
Luis Ciprian, visiting from Brazil, gave us an overview of XMPP and talked us through a real-time web app – a basketball score and conversation tracker – using XMPP.
It’s been said that the world hasn’t been this excited about a tablet since Moses came down the mountain. January 27, 2010, is the day Apple is slated to finally put us out of our misery and tell us what it’s all about. But imagine Steve Job moseys onto the stage, launches a forceful history of Apple’s portable record, and then announces Apple’s launching some new ipod speakers. (It happened a few years ago.) No “one more thing”. No tablet. Not even an iPhone OS 4.0.
Even if this happened (it won’t), Apple will have added huge value by sparking a conversation about the future of computing. While some say all the speculation is a waste of time, in this case, I’ve actually found some of the discourse rather fascinating. In particular, Gizmodo’s invocation of Jef Raskin and the “information appliance” dream, and John Gruber’s analysis.
I think Gruber nails it. Steve Jobs, in what many consider will be his final act at Apple, is attempting no less than the next generation of computing UI. Many people are already finding they can get by with just their iPhone for many tasks. Myself, I actually prefer to read blogs on iPhone NetNewsWire and Instapaper on iPhone Instapaper. I can read these away from the distraction of the big machine, whether at home, commuting, or in a shopping line. I’ve been trying to read stuff on mobile devices since the Palm Pilot, and now it’s truly practical. If people are finding their phone does some things better than the computer, imagine what will happen when you have a big touch-screen, let alone any secret-sauce innovations like tactile feedback or live docking into desktop equipment. I think we will find it’s more than adequate for many casual users and a valued extra device for power users.
But this is about much more than Apple. I think we can take it for granted that the medium-term future will be all about touch-screen tablets. We’ll struggle our way through questions about how to stand them up and challenges like their never-satisfying battery life. And what happens when they fall on the floor? Oh, and there will be patent wars galore. But the category will grow fast, as many people start to reap the benefits of a double whammy: better interaction, more convenient form factor.
The really interesting question is how will the UI on these tablets work? The Gizmodo and Daring Fireball articles point in the right direction – it will be more like the new “super phone” mobile generation and less like the traditional PC. Lots of sandboxing, lots of highly-customised idiosyncratic interfaces (but with common idioms), and lots of abstraction (==liberation) from the file system, lots of app stores and repositories.
Now one model for all this is iPhoneOS, the custom-built operating system Apple put together or its own phone. Is there another model?
Of course. The web.
And we can do it today. Apple won’t, others will. We have the makings of an operating system that does all that. Lots of sandboxing? Yep, the whole security model of the web assumes domains don’t trust each other, unlike traditional desktop applications. Lots of customised interfaces? Yep, with Canvas and CSS3 and SVG and WebGL and audio and video and screamingly-fast browsers and a million brilliant libraries and toolkits, yes. Lots of abstraction? Yep, the web never did like file systems, and with offline storage, it doesn’t have to. App stores? Yep, a simple system of URIs and standard HTTP security techniques can do it easily.
Most developers would rather code in technology they already know, that’s open, and has a diverse community contributing a wealth of “how-to” knowledge.
It’s all happening now. Google has ChromeOS. Palm has WebOS. Nokia and others have the W3C web widget standard. Stick these things on tablets, and a whole new generation of UI will flourish.
Quick mention of projects and writings outside this blog:
jQuery iFrame plugin – Stepped up work on this, as it was buggy and not very jQuery-plugin-like. Whacked it in GitHub along with test cases. Not all are passing on the 3058 day old browser, yet. This was a good opportunity to play around with asynchronous testing in QUnit and I was pleasantly surprised to find there’s good support for it – use stop() to suspend the test case (conceptually) and start() to continue it. QUnit Asynchronous tests.
Scrumptious reboot – Following Osmosoft’s decision to deploy everything inside a multi-user TiddlyWiki platform, Scrumptious has to be migrated to work inside of a TiddlyWiki. The final, pre-TiddlyWiki, Trails player you can see online. I’ve since begun work on an overlay plugin, which is a Claytons TiddlyWiki: the TiddlyWiki you’re having when you’re not having a TiddlyWiki; there’s a TiddlyWiki underneath for power-user functionality and a pretty generic UI on top of it. You can flip back and forth between a TiddlyWiki and a special overlay UI, which has full access to the TiddlyWiki state. It works by hiding all TiddlyWiki elements and pushing “style” elements to a DocumentFragment, so the operation can subsequently be reversed when flipping back. The first proof-of-concept is here (source in the TW repo). I’m psyched about this general approach for rapidly building web apps in a multi-user environment. TiddlyWeb provides a RESTful, permissioned, set of web services; and the UI can then be as flexible as you like. Ideally, each recipe/room would be in its own subdomain to help prevent XSS concerns.
Mahemoff.com reboot – Okay, it still needs some love, but my homepage is at least up-to-date now.
Server-Side Javascript article – Published Server-Side Javascript: Back With a Vengeance. Sums it all up really. I decided to submit it to ReadWriteWeb, rather than here or Ajaxian, because I figure i’s a good thing to make the wider audience aware of trends like this. Otherwise, it’s preaching to the converted to some extent.
End of Days for “View Source” – An editorial musing about the end of days for View Source. Turns out there’s going to be a SXSW panel on View Source and Alex Russell, who’s participating, has Save View Source effort.
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.]
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.
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.
alert("this is my script - it's eval'd on demand");
</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).
Welcome to Michael Mahemoff's blog and podcast page on software
development - topics include Web/Ajax, Usability, Programming
(Rails/Java/OO), Patterns, Agile. I'm based in London and I'm from
Melbourne.
