Crayon Physics Deluxe is a cool physics game :-)

It is good to see WPF (Avalon) applications breaking into the real world. It's feels great when you architect and build one of the first mission critical applications for WPF.

Back when WPF was Avalon, I and Jaime Rodriguez from the Enterprise Go program worked together to build this next generation ATM and the first ATM went live last year when Avalon was still in beta. It was the designed to replace the DHTML ATM that I had architected in 1997, and which is deployed to entire Wells ATM network. I expect in a couple of years, the entire Wells network will run the new WPF codebase.

And last week, couple of the other products I worked on, also hit beta, Seattle PI and Forbes Reader.

IM.NET was designed and written by me to familiarize myself with C# and .NET framework in early 2003. I was familiar with the Jabber/XMPP protocol at that time and was looking to take C# and .NET for a test drive.

Now with Linq/XLinq integration in C# 3.0 due next year, it looks like the best time to take it out of the closet and take the new technologies for a test drive and find out if the hype behind functional programming is really justified. This time I have also decided to open source the application under the Mozilla/LGPL license and host it at Codeplex.

I am currently cleaning up some of the old code and plan on adding some technical documentation and hope to release the source by mid-September.

This is a snapshot of how i3Connect's Vista's Unified View would look like.

I designed this picture in 1998 or 99 and it shows integration between calendar, task, contacts, notes, IM, email, news and other enterprise data types integration

My Context presentation has more information on the vision behind i3Connect.

The above title seems to make no sense at all. How it possible for an UX (User Experience) to be invisible and yet evoke a powerful emotional connection.

Quick Question – What is the best User Experience for setting the clock on your VCR or DVD player or any device in general?

Most device manufacturers have tried to solve this the wrong way by creating an UI (User Interface) that allows the user to use the remote control or a set of buttons to set the time. That’s why most of the devices either blink 12:00 or have been set by the service technician. BTW, this is a great interview question.

The correct answer to this question is – Does the customer care to set the time? Setting the right time is a requirement for the device not for the customer. The customer is not planning to use the device as a clock, so there is no reason for them to set the time in the first place.

If the customer does not care, the right answer is - the experience should be invisible.

In fact most clocks do this right. They use a radio signal to sync up the time.

But this (setting the clock) is a one time operation only and it takes only a couple of minutes.

The above statement is wrong is so many ways …

1.      This leads you down a slippery slope of making the customer do things to use your product that they don’t care about, degrading the UX as you go along.

2.      It takes only couple of minutes for customers willing to learn and do it.

3.      It is a one time operation till a power failure or a power cord is unplugged, since most devices consume power in standby mode (Maybe an EPA standby power rating would help, but let’s not digress)

Now that you are free of creating UX for things that customers don’t care about you can focus on items that customer really care about to create an emotional connection with them.

Apple is one of the few companies in the world that get this and that’s why the market share for the iPod keeps growing every year.

The iPod uses a combination of a great device, software and service to create an experience that is focused on creating an emotional connection based on what the customer wants to do.

The first step is to understand what the customer wants to do. No kidding, but this is really difficult for most companies to do. In the iPod case, it is listening to customized music on the go.

The elegance of the device, simplicity of wheel interface, shuffle mode, iTunes, music store, etc. are all features and not the end game. Most PRDs (Product Requirement Documents) start and end with feature checklists and are very helpful to create a me too product. That’s why all the iPod wannabes have failed. Copying features without understanding the customer’s goals is a great example of Cargo Cult Engineering.

Choosing the genre of music on the go, to match your mood is a good example on how the wheel on the iPod and tiny screen collaborate to let you quickly select it.

So if the customer cares, the right answer should be – the experience should generate an emotional connection.

If you look at successful products you will see this pattern of Invisible and Emotional connection in their UX. Understanding how customer intend to use your product will help you choose the right UX items to make invisible and right ones to generate an emotional connection.

BTW, this is why the iPod does not ship with an AC charger. After all why add another block in your life that you don’t care about when the iPod can charge itself via the USB connection when it is downloading the music.

i3Connect Vista was the consumer version of Communication client of the start-up (i3Connect, Inc.) I co-founded in 2000. Some features included …

If you are looking to convince your Boss to let you play with WPF, then these three videos will come in handy.

1.       Healthcare demo

This App is a great demo on a real and practical use of Avalon and covers most of it’s features. It expands the definition of User Experience for Line of Business applications.

2.       The Northface Demo

This video pushes the limits of Avalon to explore new UI concepts with 3D and media.

3.       Evolution of Avalon

For folks who are discovering  AJAX and sing wonders of it, this video delivers a good reality check. I like this video especially since I experienced the wonders and pains of DHTML in two major applications in the late 1990s and early 2000.

One of my feedbacks to Microsoft was that they should have shipped a stripped down version of Avalon in 2003 on Windows XP and it’s was nice to see Michael agreeing.

If your Boss is still not convinced and does not have a good reason, then maybe it’s time to look around ;-)

I have a lot of respect for Miguel and his work with Mono but statements like “Avalon is the J2EE of GUI Apps” is just nonsense.

Having worked for the last one year to architect and build an Avalon (WPF) application, I can say that the Avalon team has made most of the right choices to build a system that you pay for what you need only. It follows the goal - Keep simple things simple and complex things require more work.  

On the other hand J2EE goal was that all things (simple or complex) should require the same amount of work and should be wrapped up in object oriented goodness. That’s why writing a simple J2EE app that dumps information into a web page is so difficult compared to Rails.

But what about the big Avalon learning curve?

It depends on what you are trying to do … If you are planning to drag and drop controls and use them like black box controls  (just like Windows Forms or old Visual Basic) then the curve does not exist. Using Sparkle and Visual Studio Orcas, you can happily create great UIs just like the old days by buying custom controls that are fancier than Windows Form controls.

If you are planning to skin the controls (Avalon’s template and styling), then you need to understand core concepts and tools like Sparkle help.  

If you want to do some fancy 3D, then you need to understand 3D Geometry and tools like Zam 3D help.

I could go on and on, but the point here is that Avalon has all this power but you don’t pay for it unless you want to use it (unlike J2EE).