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!
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.
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!
I’ve been musing on where device detection and Responsive Design + Server Side Components (RESS) fits in the solution stack as the lines between devices are increasingly blurred.
I would love to see solutions more like what the Riegers presented a couple of years ago at Breaking Development. Solutions that use device detection to inform first load, but then have fallbacks in place if the device detection was wrong.
Enabling solutions like that would allow the best of both worlds. You allow device detection to help you make the best guess at what the device is capable of so you can deliver an optimized experience, but you use client-side detection to redress the errors to ensure that if you get it wrong, you can fix it.
Then device detection truly becomes an enhancement to responsive design—it supercharges it.
BUT, the challenge is that bringing device detection into the mix creates a ton of implementation complexity. That’s why device detection remains something used primarily by large sites.
Here’s my half-baked idea: it would be kind of cool if device detection was running on Node.js and used all of the same API calls that are used client side.
Then you could run the same tests on the server and use it to set the first load code for page, but then execute the same logic in the client and if things didn’t match, you’d know immediately that you needed to fix it. Then you could use the same code on the client that was used on the server to build the correct experience.