The Widget Plan

• www.mozilla.org/xpfe/widgetplan.html

Introduction

a native widget

A native widget has a look and feel unique to its platform. Its implementation is, at least in part, and very probably in its entirety, specific to that platform. Its core functionality may by supplied `pre-packaged' by the OS.

an XP widget

An XP widget has a single implementation, intended to compile and run across many target platforms. Its look and feel is similar, if not identical, across those platforms.

Objectives

1. Provide a set of cross-platform widgets, libraries and services that leverage the NGLayout technology to allow single-source development of graphical user interfaces.
1. Widgets
1. HTML 4.0 Forms widgets such as buttons, checkboxes and edit fields.
2. General widgets not found in forms, like disclosure triangles and grippy panes.
3. Composite widgets such as tree views, toolbars and font pickers.
2. Services
1. Clipboard management
2. Cursor management
3. Menus and Context Menus
4. Drag and Drop
5. Tooltips
6. File picker glue
7. Keyboard Navigation
2. Provide a common resource format for describing the static user interface content, and a means for instantiating the UI from these resources.
3. Provide a method for specifying stylistic variations separately from content.
4. Support the the XP GUI needs of the Ender, XPApps and Messenger teams, in particular by providing for downloadable chrome and running on Win32, Linux, MacPPC and  AIX.

Proposal

1. The XPToolkit team will provide a a set of GFX widgets that sport a 'Netscape platform' look and feel, details to be provided by the UE folks, who fully support this direction. The XPToolkit team is on the hook for this, but will hopefully be able to leverage work done by the NGLayout team providing form widgets, and by net developers.
2. The XPToolkit team will provide a 'cascading widget' architecture that allows for implementation and substitution of native widgets. Everyone agrees that native widgets are highly desirable, but until they are identified as a crucial requirement, we don't intend to plan on doing them in this release.
3. As time/resources become available, native widgets may be implemented and plugged in, according to the priorities of the developers doing the work (e.g., Netscape would probably do Windows first). The XPToolkit team is explicitly NOT committing to supply these in any particular timeframe. We will evaluate doing some of this work when/if we have time in our schedule, approval to add resources, or both.

• This is probably the least amount of work for development, UE, I18N, L10N, and QA, by a factor of 2 or 3 in some cases. It is the only strategy we can see that meets our requirements within time and resource constraints.
• Doing a complete set of GFX widgets is the only route that allows a seamless UI throughout the app, allowing maximum integration of the client, Netcenter, and other web sites and web applications.
• It is an opportunity to develop a platform-agnostic Netscape UI, which we can use on platforms that have UI religions, as well as the countless information appliances to come, which could not possibly have their own UI devotees.
• It allows us to change the rules on MS again. They can out-native us by deploying armies of Mac and Windows programmers, but we can stake out the high ground as the first Web Native applications, and say that they are porting offline apps to the web.

• Some users may not tolerate anything other than native platform look and feel. We may not satisfy them until we go all the way.
• If we have to do native widgets on all platforms anyway, any work done on non-forms GFX widgets may be unnecessary.

We have to do this in a big way, producing a Netscape UI that a large number of users consider a better overall experience than the combination of web and platform-specific UI they get elsewhere. This means appealing to the large number of new Internet users expected in the target timeframe.

Alternatives

All Native Widgets

Pros:

• A single native widget is typically easier to write than the equivalent XP widget, since the OS provides the core functionality.
• Native widgets automatically handle desktop themes and appearance schemes. In fact, native widgets are the only realistic way to accomplish this. This is an important consideration in writing an application that will be accepted by platform zealots.
• Native widgets will automatically handle changes to the desktop look and feel as they are implemented by platform OS vendors.

• Whether three native widgets are easier (read: quicker) to implement than a single XP widget is a question best answered by taking both roads and measuring the skid marks. The authors suspect three native implementations to be an effort at least equal in magnitude to a single home-rolled version. So while the comparative effort of implementation is difficult to measure with any authority, the efforts of testing, maintenance, documentation and internationalization are all almost certainly tripled.
• Native Widgets do not fit easily into the web content environment. Full HTML/CSS compliance implies an ability to support such style as transparency and z-ordering. Proper web page widgets will not be straightforward native implementations; they will need to be owner-draw.
• Native widgets cannot be convinced not to follow desktop themes. The result is web content, designed by web designers to be platform agnostic at best or to favour Windows at worst, which can look unbalanced and goofy.
• Native widgets generally do not directly support internationalization. The i18n group generally needs to hack every widget implementation to draw in fonts requested by the web page. (Note this point is covered above, but seemed to deserve specific mention since it is often overlooked.)

All XP Widgets

• A widget is finished after a single implementation has been written. Only a single source base must be written, tested, localized and maintained.
• XP widgets can be given a consistent look and feel even across platforms. Web content, which is seldom written with alternatives for different platforms, looks better if it can be written to a single appearance. (We should probably be as faithful to Communicator and IE appearances as possible in our "new" design.)
• XP Widgets can be written to respond to the peculiar stylistic demands of HTML/CSS. They stand the best chance of actually looking like web content.
• XP Widgets can be written to follow a consistent event model and API more easily than a corral full of their disparate native cousins. That is, native widgets may be difficult to fit into a library of consistent tools, while a single home-rolled set stands a better chance of achieving this goal.

• The effort of writing even a single XP widget is comparatively great.
• Taking the lesson of JFC to heart, XP widgets should not even try to look like native versions, since they will necessarily not behave the same. Look can be copied (until the native platform changes underneath), but feel cannot be practically implemented cross-platform. Therefore, UIs implemented with XP widgets will not feel and should not look native.

Mixed Model

Pros:

• It's the best of both worlds. Widgets which should be cross-platform are. Widgets which should be native are.

• It's the worst of both worlds. While non-forms widgets will appear only outside web content, forms widgets must appear in both environments. That is, common widgets like radio buttons will clearly find themselves both in web content and on dialogs. While web content will therefore behave as described in the XP Widgets section, dialogs will contain a mixture of native widgets and XP ones. This is a preposterous situation. Some controls will respond to desktop themes, some will not. Some controls will behave exactly as native controls, being native, and some will have subtle differences confounding to users. (For example: a Windows Tab control is generally activated on mousedown; no Macintosh control is ever activated on anything but mouseup. Pick one.)
• XP ("lightweight," "windowless") controls do not mix well with native ("heavyweight") controls. This may not present any real problem unless native controls overlap XP controls, in which case z-ordering becomes difficult to control. Honestly, dialogs could generally be designed to avoid this issue, but discussions of problems with Java's AWT often mention this issue as if it were a problem. Some controls such as tabs and bordered groups naturally overlap other controls.

Appendix: Frequently Asked Questions

Won't using XP widgets mean forcing the user to learn a whole new interface?

Aren't interfaces built from XP widgets ugly? Look at HTML dialogs!

Should we use GTK?

Native controls are easy. Why do you keep saying they're hard?

Everyone agrees that we already require XP widgets for web page content. Content developers really want this in order to provide a consistent look and feel for their web page across all browsers. Most importantly, however, the native widgets on all 3 tier-one platforms are not up to snuff when it comes to HTML 4.0 compliance. They cannot be arbitrarily colored, composited, or easily placed on backgrounds. As a result, we already have a requirement to produce XP form widgets even though there are perfectly good native widgets at our disposal.

In dialogs, however, people want native look and feel. That means they want to use native widgetry. So in addition to writing all the XP form widgets, we also have to write native form widgets so everything appears consistent. Along with the form widgets, we also need to write the set of widgets that reside in dialogs but not forms (tabs, sliders, color pickers, etc).

Summarizing, we have one set of XP form widgets, one set of native form widgets, and one set of dialog widgets. But wait, native form widgets require platform engineers on three platforms. So in reality, we have one set of XP form widgets, 3 sets of native form widgets, and 3 sets of dialog widgets. In a perfect world, this might not be a problem. Even without native widgets, our schedule goes way past the target delivery date, adding them would require adding significant resources.

Won't dialogs that mix XP and native widgets look goofy?

Won't applications that mix XP and native dialogs look goofy?

Won't XP widgets based services embedded in native apps look goofy?

How can XP widgets keep up with native look and feel as OSs move forward?

The plan, as we move forward, is to augment our XP widgets with native ones. Only native implementations can keep up with the native look and feel for an OS. While we do not have resources internally to attain that goal, we must design the architecture so that others can. If Net developers (or even OS vendors like Apple) get so motivated, they can write their own widgets (since they're so easy, see the previous question) and submit them through mozilla.org.

The architecture will be designed so that in, say, August we can ship a SmartUpdate module with replacement widgets which have native implementations and suddenly Communicator looks much more native.

GTK has `skins'. Doesn't that solve your native look and feel problem?

As this question poses, can't we just ship themes that look like each native platform? This is probably the worst thing we could do. We would, in fact, be tricking the poor unsuspecting user because the widget they see may look like a widget they are used to from other applications, but because it is an XP widget, chances are very good that it would not behave like the native widget.

Skins give us look, but not feel, and are in fact damaging to the user experience if used in this manner. As a result, it is imperative that XP widgets have their own look and feel, so as not to elicit comparison to existing widgets.

---

Copyright© 1998 by Netscape Communications; use is undoubtably subject to the NPL.