As part of my day job at Bloomberg, our team just released a pretty mammoth update to our iPad app. In one monthly release cycle we added pencil support, picture in picture video, iOS multitasking, plus our own in-app split screen multitasking. I've written a fairly techy blog post over at Bloomberg about it, go have a read!
Here are four links to articles on a theme. The first three ask, in their own way, if the tablet is coming of age: is it ready to do real work on, can it really replace the laptop for some of us? The fourth article is a link is to my piece from 2013, that posits the PC as we know it - all pervasive, in our homes, on our laps - was just a blip, and its first home, the office, should be its one and only home. To me, they are all singing the same song.
“At some point, the difference vanishes. Most people never did “real work”, by whatever metric, on their computer; they were happy to browse web pages, send emails, Skype friends, whatever. Yet the redoubt of “real work” is defended valiantly, perhaps by those whose jobs depend not on the work, but on the tools used for it — the PC.”
A great article around the general derision of the use of tablets to do what people snobbishly refer to as ‘real work’.
“Moreover, what I’ve come to realize is that the iPad is a much more elegant system than my Mac. This isn’t to say that I have no use for my desktop (more on that in a moment), but that by and large iOS software is considerably more thoughtful, more carefully considered, and more visually polished than desktop software.”
A discussion of whether with the latest generation of iPads and accessories, and the accompanying software, if designers can now build successful workflows without resorting to a PC.
"The fact that the keyboard and screen are limited to being held in an L-shaped configuration seriously limits its flexibility. It is basically impossible to use a MacBook pro while standing up and downright dangerous to use when walking around. Your computing is limited to times when you are able to find somewhere to sit down.”
“The PC unwittingly really did become the personal computer. And then the iPhone happened. And we all realised that actually, that was what we really wanted when we said personal computer.”
Back in 2013 I discussed the hisory of the PC, how it inadvertendly ended up in our homes, and why I would love to see it leave again once and for all.
We are at the dawn on a computing era where we should, before undertaking any new project, be asking ourselves: "what do I want to achieve?". Actually achieve. Not "what app should I build, what program should I wrote, what digital artwork should I create, what blog post should I write? What do I actually want to achieve?". (Yes, I just used bold-italic.) When you have honestly asked that question, then, look around, without prejudice, and pick the device or devices and tool or tools that allow you to accomplish that goal. For so many people now, finally, computing no longer needs to be the goal: it can consigned to being the magic glue that provides the tools for us to accomplish our goals and dreams.
This October I attended the London JAM Conference 2015 - Sharing the Stories Behind Great Products. I'm primarily a developer, and so I went along hoping that some of the content would be relevant to my role, and the conference did not disappoint. These are my 5 key take-aways from the day.
Note While the conference had a great line up of speakers and all were inspiring, each of these lessons is based upon a point or points from a particular speaker. I've developed each of these ideas into my own for this article, but I've credited the original speaker under each.
1. Five Whys
(From Pip Jamieson, The Dots)
Five Rings is a famous book by kenjutsu practitioner Miyamoto Musashi on business strategy, later found to be applicable to martial arts and sword fighting. Five Whys is the second most famous concept to come from Japan about 5 things.
A technique used by the under-fives for millennia, it was formalised by Toyota founder Sakichi Toyoda (yes, the same one we stole all those other 'lean' ideas from) and is a technique to help get to the root cause of a problem. It's simple: ask "why?" 5 times when questioning a problem. The reason Five Whys is important enough to go on this list is that it's so simple, yet it's so easy to forget to do. There's a great example here from the guys at Buffer.
As a developer, try applying Five Whys when next tackling a bug: either apply to the problem you're trying to solve, or to your proposed solution. If applied to the problem, chances are you'll uncover the root issue rather than the special case your bug is. Applied to your proposed solution, you'll make sure you're actually solving the right problem. It can work in both directions, and it's like rubber-ducking on speed.
Put down that burger, I said 'Whys'!
2. Idea Incubator
(From Pip Jamieson, The Dots)
A good development team can be a great source of product ideas, but these ideas rarely see the light of day. This can be due to prejudice against ideas coming from Dev, or simply because they don't come up at the right time or get heard by the right people. It can be unproductive for a dev team to discuss ideas that aren't in the current sprint or in the backlog, but you don't want to discourage the principle. Idea Incubator is an outlet for this creativity: every two months, organise a formal internal pitch session where anyone can present their idea to Product. Keep it lightning-style: two or three minute pitches, and five minutes for feedback.
The benefits are legion:
- Everyone is given a chance to contribute to the product and so promotes inclusion.
- The sprint is not blown off course by discussing ideas that aren't yet relevant.
- It provides a natural filter for ideas: it seems like a great idea now with all this other work to do: will it still seem like a good idea in a few weeks?
- Another source of potentially great ideas!
3. Be A Customer
(From James Gill, GoSquared)
When developing or launching a new product, it's very clear that the on-boarding experience needs to be refined to perfection: firstly, to give the best possible first impression to your customers, and secondly, to make sure attrition is kept to a minimum. However, if you work on a well-established or long-running product, or a product people have no choice but to use, this part of your experience can easily be neglected. As a developer you may work in a sandbox that is far from the standard customer experience, or not us ethe same sign in process as them. Even worse: you might not even realise!
Once a month, sign up or log in to your app or site or service. How was it? Fast? Slow? Confusing? As a developer you may not be able to control all aspects of this process, but focus one the parts you can. Was the keyboard set to the right style? Did the spinners freeze? Look at the code: could it be more efficient? Run faster? DO things in paralell?
For those aspects your can't directly change - there could be a UX or business reason why the process is a certain way - it's still better to find and discuss them, so everyone understands what decisions have been made and why. Even in the worst case where you might not get a good explanation, you'll at least build up some empathy for your customers!
4. Use Processes, Don't Fight Them
(From Tim Davey, OneFineStay)
There are many ways to upset a developer, and enforcing process where it doesn't belong is right up there with telling them they're using the wrong text editor. When software is developed in a large team or organisation there are places where decisions must be made, or workflows adhered to, in order to keep the team running as a cohesive unit. They might seem arbitrary, but they are there to promote consistency, reduce complexity and therefore improve overall efficiency.
Use process in the areas where, as a team, you have a pre-agreed position on a decision that needs to be made regularly, or where there is a rule-of-thumb and it can usually be followed. By using process in these places, you reduce decision fatigue in your team and improve the quality of the decisions that they must make.
Culture is the way a collective of people can make individual decisions. By agreeing on and abiding by certain processes, you can create a team culture that encourages free-thinking but is fast, efficient - and most importantly safe - as the decisions are made within a consistent framework that you all fundamentally subscribe to.
5. Never Don't Not Use Data
(From Graham Paterson, Intuit)
The benefits of using data to assess your product are clear: it can show you why your product is succeeding or failing. What isn't so clear is the danger of not using data. If you don't use data, your product may be succeeding - or failing - and you will have no idea why.
- you won't know why you have suceeded
- you won't know why you have failed
- you will miss illogical cases
This is why data-driven analytics aren't just a luxury: they are a necessity. Of course, data is never an excuse to not listen to customers too: the two need to go hand in hand to keeo your prodict on track.