About Objects Blog

Thoughts on software development, consulting, and training

Hamburgers Belong on the Grill, Not on Your iPhone

| Comments

How many projects have you worked on where the client wants to throw in every feature and action they can think of? It often seems they want their app to have everything, plus the kitchen sink. And once they've specified some huge set of features, how do they want them organized? All too often, it's via the infamous hamburger menu.

This is, unfortunately, a common pitfall for iPhone apps. First, an iPhone app isn't a responsive website. Responsive web designers love to use hamburger menus. However, web designers have different constraints on how they must organize their content, and the nature of the content is generally different than that of a mobile app.

An iPhone app is a tool. Every action and task should be so easy that users don't have to think about how to perform them. That way users can just focus on the tasks they're currently trying to carry out.

Second, iPhones are not Android phones. Some folks prefer Android, others love iOS. While both are successful platforms, I personally lean towards the Apple side. I find the iOS platform very efficient and effortless to use. Android may have a lot of bells and whistles, and give you the freedom to do things that iOS doesn't, but more isn't always better. Usability goes a long way, and often trumps other considerations. Too much is a manifestation of complexity. Apple does a tremendous job of reducing the too much to help keep the focus on the essence.

On the left, is a standard cable TV remote. On the right is AppleTV remote.
On the left, a standard cable TV remote. On the right, an AppleTV remote.

For example, your standard cable TV remote has a zillion capabilities, yet, how many buttons do you actually find yourself using? Now, look at an AppleTV remote. It delivers all its available features via six visible buttons and a trackpad. Compare that to a typical cable TV remote, sporting nearly ten times as many controls. Long story short, throwing in lots of functionality and grouping all of it in one place is not a good solution.

I’ll Take My RESTful Services Well-Done

| Comments

Last decade was SOA services. This decade is REST services. These days it seems just about everyone is doing REST — but are they doing it well? From all the evidence, it seems most enterprise IT organizations are struggling with the transition from SOA to REST. And it turns out that the mobile platform is usually at the epicenter of that struggle.

Mobile App Development Readiness Review

We often perform assessments for enterprise IT organizations to help them identify areas of risk related to their mobile development practices. As part of what we call a Mobile App Development Readiness Review, we conduct a four week assessment covering everything from business and mobile strategies, through architecture and design, execution, testing, delivery, and implementation.

Whenever I conduct one of these reviews, one of the first things I look for is the health of the service layer. After all, most mobile apps can't do much without a good backend service layer.

Taking an Inventory of the API

The question I usually start with is, "Can you provide me an inventory of your service APIs?" You might be surprised that most companies can't do this. They can produce a bunch of APIs that are spread all over the place, documented poorly or not at all, and that typically have numerous orphans or single use services. The spaghetti has moved from the code to the service layer, and as a result, opportunities for reusing shared services are often missed — in many cases, internal consumers are not even aware of the existence of the API. The best way to avoid these kinds of problems is to build a discipline around the holistic management of the entire collection of enterprise services.

Most large enterprises currently have a mix of legacy SOA services and newer, RESTful services. I generally view the ratio of this mix is an indicator of how much progress an organization has made in modernizing their service layer.

NFL Sunday Ticket Kicks Off With Chromecast

| Comments

Congratulations to the About Objects team at DIRECTV for their well-received implementation of the NFL Sunday Ticket Chromecast app. The app is currently featured by Google, and was highlighted in Google’s September 2015 new Chromecast release as a premier example of a powerful, second screen Chromecast experience.

Integrating Chromecast

Given my strong affiliation with Apple's platforms, people are sometimes surprised to learn that I've been responsible for leading our Google Chromecast strategic partnership the past few years. Did I go over to the dark side? Maybe. Have I ridden a rainbow colored bicycle? Possibly.

Actually though, we've been working with a number of companies in the digital media space, helping them capitalize on the cord-cutting trend. At its core, Chromecast allows users to stream content on everything from mobile devices to large-screen TVs. It’s sort of somewhere in between Apple’s AirPlay and a full-blown Apple TV app (we develop those too!). The big difference is that with Chromecast your app controls the whole experience and becomes your remote control, allowing for a much more immersive, second screen experience.

Key Challenges

Chromecast implementations can present a number of potential land mines. Problems often crop up in dealing with DRM, adaptive bit rates, CORS headers, environment setup, error handling, networking issues, UI synchronization, and automatic reconnect, as well as determining when and when not to use custom channels.

What’s most interesting to our developers is the challenge of architecting an elegant Chromecast solution in the context of an existing mobile app. Integrating Chromecast (especially with iOS apps) tends to be an afterthought, and none of the apps we've dealt with were designed with that sort of integration in mind. It tends to be such an outlier that it can stress the application architecture in dramatic ways, often uncovering significant weaknesses.

Managing Technical Debt

| Comments

Among the services we offer is an assessment that can span everything from mobile and cloud strategy, to enterprise architecture, process and methodology, design, testing strategy, software tools, and even an in-depth analysis of existing codebases. After conducting a number of these assessments, I noticed a trend. Many of the IT directors who had until recently been hailed as heroes for delivering low-cost mobile apps seem increasingly alarmed about their future. Why? Their projects incurred significant technical debt as a consequence of cost-cutting measures. (See also: wiki article on technical debt by Martin Fowler

In short, technical debt is the accrued balance of the shortcuts taken and compromises made to get a project out the door on time and on (or under) budget.

While initially, an app whose development team cut one too many corners may seem to work just fine, as the app evolves the code base can quickly degrade into an impenetrable mass of spaghetti. Unfortunately, development teams rarely consider (much less track) the amount of technical debt added from one revision to the next.

Signs and Symptoms

One of the symptoms we typically see when a project is over-leveraged (i.e., has accrued too much debt), is a growing rift between Product (the business) and IT. The mobile development team may be perceived as losing velocity over time, struggling to meet deadlines, delivering increasingly buggy code, and being seemingly incapable of implementing a growing subset of new feature types.

The latter issue tends to be particularly frustrating to Product. It would naturally be hard to reconcile development's claims that certain features are 'impossible' to implement with the presence of the selfsame bright, shiny, organic, grass-fed, free-range features in the latest versions of competitors's apps.

When developers claim that new features are impossible to implement as specified, and plead for requirements changes and simplifications, often what they're really saying is, “Uh, we can’t get there from here — the current state of our application's design and architecture (or lack thereof) and codebase simply won’t support it."

Fingers get pointed. Things get said. Chairs get thrown.