Why it's time to stop making assumptions, and put in the work.
Developer Experience is a primary hurdle between ideas and implementation. Yet, consistently, designers and product managers can be heard making statements—confidently, no less—like the following:
- “What developer would read API docs on their phones?”
- “Developers don’t want to code on their phones.”
Where are these opinions coming from, and why are they being made so strongly by people who aren’t developers?
App Store Results
Searching for “code editor” on the various mobile app stores yields the following results
Apple App Store: iPhone apps: 89 results, ~10 for margin of mis-categorization.
There are actually 2 results for Apple Watch. It’s not that crazy when you think about it. The Apple Watch is primarily used for notifications. Developers need those to keep track of all the things we need to monitor.
iTerm2 is a perfect example.
Google Play: Android Apps: 256 apps, ~125 margin of mis-categorization and/or store-driven result padding. Still, a lot of developer focused apps.
Microsoft Windows Phone Store has a dedicated “Developer Tools” category, but admittedly that is pretty slim because very few people buy Windows phones. To be fair, that category most likely exists because it’s a desktop app store as well. However, there are 23 apps. 0 margin of error here.
Case-study: Panic Prompt 2
One of the primary flaws in thinking about developer tooling comes from the traditional desktop interaction patterns of mouse and keyboard. Developers tend to lean heavily on the keyboard for as much interaction as possible.
The Prompt app from Panic, Inc. is a wonderful example of design thinking, particularly diverging from the as-is scenario and using technology to enable a unique, stellar experience.
Prompt is an SSH client for iOS. If you have ever done any UNIX-related work, and chances are you have, you know that a lot of typing is involved. If you’ve ever worked with SSH, you’re aware that many tasks require specific encryption commands, modifier keys, meta keys, and more finger gymnastics than getting gum out of your dog’s fur.
The designers at Panic have taken advantage of the custom keyboard capabilities in iOS to provide shortcuts to the most commonly used commands.
Why would anyone want to use this? If you’ve ever gotten a call on a Friday night about a bug or a server being down, while you’re out trying to enjoy your weekend, you already know why. Once again, this is clearly an application of empathy from Panic’s designers.
When there is a need, people will do whatever it takes to get it done. As designers, we need to make the ability for users to complete tasks as frictionless as possible. This especially includes developers, and the mobile path.
As of WWDC 2016, Apple agrees with this. They’ve introduced their own Swift Playgrounds for iPad app, which leverages many of the UI techniques I’ve described in this article.
Case study: Dash
Kapeli Dash is a developer favorite for collecting and managing sets of documentation on MacOS, including snippets, and offline access.
2 years ago, Dash for iOS was introduced, proving that smaller form factors don’t have to sacrifice utility.
The developer even set up “Dash Remote”, which allows syncing from the Mac desktop app to support bidirectional search and mirroring to the iOS app.
Case study: Pythonista
Pyhonista is one of the best development experiences that exists on mobile devices. The interface feels ergonomic, and plays to the strengths of the iOS platform. Touting itself as a “full Python IDE for iOS” (I think it’s something more, and better), I’ve never had this much fun using an interface designed to help me learn by way of tinkering.
The GitHub in the Room
GitHub is home to 38 Million open source projects at the time of this writing. Why, as we tread closer to the year 2017, must we be satisfied with this 2008 experience on small screens, when working?
The dashboard content is missing the largest part of the desktop UX: the feed.
No autocomplete at all. Not for emojis, not for user, team, or org @mentions, issues, commits, nothing. It’s literally just a text area.
The desktop site has it’s own issues, though. First, it’s not even a little responsive.
and my favorite screen:
This doesn’t even begin to talk about GitHub’s mobile UX with wikis and gists, mind you, and I’ve just scratched the surface. What I can’t understand is how badly the mobile experience has been overlooked, when clearly the need is there.
I’m still not sure where the concept or confidence in saying that developers don’t use their phones came from, but hopefully this post is something you can point naysayers towards when it inevitably comes up in the future.