Play

Once upon a time I used to work on side projects, writing mobile applications for other people. In an ideal world I would still be doing it, although maybe not for money, because that can play havoc with work/life balance issues. I love coding, but one full time job as a coder at a time is really enough for me. On the other hand, as I move into more and more management, it becomes more important to keep my hand in the coding game. But then you run into the problem of what to code.

Seriously, it isn’t easy to come up with a truly useful idea for an app, and that really isn’t my goal. What I want is a project that stretches my skills in some area, that is self contained enough that I can finish it well on my own, and that can plausibly bring at least some joy to someone. Which means that my favorite types of app to work on are casual games and fun learning toys.

Long ago and far away, I developed a toy app that let you count change, and that included a fun animation of tossing coins into a glass jar, complete with public domain sound effects and graphical assets I created from my own photography. Tweaking the animation curve and figuring out how to composite the graphical assets was fun. (Spinning coins!) I also learned about sources of public domain sound effects as well as the fact that many currencies are carefully protected by copyright. And that’s why my grand scheme of releasing localized versions for different currencies came to a screeching halt.

About a year ago I made quite a bit of progress on another app, this one related to fencing. Again, I learned a lot from it, including trying out more than one cloud service. In the end though, the design just never gelled and the use case never quite worked, so I abandoned the development on it. I may revive it some other time if I can find a way to solve the issues it had, but it was still an excellent project.

This afternoon I got waylaid by a casual game idea. I have some user interface design issues to solve and lots of user experience work to do on it, but a couple of hours of poking at the basic back end design makes me think I have an idea I can execute. Now I just need to spend some time dreaming up what the actual experience will be. It won’t win any awards but that’s not my goal. I just want to make something silly that will make people smile while giving me an excuse to play with code while I learn.

Happy Holidays

You’d think that the holidays would be a quiet time for developers. Sadly, no. Right now I’m in the middle of fighting another round with UTC versus local time and trying to explain it to the quality assurance folks who are backups to the primary folks who actually know the software design. It’s a special way of earning a living.

While I was looking into things, I discovered that the Japanese calendar is about to start a new era because the emperor is stepping down. I don’t think it’s going to affect the Japanese app we’ll be working on next year, but I’ll need to read up on it just in case. One of the worst things about being busy is that it makes it more difficult to find the time to keep up to date on what’s happening in the field. And yet, being too busy with work is almost always a better class of problem than not having enough to do.

Here’s a tip: don’t count on being able to use up your vacation days during the last week of the year especially if you’re on a small team that’s spread thin. Technically I should be off work all next week. Practically? Unless I work this weekend, there’s a good chance I’ll be spending some time in the office (or at least working from home) next week. Luckily I should be able to take a few extra hours here and there in the early part of the year to make up for it. If your employer demands that you be flexible in your schedule to meet their needs, then they should be flexible to accommodate yours as well.

Here’s to a productive and interesting new year.

Keeping Track

Well, I finally missed a morning deadline here. The good news is that it was because I was dang busy this week. By three o’clock things had started to settle down a bit and I started trying to remember everything I had done today. I knew it had been quite a bit, but when I started writing it all down, I was surprised at just how much there was and how easy it would have been to lose track of it all to the general sense of busyness.

Keeping a work journal can help. Sometimes I manage to keep a more formal work journal, separating out each project with milestones and issues. But even if you just keep a running log of things accomplished, issues raised, open questions, and future plans, it can be useful. It doesn’t have to be fancy, although I vastly prefer to have a permanently bound notebook so that you aren’t going to rearrange or lose pages. Just a cheap composition book will do the trick. I also use my work journal to jot down test data or to work through possible ideas. Many is the item I’ve been able to answer a questions just by flipping back through the pages of the past week or two. This is also a place where bullet journalling could be very helpful.

And if you want more ideas for how to stay organized and you like podcasts, Kevin Sonney’s Productivity Alchemy podcast can be quite good.

Documentation

When you’re in a small team and things are moving fast, documentation is important. Yes, documenting your code is important and the issues around it are well known. You do document your code, right? Documenting assumptions and decisions is more important.

There’s always pressure to be “agile” (don’t get me started), and even in a waterfall development model, you will need to make changes during development. Document the issues that led to the changes and why you decided to make that particular change. Eventually you will find yourself asking, why did we do that? If you have even basic documentation around midstream changes, it makes life so much easier. (And don’t forget to include the date when you made the decision. Sometimes knowing the sequence in which changes happened can make all the difference, although you can usually reconstruct sequence using source code versioning. Don’t count on it.)

But the hardest kind of documentation to do, and the one most often missed, is to document assumptions, as many as you can. They can be critical when it comes time to do testing or to evaluate future changes, or even when handling support calls.

Yes, I do mean that you should take the time to put together this type of documentation even if you’re a one-person development team. Six or twelve months down the road, you may not remember all the details of what you decided when. If you’re business expands and you need to bring on additional help, or if you’re in a larger team and you have turnover, this kind of documentation can make maintenance and enhancement go much more smoothly.

I may have been dealing recently with a project that has suffered greatly because the previous development team assumed that they would be doing the work so they didn’t document everything. Then the project was dumped on an entirely new team with little to no experience with the project. We should be out of the weeds in another week, but it’s not been a fun process. Now, every time I’m tempted to cut corners, I’m going to remember this project.

Cloudy

Have you ever used a cloud service to support the function of a mobile app? Whether it’s AWS, Azure, Firebase, some other service, or even a server of your own, it’s time to learn. Cloud services allow users to work seamlessly across multiple device contexts, as well as making it possible for users to interact with each other. Getting familiar with how to set up and interact with these services will increase the scope of projects you can handle.

If you’ve used one of them and gotten comfortable with it, I strongly suggest at least trying out one or two others. Not all services are the same; they have their own strengths and weaknesses and idiosyncrasies. There’s no one perfect operating system or programming language, and there’s certainly not one perfect cloud service.

Using a cloud service is also a good way to get used to the idea of handling users with intermittent or context based connectivity. While modern mobile devices are usually within range of connectivity of some sort, you can’t take that connectivity as a given. Ideally, as much functionality of your app as possible should be available offline. For some apps this might be a very small set of functions, but even a little bit helps, particularly if you handle the transition back to connectivity well. Build the user’s trust!

This also means that you need to handle more complicated testing scenarios around connectivity issues. Don’t just test on wifi! Test on cell data. Test on minimal and intermittent cell connectivity. Be inventive and some up with the worst case scenarios you can think of and test those. You can’t test everything, but catching issues before the code is deployed is generally cheaper than handling support calls/emails and is less destructive of user trust.

Some Assumptions

Never assume that your testers (yes, even your internal test team) know how to get an app onto a device. There are otherwise wonderful and intelligent people who believe that new app builds magically appear on devices without them doing anything. Chances are good that, like me, you are one of those clueless people in other contexts, so be patient, and over-communicate the procedures for installing. And don’t assume they will remove previous versions.

If your mobile application has an internal database, pay attention to when the database schema changes. If the schema changes, you will need to add code to upgrade the copy of the database that resides in the app’s sandbox. You also need to thoroughly test that update code with any and all publicly available prior versions of the app. Yes, it’s a pain in the tail.

Never assume that your users know what version of the app they are using, what version of operating system they are using, or even what type of operating system they are using. They are more likely to know they are using a Samsung than they are to know that the OS is Android. (On the other hand, knowing the manufacturer can be very useful when you’re dealing with Android issues!) You’ll also be lucky if they know which device model they’re using. Consider whether you can get some or all of this information from analytics reports before you release the app.

Never assume that the device has connectivity, not from a user support perspective, but particularly not from a code implementation perspective. Plan to handle the effects of intermittent connectivity on database functionality, external server syncing, and from a user interface perspective. Don’t just rely on the status bar to tel the user what’s going on and why something isn’t working.

Not Just a Word; Not Just a Checkbox

Don’t wait until the end of the design (or development!) process to think about accessibility issues. Accessibility is not just a buzzword. It’s not just a checkbox on your prepare for deployment list. It’s about making sure there are as few barriers as possible for all your users. And no, I’m not talking about capturing a few extra folks who might be sight or hearing impaired. I’m talking about the larger (and largely invisible) group of people who have various kinds of color blindness. I’m talking about making your app easy to use by people who are keeping track of kids while shopping for groceries, or students in a lecture, or people working in a poorly lit office or out in the sunshine at a soccer game.

Mobile devices are mobile and people take them everywhere. This is both a strength, because they tend to always have them available; and a weakness, because they take them into less than ideal situations and still expect to be able to use them. Accessibility features are for everyone, not just people you think of as being covered by (inadequate) ADA laws. And accessibility works best for everyone if it is part of the initial design decisions rather than being an after thought. Make it part of the design. Make it part of testing. If the team pushes back, come up with use cases for otherwise able people who would benefit. Can’t come up with an appropriate use case? Try harder.

Sometimes the pushback will come from the client. Be ready with your arguments. Implementing accessibility features up front tends to be cheaper (and more thorough and less likely to break things) than bolting it on at the end. You have to test accessibility features because, whether or not you intend them to be used, someone will eventually use them. Making sure accessibility features don’t break your app (even if your app doesn’t make full use of them) can save you losing that customer plus all the friends they tell about the problem. It’s cheaper to keep an existing user than to get new ones. Plus, it’s the right thing to do.

What’s in a Name

Are we still having this issue? Will it ever go away? (Yes, and almost certainly no, but one can live in hope.)

Look, it’s very easy to think that names are simple. You have a first name, maybe a middle name or initial, and a last name. Except that it is never that simple. If the data set you’re currently working with happens to be that simple, then you have a ticking time bomb waiting to encounter a perfectly ordinary name that will blow up your code.

I just ran into this one this week. A third party vendor we’re working with (through two removes, and isn’t that a joy) cannot deal with last names that have spaces in them. If you’re the eighth president of the United States, Martin Van Buren, and you try to add your data to this database, it will reject your name. The problem is that the database is trying to separate first and last names into their own fields, but the data being imported has the entire name in one field. So the data import process is using spaces to break up the string into first name and last name. But it can’t tell whether the first name should be Martin Van or if the last name should be Van Buren, or if maybe there is a middle name stuck in there for some reason. (Because, yes, it is also possible for a first name to have a space in it. Really and truly.) And last names can even have multiple spaces.

I would not be at all surprised if this vendor’s system also had problems with names that have apostrophes in them. I feel for the O’Brian’s and the rest of the apostrophe’d of the world, I really do. Hyphens don’t usually cause as much of an issue, but they can.

If your system is foolish enough to track middle names, then you’re going to have to deal with people who have more than one middle name. Two is not at all uncommon. Three isn’t unheard of. Are you going make your users pick just one of their middle names and lose the rest? And have you accounted for people who don’t have any middle name at all? (NMI is a truly ugly middle initial.)

Speaking of not having names, what of the large (yes, very large) number of people who don’t use surnames? I’m not talking about Cher and Bono here. I’m talking about whole communities where it is normal for people to have only one name. (See Indonesia and Iceland.) DO you leave the first name blank? The last name? Can your system handle a blank first or last name?

Now think about the people who use a first initial and go by their middle name instead of using a middle initial. Or a first name that has both a period and a space in it. Really. Names aren’t all Dick and Jane and Smith and Jones, not by a long shot.

If you’ve made an assumption about how long a name should be, there’s a good chance that you’re underestimated. Do your research. If you’re trying to create a good experience for your users and maintain valid data in your database, you don’t want people’s names getting truncated just because they’re longer than you had expected.

We haven’t even gotten to honorifics and suffixes yet, and we’re not going there today. Just be aware that storing and displaying names, especially when moving them from one system to another, is not as easy as you might think.

Mobile Design is not Web Design

When you’re doing mobile development within an organization that also does a lot of web development, you have to constantly be on the lookout for web design creeping into your mobile apps. Because of the large influence of web design on mobile app design (and because so much web design is now very much mobile first), it’s easier to find designers who are familiar with web and assume that mobile works the same. Sometimes it does; sometimes it doesn’t. Here are some things to look out for.

Descriptions of interfaces that describe users as clicking things. I know, this is a small and petty item. You don’t click mobile interfaces (unless they are hardware buttons), you tap or press or swipe them. And yes, even mobile developers can fall into this old habit. Insisting on describing it as a tap helps keep everyone focussed on that fact that this is a mobile app, not a desktop app.

Dropdown lists. This one isn’t quite as bad as it was a few years ago, but it tends to indicate you’re dealing with someone who is not only more used to desktop interfaces than mobile ones, but also someone who is very Windows centric. It’s not that dropdown lists are intrinsically bad. The problem comes when your designed reaches for familiar to them interfaces that aren’t native to the mobile environment you’re working in. Yes, you can implement these interfaces in a mobile environment, but that comes at a cost in time to code and test and continuing maintenance costs. It also tends to make your apps look naive in a mobile context and will threaten the trust of your more savvy users. Also, if your designer is leaning on desktop-centric interface patterns, they’re likely not making best use of mobile interface patterns.

Fonts. The availability of web fonts in a web context is great and allows for some wonderful typography, but be on the lookout for mobile app designs that use a large number of fonts that are not natively available on the device. You will need to add those (properly licensed!) fonts to your mobile app, increasing the app size and the load time. When you’re developing for multiple platforms, you probably won’t be able to avoid adding some fonts, but you should keep them to a minimum. Increased load times almost always results in more users abandoning your apps.

These issues get even murkier in hybrid development where much (or most) of the content is html/css/javascript served via a native web view. Even in this case, you should let your design be driven by mobile principles rather than desktop/web principles if you want an app that is perceived as being of high quality. And if you’re trying to contain development and maintenance costs as well, then sticking with native interfaces can help a lot.

Ye Olde Code

With limited exceptions, most mobile applications have a very short life, assuming they ever get used at all. [Insert links here] And a mobile app that isn’t updated every 6 to 12 months is essentially abandoned. If you’re a coder for hire, working on multiple projects for multiple clients, over a three year period you could easily touch 20 to 40 apps or more. (For reference, in the last five years I’ve easily worked on over a hundred apps, only one of which is still being actively maintained and updated.)

This is a good thing, yes? Now what happens when a client comes to you and says, remember that app you developed for us two years ago? We’d really like to get it installed on a device so that we can use it as part of a demo.

Did you archive the executable you delivered? Is it an enterprise app you can just resign so that it will install? Will it run on a current version of the operating system? If it runs on the current operating system, will the graphical assets look decent on current displays?

Or maybe you need to rebuild it. You do have the source code controlled in a repository, right? Do you still have an IDE that you can use to compile it? Will the IDE run on the operating system your development machine is currently running?

Even if the contract explicitly stated that you would not provide this service, you can potentially generate good will with clients when you are able to help them out. Just don’t let yourself get sucked into providing too much support for free. It’s best to determine ahead of time (before the request comes in) just what level of effort will necessitate creating a new work order and subsequent charges.

But also remember that, even with the best of intentions and the most reasonable systems in place, you won’t always be able to meet the client’s needs. (The client needs a 32-bit iOS app designed for a non-retina screen to run on the latest iPad Pro for a major event that’s happening in 24 hours. Ahem.)