What are widgets?
Time and time again, I hear people ask: "What are widgets?"
I think there is a lot of confusion in the industry from what I heard last Tuesday at Mobile Monday London.
So let's start from the beginning. Remember File->Save Page as?
Notice how Firefox saves a "webpage.html" with the webpage_files/ directory and perhaps a style sheet? Notice how Opera saves a Web page as a single mime html? Notice how Internet Explorer does this again differently?
So you've written a Web page or perhaps really it's an "office document" written with open proven Web standards instead of that ghastly proprietary Word XML. How do you store that file and share that document interoperably from a USB stick with all your work colleagues? Everyone in your organisation has a Web browser, but how do you package it all up? You need a standard dude!
Ok, you could 'get by' with a zip file. "Send me that zip file with document, style sheet and the images!" Fine. Zips are great, though can browsers handle them consistently?
Guys, widgets actually are simply zip files. You just need that config.xml. Widgets first and foremost are a packaging format. You've probably created hundreds of widgets already, except they are called Zip files.
Now with widgets under the W3C family of standards, this will drive browsers to support zip files, oh sorry... I mean widgets natively. Super convenient!
HEY! HTML5 has offline support so we don't need no stinkin' widgets
So why aren't we using HTML5? HTML5 offline technology features the Application cache, defines a 'logical package' with a manifest. It's actually a great feature to give Web developers extra control of how browsers cache resources.
However one could argue this new feature:
- might be tricky for some browers to implement (whilst it's easy to slap on Zip support to PocketIE)
- difficult to implement for Web developers since it's new
Compare this to zipping up a Web page of your bus schedule. BOOM! You have an "offline Web application 1.0" (aka the W3C Widget). Was that hard? No. Will widgets be the end all of offline Web applications? Certainly not. Though they fill a gap.
A gap that will exist as long as people do not have the latest software and aren't inherently connected. That I'm afraid might be a few years.
Well Google will push this as they need a way of slipping you advertisements.
WTF happened to my killer widget application then?
Ok let me let you onto a dirty little secret: The Web's security model is completely broken. The reason why all these APIs have not made it onto the Web so far, is because of the security nightmare that would ensue.
Though we must have these APIs. How can we introduce them safely, define them and then hopefully get them into the Web sanely? And when there is a will there is a way. That's widgets for you.
Widgets are self-contained little balls of the Web. We can secure widgets by signing and associating an access control policy for them. If something goes wrong with the policy, we can pull the plug and revoke the signature. Great, now we have a basis for a security model. Rock on!
Once we know how these API control policies work with widgets, the big idea is that we can bring this "trialled by fire" technologies to Web applications via W3C participation. So BONDI is not just about widget APIs, they are looking to the future with Web applications.
So my widget is a Web application! (or not)
Widget applications aren't exactly Web applications. They aren't reliant on the back ends like Apache & PHP. Widgets are not inherently connected. They probably will not update and degrade seamlessly like Web applications do at first. Those new device APIs aren't mature. And ... what happens if widgets are just SVG files or canvas elements? DUDE that isn't the Web is it? Or is it?
Thinking of widgets as applications is hard. We are feeling our way here, to the connected Web application platform (HTML5) several years down the line. So let's keep our expectations in check.
Widgets will be useful and they won't neccessarily be doing anything new & connected at first. Though widgets will make sharing content offline a whole lot easier.
So when you are on the Underground and you want to share some funny cat pictures, you can now transfer that content as a widget. Simple.
Ok, fine... then can I have a widget of a book please?
Hey! That's more like it! You understand! Here is a real example of how a zip file of a book from Project Gutenberg is turned into a widget with shell:
#!/bin/sh -e [ $1 ] wget http://www.gutenberg.org/files/$1/$1-h.zip unzip $1-h.zip rm -f $1-h.zip cd $1-h
mv $1-h.htm index.html echo '<widget xmlns="http://www.w3.org/ns/widgets"></widget>' > config.xml
zip -D -r ../$1.wgt * cd .. rm -rf $1-h
Or you could just use the widget books interface I cooked up to save Gutenberg books as a widget. With that book/widget on your device, you can read offline and share the widget with a friend who can't afford a pricey mobile Internet plan. Cool eh?
Remember widgets are just a simple offline encapsulation format to begin with. Backup your files to a widget. Share a widget. Authenticate & trust a widget. Buy a widget. There are new opportunities, you just need to see them for what they are.
Update -- Widgets as a serialisation format for HTML Appcache?
Hopefully widgets will adopt the cache manifest as a mechanism for updating.
So what does this mean? Imagine you had an HTML5 application installed on your mobile. It could be a simple todo list that you want to pass on to your partner or perhaps deploy to zillions of devices.
The Appcached application could be exported into a Widget (a Zip file) and then bluetoothed or deployed into a ~/widgets directory. When the destination device boots the browser, the browser will have the application (and its information contents) readily availble without connecting to the Internet!