First, we’ve been producing award-winning interactive media, installations, and cutting edge interfaces for more than a decade. Flow is the culmination of all of those years of practice and of immersing ourselves in art, tech, and design. We’ve used pretty much every piece of software you can think of, and draw on all our experience to produce Flow. If you want to dive into our background, please check out The Roots of Flow.

Second, we’re experts at writing animation software. Our roots in this started way, way, waaaaay, back with Processing (Java), OpenFrameworks (C++), and transitioned to Objective-C and every version of Swift and Core Animation along the way. Then we jumped to the web where we’re confident in saying “we know our shit” when it comes to the most advanced, native approach for creating animations in the browser: the Web Animations API. Along the way we’ve learned a lot of tricks, and all of that experience is manifest in Flow’s code export. We’ve published a high-level article of our thoughts on Control, Craftsmanship and Code Export that is definitely worth a read.

If you’re reading this article because you’re looking for proof that Flow lives up to its claim, that it ships Production-Ready software, then you’re in for a treat.

Preface: A Swift Context

Flow can generate many different kinds of media files and software, which makes it difficult to show a complete and comprehensive account of every design and architectural decision we made in the production of its code export capability. However, the decision-making and philosophy behind our approach to designing, architecting, and producing exported code is consistent across all formats. So, while this article will heavily focus on Swift code, Core Animation, Xcode and iOS as the basis for exploring patterns… our approach applies to all other exports.

Defining Animation

An animation can be broken down into two main categories: style and timing. By style, I mean the layout, colors, and visual form of the elements that are a part of the animation. By timing, I mean the pacing of changes to the visual style over time.

From a software point of view, these two elements can be understood as (visual) properties and timing functions.

The Syntax of Motion

In the world of iOS, the technology for rendering, composing and animating visual elements is called Core Animation — in the browser the Web Animations API is very similar. Core Animation is a powerful framework that allows a developer to configure parameters and trigger animations to occur. Two of its main strengths are that it basically hands off the compositing of animations to graphics hardware — you don’t have to worry about the in-between moments of your animations — and that it actually defines a nearly universal model for representing animation as software.

Layers

When you look at a mobile app you might see tweets, or music videos, or controls to play your favourite podcast. However, what you’re actually looking at are a complex set of layers that, when overlaid upon one another, make up the entirety of an apps interface. On iOS there are two types of layers: image layers and shape layers. These layers have properties you can set, many of which are visual — shadows, paths, images, borders, etc. — and are defined by values which are often numerical.

Here’s an example of setting a property on a layer.

ourLayer.opacity = 0.5 //set its value to 50% opacity

Most, but not all, visual properties can be animated. Here a complete list of animatable properties for iOS.

Animations

The simplest form for iOS is called an implicit animation. The default behaviour on iOS is that if a value changes, it animates over a 0.25s period.

ourLayer.position = newPosition //move an object

For a bit more control than this, the technique is to create an animation object. The animation above, when created as an object, looks like this:

let anim = CABasicAnimation(keyPath: "position") 
anim.fromValue = ourLayer.position 
anim.toValue = newPosition 
anim.duration = 1.0 ourLayer.add(anim, forKey: anim.keyPath)

The key difference here, is that when you create an animation like this you can specify parameters for the animation itself. This animation now takes 1.0s to complete its transition to move from one position to another.

Chaining Animations

Thinking about animations in this way becomes increasingly difficult when you want something more advanced to happen. Imagine you want an element to fade in and fade out. Seems simple, right? Well that animation effect actually needs to be broken down into two opacity animations.

let animIn = CABasicAnimation(keyPath: "strokeWidth")
animIn.fromValue = 0
animIn.toValue = 60
animIn.duration = 1.0
ourLayer.add(animIn, forKey: anim.keypath)
animIn.delegate = self

let animOut = CABasicAnimation(keyPath: "strokeWidth")
animOut.fromValue = 60
animOut.toValue = 0
animOut.duration = 1.0
animOut.isRemovedOnCompletion = false
animOut.fillMode = .forwards
ourLayer.add(animOut, forKey: anim.keypath)

This is actually two animations, the first from 0 ➔ 60 and the second from 60 ➔ 0.

Notice how things are getting complicated? You need to know to remove animations (or not), you need to know how to set the fillMode, and even set the delegate for the first animation.

The explicit animation approach (above) gets unruly very, very fast. The solution to this is to use keyframe animations, which let you set values and timing functions.

Here is the same animation as above, using keyframes:

let anim = CAKeyframeAnimation(keyPath: "opacity")
anim.values = [0, 60, 0]
anim.keyTimes = [0, 0.5, 1]
anim.duration = 2.0
anim.fillMode = .forwards
anim.isRemovedOnCompletion = false
ourLayer.add(anim, forKey: "opacity")

Easier. Cleaner. But, still with a level of complexity. You need to think of your animation timing in terms of values from 0…1 and how those translate to the overall duration of the animation.

Easing

Let’s have a look at easing. Here’s an animation that animates the movement of a layer from the bottom to the top of its frame and back. In iOS, the default easing curve is Ease In Out.

let anim = CAKeyframeAnimation(keyPath: "position.y")
anim.values = [100, 0, 100]
anim.keyTimes = [0, 0.5, 1]
anim.duration = 2.0
anim.fillMode = .forwards
anim.isRemovedOnCompletion = false
ourLayer.add(anim, forKey: "position.y")

Let’s say you want to use two different timing functions for each part of the animation. You would do something like this:

anim.timingFunctions = [CAMediaTimingFunction(name: .easeIn), CAMediaTimingFunction(name: .easeOut)]

Great, but the problem with this is that most animation engines have only a basic set of predefined easing curves. In iOS, these are easeIn, easeInOut, easeOut and linear. What if you wanted something custom, say from easings.net. Well, you'd have to roll your own timing function like so:

let cubic = CAMediaTimingFunction(controlPoints: 0.55, 0.055, 0.675, 0.19)
let back = CAMediaTimingFunction(controlPoints: 0.68, -0.55, 0.265, 1.55)
let custom = CAMediaTimingFunction(controlPoints: 1, 0, 0.66, 1)

Here is what these timing functions look like:

Other Animation Things

Other things to consider with animations are:

• paths
• gradients
• round corners
• groups
• snapping from one value to another
• multiple animations for multiple properties on the same layer
• reversing complex animations
• reversing complex animations with custom easing curves
• managing animation states
• adding controls (e.g. ability for a user to pause an animation)
• rotations and transforms

This is just a small, small list of things to thing about when writing out animation code, and one of the main reasons why getting animation into your apps is difficult, time consuming and expensive.

Flexible, Robust and Easy

The best way to write animation code is to be clean clean, modern and consistent. But, that’s just one part of how we approach exporting production-ready animations. The other critical component is making it easy to interact with and control the software.

A View & A Timeline

Every animation, no matter how complex, is broken down into two classes of files: a view and a timeline. This dichotomy makes it easy to identify and modify the layout of the animation, and separates the animation code into its own class that can be hot-swapped if needed.

AnimationView

An animation’s view is a subclass of UIView which means it works exactly like a native view on iOS. Each animation is given a unique name when it is exported, so you'll see things like this:

• DialedView
• GradientRingView
• GriddyView

A view gets created just like a normal UIView:

let view = DialedView(frame: frame)

After initializing, the view runs its setup and creates each layer in your animation:

private func createViews() {
  CATransaction.suppressAnimations {
    createDial()
    createMask()
    createBars()
    //etc...
  }
}

See that suppressAnimations block? That's an incredibly handy trick we created after years of mastering Core Animation.

As you can see, there will be a unique method constructing each layer:

private func createDial() {
  dial = ShapeView(frame: CGRect(x: 18.5, y: 18.5, width: 32, height: 32))
  dial.backgroundColor = UIColor.clear
  dial.layer.position = CGPoint(x: 18.5, y: 18.5)
  //etc...
}

As an added touch, we have a great method for scaling your view:

public func scale(to size: CGSize) {
  let x = size.width / Defaults.size.width
  let y = size.height / Defaults.size.height
  transform = CGAffineTransform(scaleX: x, y: y)
}

This scale method makes it really easy for a developer to quickly resize the animation based on layout constraints.

AnimationTimeline

The timeline is a unique class that encapsulates pure Core Animation code. Each timeline is given a unique name when it is exported, so you’ll see things like this:

• DialedTimeline
• GradientRingTimeline
• GriddyTimeline

The really cool thing is that you can pass a view into a timeline. This means that the timeline can be reused on multiple views — very handy for buttons that should all have the same animation.

DialedTimeline(view: dialed, duration: 2)

If you want your animation to repeat and/or reverse, there are options for that:

DialedTimeline(view: dialed, duration: 2, repeatCount: 10, autoreverses: true)

The timeline contains playback controls:

• timeline.play()
• timeline.pause()
• timeline.stop()
• timeline.reset()
• timeline.offset(to: time)

There are some other fancy controls, but you get the idea… things are straightforward.

The timeline will have a unique method that generates a keyframe animation for any animated layers in your file:

let transform_rotation_z_dial: CAKeyframeAnimation = {
  let anim = CAKeyframeAnimation()
  anim.keyPath = "transform.rotation.z"
  //etc...
  return anim
}()

Architected for Animation

Every project exported from Flow has a carefully crafted structure that employs a forward-thinking approach to integrating animations into your products.

Common Files — Not a Library

As we’ve mentioned above, animation code can be very unruly. Over the years, as we’ve come to master Core Animation, we’ve created a few tricks along the way that help make making animations easier.

These “tricks” are encapsulated in a set of files we call FlowCommon. There are two versions of this, one for iOS and the other for Web, both of which have their own CocoaPods. Most of the files in this collection are very minimal, adding a convenience function or two.

For example, the CATransaction+Extension.swift file has only this method in it:

extension CATransaction {
  static public func suppressAnimations(actions: () -> Void) {
 begin()
 setAnimationDuration(0)
 actions()
 commit()
  }
}

An incredibly handy method for turning off the default 0.25s animation during setup.

FlowCommon is not a library. The majority of files have less than 20 lines of actual code in them, so these are very easy for a developer to review and approve.

Interface Files Made Easy

Our Xcode projects have a Main.storyboard file that contains a view. For our basic iOS export, that view’s class is the unique AnimationView for your animation. The elegance of this approach means you can easily change the class of a view into an animation view via Interface Builder.

For more custom exports like our iOS Custom Activity Indicator, the animation view may be embedded dynamically into a native view.

private func setup() {
  view = createView()
  addSubview(view)
}

override func createView() -> UIView {
  return dialed
}

private lazy var dialed: DialedView = {
  let view = DialedView(frame: .zero)
  view.scale(to: frame.size)
  return startView
}()

This approach is consistent with being able to add a native component to your Interface Builder file, then simply change it’s class to the custom one exported from Flow.

Everything exported from Flow is a native component for the platform. In the case of iOS, an animation view is a UIView and an animated spinner is actually a UIActivityIndicatorView. In each case, the animation is "slipped" in to the native element.

Very Nice.

And if you look very closely, you’ll see that every project exported from Flow shows you how to add a loading animation to your app!

Trusting Generated Code

Animations can be big or small. Launch and onboarding animations are great places to put in a lot of effort, nuance and beautiful added touches. In contrast, micro-animations can create real moments of delight when users interact with otherwise mundane elements of an interface, like buttons, sliders, and loading indicators.

From a software perspective, there very little difference between the simple and complex animations. In the end, they’re just a collection of keyframe animations being triggered at the right points in time.

Animation Code is Boring

Animation code is actually a very mundane thing to write. You create a layer, set up its initial properties, you create some animations and apply them to the layer when things are supposed to kick off. You do this over, and over, and over, and over again for every property and every layer. If you do things properly, then writing animation code really just a whole bucketful of lather, rinse, repeat.

1. choose a property
2. set its value(s)
3. set its easing(s)
4. choose a duration
5. trigger it

These 5 main steps are just repeated for every layer, and every animation throughout your apps.

It’s mundane.

It’s boring.

It’s trivial and…

That’s a very good thing.

Generated Code is Trustworthy Code

When there is little variability in the kind of code that you need to produce, then using generated code is by far the best way to get things done. If you know the patterns you need to produce, you can easily set up a generator to do the heavy lifting for you. That generator will follow the rules you define, systematically, accurately, every single time.

If you trust the rules that govern the generator, then it follows that the code being generated is trustworthy.

50 Activity Indicators

Until now we’ve mostly been looking at animations from a high-level perspective. So, I’d like to end this article by looking at real-world examples of code generated from Flow.

We recently published an open-source project with 50 custom iOS Spinners, that express a wide variety of animation techniques. Here’s a few examples with some code excerpts to show how things work.

Dialed

This animation is really interesting. The effect looks really complicated, but the technique is quite simple.

We call the whole element dial , which is essentially a layer with a doughnut as a mask.

let dialMask = CAShapeLayer()
dialMask.path = CGPathCreateWithSVGString("M16,0c-8.837,0,-16,7.163,-16,16 0,8.837,7.163,16,16,16 8.837,0,16,-7.163,16,-16 0,-8.837,-7.163,-16,-16,-16zM16,8c4.418,0,8,3.582,8,8 0,4.418,-3.582,8,-8,8 -4.418,0,-8,-3.582,-8,-8 0,-4.418,3.582,-8,8,-8zM16,8")!
dial.layer.mask = dialMask

Inside that layer is a group of 5 bars of color.

dial.addSubview(bars)

The bars group moves through the mask in a downward angle.

anim.keyPath = "position.x" 
anim.values = [-34, 67]  

anim.keyPath = "position.y" 
anim.values = [-34, 67]

The top layer rotates.

anim.keyPath = "transform.rotation.z" 
anim.values = [0, 6.28319] //aka 2𝜋, aka 360° 
anim.keyTimes = [0, 1]

Griddy

Here’s an interesting visual effect that you get by running the same animation 16 times, on 16 identical squares in a grid, with their start times offset by a little bit.

The trick with this one isn’t to animate the size of the squares, rather the line widths of their edges!

anim.keyPath = "lineWidth"
anim.values = [4, 4, 0, 0, 4, 4]
anim.keyTimes = [0, 0.205479, 0.547945, 0.719178, 0.993151, 1] 
anim.timingFunctions = [.linear, CAMediaTimingFunction(controlPoints: 0.55, 0.055, 0.675, 0.19), .easeInEaseOut, CAMediaTimingFunction(controlPoints: 0.215, 0.61, 0.355, 1), CAMediaTimingFunction(controlPoints: 0.55, 0.055, 0.675, 0.19)]

As you can also see, we’re using some custom easing curves as well — specifically cubic-in and cubic-out.

Gradient Ring

You can simulate a ring with gradient color by using masks in a sneaky way.

First, create a gradient.

let startPoint = CGPoint(x: 0.5, y: -0.0450368)
let endPoint = CGPoint(x: 0.5, y: 1)
let colors = [UIColor(red: 0.463, green: 0.275, blue: 0.988, alpha: 1).cgColor, UIColor(red: 0.314, green: 0.888, blue: 0.76, alpha: 1).cgColor]

Then apply a mask:

gradient.layer.mask = foregroundCircle.layer

To make the ring, the foreground circle has a clear color:

foregroundCircle.shapeLayer.fillColor = nil

Then, animate the path of the foreground circle:

anim.keyPath = "strokeStart"
anim.values = [0.75, 0.7, 0, 0]
anim.keyTimes = [0, 0.17, 0.55, 1] 
anim.timingFunctions = [.easeInEaseOut, .easeInEaseOut, .easeInEaseOut]

anim.keyPath = "strokeEnd"
anim.values = [1.001, 1.001, 0.25, 0.25]
anim.keyTimes = [0, 0.32, 0.55, 1] 
anim.timingFunctions = [.linear, .easeInEaseOut, .easeInEaseOut]

Finesse == Flow

The animations in this article were all made with Flow, and while it is very possible to make all of these by hand, the speed at which I was able to create these and level of detail in the software would be impossible to achieve without Flow.

Take the keyTimes from the Griddy example:

anim.keyTimes = [0, 0.205479, 0.547945, 0.719178, 0.993151, 1]

The smooth poppiness of the animation comes from my playing around with the distribution of keyvalues while watching the animation on loop. Only when I was happy with the outcome did I export the animation to code. If I coded this by hand there’s no way I’d ever be able to consider these values.

Instead, I might only be able to think through them in fairly “round” numbers, which would strip away the finesse that makes the animation really nice. On my own, I would come up with:

anim.keyTimes = [0, 0.25, 0.5, 0.75, 1, 1]

But here’s the thing… I would never spend time hand-coding the Griddy animation. My experience tells me that it would to take way too long for something so small as a loader.

If someone brought me this animation, made with Flow, I’d drop it in my project in a heartbeat.

“Why?”

Because I know that the code-generator behind Flow is reliable, and the code it exports is a reflection of decades of experience and a great deal of craftsmanship.

If there’s anything you can take away from this article, I hope it’s this:

I trust the code that Flow ships, and so can you.

Originally published at https://createwithflow.com on November 7, 2020.

Code We Trust was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

A year before the first iPhone blew people’s minds, I graduated with an Interactive Arts degree that I was a few years late on starting, and I was madly passionate to find a job as an Interaction Designer — a role that at that time was lipstick on a web-developer. I was interested in the bleeding-edge, the out there stuff, like camera vision, sensors, data-visualization and how all that mixed in with artistic expression. I wasn’t the only one, but the centres for that kind of work were really few and far between, and a lot of them were in Europe.

Between Design and Development

After scraping, digging, and clawing my way through learning how to program, learning how to build interactive devices, and program some basic hardware, I ended up getting an amazing position at the Ars Electronica. Throughout my time there I found myself always at the center between the design and engineering teams, often doing some early work to “translate” ideas into early forms of software that would then get handed off to engineers that, for the most part, worked in C++ and OpenGL. The biggest struggles in communicating a creative vision always stemmed from the following scenario.

A comp was made in illustrator that expressed an idea, one that made total sense to the creative person who envisioned it, but made far less sense to the engineer who had to realize it. While beautiful in sentiment, that idea clearly overlooked basic fundamental aesthetic principles. The problem was that the designer was trying to express a vision of dynamic motion, but was fundamentally constrained by the static medium (sic. Illustrator) that they were using to express themselves. I came to believe that all designers should know how to program so that they could design in the medium they were creating for.

Another thing I learned from that time was the enormous undertaking of building custom interfaces. At the time, JUCE had split out from Tracktion and was one of the newest industry tools for developing custom desktop and mobile applications, while Processing and OpenFrameworks were on the rise as alternatives for building expressive and dynamic experiences. I thought that it would be amazing to have a robust library of animated, customizable interface components that could be reused for any purpose (i.e. a code-based design system).

That was a nice idea. Then I quit the Lab, moved to the mountains, and shelved the design-system idea for a while.

Discovering A New Paradigm

While living and hiking in the Rockies, I became fixated with dynamic typography and wanted to be able to draw with letters, using gesture and a Wacom tablet to do typographic layout. Almost immediately, it became blatantly clear the programming languages and IDEs I had been working in up to that point were not going to cut it — memory, performance, and rendering techniques were huge factors. I started really digging into new software systems and architectures that would allow me to express my creative vision, and I decided that Objective-C and CoreText were the two technologies that I needed to use. I made a lot of applications, printed artworks, and interactive installations with the software I was creating.

After more than a year of experimental development with Objective-C, I understood that there was a fundamentally different paradigm for rendering software. This technique, which was at the core of Mac app development, didn’t require re-drawing an interface at 60 frames per second. This technique was also layer-based, rather than drawing-based, which meant that there was a massive opportunity for inventing new kinds of aesthetics. I remained driven by the idea that artists should learn to program. I was obsessed and insatiable.

A New Approach to Creative Coding

So, I built the first version of C4, an open-source project for building beautiful interfaces. Through its development, I paid great homage to Processing and OpenFrameworks, building the programming language in a similar style to those projects but with this amazing layering capability built-in.

Eventually, on a cold snowy winter evening in a Canadian pub, someone walked in wearing a cowboy hat and shorts. A friend of mine caught this and said “See? Even that guy has an iPhone.” A longstanding discussion came to an end and initiated C4’s move to from Mac to iOS.

Over the coming years, I would leverage C4 to teach programming for artists, to produce print and interactive data visualizations, and build cutting edge experimental apps for companies like SAP.

The ability think through code to produce beautiful user experiences manifested the opportunity to open a design studio. From there, I managed to win grants, build new cutting-edge interfaces, interactive installations and generally bring my practice into a blooming professional environment.

One evening, I gave a presentation about creative coding and first met a brilliant engineer who was interested in contributing to C4. We started working together and eventually he took the lead on the engineering development and direction of the project. I learned a lot along the way, and one day came the opportunity to take the project to the next level.

Evolving Into a Product

I still fundamentally believed that designers should learn how to program, but by this point I knew that there was limited shelf-life to the idea. It wasn’t that it was “wrong” so much as it was too specific. The opportunity that arose for us to wrap an interface around our creative-coding API. On a Saturday, we met up with another friend of mine — a brilliant Interaction Designer — and sketched out an early vision for an animation and interaction design tool that would also have code export.

The idea was simple: if people don’t want to learn programming, then give them something that programs for them. I would later come to realize that the idea was also consistent with my original thesis: designers should be able to design in the medium for which they were producing.

We got the funding we needed to kick things off, the first line of code was committed in August, 2015, and the product was called C4 Studio. About a month later, Principle was released and looked just about exactly what we had sketched out earlier that summer… But, it didn’t have anything to do with code export and, luckily, pretty much ever prototyping tool to come thereafter also had nothing to do with software.

Shipping Creative Vision

Over the years our vision has been proven, time and time again. Despite the space of prototyping, design and production getting messier, noisier, and bigger, there remains the unsolved problem of design-to-development hand-off. Tools in our space have come and gone, largely because they only offered a fraction of a solution for a difficult process.

Today, Flow has the most powerful and flexible approach on the market for bridging the gap between Design and Development. This can be seen in the variety of export options (buttons, launch screens, onboarding animations, spinners), the variety of languages (Swift, React, HTML, JS, CSS), the variety of platforms (Xcode, Web, Android) all of which are backed up by the media export options that include images, animated GIFs / PNGs / SVGs, movies, and Lottie files that it can produce.

We have built a system for converting creative expression into a variety of visual media, or to beautifully written, efficient, modern software. It is the software side that truly gets to the root of my earliest vision, by allowing people to test in the medium before shipping. Flow allows a designer to craft beautiful signature motion pieces and, ultimately, accurately ship their creative vision.

Originally published at https://createwithflow.com on November 5, 2020.

Late on a Wednesday a few weeks ago I thought to myself, “let’s see if I can make 50 custom iOS loading animations by the end of Sunday…” If I started the next day, that would give me 4 full days to get the job done so that I could start posting them to our Dribbble portfolio. I ended up starting in the afternoon on Thursday, and by lunch on Saturday I was done! It was a marathon of work, but made totally possible using the right tools. Here’s how I did that.

Step 1: Find Inspiration

This is my favourite part. Having a project for which I get to go and spend a lot of time digging through the inspiring work on Dribbble is most definitely a treat. I spent the first part of Thursday afternoon finding really cool spinner animations.

Search & Collect

First, I create a new collection where I will save the animations that are awesome/inspiring/cool. Then, I start searching for great shots by selecting the animations tab, then adding a filter to find relevant designs.

For this project, the filters I used were: #uianimation, #loading, #loaders, #spinners, #loadinganimation.

At this point, my whole goal is to collect awesome stuff, not worrying about how hard or possible it might be to recreate an animation.

I quickly go through the various search results, and as I find shots I like I add them to a collection on my profile. This is a great part of the project, because I get to spend time looking at new trends, seeing new work and looking into people’s profiles, all of which really inspires me and pumps me up for the next phase.

Here are a few really nice ones from my Loading collection:

Queue Them Up

After I have a significant amount of designs in my collection, I start moving them into a Monday board. I do this one at a time so that I can have a closer look at the animation and gauge how difficult it will be to recreate.

As each animation goes into the board, I copy its url and paste it into a linkable column, name it and mark it as Easy, Medium or Hard so that I have a decent idea of how much time it will take to reproduce.

After looking at an animation, if I an idea on how to produce it I will add a note to the entry so that when it comes time to make it I will have a starting point of reference.

If there are multiple animations in a shot I will duplicate the entry for each animation I want to create.

Step 2: Animate

This is the big step, because it’s a lot of editing, tweaking, designing, and repeating a solid process that happens over and over and over again. The goal for this project is to produce and ship 50 Custom iOS ActivityIndicators, and to do that I use Flow to accelerate my ability to get work exported to Swift / Core Animation / Xcode.

Process

Process helps here, and it looks like this:

1. (Re)create the design and import into Flow.
2. Animate and Iterate.
3. Export, Test and Tweak.
4. Save the final animation file, move on. Don’t Stop

There’s not much to explain about this step other than.

I animate.

And I don’t stop.

And I just keep going.

And I animate.

And I don’t stop.

And I just keep going.

And I animate.

And I don’t stop.

And I just keep going.

And I animate.

And I don’t stop.

And I keep on keep on keep on keep on going…

You get the point, right?

Non-stop animation until all 50 animations are done.

Examples

Here’s an example of designing, animating and testing animations.

Check out our other examples on the 5048 Showcase.

Step 3: Github

Now that all the fun work is done, I move on to producing the media so that I can upload everything nicely. The strategy here is that I want to produce a project that people can actually use. So putting the software up on Github is a critical first step, because we want to make our animations freely available and reference this project everywhere.

A Github project for my work is important because it makes available all the animations for anyone who wants to use them, and I use it as the centre point around which all my other media posts will be based.

Here’s how I go about publishing this project:

1. Create a new Xcode project from one of the exported projects
2. Create a few classes to make it easy to switch between animations
3. Individually export each animation using Flow’s Custom iOS Activity Indicator option
4. Import all the animation files (3 per animation, 50 animations = 150 files)
5. Create a layout with all the spinners
6. Record all the spinners on my phone
7. Make an animated GIF in photoshop with a bezel around the animation
8. Upload the Xcode project to Github
9. Write the markdown page, including the GIF

Here’s what the final project page looks like:

Step 4: Dribbble

Almost there… The next step for me is to schedule all of my shots on Dribbble. First, I prepare 3 things for each project:

1. A 1600x1200 mp4 with my animation centred
2. A zipped version of my animation file.
3. A description, using a template, of the shot being uploaded.

When all of that is done for each of the 50 animations, I then go into upload mania.

1. I create a new project called iOS Spinners
2. I upload/rebound each shot, using its prepared files and description.
3. I schedule each shot so that there are 2 posted each workday for the next 25 days.

If you’re interested, check out my in-depth article on How We Publish to Dribbble.

Reflection

This was a fun and challenging project. At times, especially during the uploading sessions, it was incredibly mind-numbing. But, all in all it was pretty awesome to hammer all of this out in such a short amount of time. I discovered some lovely new aesthetics that people are working on, I learned some new animation techniques, and I pushed the limits of Flow. It was awesome.

I really like interacting on Dribbble, and have already seen a few comments and likes come through. I’m looking forward to seeing more, and have a few new projects up my sleeve that I will get to after we launch our upcoming official Figma integration (~ Nov. 24th).

Originally published at https://createwithflow.com on November 5, 2020.

Our Process

When we post shots to Dribbble, we often do so en masse. Typically, we do this because we’re diving in on a particular animation theme and we go all-out in generating a whole series of animations at the same time. The volume requires a process for making sure all our posts get tagged properly, have great descriptions and — most importantly — reference any original works that inspired our post.

After creating animations, the way we go about things basically boils down to the following steps:

1. Make a set of description templates for the current project.
2. Export media for an animation
3. Upload to Dribbble
4. Pick and customize the appropriate template for the post
5. Add tags
6. Add a file attachment
7. Add the shot to a project
8. Schedule the post

Shot Description Overview

There are 5 templates that we use for any given project:

• Original Shot
• Rebound of one of our Original Shots
• Rebound of Someone Else’s Original Shot
• Rebound of a Team’s Shot
• Rebound of a Rebound

We prepare them as HTML code blocks so that the links show up nicely in the Dribbble post.

Basic Format

Each post should have the following basics:

• Customized reference to someone else’s portfolio and the original shot.
• Custom description of the shot.
• Link to the software it was made with.
• Description and link to any relevant project pages outside of Dribbble (e.g. Github, etc.)

A basic writeup template might look like this:

Inspired by {NAME WITH LINK TO DRIBBBLE PROFILE}’s {DESCRIPTION WITH LINK TO INSPIRATION SHOT}, with some other detail if needed

Made with Flow.

Here’s an example of a simple description:

Inspired by Aaron Iker’s rebound of a cool shot by Gur Margalit.

Made with Flow.

Shot Description Templates

When we’re about to launch a series on Dribbble we take just a little bit of time to customize 5 templates, making it smoother to post multiple shots. The templates below are modified versions for our latest project — iOS Spinners.

Each one of the code-blocks is copy-pastable into Dribbble, allowing you to tweak links.

Original Shot

We use something simple like this when we’re posting an original work.

A piece of our own minds; simple originality.

Rebound

We use this template when rebounding someone else’s original work.

Inspired by {Designer's Name}’s {Title or Description or Original Shot}.

Here’s the code…

Inspired by <a href="https://dribbble.com/{portfolio link}" rel="nofollow noreferrer">{Designer's Name}</a>’s <a href="https://dribbble.com/shots/{shot link}" rel="nofollow noreferrer">{Title or Description or Original Shot}</a>.

Rebound of a Rebound

We use this template when rebounding a rebound.

Inspired by {Designer's Name}'s rebound of {Title or Description or Original Shot} by {Original Designer's Name}.

Here’s the code…

Inspired by <a href="https://dribbble.com/{portfolio link}" rel="nofollow noreferrer">{Designer's Name}</a>’s <a href="https://dribbble.com/shots/{shot link}" rel="nofollow noreferrer">rebound</a> of <a href="https://dribbble.com/shots/{original shot link}" rel="nofollow noreferrer">{Title or Description or Original Shot}</a> by <a href="https://dribbble.com/{portfolio link}" rel="nofollow noreferrer">{Original Designer's Name}</a>.

Rebound of a Team’s Shot

We use this template when rebounding a shot that was uploaded to a team’s portfolio.

Inspired by {Designer's Name}'s {Title or Description or Original Shot} for {Team name}.

Here’s the code…

Inspired by <a href="https://dribbble.com/{portfolio link}" rel="nofollow noreferrer">{Designer's Name}</a>’s <a href="https://dribbble.com/{shot link}" rel="nofollow noreferrer">{Title or Description or Original Shot}</a> for <a href="https://dribbble.com/{team link}" rel="nofollow noreferrer">{Team name}</a>.

Rebound of a Self-Rebound

We use this template when rebounding someone’s rebound of their own work.

Inspired by {Designer's Name}’s rebound of the {Title or Description or Original Shot} by {his/her} own hand.

Here’s the code…

Inspired by <a href="https://dribbble.com/{portfolio link}" rel="nofollow noreferrer">{Designer's Name}</a>’s <a href="https://dribbble.com/shots/{shot link}" rel="nofollow noreferrer">rebound</a> of the <a href="https://dribbble.com/shots/{original shot link}" rel="nofollow noreferrer">{Title or Description or Original Shot}</a> by {his/her} own hand.

Boilerplate

After the custom description for the current shot, we always like to add a bit of boilerplate that talks a bit about our current project.

Here is the boilerplate for our iOS Spinners Project.

This is an actual Custom iOS ActivityIndicator.

Exported to super clean Swift code.

<a href="https://createwithflow.com/" rel="nofollow noreferrer">Made with Flow</a>.

Only #realsoftware generated here, everything from Flow is real.

Checkout our <a href="https://github.com/createwithflow/ActivityIndicatorView" rel="nofollow noreferrer">Github project</a> about this Flow feature.

Files, Tags, and Other Polish

Here are the remaining things we do for a post.

Upload an MP4 File

We like uploading an MP4 file for our animations with a resolution of 1600x1200, using .H264 compression (other compression formats sometimes won’t work).

Tags

Prior to starting our upload process, we also create a set of custom tags to use. Here’s the set for our iOS Spinners Project.

• not fake
• real
• uikit
• spinner
• ios
• microinteractions
• ui animation
• flow
• createwithflow
• animation
• loader
• loaders

Export Options Media

When generating videos of our animations from Flow, we use the Dribbble export option with the following settings:

• 4x scale (gens a 1600x1200 vid)
• 2x preview scale (scales up the original animation)
• Shadow (adds a shadow to the animation layer
• Round Corners (rounds the corners of the animation layer)
• Custom background color if needed, otherwise default Flow light-grey.

Animation File

We make sure to upload a zipped version of our animation file for people to download.

Include the Shot in the Project

Prior to scheduling the shot to go live, we add it to our latest project.

Final Shot

A final shot will look like the image below.

Why We Do Things This Way

The main reason for this process is volume. For example, in our latest project we uploaded 50 animations that we created in 48 hours. With that number of uploads you definitely need to keep things organized.

More importantly, our approach is designed with recognizing an crediting the great work out there that gives us inspiration. We set things up early on so that when we’re in a frenzy of uploading, we help amplify other people’s profiles, animations, and originality... without missing a beat or a link.

Originally published at https://createwithflow.com on November 4, 2020.

There are 3 main reasons I really like rebounds.

Rebound to Learn

The first, best reason to rebound is to learn. In this, I fully agree with Michael Abehsera’s great article: The Art of Stealing: How to Become a Master Designer. In it he breaks down how to think differently about being inspired by other people’s work:

Instead of looking at other designers’ work with envy, think of it as the key to your success.

He introduces a parallel between Github and Dribbble, and talks about how being inspired to recreate another designer’s work is like forking code.

Dribbble’s rebound feature is the closest thing we have in the design industry to GitHub’s “forking,” or downloading any piece of open source software and making it your own.

He takes a broad look at rebounds in the Dribbble community, and uses 10 really interesting shots to support his position. In the end, he concludes:

When you copy someone else’s design work, you have to pick it apart in order to understand it and apply it… Copying effectively teaches you to do it the right way.

Can you, as a designer, look at a static image and decompose it into the techniques, styles, and layers that you need to recreate it? For me, I really like to do this same practice but for animations.

Rebound to Homage

It often takes a lot to create a rebound because you’re analyzing a static image, looking at its various elements, picking apart the techniques and layering, then rebuilding it from your own perspective and experience. That’s a lot of dedication, so when you do this and repost your work, it’s like an homage to the original designer — a tip of the hat — a recognition of great originality — a desire to honour that creativity.

Here are few of my rebounds.

Gridlock

Here’s Gridlock, an animation with a cool visual effect, it looks like each of the squares makes its way around the design by sliding — right, down, left, up. It was based on one of the animations in Unusual Animated Loaders by Margarita Ivanchikova — L, F, S. Her portfolio shows a really great breadth of style, and I really like a lot of her posts. So, I was compelled to recreate this piece. The neat thing about it is that there’s only 4 actual slides then everything repeats — so it’s a bit of a visual trick.

Stretch Around

Recreating Stretch Around required figuring out how to create the looping effect, as well as deciphering the layering that gives the aesthetic of a line stretching with a thick border. It was inspired by Loader XLVII, a micro animation experiment by Oleg Frolov — W, T, I, G, B, L. Oleg’s work is a bastion of design ideas and creative experimentation, all grounded in cutting-edge aesthetics.

Can you see that each of the dots is actually 2 lines, and that there are 8 total shapes animating?

Reflect

This one, which I call Reflect, was more of an inspired idea than a direct rebound. Inspired by on one of the animations in Daily UI #76 by Namika Hamasaki — W, T, G, M, L. Namika’s style is elegant, to say the least. In her original piece, I saw the two circles overlapping and realized I wanted to create a similar effect using a masked layer to reveal the green, and I also wanted to create a bit of a pop mid-way through the animation.

From time to time I’ll dive into an new category of animations, round up some awesome inspirations and see if I can unpack, rebuild, and recreate them. I like this process a lot because I learn, and I get really inspired by the amazing work that’s out there.

Rebound to Challenge

Challenges are a awesome way to engage with the community. Back in May, Loris F. Alessandria — W, I, B, V — shared an interesting design and threw down the Martini 🍸Animation Challenge! for people to animate it. In doing so he gave away his design file, and in return there were a bunch of people from all over the world who brought it to life.

The original illustration looks like this:

In the next week and a half, 5 designers from 5 different countries around the world rebounded original animations using Loris’ illustration.

This kind of thing is just awesome to see.

Steal, Own, Credit, Give Back

The rebound is probably one of Dribbble’s best features, and was really forward-thinking when it came out. I fully believe in using rebounds for learning, paying homage, and challenging other people to create beautiful work. I highly recommend you take up the practice, through which you will discover new aesthetics, learn new techniques, promote great work, and hopefully push others to do the same.

Own your creative expression, even if it’s riffing off of someone else’s original work.

Remember though, it’s all about crediting people for their originality, creativity, process and talent.

Don’t just steal. That’s a d*** move.

Originally published at https://createwithflow.com on November 3, 2020.

This is article #1 of that series.

In many circles, over many pints, and in many threads, lives the often fiercely debated topic of 3rd party libraries. Should you use them or not? Is it good or bad practice? Are they the Devil?

At Flow we’re constantly aware of and dwelling on this dialogue, because engineers are one of the primary users of our product. While the elusive unicorn may animate and program by themselves, the majority of teams working with Flow have engineers and designers working together, using the product. From the design side, our product needs to be a beautiful, easy and powerful animation tool. From the development side, it needs to produce modern, clean, flexible software.

But, therein lies a problem. So let me explain.

A Gentle Bias

Imagine a Designer picks up an animation tool and is amazed by its quality, ease of use, and ability to export media as well as great software for a variety of platforms. They animate their work and hand off a project to a Developer who then might say something like “We don’t use 3rd party code” without looking at it or “Generated code is never any good” or something else to that effect. There is a tendency — some might say a gentle bias — towards rejecting generated code out of hand.

Let’s have a look at two really important reasons for this sentiment.

Control

As a developer, a complete understanding of how your product works is fundamentally important and can also be a very difficult thing to manage. Having clear parameters around how to review code, how to style, and when to use someone else’s software is really important for maintaining control over your work. Ben Brooks has a salient take on how to determine when to use 3rd-party libraries. What it boils down to is that, sometimes it is important to understand every line of code in a project, and sometimes it isn’t such a big deal.

Building a design + animation tool is very complex and requires a significant amount of architectural software. In our journey, making certain that our software is stable requires a great deal of control, and is a primary reason that we write most software from scratch. On top of that, we often need to quickly work backwards from a bug to the exact source of an error — with a small team, knowing where a bug is coming from is critical. However, that level of control is far less important for UI elements, where we can easily justify the use of generated code.

Craftsmanship

As much as a Designer might pride themselves on the attention to detail in a design, a layout, or the timing of an animation, so too will a Developer take pride in the craftsmanship of the software they write. This is especially true for devs who see themselves on the “front lines” between the product they’re building and their customers.

“Clean code always looks like it was written by someone who cares.” – Robert C. Martin

We totally get it. Our team has had long discussions about the color, including questions like “what does a color mean?” to “what does the absence of color imply?” Every design element in our product exists because it represents a critical idea. From the engineering side, every line of code is written with the same attention to detail that we put into design.

An Olive Branch

The bias towards what we are doing — generating code for developers — may come from a variety of places, but control and craftsmanship are right at the top of the list. We totally understand this because these are two things that are incredibly important in every level of detail on both the engineering and design sides of our product.

If you’re on the fence, I’d love for you to suspend your disbelief for a moment and have a solid look at the quality of our code, and the structure of an exported project.

Our iOS export is a great example because you can integrate an animation into your project through Interface Builder. We use native UIKit classes, and everything is backed by Apple’s Core Animation. It’s not like we couldn’t figure out how to make animation work on iOS, and so created an animation engine for you… We didn’t do that. There are no heavy-handed 3rd party libraries here.

For iOS, we make Core Animation work for everyone.

For the Web, we make Web Animations work for everyone.

Code Export that Really Works

Animations make up a critical component of a beautiful user experience. But, they can be very complex to code up by hand. The level of detail in the coordination of timing, motion and color can be very tricky for an animator to create, and more so for a developer to convert into software.

Flow is a simple-to-use animation tool that eliminates the need to manually convert things to code. It preserves a designer’s vision while saving your whole team time, money, and heartache.

We’re here to force multiply your team’s ability to implement animations and elevate the user experience of your product.

Originally published at https://createwithflow.com on November 2, 2020.

This release opens up our Lottie export. For now we handle shapes, layers, and groups which cover a vast majority of animatable properties necessary for making pretty things.

A few examples of visual experiments we exported as Lottie animations:

Why A Lottie Beta?

Flow is an incredibly powerful animation tool, but it’s infinitely easier to learn than After Effects. Until now, we had many, many people tell us they use AE+Lottie for their UI Animations. This means that that combination of tool and output file is part of their workflow – i.e. their production pipeline. It’s hard enough to compete directly with other animation tools, but competing against a team’s production process is very, very hard.

Now, we can offer Flow as a powerful, easy-to-learn substitute for AE when it comes to UI Animation – and people don’t have to change their pipelines to get Flow producing the kinds of files they need for production.

What Beta Means

As I mentioned, this is our beta release. Which means we cover a lot of things, but not everything. In short, we cover shapes, layers and groups (which is essentially the majority of things you need).

Specifically, you can find a list of things that we handle over at our Lottie Compatibility page, and to see what’s coming soon.

I Bet You Can Break This!

We’d love it if you made some animations, exported them to Lottie and tell us what works, what doesn’t, what needs improvement, etc. In this area, we’re the rookies here and could use your keen eye and experience.

Connect with us on our Slack Group to give us feedback.

Or, email us with your thoughts.

Originally published at https://createwithflow.com on March 16, 2020.

One of the more subtle aspects of Flow is our code template engine. It allows us to very easily update and maintain or create new export formats.

When we released our React export in December, it had taken us less than a week to produce, test, and ship it… Which is nuts, because our team is small and adding code export to a tool should be really really hard. For us, it’s not… and this is because of Flow’s amazing code template engine.

A few key releases from last year show what I mean:

1.5.1 (Jun 27): 2 templates
1.5.6 (Jul 17): 5 template (added 3 in a single month)
1.6.7 (Nov 5): 6 templates
1.6.8 (Dec 10): 8 templates
1.6.9 (Dec 20): 9 templates

At the beginning of 2019, we had 2 export options:

• a solid iOS / Swift export, and
• a terrible Web / CSS keyframes export.

By the end of 2019, we had:

• iOS
• iOS — Launch Animations
• iOS — Onboarding Animation
• iOS — Custom Button
• HTML
• HTML — Toggle Button
• HTML — WebComponents
• HTML — WebComponents Toggle Button
• React — Toggle Button

Our team is small, so to be able to achieve this kind of production timeline is a very real testament to the power of Flow’s code template engine.

It’s easy for us to bring new export languages to Flow.

Flow Pro

We are working on a Pro version that will allow YOU to do this kind of thing as well.

So, you don’t like our export / programming style? That’s fine, you can modify a template to generate software exactly how you would have written it.

Do you need a language we don’t support? That’s fine, you’ll be able to write one yourself.

This is going to be a killer feature that truly puts Flow in a class of its own, so stay tuned.

Wait. What’s Flow?!?!

Great question.

Flow is a UI Animation and code export tool for animating Sketch files and eliminating the most painful parts of hand-off in app development. It bridges the gap between design and development by exporting production-ready native code for iOS and HTML.

Our Site

createwithflow.com

Get a Copy

createwithflow.com/download

❤

Originally published at https://createwithflow.com on January 3, 2020.

Flow now exports React components! Adding a 3rd export platform is a major milestone for us because the true nature of Flow is starting to reveal itself — as a tool that can export to any language, platform and style.

React Toggle Button

The newest export option that Flow offers is a toggle button built in React. After creating your animation and export it, you can integrate it into your site with just two lines of code:

Import it like this:

import ReactButton from "./js/ReactButton";

Use it like this:

<ReactButton elementID={"ReactButton"} callback={null} />

❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎❤︎

Backed by Web Components

Backing this by HTML Web Components made it really easy for us to create this React export. Essentially, the component wraps this:

<timeline-button   
  id={this.props.elementID}   
  onClick={() => this.state.toggleButton.toggle(true)}
></timeline-button>

I’m Amazed

I had a hearty giggle when our dev team showed me this for the first time. It took less than a week and is a beautiful testament not only to their abilities but to how truly awesome Flow is becoming.

Our goal is this:

1. Import your designs.
2. Animate them.
3. Export to ANY language.

We’re definitely getting there.

❤︎

Wait. What’s Flow?!?!

Great question.

Flow is a UI Animation and code export tool for animating Sketch files and eliminating the most painful parts of hand-off in app development. It bridges the gap between design and development by exporting production-ready native code for iOS and HTML.

Our Site

createwithflow.com

Get a Copy

createwithflow.com/download

❤

Originally published at https://createwithflow.com on December 20, 2019.

The latest release of Flow has an awesome new feature that lets you embed your animations in a website, using only a single line of code. It comes with some slick performance upgrades to boot.

A Single Line of Code

We’re overhauling our HTML export to offer the option of exporting using Web Components which allows you to reuse custom elements, and embed them using (typically) a single line of code.

How?

Three main elements come together to make this happen.

• Javascript stuff — for defining the component’s behaviours.
• Shadow DOM — for injecting the component into a page.
• HTML Templates — reusable markup that defines the layout of the component.

Our new HTML Button — WebComponent export option packs up your animation into these three things and gives you the option to then embed your button as a reusable component.

Why?

Aside from using only a single line of code instead of copying a DOM into your page? Great question.

Because it sets us up for exporting to React, and Angular.

So, in a nutshell:

• easier to integrate your stuff
• reusable elements for you to use
• gets us more export languages for Flow

An Example

Here’s an example of an animation that we created to show you how this looks. The component uses the Flow logo and looks like this:

Full DOM

Exporting with the HTML or HTML Button templates generates a full DOM that you can copy and paste into your pages. For the animation above, it looks like this:

<div onclick="buttonFlowButton.toggle(true)" class="flow-artboard" id="FlowButton-ButtonID">
  <div class="flow-artboard" style="visibility: hidden;">
    <div class="flow-artboard" id="FlowButton">
      <div class="flow-layer w_blue">
        <svg class="w_blue-svg" preserveAspectRatio="none" viewBox="0 0 28 28">
          <title>W-Blue</title>
          <desc>Made with Flow.</desc>
          <defs id="w_blue-defs">
          </defs>
          <path id="w_blue-path" vector-effect="non-scaling-stroke" d="M0,26.451c0,0,0,-24.904,0,-24.904 0,-0.854,0.692,-1.547,1.547,-1.547 0,0,24.904,0,24.904,0 1.378,0,2.068,1.666,1.094,2.64 0,0,-24.904,24.905,-24.904,24.905 -0.975,0.974,-2.64,0.284,-2.64,-1.094">
          </path>
        </svg>
        <div class="flow-border w_blue-border"></div>
      </div>
      <div class="flow-layer w_red">
        <svg class="w_red-svg" preserveAspectRatio="none" viewBox="0 0 28 28">
          <title>W-Red</title>
          <desc>Made with Flow.</desc>
          <defs id="w_red-defs">
          </defs>
          <path id="w_red-path" vector-effect="non-scaling-stroke" d="M0,26.451c0,0,0,-24.904,0,-24.904 0,-0.854,0.692,-1.547,1.547,-1.547 0,0,24.904,0,24.904,0 1.378,0,2.068,1.666,1.094,2.64 0,0,-24.904,24.905,-24.904,24.905 -0.975,0.974,-2.64,0.284,-2.64,-1.094">
          </path>
        </svg>
        <div class="flow-border w_red-border"></div>
      </div>
      <div class="flow-layer w_pink">
        <svg class="w_pink-svg" preserveAspectRatio="none" viewBox="0 0 12 14.18">
          <title>W-Pink</title>
          <desc>Made with Flow.</desc>
          <defs id="w_pink-defs">
          </defs>
          <path id="w_pink-path" vector-effect="non-scaling-stroke" d="M0,14.18c0,0,0,-12.634,0,-12.634 0,-0.854,0.692,-1.546,1.547,-1.546 0,0,8.904,0,8.904,0 1.378,0,2.068,1.665,1.094,2.639 0,0,-11.544,11.541,-11.544,11.541zM0,14.18">
          </path>
        </svg>
        <div class="flow-border w_pink-border"></div>
      </div>
      <div class="flow-layer o">
        <svg class="o-svg" preserveAspectRatio="none" viewBox="0 0 30 30">
          <title>O</title>
          <desc>Made with Flow.</desc>
          <defs id="o-defs">
          </defs>
          <path id="o-path" vector-effect="non-scaling-stroke" d="M15,30c0,0,0,0,0,0 -8.284,0,-15,-6.716,-15,-15 0,0,0,0,0,0 0,-8.284,6.716,-15,15,-15 0,0,0,0,0,0 8.284,0,15,6.715,15,15 0,0,0,0,0,0 0,8.284,-6.716,15,-15,15">
          </path>
        </svg>
        <div class="flow-border o-border"></div>
      </div>
      <div class="flow-layer l">
        <svg class="l-svg" preserveAspectRatio="none" viewBox="0 0 28 28">
          <title>L</title>
          <desc>Made with Flow.</desc>
          <defs id="l-defs">
          </defs>
          <path id="l-path" vector-effect="non-scaling-stroke" d="M26.451,28c0,0,-24.904,0,-24.904,0 -0.854,0,-1.547,-0.692,-1.547,-1.547 0,0,0,-24.904,0,-24.904 0,-1.378,1.666,-2.068,2.64,-1.094 0,0,24.905,24.904,24.905,24.904 0.974,0.975,0.284,2.64,-1.094,2.64">
          </path>
        </svg>
        <div class="flow-border l-border"></div>
      </div>
      <div class="flow-layer f">
        <svg class="f-svg" preserveAspectRatio="none" viewBox="0 0 28 28">
          <title>F</title>
          <desc>Made with Flow.</desc>
          <defs id="f-defs">
          </defs>
          <path id="f-path" vector-effect="non-scaling-stroke" d="M0,26.451c0,0,0,-24.904,0,-24.904 0,-0.854,0.692,-1.547,1.547,-1.547 0,0,24.904,0,24.904,0 1.378,0,2.068,1.666,1.094,2.64 0,0,-24.904,24.905,-24.904,24.905 -0.975,0.974,-2.64,0.284,-2.64,-1.094">
          </path>
        </svg>
        <div class="flow-border f-border"></div>
      </div>
    </div>
  </div>
</div>

With Web Components

Now.

Check this out:

<flowbutton-button id="flowbuttonButton" onclick="flowbuttonButton.toggle(true)"></flowbutton-button>

That’s what you have to drop into your page with our new approach.

Nice, right?

Right?

But That DOM Still Exists Somewhere Right?

Yes, it still exists, but it’s now encapsulated in a document that allows you to inject into any page, menu, etc. on your site or web app.

A Hint at the Future

We are moving towards having new export options, specifically React and Angular and we’re using this Web Components approach to leverage adding two new languages.

This news is actually centered around exposing an API for developing new templates with Flow. Soon, developers will be able to create their own export templates, either by modifying one of ours or creating an entirely new one from scratch.

Keep an eye out.

Wait. What’s Flow?!?!

Great question.

Flow is a UI Animation and code export tool for animating Sketch files and eliminating the most painful parts of hand-off in app development. It bridges the gap between design and development by exporting production-ready native code for iOS and HTML.

Our Site

createwithflow.com

Get a Copy

createwithflow.com/download

❤

Originally published at https://createwithflow.com on December 13, 2019.