But then, there is a third kind of GUI: couch interfaces. With their media center software, both Microsoft and Apple have been quite innovative in this space. The more I use couch interfaces, the more I want a couch interface for almost every desktop application: For example, if I am on the couch, I don't want to leave it to quickly check my email. Any kind of widget such as weather, dictionary or stocks also makes couch-sense.
Note that couch interfaces are a lot like smartphone interfaces: The screen space is greatly reduced and input facilities are limited. Smartphones partially solved the input problem via multi-touch, couch interfaces could do something similar by building small trackpads into remote controls. Wireless keyboards or wireless air mice might also help. But then the Desktop GUI cursor has to be adjusted to couch constraints (by making it larger?).
In this post, I'll take a look at where desktop and web applications are heading. Eclipse E4 could be a major player, but its vision is too limited. First, I'll summarize the current state of application affairs.
Recent developments in web applications:
- Offline modes and databases (Google Gears).
- Run them as separate applications via Mozilla Prism.
- Write them like a desktop GUI application, be it via Dojo or via GWT.
- Have bidirectional communications with a server (Comet).
- The server is getting leaner, becomes mostly a service provider, while the clients do much more work.
- receive updates via the internet.
- provide help texts in HTML.
- Ubiquity: Applications are available anywhere (where you have online access) and there is no installation necessary. Update are completely unobtrusive.
- Synchronization: A corollary to ubiquity, you want your data to be ubiquitous, too; not just your application. Applications will synchronize with a server, in a fashion that mimics distributed version control systems.
- Integration: Applications are first-class citizens in a desktop environment.
- Mash-ups: You build mash-ups by orchestrating web services and exchanging user interface components.
- Stability: Applications run safely separately and don't affect some kind of browser, be it by slowing it down or by crashing it.
- Rich content: appears everywhere, it includes images, sound and movies.
In my opinion, tools like GWT get it right, while the Eclipse E4, at least from what I've read about it so far, does not. The former is an excellent intermediate solution that will be easy to evolve into what is to come. The latter feels more like a frantic push to be web-enabled, somehow. RAP, which has been quoted as an E4 inspiration, is a bit like an anti-GWT and relies a lot on the server to keep state. Pursuing this path gives you the worst of both worlds: You have sluggish web applications and do not evolve the state of desktop applications, either.
Any comments? Am I right in bashing E4's web ideas or did I just misunderstand?
Disclosure: This post has been partially triggered by "Who Needs an Online IDE?".
Update: The newest generation of applets can be dragged to the desktop to become a Java web start application. This is really cool: You can quickly test-drive an application as an applet, but also turn it into a proper application for long-term use.
LaTeX on Mac OS X is a very pleasant experience, because both LaTeX and the operating system have excellent support for PDF. That means that you’ll be able to use a “PDF-only” workflow (with the occasional bitmap graphics thrown in). In this post, I describe my favorite setup for LaTeXing on the Mac.
- Don't start with an overview (of the subject, its history, etc.).
- Don't start with the abstractions (the result), start with the concrete examples.
- Keep things initially simple, add ambivalence later (to complete the knowledge).