Why and when to break out of the browser

"A web app can do what a computer from 15 years ago, without a disk can do" Daniel Jalkut

While Daniel Jalkut was sort of kidding when making this statement on "Core Intuition 17", he wasn't really kidding. The fact remains that desktop applications sport a lot more features, both UI, functionality and user friendly vise compared to Web 2.0 applications. But, when does it make sense to move something onto the desktop, and to what desktop?

With the advent of the real iPhone SDK and the AppStore, Apple managed to light a spark in the idea of creating applications once again. It's nothing new, this idea of creating applications instead of webpages, however the distribution model(AppStore) is "new". Suddenly everybody, designers, web-developers, marketing people.. the list goes on.. everybody is making iPhone applications. In most cases they are good apps, however in other cases there seem to be a lack of planning/thought ahead of launching xcode.

Why and when should you consider making your project into an application instead of a web-application? I always ask myself the following questions before making such a decision:

• Does the application need to access local resources on the users computer?
• Does the application need to exist outside the web-browser? Why?
• Does the application rely on server storage completely?
• Does the functionality ask for a custom UI?
• What solution handles the users frustration level in the best way?
• Does the IA need a page-based layout?
• What's the degree of interaction required?

While contemplating these questions you would probably form an idea as to what is needed for your application to succeed. But, bear in mind that most of the questions above result in solutions that can and will run fine in a browser. Trough RIA tools like Flex and SproutCore, the most demanding UI demands can be met. But, if your application needs to do a lot of local file access, or it needs to exist outside a browser session... Imagine a chat client running only in the browser, it would be no good because you'd go offline when you closed the window.

My advice would be this: Think about it.. are you presenting information that constantly updates, like a news site, why in gods green acres would you do that in an application, it screams web page! Remember that users pick their applications(no matter the platform) with much greater consideration and care than they pick websites to read/use. An application on the computer desktop or on any device needs to satisfy a need or solve a problem, be it something practical or a just game. An application exists forever, because you don't own it like you own your webpage. A webpage can be revoked and it will for all intense and purposes be gone from this world. An application is downloaded and cannot be removed unless the user decides to delete it.

Don't try to emulate a desktop application in a webpage if the application actually needs to exist on the users computer. Try to see if you idea fits into the following boxes, in this order:

1. Can I solve this using HTML/CSS?
2. Can I solve this using HTML/CSS and JavaScript
3. Should I solve this using SproutCore/Flex(or similar)?
4. Can I solve this without platform specific APIs?

Here is what I would do:

1. Create a webpage
2. Create an advanced webpage
3. Create a RIA application running in the browser
4. Create a RIA/RAD application running in a cross platform runtime(AIR or Java)
5. Create a platform application

Now, go do some real work, until next time.. cheerio!

Tip: Tracking you Flash/Flex site[UPDATED]

There's a lot of fuzz surrounding this topic. So why should we bother with tracking what users do to our applications and games on the web? Well, there's a lot of reasons for doing this, however the main motivation should be to gain knowledge about the user friendliness of you creation. Do the user understand how to use the site/app, or does he give up after a short try? If your in the advertising business there also be alternate motives, but then you'd probably know what you're looking for..so.. I'm just going to outline how to track you app.

The first thing you need to do is to head over to Google Analytics(GA) or a similar service unless you want to develop you own tracking system, something I will not touch with a ten feet fork in this article..

GA is pretty straight forward to set up, and once you have managed to set up tracking on the html page that will host your swf file it's time to get into the clever stuff. The thing is, to track something from ActionScript 1/2 vs AS3 are two different things. In AS2 you would simply use the getURL("javascript:pageTracker._trackPageview('myTrackingPoint');"). This will then add a tracking point called «myTrackingPoint» to GA, in AS3 it will look like this: ExternalInterface.call("pageTracker._trackPageview","myTrackingPoint"). This difference can be traced back to that AS3 has a different and much more powerful interface to talk to JavaScript.

To use this in an effective manner I highly suggest using some kind of folder structure when tagging your apps. Like e.g. if you have 5 buttons in your main menu, then track them like so:

ExternalInterface.call("pageTracker._trackPageview","mainmenu/button_home");

In this case GA will create a folder structure which makes navigating within the GA report much more useful.

Okay.. now your on your own..

User friendliness - a matter of taste?

Sneaking about on the WWW I tend to find all these articles dealing with something the authors call user friendliness in computer programs. Most of the articles deal in the differences between the OS X interface and the Windows interface. But they often tend to generalize, thereby and hence talking about user interface design in general. And that's nice, that people care about how things look, but that's also the problem. 90% of the articles dealing in user interface design focus on visual design. Now, visual design is only a small part of the user interface. Indulge me while I explain why it's important to know this.

User interface design is not if that button should be red or blue, or it's that too, but not only. The isolation of visual elements is called graphical design, which is something quite different from user interface design. Since my field of interest lie within the world of RIA applications, I'll use this as my point of origin for this statement.
When you sit down on your trusted behind and start thinking about how your RIA application should behave, you need to take into consideration the following elements: IA/SD, UID/HMI and GD. So, that's a lot of nice not disclosing concepts, here's what they mean.

IA - Information architecture. SD - System design(systemization):
In RIA development, these two are actually the same thing. In other areas like website development, IA will adhere to a slightly different path than SD, but in most cases, and in this case, they are the same thing.
The science of expressing a model or a concept of an entire system is the shortest possible definition of these concept I cold come up with on the fly. This means using a modeling approach to break down large amounts of data to a more readable format in which logical paths of data can be seen in the development and design of the application. In others words, trying to predict the users movement trough the system. This approach lays the foundation for usability and findability in applications, websites and databases.

UID - User interface design. HMI - Human machine interaction:
Like IA and SD, UID and HMI also go hand in hand, the only difference lies in more empirical approach of UID, while HMI is much more theoretical. UID is, as the expression denotes, a collection of rules on how to design the user interface of your application, like buttons and boxes and stuff. The rules that make up UID are derived from HMI principles, like Fitts' law, reaction time and so forth. Let me stress this point, these rules are measurable data, it is not a matter of taste. The HMI principles are built upon years of research into human physiology, psychology and human habits. So when the UID principle state that the OS X menubar on the top of the screen is a better way to go than attaching the menubar to each and every window(Windows), we know this because we can actually prove it trough a HMI principle. And therefor we simply adheres to the UID/HMI principles when designing an interface.

GD - Graphical design:
This is not a matter of taste either. Surprised? Well, GD is kinda a matter of taste, but there are lot's of rules in this area too. It's a reason why you are reading this black text on a white background you know. Graphical designers knows that this work, and they stick to it most of the time. In this area you encounter subjects like readability, fonts and so on. But do not get me wrong, graphical designers do not only deal in colors and fonts, they also need to know stuff from the UID area, how else would that know how to design a button that the user actually will understand how to click.. The transition between UID and GD is blurred, and I think it should be. The result of all these fields coming together will result in a efficient, understandable, beautiful and intuitive user interface.

So here is my point in all of this. You cannot simply look at an application and say that it's ugly and therefore it must it can't be user friendly.. it may very well be extremely user friendly. And then again, a really pretty application with fancy stuff in it may be completely useless. User friendliness is not a matter of taste, it's a matter of skill and knowledge, plus a touch of magic.

Review: Pixelmator

The brand spanking new Pixelmator from the Dailide brothers adds a new member to Delicious generation software pool. So, this is an image editor app for OS X, utilizing Apples core image processing routines. It's not a Photoshop replacement, yet. But it has the potential of becoming one.

I'm a vigorous Photoshop user, so naturally I'm accustomed to the tools provided to me in that app. Containing in that mode, Pixelmator was a no brainer, the menus and tools where almost exactly where I expected them to be located. There is one huge difference in the UI though.. Pixelmator is far better than Photoshop, not only does it look prettier, it's also more logical, cleaner and does make for a sleeker experience. You won't get scared when being presented with the Pixelmator interface, you'll go "vow, way cool man!". Where when opening Photoshop for the first time you'll go "ehm, do I really need this".

However.. this is the first release of Pixelmator, and it is slow.. sometimes too slow, even on my iMac Core2Duo. Photoshop is much faster..and that matters. But as a whole I do believe that Pixelmator will become a Photoshop competitor..in time. Check it out at www.pixelmator.com!

Fitts' law and RIA

To my amazement, it seems like the usage of Fitts' law in Internet applications and websites is a rather controversial topic these days. There are critics out there claiming that Fitts' law is an old and outdated approach to designing user interface elements.
Well.. the law of gravity is also getting old, but guess what.. it's still relevant. I really don't insinuate that Fitts' law and the law of gravity are the same, but the point being made here is that Fitts' law is just that, a law describing physical movement. This is not an idea made up by a besserwisser trying to revolutionize the UI of computers. I believe that the biggest problem with Fitts' law, is the fact that most people working in UI design, and particularly in RIA and web design, have either little or no knowledge of the actual content of Fitts' law.

So what is it? In short, Fitts' law is model describing human movement. It was described by Paul Fitts back in 1954. Despite to popular belief, Fitts' law isn't all about making things bigger on screen. As this is a part of the law, the actual formula describes the relationship between distance between the starting point and the target, and the size of the target. And you have something called infinite width, which I will describe in more detail later.

Mathematically speaking the law states that «Time = a + b log2(D/S+1)». Where D is the distance from where your cursor is currently at to the target, and S is the width of the target. The a and the b are constants. It's not that hard now is it, but yet extremely powerful when taken in to use. So how do we use it? Let's start of with the words of Bruce Tognazzini.

While at first glance, this law might seem patently obvious, it is one of the most ignored principles in design. Fitts' law (properly, but rarely, spelled "Fitts' Law") dictates the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out.

What TOG is talking about here is the infinite width. What that means is that, like in the Macintosh menubar, the menu is at the top of the screen, always. This will let the user move his cursor at full speed to the top of the screen, because no matter if the user keeps pushing the mouse upwards, the cursor will stay in the same place, hence making a target of infinite width.

But let's drop the Os X vs Windows crap. Let's instead concentrate on how to apply the principles of Fitts' law to our RIA apps and web sites. Now note that these are only my suggestions on how to apply Fitts' law, so please do your own research. My opinions are largely based on my studies of HCI from the university and later experiences in building applications, RIA apps and web sites.

1. Contextual menus. If you are going to build a contextual menu, make it a pie menu. I don't really like contextual menus, because they hide the interface from the user, but it seems they're here to stay so let's make the best of it. Well, a pie menu will be faster than a dropdown menu. The reason for this is that you minimize the distance the cursor have to travel by centering the menu under the cursor at creation time. Additionally, pie pieces make for bigger targets than lines of text in a drop down menu.

2. Buttons. Group your buttons together in that order the user is most likely to use them. Commonly used buttons should be bigger and more accessible that less important and less used functions.

3. Dialogs. Attach your dialog windows to the window it belongs to. In this way, the user will know where the dialog will appear and the movement can therefor be "trained". Fitts' law doesn't actually describe trained movements at all, but this is important in conjunction with "the easy to hit target", this explains it's relevance in this context.

4. Edges. If you are in control of the mouse pointer. E.G a full screen app. Then make use of the edges to place important UI elements. Edges are much easier to navigate to because of the infinite width. But don't use both horizontal/vertical edges of the screen so the user need to move the cursor over the entire width..that would be bad. For both right and left handed people, the upper left edge of the screen is the spot most easily navigated to.

5. Drag and drop. Since the muscle tension increase when doing drag and drop operations(holding mouse button pressed), it's a good idea to minimize the distance the user has to drag something to drop it. You could for example pupup a drop-box next to the item when the drag operation starts, hence minimizing the distance.

In my opinion, Fitts' law is an easy to implement principle that requires some thought and consideration, but it's worth it.

Flash vs Flex, what to choose when

If you're a ria developer like me you've probably encountered this situation at least once. You have this somewhat large project to do, there are lots of interactive elements to it and the target format is swf. If you don't already know this, both Adobe Flash and Adobe Flex delivers in the swf format, the same player and all. The only real difference dwells in the approach in which you choose to take developing the finished product. My approach to this would be to first define what kind of project this will be. Will this end up to be a presentation (1), driven by animations and not so much depended on user interaction to work. Or will it become a (2) true ria application, containing lots of interactivity and projecting a user depended interface.

In the first case, your choice should be Flash, as this tool has a timeline and is in fact intended for online presentations with some interactivity. Flash is great for presenting video, small games and other project that can be clearly defined as more depended on the designer rather than the developer.

In the second case you could in fact go for Flash as well, which will be slow and horrible, but it will do the job and the end product will most likely end up looking almost identical. However, when doing developer driven project, the tool used should be a developer tool. Enter Adobe Flex. The UI of Flex is dramatically different from Flash, focusing on code to a much larger extend and totally abandoning the timeline. Because Flex is build like any other developer tool, like xCode and Visual Studio, most developers will feel much more familiar with the UI of Flex. Another thing to consider is development time. Since Flex features layout elements made especially for making applications, it much easier to set up an UI that will shrink to fit the needs of the user. And Flex has even more trick up it sleeves, it can handle swf's exported from Flash. So really, you can have the designer make custom elements all the way trough and set it up visually in Flex. However, most designers will probably end up using Flex powerful CSS support instead, as it's quicker and makes for a more consistent user interface.

The difficult thing here isn't really to convince a designer to work in Flex, or a developer to work in Flash.. the hard thing is to define which is the right tool for the project you're currently working on. Well, good luck with that then ;-)

RIA - Rich Internet Application

According to Wikipedia: "Rich Internet Applications are Web applications that look and behave like desktop applications." I totally agree, and therein lies the conundrum. Web-designers and web-developers alike have their way of doing things, and so has application designers and developers. Even thought they all are in the same business, the application approach to things have a somewhat longer history to rely upon. The web-developer approach really didn't come into play until the middle of the 1990's. By then application developers already had clocked in about 10 years of experience creating software and UI design. But the much anticipated clash of the different groups of developers and designers was never to come, for the simple reason that they where doing different things in different places. That is, until now. These days it's not longer enough to master "tagging" and Photoshop to satisfy the needs of clients wanting to blow away competitors online. And with the introduction of such tools as Adobe Flex and Microsoft Blend the www is rapidly heading towards application design and development. I haven't forgotten about Google and their go for JavaScript AJAX development, however, that's somewhat outside of the scope of this, as it largely remains web-development.

To develop an application for the web versus the development for an OS, are two different worlds by far. There is not only the technical aspect of filesystems, hardware and low level programming versus the high level web development strategy, it's also the heavily fortified rules of user interface design existing in application development. On the other hand, app developers escape the headaches of making sure their app can run alike in all browsers.

My take on this is to take the best of both sides. UI design guidelines have come a long way on the client side of things. The Apple design manual can by it self carry the entire weight of the user experience. However, the freedom expressed by some web-designers, the ability to throw out old concepts and bring in new ones is something we should have in the mix, as long as these new ideas conform to established truths about what people actually do in front of a screen. Regarding development, I do firmly believe that pure web-developers have a lot to learn from application developers in the fields of efficiency and security.

The problem that still remain, is the speed of the evolution in RIA design. Most people do not have enough computing power to run high end RIA applications. The reason for this is the inefficient browser and the plug in architecture. In a recent interview with Bill Gates and Steve Jobs (yes, together), this question was brought up. Those two disagree on many things, but one thing stood out that they both truly believed in. They argued that in the future the Internet will function more like a giant database, a back end system while the front end part will be handled by client apps running naively on the system of the user. Thereby effectively removing the problem of bad user experience. They make a good point. The thing is, you cannot leap into the future online, cos you can't be sure that people will be able to follow you. And it looks like many developer companies have came to the same realization, just take a look at Air (Apollo), it's Adobes way of moving application development away from the web and onto the desktop, but at the same time keeping the multi platform Flash development environment.

For the future I predict that the web will keep it's role as a place to get information, to advertise and a place to play. But for bigger more complex things I believe that people, given time, will notice the better user experience and the share speed a desktop app can provide. A good example is Apples Google maps client on the iPhone. It's a client running on a phone that actually outperforms the original Google maps client by a factor of ten. As people become more tech capable, they'll demand more, and then we whom are designers and developers should hear their call.. or crash and burn.