Anyone making a desktop application in Swing and several other platforms will be struck by the absense of a framework for the basic user interaction.
Spurred on by the recent discussions on XML-DEV about a common platform for XML applications, by the current work at Sun on their Swing application framework, and by the need to brainstorm user interface ideas at Topologi, I’ve made up spec for office desktop application user interfaces called Doxology (Download PDF file). Documents and Topologi, geddit. It addresses a fairly basic functionality that is missing from current Swing APIs, for example. Feel free to adopt or adapt it, as part of your designs, if you need something like this. I don’t intend to provide code, its not that level.
I’ve also submitted Doxology as an input into JSR 296; the note to Sun’s Hans Muller follows.
[Note: the link above is to the most recent version of Doxology. The link below is the version I sent Hans.]
Dear Hans
As a supplier of almost a dozen commercial Java/Swing desktop applications, most of which were based on our in-house application framework, I applaud the JSR 296 effort and I would like to contribute to that effort.
Please find attached in PDF the specification for Doxology, a simple framework described in general user interface terms rather than in class terms. If I were implementing our products again today from scratch, Doxology represents the kind of features that I would want a framework to provide or support.
Now I am not suggesting that JSR should necessarily adopt Doxology, or that it is particularly wonderful; instead I suggest that it is typical of the kinds of designs that JSR 296 should support, and so perhaps useful as a benchmark.
From the Swing point of view, I note that there is currently (AFAIK) any Swing classes or interfaces for the almost all the important parts of the Doxology model, and it would be great if some combination of JSR 296 and SwingLabs/SwingX could provide them:
* generalized Screen View
* generalized Document with dirty bit
* generalized Document View
* generalized Application with dirty bit
* state machine (for disabling controls based on selected object)
* Status bar
* Navigation box (tape transport) controls
* Ribbon controll (but Substance will provide this)
I have also posted this email to my blog on O’Reilly’s www.xml.com
Cheers
Rick Jelliffe
Have you ever looked at OpenDoc? I ask because that was the first thing that popped into my head when I saw the title of this post.
Document-centric interfaces are almost certainly on the wane, as evidenced by the fact that Swing has existed for this long without infrastructure to support them.
However I believe the document user-interface metaphor is a useful one and I recently posted some thoughts on how it can be extended into the world of web-based applications.
Interesting that both comments raise OpendDoc (Aka Bento). I certainly agree that interfaces that aggregate related information from different sources have a lot of legs at the moment: in fact, my company sells a schema collaboration tool (for consortia or organizations) based on the PageSeeder annotation and collaboration platform, which is a good example of this kind of thing. OpenDoc had a file format (Bento) and container system, which Doxology doesn't address: XML and ZIP are what people would use now for those, I'd expect.
So how Web 2 is Doxology? Its neutral. But I don't see that there is anything in Doxology that prevents that some extended Web 2 applications: I define a document as information "stored in a single document or accessible from a single root file" to include dynamic linked information. The collections section mentions searchin on "tags". The details section allows display of information related to the current object, which could certainly be dynamically obtained. And the different views and applications allow the document to be mashed up in different ways. (At a simple level, for example, an XML document with multiple stylesheets would have view tabs for each stylesheet.)
So I think Doxology can be used as an interface to virtual documents as well as actual documents. The thing for JSR 296 I would like would be for an application to register components in their sections, so that predefined screen views can be supplied as part of Swing: this would make it much easier to deliver accessible applications and is sort of like the next level of skinning.
I agree that a big characteristic of Web 2 is indeed that information is mediated through an aggregating/bundling/agregating function, as a level above the self-contained document-as-file. However, in large part this is due to the inadequacies of HTML/XML for representing compound documents: SGML was much richer, especially with HyTime, for re-use because of the much richer entity structure (entities could have attributes.) So I tend to assume that there can by dynamic served fragments and mashups: that was an old thing for SGML, its just new (and livelier) for the Web.
However, before declaring the death of the document as file, consider the popularity of MicroSoft Office (plus Open Office and other act-alikes.) Annotative/linking systems are not hurt by the existance of non-annotative content creation and data capture systems.
I agree with Alastair's blog, I think. But using Swing's lack of support for documents as evidence that self-contained documents are on the wane puts the cart before the horse: an alternative view is that people will be discouraged from using Swing (and move to other frameworks such as Eclipse RCP) by the lack of facilities. Indeed, the network theorists would make us expect that there would be many document fragments that have no outgoing links! But I think Swing currently has a lot of life in it, and hopefully it is reaching the kind of maturity and openness that makes an application framework timely.
Based on reader comments, I've updated the PDF slightly to make it slightly clearer that Doxology is not antagonistic to Web 2. The view tabs have an example view called "Mashup" and the Help button is renamed "Search" + some minor changes.