Skeuomorphism is right, in the apps, perhaps not much in the base platform itself

Arguing whether skeuomorphism is good or bad is utterly pointless. The real argument is whether a platform should be the flag bearer or not. I know a lot of prominent bloggers wrote the opposite, I’m not sure if they’re just going with the flow or really giving this topic a serious thought. Anyway, going with the flow isn’t something for me, certainly not in this case.

Any design when tastefully done can delight users. Any design that is tastelessly done would only highlight every other shortcoming there may be in the object being presented to users.

Great technology should get out of user’s way and just allow unfettered creative expression. A platform is ultimately a place of happenings, where the vendor or moderator wants to attract people and let them express their creativity. Imagine a London Westend theater with a permanent set of stage prompts for every single performance, that would be overbearing for sure. In this sense, if the platform itself is too loud and too expressive, it creates unnecessary noise that may drown the creative message being brought forward by its users.

Flat or not, skeuomorphism or not, the platform should give way to the creative work of its users. In this context, I would welcome a UI refresh of iOS. This is what I appreciate in Flickr, Instagram, Tumblr, Flipboard, all these platforms that don’t push themselves too much in your face. In some respect, the current version of iTunes on iOS and Apple’s web store, illustrate the kind of UI refresh that would be nice to see across the board on iOS7.

I wouldn’t enjoy a context where all the major platforms would look the same and keep copying each other, that would defeat the very idea of creativity. Diversity is a good thing in all contexts, it’s how we thrive and evolve.

Scalability is basic hygiene for Internet Services, trade it off at your own risk

Scaling can mean a lot of things, the way companies address it and make trade-off decisions have a large impact on the user experience. In these days of dwindling attention span, users expect snappy experience regardless of the amount of data or people interacting on any platform. I am tempted to think that Apple may have made many software trade-off decisions by sacrificing service scalability, and that is a bad idea for Internet services.

Here are some examples of what I mean:

  • Safari Reading List feature: it works well when you have just a few of items bookmarked. Since it’s easy to use, my reading list grew quite fast and this is causing Safari to become less responsive whenever I try to view the list from one of my devices.
  • iTunes Match: this is quite handy, all your music on iCloud and you can listen to them on up to 5 iOS device. However, if you have a large music library and that your Internet connection quality fluctuates, you quickly get an non responsive music playing experience. So, it appears that the Music App isn’t able to gracefully degrade iTunes Match service.
  • Using documents from iCloud: this works well with a good Internet connection, but Pages or Numbers tend to get stuck whenever something isn’t smooth in the network connection. Furthermore, iCloud documents created with a Mac are not fully supported by iOS versions, it converts them or duplicate them, it’s a pity that it works that way.
  • I can’t directly share my purchased books and PDFs between iBooks on iPhone and iPad, these need to be manually copied around and sync’ed with iTunes.
  • Apple’s App Store is getting slower and slower all the time. In the early days, it used to be fast. But nowadays, with everybody putting up App Stores, Apple AppStore service or its client applications don’t appear to be coping very well.
  • Server Manager is now a stand alone app that can be installed on Mountain Lion on any Mac and turn it into a server. That’s great, but I discovered a couple of annoying issues with it. First, if you ever touch the embedded RubyGems package then you could be in for a ride. When you dig deep into it, you see that Server Manager ships with its own PostgeSQL and Ruby on Rails distributions, so why not completely sandbox these? The second issue I found is that, as I move my laptop around it gets assigned new IP addresses that cause problems with the embedded DNS Service. Sleep/wake cause Server Manager to start up really slowly and become non-responsive for a while. I know how to work around these but not before hitting a problem.

These are different types of shortcomings that all relate to scaling trade-offs, sometimes the volume of data is causing problems, other times it’s just the way of sharing objects that doesn’t scale out across devices. If a service has an upper-bound scaling threshold, why not either advertise it or adapt the user experience to reflect that? None of the examples above could have escaped Apple’s legendary experience design and iterative refinement crafting. These have to be happening because someone thought them good trade-offs, but I can’t find a good justification for trading these off for anything else. The use cases that are covered in my examples are all too simple, predictable if not obvious for a large scale product usage.

Apple talks a lot about creating the best possible user experience, and it is mostly believable when you use their devices and also judging by their success so far: haven’t they been at the forefront if the current consumerisation? However, several Apple Internet based services just don’t seem to scale up to good user experience. This is surprising to me, because it’s impossible to imagine Apple not knowing the consequences of the trade-offs they made in this area. Yes sure, it’s hard to excel everywhere, but with Apple’s clout and the abundant supply of talent for a company like that, I don’t understand why they’re still not plugging gaps in these Internet services. That was the reasoning behind my tweet around mid-October, where I speculated that an acqui-hire was in order for Apple.

I am basing my examples here on Apple, because I experience many of their products every day. But, in fact, these observations apply to any organisation putting out Internet based services. For Internet services, designing for Scale isn’t luxury, it certainly must not be a second thought, it is fundamental to any ambitious endeavour.

Scalability is difficult to get right. Inexperienced teams would typically cry foul, the catch phrase “premature optimisation” is bandied about by people who are not sure how to go about it. That’s fair, if you don’t know how to address scaling it’s best not to try. But large companies that ship products to hundreds of millions of people cannot trade-off scalability without paying a heavy price for it. Competition is heating up, Microsoft and Google are getting better at responding to Apple’s dominance, and this will force all three to ship products that scale smoothly.

Conservative innovation as a path to better user experience. Avoid Feature Debt.

Designing sustainable user interface (UI) is a very hard task that could take a large number of retries to get right. A technology powered solution that spares its users tedious learning will fare better than those who simply skim over such issues in favour of other agendas. Realising this makes me respect even more people who invented some of our everyday tools such as drinking glass, the pen and paper, and so on. This post is about highlighting some aspects of UI design decisions and why that is where conservatism should be preferred.

I always push hard to find out every detail I could about the problem domain that I am dealing with, preferring to postpone technology concerns until I know enough about everything else. Incidentally, this way of working tend to ruffle the feathers of those who prefer to skim over details, the manager looking for quick way out and avoiding any potential blame. I digress there a bit. In essence, looking to get more than one perspective of a problem domain makes me spend hours exploring wide ranging concepts, business and technical blueprints, various vendor solutions, looking to debunk blind-spots from the endeavour. Ultimately I found out that UI design decisions where happening everywhere even though people weren’t looking at things that way. In this post I’d like to highlight some of the learning points on user interface issues:

  • A stable UI design will sustain several product revisions without requiring that users learn and adopt new behaviours. Designing and rolling out a stable user interface seems to be an extremely difficult task, partially because the UI scope is often hamstrung by blind-spots.
  • Technology vendors that tend to frequently overhaul their UIs will upset users, cause people to scramble to adapt, disrupt well honed user productivity work flows, distract people from doing their real job.
  • In software development texts you often read about “Technical Debt”, meaning that some corners were cut for technical reasons with the intention to make amend at some (often unspecified) time in the future. In a similar vein I also frequently noticed what I would call “Feature Debt”, which has a broader meaning than its technical counterpart and is mostly about adding clutter. I’ve not heard of this term before, so I am creating it to make my point. An example of Feature Debt is when people sneak in requirements that only reflect their own personal preferences far removed from the actual problems at hand. Another example of Feature Debt is when designers don’t envision the user’s daily activities while designing a solution. Feature Debts stemming from a technical way of thinking tend to result in cognitive tax on the UI experience. I will write a dedicated post on Feature Debt when I get a chance. The point here is that Feature Debt is really hard to fight, it goes against conservative UI innovation and coud cost dearly.

Changing the UI of a well established technology should not be taken lightly, because of the unnecessary upset it might cause. A symptom of Feature Debt is when a solution is deployed then outsiders react in bewilderment, wondering how such product release came to be. Another sign of this is when folks have to scramble to learn new habits for things that are otherwise plain and simple normal activities.

With this way of thinking in mind, I try to analyse new technology product releases that hit the market, sometimes you expect to see revolutionary new interfaces and may be disappointed not to find that. Sometimes new products receive negative media or user reactions, you wonder how that could happen when the organisations behind them clearly had all the resources they needed to get things right. It is always too easy to shout at bad decision making with hindsight, especially from an armchair executive perspective, but it is very difficult to spot issues as they are happening. People often seek prescriptions as an easy way out, some of shortcoming of such prescriptions is that  they make our minds lazy and could be giving us an excuse to blame someone else if things don’t work out. To illustrate the effect of the mind laziness, imagine a situation where someone could perform a mental mathematic calculation but they stop trying if a calculator is at hand, over time they lose the ability to perform any mental calculation at all. That is also what happens if we keep looking for prescriptions and stop thinking things through by ourselves.

One thing that could help in IT driven initiatives is to look out for Feature Debt, they typically won’t survive proper user testing, won’t make it through the “five whys”. Feature Debt has a snowball effect, everything that trickles down from it will amplify its negative impact. When a group or organisation is caught in Feature Debt, very smart people might totally overlook obvious faults simply because they would imagine that fellow smart people must have vetted things and nobody wants to look bad or sound like they are obstructing. Such invisible pressure would nurture Feature Debt, people would start rationalising them and after a while feature debts become indistinguishable from real user wants, that’s when the damage potential is maximal.

Conservative Innovation is about looking for those precious UI experiences that must be preserved as one innovate, actively looking for Feature Debt and removing them from the picture before they grow and become ingrained. The conservative part is really about avoiding changes in what is already working well. When considered this way, examples can be found in a lot of successful products out there. This is also what drives copy-cats because they don’t risk trying something new, they try to follow what appears to be working and accepted by communities.

This post isn’t asking to avoid change, that wouldn’t make sense. But rather, this is about ensuring that user comfort is sought and protected very early on and often as you go about innovating.

Buzzing, tweeting, now everybody can get a taste of being stalked

I’ve started buzzing, stumbling upon it’s activation at a browser restart. After a couple of days, I’m reconsidering the whole thing: why am I getting involved in all this?

Having been involved in innovations in social networking and online communities for a number of years, I was always going to try the latest stuff to see if it could help in my job. Little did I realise the slippery nature of all this. It is somewhat like “zapping” with your TV remote control, pointless but you somehow keep doing it until something urgent drag you away from the sofa. Before you know it you’ve spent a couple of hours watching the TV but seeing absolutely nothing. What a waste that is!

I started tweeting because I was too lazy to blog, it was just an excuse for me and I hoped to learn something in the process.

My idea of blogging has always been measured, I don’t like all the self broadcasting that goes with it, I didn’t want to write “hello world” program codes or regurgitate what others have been saying somewhere else.

I tried Google Wave and I never really found a reason to stick to it. I could imagine tons of use though, I just wasn’t ready for any of those – still am not.

Now I’ve joined Google Buzz, it’s giving me the goose bumps for it’s eerie stalker feeling. I never felt stalked like this before, it’s not due to my contact list or my friends activities, but rather it is the fact that I kept seeing a mirror reflection of my activities in many places of my Google account. Then you start to think: if I click on any link, it’s likely being broadcast. For someone  who is a private person by nature, this freaks me out.

A few years ago, I’d already taken a giant step by going out there and putting pictures, comments and various things online. I could always do it again, when I get a chance, and it felt ok. But, the idea that something follows me and tells the world about what I’m doing doesn’t feel right, I have no control over it. It is bad enough that this is happening, street CCTV cameras are an example, it’s much worse when you can actually see realtime the footages. That is what is troubling, and Google seemed to have thought none of that. Of course, when you’ve not known anything else you would just adapt to it.

There you go, the bucket must stop somewhere. I’ve got nothing to hide, but I don’t want to broadcast everything either. This is a case of a feature’s default option in user’s disadvantage. That is a hindrance to user acceptance from my point of view, and Google failed in this case. This case inspires me to write an architecture principle: design for acceptance, the default features and options must cater for user’s natural preferences and behaviour.