Ambient background image.

The work and times of the app development team at Steamclock.

Follow @steamclocksw or our RSS Feed or explore our archives.

Saving Money by Paying for Design

When we founded Steamclock, our primary focus was development. While we did do design work when needed, our clients’ teams typically led the design effort while we focused on the software engineering side of things. Since our clients often have in-house design talent, this seemed like a reasonable way to manage costs.

Over time though, we noticed a concerning trend. Projects where a client wanted to save money by doing app design in-house turned out to be more likely to go over budget. On the flip side, projects where we also took on app design were more often on or under budget. What was going on?

Perhaps unsurprisingly, we’d learned a lot in our years of designing and developing mobile apps. Just as designers with a deep background of building web apps get better at designing web apps, designers with a lot of experience in mobile excel at designing mobile apps. This experience makes mobile designers adept at avoiding common pitfalls or complexities on these platforms.

With these lessons learned, we can often eliminate problems at the design stage before they become costly. Usability issues, “scope bombs”, failure to make use of “free” platform features, unnecessarily expensive UI customizations, and insufficient user testing are just a few problems that can be remedied at the design stage by a team that knows mobile development well.

In the same way that a designer can create a week of developer work in an hour of design time, a designer can instead save a week of developer work in just a few minutes by asking the right question, proposing a more elegant solution, or making use of a hard-won lesson from a previous app we’ve shipped and iterated.

Having learned those lessons, I wanted to share some design elements that we’ve learned to recognize as signals – flags that a proposed app design could save a substantial amount of budget from a mobile-centric design and refinement pass.

1. Non-native UI conventions

Native iOS and Android component libraries provide a lot of navigation functionality for free, and adhere to the platform conventions users already understand. If a design uses dropdowns, radio buttons, “hamburger” menus, or other UI elements that are common on the web but not ideal for mobile apps, that’s often a sign the design needs a mobile-centric revision. Even sizing can be a big clue here: when we see designs that have drawn system controls to be slightly different than their standard sizing, there’s often an opportunity to save a lot of development time with a design pass focused on making better use of the platform.

2. Flowing text

Web and print designers are used to a text layout engine that makes it easy for text to flow around images, buttons, and other page elements. While this is possible in native apps, it’s often a lot more work than in web apps, and is a common signal that an app was designed with a web or print mentality.

3. Novel navigation

Some apps, such as Snapchat, distinguish themselves with a novel navigation scheme. Most often, however, it’s best to leverage users’ familiarity with native tab bars and drilldowns. Luckily, there are a lot of engaging ways for an app to distinguish itself visually from the competition without incurring great usability and discoverability costs.

4. Offline sync

Having built apps for eight years, we’ve seen almost every kind of requirement you can imagine. By a significant margin though, offline sync capability is the most frequent feature we see proposed for 1.0 that is best deferred to later. This is sometimes truly needed – for example, an app that is primarily used in the wilderness – but it comes at a substantial cost when you consider the additional development and design work to handle conflict resolution, error handling, sync status reporting, and all the other details that come out of a bullet point as simple as “offline mode”.

5. Welcome tours

A common issue we see in designs proposed by teams that are new to mobile is attempting to mitigate overly complex or unclear functionality by offering a “tour” on first launch. While it may seem like less work to throw up a tour before folks start using your app, text-filled screens are typically glossed over or not retained. Given that, tours don’t tend to fix most usability problems, and the work required to make sure every interaction is clear and understandable will still be necessary.

Shipping better apps

All that said, no matter how new your team is to designing mobile apps, you surely have a huge amount of insight and product knowledge to offer the process. Designing a new app is all about collaboration, especially for teams with a background in print or web work. If your app design work is hitting any of these issues, we’d be happy to help bring them to the next level!

Return of the Map of the Internet

Four years ago, we built a 3D map of the internet for Peer 1 Hosting. That was a really fun project – it’s not every day your app is featured on CNN. With over 100,000 downloads and an average rating of almost 5 stars, the Map of the Internet was one of the most-loved apps we’ve built. The visualization was used in various other mediums, including an exhibit at London’s Science Museum. It was really cool.

Soon after the app’s launch, our client Peer 1 was acquired by Montréal-based telecom Cogeco. It seems the key to getting your company acquired is launching a cool app with Steamclock! In the resulting shuffle though, the app got out of date, and eventually it disappeared from the App Store.

When the app went “out of print”, so to speak, we got a surge of fan mail about it. Folks wrote in from around world, asking for information on the data, permission to use the visuals in other work, and whether the app would return. We also got some requests to open source the code, so people could help update the data and continue to support new OSs and devices, which was great to see.

Well, we’re glad to announce that we’ve teamed up with Cogeco Peer 1, who have been great to work with, and brought the apps back to life!

This fall we brought Map of the Internet up to date to support iOS 11, iPhone X, and current versions of Android. The updates are now live on the App Store and Google Play. The new apps feature new data through 2017, and some UI updates and refinements over the original versions too.

Even more exciting is that the folks at Cogeco Peer 1 have agreed to open source the apps! Now, community members can check out the internetmap github repo, propose improvements, and submit pull requests. If you’re down with Objective-C++, we have the project for you! 😘

Thanks so much to the folks at Cogeco Peer 1 for making this project possible, and for all the fans of the app who wrote or tweeted that motivated us to get this done.

Bluejay: Reliable Bluetooth in Swift

Building apps that reliably talk to Bluetooth hardware can be tricky. Apple’s Core Bluetooth APIs are pretty low level, and they offer enough flexibility to really make a mess if you’re not experienced with Bluetooth. We’ve built a lot of Bluetooth apps in recent years, ranging from medical apps to solar lighting apps, and learned a lot about what does and doesn’t work well with Core Bluetooth.

Using those lessons, we built a framework for building reliable Bluetooth apps. We call it Bluejay, and its first public release is now available! 🎉

Bluejay is a simple Swift framework for building Bluetooth LE apps that are reliable. It makes properly queuing Bluetooth communications easier, helps coordinate background operations, and takes advantage of Swift idioms with a callback-based API.

We’re staying modest by numbering this week’s official public release 0.1, but Bluejay is already working in three apps we’ve built for our clients, so with luck it will be a good fit for your apps too. We’re going to keep iterating and are open to the community’s input as we move towards a 1.0 release.

We’re eager for feedback, though of course Bluejay is MIT-licensed, so code contributions are encouraged but optional. If you do build Bluetooth apps, or are even just curious, we’d love for you to take a look and let us know what you think!

Hello Kotlin!

Last week at Google I/O, the Android team announced that Kotlin is now an officially supported language for Android development. This is good. Very good.

When Apple launched Swift in 2014, it raised a big question: when will this young language be ready for prime time? In contrast, Google’s announcement of support for Kotlin actually reduces uncertainty: Kotlin has proved itself a capable and relaible language for Android development in recent years. The question about Kotlin has long been: is this going to be the language Google puts its official weight behind? Thankfully, we now know that the answer is yes! You can take it to the bank – which we intend to do.

Yes that’s right, we’re throwing the doors open: Kotlin is now our first-choice development language for new Android projects. We’ve been building various smaller projects in Kotlin over the last year, and while it’s a great improvement over Java, it’s been hard to guarantee that this scrappy new language isn’t a flash in the pan. Thankfully that era is over, and Google’s commitment to the language gives us the confidence we need to go all in.

Kotlin and Swift, sitting in a tree

Not surprisingly for a new language, Kotlin has a ton of advantages over Java due to its modern language features, along with a cleaner, clearer syntax that’s still familiar to folks who know the Android system APIs.

What’s less obvious but exciting here at Steamclock is that Kotlin is a lot like Swift. While there are surely differences – for example Swift’s performant value-typed structs aren’t generally available in JVM-based languages like Kotlin – there is a ton of overlap with Swift’s language features and basic syntax choices. A developer who is comfortable with Kotlin or Swift should be able to get comfortable in the other quite quickly.

Looking at just one example, Kotlin has a feature that Swift has taught us to very much appreciate: nullability. In both languages, the type system will not by default let a variable be assigned a null value. If you want a variable to be nullable, you need to mark it as such, and then the complier will ensure that you handle what happens if that variable turns out to be null at runtime.

While nullability seems at first to be a complication, a burden of sorts, it is a mental shift that once made, produces substantially more reliable code. It’s incredible how many failures that occur in production code – both server-side and app-side – that boil down to an unexpected null value. Being able to categorically remove these bugs gives us a big leg up in reliability, and fewer fires to fight down the road.

Of course, nullability is just one of the modern features that Kotlin and Swift bring to the table. So, here’s to cleaner, clearer, safer code – on iOS and now on Android.

Reports from the Mountain

For years, the Association of Canadian Mountain Guides has run a service called the Mountain Conditions Report. The MCR started as a mailing list so professional guides can warn the world about hazardous mountain conditions before things get ugly. Some avalance risk here, a bear sighting there – all in a day’s work as a mountain guide.

A couple years ago now, the famed outerwear company Arc’teryx got in touch with us about the MCR. As part of their work with guides, they wanted to bring Mountain Conditions Report to the web and mobile. As with most of our clients, they were looking to build the web platform, and have Steamclock build out a great mobile app. In the longer term, they wanted to roll out this potentially life-saving tool to mountain guides and the public worldwide. Marc Piché, the Technical Director of the ACMG, explains the motivation like so:

The Canadian guiding culture is very much about sharing. We want to learn from each other’s experiences. Sharing helps everyone make informed decisions and prevent incidents.

At its core, MCR is about creating and viewing field reports. There are plenty of other details, including a directory of guides who have posted recently, alerts for nearby reports, and so on, but the core experience is about finding and posting reports.

Since we launched the MCR app, we’ve been iterating it, making improvements, adding features requested by guides, and adding support for more guiding associations arond the world. It doesn’t get much better than building an app that could help save lives with a company we all admire – living in a city as rainy as Vancouver, rain gear is a core competency.

If you’d like to learn more about MCR, there are articles on the background for and details of MCR on the Arc’teryx blog. The app is also free to download on the App Store. Let us know what you think!