Storybook to the rescue

Creating durable UI is hard: a flaming juggle of state management, business logic, styling rules, responsiveness, browser support, evolving tools, flaky APIs, dependency graphs, etc. Now try to stay on top of that over time 🔥

Mark Dalgleish on Twitter

Developers during hackathon: We built an entire application in just 3 days. Developers after hackathon: Adding that icon is going to take 3 weeks.

Fortunately, in recent years, Storybook has quietly begun to revolutionize UI development. The open-source project is now used by over 30,000 projects, including brands like Shopify, IBM, Salesforce, and Airbnb. With zero-configuration integration with popular frameworks and the ability to develop and test UI components in isolated environments, it’s no wonder developers have flocked to it.

But why should developers have all the fun? For the first time, Storybook for Teams puts your Storybooks within reach for every teammate. Whether a designer, product manager, UX researcher, or marketer — everyone on your team can securely log in and access your latest UI source of truth.

Storybook, now for your whole team

Why would the rest of your team want to use Storybook? A few crackling reasons: It’s a component explorer, QA playground, development workbench, demo environment, prop documentation, usage examples, and much more depending on what else you add on. When you consider the communication overhead reduction of rallying your entire team around Storybook as a source of truth, the implications are staggering. If only it were easy to use in a whole-team setting…

Everyone on the same page(s)

How does Storybook for Teams work?

1. Create an account
2. Connect your team’s GitHub organization(s)
3. Voila! all of your Storybooks and all of their branches, always up-to-date
4. Invite your teammates to your secure team dashboard for ongoing collaboration

Note the lack of tango’ing with a terminal! We’ve done a lot of work to make the initial setup a pain-free experience. Behind the scenes, Storybook for Teams utilizes a state-of-the-art continuous integration pipeline — building feature-branches every time a developer pushes a git commit. Imagine Travis-CI but for UI components.

Designing a new feature? Explore your team’s UI component vocabulary and get a feel for how each one consumes data in the real world. Crank out new UI designs with speed and confidence in how your work will snap into your app.

Want to reference your component designs from Figma, Abstract (Sketch and Adobe XD) within Storybook? Storybook Addons have you covered there as well.

Have you developed an upgraded version of a component? Push your changes to a new branch and send a link to your designers and PMs for visual review and sign-off. With deep-linking to components on specific branches, your team always has an up-to-date, universal reference point for discussion. Everyone stays in sync with production code.

The next chapters

Storybook for Teams is built & maintained by Haiku, where we’re working to connect creators of software with tools that bridge long-standing gaps in collaboration.

UI components
at everyone’s fingertips — 
teamwork paradise

What’s next? In the near term, we’ll be releasing new features to make collaboration more streamlined and efficient. Give us a shout @haikuforteams and let us know what you’d like to see!

Soon we’re releasing a powerful set of commenting features — to enable designers, developers, and PMs to give feedback on specific components on specific branches. No more tracking down UI feedback over multiple platforms & design files or painstakingly communicating reproduction instructions.

What about the medium-term? You may have seen another project from the Haiku team: Diez, the design language framework. Wouldn’t it be nice for Storybook to have first-class support for design tokens? What about support for native UI components?

Keep your eyes peeled over the months to come. We’re just getting started.

– The Haiku Team

Introducing Storybook for Teams was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Haiku team is super proud to launch a new open source project today: Diez, the design language framework. diez.org

Diez radically reduces the cost of delivering a consistent visual identity across your company’s apps & websites.

Haiku’s mission is to revolutionize the way that teams create software — by unifying design & code. Diez’s framework for design languages sits right at the gap between design and code, and it addresses a real problem affecting any company that ships software: delivering a consistent visual identity (a.k.a. brand) across their apps & websites.

Diez represents a big move toward executing our team’s mission: it’s been under development for a year and a closed beta for the last six months. And now it’s all open source on GitHub for the whole world to use!

Read the whole story on the Diez community blog: https://medium.com/dieznative/diez-is-now-open-source-cfaa719f4ade

Or head on over to diez.org

Haiku Releases Diez Today, Open Source was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Inspired by project forks in software development, forking a project in Haiku makes a copy of it which you can freely experiment on, without affecting the original project.

Forks represent a simple but powerful way learn from each other’s projects, kickstart your design and development process, or simply customise existing components.

Managing Forks🍴

When creating a project in Haiku, you now have the option to make your project private or public. Public projects are discoverable on your share.haiku.ai profile, and we’re regularly featuring our favourite haiku on the showcase homepage. Public projects can be viewed, forked, and installed by anyone.

You can also give kudos to each other’s projects to show your appreciation.

What’s new in Haiku

Aside from launching the community showcase, we’re also constantly improving and adding new features for designers and developers to Haiku for Mac. This spring, so far we’ve added:

Draggable timeline rows

Stage resizing from all sides

Custom origins

Multi select

All new Autocomplete

In memory undo/redo

Proxy Settings

…along with support for Figma projects, hundreds of bug fixes and performance improvements across the board.

Looking forward

Today’s launch marks our first steps towards empowering users to experiment with each other’s creations in Haiku. We’re really excited about these features, and the foundation they provide to build a platform that allows you to do your best work.

We have lots more planned on this front, so stay tuned! If you’ve made it this far, you should head over to haiku.ai and get Haiku for Mac.

Keep up to date with the latest on:

• Twitter
• Facebook
• Instagram
• Slack

Originally published at www.haiku.ai.

Kickstart Design & Development with Forks 🍴 was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve dreamed of this, too! This is why we set out to build Haiku, a tool for designing and building animated, cross-platform UI components. Our mission is to bring design and code closer together — and to do this, we do a lot of integrating.

Haiku integrates with Sketch so you can use familiar drawing tools; it integrates with Git and npm so that designers and developers can work with a shared version history; it integrates with Lottie so you can export native animations for Android and iOS; and it integrates with React so that your designed components work seamlessly with any React web app.

Now Haiku integrates with Vue, too. This means Haiku components are first-class citizens in Vue applications. Pull components in through npm, nest them with other Vue components, pass in live data through props — it’s the same Vue you know and love, but a lot more animated.

Here’s Evan You’s take on it: (the creator of Vue)

Evan You on Twitter

Quite impressed with @HaikuForTeams - allows you to design complex animations with GUI and use in an existing Vue app as a component: https://t.co/3WaS37paNS

Let me show you an example. I’ve crafted a very simple Whac-A-Mole game: all the animation and logic related to the game itself is handled internally by the Haiku component while the score tracking is handled by Vue. The component is able to communicate back and forth with the Vue app with ease.

Haiku automatically hosts Git repositories for every project you create (private by default). Here’s the source for this component.

In this post we’ll explore the basics of Haiku Core, the rendering engine that powers Haiku for Mac, as well as the new Vue adapter, while showing how we built out the adapter itself.

Haiku Core

Haiku Core itself is a platform-agnostic UI component library. Give it a JavaScript object that fits the specification of a Haiku component, and it will give you an object that describes how it should be rendered.

But just describing how to render isn’t very interesting or useful. Normally, you want to see something on your screen! That’s where the concept of adapters comes in.

In Haiku Core, adapters take care of turning the rendering and layout returned by the engine into an actual visible, animated, and interactive element — inside whatever the host platform is. Out of the box, Haiku Core ships with a DOM adapter (for rendering in web pages), a React DOM adapter (for rendering Haiku components inside React DOM components), and the Vue.js adapter. You can also export Haiku projects to Lottie, for native animation rendering on iOS, Android, and React.

Before diving into adapter-specific code, let’s take a peek into the internals of Haiku Core and its relationship with Haiku for Mac in order to discover some of Haiku Core’s possibilities and features.

Your design is code

With Haiku for Mac anyone can build interactive components for any web page or native app.

When you design in Haiku, you’re writing code (well, Haiku does it for you). And when you edit the code, you’re updating the design. This bridge between design and code goes both ways. This works because the Haiku design format is no more than a JavaScript object, which Haiku for Mac knows how to read and write.

We informally call this normalized definition of a component the bytecode. This way of representing components enables Haiku to provide an amazing set of features such as shared version histories for designers and developers.

From bytecode to live components

Here’s an example of a simple component definition, to get a taste of what it looks like:

const definition = {
  timelines: {
    Default: {
      '#box': {
        // You can provide layout and style definitions...
        'style.width': {0: {value: '100px'}},
        'style.height': {0: {value: '100px'}},
        'style.backgroundColor': {0: {value: 'steelblue'}},
        // ...and you can also animate them!
        'rotation.z': {
          0: {value: 0, curve: 'linear'},
          2000: {value: 2 * Math.PI}
        }
      }
    }
  },
  template: `
    <div id="box">Hello Animation!</div>
  `
};

In order to render this component definition, Core needs a DOM element to attach the component and an optional set of options that allows you interact with your it by providing live data, hooking into its lifecycle events and more.

ADVANCED: Building the wrapper

If you want to use Haiku to design and build app components, you’ve already read far enough. However, if you want to know more about the internals, or would like to integrate Haiku with another library (looking at you, Angular!) then read on.

Now that we have a basic understanding of what’s behind the covers, let’s create a Vue wrapper that can be used for consumers of Core to render idiomatic components.

Inside of this component, we need to tell to Core where and how to attach our haiku, and we are going to do this by taking advantage of Vue lifecycle hooks:

• When the component is mounted, we are going to create an instance of our haiku, just like we did in with our sample component definition above.
• When the component is destroyed, we are going to let know to our haiku that is being unmounted by calling the component instance method callUnmount.

Lastly, we are going to define a render function that it’s going to render an empty div which we can use to attach our component:

const vueWrapper = {
  mounted() {
    this.haiku = factory(this.$el, {});
  },
  destroyed() {
    this.haiku.callUnmount();
  },
  render(createElement) {
    return createElement('div', {});
  }
};

Accepting options

As we saw before, Core is able to receive options, and our component is going to receive them via props.

But, since props can be updated once the component is already rendered, we also need to use the updated lifecycle hook to update the haiku instance with the new configuration by taking advantage of the haiku component instance method assignConfig.

Note: in this example, we are only accepting haikuOptions and haikuStates, but Core supports even more configuration options!

const vueWrapper = {
  props: {
    haikuOptions: Object,
    haikuStates: Object
  },
  mounted() {
    this.haiku = factory(this.$el, {
      options: this.$props.haikuOptions,
      states: this.$props.haikuStates
    });
  },
  updated() {
    this.haiku.assignConfig({
      options: this.$props.haikuOptions,
      states: this.$props.haikuStates
    });
  },
  render(createElement) {
    return createElement('div', {});
  }
};

Lifecycle events

A Haiku component also provides lifecycle hooks that are modeled after React lifecycle hooks.

Since Vue exposes a special syntax to deal with events, we want our wrapper to embrace it by providing an interface that looks like this:

<my-component :haikuComponentDidMount="myFunc"></my-component>

Haiku lifecycle hooks are declared in the config object that you pass to Core, so we’ll need to update our mounted function with the proper hooks, adding a $emit call every time an event is triggered:

const vueWrapper = {
  //...
  mounted() {
    //...
    this.haiku = factory(this.$el, {
      //...
      onHaikuComponentWillInitialize: (component) => {
        this.$emit('haikuComponentWillInitialize', component);
      },
      onHaikuComponentDidMount: (component) => {
        this.$emit('haikuComponentDidMount', component);
      },
      onHaikuComponentWillMount: (component) => {
        this.$emit('haikuComponentWillMount', component);
      },
      onHaikuComponentDidInitialize: (component) => {
        this.$emit('haikuComponentDidInitialize', component);
      },
      onHaikuComponentWillUnmount: (component) => {
        this.$emit('haikuComponentWillUnmount', component);
      }
    });
  }
};

Wrapping it up

And that’s it! The real adapter has some subtleties related to rendering and adaptation to the codebase, but that is the gist of it. If you want to see the full code, please take a look — it’s all open source.

If you want to build an adapter for your favorite framework, we are open source and very much enjoy pull requests! If you need any help to do so, please ping us in our Slack Community.

Originally published at www.haiku.ai.

Vue Animations with Sketch + Haiku was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I want to start by emphasizing that what we’ll be making is a real component. Haiku are all SVG and work on iOS, Android, and the Web. They’re stateful, programmable and best of all, you, the designer, retain control over your creations even after they’ve been integrated. But why does that matter?

The Trouble with Design Tooling

Users’ expectations have evolved past simple screen-to-screen transitions — the best apps now provide thoughtfully choreographed interactions to guide users’ every move. But even the latest and greatest screen design tooling isn’t helping us make this leap. We’re stuck trying to brute force artboards into describing complex states. We wrestle symbols, overrides, layout constraints, dynamic data, and design systems, only to create artifacts that aren’t the real thing. It leaves quite a few of us bashing into this realization:

Mike on Twitter

@markdalgleish @mrmrs_ Crafting a Sketch Library with clever symbol overrides was so gosh darn complicated compared to code

At Haiku we believe designers deserve something more powerful than the ability to draw magic lines between screens; more real than symbols that fall out of sync with production apps.

What might this look like? Glad you asked. We have a series of upcoming posts that will provide the full picture. Today we’re going to focus only on a piece of it: Actions.

Introducing Haiku Actions

Actions are small snippets of code (JavaScript) with a lot of power. We’ve designed actions to be accessible to people who only know a little code, or who want to learn — as well as to engineering veterans.

To be clear: you don’t have to code to use Haiku. Actions are completely optional, and you can stay strictly in the timeline and the stage, or you can dive right into the code. Haiku invites you to bring your own skills to the creative table.

You can use Actions to:

• Travel through time by changing the timeline position
• Respond to user input
• Work with real data
• Change properties of app elements (think: position, color, etc,)
• And more! The rabbit hole runs deep, as you have all of JavaScript at your fingertips.

Using Actions to travel through time

Let’s dive into exploring how to make an interactive experience in Haiku. For the sake of simplicity, we’ll run the entire example on a single timeline; within a single component. A lot can be achieved even with these constraints. From the first gif you may have noticed that the first portion of the timeline showing movement in the water loops until the user clicks the ‘Check Out’ button.

This is achieved with a Frame Action — an event that is triggered every time a frame is crossed. We’ve put ours on frame 518 and instructed it to go back and replay from the beginning (time 0). See below:

With this Frame Action in play, the timeline will never cross this frame on its own — it will respect the command to jump back and repeat from the beginning. The selected snippet is simply inserting JavaScript. By the end of this tutorial you should be reassured that you don’t need to know JavaScript to be able to achieve the behavior you’re pursuing. Most tasks can be accomplished by inserting a snippet and knowing to which point in time you’d like to travel. Don’t believe me? Let’s time travel again; this time when the user clicks the ‘Check Out’ button.

Using Actions to respond to user input

Let’s add an Element Action this time that will tell the timeline to jump past our Frame Action and play our finale sequence. This section begins on millisecond 8780, so let’s instruct the button to play the timeline from that point.

With just these two Actions — one on a Frame and one on an Element— we’ve achieved a quite a lot, wouldn’t you say?

Properties that listen

Let’s continue exploring. You may be familiar with using simple formulas in spreadsheets to create dynamic equations.

It’s a simple and clear, yet powerful provision for referencing a value stored in one cell and using it in another in a new way. We’ve taken this construct and put it into all of our property inputs inside of Haiku. We call them Expressions. Our inputs can, of course, take a simple value, but they become dynamic expressions when you start them with an “=”.

Let’s make our static ‘Check Out’ button dynamic by telling its horizontal position to reflect a small percentage of the user’s mouse position.

Following the same pattern for the button’s Position Y, we can achieve a dynamic effect that draws attention to the call to action.

Haiku’s Expression Inputs can also listen to States. You’re able to define and alter these States to create a virtually limitless amount of dynamic interactivity. We’ll leave that piece for the next tutorial, where we will demonstrate how to pass dynamic data into your Haiku creations, as well as how to drop them into your codebase.

Thanks for reading! Be sure to subscribe to our publication here on Medium and follow us on our social channels for updates.

• Twitter
• Facebook
• Instagram
• Slack

Designing the Real Thing with Haiku Actions was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Paul Stamatiou 📷 on Twitter

If you're a designer, please learn motion design skills. At 60fps there's 58 frames you need to design between Mock A and Mock B" #io14

Sadly, most modern design tools and workflows aren’t set up to let designers actually design those 58 frames.

Today’s popular workflows revolve around creating throwaway prototypes used to communicate to developers who then painstakingly recreate animations to the best of their eyes and ability in code.

Not only is this a waste of time and resources, but the process is so fatiguing that even seasoned designers and developers end up settling for “good enough” implementations. And if they want to iterate on their designs after trying out a concept, they’re back starting again from square one.

Haiku is different

Haiku is a modern design tool that empowers designers and developers to build imaginative UI components. Code optional. With its visual timeline, it’s easy to design interfaces powered by motion.

Everything authored in Haiku is production ready, and once integrated with your codebase you can continue to iterate on your designs. No hand off necessary.

Thinking in time and space

Before we roll up our sleeves in Haiku, it’s useful to think about how we want to translate our designs into motion, by thinking like an animator—in time and space.

If you’re new to motion, one simple way to do that is to storyboard.

Storyboards were popularised by Walt Disney Productions in the 1930's as a way for animators and directors to communicate a story as a sequence. In interaction design, storyboards can help us determine:

• What elements we’ll need
• What properties we’ll manipulate
• What keyframes we’ll begin with (more on those later)

For example, let’s storyboard a bouncing ball, which we’ll use to get started in Haiku:

From this simple storyboard, we can determine:

• We need 2 elements; the ball and the shadow
• We’ll want to modify the position of the ball, the scale of the ball and opacity of the shadow
• We need at least 3 keyframes for our animation to seamlessly loop

When storyboarding, try not to get hung up on small details — a lot of the magic in motion happens when animating and iterating on your designs visually. Just figure out enough to get started.

Getting started with Haiku

Working with Sketch

In Haiku, there’s 2 ways to work with Sketch— you can either import an existing Sketch file or create new designs from scratch.

If you want to start on a new design, the best way to do that is to begin designing in the boilerplate Sketch file included in every Haiku project. Just double click to edit:

You can also import existing Sketch & SVG files:

Haiku looks for artboards and slices and smartly imports them as separate elements in your library. After drawing your ball and shadow, the easiest way to convert your shapes into slices is to mark them as ‘Make Exportable’ in Sketch:

After hitting save, your Sketch slices will appear in your Haiku library:

You can then drag elements from the library to the stage:

Whenever a property is edited, Haiku automatically creates a keyframe where the playhead is positioned. Think of keyframes the same way you would frames in our original storyboard.

Properties can be edited directly in the timeline, or by manipulating elements visually on the stage:

Now that our keyframes are set up, let’s smoothly ease between them using the built-in tween library by right clicking in the timeline. I’m using Ease In → Cubic and Ease Out → Cubic but I’d recommend experimenting with different tweens to find the right one for your animation:

Using the basic techniques we just employed, it’s easy to add more detail. Adding keyframes part way through the timeline to reveal the shadow when the ball is near:

And squashing the ball vertically to emulate physics:

Publishing generates a unique Share URL you can use to share with others:

The share page lets you preview your haiku on the web with embed instructions:

Everything created in Haiku is pure JS/CSS ready to snap into any web app, with native renderers for iOS & Android powered by Lottie.

That’s a wrap!

If you’ve made it this far, you should probably sign up for the private beta if you haven’t already. If you have any questions, feel free to reach out in the comments below.

You can also keep up to date with the latest on:

• Twitter
• Facebook
• Instagram
• Slack

Motion design for the web, iOS & Android with Haiku was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lottie Who?

The process of creating motion for mobile felt broken up until Airbnb released a stunning open source library called Lottie. Prior to then (Feb. 2017), creating complex mobile animations required an arduous back-and-forth between designers and developers.

Designers would create prototypes for developers who would have to either recreate them by hand in multiple languages (once for Android and once for iOS), or choose to embed large non-scaling GIFs or image sprites. But Lottie changed all of that, rendering intricate, scalable animations for both iOS and Android with the ease of including a static image. Swiftkey, for example, swapped out a .png sequence at 6mb in size for a Lottie .json of just 340kb. The pristine fidelity and download savings have an enormous impact on the user experience.

It’s a big deal to have this power, and droves of designers are scheduling time out of their weekends to learn the new toolchain. But it’s surprisingly complex.

Lottie’s reliance on After Effects

Lottie relies on Adobe After Effects (AE) as its animation creation tool. AE’s brilliance is undeniable — it’s the industry standard for animating cinematic movie titles, intros, and transitions. But with the power comes a labyrinth of complexity (many features being unsupported by Lottie and UI animation in general). AE’s capabilities make it nontrivial to learn, and sadly the steep curve puts using Lottie out of reach for many designers.

As we imagine the ideal set of tools for UI motion design, we can’t help but wonder if AE is really the right companion for Lottie. After all, AE being used for UI motion design is beyond its original scope. The situation feels analogous to 2005, when designers were relying heavily on Photoshop as a UI design tool — not because it was made for the type of work, but because there was nothing better suited on the market. Then along came Sketch, a tool with a pure UI design focus.

What if there were an “After Effects” that was intended for app motion and interaction design?

A new way to Lottie

We designed Haiku from the ground up for animating UI components. Like Sketch, it is a simple tool with a specific purpose, and like AE, it is compatible with Lottie.

Our users are saying that it’s more intuitive to animate, and generally much easier to get up and running than AE. You’re not required to download and install special third-party plug-ins for both Sketch and After Effects, then learn to animate using the subset of features that are supported. You simply create animations in Haiku and publish.

After publishing, you’re able to choose to use Lottie as your player (for native applications), or to use our own player (web only for now) where your animations can respond to user interaction.

On top of that, we have a little something up our sleeve we’re calling Live Design. Imagine making a change in your drawing tool (Sketch) and seeing it instantly update in Haiku, your application’s codebase, and across all of the production platforms you’re targeting. That’d truly be an unprecedented connection for design and development teams — the backbone of a connected design system.

There’s recently been a lot of buzz about design tools implementing “design system managers” when they are in reality merely static pictures of design systems. We think there’s a better way forward — that a design system should be a living set of components. With Haiku it can be just that, and it’s a big difference. We’re going to release Live Design into the app soon. Until then, here’s a quick teaser of just how satisfying this paradigm-shifting workflow feels.

Full disclosure: Haiku is currently in a private preview and there’s still a few things you can do in After Effects that you’re not yet able to in Haiku, such as shape morphing and masks. These are important features and we’re working on bringing them into the app as soon as possible. That said, Haiku already has many features that AE doesn’t (Live Design, Interactions, Events, States). We hope our vision to empower designers inspires you to try out our private beta.

Sign up and see what users are creating over at www.haiku.ai.

Lottie without After Effects was originally published in Haiku Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.