techno.blog("Dion")

I turned on another keyboard for the first time on iOS. This wasn’t Spanish or another locale, but rather Emoji :) Being able to flip between the standard input and the emoticons reminded me of the opportunity that iOS is missing with respect to inputs.

When I use my Android device I find that I really like the Intent system and the fact that I can install and try different input technology. Swype, Swiftkey, and more. Along with the fact that the keyboard area is larger (due to a larger form factor) it all means that I type so much better.

I have gotten to the point where I don’t reach for my laptop in the same way that I used too. In former times (I love how Germans say that) I would grab my Air as soon as I needed to type more than 3 words as it would drive me nuts to try to do so on a phone keyboard (or even iPad half the time). Something has happened where I no longer do that. I will bang out longer content on my device and have gotten used to doing so.

It is one thing to be able to replace the system keyboard, but if I could even add new inputs to the system so I could hit the globe like icon and live in my other keyboards or input devices or any type that would be great (e.g. a graffiti window! ;)

Fleksy (pictured above) is a great new keyboard that came out of trying to be more forgiving for visually impaired folk, but also works well for me (some things bug me about it for sure…. mainly entering punctuation and going beyond the swipe right for space). Let me dock it and use it!

And then we get past keyboard inputs and allowing innovation on voice rec, photo input, and more!

Coding has a voice too, don’t you think? — @tobie

Man, I was thinking about something just like that as I was reading Steve Yegge’s latest essay on the parallels of the political spectrum to the developer platform spectrum. I am always very happy to see a new post from Mr. Yegge.

When people ask me about Java and why I don’t often write applications in it, my answer is not that I think “Java sucks”. I think the JVM is amazing technology, and there are a ton of fantastic APIs. Using Java is a great answer for many situations. However, the least amount of fun that I have had programming has been when using the Java language. It isn’t just that it feels frustratingly verbose, although that is part of it. I feel like I am saying too much:

I am using the Greeting “Welcome” to the Person Ben!

I always found like I was stuck speaking in someone else’s tone. A boring tone. I would try to change things up by using more fluent APIs (e.g. withScreen().shop().navigateToCategory("Auto & Tires/Tools & Equipment").tapListItem(3), but then I would feel like I just didn’t fit in. It also didn’t feel fair to the rest of the team that would be speaking in another monotone. Reading code is so much more important than writing it… and all that jazz.

Speaking of jazz, maybe some people enjoy singing in a large choir and getting the harmony just right. I think I prefer to be in a jazz band where I have more room to explore (and mess up?). Improvising leads me to different API choices and different solutions. Some people hate APIs such as 7.days.ago, but I tend to enjoy them.

There is huge value in a community having a coherent voice, but I am still trying to find the right balance. I am still looking for my voice. I don’t want to go too far and get obsessed with the process and forget the content though. The purpose of my code is to deliver an experience, and that output has the most value, but that doesn’t mean I don’t have to care about my craft and learning.

If I think about the (somewhat) massive wasted effort that I have seen over the years on switching frameworks and arguing over Struts vs. WebWork, jUnit vs. TestNG, Spring vs. Guice, jQuery vs. Prototype, or [insert your favorite argument]. I don’t think that if I went back to any choices and switched the “winner” I would have had drastically different results in the experience I ended up building. I think that is why I am focusing more on being a Product Engineer, but one who has fun building it in his own voice?

The status bar should be treated with respect. It drives me nuts when it is abused, and it can give delight when it is used well. One of the lil hacks I really liked came from Joel Bernstein when in developer mode only, you get to see if you are talking to dev, qa, or production servers! Delightful Joel.

But then I saw this…

… the Olympics app takes over my status bar to show a sponsor? I am not allowed to know my battery life, the time, network situation, and if the app is going back to get data and instead I get…. an ad? You have to be kidding me guys.

Feel free to use it in a temporal way to give me updates such as Twitter does these days:

But please, don’t take away my info without giving me something back.

(The apps are pretty bad in general. They are buggy and flaky, have been “updated” daily, the video goes in and out a lot, and the content isn’t that good. Meh.)

Google Plus. In a world of Facebook, Twitter, Path…. Google Plus is yet another option that sits in between Twitter and Facebook for me. It has great technology (would love to have more than 140 characters on Twitter and decent comments etc) and features (e.g. hangouts).

But, for now I don’t use it much. Having it integrate into Google properties is fantastic if you are a Google+ user, but as someone who isn’t it drives me nuts.

It would be one thing if space was taken up in subtle ways, but what has really started to drive me nuts is the “look I’m here!!!!” approach in the UI.

When in a property such as search or maps, there is a red notifications square that shows up. Not only does it appear there, but it animates its way into your life. It is subtly distracting in a way that makes you look over there… which is what you would A/B test for if the info was important, but I came here to see the map!

The Web doesn’t tend to have much animation and transition going on in UI (although this is changing) compared to iOS, Android, and Flash. You can use it as a powerful force to alert the user to something you really want them to see.

I saw an even more annoying usage. The Telegraph newspaper has the images in its ads seemingly randomly shift around. I can only assume this is to again draw your eye over there and it is incredibly annoying.

Stop it!

Use your powers for good.

WWDC and Google I/O have come and gone. At first I was disappointed with both, but then I sat back to think about what an amazing time we are in with mobile and computing. I don’t know about you, but I feel like the battle of the full touch screen is done, and now we move on. Android has caught up enough on the quality of display (although not “retina” displays such as housed by HTC One X are fantastic), and especially with Jellybean, the UI isn’t as jaggy and laggy as in the past. The hard work of battery drain and performance still continues, but it is also easily close enough. The Nexus 7 shows that Android tablets can compete too. Finally people can talk pro’s and con’s versus “er, why the hell would you buy that?”

All in all it feels like we are heading to another game of Brazil vs. Germany, both at the top of their game. Brazil has the amazing feel, taste, and style, and are also continuing to up their game with pace and strength. Germany has their organization and resource to bare, but also have growing cunning and quality. You look forward to watching the next game.

The next battles live in new inputs, integrations, smart services and ecosystems.

Inputs

Touch has been somewhat nailed. We do have haptic feedback to look forward to in the future, and this has the chance of changing the game again. How will our typing productivity go up with haptics? How will it change gaming, or music instrumentation, or art?

Voice is the obvious big push. We are still pretty early here, but where Siri was good, Google has gone beyond. The speed of recognition has been outstanding, and once you get to a certain point where you can trust it, I think this will go far past the gimmick to full usage. I also feel like there is room for hybrid usage. When typing something you can tell your system to go into caps mode, or switch to the spanish keyboard, or what have you. Once voice is of a certain quality it all changes.

Then there are other new inputs. Having the camera giving us a Kinect experience on mobile. Who knows what else will come along that will enable us to get our ideas, requirements, and instructions to the computing device as quickly and efficiently as possible.

Oh, and of course there is Glass :)

Integrations

With hardware Apple has the advantage of full integration (their own chips) and buying power. This means that they typically have the nicest hardware with the best overall package, AND they can do it for cheaper (this is very different to the Wintel generation where Mac couldn’t compete on price!).

Google has the advantage of Open, and giving consumers more choice (”I want a bigger screen”).

Smart Services

Google must be salivating on this one. Now that we have the basic integrations and inputs on great devices…. services can come in to solve user problems. We see this clearly with Google Now. The server can put together your location, your history/data, and your context to “do the right thing.” This is in the realm of magical, and although folks will freak out about privacy and “big brother knows too much!” the good side is that it can deliver humane results.

Google has the chops on the server, it is their DNA, so I expect them to push hard here. The more data you have to work with the better you can service the client, so as the data and the algorithms get better we will see more and more magic.

Ecosystem

Android has a lot of applications. There is more of a push on all digital content. However, we are dealing with many wall gardens, which is frustrating for customers.

If a user has their content in iOS apps, and tons of music and movies in the iTunes locker, it can be hard to make a switch to an Android device. You can have the same feeling as if you have an amazing VHS collection and then a new betamax player comes out with some nice features that you would love to try.

Man, what a battle. We are finally at a place where the fight is competitive and I hope that each side keeps pushing and we continue to see a fantastic tug of war.

Really impressed by seamless Nexus Q setup and integration with Jelly Bean. Not happy. Life was simpler when iOS was clearly better. ;-)

— bgalbs (@bgalbs) June 29, 2012

You can argue about iOS vs. Android. Ben would still come down on the iOS side, but you can see that he is at least thinking about it now. It is a debate. There used to be few to no features that iOS users wanted. Now there are plenty (from new: offline voice controls, to older: decent home screen w/ widgets and Intents).

It is fascinating to watch the old Steve Jobs All Things D interviews. At D2 in 2004 Steve talks about how, even though Apple is pretty good at the hardware thing, the differention is in the software. Folks can catch up on the hardware. Now, Apple has done an amazing job on the hardware, and their scale + deals + how they have taken so much of the work in house (e.g. their chips) has kept them mainly in the lead.

When I look at Jelly Bean I see some nice new features and a lot of important catch up (e.g. buttery scrolling and UI performance in general!) It also feels like most of the leaps in UX on the phone itself is to do with server side smarts. The Google Now work, and putting together info on “hey, head to the airport now! the traffic sucks”. This is great news for Google as they know the cloud and computing smarts. Apple has iCloud and is growing there too, but Google should enjoy fighting more of the battle in the cloud.

Even seeing new interesting features, I feel like I have deja vu from some old times. When I see the cool Nexus Q, it feels like I am looking at a great VHS recorder with interesting features…. but my collection is in betamax tapes. The digital lockers of Apple, Google, and Amazon are locking us in (even with some ability to get content out… like doing a tape to tape). It also feels like the days of having an Atari ST when friends had Amiga’s; ZX Spectrum vs. Commodore. It is frustrating to have to make a choice.

Competition may be good in that it will spur the horse along faster, but it sure can feel frustrating. That magical time when the content you wanted was all in the Web isn’t there in quite the same way (even with lockin on websites).

Until we get more hardware improvements (e.g. Glass) the battle field will be through client software and software in the cloud. An exciting battle for sure.

It is easy to make fun of the Android WebView. Ben and I had a slide on that in our talk yesterday. Painful, but easy. It’s almost as though the Android wing of Google doesn’t want the Web to be a great platform :/

We have a big fight for maps and location going on too, and next week will give us more information. iOS 6 is expected to showcase some amazing home grown (via 3 acquisitions) maps, and Google is trying to jump in and show that they have some life too ;).

The cynic in you may understand that the Android platform would be wise to make Google Maps amazing and easy to work with (their mapping, driving, and local functionality is fantastic!) but maybe have it be harder to work with other foundations.

If I owned a platform and NOT a mapping property, I would create interfaces so the developer would loosely talk to the system, and they would have a way to get a handle to the lower level to do fancy things that a particular provider had. An API / SPI model.

What do we have with Android today?

“To create a Google Map, you must extend MapActivity and implement a MapView in the layout.”

Wait, a MapActivity? Not just a view/component that you can pop in?

“Only one MapActivity is supported per process. Multiple MapActivities running simultaneously are likely to interfere in unexpected and undesired ways.”

If you wanted to use another mapping platform you can of course. OSMDroid is one example. They even have a wrapper so you could plug and play on the MapView layer, but note that you still live within the MapActivity bounds.

This becomes an issue if you want to ship on a device that may be Android but isn’t certified with Google goodness. A platform such as the Kindle Fire for example, where you don’t have access to the Google APIs. Now you have the pain of having separate builds.

I compare this to our mWeb codebase where we can flip a bit and suddenly the maps change between Google or Bing.

With WWDC and Google I/O coming up soon and soon-ish, I can’t wait to see these things go away :)

What headline would you most like to see? I wouldn’t mind some of:

• “Android SDK updated with ChromeWebView that enables amazing WebView support!”
• “iOS 6 delivers fantastic Siri and Gesture SDK”

But hell, I wouldn’t mind the small things…. “In mobile safari if you use native scrolling you can still tap the top menu bar and scroll to the top”, “iOS 6 auto-updates apps and doesn’t download unused assets. Finally.” etc.

Tools enables new ways to build. Distributed version control and the tools that are enabled on that platform (as highlighted by Github) have hit mainstream. Some graybeards will scoff and talk about how they did this and more decades ago…. And they typed up hill both ways! Now, it is available for all.

I have seen the shift in the way that projects can now be run, and how software product can be shared. Take an example, such as where I work now. Ben and I run mobile engineering for Global eCommerce at Walmart. This means that our products scale in different dimensions. One axis is the number of platforms for a given locale: iPhone. iPad, Android, mWeb, etc. Then within that locale a platform can have multiple products: grocery app, general merchandise app, etc. Yet another axis is the various locales. The apps and platforms for the different countries may not fully align. As you can imagine, we think about the topic of “leverage” across these axis a lot. There are extremes.

One True App

This is the mega platform. It is generic in a way that lets you customize it for varies experiences, but it has to know it all. I have rarely ever see this approach as it means that you need to think up and agree to the constraints of he system for all parties up front. Can you take a look. At the businesses from China to the US and say they can happily live with the same guard rails? If so, great, you have gotten a winner. Even so, you quickly find yourself in a resource allocation quandary. The owner of the core platform is the parent, and each locale is now a child shouting for resource. The largest baby bird often wins, even if the runt is actually growing, or had the potential, to grow fastest. The sibling rivalry can become a pain too. The parent may want to push back to the children, and can try to do so by developing the core APIs and letting the kids have at it on their own. Awesome, loose coupling. The other massive benefit is that the kids can go outside of the family. We see this a lot due to the fact that the parents use popular and/or standard libraries with well trodden API. This is where API shine the strongest anyway. Great a small piece of functionality that can be shared and extended. If you are building a mobile Web application client, why wouldn’t you build off of a Backbone, socket.io, zepto, underscore, handlebars stack (or your own favorite equivalent version)?

The Third Option

There is a middle ground between “here is my code” and “here are some APIs”. The greatness of the pull request enables this in spades. Give the kids some safe rope to help them climb. If the platform is evolving fast and one kid wants to go off in a direction they can fork away and use the tools available to diff and merge. When over for Sunday dinner and you are all chatting about what you did that week, you can see if it makes sense to pull something into the mainline.

The parent product now has evolved into others that are able to steal good ideas from each other all the time. When taken to an extreme you see Linux. Linus has his Truth, but his lieutenants have their own, and there are folks who have their own under that.

This is all non-trivial to manage from a process standpoint. It also takes time to keep up to date and sync early and often so you aren’t looking at a mutant form that can’t breed with the core no ‘more. There are many new tools that could enable us to visualize and work with the forks, but it seems like we have hit a new norm, and the nuance of this approach can be just what the doctor ordered for certain platforms and products. It enables truly fluid structures. You can get up to speed with something new quickly, without having to fully by in.

As a company, do you focus on the customer? Many companies do so only when the focus is to lock in the customer. How many services have you used that when it came to leaving said service you ended up running around like a blue arsed fly on their Web site. This is the norm. Many will say “duh, we don’t want to put effort into that side of the business where we are losing a customer!”

Every now and then I see companies that care about the entire experience, and I just saw another example in Sprint.ly.

I love their service, but recently have been (due to reasons not to do with the quality of the product or what I would personally like to us) using other products to develop software. I stayed signed up as I want to come back to the service, and the following email just came in:

Your credit card was NOT charged!

Inactive account disabled

It looks like you haven’t used your Sprint.ly account in the last 30 days or so. We don’t like getting billed for things that we don’t use and we don’t think that you should either so we’ve disabled your account.

Fear not! Your data has NOT been deleted and you can always log into your account to reactivate your account and access all of your data.

We hope to see you again sometime soon. If you’d like to reactivate your account now you can do so by logging into your account and updating your billing information.

If you no longer plan to use sprint.ly, there’s nothing left to do on your part. Your account has been disabled and we will not continue to attempt to bill your credit card.

Sincerely,

The Sprint.ly Team
http://sprint.ly

Now this is classy. Not only did they pro-actively stop taking money from me, think about the fact that they had to code this into the system. This story made its way up through their large backlog to a point where they did this.

The net effect is that my trust and emotional connection to Sprint.ly has risen. I look forward to re-activating my account soon.

Joe Stump and friends, you are a classy act.

I have been thinking about the shape of teams. I have built software products in teams as small as 1, and as large as “I don’t actually know everyone who is involved in this project”. You are probably not shocked that I prefer closer to 1 than infinity (ignoring the fact that we all build on the shoulder of computing giants!)

What is the ideal size for a team? It obviously depends on the problem, but I have changed my view over time. For awhile I would see the skills that I lack, and think of the roles that need to fill in the gaps.

• You need a developer to write code (and then there is front end vs. backend)
• You need a visual designer to create assets
• You need a UX person to get the right experience
• You need a product manager to define what we are building and garden the backlog
• You need a QA person to test the application
• You need a project manager to keep everything moving and unblock blockers
• … and you can keep going …

For some projects this can make sense, but for many…. maybe it is overkill?

The other extreme is the team of 1. There are some real advantages to a team of 1:

• Easy to build consensus :)
• The entire team thinks the same way.

You often here the “Linus was able to do the core of Linux by himself” (even though it grew into a case study for distributed collaboration). Solving a narrow problem can be ideal for 1, especially when they can collaborate in a loose way with others. We have been doing this in academia for a long time.

In the modern time I look to folks like Joe Hewitt as people who can go off and do something brilliant in a short time with their style. If you look back at the early Firebug your hair may curl when you see his with()y style. Pairing him up with the wrong person would not be productive. He also happens to be solid at all of the other skills (not just a great developer). He is a perfect “Product Engineer”.

Two heads are better than one

I am often a fan of pairing up on problems. There is a reason that I love working with Ben for example. The advantages here are:

• You have a built-in sounding board / reviewer
• If you complement each others skills, the match can be golden.

One of the pairings that I really enjoy is that of a product focused designer and a product focused engineer. I have seen more and more companies with job openings that they call “Product Designer”, but I have only just started to see the “Product Engineer” term. I have changed the view of myself and my roles over the years (developer, engineering manager, advocate, technologist) and I often have conversations with myself (bicameral mind and all) about what I want to be when I grow up. I find this hard because I like each of those roles. When I am in the mood to be a “maker” I find myself much more interested in the software product than the pure technology that gets me there.

Thus, I enjoy being a “Product Engineer”. Someone who doesn’t sit in the corner hacking up some code, but someone who loves building products with software, and programming is the tool at hand.

One of the reasons I am so impressed with the GitHub team is that they tend to hire product engineers. It helps greatly that the product they are engineering is something for a developer, so they don’t have to dig deep to see how their user base would want something to work.

Every team is different. If the engineer on your team is an amazing hacker but just wants to be told what to build? get a strong UX/PM to cover that role. There is no “right structure” for all projects with all types of people.

When I think of developer super heroes though? I will be day dreaming of the “Product Engineer”, “Product Designer” duo. And, at the very least, I will make sure that my engineers are as invested in the product as they want to be, and that my teams are as small as possible (but not smaller).