The Widgets page is one of the most visited on PatternFly.org. What do visitors expect to find in the Widgets page? Do they get what they need there? And what is a Widget, anyway? I spoke with five PatternFly users to get their thoughts on this topic, and also ran a survey (we got 12 responses). Thanks to everyone who participated in this effort!
Visitor opinions varied quite a bit on a number of topics. As a key example, exactly half the respondents believed that Widgets were the same thing as Components, whereas the other half did not agree. But why, exactly?
When I broke down the responses by discipline, I was able to see some patterns emerge. The following chart shows the same data, further broken down by discipline.
The way a person responded to the statement “Widgets are the same thing as Components” roughly corresponds with what they do in their job. The terms “Widget” and “Component” are clearly distinct concepts to a developer, but not so much to a designer.
Let’s dig in a bit more to how people define Widgets. First, here is what interviewees said about widgets:
- “I think of widgets as small things you can interact with. For example a dropdown [menu] is a widget that can be put into something larger, like a table pattern.”
- “[A widget is] an independent bit of code that can be used anywhere in the UI in different sorts of layouts, in different sorts of patterns.”
- “I see widgets as low-level, with no guidance as far as when you should use one widget versus another.”
This matches up pretty well to the survey results. Respondents tended to agree with the statement that “Widgets are the basic building blocks I can arrange on a screen.”
But, unless you’re a Visual Designer, you likely wouldn’t classify CSS elements as Widgets:
According to interaction Designers surveyed, Widgets are always small. However, developers mostly disagreed with this statement:
Developers tend to be more concerned with functionality over form. Technically speaking, the overall size is not integral to the Widget; it’s actually an easily changed parameter. You could even say it’s arbitrary. However, when it comes to visual design, every pixel matters. Changing the size of an element completely changes the visual balance. Thus, classifying elements by size would make more sense in the field of Visual Design, and I believe that Widgets are a used here as a convenient term to indicate small elements. And Widgets do tend to be small, in reality.
And finally, Interaction Designers fall in the middle between form and function. They see both sides, and need to consider both of these perspectives at different times.
How do Widgets relate to Patterns?
Now that we have a better picture of how people define Widgets, let’s look at how those same folks relate to Patterns. Here is a statement that really resonated with respondents: “Patterns are multiple widgets, used together.”
Interestingly, Components seem to have almost exactly the relationship to Patterns as Widgets do, according to respondents:
As only half of visitors agreed that Widgets and Components were the same thing, how does this result make sense? Widgets and Components do have a few key things in common: both are seen as tangible elements and both can be used as pieces of larger elements. So, regardless of what exactly Widgets and Components are, they do seem to relate to Patterns in the same way.
Let’s take a look at how people define the term “Pattern”.
Respondents said that patterns are:
- “Industry-tested, customer-tested, UX-Designer-tested ways of doing things; kind of best-practices for using widgets.”
- “How you should build applications that [work] towards [a] goal.”
- “UX; How things look and how they should operate.”
These statements emphasize the guidance that patterns provide. So then the question becomes: are patterns purely guidance or are they also tangible elements that you can use directly in an application?
Designers mostly agreed that patterns could be used directly in an app, whereas developers were a bit more split on this (3 of the 5 developers disagreed with the statement). This is an interesting result, as Patterns in PatternFly do, in fact, provide example code. Where is this discrepancy coming from? I believe that these developers generally see Patterns with code as “Components.” In the following categorization exercise, you’ll see that developers do tend to categorize items as “Components” that designers tend to categorize as “Patterns”. What’s interesting here is that this implies that developers navigate the Pattern Library in PatternFly.org to find the things they know as “Components.”
As a final task in the survey, I had respondents categorize a selection of elements into the categories of Pattern, Widget, Component, or Layout. Here’s how they categorized these items, broken down by respondents’ primary discipline.
As you can see in the charts, people generally tended to gravitate towards the term “Component” more than “Widget” — developers did this more so than designers. Developers also tended to use the term “Pattern” less than designers, as can be most clearly seen when looking at the categorization of “Dashboard Card” and “Table.”
Analysis: On Accommodating Developers and Designers
Design frameworks such as PatternFly exist at the intersection between the design and development disciplines. The terms and concepts we use in PatternFly are a mashup of terms and concepts from both disciplines. Occasionally, the subtle differences in the meaning of terms between these disciplines can cause confusion. The site design ultimately has to accommodate both perspectives and approaches, directing both designers and developers to the content they are looking for.
Developers tend to define the tangible elements used to build applications as “Components.” In other words, if an element is not abstract, there’s a better chance a developer will classify it as as a Component, rather than a Widget or Pattern. Components can be large or small, complex or relatively simple (anything above the level of basic HTML tags). To developers, the term “Widget” is more narrowly defined than “Component,” and is a less accurate term for the elements that we provide. Finally, developers understand UI Design Patterns at the level of guidance or best practices in UI design.
Designers, on the other hand, have no preference whether something is a Widget or a Component. Widgets are generally understood by designers to be the basic building blocks. To designers, the line between Patterns and Widgets is a matter of scope; Patterns tend to be composite elements, built out of multiple smaller elements. If you look at the sorting exercise, the elements that designers categorized as Patterns were Dashboard Cards, Tables, and Master-Detail, which are all composite elements.
In PatternFly, Patterns tend to get a greater focus than Widgets. To designers, the solutions provided in Patterns are of greater value than individual Widgets, because the choice of Widgets are already built in to the larger solution. Being able to simply choose a proven solution to a problem is a big win for a designer. Patterns are a tool to help make large design decisions quickly and with confidence.
We need to take another look at how we classify elements in PatternFly. As you may recall from the survey results, respondents overwhelmingly viewed “Bar Chart” and “Datepicker” as either Widgets or Components instead of Patterns. Currently, we mix basic and composite elements in the Pattern Library, which is causing some confusion. We need to be more consistent about how we classify elements as Widgets or Patterns. It’s clear from the survey results that these categorization issues affects both designers and developers. As a general rule, the more basic (non-composite) elements should probably be in the Widgets section.
Why would “Datepicker” and other Widget-like elements be in the Pattern section? What makes them different from the other non-composite elements that we classify as Widgets? The answer is that these elements all provide design guidance.
In PatternFly.org, we have no solution or page template to deal with Widgets that have design guidance (like “Datepicker”), so they end up in the Pattern section. Instead, we should use the same template for the content that we have in the Pattern section for Widgets. Overall, this will help everyone. Developers will be able to find and get code in the same way for any element. We can handle Widgets that have design guidance in a prescribed and consistent way. And finally, a universal template makes it easier to move elements around, without needing to modify the content format. If we decide that something should be re-categorized, it becomes trivial to do.
Thoughts or feedback? Let us know in the comments!