Archives for April 2013

Fashion has long been a part of user experience. You can take a look at the UI of a product and can probably place it in time. It helps that the UI is tied to a system UI that is a heavy cue (e.g. You will recognize a Windows 3.1 UI vs. Windows 95 vs. MacOS 9 vs…..).

Just as you can place software UI fashion, you can obviously do the same for clothing. If you think “80’s” I bet you will picture some clear apparel and looks.

There was a lot of interest in Apple’s organizational move to place software UI under Jony Ive. Most were excited to see the unity of hardware experience, especially since he is held in such regard.

Few worried about what changes he would bring. Would they be too bold? (“Don’t change a great thing that my Mum knows how to use!!!”) Does he “get” software? I am in the excited camp, mainly because I am ready for a change. I admit it, I am a lil bored with iOS. Having gone through the revolution that was holding the hitchhikers guide to the galaxy in my pocket, recent improvements feel very evolutionary. I am asking myself the “will this make my happier?” question a lot more recently, which becomes very meta very quickly, but that is another topic.

The fashion of software has always been driven by constraints. The “what tools do I have available?” of a platform changes very quickly. The path of text based UI to a desktop GUI to mobile and touch. I guess the same is partially true for clothing too. As we have new materials to work with and innovations in manufacturing, we can have new forms of design.

Some fashion seems to last the test of time. A nice pair of denim jeans are timeless. A simple black suit. It seems like the cleaner and simpler the cut and design, the longer it can last. If the design highlights the underlying content, it wins.

We have been seeing a push to “let the content do the talking” where the UI takes more of a backseat. The small mobile form factor makes that necessary, but it had also moved to the desktop (Chrome) and hardware (new tvs with minimal bevel).

The Windows “metro” interface is a great recent example of pushing simplicity into the platform. There has been talk about how some of the constraints on the engineering side (dealing with compositing) helped push a simple flat look, and it has some side effects.

When I use Windows Phone applications two things jump out at me:

The apps tend to “look good out of the box”

– compare this to the Web, where most experiences looked bad by default (because there weren’t many defaults)

– Twitter bootstrap has become a de facto starting point (which some designers dislike!)

The apps tend to look the same, and are more Windows branded vs. tying to the given brand. For example, when I launch the LinkedIn app on Windows Phone it feels like it is written by Microsoft (it may be 😉 and it is just injecting content from LinkedIn.

I guess the balance is always interesting. Can you find constraints that make an experience great by default, but also leave enough room for the spirit to shine and mate with the platform.

With iOS we saw the migration from stock iOS looking apps to the point where people both had the ability, and were also experienced enough to stay within the platform but also push the boundaries. The innovation has gone from Apple apps more into great third party ones.

So, I am very excited to see what iOS 7 comes up with. iOS.current is a nice pair of worn jeans, but they are starting to feel a lil 80’s. I wonder if Jony can get us a black suit for a change of pace?

I have had a lot of conversations about A/B testing that remind me of those that I had back in the days when Test Driven Development came on the scene.

It ain’t about tests

Much of the talk at the time was about testing and tests, focused on
fixing bugs and finding regressions. This is incredibly important,
especially as it was also growing in popularity at the same time that
dynamic languages were coming back en force (trust the tests not the
compiler!) as well as rich refactoring tools. The tests were a safety
net to allow you to say “yes” to evolving the code base versus a de
facto “no.”

I quickly found that the quality of my code was better with the right design because I was now thinking about the interface first, and the initial point of view was that of a client to the code base. End result: a much better design.

I also found that my tests were amazing documentation for the API. Screw pure text docs. Commenting the code is great but again favors the implementation. This way the core implementation docs were for the implementors and the tests had docs for the consumers.

Building product

Bringing it back to A/B testing, I have seen many talking about the effects that measuring your product has, and the effects of the backend of the process (running reports etc), but one of the most exciting side effects has been on the front loading of product development.

Recently someone told me that they didn’t have time to do A/B and “isn’t it a waste to build more than once?”

I have found that not only isn’t it a waste, but it is faster to build product with an A/B approach and the results are better.

I think that I am old enough to know that I am not always good at predicting the future, and when you are building a product you are predicting how your users will use your work. I believe in “instinct”and having knowledge of what to build, but I want to mix that with a healthy amount of data and trials.

I also believe that good ideas can come from anywhere, and any one on the team. If you have a “product manager” they aren’t the only holders of great ideas that the product should do.

I have been involved on projects that changed from one of these environments to the other:

Top Down

– team discusses what should be in the next release
– team disagrees on some points
– best debater may win, else
– the person who can raise it up the chain plays The Boss Card: “Well,
the Boss wants us to implement X so no more point in arguing.”

This can easily result in the team not feeling ownership and they end up more disgruntled.

Not only may the boss be wrong, but they may have different context….
And then there is even pure misunderstanding and Chinese whispers.

Team Ownership

– team builds out their hypothesis on what would result in hitting the
business outcomes
– instead of lengthy argument, build different versions and measure

Now the data wins versus personality, you learned something about you
product and users, and you iterate from there.

It is often quicker to build out a prototype or live feature vs. arguing about whether it will rain tomorrow. Acknowledge that users will surprise us, and then embrace A/B at the heart of your product development efforts and run like the wind.

I can’t wait to see the barrage of feedback from the Web community around the news that Chrome/Chromium will be powered by a true fork of WebKit (not just a slightly different fork 😉 called Blink.

It is interesting to remember that WebKit != a “browser”, as Paul Irish foreshadowed (interesting that he did that before the announcement ;).

I predict some people making fun claims such as:

OMG We were loving that there was just WebKit with no bugs!

Much has been said about the fact that there is not “one WebKit”.

Joe Hewitt commented on the fact that Chrome is “behind” on some features such as CSS hyphens…. I wonder how much of that will come into play with Blink. It again shows that there wasn’t “one WebKit” (HINT: CSS hyphens != just a WebKit issue).

If you admit that there isn’t one WebKit anymore, then you can come to a conclusion that if Google does a great job here, Blink could move the Web forward faster, which could be good for us all, even if we feel like we have to “test a lil more”.

OMG Google is going for POWER!

People love a power play (love to hate mostly). If you think that WebKit was perfect, remember that it isn’t. With Opera switching to WebKit we saw some more truth come out. For example the jQuery folks talking about the myriad of bugs and work arounds, and how there are more for WebKit than for IE!

Give me my WebView! Where I hope this leads

If I may put on an optimistic hat for a second, I can get excited about this news along with having Android report into Sundar Pichai.

If:

a) Blink starts to move faster than WebKit and/or helps spur on WebKit and other rendering engines (e.g. Firefox OS / Gecko)

b) Blink becomes a key part of a new WebView component on Android (and iOS! :/)

Amazing things can happen.

I want the WebView component to be self updatable, and then I can build a hybrid app that targets a version of said WebView. At that point we can update the renderer/other WebView pieces separately from the OS itself and the Web can pick up the pace.

PLEASE DO THIS GOOGLE. PLEASE PROVE ME RIGHT. How about at Google I/O?