Adventures in styleguide driven development
I find myself getting more and more into the subject of styleguides. I use design and development to solve problems. For me, this means striving to build intuitive interactions for a digital space.
If it's about solving problems, we need to explore solutions
To achieve this, I start wondering about the bigger picture. I find myself trying to make a mental model that represents all the facets. First by defining the small parts, and then understanding how they can link together, and how they can affect each other.
1. The desire for a low barrier of entry
I'm working away and I have an idea for a simple interaction or layout. I should be able to implement it relatively quickly.
- Drupal's UI for content modeling: fields on content types, taxonomies, content generation
- Drupal modules for prototyping user flow: create navigation structure and display data in views
- Notepad and pencil: for the rest
I have all of the above. Life is good.
2. The desire for some kind of dynamism
- Data: I can go further and take my HTML/CSS/JS and sprinkle on some JSON. Voila! I have my UI populated with static data. I can dynamically generate data too, so now I can see whether my teaser designs hold up when the titles wrap, for example.
I can discover where my display design fails at this point. And I can start to understand and leverage the emerging patterns.
I also have this, and it's lovely. But then, the user.
3. The need for real data
Because users. Because cross-browser, multi-device, and interconnected means so many permutations. Our design systems need to account for unknowns. The people interacting with our designs are varied, and their behaviour will be too.
4. The appeal of plugging in to an existing system
Despite some frustrations with Drupal's admin and editor experience, I think it's a brilliant tool; the best I've seen yet. Configuration via the UI enables me to create different data structures that represent the content I am designing to accommodate.
I can chose to use Drupal's theme layer as my front-end, or I can venture into decoupled Drupal, with a JS front-end *the implications are different, and also very interesting. I should write more about that :)
Front-end management for EcelecticMeme
Since I've co-worked on the EcelecticMeme project for so long, I've had the luxury of battling with design components that grow over time and change as I accommodate new techniques. I've wrestled with theme engine changes due to CMSs changing. The desire for design system agnosticism, reusability, control over interdependency ("the cascading bitch", as Rob once put it), all come from attempts to ease my own struggles with these things.
I am understanding it so much more fully the more I put these ideas into practice.
Inevitably, as the EclecticMeme moves towards a progressive web app, I want to use the same design system (HTML/CSS/JS) for a server-side Drupal node, as I do for my client-side content as an Ember app.
What I've seen so far:
I've begun using it to implement the EclecticMeme styleguide. This is interesting because I have gone through the process of moving from Joomla template, to Drupal theme, to Ember app and I am getting much closer to being able to copy my entire component directory from one project to another and hook things up without much extra work. An added benefit of Fractal is it uses handlebars (there are other options) as does EmberJs.
While working with Annertech as a web designer, I was able to start moving away from static page designs for commercial projects (one of the many benefits of working with developer-friendly agency). I began exploring component design by first creating graphic style tiles, then moving to designing-in-the-browser.
This was a very intuitive process for me. I had spent a lot of time tweaking designs for my own projects directly in code and loved the ease of exploration and immediate validation of design ideas. I had implementing plenty of others' PSD designs as a front-end developer in previous roles as well, and struggled with trying to interpret all the elements properly, and adjust the design to suit the browser with all its variations.
I heard of this first during DrupalCon Amsterdam from @JohnAlbin. I was pretty excited, as it felt like the answer to all my sticky design consistency and implementation problems. However, there was one caveat which to me was a deal breaker. The markup needed to be added into the scss files as comments, in order to be parsed by the styleguide. It essentially meant the need to maintain two sources of markup, which I could do already (but didn't want to). Luckily, time goes by and the good people behind KSSNode integrated Twig includes and this is no longer an issue.
While working at GoalGorilla, the team behind the OpenSocial Distribution, I had the opportunity to explore KSSNode in depth. Their long-time front-end developer Maikel Koopman had added it to the SocialBlue theme (the out-of-the-box theme for the distribution). Its initial intent was to demonstrate to the prospective user the various components available in SocialBlue. In that, it did its job well.
As part of the Enterprise team, my job was to extend SocialBase/SocialBlue theme to fit client requirements. This meant the design components would change so I needed a styleguide to reflect this. And of course I didn't want to maintain multiple code bases (who does?). I wrote a blog explaining the process of creativing a Living Styleguide, (including some example code) and the pros-and-cons. The blog post was even sponsored on Drupal.org (although badly credited)
Together with my colleague Alexander Varwijk we managed to solve some of the technical issues that were blocking realistic implementation.
Ember Freestyle investigation
I've started to implement this for the Umami Ember contenta consumer recently. I discovered it one day after binge watching EmberConf videos and coming across @chrisloprestos's great presentation. It adopts the "living" styleguide approach by default, allowing me to reference existing components.
I especially appreciate his example of dealing with the "ephemeral states" of elements like spinners and progress bars (11:50). By adding modifiers, we can have a slowed-down and enlarged spinner element present in our styleguide all the time. This makes it so easy to tweak and debug, and we can immediately see how our changes will affect all instances in production.
And the following quote:
It is possible to design impossible things.
- Adobe Photoshop
I'm available for hire and would love the challenge of helping your company introduce styleguide driven development into their design and development workflow. Email firstname.lastname@example.org