Apparently it's been over a year since I added anything on here, which is mainly terrifying because it feels like 3 months at most. I've held off on a lot of practical posts thinking they'd be useful to save for Bopp, but now it's come to the point I'm actively working on Bopp, the writing hand feels a little rusty. So this is me dusting off the cobwebs.
Fashionably late, the origins of this post were mainly a reaction to #talkpay, a trending Twitter topic from a few weeks ago where people were encouraged to share their job and earnings.
There's been a lot of conversation around whether this is a good or bad thing. I agree shouting into the wilderness (well, the tech bubble wilderness) perhaps isn't the ideal environment for genuine insight into whether you're making a fair buck, but it's got people talking at least, and that can only be a good thing.
There's varying reasons why people don't agree. "People" often being well paid white men who are totally naive to the regularity of gender, age, and racial discrimination in all industries, and especially tech. What some people see as a boastful statement of wealth can be legitimately useful information for young freelancers or a lone woman in a dev team.
Out of those reasons, the most exasperating point which appears over and over again is how it's "not about the money". That you should ignore all external factors, industry standards, and simply ask for more if you think "that's what you deserve". That we should all work towards making enough to live comfortably in a nice location with the people we love and thus, inner contentment is reached. Along with some other zen bullshit.
I get that money shouldn't be a constant focus with your job. I also definitely know you need to love what you do to produce truly great work. But I accept that:
It does't happen 24/7. Sometimes, this shit simply feels like a chore.
It isn't mutually exclusive with the desire to make more money. Both can co-exist just fine.
There's also various reasoning for why people wish to make money. It's foolish to assume the intentions are consistently negative and greedy.
I've always had half an eye on stumbling upon some half decent product idea in the earlier years of my career and making a successful business out of it. I've also always planned to sell if that business ever became valuable enough to make a fair wedge of £ from an exit. But any kind of substantial cash injection for my bank account would go straight in to giving my parents a (slightly) early retirement, after working 7 day weeks and 12 hour days for nearly 20 years in the later part of their careers (aka planning for an early retirement), only to be dealt with the roughest of hands with the financial crisis of 2008 for their business. While they suffered bad luck, I grasped good luck by accidentally falling into a lucrative industry at the right time, and would love to help them in one way that I potentially can.
Does chasing money seem so ill-intentioned then?
In the meantime, slightly less substantial pay bumps via a rate increase will most likely fund more working travels and basic time off. A more selfish prize, but maybe slightly more sensical than investing in the latest shiny thing. To summarise, my moral compass has no issue with taking more money off my clients (as my skillset improves) to instigate more time abroad, or selling a company with the idea of helping my family out.
Everyone has their own story and motivation for making money. I'm not naive to plenty of people having the wrong intentions, but it's damaging to assume that's always the case.
If we can get over the mantra that focus on money and earnings is a bad thing, it'll go a long way to making that side of the industry far more transparent, which can only be a good thing for making tech a fairer place. A hashtag on Twitter may not be the finessed solution, but I'm really hoping it's a step towards transparent salaries, open freelance rates, and general debate around money in podcasts, blogs, and actual human discussion.
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.