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.
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.
Chrome 28:
IE 10:
A custom widget is a UI element built from scratch using HTML, CSS, and JavaScript that either recreates the wheel or extends a native widget. If you think about it, anything that is not provided natively could be considered a custom widget. Custom widgets are an absolute necessity, because native widgets do not provide all that is needed to design complex web applications across many different browsers. The advantage to using a custom widget are obvious and entail the fact that more control over the function and visual treatments of the widget are giving to the designer and developer. The disadvantage is that you are dealing with a custom solution. The disadvantages of a custom solution can be elevated to some degree by opting to use a third-party stand alone widget or widget framework instead of starting from nothing. Of course, using a third-party widget does not equate to complete control over the functionality or visual parts of a widget. Unlike building the custom widget from scratch custom third-party solutions come with limitations. (i.e. When using dojo dijits you have to design to the functionally and visually limitations dictated by the dijit). Don't think just because you are using a custom widget that you are free to do as you please. Total widget freedom only comes when you pay the price of re-creating the wheel (i.e. you build the widget from the ground up).
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:
Frameworks:
Standalone:
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:
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.
Solutions/Examples:
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.
Solutions/Examples:
Native Widgets + Custom CSS + e.g. purecss
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.
Solutions/Examples:
Native Forms & Widgets + Custom CSS + e.g. bootstrap
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.
Solutions/Examples:
Native Widgets + Custom CSS + e.g. Kendo UI + Custom 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.
Solutions/Examples:
e.g. Dojo Dijits + Custom CSS + Custom 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.
Solutions/Examples:
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.
Native widgets and creating custom widgets from HTML, CSS, and JavaScript must evolve. Bending these technologies to make custom widgets is not ideal and several specifications aim to change this. These specifications pave the road for the future of web widget's, called Web Components.
These parts/specifications are:
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.