Lions, Tigers and Cloud HTML5 .. oh my!
I've written about this from various points of view before, and I just love Larry Ellison's response to a question about "the cloud", but it bears repeating and looking at the core issues from different angles because people continue to find themselves confused on the matter. This time we'll look at it from the perspective of "form factors are not programming languages".
Reality is that well over 300 million new desktops and laptops are sold every year. That number is even growing, albeit slowly as one would expect from a mature market segment that is also seeing displacement pressure from new (or revived) form factors. So the "large screen, got a keyboard and a pointing device" form factor is really not going anywhere. It's a good form factor that works for a lot of real world use cases and it will be with us for a while.
HTML5 and the "cloud" do not change that one bit. That's because those technologies are not drivers of physical form factor. I could use those technologies equally well on a phone or a laptop or a T.V. or a fancy billboard at a sports stadium. That is why coming to the conclusion that "Our idea of the desktop is gone." is so wrongheaded.
Now, our way of writing applications for "the desktop" may change over the next decade, but the desktop will still be with us. People will still want a way to launch their apps, manage the shapes they appear in on the screen (aka "windows", since I assume that HTML5CloudAwesomeness doesn't mean "everything is fullscreen with one app at a time" for most people), will want to place these HTML5CloudAwesomenesses around their screen (aka "desktop widgets"), etc. That could, indeed, be written in HTML and Javsacript, but it will still exist.
So what appears inside of our windows may change in the form of where some or all of the data being manipulated is stored and/or what language is used to write them .. but it will still be a lot like a laptop computer.
Just like a tablet doesn't become a desktop just because you run a desktop application on it. If you don't get that one, try running one of the games that are available for the N900 that are just re-compiles of games made for a desktop. It's pretty evident that the language used doesn't magically change the form factor or render it useless.
Network centric computing is awesome and is changing the landscape. How it will change the landscape in the future is not how it is changing it now in terms of creating all these walled gardens that require you to pay with your attention (ads) or with your wallet (rental sites), and I think it is imperative that Free software does provide network storage solutions that work well in this new reality to prevent all the technology from aggregating behind those walled gardens, such as Google.
We will change how we write apps
On that note, I am fairly confident that we will radically change how we write applications with a graphical interface over the next few years. This will not just be on the desktop, but across all kinds of devices. The most exciting thing won't actually be the language used (e.g. HTML vs C++ vs $WHATEVER), but in the level of modularity and subsequent re-use that happens as a result.
Ryan Rix published a screen cast about the Plasma Dashboard KPart that he worked on, particular with regards its use in Kontact. The first comment on his blog asked why use Plasma there at all. The answer is wrapped up in a new way of thinking about application development. This is something I've also blogged about in the past, but that we're starting to actually see happen now.
Instead of writing applications as monolithic things, or at best as collections of components that work with each other only, we're starting to see the emergence of applications that are written as collections of self-contained components that are then collected together into a single interface.
In the specific case of Kontact and it's summary view, it needed to be rewritten for Akonadi anyways. So it was decided to do it in a way that (a) improved what is already there and (b) made new things possible at the same time.
The version shown in Ryan's screencast isn't finished, and the layout and graphic design still has tweaking left to do so it looks a bit nicer in certain places, but even in its current state it gives Kontact's summary dashboard some nice improvements.
I'm not sure how many people new that you could actually move items around in the summary. This is both more obvious now (which is mostly a factor of the graphic design), but also has the ability to provide multiple columns in addition to rows. Horizontal scrolling is there when needed, another improvement.
To extend the summary page requires a plugin system of some sort that everyone can use. Plasma provides just such a component model that fits that perfectly. So an existing widget that is related to email, contacts, events, etc. can now be used in Kontact without any additional work being required by the Kontact team. The email summary widget seen in Ryan's screencast, with all of its great features, is Lion Mail. This was developed for Plasma Desktop in mind originally by sebas, but can now be used in Kontact, saving the Kontact team a ton of work.
What about a weather widget? It was going to have to be re-written, too, to use the new weather data fetching in KDE Platform 4 (which happens to be driven by a Plasma DataEngine now). Well, with the dashboard it doesn't need to be re-written at all: the existing weather widgets can be used there.
Conversely, components written for the Kontact dashboard can also be used in Plasma Desktop, Netbook, other apps using Plasma Dashboard, etc. So the nifty "upcoming events" Plasmoid, written for Kontact is now also available wherever you want.
This is a remarkable, if seemingly subtle, change in how we are writing applications. It's a floating mix of components that we can re-arrange, mash-up and re-use .. at runtime.
We see this not only in Plasma derived work, but also in Akonadi itself as well as KDE Telepathy which renders the functions of Kopete into a similar raft of run-time components.
Not only does this save all of us developers time, it increases consistency between applications, raises the number of features that are easily available to integrate seamlessly into your application (or mash-up) and reduces the runtime overhead of doing so.
Componentizing the Chrome
Another sort of components (don't you love it when we use the same words for different things?) is the user interface chrome itself: the buttons, the knobs, the dials, the menus, the sliders, the web canvas, the print dialog ..
The status quo has been that everyone writes a set of such components for each project type: one for this phone, one for that phone, one for desktop apps, one for PIM apps, one for T.V.s, etc. These components have traditionally been a horrible mix of logic ("when the user presses on this area and then releases on that area, then ...") and display ("paint this gradient here when it is in a pressed state ...").
The display of these elements has been further compounded by the need and desire to make things look and work differently in different contexts. So we have the Oxygen style along with dozens of other Qt styles, each of which is a behemoth of complex C++ that can style all kinds of things in all kinds of situations. There are very real limits to this approach, mostly due to the complexity it introduces and the limitations one runs into quickly due to this.
We also have a different presentation style on a small screen than we do a large screen. Dialogs may look completely different, for instance.
What would be great, however, is if we could get the C++ guy out of the room as much as possible, break up the logic and the display into different pieces so that changing one doesn't impact the other (and removes so much need for subclassing!), make it easy to define new components that overlay just those components from the defaults (so I don't have to write a whole new style just to get a different kind of toggle button semantics, e.g. checkboxes in a mouse driven UI and a slider toggle on a finger driven UI).
If that was possible, app developers could write their UI quicker and easier than they do now (thanks to logic/display separation) and platform developers could mold those application UIs much more cleanly when run on their platform.
This is the future that QtComponents is attempting to bring us. There is a development hot-house happening next week in Oslo (that I hope to attend for a couple of days as I just happen to be nearby that week, as it turns out) that will be critical to the future shaping of this potentially ground breaking approach.
It should, done right, result in it being possible to write UIs which are as or more powerful than the desktop interfaces we have now that look better, work faster, cost less to make and without being bound to a web browser or the technologies they provide (or don't, as the case may be). All with write-once-run-anywhere-there-is-Qt, even without a native compile if done right.
The Device Spectrum
Something that has struck me about what the Linux kernel did that was groundbreaking for the time was to view all computing devices as a spectrum upon which the kernel, albeit in different configurations, should run well on. A wrist watch, a smartphone, a desktop, a super computer .. they are all just collections of CPUs and storage (volatile and non-volatile) coupled with form factor specific stuff, like graphical displays and networking, with processes running on them, right? Hey, it's all the same! Sort of. So why not one (sort of) kernel that runs on all of them? So came the Linux kernel which now is both running rampant in mobile and owns the super computing world, two opposite sides of the spectrum.
Why not our graphical applications?
With decomposable applications and componentized interface elements we begin to approach the age of the device spectrum with our graphical applications. Right now Marco and I are helping a company in Asia working on a tablet device running MeeGo with Plasma providing the UI. They are able to simply re-use work done for the desktop and the tablet we've already done, re-arrange it, put it on MeeGo and profit. (Well, ok, that last point is yet to be proven: the product is still in R&D. :)
We can now take pieces of Kontact, be it at the level of Akonadi data delivery or in Kontact widgets written with Plasma, and use them on a phone, in a Plasma Desktop panel or in Kontact where we'd traditionally expect them to be stuck. Today, we can even pull that widget live from Kontact's dashboard and show it on my smartphone with Plasma. Tomorrow, with QtComponents, we'll go even further with what we can do with the presentation on these devices.
In Summary: It's Doing Less For More Reward, Not Just Doing It Different
- In how many environments and form factors can I run it?
- Does it look good and work well wherever I run it?
- How much does it cost to write it?
- Does it provide me with all the facilities I want during usage?
(Before you lob security and privacy as additions to the above, realize that those are actually facets of the fourth point.)
It becomes apparent that HTML5 (to continue to pick on it :) is one attempt to fill the above four points with varying degrees of success. HTML5 itself isn't very interesting at all, viewed that way. It is of high interest to groups like Google who have run themselves down the narrow alley of "web browser", but not because HTML5 is, per se, that great but because it addresses more of the above in their delivery channel (a web browser) than HTML4 does. While it certainly doesn't hit 100% on all the above points, it moves the metrics closer in that direction.
Still, HTML5 doesn't do a whole hell of a lot for my delivery channels, and it won't for many others as well. QtComponents, QML, Plasma ... these things do a lot for my delivery channels and does so remarkably better than HTML5 on every metric save one: ease of deployment. This is solely because the web browser is ubiquitous these days, even if HTML5 isn't just yet. When "Qt Everywhere" is achieved (or close enough to it, and terrific progress is being made on that goal), even this will no longer be the case. On all the other metrics, we're already at or headed shortly to a much better solution that is more than just "hey, what language can we write applications in for easier deployment?" Of course, that better solution also works seamlessly with HTML5 content thanks to QtWebKit.
This set of technologies will provide (some pieces aren't done yet, e.g. QtComponents) convincing answers to the device spectrum challenges, the component re-use issues and cost factors while opening doors to deployment. Best of all: without sacrificing existing or impending capability. (Aka "we already have OpenGL, what's so exciting about that?")
This is a set of changes that is being seen reverberating across our UI stack even now. Plasma is built around these ideas today, and whether it's a tablet or a smartphone shell or Kontact, KDevelop and Skrooge using it for a summary dashboard or the good ol' laptop with Plasma Desktop on it, we're getting to see the early days of this shift in how applications are being made and delivered right here in KDE.