Writing Code on a Phone

Learning to program on a phone is actually easier than you might think. You just need the correct peripherals and the right software to help you accomplish the goal. One such software apps is the Coda by Panic, Inc.. It has all of the benefits of a normal SSH client but also helps create SSH keys, and gives you easy access to multiple sites. Combined with screen on the remote host and you can easily pump out code on a phone.

You can learn Python, or Java or Ruby or whatever you fancy. Coda also has a nice feature where you can preview your code before you bother uploading it. Combined with the Transmit application you can easily sync between your phone and the remote server. You can use the remote machine as a file store, or a backup, or as a test server, etc. All you need is a couple of apps and the determination to learn how to develop on a command line and you’ve got everything you need!

I’m always amazed when people don’t take advantage of things like free EC2 accounts (as an example). But if you are just learning how to program, and want to get started, you don’t need anything more than a free EC2 account and an app like Coda to get started. A quick note on EC2 though – EC2 is free to use as long as you don’t use it a lot (lots of CPU usage, or disc usage, or bandwidth, etc), so if you’re going to start doing something significant, you’ll want to think about your options a bit more.

Like always, I think that trying to program or do any meaningful tasks without a full keyboard is slow and tedious, so make sure you have a Bluetooth keyboard. But just today, I wrote several small programs, compiled Java, set up some aliases, copied code around and many other administrative tasks all from my phone. It’s always going to be easier to do it on your desktop, but we’re getting closer and closer to a world where you won’t miss your laptop one bit!

Rules of Thumb for Business Mobile App Development

I’ve spent a lot of time with various types of mobile apps over the years and compiled a list of things to think about when developing a mobile app for business use. If this saves anyone a headache while using your app, that’s a big win. If you want to make your business customers happy, this is the hit-list I’ve come up with:

  1. Make it work functionally. So many apps have drop downs or buttons that don’t do anything at all. It’s mind boggling how these apps make it through the QA process. But if something looks like a button and doesn’t work like one, you’ve created a usability nightmare.
  2. Make it easy to use. A lot of apps have rich functionality buried underneath a complicated/convoluted multi-tier navigational structure, making it difficult to find the options necessary to interact with it in the way the user wants to. There’s been a lot of studies that the more you make someone click the less likely they are to find and click that option. So keep the interface clean, simple to use and easy to navigate. Don’t forget to pay attention to your workflows.
  3. Make it stable. I regularly run into unstable apps that crash when you do something like navigate away and then navigate back. That’s a terrible user experience. Your apps should be memory efficient, fault tolerant and if they do crash they should do so in the most graceful way possible.
  4. Make it save work if appropriate to do so. Some apps are safer to use because they save work as you go. Crashes are quite common on mobile, so this is a very useful feature if it’s appropriate to do so.
  5. Make it work with an external keyboard. Things like tab and shift-tab should work as expected – getting you from one form field to the next. If you have to take your hand off they keyboard to use your application you should probably re-think it, unless it is core to the app’s functionality (like a drawing program or something). Business users intuitively feel like touching the phone and interacting with it directly slows them down. Lack of a mouse really hurts app developers, but that’s a separate issue.
  6. Make it work equally well in landscape and portrait. So few apps do this well or even at all. Not even the settings app on iOS does this. Having to switch between the two just to use your app is annoying to say the least. You’re not a special snowflake and there’s almost never a reason to force the user into one mode over the other. Some apps like games need it to be in a certain orientation, fine, and no, I’m not talking about those. But your feature had better be worth it if you’re going to force the user to change the orientation of the device. Don’t play favorites though – just because you envision someone using the device in portrait mode, doesn’t mean that’s how they want to be using it. That’s especially true if they are using an external monitor.
  7. Give your app the same functionality as the browser version of your website. This should be straight forward, but almost no apps get this right. They often have no signup system, no payment system or a bunch of missing features. Why bother building an app if you aren’t allowing your customers to give you money? The worst is when websites force you to download an app and then don’t have the feature on the app. Are you trying to drive the customer away?
  8. Give an option to remove your ads, even if that means payment. It’s the most requested feature of most apps that have ads. Go ahead and do them a favor. Ads are not just annoying, they’re also a huge user of data, and mobile data plans aren’t cheap.
  9. Allow selectable muting and selectable alerts. A lot of the alerts that you think are important a user will disagree with you on. Meanwhile a lot of the things you couldn’t care less about a user will kill for. Making your alerts as selectable and customizable as possible is very helpful. As an example, making alerts specific to certain senders in emails would be very useful because some people have very important things to say, and many people have way too much email to get alerts about every inbound email. Selectable alerts is a winner.
  10. Keep push notifications to emergencies or important notifications only. Basically my rule of thumb when it comes to alerts is silence all of them unless they are warning of something involving a combination of the three I’s: impending, important and irreversible. If your alert is telling me about something I don’t care about you’ve made me that much closer to uninstalling your app or muting it permanently. Don’t waste the user’s time.
  11. Give the option to disable access to the location when not in use. Not only is accessing my location a battery hog, and a data hog it’s also just plain creepy. Ask for only the permissions you need. This should be obvious, but most of the time it appears it’s not. If you really want to be nice to your user only ask for it when you need it, rather than upfront. That way they can selectively disable it and re-enable it. Not many people are this paranoid, but when they are, this little detail can go a long way.
  12. Use SSL/TLS for everything possible. A lot of apps not only don’t use HTTPS but they don’t even tell the user that they aren’t. So there’s no way for them to even notice that something nefarious could be happening and is possible, unlike a web application with a browser where the protocol (http or https) is in the URI field.
  13. Create layered authentication if the app’s access includes sensitive information. For example banking apps shouldn’t allow users to check details without authenticating each time. The rule of thumb here is that theft of an unlocked phone should not mean complete loss of whatever data the app has access to if you build your app well. This really only applies to sensitive data, but it’s amazing how many apps have sensitive data these days.
  14. If you’ve discontinued the app in favor of another one, alert the user to that fact. I’ve run into a number of situations where the app appears to no longer work, but what really happened is that they stopped supporting that version and created a new version. Without telling the user, you’re really creating a terrible user experience.

These rules of thumb are primarily related to business apps but I can see situations where many of these issues could be useful for any sort of mobile application. Let me know if you think I’ve missed anything.

Mouse vs Productivity

A friend of mine sent me a quick note that I thought was worth sharing. In an effort to improve production vs consumption he has opted to forego a mouse entirely in his PC environment.

so an interesting thing I’m going to try is is turning off my mouse whenever I’m “working”. So doing anything focused like coding or whatever. Get to know my keyboard shortcuts better and hopefully be a nice way to reduce the temptations to get distracted

Obviously there are some times a mouse really aids in production. Drawing, or clicking through research to find the snippet of code (consumption for the purpose of production) or clicking on rich apps that have drop downs are all examples. Ironically, the lack of a mouse is one of my greatest pet peeves with the iOS environment because tab doesn’t work the way you’d expect it to in most apps. But this is an interesting take on improving productivity that I hadn’t heard of before.

Context Switching

Context switching is one of the most important issues with using an operating system of any sort. What I mean by that is if you have two tasks running in parallel and one of them needs your attention it becomes a very real issue for usability.

In the simplest example, let’s talk about a terminal window, like SSH. If you have a program that, for instance, wants to message all users on the system with some information it will overwrite the screen you’re currently looking at. This is a pretty terrible user experience if the page is being repainted regularly. Not only is it distracting and might impact whatever you’re doing negatively, but it’s also potentially hard to read and switching to that task is overly complex.

On a smart phone, context switching is just about the worst experience imaginable. I’ll talk about how bad alerts are in a future post, but for now let’s just talk about when I do care about the alert and do want to switch contexts.

First thing’s first. Let’s say I want to do the equivalent of an “alt-tab” in Windows, but on an iPhone (as an example). There really is no such thing, and no keyboard equivalent of that that doesn’t have some other massive impact on usability (accessibility features do not count since they hurt the user experience so dramatically in other ways).

That means, my hands now have to leave the keyboard to click on the home button to launch the other app if it is open, or worse, hunt around for whatever sent me a push notification and open it. Or if I’m lucky enough to be able to get to the alert/push message in time to press it before it disappears, it will switch me immediately so that I can interact with it, but then I’m left with the same issue of having no way to get back to the screen without hitting the home button again.

This context switching turns out to be one of the biggest productivity faults with the iPhone’s design and it’s something the Windows mobile has spent quite a bit of time getting right from what I can tell. It’s definitely an area of improvement. My general take on this is that Apple probably just never expected anyone to use an iPhone in this way and that’s why it’s missing. Or they may have decided that people should use the iPad if they want to produce vs consume because the iPad does have this feature – meaning it’s a software only issue that hasn’t made it to the iPhone despite being equally useful.

Without speculating too much, I think this is an incredibly useful feature, that has been either intentionally or unintentionally ignored, but makes the iPhone (as an example) unnecessarily slower to context-switch and more difficult to use for a Smartphone Executive.


One of the more common complaints I hear about trying to use the phone is that it’s slow. These people don’t necessarily mean processor speed, or refresh speed, or anything related to hardware specs per se, for the most part. I think a lot of people feel that the modern cell phone is useful but slow because the workflow is tedious.

Let’s take the example of editing a Word Document hosted on your computer but saved through Dropbox. Without having to do anything special, it is synced to your local computer. Let’s walk through the two workflows of editing a Word Document. Computer first – and let’s use Windows 10 as an example:

  • Mouse over to your Windows Icon start menu button.
  • Click “File Explorer”
  • Click “Dropbox” and find the file in question
  • Double click the file.
  • Edit the file
  • Save or Save-As if you want to save a new version for revision control instead.

On smart phones, it’s a bit more annoying:

  • Click on the Dropbox icon to launch Dropbox and wait a moment.
  • Find the file.
  • Tap the file and wait for it to download, unless you’ve already selected it to be stored locally.
  • Click the button to edit it.
  • Select Word to open it (there’s no option to remember)
  • Wait for Word to download the file (despite the fact that it might be local to Dropbox) and open the document inside of Word
  • Technically you can edit directly at this point, but Word encourages you to select the button to put it into mobile friendly mode – and they should, because it’s a much easier mode to edit in. The problem being that is another step, and it lacks pagination and pagecount information which can be useful. It’s also got quirks where the cursor goes below the navigation bar at the bottom in landscape mode.
  • At this point you don’t have many options, because auto-save is enabled. Normally I’d say this is a great thing, but if you need to do revision control you don’t really have an option to “save-as”. You’re going to be saving over the original document, unless you took an initial step to make a copy.

I fully realize there are ways around some of this, but ironically, this is one of the best flows that I’ve found. The Dropbox/Word integration workflow is straightforward, the functionality is largely there, and despite the form factor, you can do what you want. I’d even say the functionality nearly mirrors the laptop/desktop environment. But the differences in workflow are substantially different even in this relatively good use case. It’s worthy of noting that most workflows are not nearly this nice either, which I’ll talk about in depth later.

As smartphone app developers think through the design, they should do their best to force the fewest clicks possible, and make the design as intuitive and easy to control as possible, because anything other than that is a time-waster and discourages use. If people aren’t going to use the app, the developers have wasted a lot of time building it – they might as well do it correctly, right?