Microsoft's XAML has a lot of people worried. Its advantage is to bring the ease of web page authoring and scripting into writing .NET application user interfaces. This makes immense sense. We have a desperate need for decent user interfaces, and the place where a large body of UI designers and programmers live and work at the moment is in web pages.
The web is on its way out for UI-based applications. What users need is a tool suited for the job, not a crippled interface shoehorned into a browser. XForms is not going to save the day here: it will improve the situation for web-based data collection, but it won't keep large scale client projects inside the browser. XAML's benefit is to bring the web page design culture into the richer world of native UI.
Good-looking native user interfaces are key, along with integration with the rest of the operating environment. OS X has demonstrated this loudly and clearly. Even for networked applications, web services have given programmers more freedom to move the UI back into native widget sets while still retaining some of the advantages of the web application.
If GNOME is to be a serious contender on the enterprise desktop, and that is very much the intent, it must meet the challenge of XAML. The Mono project is bringing us the rapid development advantages associated with .NET. We need something to match on the UI side. Let's take a look at existing solutions, and how they might be adapted to meet the challenge.
Glade
The Glade XML-based UI designer and toolkit for GTK+ applications is a great piece of work. The GNOME world has reaped considerable advantage from using it. But it's not simple to use. If you want to produce applications conforming to the GNOME Human Interface Guidelines (another stunning piece of work) you need to read the document carefully and be sure to apply the right spacing, alignments and so on.
What I want to do is be able to describe the few UI elements I need and have the layout engine do the rest, ensuring as far as possible conformity to the interface guidelines. For many applications, the UI idioms are pretty much consistent. As Glade sits on top of GTK, not GNOME, it has not really had GNOME interface design as a specific goal. So we need to bite the bullet, realise GNOME is the main consumer for GTK, and start making it easier to produce decent UI.
I know good design can't be automated, but I'm not talking about the technologies for the core GNOME applications. I'm talking about making GNOME a development platform that's useful for a larger number of everyday programmers with business problems to solve.
Secondly, Glade could do with enhancing its hooks into the host program. XAML allows intermingling of code in the same way Javascript can be written in web pages. Mono's Javascript compiler is coming on well -- Miguel does not miss a trick. Let's put some Javascript inside the UI descriptions so that basic UI logic can be done there.
For Glade to meet the challenge we at least need to (a) create a simple XML format that brings much more to the party, and (b) enable scripting.
XUL
XUL is the user interface language used in the Mozilla project. There are other implementations, but Mozilla is the only realistic game in town. XUL was around doing what XAML does before XAML ever existed. So why the heck aren't we using it? Problems include
All of this is not to say that applications written in XUL and deployed through Mozilla aren't a sensible path to take. Where requirements stick within XUL's capabilities, it can work well. The cross-platform thing cuts both ways. If developers want to deploy on Windows, Mac and Linux, then XUL is a strong contender. The standards-based approach is also an advantage: the XML and Javascript looks very familiar to web developers.
If we were to back XUL for a next generation of GNOME UI, what would need to happen? First and foremost would be a political and social change to get more dialogue going between Mozilla and GNOME. Secondly, there'd need to be a way to ensure a good native GNOME look and feel and interoperability. Thirdly, it would need to be extensible enough to use the richer palette of widgets GNOME offers. Fourthly, Mozilla needs to get SVG support done to bring richer graphics into the UI.
I like XUL, I really do. But I worry that the drag factor is too large to bring XUL up to GNOME's level of expressivity, and GNOME doesn't want to throw away what it's got.
HTML, SVG, XML, CSS
This is more of a grab-bag solution for now. Various projects have used and are using HTML for rapid UI development. The Evolution mail reader is the most prominent among these. SVG is starting to be deployed well on the GNOME desktop.
These solutions have the big problem however that they totally miss the native look and feel. Microsoft themselves went down the HTML-as-UI route and I think proved its difficulties. Neither do the current HTML and SVG libraries have any scripting support. So we're really just limited to document-like display. Also, all of the GtkHTML libraries are rather crusty, especially compared to things like Mozilla.
CSS may have something to offer. The creation and application of sensible stylesheets to markup could make all the right border and spacing choices, etc, for the developer. The possibilities of XML and CSS used together are broad. That said, they're also uncharted. GNOME has some excellent CSS work going on in libcroco, much under-appreciated. If nothing else, I believe that libcroco and the associated renderer, "sewfox", are a sensible migration path forward for GtkHTML.
So this route is a little more experimental: it won't bring a rapid response but there's good work that could be done, especially in the more presentation-oriented aspect of UI.
Conclusions
We need to recognize this as a problem the desktop needs to address. As a happy core of programmers we GNOME hackers are too content bumbling along with our familiar tools, as we've become expert in them. While this may even work in enabling us to compete at the desktop core level, it's not going to bring massive adoption of the Linux desktop for everyday developers with a job to do.
All of the options I mentioned above need exploring: a new layer for Glade to make it simple; dialogue with Mozilla and investigation of XUL, and a serious look at the future of HTML, CSS and SVG in the desktop platform. Doubtless there are other ways forward, too.
I believe the GNOME project and the open source desktop community at large can make a response to Microsoft. But we need to recognise a key economic constraint for would-be adopters. This constraint is developer time. Microsoft licensing and support is cheap compared to the time spent in creating applications. To get the cost of Linux desktop deployment down, we need to drive down the cost of application development.
Microsoft knows and understands its developers well. GNOME has made some great progress at starting to understand its end-users, but it's time to take the next step.
