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.
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!