Photo by Yes Moon

Had an excellent, jam packed time at Texas Camp in Austin. It was an extremely well organized event attended by a bunch of super engaged and friendly Drupalers. A bit of a short trip for me as I had tickets to see How Did This Get Made back home on Saturday night, but that just resulted in things being focused around a couple of clear themes.

Visual Regression Testing

Visual Regression Testing is a topic I’ve been interested in quite a while now, but I’ve fallen out of practice as of late. I was really excited to see that there was a bunch of content on visual regression testing planned for the camp, much of which was focused around BackstopJS. I’ve tried a number of other solutions in the past (Wraith, PhantomCSS, WebDriverIO) but not Backstop JS which seems to be gaining momentum in the Drupal community.

On Thursday the folks at Pantheon held a training session on BackstopJS, which I attended. It provided a great overview of how they use the tool, along with some example repositories for learning. By the end of the training I had completed a first pass at adding a suite of regression tests to this blog. I would have liked to see a little more content in the training about the general functionality of BackstopJS rather than the Pantheon team’s use cases, but any training where I can walk out with a real world example implemented is a big win.

Continuing on the Backstop train I also doubled down and attended Ryan Bateman from Hook 42’s session on BackstopJS. He provided a little more of the general functional overview that I was looking for after the training, and also talked about the Backstop Generator module that he had recently created. Backstop generator allows you to quickly create a backstop.json file that tests against specific pages on your site and/or a random selection of pages. Seems like a great way for Drupal projects to take advantage of BackstopJS with very little effort. It was also great getting a chance to talk with Ryan later on in the camp - I think he stands as the only Alaskan Drupalist I’ve ever met.

Due to travel I wasn’t able to catch David Stinemetze from Rackspace’s related Archiving and Visual Regression Using Drupal 8 session, but I’m planning on catching up on the video later.

Community

Texas Camp featured two very excellent keynotes that I was lucky enough to enjoy over breakfast burritos. Both are very much worth watching, so rather than try to recap, I’ll just paraphrase a few things that really stuck with me.

Nikki Stevens - Breaking the Binary: The Politics of Code and Inclusivity in Technology

• Diversity is being invited to the party. Inclusion is being asked to dance.
• Small choices matter and create new futures.
• Forms on a website can influence real world behavior.

Michael Schmid - The Future of Drupal

• Change is what keeps us alive.
• JavaScript is taking over the web.
• The market is (Squarespace, Wix, etc.) is pushing us in the direction of 'ambitious digital experiences'

A Whole Bunch of Me Talking at People on Friday

I was initially scheduled to do my UI Patterns Talk, but was also asked to fill in for a presenter who was unable to attend. As a result I got to give two talks in a single afternoon. This is fine for me because I love hearing myself talk, but to the brave souls who attended both of my sessions - I salute you.

Component Based Theming With UI Patterns

Was exceptionally happy with the lively Q&A that followed the session. Even if you've heard me give this talk before, I'd encourage you to jump to the Q&A at the end.

Hot JAMS(tack): Building a Music Discovery App with Drupal and React

It was fun revisiting this talk after DrupalCon, but I was especially excited to hear from people who either have, or were planning to use the examples in this project to learn more about decoupled Drupal and React. That was main motivation behind the talk in the first place, so I'm extremely happy that this project may have helped a few people find a starting point to experiment with decoupled Drupal and React.

Other Sessions

I also caught a handful of other great talks.

• Web Accessibility Tips and Tools - provided an excellent overview of a11y resources, many of which are outlined in this google doc.
• Manifesto-Driven Development - an interesting look at influential tech manifestos and how you could use one to define the direction of a project. Thinking about writing one for an upcoming project.
• Decoupling Edutopia.org - a fascinating look at a complicated, highly performant decoupled build. I was impressed by some of the technical solutions but left wondering if the effort outweighed the benefit in this case.

Fun!

Had some great BBQ and craft beer at the after parties, and can't stress enough how convenient it was having breakfast tacos around to start the day. And then Saturday night I met up with some old Boston friends and did the tourist-y bat bridge thing, saw a fun band called Quiet Company play at Stubbs BBQ, and closed out the night with some Austin food trucks.

All in all, a great trip. And I barely got this post online before the end of the next camp on my list.

Jen Simmons’s suggestion is spot-on: it just got a lot more important to design from a sensible, small screen-friendly document structure built atop semantic HTML.

I'm less excited about WebKit coming to watchOS than I am about the overall impact it will have. The more we focus on developing experiences that can be consumed at any size on any fidelity device, the better the web will become.

Nice post from Erik Runyon about some of the technical specifics as well.

Sometimes, a CMS gets built and the work is done. It gets used by content editors and is occasionally upgraded, but the development team and budgets are reallocated to other priorities, and the world moves on. This pattern is especially common with time-sensitive projects (event websites, marketing campaigns, etc.).

Design systems don’t make sense here because a design system demonstrates its value in times of active development. It’s when a designer is working on a new notification message and needs to know what colors to use. Or when a developer is building a new form and needs to see what field types already exist.

If you don’t anticipate a lot of new development on a project, then a robust design system may not make sense.

Had some related discussion in the Q&A during during my UI Patterns session at Texas Camp this weekend - specifically on the actual value of creating an external pattern library in a typical Drupal project. I'm a believer that even just the opportunities to decouple front end and backend efforts can be worth the effort in many projects, but I also agree that you need to sensible in the amount of effort that gets invested into the pattern library. If the pattern library starts to feel like its own product, you might be going overboard. This post encapsulates those concerns pretty nicely.

tldr; I’ve recently been working on the UI Patterns Pattern Lab module which automatically discovers components in a Pattern Lab instance for use with Drupal. I’m looking to test it with a variety of Pattern Lab instances - can you help?

If we’ve run into each other at Drupal camps over the past couple of years, you’ve probably heard me talk about component based development and most likely also the UI Patterns Module. I’m a big supporter of a pattern library driven approach to building a Drupal site, but also feel that some common practices can be complicated - especially for those new to the approach or those not focused on the front end. In my opinion, UI Patterns can reduce that complexity quite a bit.

When the UI Patterns module came along it seemed too good to be true. It allowed patterns to be formally defined as Drupal plugins and took the data mapping that was commonly happening behind the scenes in Twig templates and exposed these in the admin UI where a wider audience could configure and understand them. But if you were using an external pattern library in your project, configuring these patterns for use with the UI Patterns module felt a little redundant.

In Pattern Lab for example you would commonly have a json or yaml file that specified sample data for each of the fields in your pattern. Much of that same data would be once again defined in the yaml file for the related UI Pattern in Drupal. The UI Patterns project has always envisioned that there would eventually be supporting modules that could automatically discover patterns from pattern libraries like Pattern Lab and Fractal, which would make it unnecessary to re-define patterns for use with Drupal. The module even contains classes that could be extended for this purpose. But similar to my initial feelings about the module, that just sounded too good to be true.

I should have seen this coming, but it might not be too good to be true after all.

On an issue in the UI Patterns repository, Pierre Dureau shared his work creating such an integration module for use with UI Patterns and Fractal. It made a lot of sense to me when I looked at the code, and seemed like something that would be reasonable to adapt to a Pattern Lab version. I asked around to see if folks would be cool with me taking a shot at that, and the UI Patterns Pattern Lab module was born.

As of now, UI Patterns Pattern Lab supports the following:

• Discovering UI Patterns that exist in the templates directory in any module or theme, or any custom twig namespace defined in a theme. Discovered patterns must have a pattern definition file in json or yaml, and a related twig template.
• Creating a library that includes css or js assets associated with your pattern.
• Parsing documentation from a related pattern documentation markdown file.
• Overriding default discovery behavior via variables in the pattern definition file.

More detailed documentation is available in the documentation guide on Drupal.org

So the call for help part…

I think that the more Pattern Lab instances we can test this against, the more useful it can be (I did some initial testing using Emulsify and was able to fix a handful of bugs as a result.) If you have a Pattern Lab instance that you’d be willing to try with the module (or even just one you’d be willing to share with me), it would be a huge help.

There are a wide variety of ways to configure patterns in Pattern Lab, so don’t be surprised if your pattern library is the one that causes the module to blow up. Also, the thing I’m struggling with right now is how realistic is is to use this with an existing pattern lab instance, especially ones that were set up to do a lot of complicated mapping in twig templates. It remains to be seen if the real use of this module would be with existing pattern lab instance, or along side a pattern library built with this approach in mind. Hopefully after putting this through the paces with a handful of Pattern Lab instances a trend will become obvious.

I’d appreciate any of the help you or your pattern library can lend here. Feel free to get in touch, or comment on this github issue. Thanks!

In an effort to stay on the absolute cutting edge of web technology, I've added an RSS Feed. Enjoy!