Eitan Suez's Blog: Community: JavaDesktop Archives

I'm excited about the upcoming Desktop Matters conference, which takes place March 8-9 this week in San Jose, CA. This conference is a first of its kind, focusing on Swing and other desktop technologies.

The conference is organized such that it has a single track, which I very much like. As much as it's nice to have a choice of talks to attend, I believe there's more value in everyone being in on what goes on, in sharing a common experience. It's not unlike how TV used to be. I recall a place and time where there was only a single national television station. If a movie was on, everyone watched it, and there's something nice about that.

Personally, I will be attending the conference as a speaker: I will be showing off my project: JMatter. It's been a little over six months since I announced the project as open-source. Our mailing list has grown to over 100 users and the feedback has been extremely positive. Some of my favorites are: "you should be speaking about this at JavaPolis" and "the documentation is outstanding." Speaking of the documentation, I have recently expanded it and it now stands at roughly 200 pages. The manual is now available in print as a self-published book from lulu.com.

I am looking forward to meeting the members of the rich client community at Desktop Matters. Sometimes as developers we overlook the importance of attending a conference. Listening to a talk or speaking with a colleague can be a catalyst for new ideas, and reinvigorates us when we get back to coding. Perhaps I'll see you there.

Where Swing should Venture

Posted by eitan on June 29, 2006 at 09:04 AM | Permalink | Comments (15)

An increasing number of frameworks are appearing that I find particularly interesting. They're web AJAX frameworks where the details of the HTTP communication and of all the HTML and JavaScript on the front-end are hidden behind a Swing-like API.

Here are some of these new frameworks:

It's also worth mentioning that Canoo ULC also provides a Swing-like API, but they're trying to leap-frog AJAX altogether: they deploy Swing thin clients.

Even though this model is new and not yet "fully" proven, I find it very promising. Up until now, web developers have had to master multiple different technologies including Java, Servlets, JavaScript, HTML, HTTP, session management and cookies, and the idiosynchracies of various web browsers on a multitude of platforms.

These frameworks promise to collapse all of these layers down to one. That's tremendous.

So I was thinking, if what is essentially a Swing-like API can be used to build rich web applications, would it be possible to extend Swing in such a way that a deployment switch controls whether we produce a web application or a ... Swing application?

I suppose we could think of this in reverse: can an HTML look and feel be constructed for Swing?

The end result would be the same: we'd write a single application, using The Swing API (not a Swing-like API) and we'd be able to target the web without any extra effort.

So, my message in this blog is: I think Swing should venture in that direction.

I'll have Spam, Spam, Spam, sausage, eggs, and JMatter please..

Posted by eitan on June 22, 2006 at 11:09 PM | Permalink | Comments (1)

For some reason, I did not catch the wonderful Monty Python Flying Circus episodes in my youth. Recently in the USA on public TV they've started airing re-runs.

So it was not until maybe a few months ago that I got a great big laugh watching the classic Monty Python Spam episode, wherein everything on the menu has Spam in it.

Earlier this week I proudly announced that I'd finally open sourced JMatter, a framework that I've been developing for a good while, for developing rich client applications at very high productivity levels.

I never really blogged about it, feeling it was not appropriate to promote code that was proprietary. For some reason, even now I have a little difficulty with this. So I thought why not try to do it with a little humour? That usually makes the SPAM go down a little easier. :-)

On a more serious note, I've been delighted at the response to my announcement. We already have a thriving mailing list, terrific discussions, and I've had the good fortune that a few fellow developers have blogged most favourably on JMatter.

If you have a little time, I invite you to check it out!

A Harness for Swing

Posted by eitan on May 04, 2006 at 05:36 AM | Permalink | Comments (3)

I was thinking about this a while back and it struck me as interesting that as a GUI toolkit, Swing is different from a number of other GUI toolkits out there that were born out of the need for creating a graphical desktkop system. Namely, GTK has GNOME (and Xfce), Qt had KDE, and MFC has Windows.

What does Swing have? SwingSet2? Not really. There are indeed thousands of rich Swing applications that exercise Swing. NetBeans being a very serious one developed by Sun, the same organization that develops Swing. One could also say, "look SWT doesn't have a desktop either, they just have Eclipse." So, you are right, it's not fair to make such a comparison. Nevertheless, it does not mean that it would be a bad idea to have such a project drive the evolution of Swing going forward.

There's nothing like a full-fledged desktop system used by thousands of people daily to serve as a complete harness for a robust GUI API. A desktop system probably exercises all facets of such a toolkit:

Does the toolkit provide a complete suite of widgets that can support a very dynamic user interface?
Are the widgets rich enough? Are they flexible enough?
Is the performance of the toolkit's components being put to the test on a regular basis?
How well do the components interact with each other?

I see an interesting development going forward. I recall reading that someone has ported most of GTK to MacOSX. That is, very soon, Apple users will be able to run GTK apps alongside their Cocoa apps. It is my understanding that GTK also works on Windows. Swing has been in a unique position for a while of being able to run multiple platforms. Others are catching up. And they do have some advantages, having multiple language bindings possibly being one such advantage.

In all fairness, I should mention an excellent project out of France whose goal is to create a desktop system for Java written in Swing: JDistro. What I'm really interested in is a stronger coupling, a stronger feedback loop between two teams: one developing a Swing Desktop System, and another supporting its development by making improvements in the Swing toolkit.

My Dream JDesktopPane..

Posted by eitan on September 23, 2005 at 09:37 PM | Permalink | Comments (17)

One area of Swing that does not appear to be getting much attention these days (or that may have fallen out of favor with developers) are the elements that make up the Multiple Document Interface: JDesktopPane and JInternalFrame.

I believe that there's tremendous potential in further developing the Swing features in this space.

What I am envisioning is nothing less than a JDesktop that rivals the modern desktops of operating systems today, in terms of feature sets. I'd like to share this vision with you. These would be some of the features in 'my ideal java desktop':

the ability to easily dock panels along the edges of a JDesktopPane (I do realize that there exist commercial implementations of this feature today)
multiple workspaces (like we have on linux desktops)
apple-like features: minimizing frames with effects?
ctrl-tabbing to switch between jinternalframes
a dock
easy default keyboard shortcuts for hiding the current internal frame, or, the one i really like from the macos is 'hide others' (command-option-h)
a trash
standard window arrangement features such as tile & cascade (why not?)
the ability to move/place iconized views of jinternalframes anywhere on the jdesktoppane, to configure the placement behavior ('snap to grid' etc..)

Opportunities are rife for improving this area of the Swing API. I believe such an environment could become the basis for some really nice and powerful rich desktop applications.

I realize I'm not explaining myself fully here. "Why would one want to create effectively a 'desktop within a desktop' type of application??" you may ask.

This raises a much deeper question. It is my belief that desktops today, albeit nice, are an incomplete model of a virtual world. The world of today's operating systems desktops is a poor world of files, folder, and applications. It is a primitive model that I believe could be made significantly richer. The desktop metaphor is effectively an object oriented user interface platform and is an excellent foundation upon which to build applications with rich domains. Imagine the ability to place representations of domain objects in folders, to search/query for objects with the facility that we query files today, to invoke their methods with a right-click gesture, to plug in model extensions, to integrate different models into a single user interface substrate. You'd use the same environment, the same runtime application to do email, to file documents, to write checks, or to do software development. More so, there would exist an overarching consistency in terms of how you manipulate objects, regardless of their type.

Well, I've gone considerably beyond the scope of this blog entry, so I better stop here. :-)

swing sessions at javaone..

Posted by eitan on June 29, 2005 at 12:34 PM | Permalink | Comments (4)

i've been enjoying some of the desktop talks at javaone
this week. with swing, a common theme for a talk is: tips
and tricks to make swing run faster. so some of these
talks got me thinking..

so here's a problem:

the construction of swing components is an expensive operation.
if you're building a fairly dynamic ui in swing, one where you
create views on the fly, as a response to a user request, then
there is a performance cost to creating the objects that make
up that view.

( an example of such an app may be one that uses
the mdi metaphor: a jdesktoppane with one or more toolbar
panels used to plan or construct representations of objects
on a canvas)

so the typical solution is caching: create views and cache
them in a pool. whenever you need a view you ask the viewmanager
and it might give you a "second hand" view. so the notion
is: don't throw away expensive things; keep them around, you
don't know who might need them later.

the reason i'm writing this is because for swing you have to
roll this out yourself.

i think a generic solution, one that is orthogonal to the application
in question can be arrived at by writing a couple of aspects:
an aspect that overrides new() on swing components to check if
an existing view already exists in the pool and return that
instead. another aspect that intercepts garbage collection and
instead of throwing away the view, cleans it up, dusts it a little,
and puts it back in the pool or "reuse bin," so to speak.

this reminds me of a recent talk that my friend bruce tate
gave to our users group in austin, texas, that touched on dynamic
languages such as ruby. in ruby, the ability to intercept such
calls is intrinsic to the language, and so injecting such a feature
turns out to be a simpler task for the developer.

the reason i write this is that i'm lazy.
i want this feature, so that i can improve the performance of my swing
applications. but this is a generic concern. maybe there's
something already out there, maybe throwing the idea in the
communal pot can help trigger the creation of a new java.net
project. who knows?

JDNC: "The Gap" .. between Swing and Business Application GUIs

Posted by eitan on December 03, 2004 at 08:20 AM | Permalink | Comments (6)

I finally got around to read about JDNC (http://jdnc.dev.java.net/), to download a copy, run through the demos, look at the .jdnc files, and read some of the documentation (tutorials, article, etc..) I am very impressed! I think JDNC is terrific. I mean its goal is right on target. I believe this is where efforts should be concentrated. And they finally are.

This blog was originally going to be about JDNC but in the course of writing, I've discovered that JDNC is more of a derivative, a consequence of a more fundamental issue regarding most developers' our love/hate affair with Swing.

I think it's fair to say that many of us have a love/hate affair with swing. many of us have been burned by the love affair and are now hateful. others have been more cafeful not to get so emotionally involved in this relationship.

We all agree that today, many developers are designing GUIs targeting web browsers. Most are still doing the HTML/CSS/JavaScript thing and are being very cautious to stick to the KISS principle (keep it simple stupid) so as not to run into issues of compatibility across browser versions and browsers running on different platforms. A few of us have been able to go beyond this and deliver richer clients still targeting web browsers by using Macromedia Flash. An interesting development which a friend pointed out to me is an open source rich client web platform called laszlo (http://www.laszlosystems.com/).

Back to the love(/hate) affair: I believe that I can finally express in writing the reasons why:

We love Swing because Swing has the right foundation. I mean Swing's design is good:
- it can be extended
- it's flexible
- it allows for the construction of other components besides the ones that come with Swing
- it allows for the construction of more sophisticated components,
- it allows for frameworks to come after it and layer themselves between swing and, say, markup developers

There exist already a number of frameworks such as thinlets, certain xul implementations, and now jdnc that allow developers to use markup to build guis. under the hood they all use swing.

so, bottom line: swing is good

Now let's talk about the hate part. the hate part comes when we commit to the relationship and try to tango with swing. Some of us are, after some difficulty, able to build the front-ends of our business applications with Swing. The relationship requires a strong investment, lots of time and effort. For many of us, the relationship doesn't work out.

The reason is now clear to most of us. They happen to be detailed quite clearly in Amy Fowler's overview article on JDNC (https://jdnc.dev.java.net/documentation/overview.html).

The fact that Swing has a great design and is extensible is great. It's the right foundation and we all agree. It's interesting to point out that even web frameworks (e.g. JSF) are attempting to give web development that swing-like design. One example is the ability to register an event listener on an input component, such as a button.

But there's a large and gaping hole, there's a gap between Swing and our jobs of building front-ends for business applications. It may be fair to say that Swing's job was never to provide all the tools that a developer might need for that task. And that's why I'm happy to see JDNC on the scene. Finally there's a project to address this situation: fill in the layers necessary to bridge the gap.

The JDNC team has identified the layers. There is a need for more sophisticated components such as sortable tables, date pickers and much more. They're working on them and a number of these components already exist in JDNC. Then there's the idea of allowing one to use markup to build a UI. So JDNC provides code that will parse xml markup and automatically translate that markup to code that will construct the ui for you. All the while, it's Swing code running under the hood.

The state of JDNC:

JDNC is not yet complete. The current version I believe is 0.6. They have a roadmap published. Check it out. I think that by this time next year, the equation of which way to go to build an app will have to be revised slightly. Make no mistake about it: the effort is asking for help from the community. I believe that help from the community can make a difference between a successful project and one that does not achieve significant adoption.

Note: JDNC is LGPL. So it's open source. What that means to me is that I sincerely hope to see code contributions from non-Sun employees folded back into the codebase.

Another thing that I think needs to happen that could help the adoption of the project is: its name!

I know that JDNC is a product of the javadesktop.org community so the name's got to have "Java Desktop" in it. Then, ok, you might want to bind the widgets to data from a web service over the network, so they threw in "Network" and, of course, we're dealing with providing a suite of components such as the data-bound tables, treetables, date pickers, etc.. so there we have it: Java Desktop Network Components.

Maybe some additional brainstorming needs to go into a good name that quickly conveys the project's purpose to the community. I wonder how many people may be passing over JDNC because they don't realize what problems the project is addressing.

Experiences with Swing

Posted by eitan on July 08, 2004 at 07:16 AM | Permalink | Comments (16)

I've had the pleasure to work on a Swing application these recent months, and I'd like to share with you one of the main conclusions I've arrive at.

It did take me a little time to gain fluency with the APIs. After all Swing is a fairly large API (over 600 classes). On the other hand, once that fluency is gained, developing in swing works out all right.

Specifically one quickly realizes how powerful and flexible Swing can be. For example, I wanted to construct a hierarchical JComboBox and it didn't take much to actually make that happen. I was able to devise such a widget (which I called JComboTree) by combining a JButton, JPopupMenu, JMenuItem, with a TreeModel.

Second, there's no denying that the Swing developer community is a large and active one. Many developers subscribe to the forums, submit their questions, their problems; they contribute their code, their ideas. It's all good (think Bruce allmighty :-)).

One even goes as far as finding all kinds of third party additions to Swing that fill in the gaps: things that a business developer would need but doesn't find "out of the box," incorporated into the Swing API. Let me give you an example: to support my particular Swing application, you will find these third party libraries:

additional (awesome) layout managers from jhlabs.com
a jar file that bridges the gap between rendering a hyperlink and actually launching it in a browser (browserlauncher.sourceforge.net)
skinlf, to give my app additional/alternative cool skins (an alternative is jgoodies)
jcalendar (widget for picking dates, displaying a month view)

Furthermore, if you don't find the Swing tabpane API good enough for your needs, you'll discover that the netbeans team wrote their own separate tabpane API. You'll also discover little pieces of clever code in the forums to give the existing tabpane API a few more features (such as displaying an 'x' on each tab to allow a user to dismiss them, like one does in mozilla for example).

You'll also surely come across various articles that have been written over time that show you additional nify and useful widgets written by various developers. One example is a swing TreeTable, that merges a JTree with a JTable, to allow one to display multi-column rows where the first column is a tree that allows nodes to expand and collapse. Another example is Alan Hollub's calendar widget (employing the decorator pattern).

Now, take a moment to think about the amount of time and effort I've spent: discovering these add-ons, learning to use them, trying out a bunch of them and figuring out which ones worked for me and which did not; which are mature enough and which are not.

Then comes that point in time where you scratch your head and ask yourself: why are these features not incorporated over time into the Swing API? Why isn't the developer team in charge of maintaining and developing the Swing API doing this type of work? This is exactly what a good software library manager does: they're in contact with the community, they distill various enhancements and contributions from the community. They keep the best ones, or work on the promising ones and finally incorporate them back into the Swing API. That's in essence what Redhat does for Linux. That's what Eric Raymond talks about in his various open source essays: how to be a successful open source software manager.

[IMHO] Therein lies the problem. I don't want to guess because I have no clue and I'll admit it. But something tells me that there's a mismatch. The swing libraries are not exactly open source. I'm sure the Swing team wants nothing more than to make our lives easier. Something tells me that this crucial last step of incorporating contributions back into swing is failing because of legal restrictions.

Swing could be more than just "nice," more than just "ok" or "i can live with it." Swing could be the most awesome thing out there. If only through the magic of open source development. The community is already there. The code is waiting to be integrated. What do we need to do next??

I believe that the good people at Sun are actually a step ahead of me. A number of recent announcements indicate that things are moving in exactly the right direction: JDIC and JDNC have been released. I can tell from the community reaction that these new libraries are terrific. Issues such as the ability to easily launch a hyperlink in the user's preferred browser are being addressed. What's really awesome is that these libraries are released under the LGPL.

Perspectives on Software Applications and their User Interfaces

Posted by eitan on October 30, 2003 at 07:49 AM | Permalink | Comments (3)

Introduction

I have recently embarked on a fairly significant project. I took some time to research various frameworks and developers' opinions on the matter of writing user interfaces. I was not only looking for opinions how to write an intuitive user interface, but also on methods or techniques for designing user interfaces that produce manageable code. I read some of Allen Holub's articles on user interface development. I have also been quite taken by Naked Objects (see www.nakedobjects.org). I purchased and read the book and have prototyped an application with NakedObjects (which I will also refer to as NO below).

The Merits of User Interfaces Reflecting their underlying Object Model

NO has had a strong influence on the way I see user interfaces. Particularly the idea of a 1-1 mapping between a user interface and its underlying object model. There are a number of really good reasons for favoring this model of development:

1. Frustration with learning new applications. Many applications today are written in such a way that the task of learning their user interface is an exercise in memorizing the mapping of commands one wishes to invoke to their location in the user interface (usually a specific index in a menu or submenu). This task is made more arduous when software upgrades reshuffle the locations of these commands to other menus. I have personally given up using certain software applications because I got tired of having to relearn their user interfaces.

With a 1-1 mapping between the object model in the code and its user interface, I believe we end up with a more intuitive and consistent user interface that is fairly easy to learn; but more importantly we end up with consistency across applications. That is, by learning to navigate and use one user interface, you essentially learn them all.

2. A common language for communicating with customers. From the perspective of a team of customers and developers working together to develop a software application, a direct mapping between user interface and model significantly facilitates communication between the customer and the developer. As developers, we have often been in the position of having to explain to a customer why a seemingly simple change or addition to an application would be really difficult to implement. The customer's understanding of the application is rooted in its user interface, the only "view" of the application he or she is exposed to. So on a customer change request, the developer has to map that request to the actual underlying model and figure out how the change request maps to the necessary code change. Any decisions derived from that point leave the customer in the dark and sometimes perplexed.

3. Developing a generic user interface from the code suddenly becomes feasible. What NakedObjects has done in this respect is remarkable because it goes well beyond just this. Besides generating a generic user interface from a business model, NO can generate documentation as stories. NO also facilitates the task of unit testing the application. Indeed a customers' tests map directly back to code as a series of actions that could be envisioned as a use case performed by interacting with the application's user interface.

An "Object Oriented" User Interface

It's easy to criticize a software application as "not user friendly" or "frustrating." But the real question is: is there a better alternative? I believe so. As developers we have switched from procedural programming to object oriented programming. OO languages are more expressive and allow us to write code in terms that are closer the problem domain. In many ways our code is easier to read, write, and maintain. For example, we know to look for a method that one would invoke on a object within the definition of the object's type (its class).

If user interfaces also adhered to the idea of an object consisting of data plus methods, a window representing an object might perhaps contain a panel of buttons via which the object's various methods are invoked. Likewise, that window would contain a property sheet of some kind, displaying the various properties of the object in question (I am using the JavaBeans term "property sheet" on purpose here). Likewise, if an object is represented as an icon, right-clicking on that icon could display a context menu, again exposing the various methods one can invoke on that object.

A Shining Example: The Desktop

It's interesting to note that a software application that embraces this style of User Interface has existed for years right under our noses: our computer desktop. Come to think of it, when we use our desktops to manage our file system, we rarely use menus. Icons on the desktop represent various objects (Files, Directories) and we interact with these objects in more intuitive ways:

a. we can drag a file icon onto a folder icon to move or copy that file to a different location in the file system

b. we can view a file in the context of a visual hierarchy representing its relative location in the file system

c. any operations we want to perform on a file is easily accessible by right clicking on the file itself (delete, copy, rename, etc..)

Besides the "object oriented" aspects of this user interface, our desktops and file managers provide several other and very appealing features, such as:

a. The flexibility to view a set of files in different ways: as icons, as a list, as a navigable tree; MS Windows provides a "details" view that allows one to view each file in a folder as a row in a table, exposing the various file details (size, age, etc..); Apple provides their famous tree view that one navigates horizontally. Also the standard "Properties.." context-menu item in MS Windows or the Command-I equivalent on The Mac provide another standard view of a file or directory object.

b. Free-form navigation of the file system hierarchy. For example, one can navigate to a specific folder using a tree view, then open a folder node as a separate window. We have the freedom to focus on a specific corner of our file system by detaching that folder from another view of the file system and displaying it in a separate window. Mozilla in this respect came up with and popularized yet another way to detach information with Tabbed Browsing.

c. Flexible search capabilities, to help locate files based on various combinations of their properties, rather than their containment hierarchy.

d. Desktops also sport a kind of customizable container for aliases wherein we can place frequently used files, folders, and/or applications. Apple provides "the dock" as an example of such a shortcut container. MS Windows has the famous Start menu. In both OS's, the desktop itself serves as a kind of dock as well.

To actually view (and possibly edit) a file in its full form, one resorts of course to launching that file in one of possibly many applications that are registered to handle the file's type (if formats weren't designed to be proprietary, we might today have more choice in viewer applications for various word processing, spreadsheet, and presentation documents).

The Desktop as a Benchmark for Software Applications

I believe many of the ideas and features realized in our file management systems can be made to apply to objects in general.

Let's take an email client as an example. The main objects in this model would be an email message and a folder, or email message container. We would log in to our mail application and a desktop would appear. On our desktop would exist a number of messages that we want to have handy. These messages would be displayed as Icons. We could open any such message with a double-click (or whatever) and view its properties (sender, subject, date, body, etc..). We could right-click on a message to expose a context menu containing a message's methods: Reply, Forward, etc.. We might want to create a new "folder" on our desktop for important messages and drag and drop a few important messages onto it. We might want to navigate a containment hierarchy of email messages. We could use a "find" feature to locate messages.

Sure, most email clients provide the same or similar such features but not to such breadth as a desktop system does for files. Furthermore, the email client application's user interface was hand-crafted. It's unique. It has its own way of doing things, its own limitations, problems, and idiosyncrasies. The main advantage to using the desktop metaphor is that (and I feel that I must stress this) we already know it. We know its behavior, how to use it, we've already learned it. We are just applying the same user interface to a different type of object.

Wouldn't it be nice to have the luxury of learning how to use a single application in-depth, and be able to use it for managing all our information? Not just files, but messages, addresses, task lists, our schedules (and the list does not stop there)? How much more productive would we be? From the developer's standpoint, wouldn't it be nice not to have to write all the GUI code once more?

Business Applications

Let's get a little more radical now. Let's talk about business applications. Say a business wants to keep track of its customers, the products it sells, its inventories, its bills. Can we apply the same UI metaphor to such an application? Why not have a desktop that allows its user (with proper security privileges of course) to create a new customer, to file that customer in a folder of "Important Customers" perhaps, to double click on a customer icon, to view their profile. Some methods might include: upgrade customer status, view customer's purchases in the last month, lookup outstanding balance, generate an invoice.

The application basically boils down to the management of a set of object types (products, customers, bills, purchases) and their relationships, that together represent this particular business domain. By management of I mean the ability to navigate the model's object graph, to browse lists of objects, to search for objects, to create, edit, persist, and delete objects, to inspect objects' properties, and to invoke their methods.

A Generic Framework

I see no reason why the developer who writes a file management application should have to write the same UI code as the team of IT developers writing the business application. Imagine the waste in developer productivity that derives from this duplication. How much of the developer's time is spent designing a user interface, writing code to open windows, lay out panels, buttons, etcetera. More interesting is the ratio of time spent writing the domain-specific code over time spent writing the generic UI code.

How many times have we heard users of software applications complain that the user interface won't let them perform a specific task. Developing a complete and flexible user interface such as an operating system's desktop and file management application is a serious undertaking. Most software applications don't come close to providing such flexibility and quality in a UI.

In constrast, consider NO. The NakedObjects Group shares their experiences in their book. They discuss how IT developers working on NO or NO-like projects achieve high productivity, and can focus on the business problem. They talk about meeting deadlines, about customers and developers being able to communicate. They talk about meetings where developers show applications to customers and obtain real-time feedback, and will often make changes right in front of the customer.

My feelings are that a complete and robust generic framework for software applications does not yet exist. NO is actually the only such framework I know of at this time. I would like to see a large company embrace this idea and put the muscle of a team of talented developers behind it. There are many problems to be solved: developing a generic persistence API, an authorization system, and more.

I feel that a successful framework must be flexible enough to allow developers to write custom viewers or editors for types if they need them.

The Overloaded Desktop

This idea is still fermenting in my mind but I'd like to share with you some of my thoughts in this regard.

By "overloaded" I mean as in method overloading in Java: just as we can declare methods with the same name but different argument types (and different number of arguments), I'd like to talk about the idea of replacing our current desktop system with one that is overloaded to handle different object types. That is, not just managing files and folders, but also addresses and messages, and other things.

Developers or third parties could write classes that would essentially plug in to your desktop (this would require that some standards organization or the desktop maker define standard interfaces for developers to adhere to). With a plug-in for email message management, one's desktop would allow a user to manage email messages in the same way that they manage files, and on the same desktop.

Such a system could be designed to allow users to create sets of desktops by specifying what combination of plug-ins to use in a given desktop. A dock or similar mechanism could be provided to allow a user to switch between desktops.

Another complementary way of describing the same idea: allowing an end user to mix and match what objects they want to be able to manage in an application. Take for example an address book application and an email management application. A user could define a desktop (or application) that combined the two. The effect would be to allow and end user to, say, search for email addresses in the address book and then use those addresses to specify destination email addresses when composing a message. What's important here is that the address book is shared across all applications. There are no application-specific notions, things that cannot be used outside an application's process boundary.

Likeness to JavaBeans

I recently reviewed once more the JavaBeans API and documentation in light of my new perspective on software applications. I am fascinated to discover that many of the concepts necessary in an API to bring about a generic framework for object management already exists in JavaBeans. The main difference I see lies in the JavaBeans API's stated goal: to assist design. The vision for JavaBeans' was to simplify developers' task of writing code. They never considered applying such an API to runtime. Bean Context applications such as the BeanBox are designed to assist the developer in designing software applications. In contrast, I see NakedObjects as a kind of BeanBox designed to run your applications, not design them. One interesting note is that Rick Mugridge ( http://www.cs.auckland.ac.nz/~rick/iduna/ ) has done the reverse. Rick's written a NakedObjects application called Emperor that can be used to write other NakedObjects applications: a design tool.

To swing or to web, appears to be a big question

Posted by eitan on October 21, 2003 at 08:01 AM | Permalink | Comments (6)

When starting a new project, the User Interface decision is always a big one. Should we use Swing? Or should we develop a web-based solution? Some also are correct to argue that web-based doesn't necessarily imply HTML-based. Macromedia-based web solutions are not only viable but a real player. In certain circumstances, the requirements make the choice fairly clear, possibly even mandated.

The traditional trade-off, whether true or not, has always been along the lines of: "give up richness of the UI that comes with Swing for a rapid development cycle that is the web." Developing UIs in Swing does seem to require more skill, knowledge and experience with a very large API. It didn't use to be so with HTML but new standards have crept up over time: CSS for styling, various XML technologies for keeping content away from presentation (XSLT perhaps, now XQuery is on the horizon). But developing web-based solutions also implies knowledge of relatively new frameworks such as Struts or Tapestry, maybe Cocoon. For Struts, one also has to be familiar with underlying technologies such as JSP, Taglibs. JSF is now the newcomer and JSTL has surfaced. So does the web way really look like a "piece of cake?"

Some have argued (and I agree with them) that a tremendous effort has built layers of abstraction on top of the HTTP protocol to make the web a platform for building distributed applications. Their point is that the web was never intended to be such a platform. From this angle, it almost feels wrong to try to "shoehorn" the web for web app development.

Traditional developers sometimes are offended when they see web-based apps violate principles that they would never even consider bending: having to make repeated calls to the server to get back the same information over and over again: headers, footers, markup that could easily be cached otherwise (that is if Swing were used instead of a web browser).

I very much enjoyed reading Amy Fowler's article on JDNC (Java Desktop Network Components) on JavaDesktop.org. Amy's article clearly sums up the debate between web'ers and swing'ers. JDNC hopefully will narrow the gap some more.

It's interesting to analyze how "the gap" has narrowed thanks to various technologies introduced in both camps to help them overcome their weaknesses. On the swing side, there's a lot to talk about: we've had Java Web Start for a while now and people are using it more and more. Also, I really like the frameworks that have embraced a pattern which is admittedly a good one used in the web world: that of using markup to define the layout of a user interface. Allen Holub's recent JavaWorld article on HTMLPane shows how one can make use of this pattern in Swing applications. In my mind the kudos should go to the folks who are building frameworks such as Thinlets (www.thinlet.com), and XUL. They're taking the idea to an entirely new level.

Now here's the one that I think takes the cake: NakedObjects (NO). This framework looks at things clearly, and from a perspective that I believe has almost been entirely overlooked by most. The idea is simple: don't waste your time writing user interface code. It's the same thing over and over again. Instead, use a framework that will draw the User Interface on your behalf; you just concentrate on your business logic, what you're supposed to be doing anyway! :) I have to admit the NO folks have a point. If you haven't done so, I recommend reading Richard Pawson's and Robert Matthews' book "Naked Objects" (http://www.nakedobjects.org/book.html). Yes, I agree that today there do not exist very many NO-like frameworks. NO is a terrific tool for prototyping applications. It's the only way to go for prototyping. One can so quickly develop a prototype application that can be placed in front of a customer, facilitating communications and feedback with the customer.

NakedObjects and various related development efforts today can take the same business logic and give you a user interface in AWT, Swing or DHTML. That said, the Swing version is 0.4, the DHTML version is also somewhat experimental. But it proves the point. I believe NO is a glimpse of things to come and sincerely hope that within 10 years the idea of painstakingly crafting user interfaces by hand will be a thing of the past.

Powered by
Movable Type 3.01D

java.net RSS Feeds