GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).
Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.
We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.
It’s a complicated relationship.
Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.
Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.
We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.
In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!
Earlier this week, I made my first custom icon font using IcoMoon (implemented with Filament Group’s “bulletproof” technique).
I set my grid sizes and exported, but all the icons felt a little higher than I wanted them to be in relation to their surrounding elements. I did some finagling in CSS, but found the results varied (sometimes wildly) between platforms.
After some fruitless Googling, I trudged through the font’s preferences and found the culprit: A rather diminutive baseline height value. In IcoMoon, this is under Preferences, then Font Metrics.
Here’s a quick example at the default height (6.25%):
Here are the same elements and icons, but with a larger baseline height (18.75%):
Lesson learned: If the icon font’s vertical alignment is off, adjust its baseline height before resorting to CSS tweaks.
The more you know…
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!