I'm a digital product designer based in London. I get excited about working with great companies, and building great products. I have some upcoming availability, so if you're interested in working with me, get in touch.
Since last year's switch to freelancing, there's been a large increase in projects that require me to jump into an existing codebase. Clean slate projects no longer take up the majority of my workload.
When working with startups, this often means getting my head around a reasonably sized Rails app. Because almost any developer would recognise at least some level of complexity inside a Rails app codebase, I've always been provided with some documentation via the repository's readme file.
It's actually the smaller scale websites that tend to provide the easily avoidable headaches. With less code and fewer tools being used, developers seem less inclined to document the environment.
But with modern web development, it's rare to find a website that doesn't utilise at least some sort of tool or service provider. CSS preprocessors, web font services, build systems, gems and dependencies, front-end frameworks, content management systems — at least a handful of these will generally find their way inside a project.
Because tools seem to get smarter each day, these examples I've mentioned are normally super simple to get up and running, if you've worked from a blank slate.
Things get a whole lot harder when you're thrown into an existing environment that utilises these sort of tools, even if the codebase is a small one. It's not easy to work out if the original developer used CodeKit to compile their CSS, or guess who holds the TypeKit login details. Nor is it easy to work out the dependencies of Gulp.js or figure out the structure of multiple asset folders.
Things that may seem obvious when you've worked on the project from the start, could cause some real confusion with project newcomers.
Here's an example of a basic readme I recently put together for a small Jekyll website. This 5 minutes of work could save hours for a future developer.
In the past we could get away without documentation being a requirement for smaller websites. With static HTML, CSS and JS being the standard, the development environments barely ever caused confusion. But with the recent surge in tooling, a well written readme file needs to be a priority, even if you don't ever envisage handing the project over to another developer or team.
Remember the days when nearly every app on your iPhone used the same fixed 4 or 5 tab navigation at the bottom of your screen? Extreme gloss and all?
I've started to miss those days.
In fairness, a large portion of mainstream apps still use this navigation pattern, albeit with some much needed variation and improvements in visual design. When evaluating some of the apps I tend to use on a daily basis; Facebook, Tweetbot, and Dropbox all utilise it, and it's no surprise for me that they feel like some of the easiest and quickest apps to navigate around.
Nonetheless, app designers regularly seem intent on straying away from the path of standardised navigation design in iOS.
So, if we consider the alternative options, one design pattern in particular has obviously built up a lot of traction.
The off-canvas menu hasn't been lacking negative opinions lately, though most of the discussion tends to be around the icon and the potentially poor clarity of the menu's existence. Instead, I'll be focusing on the actual usability of the design pattern within iOS. I'd actually say off-canvas menus can be a great solution on the web as part of a responsive build for smaller viewports, but a clear labeldefinitely helps.
My dislike for off-canvas menus on my iPhone increased with the release of iOS7, which introduced a new standardised interaction that really damaged the usability of the off-canvas navigation pattern — swipe to go back.
Swiping to return to the previous page was an interaction I'd wanted to become a standard in iOS for a while. Instead of aiming at a specific point in the top left corner of the screen, my lazy finger or thumb can now aimlessly pull from anywhere along the left hand side. However I quickly realised how much this clashed with the off-canvas menu, which has been steadily gaining in popularity with seemingly every app update and redesign.
Navigating backwards and revealing the navigation are two of the most regular tasks you'll perform while using an app. It feels confusing for the same interaction to jump between controlling both features, and I seem to get it wrong pretty regularly.
Of course, there is generally some strong logic to how the swipe can switch between each task. If you're at the home screen of the app, the menu will appear. Any screens deeper than the initial view will make sure swiping returns you to the previous view. But if this is the only logic implemented, another fault appears.
A huge percentage of apps using off-canvas navigation implement it so it can only be accessed from the initial home screen. It's a minor fault when your app structure only has two levels, but with more complex apps using five levels of hierarchy, such limited accessibility for the navigation creates a major user experience problem.
I've demoed an example of this with Spotify for iOS. They've used an off-canvas navigation since the start of 2013. Let's say I've searched for a band, ended up viewing a related band, then want to check if this is the same band I recently filled a playlist with. That means switching between two key sections, which requires the off-canvas menu…
There's a large amount of swiping and screen switching there. Worst of all, I've had to go back whilst in the Search section, and thus lost the artist I ended up viewing.
However, despite using their app to demo these issues, the design team at Spotify have actually implemented support for a gesture which means the main navigation can be opened up in the lower levels of the app, avoiding this obstacle altogether. By dragging across the top header from a central point to the right, the navigation reveals itself, instead of switching back to the previous screen.
But here's the big problem with this. I had no idea that support for this gesture existed. In fact I only discovered it when researching the details of this post. I'm inclined to believe that many other iPhone users will be totally naive to this particular gesture too.
When delving further into this discovery, it's clear that this gesture is certainly not a standard alongside off-canvas navigation implementations. Rdio support it (their navigation setup is almost exactly the same as Spotify's experience). However, Gmail, Vine, and Foursquare (as some limited examples) do not. So, the standardisation isn't there, and perhaps most importantly, this design pattern simply doesn't feel intuitive. Even now when I'm aware of it, it seems awkward, and a solution formed from an afterthought.
Still, as a disputant of absolute truths, I'm certainly not saying off-canvas navigation should be thrown out of the designer's arsenal. I only wish to draw attention to the big problems with the majority of implementations.
Indeed, some app designers are thankfully experimenting with varying UI for these off-canvas navigations. One of the most interesting examples is what IMDb have done, which solves both problems mentioned above.
Visually, their navigation panel slides down from the top, and swipe gestures don't control it at all, so there's no confusion between the "swipe to go back" interaction. Then when heading into sub-screens, the header UI manages to accommodate a back button and the menu icon side by side, so the navigation is always accessible (with no complex gestures required). To help fit these tools in the header, they've removed the current screen title that many apps choose to display, an option that I'd encourage more designers to consider — often the screen content alone explains itself well enough.
For me, this is one of the best solutions I've come across.
IMDb also highlights the biggest and most consistent benefit to off-canvas navigation that I'm sure every designer is aware of, but I've yet to mention. Pages in their app are typically packed full of content, creating long pages to browse through. Fixing a navigation panel to the bottom would reduce the readable viewport, and the IMDb app does feel like an example where this really would damage the user experience.
Nonetheless, as some sort of conclusion to this post, I'd like to insist that designers for iOS should see the fixed tab navigation as the default standard. No matter how good the implementation is, an off-canvas navigation will require two taps to use at a minimum. Tabs are better at constantly informing the user where they currently are in your app, the links are always available, and they'll nearly always be the best option for encouraging interaction. And of course, they're Apple's choice for a design pattern standardisation. Using fixed tabs for your navigation may not have the slick, shiny visuals and interactions of an off-canvas menu, but they nearly always win for pure usability. Please, experiment with varying navigation types, experimentation is how better ideas come to fruition. But acknowledge the common problems that exist — don't ignore them.
…and seemingly an open minded research process where nothing is ruled out at the beginning?
Absolute truths are nearly always damaging, yet the modern designer's opinions seem to be full of them. Of course, knowing which ideas and design patterns are more often suitable and successful is a large part of being a better, and more efficient designer. But totally ruling ideas out because of popular opinion is just too close minded. Use research, use data, and decide on a per-project basis.
“Helvetica is overused.”
“Content toggles often mean a lack of content strategy.”
“Hover interaction fallbacks for touch screens always seem to get forgotten about.”
As true as these statements are, that doesn't mean any of the design choices or solutions are never suitable. Any idea can have its place, even if the circumstance is a rare or obscure one.