Couch graphical user interfaces

Let's review: What kinds of graphical user interfaces (GUIs) do we currently have? On the one hand, there are Desktop GUIs whose development has been a bit stagnant for a while (I have written about some new ideas, older, but not yet widely used, include lifestreams, zoomable user interfaces, and 3D GUIs). On the other hand, there are smartphone interfaces that have recently enjoyed a resurgence via multi-touch.
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?).

Online Eclipse E4? Lack of imagination! [Update]

Related posts: "Improving code browsing in Eclipse", "Eclipse 4 wishes: simplification first, then innovation".



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.

GUI applications

• receive updates via the internet.


• provide help texts in HTML.

This makes it seem inevitable that both kinds of applications will meet in the middle. So what will this middle ground look like?

• 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.

What I would love to see is more thinking about how we can move desktop applications closer to this middle ground. For example: Why is Java web start so close to the above outlined ideal and yet not nearly used as much as Ajax applications? How can we make desktop applications simpler to maintain? How can we build synchronization into every application? How can desktop applications do mash-up-style data and GUI integration?



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

Update 2012-04-04: Brought several smaller things up to date, added a conclusion.

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.

Getting started

• Installation: The best way is to use the MacTeX distribution (TeX Live on Mac OS).


• SyncTeX: Enables jumping between corresponding locations in PDF and LaTeX source. Aquamacs and Skim support it out of the box. SyncTeX has been created as a replacement for the older PDFSync.

Aquamacs

Aquamacs is a Mac OS X version of Emacs that comes with all the great Emacs LaTeX editing packages such as AucTeX and RefTeX.

• Overview with screen shots: “Editing LaTeX with Aquamacs”.


• Options → Option Key: Change if you need the option key for special characters (e.g.: backslash on German keyboards or French accents).


• Command → Jump to PDF (or command-shift-click or C-c C-c "J)ump To PDF"): Uses SyncTeX to go to that part of the PDF that corresponds to the cursor position in the LaTeX source.


• M-x longlines-mode: Avoids inserting hard line breaks (e.g. via auto-fill). This used to be a big problem when you wanted to edit LaTeX source in both Emacs and other GUI editors. Tip: You can remove intra-paragraph line breaks via unfill-region (but this does not work if each line of the paragraph is indented with spaces).

Skim

Apart from being able to annote PDFs (which the Leopard Preview app does really well now, too), Skim is also the perfect LaTeX PDF viewer, because it updates its contents in the background whenever the PDF file changes and it supports SyncTeX.

• Enable SyncTeX with Aquamacs: “Preferences → Sync → PDF-TeX Sync support”.


• More information on PDF syncing: “TeX and PDF Synchronization – skim-app”.


• Jump to LaTex: command-shift-click.

Tips and tools

Tricks and tricks:

• Mac OS Spaces: I don't usually need them, because an application often suffices as a substitute for a space when it comes to grouping windows. But if you combine two different applications, such as Aquamacs and Skim, spaces are very handy.


• Check out my other LaTeX posts.

Other LaTeX programs (see also external extensive list):

• Integrated GUI LaTeX editors: If you are not into Emacs, you'll probably want to take a look at TeXShop and iMacTeX.


• GraphViz: Check out the Mac OS X GUI application. It exports PDF which is easy to integrate in LaTeX.


• dot2tex: a LaTeX-friendly converter from Graphviz to PGF/TikZ commands, with support for LaTeX (math!) labels and arrows.


• BibTeX: BibDesk (Mac OS X only) or JabRef (Java).


• jPicEdt (Java): Graphical eepic editor.

Conclusion

Emacs is very hard to beat, because RefTeX does so many things: It shows you the table of contents in the editor, with live links; it lets you change the “depth” of several sections via the TOC (e.g. to turn several subsections into sections); it lets you search your BibTeX database from the editor and insert the citation you have found; etc. I find it hard to work without these features, but many people happily use Eclipse, TextMate, Sublime or other text editors for their LaTeX needs. At the very least, you should make sure that SyncTeX works with your editor.

How to guide an audience from novice to expert

The article "The Hero's Journey: Are You Experienced?" uses the Dreyfus model of skill acquisition to explain how people learn: Initially, when they are novices, they cannot handle a lot of contradictions. They want to be told what to do and everything must be simple and consistent. Combine this with the observation that abstractions must be built by amassing concrete examples, and one can derive a few rules for teaching (some of them borrowed from "Hero's Journey"):

• 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).