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!
Out of all the conversations I’ve had with individuals who have had ideas for apps, the one I had with Miloš Jovanović stands out the most. That’s why I’m so pleased he is going to be telling his tale at Mobile Portland on Monday.
Most of the conversations about app ideas have similar characteristics. Someone has an idea for an app. They think it will be a hit. They don’t have the technical abilities to build the app. They don’t know what it will cost. And they’re trying to figure out how to make the app a reality. So they ask me for advice.
I start by sharing some articles that I’ve found that describe how much app development costs. We’ll talk about how it isn’t enough to simply build an app. You need to have a business plan. That you need recurring revenue to maintain the app. What happens if you build it and they don’t come?
And that is often the last I see of the individual. The app never gets created. I always feel bad to see their ideas die, but simply having an idea isn’t enough to be successful.
Miloš was different from the beginning. Yes, he had an idea for an app, but he set himself apart in our first meeting by demonstrating how much research he had already done. He had domain expertise. He wanted to learn everything there was about how to build an app and a business.
He had even gone so far as to hire someone to build a crude, throwaway application just so he could see what the process was like.
And Miloš didn’t just distinguish himself during our meeting. He has shown perseverance in his pursuit of his vision like no other person I have met. He has been working on making his vision a reality for two years now.
There are many points where it would have been easy to give up. And even now, I don’t know if SpaceView, that app that Miloš is building, will be successful.
What I have no doubt about is that Miloš will be successful in whatever he does.
And I now have a simple answer when someone asked me what it takes to build an app: you need to be as persistent and dogged in pursuit of your vision as Miloš has been.
If you have an idea for an app and you’re wondering what it takes to build one, I highly encourage you to come listen to Miloš on Monday at Mobile Portland. It’s not to be missed.
In case you’re curious, here are the articles that I’ve found do a good job of describing how much it costs to build an app.
I realized as I wrote those words how sad I was that I’m going to miss the meeting. I’m going to be in Boston speaking at An Event Apart. I’m always sad when I miss Mobile Portland, but this month is a double whammy. I’m not only missing Miloš, but I’m missing out on an opportunity to see Urban Airship’s new offices. :-(
There are things that we put on web sites that we know annoy users. We know they annoy users because they annoy us as well.
But it can be hard to convince your boss or your stakeholders that they shouldn’t do something that is annoying when so many other sites are doing it.
That’s why it is so encouraging when Google decides to penalize sites that utilize these practices. Now you can say to your stakeholders:
So you want to add a full screen ad to encourage people to download your app before they can read your content?
Go ahead and do it if you want to decrease your search rankings.
Oh and by the way, people really hate these download my app pages.
So you’re going to redirect mobile users to your mobile home page?
Ok, but you’re going to piss people off, and it is going to affect your search engine rankings.
And really, URLs should just work no matter what device someone happens to be using at the time.
Oh hey, you’ve got a mobile design, but it is still downloading all of the desktop assets?
Well, now not only will people never see your wonderful design because it will take too long to load, but you’ll also be penalized by the search engines for serving such a slow site.
As I’ve said before, the first thing you should do to optimize your desktop site for mobile, is make it fast no matter how it looks on a phone.
In general, I think people spend too much time focusing on search engine optimization hacks and not enough time on writing and producing compelling content or products. But in this case, Google is changing their algorithms that penalize bad practices and create more better sites for users and we’d be foolish not to use this to try to win arguments.
So the next time you’re in a debate with someone who wants to put a big ad on every page to get people to download their app, appeal to their humanity. Remind them that they are hurting people.
And if that doesn’t persuade them, appeal to their wallet. Tell them that they will be shooting themselves in the foot when it comes to search engine rankings.
On a recent responsive design project, we wanted an off-canvas menu for narrow viewports. We tried some of the off-canvas menu libraries out there. But, being very particular about design and performance, we ended up writing our own.
Our library, the not-so-creatively-named offCanvasMenu, is a jQuery/Zepto plugin built for flexibility and performance.
Many of the libraries we tried required that we structure our HTML in a certain way. Others were built to be a complete responsive menu solution, having their own opinions about where the breakpoints should be. We found both of these aspects to be too restrictive.
offCanvasMenu doesn’t depend on the structure of your HTML. Just specify which elements to use for the menu and menu trigger, and the plugin takes care of the rest.
It is not a responsive menu. It’s meant to be used as part of the responsive system you’re already using. Your code determines when to turn it on and off. The plugin also exposes methods for opening and closing the menu, if you wish to add support for other gestures, such as swipe.
offCanvasMenu, when used with Modernizr, will use CSS transforms for animation if the browser supports it. Of course, if the browser doesn’t support CSS transforms, it will fall back to using jQuery/Zepto animation.
It also eliminates the 300 ms delay between a tap and the resulting animation by firing on
mousedown, rather than
Update: We’ve changed our thinking on tap-handling within the plugin and have removed the feature. This is best handled on the page level, using a library like FastClick.
Try It Out
You can see the plugin in action as part of a responsive design on its GitHub page. To see more examples or get the plugin, go to the repository page. Please let us know if you have suggestions for improvement or run into any problems.
We hope you find it useful.