Interaction with today’s touch interfaces feels numb and yet it seems that device manufacturers are steadily adopting that design solution. I deeply empathize with Bret Victor’s description of “picture under the glass” effect in his article “A brief rant about the future of interaction design“.

I’d like to inquire about the motivs behind why did the “picture” end up “under the glass” and what is an alternative.

Enabling enabling

To start, I am curious to hear what do you do with your smartphone and tablet. Please tell me.

On my smartphone, I:

1. Look for driving directions
2. Send and read messages
3. Check my bank balance.

Yet my smartphone enables me to do so many more things. I find that to be a failure of design to a degree.

Let me put it in a user story:
As a smartphone user, I don’t want to be distracted by all the possibilities that I can use the smartphone for because it’s a waste of time.

With a knife, I cut. Having a knife in a drawer enables me to cut things in my kitchen. Nobody ever blames a knife for not being able to integrate with GitHub. It’s design is complete by the nature of its purpose.

I can use a knife as a door stoper, per say, but that is clearly not its purpose which we can conclude from its design.

Problem with “picture under the glass” design is that it is devoid of purpose – by design.

We are supposed to add the purpose by buying an app that fits our need. In order for a multitude of apps to work using the _same interface_, it needs to be very flexible. iPad design achieved this by making the interface entirely absent and therefore ulitmately maluble.

It seems to me that we spend so much time on the enabling part that we forget to do.

Out of the box

We are already enabled to do a lot of things. Like compute. Our brain is fantastic at computing. The span of movement we can perform is astaunding. We can talk, read and write! These are all amazing capabilities!

So we all have a lot of great things going for us out of the box. Before adding more capabilities to our list, we should ask the question “What am I doing with what I already have?”.

Infinite loop

If we don’t ask that question, we put ourselves in a infite loop of increasing our potential for when we _might_ need it. While it seems like a good idea, one can spend a lifetime of enabling and not _do_ anything.

This situation is humorously described by Joel Spolsky in the article “Why I hate frameworks“.

The Future

My vision of the future of interaction design is about making tools that allow us to _focus_ on the purpose of our action.

That action should not come through a compromise of having a plethora of options that I _might_ use. That action should be the razor’s edge of it purpose.

Would you rather eat your steak with a steak knife or a swiss knife?

In the future of interaction design, I see devices created with their purpose hard coded into them. I see software that doesn’t have configuration options. I see people having the balls to stand behind their design. And if it fails, throw it in the garbage, note lessons learned and make a new one.

Hard coding a purpose into an object requires determination that stems from the belief in its purpose which liberates us to create an _uncompromising_ design solution.

Otherwise we shoudn’t waste our time when we can go dancing instead.

Share/Bookmark

In a recent article, John Gruber masterfully compared Google’s and Apple’s software strategy. He insightfully concluded that Apple solved the software distribution problem through their app store therefore doesn’t have to rely on browser based software. As a result of that, they can have all the benefits of native apps. Read the article, I was impressed by its sobriety.

He does have a grave misconception that spans technologies in his following thoughts:

I’m biased, insofar as I consider Apple’s strategy more appealing than Google’s. But that’s because my interest lies in having the best possible user experience — the best-looking UIs, the lowest-latency responses, the smoothest animation, the most elegant designs. I share that interest with Apple.

The error is that Apple strategy does not lie in betting on native apps for “the best possible user experience”.

There are many Widows native apps that are horrendous. Flash, Java and HTML5 are all able to deliver equally good user experience. Most importantly, it is tremendously simple to create awful software in Objective-C, especially Cocoa. No, it’s not about the native apps vs. browser apps vs. any other apps.

Apple strategy lies in their approval process for the app store. That’s why you never get to see all the under-performing, ill-designed nonsense. Because it never get’s to your device.

I can conclude this because I’ve been developing for Flash platform for 10 years where that problems manifests in its fullest. People would often mention to me how they hate Flash because of the annoying advertising banners and non-usable web sites. I on the other hand have experienced some of the best software in the world in Flash.

How can those two impressions co-exist? Because Adobe doesn’t have an approval process for Flash software. Anyone can create and distribute whatever they can manage to compile. In such an environment, all kinds of good and bad work is going to show up. Bad work also gets associated with Flash and Flash ends up having a bad name.

Apple is smarter than that. They decide who is good enough to be associated with their brand. It’s their show and they are running it well.

Their interest lies in their brand image and profits, like of any other business. “Best possible experience” therefore, has nothing to do with Apple’s software and everything to do with how they run their business.

Share/Bookmark

Recently I have been tasked with researching options for video conferencing platforms that one can integrate with a software product. I will share it how I see it and I would love to hear what you have to say.

High expectations

We used to sit down at our desk, plug in or adjust the external web camera, turn Skype on and start chatting on our hard-line cable or DSL connection. Dropped frames and pixelation came with it and we did not complain much because video chatting was sci-fi and quirks were expected.

Then we got used to the idea that web cameras come with our laptops, neatly positioned in the frame above the screen. We would again turn on Skype and hope that our home wi-fi connection wouldn’t choke with the overflowing data.

Today we like to complain how Apple’s Facetime does not work on 3G network. But we say, “Well, I guess I will have to connect my iPhone to one of the multitude of wi-fi connections around me and expend two clicks of my effort before I can start the video chat”. From pretty much anywhere. Having one camera on a mobile device didn’t seem to do the trick for us so one more was added.

When video chatting with just one person at a time wasn’t enough, Vidyo, Skype and ooVoo started offering multi-person conversations. And then they took it to mobile.

This is the environment in which we are developing right now.

Having video chatting so widespread by leaders like Skype, businesses started not only using such services daily but also incorporating them into their processes and services. A need has arisen to seamlessly integrate video chatting into existing and new software.

Who is out there?

Flash Media Server was the most popular and accesible solution for a long time. Adobe released a specification for RMTP protocol that other people used to create their media servers like Wowza and Red5. Vidyo came to the scene is 2005 and created waves with their patented Adaptive Video Layering Architecture. GTalk joined the scene recently supporting XMPP protocol and Skype SDK is currently in a closed beta.
While there are many other good video conferencing services, the ones above are what developers have to work with.

How does mobile come into play?

Since mobile is such a big part of video chatting today, imho it is critical that anyone offering SDKs has a solution for it. While there is a RTMP implementation for iOS, I haven’t worked with it so I can’t speak to its quality. That used to be a big hurdle for Flash Media Server and its siblings. For that reason, Wowza added support for RTSP/RTP and MPEG-TS protocols so you can stream content to iOS and other platforms. Vidyo has an API for iOS and Android. That makes Vidyo, Wowza and potentially FMS the best candidates to focus on. When Skype goes public with their SDK they might join the list.

Who has the best quality?

Vidyo, simply put. Quality is what they are all about. They architected their solution from the start for Internet conditions, meaning they built the system with the expectation of questionable network connection quality. Vidyo also helps power GTalk’s video conferencing which speaks highly about their capabilities.

That does not mean that Flash based solutions are a throwaway, far from it. But a side by side comparison puts Vidyo solution ahead by a critical difference. Let me explain. Let’s say that in a RMTP (Flash) conversation that lasts two minutes you have the video freeze-up for one second. That amount of loss is acceptable and expected. Chances are you will not loose a critical piece of information in a regular conversation. But let’s say that you are not in a regular conversation. Let’s say you are talking to your doctor or communicating via sign language or just moving a lot in front of the camera. Let’s say your business depends on the quality of video chat. That’s where Vidyo comes through. In my testing I haven’t had any video freeze-ups at all – ever. That makes the rhythm of the conversation much more human. It makes the experience feel like an in-person conversation because there is no reminders such as lag or a freeze that there is a technology between you.

Pricing

Wowza licence will run you ~$1,000. They also offer a developers edition free. FMS will run you between ~$1,000 and $4,500 depending on the edition. Both of them you have to host yourself or my personal preference, have an account with a service that hosts it for you. Influxis has been my choice for years. Not having to worry about scaling and maintaining hardware goes a very long way. Vidyo’s pricing is cut up into smaller pieces based on your needs and you can inquire with them about your case. They are pricier than the previous two.

Documentation

Sole reason for not considering GTalk and XMPP further is the state of documentation for it. While I have found some materials, it seems that there is no big effort to make it easier for developers to jump into it. Please prove me wrong. FMS has a huge body of documentation and a big development community behind it. Wowza is well documented and has a formidable community behind it, enough to have good chances of someone else having the same problem as you are. Vidyo’s documentation is impecable but I can’t speak to the community size. That doesn’t matter much because with Vidyo you have to get support which is fantastic if you can afford it.

Summary

Today, I would consider these three players: Vidyo, Wowza and FMS, in that order. Now I would love to hear about your experience with developing video conferencing apps!

Share/Bookmark

HTML5 i.e. HTML is a markup language. As such, without JavaScript, developers would be reduced to hand-rolling HTML or creating it dynamically server side – page view by page view. Being constrained by page views is something I fundamentally refuse to accept since I am not in the printing industry. I’m in the computer interface industry. I demand programable interfaces.

What comes to your mind when you think about a computer interface? No, really, let your imagination run wild. I think of Minority Report gestures and the latest Tron. It was made as a geeks wet dream. Now fly back down to page views. That’s a hard landing.

And for whatever reason, “the Internet” comes with Javascript today. How we got here is for historians. It is here now and it provides programatic control at client runtime. That’s the card that trumps them all.

To make a digression, my beloved ActionScript used to look a lot like JavaScript before we got all fancy with AS3 and haven’t looked back. And people created amazing things with it. Just like today people create mind-blowing things with JavaScript. For a decade I was basing arguments for Flash on Internet penetration percentages. Now we have rediscovered JavaScript that was here all the time.

What I’m missing in HTML5 today is developers time. The ones that are spending their time whining about JavaScript shortcomings. I miss you here and now building great things in JavaScript together with me. I miss you in making the Internet better.

Let me give you an example. SVG is supposed to be an Internet standard. Well, it really is but Microsoft didn’t find that important until recently, so we really don’t have complete browser compatibility. So what is a gal to do?

Should she:
a) Drop SVG altogether because IE doesn’t support it.
b) Create a fantastic JavaScript library and jump through a number of hoops and make SVG available for all browsers, popularizing it in that way in hope that one day it becomes a fully supported standard.

Dmitry Baranovskiy did the latter when he created RaphaelJS. You could start noting the shortcomings of his solution or you can simply recognize that Dmitry made it happen.

Go make something happen!

Share/Bookmark

I love PureMVC because of the simple idea behind it. Have Model-Viewer-Controller pattern that can span languages and therefore time, as explained in this article by Clifford Hall. I started using it in the Flex world when it was competing with Cairngorm for that very reason. Cairngorm was Flex specific and PureMVC was language agnostic.

Coming form a mostly strict-typed MVC environment, it was very hard for me to even start thinking about big scale applications in JavaScript and HTML5 which were reserved for widget type implementations for a while.

As a natural progression of the idea behind PureMVC, it started being ported to JavaScript frameworks that emulate classes through an effort of great folks like Frederic Saunier, Justin Wilaby, Tony DeFusco and David Foley. Music to my ears! Heck, there is even an ongoing ‘native’ JavaScript port.

I decided to see if the story holds and lately I have had a great experience with the MooTools implementation of PureMVC. It feels very familiar. File structure is the same, meaning well organized with recognizable command, model and view folders that imitate packages. I use ANT to combine these files in two varieties. One just plain stacked for debugging and the other compressed using YUI Compressor for production.

There is also something magical about working with PureMVC. It feels far more like solving a workflow puzzle than coding by knowing that the same PureMVC based program can be fairly easily ported to another language and in that way have longevity. Kinda leads you to think that programing is most about managing workflows of user experience.

This setup is enough to make me feel comfortable as a programmer about big scale applications developed in JavaScript. Which begs a question: “Why would you want to develop big scale applications in JavaScript?”. Because I want to share the fun.

You can read about the PureMVC developments for JavaScript here.

Share/Bookmark

Truth be told, a lot of time is wasted on the Internet. It is wasted because it was intended to be wasted. On the other hand, there are folks that are not looking to waste time but a lot of content creators are not accommodating them. They are accommodating choice paralysis.

The proverb “paper will take anything” has evolved in the digital era to include another interesting manifestation together with the standard one. Before the digital era, people were limited in the amont of published content by the nature of the paper medium. Printing is not cheap and paper takes up space.

Today, those limitations are gone. On the interwebs, you can publish vast amounts of content at very little additional cost. The side-effect of that is that people are publishing vast amont of content without giving much thought about the consumption of that content.

And on the other side of that content is a human being that has not been upgraded for ten thousand years. Same set of eyes and hands, same mind.

The problem boils down to the fact that humans lock up when presented with too many choices. No action is taken because the perceived effort of analyzing all the choices is greater than the perceived value of the resulting action.

So what should one do about it? Certainly not spit out everything that’s on one’s mind. Everything you put forward should be filtered through the eye of the beholder and focus should be but on actions. After all, you want to interact with your audience.

You can study actions simply enough through the Agile concept of actors. Actors are not ment to be a list of roles that sits dead on paper. You are supposed to literally act out what would they do. You can one-up that by getting someone from intended audience to give you real feedback. You can’t beat that and you will always be surprised by what you find out.

What I have found out to be the rule of thumb is that people are not looking for all the choices but the right choices. Making the effort of finding the right set of choices is enabling actions of your users by doing some of the work for them.

Tavi Scandiff-Pirvu, our QA Analyst and persona actor has a talent for not only coming up with valuable conclusions but making the whole process tremendously fun.

Share/Bookmark

There are many miracles that Git performs for source code versioning and I would like to highlight a recent one that really made my day. Pathfinder did a project for client that also has a team of in house developers. But they use SVN, not Git. Since the development was happening on our side, Git was used to version the project. And since the client is a big organization, having them change their versioning policy was not likely to happen. At the end of the project came a time for the client team to pick up the code maintenance. We shipped the code by FTP and that was that, versioning was in their hands.
After some time the client wanted to add more features that they wanted us to develop. We got the code back and to my pleasant surprise, all the Git files were intact and we were quickly able to educate ourselves about the changes client made in the meantime by looking at “diffs” and pick up the project the same day. We did our “commits” and it was as the code never left. It was touching. It is teamwork. Git rules.

Share/Bookmark

I thought I’d share my favorite programing tool today. It’s not a particular IDE, a framework or a process. It’s a proxy program.

Back in the days of early Flash, debugging looked a lot like JavaScript debugging without Firebug or Chrome Developer Tools. You had to cook up your own recipe. For JS developers, does “Alert box” debugging ring a bell? That process involved a lot of guesswork because we just did not have the opportunity to inquire about the state of the application freely. You basically needed to know the answer upfront to make the question.

I am very happy with the debugging scene today. We have very good in-browser debugging and IDE’s that support debugging of  a number of languages. I would highlight Eclipse as my weapon of choice. Adobe Flex, where I spend most of my time is immaculate. Not only is debugging superb but it also allows profiling that often overlaps it. For JS, I have recently switched from Firebug to Google Developer Tools although Firebug Lite is still irreplaceable sometimes.

I started using Charles Proxy as a sanity check long time ago. I wanted an independent view into what’s going through the wire over HTTP. With all the guesswork going around at the time, I wanted to apply more of a scientific method. Although my work is mostly on the front end, most of my problems were not. They were making sure that I’m getting the expected result from the server for a given set of parameters. Back-end work was usually done by a third party. Ever so often there would be an argument about what is messed up – client parameters or server result. Projects have changed, technology has changed but I still get all the material to work with from the server. Most applications I work with are extremely dynamic and require server and client to talk flawlessly. Charles is a way for everyone to see that conversation. And with the web being more and more distributed, that aspect is not going to change any time soon.

Charles shows you what is going through the wire, both in and out, in an appropriate format – HTML, Raw, Text, AMF, JSON, XML, Hex. It has just the right amount of granularity needed for programming. When I see the data come through the wire, than it is in my domain and I can make origami out of it because I know what I’m working with. It’s that simple. Take a look at a walkthrough in the video bellow.

Share/Bookmark

Finally, this obvious idea is starting to sneak into the agenda of leading businesses – that email, SMS, IM, Facebook updates, tweets and phone calls are different channels for the same thing – a message.

As a user, I want to check messages for news.
As a user, I might even want to check only my business or only my family messages.
But as a user I really don’t want to check my email messages or my SMS messages (unless there is no other way to check my messages).

Is it a video message, an audio message, a message with a little or big amount of text, does it have an image or not, through this account or that account? Well, as I user, I just want to see my messages, I just don’t care that much. Message channel and format should be appropriate for its content and intention.

We have definitively entered a time when technology itself can not stand as a sole selling point. In my opinion the pinnacle of it was the introduction of streaming video by Macromedia (now Adobe) and services like Skype years ago. That is eons in technology time!

Today, like a lot of people, I have more than a dozen messaging accounts. Having one inbox to check them would make my life easier. And I do not mean combining my email accounts like I do in Gmail right now. Over time there will be more messaging technologies and even more messaging services. Do I have to have dozens of accounts and devices to check my messages? I hope not. I hope that the future is in distributed systems coming together in User Interface solutions yet to be seen.

Facebook and AOL are coming up with a their first shot at such an approach. Google has done best so far by rigging GMail, GTalk and Google Voice into one interface although they didn’t go the whole nine yards.

Skeptics are already saying that jamming all messages into one inbox might not be a smart idea, that it could be overwhelming. I couldn’t disagree more and I ask, what is the alternative?

Having all messages in one inbox will also do something healthy for you. It will make you think what messages do you really want to receive. You will start thinking which sources of messages is worth your cognitive processing. Needless to mention that various successful approaches in message filtering are available today, my favorite being Gmail labels and the tag based approach in general.

In the end, one inbox could allow you to analyze your communication better, so you could do it better.

Dear reader, how do you check your messages? Please share, be it your frustration or your great solution.

Share/Bookmark

I can not overstate the importance of getting some actual User Experience out there quickly for feedback. Mockups being static do not convey that critical aspect of interaction so they don’t pass muster. It often takes development dollars to realize an app was great only in picture format and that to make it a good app you’d need to double the original budget. Ouch.

Amir Khella was so nice to elaborate on how he did this fast and cheap. As far as I’m concerned – case closed – since I work on a Mac and Amir’s solution relies on Keynote.

I’ve gone through a number of home brewed prototyping versions, Omnigraffle, Acrobat Pro and latest being Flash Catalyst. In my opinion, Amir’s workflow gives the biggest bang for the buck and shortest lift off time. Workflow is the keyword here because Keynote is a presentation software just like PowerPoint, albeit a good one.

Speaking of good old PP, what about the Windows users? Has anyone tried this workflow on PowerPoint or similar?

Share/Bookmark