Themes and Structure

At first glance, a theme is nothing more than aesthetics, the visual polish applied to the structural layout of a user interface. The colour combinations, the the gradients, the proximity of one thing to another. These properties are the eye-candy that make or break the whole experience. This view marks aesthetics as a blanket, coating the structural scaffolding of each widget, and collectively, the whole UI. But is it actually as clean a distinction as that? Can a theme really be thought of as no more than a collection pf appealing CSS rules? Can we detach the aesthetics from the UI, and it's constituent widgets, cleanly and without worry? It turns out, yes, we can and do. Thinking about the patterns of software reuse, the theme, or rather, the ability to theme, is crucial to user interface reuse.

How, exactly, do we go about reusing the same user interface components, but perhaps for a different client? The theme helps us do that — the whole idea being that the theme is a independent thing from the UI. The UI exists prior to the theme entering the stage. Themes, by nature, are interchangeable. And we can swap themes out for something different using any user interface framework that supports themes.

The currently-active theme is just a configuration value, set in the deployed application. It points to a theme, which in turn, tells the framework to read the theme, and apply all it's properties to the user interface components where need be. So in this sense, the theme is really just like another installable software package. A theme has a completeness to it, as it must encapsulate the definitions of how the user interface must look. Of course, there will always be a slight overlap from one theme to the next. Maybe changing themes that are aesthetically similar only result in a few visual properties being updated. Another common behavior of themes, when applied to user interfaces — it's not the structure of the UI that changes. It's just the palette level things in the UI that say — "this belongs to another company". Changing themes doesn't result in the re-ordering of tabs or the height of a header. These structural things are largely static.

Should the structure of a given widget be defined statically by the framework code? Or does it belong in the same definition language as the visual aspects that make up the theme? We say the structure of a widget is static not because it cannot be change by the application developer, but because it isn't conceptually accessible to the developer. The button structure is divorced from the theme. It resides elsewhere and so isn't affected by the dynamic nature of a changing theme. But I suppose this is a valid question as well — is this in fact an ideal setup — do we want to make the structure largely static and unchanging?

What it boils down to, I think, is that themes in the web application world have grown up. They're now at a stage in life where frameworks support the concept of packaging and distributing. A theme is a thing that can be developed independently of any application that uses the framework. And so I think it's necessary that structure belong to these packages that get passed around, altered, and deployed. As rare as any change to the physical widget structure is, they should still be accessed and manipulated using the same pattern as a basic change in aesthetics. This approach of bundling aesthetics with structure to form a theme has the benefit of simplifying the framework code itself, allowing the focus to be capabilities, and improving them over time.