When I wrote Common Patterns in Styleguides, Boilerplates and Pattern Libraries back in May, I honestly didn’t know if anyone would find something as pedestrian as a spreadsheet that interesting. It was great to discover I’d at least partially solved a problem for a lot of people. But I was surprised to hear from a handful of designers and developers who interpreted it as a score card… the more patterns a library contained, the better.
Yikes! Totally not my intention.
Here’s the thing: These frameworks are terrific resources. I think it’s really helpful to see how other teams craft (and document) scalable and modular interface elements. They are excellent points of reference.
But I tend not to use them for more than that. For two big reasons.
It’s a rare project that launches with less complexity than anticipated. So why front-load your project with the totality of another team’s interface needs?
.net magazine recently published an interview with six RWD experts. Here’s a gem of a quote from Tim Kadlec:
I think that our industry in general has it a little backwards: instead of the default being a framework or all these other little plugins and polyfills, the default should be just simple HTML and CSS. Then, as the project needs, you can start including things. But everything you add to a page or project adds something — be that weight, maintenance or complexity — and therefore everything needs to be justified before it gets thrown into play. Start light and vanilla and only add things in if they’re necessary.
And from Aaron Gustafson:
Opaque design thinking
Many of these frameworks are incredibly well-designed and executed. But how, and why? Why that corner radius? Why that font size? Why three button sizes… why not four, or five? How can we competently extend this design thinking without knowledge of its history or principles?
Trek Glowacki wrote a wonderful gist that describes this problem in detail:
Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.
Without first understanding that language it’s impossible to correctly express anything new. And that’s where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.
So why care about common patterns at all?
Our own responsive deliverables benefit from seeing what patterns emerge from those who’ve solved similar problems before. We can learn from their techniques while crafting new ones.
In the immortal words of Emil Faber, “Knowledge is Good.”
Sliding views (incoming views that “push” old ones off-screen) have become so commonplace in mobile design we tend to take them for granted. They’re useful because they allow content to be broken into bite-sized chunks while maintaining hierarchy through the use of spacial animation. They look pretty neat, too.
So we made SimpleSlideView, a plugin for jQuery or Zepto.
Check out the basic demo to see it in action. There’s also a responsive demo to show off how the plugin can activate or deactivate for different layouts.
What makes SimpleSlideView special? Since you asked…
You need a containing element and a way to select the views within it (a class of “view,” for example). That’s about it.
Views can be “pushed” (the new view “pushes” the old one from the right) or “popped” (the opposite). That’s it. No complex multi-step animations. No built-in history tracking.
popView methods to control navigation, or you can add some magical HTML5 data attributes (
data-popview) to links or anything else.
Plenty of frameworks do more. This one does push and pull.
Responsive by Design
Sliding views don’t always make sense when your viewport’s rather spacious. SimpleSlideView was developed for responsive layouts, and it handles them like a pro.
The plugin activates by default, but you can override that with the
deferOn setting. You can turn it on or off any time you’d like with the (creatively named)
It even has some nifty events you can use to activate or deactivate alternative functionality. See the responsive demo for an example.
Give It a Whirl
The plugin, source and documentation are available on GitHub… also an excellent place to report issues or contribute improvements. Let us know how you like it!
It’s easy to take the “masking” of passwords (replacing characters with ••••) for granted. As Luke Wroblewski documented last November, this practice increases login failures while providing little-to-no security benefit.
Here’s the alternative Luke and his team built into Polar:
By default Polar displays your password on our Log In screen as readable text. A simple, Hide action is present right next to the password field so in situations where you might need to, you can switch the password to a string of •••• instantly.
Similar patterns have also popped up in the LinkedIn app and Internet Explorer 10.
hideShowPassword is a jQuery and Zepto plugin for… wait for it… hiding and showing passwords. Give it a whirl!
The coolest part about this plugin is the “innerToggle” option. When true, it will create a nifty hide/show control you can style as you like. It even maintains the input focus when tapped in a touch browser.
You can get the plugin or view the source on GitHub (also a great place to report issues or contribute improvements). We hope you dig it!
It’s hard to believe it’s been almost three years since the publication of Ethan Marcotte’s seminal Responsive Web Design article on A List Apart. The ideas and techniques described therein blew our minds while forcing us to drastically reconsider our design processes. Even today, the struggle continues to determine which design deliverables make sense in a post-PSD era.
Personally, I dig Dave Rupert’s idea of “Tiny Bootstraps, for Every Client”:
Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs. These living code samples are self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.
The whole post is great, and it got me thinking… along with solid content strategy, design and engineering processes, what steps can we take to insure our “tiny bootstraps” are comprehensive enough to remain relevant and useful long after launch?
Cue Jason with a cool idea: We could document patterns in existing frameworks. A list of what’s typically included might serve as a good starting point, something to measure our client deliverables against to make sure we haven’t overlooked anything obvious.
In which I willingly make a spreadsheet
I combed through a (non-exhaustive) collection of suitably broad or noteworthy links from Anna Debenham‘s list of front end styleguides and pattern libraries, recording instances of observed patterns and adding new ones as necessary. I skipped over anything that seemed too idiosyncratic, and grouped elements of similar intent even if their description or implementation differed.
The results are contained in this handy Google Doc.
I found this to be a worthwhile exercise. It helped me wrap my head around the elastic scope of a “tiny bootstrap.”
I thought there’d be more overlap between frameworks than there is. I recorded over 160 distinct patterns, none of them ubiquitous. Some came pretty close, especially headings 2 through 4, typographic elements and pre-HTML5 form elements. No single framework included even half of the total recorded patterns (Bootstrap had the most).
Sometimes the most infrequent elements surprised me with how obvious they seemed in retrospect. For example, color guides and font stacks only occur in a couple of places.
The thought of maintaining the document indefinitely makes me queasy, but I’ve already started referring to it frequently. I’d love to know if anyone finds it as interesting or useful as I have.