Michæl Graves

Groundskeeper @ gskinner.

Google, Adobe, gskinner | Flutter Interact ’19

Flutter is a mobile UI toolkit that combines fast development, expressive and beautiful UIs, with native performance. To test-drive the platform, Grant Skinner & Mike Chambers recently built Redrix: a mobile companion app for Destiny 2.

Download Redrix on iOS or Android

In the short time since, in preparation for Flutter Interact ‘19, we’ve been collaborating with Google & Adobe to showcase the capabilities and potential of the platform.

With an open brief from Google, we were given the freedom to create expressive experiences with the purpose of inspiring and empowering designers and developers to explore the capabilities of Flutter and learn how easy it can be to elevate UI.

We created 17 distinct vignettes spanning a range of UI concepts and styles targeting different devices and screen sizes. They’re all released open-source (under the permissive MIT license) on our dedicated vignettes showcase website.


We established some high-level goals for the vignettes:

  • real-world: representative of pragmatic & relatable scenarios for apps (with an occasional fun, novel piece sprinkled in)
  • approachable: simple enough to help creators get started quickly
  • delightful: thoughtful & fun motion, interactions, and design

After dedicating time to charge up our own inspiration — researching the most beautiful interactive designs we’ve seen — we compiled a list of ideas, rough sketches and descriptions for potential vignettes.

We reviewed and prioritized the ones that would best achieve our goals. Our designers started working on visual language, illustrations, interactive models, and motion design prototypes.

In parallel, our dev team started building Flutter widgets: modular, re-usable elements used across numerous vignettes for common tasks, such as masking, sprite sequences, and simple 3D rendering. These serve as take-aways for developers to utilize in their own Flutter projects.

We set guidelines for design & development: the architecture and code for all the vignettes should feel like a single, cohesive, and approachable unit. We favored readability over optimization; simplicity over intricacy.

As our vignettes came to life, we earmarked time to share, critique, and prioritize. These sessions informed our iterations & effort, weighed against our timelines.

Near Real-Time Iteration

Hot-reload in Flutter is a game-changer for productive iteration — our design team could critique & communicate concepts, tweaks, and polish to developers to make changes right before their eyes: no recompiling, no deploying a new build for review. No wasted cycles.

We even performed critiques and applied real-time feedback remotely through screen-sharing. The feedback loop almost disappeared; designers and developers working in unison, applying discrete talents towards the same goal simultaneously.

We’re a bit smitten with hot-reload in Flutter.

It’s a testament to the Flutter team, that despite our ambitious vision for the vignettes, our biggest challenge was a familiar one — timelines.

XD to Flutter Plugin

To create our Flutter vignettes, all the UI was hand-coded.

If you’ve poked around our blog for the past 17 years (!) you know we have a long history of building tools, utilities, and workflow enhancements for Adobe products.

As such, we are incredibly excited to be working with the Adobe XD team on their integration with Flutter.

The goal is to empower creators to use familiar design and layout tools & workflows in Adobe XD, and generate Dart code to use in their Flutter apps — streamlining designer and developer collaboration to go from idea, to prototype, to working product, faster.

Leveraging a fairly complex view in Redrix, we re-created the design in Adobe XD, which is exported as a near pixel-perfect view in Flutter. It additionally offers functionality to export elements as re-usable Flutter widgets, complete with configurable instance parameters.

Paired with hot reload, you can make design changes in Adobe XD, and see them instantly reflected in Flutter on a simulator or device.

In 2020, we plan to continue helping Adobe to evolve this tool and release an open-source XD plugin.

If there are specific features or functionality you’d love to see, leave a comment and we’ll add it to the wishlist. You can sign up for early access here.

5 Times When You Absolutely Must Write Tests For Your Code

It’s my opinion that you should always write tests for your source code. Tests force you to code better. Tests allow you to write dependable code, create better architecture, and help you live longer*. They also help you spot fussy APIs, opportunities for reuse, and redundancies.

That said. You don’t always have the time (or budget) to test everything to death! Not everyone sees the value in all those little green checkmarks. Life isn’t pedantic and heavy-handed. Life is a pack wild horses and sometimes you need to be the cowboy.

So, when do you push back? When do you say NO! We must write tests!

1. When you have the time.

There is no reason to skip out on writing tests if you have the time to write them. Why would you opt out of better code? Taking the extra time to make your code testable will turn average code into dependable code. Code that you know actually works is almost always better than new code.

2. When you’re making a data structure.

You cannot make a data structure without writing tests for it. Why would anyone trust a data structure that cannot prove it works?

Data structures must be tested. I don’t even know how you’d code a data structure without setting up a test harness first. You don’t know how your code will be used, so knowing that every little piece works as expected is necessary.

With tests, you’ll see the logic in breaking code into small pieces. Tests will make it easier to spot problems in your architecture.

Writing data structures against a test suite is the only way to do it right.

3. When you want community contributions.

Tests are the backbone of any open source project. They make sure that community contributions do not break the codebase. This allows fixes, changes, and optimizations to be made with certainty.

Your test suite becomes the hurdle that any contributor must clear. It’s not too much to ask for contributions that prove they work.

4. When you’re designing an API.

Starting with a test suite is a great way to design an API.

This allows you to work backward from your code interface instead of coding to it. This will let you design an API from the user’s perspective first.

5. When it is a dependency

Point blank. If other code needs to use this code, you must write a test for it.

The testable code will become part of an ever-expanding toolbox. Dependable toy soldiers who can be summoned to fight for you. Go! Test the world!

Here are a few resources to help you start writing tests for your code.
Node.JS Assert
Writing good tests

*There is no scientific data that shows writing tests will help you live longer.

Explaining Patterns and Matches in RegExr

RegExr 2.0 was released a little over 2 years ago. If you haven’t used it, it is a great way to test, preview, and share Regular Expressions. We’re committed to updating and improving RegExr, and in January we quietly pushed out some features to help inspect and explain patterns.

Check out RegExr here.

The New “Tools” Bar

Initially, RegExr only had one tool, the “substitution” panel, which let users show sample text with matches substituted using an expression. It was hidden by default, unless a pattern included a substitution expression. This tool has been renamed “replace”, and is now part of a larger “tools” bar, which we hope to continue growing in the future. In the meantime, it has a few other useful tools that I’ll describe below in more detail. Continue reading →