DISCLAIMER: The term widget is being broadly used in this article to refer to any user interface element that either supports (e.g. fieldset or splitter) or directly aids (e.g. textarea or tree) the display of information.
It is extremely uncommon for a visual designer or interaction designer building an application user interface to open a design program and begin to re-create the wheel in terms of UI patterns. No, in fact, the majority of the work that is done when designing a new application interface is based on common patterns that users already intimately understand. Imagine the scenario where the expectation placed on the designer was to create new and unique UI patterns for each UI project. They would argue to no end that from a usability perspective this would be UI suicide, not to mention the large amount of time (i.e. money) that would be needed for such an innovative endeavor.
Now, it is often the case that these same designers who know perfectly well the value of reuse, will design a UI they assume visually and functionally should be engineered as if it were being built new for the very first time. In a sense, they believe that each of their mostly-recycled patterns can simply be engineered from the ground up and tailored specifically to the detail they designed. In short, they ignore the native and custom third-party widgets that are commonly used to create web apps. Is that acceptable? Absolutely not! Designers and engineers have to abide to a widget strategy.
DISCLAIMER: Now don't get me wrong, I'm not saying that innovation is not a premise that a lucky few get to build from, but certainly it is a rare situation where large amounts of time and money are needed. If you are thinking that sounds a lot like a funded start-up, you'd be wrong. A funded start-up has money but no time. If you or your clients have large amounts of time and money, I suppose you can ignore what I am saying today. But let's not pretend that this isn't a rare situation in which an uncommon reality is purchased.
As developers, we also have a strong sense of the value of reuse just like visual and interaction designers. This is why when a user interface is to be built we can immediately begin strategizing the engineering of the widgets. When I am doing technical oversight, the widget strategy is often the very first specification I define.
In this article I am going to discuss native and custom widgets (standalone and frameworks) and how these widgets are employed (i.e. strategies) by developers when building web UI's. We'll start by examining native and custom widgets and then look at some common strategies for employing one or both of these solutions.
Native HTML Widgets
A native widget is built into the browser and does not require construction, just implementation and configuration. The advantages of using a native widget are found in the fact that they are built-in, maintained by browser venders, and optimized for speed and the environment (no hacking required, no maligning of the DOM or JS). In short, they just work, and are ready to be used while rarely introducing additional bugs or regressions into a code base. It is common practice that native widgets are exhausted before a custom widget is implemented.
The disadvantage to a native widget is that the ability to customize their functionally or change them visually is limiting via CSS, if not in many cases impossible. What is even more bothersome to a lot of pixel perfect folks is native widgets vary in look and function depending upon the browser rendering the widget. Additionally, not all browsers support, or support the same exact functionality, found in the the newer native widgets.
Below, I show a visual representation of the native widgets defined by the HTML5 specification in Chrome 28 and IE 10.
Custom HTML Widgets
Custom widgets are typically part of a larger framework of widgets but can also be stand alone. It is not uncommon for some widget frameworks to provide a comprehensive set of widgets so that no native widgets are needed.
Below, I show many, but not all of the of widgets that typically fall into the category of a custom widget:
Additional examples of third party custom widgets, grouped by standalone or framework, are listed below:
- google closure
- YUI3 Widgets
- dojo dijits
- jQuery UI
- Zino UI
Just like an architect of a building who must know the materials they have to work with, a designer of UI's must also be intimately familiar with the types of widgets they have to work from. When a UI is being built a presuppositional development strategy has to be adopted, regardless of if any information or design has occurred. This premise must not only be adopted by the developers but also by the designers. Once the strategy is chosen it is the designers and engineers job to adhere to the realities of the strategy. The designer is either free to build everything from scratch and thus the engineer will follow suit, or they must both limit their solutions to the confines of the strategy selected. If this understanding between designers and developers is mismanaged or worse ignored, it is almost certain that both the quality of the design and the quality of the code will be degraded.
Front-end Developers commonly employ one of the following 6 development strategies to engineer UI widgets:
- Native Widgets + Custom CSS
- Native Widgets + Custom CSS + Third-party CSS
- Native Widgets + Custom CSS + Third-party CSS + Custom Widgets
- Native Widgets + Custom CSS + Third-party CSS + Custom Widgets + Custom JS
- Abandon Native Widgets And Adopt Comprehensive Widget Framework
- Build Your Own Comprehensive Widget Framework
The most common strategy employed is somewhere between strategy 2 and 4. Engineers are taught not to re-create the wheel so they will exhaust native widget use and reluctantly abandon them for custom widgets. However, browser issues or missing functionally forces developers to use standalone or framework widgets and if that doesn't work the last resort is to build a standalone custom widget from scratch.
Let's examine each of these in more detail.
Strategy 1. Native Widgets + Custom CSS
Description - Developer makes use of out of the box native widgets. Custom CSS is developed to customize the native widgets.
Strategy 2. Native Widgets + Custom CSS and Third-party CSS
Description - Developer makes use of out of the box native widgets. Custom CSS is developed alongside third-party CSS to customize native widgets.
Strategy 3. Native Widgets + Custom CSS + Third-party CSS + Custom Widgets
Description - Developer makes use of out-of-the-box native widgets. Custom CSS is developed alongside third-party CSS to customize native widgets. Third-party CSS & JS provides custom widgets.
Strategy 4. Native Widgets + Custom CSS + Third-party CSS + Custom Widgets + Custom JS
Description - Developer makes use of out-of-the-box native widgets. Custom CSS is developed and third-party CSS is leveraged to customize native widgets. Third-party CSS & JS leveraged and anything not provided by the framework will have to be custom built using HTML, CSS, & JS.
Strategy 5. Abandon Native Widgets And Adopt Comprehensive Widget Framework
Description - Developer selects a third-party framework of custom widgets and anything not provided by the framework will have to be custom built using HTML, CSS, & JS.
Strategy 6. Build Your Own Comprehensive Widget Framework
Description - Developer re-creates the wheel for each widget so that complete control over visual appearance and function is possible. Everything is custom built creating a custom framework. Design and development has only the constraint of the technology and commonsense (i.e. usability and patterns) to limit the innovation contained in each widget.
It is incredibly uncommon to develop all of the widgets contained in a web application from scratch. In fact, I am only aware of four frameworks which provide such a solution for html, web based, applications. Most frameworks exists to fill the gaps while the following frameworks attempt to re-create everything. Building your own widget framework can be likened to building solutions similar to closure, extJS, DHTMLX or Dojo Dijits.
The Future of Widgets On The Web
These parts/specifications are:
- Templates - which define chunks of markup that are inert but can be activated for use later.
- Decorators, which apply templates based on CSS selectors to affect rich visual and behavioral changes to documents.
- Custom Elements, which let authors define their own elements, with new tag names and new script interfaces.
- Shadow DOM, which encapsulates a DOM subtree for more reliable composition of user interface elements.
- Imports, which defines how templates, decorators and custom elements are packaged and loaded as a resource.
According to the Web Components specification, "Each of these pieces is useful individually. When used in combination, Web Components enable Web application authors to define widgets with a level of visual richness and interactivity not possible with CSS alone, and ease of composition and reuse not possible with script libraries today."
Change is coming and you should be aware and tracking the improvements in the web widget space provided by Web Components.
Just like the Dude, developers and designers have to abide by the strategy. Define and clarify a strategy and then abide, otherwise expect annoyed designers and burned out developers.