Drawing and editing lots of lines and boxes for user flows in any design tool is is a real pain. If you’ve ever done it, you know what I’m talking about.

Even if you manage to get it done for your current project, there’s always the next project that needs almost the same treatment.

Almost. That’s the problem. Your old lines and boxes don’t quite match up with what you need now and there’s not easy way to reuse what you’ve already done.

After experiencing this pain myself on multiple client projects over and over again, I finally decided to do something about it.

I decided to make my own reusable flow library. I thought of every possible direction, line curve, variation, etc. that I would possibly want in a flow component library. Then, I made it.

I spent what some would consider an unreasonable amount of time crafting every single little detail. I even changed the naming convention several times based on how usable and memorable each component was.

I had a dozen or so people test out the initial version back in October of 2017, right before I went live with version 1.0.

Fast forward one full year and I’m still using Flowkit on my projects and still have people telling me how much they love it and how much time it’s saved them on their projects.

Ramon Gilabert 🎗 on Twitter

@mds @figmadesign @sketchapp 🔥 dude-our stakeholders are loving our flows now, so easy to combine in documentation and presentations!

🅲🅷🆁🅸🆂 🅼🅴🆂🆂🅸🅽🅰︎ on Twitter

This is super dope for anyone that designs UI flows in @sketchapp! Discuss on @ProductHunt: https://t.co/nHQGci8JBh https://t.co/4tNAm6SHt9

🅹🅴🅵🅵 🅷 on Twitter

Forgot to send a shoutout to @mds and https://t.co/Nhx9IRTgcY Saved me on a deadline right before Thanksgiving...would've taken me triple the time without it. AND it's incredibly extendable as you can see.

Arantxa Vizcarro on Twitter

Flowkit for Sketch!! Bonito y rápido! ;) https://t.co/fJsGsfdpSg #design #process #flow #life #megalike #good Gracias @angelcreative!!

After a full year of personal use and informal feedback gathering, I wanted to rebuild Flowkit from scratch to work with more design tools and incorporate a few updates here and there.

What’s new in 2.0?

Flowkit has been redesigned from the ground up for both Figma and Sketch. Both files contain the same content in regards to symbols and components, but each format was designed natively to leverage the unique features of each design tool.

What about Studio and XD? At the time of this writing, they don’t currently support all of the nested component features that Flowkit needs to be fully functional. When they do, I’ll update Flowkit. 👍

Please note, the use of the word component used in the rest of the article applies to both Figma components and Sketch symbols respectively.

New Grid

Each component has been redesigned at 360x360 pixels with padding included. This means that all flows, blocks, annotations, etc. can now be aligned side by side, with zero margin, and have a consistent spacing throughout the entire document. This eliminates the need to guess the dimensions and proper spacing for any specific component used in your flow.

Master Components

The Master Components are the foundational pieces that create all of the component instances. The total number of Master components for the flow lines has been reduced from 22 components in Flowkit 1.0 to now only 12 Master components in Flowkit 2.0.

Each variation of the Master components all scale correctly while manually scaling the bounding box of a component or by using keyboard shortcuts like ⌘ (↑ → ↓ ←)and ⌘ ⇧ (↑ → ↓ ←). Any edits made to these components will affect all instances in the library. It is not recommended to modify the Master Components.

Master Variants

There are several master variants for quickly changing the core style of the Flow instance. These include Dashed, Red, Green, Blue, and Light.

Pre-built styles are available for all components in Flowkit. There are multiple options for stroke styles, fill colors, and more built directly into both Figma and Sketch using their own unique way of handling styles.

Naming Conventions

Each directional component uses the following naming convention. It begins with the point of origin and ends with the destination.

Type / Direction 1 / Modifier 1 / Direction 2 / Modifier 2

• Type can be either Flow or Tap, depending on the type of flow you are creating. Flow is intended to be used for high-level user flows, whereas Tap is intended to be used with wireframes or actual screen designs all on the same artboard.
• Direction 1 determines the initial direction of the path. This can be Right, Left, Up, or Down
• Modifier 1 comes immediately after the Primary Direction. This can be Straight, Curve, or Snake.
• Direction 2 comes immediately after the Initial Modifier. Right and Left components can be either Up, or Down, whereas Up and Downcomponents will have Secondary Modifiers as Left, or Right.
• Modifier 2 is the final section of the Flow component and determines the direction of the arrow. This can be Straight, U-turn, or Hook.

Flows

These are the primary components in the system. There are 11 options (listed below) for each direction. All Flow components can be scaled without skewing or stretching. Each Flow component also contains nested endpoints that can be hidden or overridden with different end points.

There are 11 variants in total for each direction. For example:

1. Flow / Right / Straight
2. Flow / Right / Curve / Down / Straight
3. Flow / Right / Curve / Down / U-turn
4. Flow / Right / Curve / Down / Hook
5. Flow / Right / Curve / Up / Straight
6. Flow / Right / Curve / Up / U-turn
7. Flow / Right / Curve / Up / Hook
8. Flow / Right / Snake / Down / Straight
9. Flow / Right / Snake / Down / Hook
10. Flow / Right / Snake / Up / Straight
11. Flow / Right / Snake / Up / Hook

Taps & Interactions

Taps are intended for use on top of UI screen designs when laying out flow documents. They follow the same naming pattern as Flow components. Each endpoint has been pre-overridden with the Tap endpoint and can additionally be changed to other interactions, such as Swipe, Long Press, and Double Tap.

End Points

In Flowkit 2.0 every single End Point is the same dimension and can be interchanged with any other end point instance for full customization. These include circles, arrows, taps, swipes, and more.

Blocks

Blocks are used as main sections of user flows. Just like every other component, they’re built on a 360x360 grid. There are multiple Block options such as Default, Dashed , Emphasis, and Solid.

There are also Device blocks for iOS,Android, and Browser.

Labels & Annotations

There are multiple label styles including solid and outline versions of default, red, blue, and green. Labels are intended for use with Flow or Tap lines to provide more context about a specific user paths.

There are two types of annotation components. The general Annotation Labels can be used anywhere within your flow to provide more situational context, whereas the Annotation Points are intended to callout specific areas of your screen designs.

Dark Mode

In my best Mugatu voice…

“Dark mode. So hot right now.”

Flowkit 2.0 comes with an inverted color option for dark interfaces, dark backgrounds and those who generally like to live life on the dark side. 😎

Ok, great. How do I actually use it?

Since Flowkit was created in both Figma and Sketch, installing the library is quite simple and no additional software is required.

Installing in Figma

Figma requires users to have a paid Team account to create and access Figma Libraries. Therefore, to use Flowkit as a shared library between users and files, you and your team will need to have a paid Figma Team account.

• Open flowkit-v2.fig with Figma.
• Click the book icon in the top right to access Libraries.
• Navigate to the Flowkit 2.0 line item and click Publish.
• Create a Team project called Flowkit and click Move.
• Flowkit will now be available as a library across all Team projects.
• For more info on Figma libraries, read Figma’s documentation.
• Please make sure you have the appropriate Flowkit Team license to share the library with your design team. Have a personal license and need to upgrade? Let me know and I’ll hook you up with an upgrade coupon code.

Free Figma Accounts

If you have a free Figma account, it is recommended that you create userflows as additional pages inside of the Flowkit file in order to leverage the assets as components.

Installing in Sketch

Installing the Flowkit Library will make it available for use with all of your Sketch files.

• Open Sketch preferences, navigate to the Libraries tab.
• Choose Add Library... in the bottom left.
• Select flowkit-v2.sketch and click Open
• Now you’re ready to use Flowkit 2.0 in any Sketch 52+ document.

Sketch Runner + Flowkit

Using Flowkit with Sketch Runner is highly recommended. You can download the free Sketch Runner plugin, here. Sketch Runner will allow you to use keyboard commands to insert Flowkit library symbols onto your canvas. Use ⌘ " to open Sketch Runner, then type in the easy-to-remember™ Flowkit naming convention Type / Direction 1 / Modifier 1 / Direction 2 / Modifier 2 to place the symbol you want.

Download this free shortcut plugin to use Flowkit even faster.

Creating High-level Flows with Flowkit

Every main component inside of Flowkit is based on a 360x360 grid. Each one was designed to have 0px of margin on all sides when linking blocks and flows.

It is recommend to create one high-level flow focused on one particular section or feature of your project, per large artboard that can later be shared or exported.

High-level flows in Figma

• Press ⌥2 or click the components icon in the lower left, to access Flowkit in the Components panel.
• At the top of the Components panel, search for block default, choose a block component and place it on the canvas.
• Now search for flow right, choose a flow component and place it on the canvas.
• Continue adding components by searching and navigating the component list, as necessary.

High-level flows in Sketch

• Use ⌘ " to open Sketch Runner.
• Type block default and hit return.
• Use ⌘ " again, and type flow right straight.
• Continue adding components with Sketch Runner, or by navigating the Flowkit symbol list from the Sketch app toolbar.

Screen to Screen Flows

Do not place the Flowkit components on top of artboards or frames and try to connect them to other artboards or frames. This will result in clipped components and unhappy Flowkit users. ☹️

Do place the Flowkit components on top of artboard instances on one giant artboard. This is the recommended screen flow technique when using Flowkit.

There are distinct ways to create screen flows in both Figma and Sketch — dynamic screens and exported screens.

Screen flows in Figma

Dynamic Screens (recommended)

• Select a frame and press ⌘⌥K to convert to a component
• Copy and paste an instance of your frame component onto a larger frame to begin building your flow.
• With your first frame instance in place, navigate to the component panel with ⌥2 and search for tap right.
• Rinse and repeat as necessary.
• Any adjustments made to your master frames will be reflected in your flow frame automatically.
• Don’t forget to reposition your flow components if you refactor your designs.

Exported Screens (alternate)

• This is a quick way to create a flow when dynamic screens don’t matter.
• Right click any frame and choose Copy as > Copy as PNG.
• Paste the bitmap onto your large flow frame.
• Press ⌥2 or click the components icon in the lower left, to access Flowkit in the Components panel.
• Search for tap right straight and place the flow component on your large flow frame.
• Rinse and repeat as necessary.

Screen flows in Sketch

Dynamic Screens with Plugins

• Install either the free Angle or Magic Mirror plugin.
• Create a large artboard to contain your screen flows.
• Draw a rectangle the same size as the first artboard you’d like to use.
• Apply the Magic Mirror or Angle plugin to the rectangle, to mirror your artboard. Please refer to the plugin documentation for more details on this.
• Use Sketch Runner ⌘" and search tap right straight to place your first flow symbol.
• Rinse and repeat as necessary.

Dynamic Screens with Symbols

• Convert your artboards to symbols.
• Create a large artboard to contain your screen flows.
• Place the symbol instance of your artboard onto the large artboard.
• Use Sketch Runner ⌘" and search tap right straight to place your first flow symbol.
• Rinse and repeat as necessary.

Exported Static Screens

• Select an artboard and choose Make Exportable in the bottom right of the inspector panel
• Use Sketch Runner ⌘" and search tap right straight to place your first flow symbol.
• Rinse and repeat as necessary.

Overrides

Whether you are building complex flows or changing interactions on tap components, Flowkit comes with lots of prebuilt override capabilities to hide or show certain endpoints.

Linking flow components

There are times when linking multiple flow components together is necessary to give you just the crazy line you want in your document. You can achieve the appearance of a continuous line by hiding the nested endcaps.

Changing tap interactions

The default interaction for screen flows is tap, but it can easily be overriden with double tap, swipe (up, down, left, right), and long press.

Snag Flowkit for you or your team

Visit https://useflowkit.com and grab the license that’s right for you!

Still have questions? I’d be happy to help you out, just tweet at me.

Design native userflows right inside Figma and Sketch with Flowkit 2.0 was originally published in bymds on Medium, where people are continuing the conversation by highlighting and responding to this story.

Globally, there are an estimated 2.2 billion people in the world who are visually impaired. This number includes anyone from legally blind, to those with less than 20/20 vision.

This short guide, written during the creation of the Contrast MacOS app, will help you achieve the accessibility standards outlined in the WCAG 2.0, specifically with foreground and background color when it comes to text on digital screens.

TL;DR

• Fail — Your text doesn’t have enough contrast with the background. You probably want to make it darker. This is a score of less than 3.0.
• AA Large — The smallest acceptable amount of contrast for type sizes of 18px and larger. This is a score of at least 3.0.
• AA — This is the sweet spot for text sizes below ~18pt. This is a score of at least 4.5.
• AAA — This is enhanced contrast with a score of at least 7.0. Think longer form articles that will be read for a significant period of time.

Decorative elements or text that is part of a logo or brand name have no minimum contrast requirements.

There are other factors to consider in order to be fully compliant with AA and AAA standards, but this will get you off to a great start.

Score and Ratio

There is an equation provided by the WCAG (Web Content Accessibility Guidelines) that determines these two values.

1. The Score
2. The Ratio

The equation outputs a number between 1 and 21, with 21 being the highest amount of contrast — think black text and a white background — and 1 being no contrast — white on white.

The output of contrast between any two colors will fall somewhere on the spectrum between 1–21. That’s where the scores are derived from.

There are technically 5 scores.

1. AAA
2. AAA Large
3. AA
4. AA Large
5. Fail

AAA

AAA means that your text has a contrast ratio of at least 7.0. For example, 595959 text on a ffffff background and vice versa.

Note that in order to achieve a true AAA rating, section 1.4.8.1 of the WCAG also states that “Foreground and background colors can be selected by the user.”

So unless you’re planning on creating that functionality in your website or app as well, there’s really no reason to shoot for higher than AA, in my humble opinion. Of course there are caveats. Your body copy may look the nicest and be the most readable if you’re hitting a AAA score, so take this advice with a grain of salt.

This score is derived for people with low 20/80 vision. This visual acuity score is often not able to be corrected with glasses, etc.

Side note, 20/200 is legally blind.

ISO 9241–3 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 3: Visual display requirements. Amendment 1.

AAA Large

AAA Large means that your large text has a contrast ratio of 4.5 or higher, which is the same score as AA, which is why you won’t see AAA Large as a visible score in the app.

The WCAG describes 14pt bold and 18pt as "large" sizes. This roughly translates to 18.5px bold and 24px @1x. This is an approximation since letterform sizes can vary greatly between typefaces.

If you’ve never checked your contrast scores before, you’re going to be shocked at how dark you need to go to hit AA for small sizes. I urge you to press through—your users will probably not thank you, but they will enjoy readable text in your designs. It’s just the right thing to do.

AA

AA means that your text has a contrast ratio of at least 4.5 or higher. For example, 757777 text on a ffffff background and vice versa.

There is empirical evidence that visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5, which is where the 4.5 score is derived.

Gittings, NS and Fozard, JL (1986). Age related changes in visual acuity. Experimental Gerontology, 21(4–5), 423–433.

ANSI-HFES-100–1988. American National Standard for Human Factors Engineering of Visual Display Terminal Workstations, Section 6, pp. 17–20.

AA Large (AA+)

AA Large means that your text has a contrast ratio of at least 3.0. For example, 949595 text on a ffffff background.

This is the minimum level recommended by ISO-9241–3 and ANSI-HFES-100–1988 for standard text and normal vision, which is where WCAG derived this score.

We made the decision to abbreviate Large to + in the app so that each score would be similar in character length and not impact the fixed width of the interface.

FAIL

Fail means that your text has a contrast ratio of 2.9 or lower. This does not apply to logos, text in logos, and other decorative elements.

Quite often, failing scores can seem to work nicely within the context of a static design review. But in the context of real world usage, these failing scores can cause serious issues for the usability of your interface.

What about mobile apps and their big sharp retina screens?

There’s a working draft of the WCAG Mobile guidelines that says…

Mobile devices are more likely than desktop/laptop devices to be used in varied environments including outdoors, where glare from the sun or other strong lighting sources is more likely. This scenario heightens the importance of use of good contrast for all users and may compound the challenges that users with low vision have accessing content with poor contrast on mobile devices.”

So while it is probably easier to see lighter text on a high resolution screens in a controlled environment, the use case for mobile is incredibly unpredictable to risk going super light with text. Direct sunlight, dark rooms, and more all significantly affect the display on mobile screens.

More than just contrast

There’s a lot more to accessibility than just color contrast. Here are a few snippets from the WCAG for example:

1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)Foreground and background colors can be selected by the user.Width is no more than 80 characters or glyphs (40 if CJK). Text is not justified (aligned to both the left and the right margins). Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing. Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

You can see that in order to hit a AAA rating, your app or site needs to allow selection of foreground and background colors by the user. So even if your color contrast is AAA, that doesn’t mean your entire product is.

If you’d like to see just how deep the the WCAG rabbit hole goes, take the red pill.

And if you’d like a super duper, easy way to check your color contrast, right from your Mac menu bar, download Contrast and start designing better interfaces. You might even have fun using it. 🤓

Also, this is the best web-based contrast checker that I’ve found if you’re more of a web person.

This guide was originally published on usecontrast.com/guide. Contrast was design by Matt D. Smith (👋) and developed by Sam Soffes.

Color Contrast for Interface Design was originally published in bymds on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the guy who made the original design that the majority of the Float Label craze was based on, I feel somewhat obligated to share my perspective on the matter.

I need to preface this by saying, I’ve never met Adam, but have read some of his other articles and I really appreciate and admire his thoughtfulness of the tiny details in his articles

Adam makes a lot of great points in his article and in certain contexts, I would agree.

I believe however, that it’s important to call out some subtle absolute statements in the article and point out their relativity based on design at large, rather than the individual pattern of a floating label.

I also want to hedge all of this by saying that I don’t believe float labels should be used for every form ever made. If you don’t think they add value to your form, don’t use them. Ok?

If you’ve tested one way versus the other, use the higher performing method. Who doesn’t want higher conversion rates?

But just remember, a form alone isn’t going to boost conversion rates through the roof. You have to create enough value and solve a big enough problem with your content so a user is actually motivated to use your form in the first place.

I myself have done no official float label split testing and can’t confidently recommend the pattern over a standard label, based on pure research alone.

But I can say that I recently used float labels on my Intro to Icon Design course form and saw a conversion rate of over 30%. According to my quick research, that’s 10 times higher than the average opt in form that generates only 3% conversions.

Would the conversion rates been higher had I not used float labels? My gut says “no”, but I have no data to back that up.

With all of that out of the way, let’s dig into my commentary. The following numbered headlines and quotes below are taken straight from the article.

1. There is no space for a hint

The article states:

Floating labels start inside the text box leaving no space for an additional hint.

Ok, so if you intend to put a hint or a note above the input field and directly below the label, then yes, a float label will hinder your ability to do that.

However, If you really wanted a note or a hint, you could move it below the input field and simply push the other field down a bit.

Debating over hint placement is futile, unless you have an extremely clear picture of the exact problem trying to be solved with a form in the first place.

In some cases hints or labels are incredibly helpful and in other cases they are a bandaid on a poorly designed form. It simply can’t be an absolute standard out of context.

2. They are hard-to-read

The article states:

Floating labels typically have small text, so that as it floats, it takes up a small amount of space. But small text is hard-to-read.

That really depends on the size of the text. And “hard to read” is a variable, not a constant, based on the user’s eyesight.

Furthermore, text size is relative to a design in general — not float labels themselves. It’s quite possible to have float labels be the same size as a standard label.

If text is displayed at a standard size of 16–18px, it’s generally acceptable as readable. Perhaps more so than say a 12–14px size.

So let’s agree for a moment that 18px is in fact easier to read than 12px…

Is it too unfathomable to assume that an easily read 16–18px, contextually scaled to a 12–14px after a user starts typing, would be suddenly too small to read?

I don’t deny that 12px can be harder to read than 18px, but I see a float label as an artifact of the past, rather than a clue to the future.

It’s a leftover indication rather than an instruction of what to do.

3. They need space to move into

The article states:

Floating labels needs space to move into. If label text is friendly (see previous point), there would be no saved space anyway — just more white space.

This is true, absolutely.

The float labels need space to move into and this is one of the trickiest problems to nail for the pattern.

Chris Coyier even wrote up his thoughts on this particular issue as well and concluded float labels don’t save any vertical height at all.

BUT…

If you agree that the Float Label is an artifact, rather than an instruction, you might also agree that it’s ok to go slightly smaller in text size than a standard label.

And with a smaller text size, say 12px instead of 16px, you would effectively save 4 or more pixels of space. Possibly even 8px since you wouldn’t need to add extra margin below the label in the traditional sense.

We’re really getting down into the weeds here, pixel-wise, but a great interface designer will be painfully aware of a 4px discrepancy and the affects it can have on the whole design if used properly or improperly.

So if you save 8px on 5 input fields in a form, you’ve saved a total of 40px. That’s roughly the same height of a button on mobile screen.

Would that helpful for your project? I don’t know. You, as the designer, will have to decide that for every use case you come across.

Let me give you a real world example of a giant complex form I worked on a few years back.

The project involved an insane amount of data for commercial shipping and transportation logistics. We were truly trying to make the complex, simple.

The forms below are screenshots of “work in progress” designs that I pulled up from the archive.

The left form uses a combination of top aligned labels and left aligned labels. We were experimenting — trying to land on the perfect solution.

Then, I designed the form on the right as an alternative to the shear amount of craziness going on in the form. We all agreed that it felt more clean, less overwhelming, and better overall.

You can see that even though only half of the fields were top aligned it still resulted in over 420px of vertical height saved.

We even had a few impromptu tests where we asked people, “which of these forms looks less overwhelming?” And they agreed the form on the right seemed better.

I know this isn’t 100% valid and statistically conclusive testing, but still, it’s a start.

I would LOVE to get something like this properly tested one day, but until then it’s an intuition, not a fact.

There are so many variables like content type, preexisting user knowledge, and more that make any single form test simply not 100% applicable for all future forms.

4. The animation is problematic

The article states:

Animation, even if it’s done well, could be distracting and disorientating, particularly for low confidence or visually impaired users. And, when zooming in, the label may disappear off screen.

Hang on a sec. If an animation is done well, then it is by definition “well,” “good,” “satisfactory,” “to be desired,” etc.

Therefore the phrase “distracting and disorienting” can’t coexist with “done well.”

I know that I’m incredibly biased, but when I fill out a form that really nails the Float Label animation, I get a teensy tiny little dopamine rush when the animation resolves and I move on to the next field. A small sense of completion that wasn’t quite there before.

It’s reminds me of a game where something visually happens in the wake of your character’s path. Like a footprint.

I feel like I can’t preface this enough, though. If float labels don’t make sense for your project and adds too much unnecessary complexity, then please, by all means, don’t use it.

I will still happily use your form if the other end of your form solves my problem.

5. They have poor contrast

The article states:

Like placeholder text, floating labels have low contrast to differentiate it but low contrast text is hard-to-read.

Depending on the design, when the label floats outside of the field, its colour will need to change. Otherwise the text will be lost against the background colour.

Low contrast has nothing to do with a float label and has everything to do with size and color.

The minimum WCAG 2.0 (Web Content Accessibility Guidelines) states that a color contrast ratio of 4.5:1 is necessary to pass AA guidelines for regular text size below 18~px.

The lightest grey color hex code that produces a passable AA contrast ratio is #767676 or #757777 on #ffffff (white) background. This is if you are using a regular font weight below 18px. If you're using a bold font weight at 14px size you can defer to the large contrast ratio the WCAG provides, which is 3.5:1 and ends up being #898989 on #ffffff. Side note: this is my favorite contrast checker.

Sidenote: I’ve designed projects for banks that require a minimum AA contrast rating for their digital product. I haven’t personally come across a client that required more than AA, but we did set AAA as a goal (and hit it) when we designed Exxon’s Unity Design System.

Ok, I’ve gotten waaaaaay off subject, but my point is that this is a color and design issue, not a float label issue.

6. They may be mistaken for a value

The article states:

People may skip the field thinking it’s completed already. When they submit, they will see an error which needs fixing. This is frustrating and time consuming.

This is a very valid point and also why color and hierarchy are of the utmost importance when designing interfaces.

Darker labels above empty input fields are pretty hard to mistake for something already in the field.

If you set a precedent for the user by having floating labels activate on user input AND the user input text color is much darker than the placeholder color — say #767676 versus #222222—then the possibility of confusion could be much lower.

I can’t matter of factly say that this won’t be an issue. I don’t believe it would be in many cases, but making that assumption without hard data would be ignorant on my part.

Please design placeholders and labels wisely. If you’re using proper contrast between placeholder color and user input color, this should solve any problems you might encounter.

7. They are inconsistently located

The article states:

Radio buttons, checkboxes and select boxes have static labels and legends. Where as text boxes have floating labels. This creates an inconsistent experience.

When looking at a text box, for example, the user has to look inside the control. For a select box they have to look outside of it.

This is a design problem, not a float label problem. Shopify does an incredible job with the float label on their input fields and select boxes.

8. The label may get cropped

The article states:

If the floating label is longer than the size of the field, it will be cut off by the field. We should design for content, we shouldn’t make content fit the design.

This isn’t a float label issue per se, this is a bad form design issue.

No one should ever have a placeholder label that long.

And if you do truly need to ask a two line question as an input label, then I 100% recommend NOT using a float label.

It just doesn’t make sense for that use case.

9. They ignore the standards

The article states:

We know placeholders are problematic anyway. However, if we’re going to put text inside a text box, it should be a hint, not a label.

This is the standard the article references. It reads:

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format.

Hmmm, “A word or a short phrase intended to aid the user” sounds like it could describe a label!

Now the standard documents also say:

The placeholder attribute should not be used as an alternative to a label.

I’m fully aware that there are circumstances that require an external label and additional placeholder data to really help out certain field input types. Sometimes you need to pull out all the stops when designing forms to really cover all the bases.

I agree 100% that no label and only placeholder data is a bad idea. That’s why the float label exists!

The float label was created AFTER this standard was written. Is it not worth challenging original assumptions in old documents after new ideas arise? Especially ones that are getting adopted so quickly.

Is it reasonable to get curious about this rather than dismissive?

There’s got to be some valid reason why Google adopted this pattern as a standard in Material Design Guidelines.

In addition to Google, the following companies have adopted float label patterns in their apps.

1. Shopify
2. Slack
3. Digital Ocean
4. Delta
5. Invision
6. Lots more I can’t remember…

Summary

The article states:

Forms are not a source of entertainment. The floating label won’t make users enjoy using forms. Users don’t care. They just want the outcome.

I agree that users want the outcome, but disagree that forms shouldn’t be entertaining. A user who is entertained is much more likely to remember their experience with your product.

I will add a caveat though that you shouldn’t put entertainment above functionality and clarity.

There are better and more productive techniques for improving form design. Let’s spend time and energy on those instead.

I definitely agree with the first sentence and sometimes improving form design is removing fields or rethinking if a form is even necessary.

But shouldn’t we spend time on ALL facets of form design improvement?

This article was originally published on mds.is, because apparently now you have to post on your own blog AND Medium because who wants to format only one blog post?

For more resources on the origins of the float label pattern see this post.

Are Float Labels Really That Problematic After All? was originally published in bymds on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mind is the master power that moulds and makes,

And Man is Mind, and evermore he takes

The tool of Thought, and, shaping what he wills,

Brings forth a thousand joys, a thousand ills:—

He thinks in secret, and it comes to pass:

Environment is but his looking-glass.

-James Allen

Smart mobile design

One of the best gestures I’ve seen emerge since pull to refresh is the Facebook flick. I’m talking about that little gesture you use when dismissing a photo back into the news feed. There is still the done button in the top right to cover the UX tracks, but the flick just seems so right. It’s one of those things that once experienced one thinks, “Everything should behave like this.” I find myself browsing the iOS camera roll trying to flick away the photo back into its place, but then remembering I have to sluggishly tap the photo for the controls to appear, then tap back. That’s like 2-3 seconds longer than a simple little flick gesture.

Anatomy of the flick

Dismissing a photo is a situation when you want to immediately return to your previous activity. Tap to close works, yes, but sometimes taps misfire and cause micro-frustation (I’m totally making up words here) and don’t quite feel right. Path does away with the done button and just uses a full photo tap to dismiss. I loved this solution when I first used it, that is, until my love affair with the Facebook flick.

The Facebook flick works so well because it’s instantaneous. There is no delay. At the very millisecond your finger begins to move up or down the photo it iniates the dismissive animation, which can also be canceled by reversing your gesture. You have complete control. This empowers Facebook stalkers everywhere to view and close photos at lightning speed.

You can see in Path that it takes several milliseconds before the photo closes after the finger touches the image. This could be sped up to be instantaneous, but then you’d lose the ability to pinch and zoom in on the photo. Not ideal.

Involuntary movement

When a pesky fly lands on your arm, what is your natural instinct? Flick it away of course. Facebook tapped into a gesture that has been prewired into humans since the beginning of time - flick to dismiss.

What other natural instincts are out there that haven’t been tapped into and repurposed for mobile design?

Forecaddying to be exact. A forecaddie doesn’t carry a bag of clubs, but rather stays ahead of a cart-riding, foursome of golfers. His duties consist of finding golf balls, taking pin-distance measurements, cleaning clubs, fetching clubs, bagging clubs, holding clubs, reading putts, and more.

This was my job during the latter half of my college years. It is to date, the most arduous hiring process I’ve ever had to go through. There was a 3 part interview - general golf questions, a 30 minute phone interview where the caller would asked questions like, “Have you ever felt the flow?” and “Can you describe an example where you’ve gone above and beyond?” and an on-site group interview at The Ritz-Carlton, Reynolds Plantation Luxury Golf Resort.

If you were fortunate enough to pass the phone/social/psychological interview portion, you were brought in for a 5 day, unpaid training session. You were taught the basics of forecaddying and eventually graduated as a certified professional forecaddie.

Forecaddying is all about staying attentive to your golfers’ needs. Each member at the course is treated like a VIP, so the pressure is on big time not to screw up.

You typically meet them on the driving range and begin asking questions like “Where are you from?,” “What brings you out here?,” “How often do you golf?,” “What’s your handicap?,” “Would you like me to clean your clubs?,” etc. We call this user research in the design world, but it’s really just asking questions, sincerely listening and paying attention because you actually care.

In addition to getting to know the golfers, you have to be able to read them. Their body language, the way they interact with people. Do they seem easy going or are they cussing on the driving range after slicing the ball 100 yards to the right? You have to determine very quickly what type of personality type they are and what type of service they are going to prefer. You find this out more and more with each hole played, but to start with, you’ve got to use your gut. You have to read them and adapt.

Some golfers want to know every detail about the hole they are about to play while on the tee box. Others like to figure it out for themselves with only a minimal amount of information. Some golfers like to have their club-face cleaned after every shot and carried back to their bag. Others like to carry it themselves. Most golfers like to know if there are any breaks on the green that aren’t apparent. You have to remember and act on all of this while running through the woods looking for golf balls, stepping off measurements from the nearest yardage-marked sprinkler head, tallying and writing down distances for every player, and running around like a madman albeit composed and confident.

Generally there will be one high maintenance golfer, two easy going ones, and one quiet self-sufficient type. You have to adjust your service to fit each one at every aspect during the game. Which one will rake their own bunker? Which one wants you to read their putt, mark their ball, etc.? You strive to make each person happy with your performance because after all, you are working towards that big tip at the end.

There are so many variables to process it seems daunting but this is where the “flow” comes in, as the phone interviewer alluded to, so many weeks before.

This is no different than our job as designers. We have to understand our users before we can effectively design for them. We need to know what they like, what they don’t like, how they interact, what are their preferences. We parse all of this information to make informed and intuitive decisions regarding interfaces and flows. Just like caddying a round of golf, we start with assumptions about the golfers and refine as the game continues. As we learn more about users, we modify our service for them and begin to relate on a more personal level - from copywriting to interactions and beyond.

Many times after finishing a round of golf, I often felt very much connected to the players. It wasn’t uncommon for returning golfers to request caddies they had previously used - friendships were built. We shared stories and experiences together. The golfers trust the caddies because they were extremely knowledgeable about the course and provided paramount service.

There was a sign at the caddie office that said “Caring to serve. Driven to be the best.” Although I thought it was incredibly cheesy at the time, this should be no different with all of our digital endeavors.