John Underkoffler points to the future of UI

I caught this video by John Underkoffler - the science advisor for the movie Minority Report on TED the other day and it got me thinking about web interfaces, especially for online banking such as CIBC's and online billing such as Roger's. I'm not saying we need interfaces such as this for these kind of online applications, but we are surely due for a major overhaul of these interfaces. I sure hope we don't need movies about these before they become more mainstream.

Is technology capable of improving the interfaces for online banking/billing sites?

Hell yes! The customers just need to demand that. We have been stuck in this e-statement model for far too long. Technology isn't the hold up. We have had these brilliant interfaces in the wild for a while now. Consider Mint. That 15 person team was so successful they were even purchased by accounting software maker Intuit in 2009. So it is not technology that is limiting us, Mint did it and clearly they don't have as much resources as the banks or telecoms do. So what is the hold up?

Its a monopoly on my data

Consider the analyst who goes through some sort of overview of customer spending habits to figure out new plans or services to offer to these customers. Do they get a dump of the data? Probably not, you can't make sense of it. For these analysts to be able to see spending habits to justify new services they probably get to see some sort of visual, a chart, a graph, something. Human minds are visual, we are pretty good at spotting things if they are in a picture, not so good at spotting the one line in a contract that will
rip you a new one
cause you trouble in the future; that is why there are lawyers. Instead of dazzling me with loading icons please start focusing on delivering a little more value. I think as much right these analysts have to study my data to justify future products and services, I too have a right to my data to make sense of my spending habits. Here's a thought, I would happily pay $6 a month for that, instead of $6 a month for call display - which by the way probably requires you to do work to DISABLE. Why do we let these people reach into our pockets without providing anything of real value to us? Would you buy a car from a dealer who asks for more money to enable the 3rd gear? or charges you per minute per kilometer driving on an out of province highway? or you pay a service charge for filling up with a different grade gas?

Who would want this kind of stuff anyway?

Gen Y grew up in the Internet age, they expect this stuff to be the norm. Its only a matter of time before it becomes the norm so why fight it? I have been using Wesabe to make sense of my banking statements up until they posted a shut down notice. I didn't mind the hassle of exporting my statement and importing it in every month to see these beautiful spending charts. The tagging feature even allowed me to track my spending on smokes by making me more disciplined at buying my smokes from the same 2 places so that I could tag my spending at these 2 grocery stores as "smokes".


As much as I'd love to manipulate my phone bill in 3D space, I will be extremely happy if my interaction with it becomes more 2010, instead of 1997. All I'm asking at this point is for 3 fairly simple, yet significant improvements:

1. The ability to tag transactions, and to view my statement by tag for both billing & banking. Rogers already allows me to tag numbers, so you are halfway there!.
2. View tags as a pie chart -or any other visual- for both billing and banking
3. For banking, graph my "income" against "expenses", month to month, year over year.
   

Simple? Can you do it for 2010? And then if you agree that these add value to your customer, then how about you replicate Wesabe for 2011?

Minority Report science adviser and inventor John Underkoffler demos g-speak -- the real-life version of the film's eye-popping, tai chi-meets-cyberspace computer interface. Is this how tomorrow's computers will be controlled?

Sir Ken Robinson is a brilliant speaker, thinker and evangelist.

the intersection of business and technology

Technology is useless if it does not deliver business value. Either it saves me time and hence money, or it makes me money. It has to be one or the other. Where does front end architecture fit in this picture? As the title points out, its right in the middle.

The front end is a misunderstood piece of any application, it is usually overlooked, underestimated, and belittled. Its fairly common to perceive it as "toying" around, "no/low value", etc. Its also very easy to believe that all the stuff that happens at the backend is the stuff that commands the big bucks. Unless you develop low level software such as compilers, web servers, drivers, etc. here is why you are wrong, and why front end architecture matters.

You can't deliver "customer focused solutions" if you belittle the front end

Successful front end architecture means focusing on what is important for the end user, not you the developer, nor you the SQL ninja, and not even you the business SME.
I don't know how this upside down tradition started, but I might have an idea. Application development usually starts with the back end framework, you know the Springs, and the Djangos, the Struts, and the Zends. None of these deliver any value to the user, they do add value to the delivery team and make them -in a perfect world- deliver better code, faster. So how did this tradition start? (One that focused on starting in an area that couldn't be any farther from the end user) My reasoning is that it started with equating building end user software with constructing a building. The first step of doing that, is to lay the foundation, the stuff that will carry all the weight of the rebar, steel, concrete, pillars, roof, and all the occupants and their equipment. All this stuff is as far away from the occupants of the building as possible, but it is by far more important than whether the doors open in or out. The occupants of a building are first concerned about their safety, a "customer focused solution" in the construction industry is one that is first safe for its occupants. Everything else comes later. However, when we use this analogy to building end-user software, we start out right off the bat focusing on the wrong things. A customer focused solution starts with the end user, what will he be interacting with, and then works backwards to define the solution that is required to support that end user.

You can't slap an interface on it

Okay, you can, but you shouldn't. Can you slap a steering wheel in the backseat of the car? Sure you can. Should you? probably not. Why is the steering wheel in the front? because the end user needs to see the road. Start with the end user and work backwards to the solution. A more accurate statement is actually "slapping a back end on it", or "wiring the back end to the front end". That you can do. Why? Because at that point you know what the user wants, and you know how your front end will achieve it.

Another reason why not to do this, is if you care about your users' experience, you would spend more time thinking through the front end, iterating and making it better. Forget the focus groups. Forget the design committees. Empower qualified, creative, and responsible people to make usability decisions. Have real users developers use your application, and keep your mouth shut. Don't show them how to use it, or what they're doing wrong. Observe, take notes, and make it better. Focus groups could just make you chase your own tail, as what happened with New Coke.

Phasing in features

Good back end frameworks and architecture allow you to phase in functionality as you progress in the project. A good front end architecture needs and should do the same. This means, just like a good back end does, a good front end must utilize a common framework. Today, not much focus is given to the front end. In fact it is assumed it can be completed 100% with a "big bang" approach. We don't use a "big bang" approach with the back end, why do you do it on the front end? Because you tried to slap an interface on it...

Front end components need to be thoughtfully designed, with re-use and phase-in in mind. Don't attempt a one-size-fits-all approach to these components. It might make for less development, but if your focus is "customer focused solutions" then you need to account for different use cases and different user types/roles. Also, just like back end components get re-factored when duplications occur, so must front end components. Why the double standard? because the front end gets belittled.

More data is better data

Yes, your gut can have a lot of say when it comes to the front end. However sometimes the change has no affect on your gut. Does it matter if your links are underlined? or are you just doing it because [insert your favorite reason here, ex. because my dog wags its tail when it sees underlined hyperlinks] Design your front end to be able to gather these usage patterns, because "customer-focused solutions" support their decisions on customers' actions. Don't even ask your customer whether they like A or B better, keep your mouth shut and observe. Do they use your application more? better? quicker? when A is there? or when B is there?

At the intersection of business and technology lies the role of the Front End Architect (FA). This person should be empowered and trusted to make front end architectural decisions based on supporting data that will deliver value to the end user. The FA, is not a business SME, they're not a designer, but they could be. They are a technical person, a developer with the scars to prove it. They work with the business to figure out how to deliver this end-user value. The FA also works with designers to iron out any usability issues that may affect the end-user value and can be fixed via enhancing the look and feel. They also work with the rest of the developers to keep front end components re-usable, and phase in friendly.

Do you have an FA on your project/in your organization?

On selling customer experiences

I was looking at how much of a dent an iPad will put in my wallet when I noticed the mandatory field reminder on Apple.com's shopping cart. Then I came to this realization, Apple isn't a mobile device's company, nor a computer company, its a customer experience company. So much time is spent on just tweaking and perfecting the whole cycle. From the moment you browse their online store or their mortar-and-brick store, to the point you make your purchase, including the point when you receive your product, unwrap it - perhaps even record that joyous moment - and then finally start using it and then officially become a fan boy or girl. This happened to me in 2003/2004 when I purchased my first Mac, a PPC PowerBook G4.

Sorry, I went on a tangent there. Anyway, they are a customer experience company. The developers who built this form did not have to do it the way they did. This sick tooltip reminding you of the mandatory fields could just have been a red asterisk. However, because they are a customer experience company, they didn't do what every average Jack and Jill developer would have. As simple a page it is - a personal info page - it most definitely went through multiple iterations before it reached its current state.

Another example, lets say you don't look like a pirate but have a speech impediment. I'm a nice guy. If you seem like a nice person too, I'm going to do my best to understand you. However, that doesn't apply to your website or application. Don't make your product seem like it has a speech impediment - even if it looks great. Its just going to be awkward.

Learn from Apple guys, they don't have to do their site the way they do, they don't have to finnish their products the way they do, they don't have to meticulously design the packaging inside and out. But they do. And because they do, they're in the business of selling customer experiences. That is a very profitable business, and that is why Apple's stock P/E is twice that of Microsoft's.

Here's a great TED talk on "People don't buy what you do, they buy WHY you do it":

Chefs, Curators, & Developers

Besides that these people all eat, sleep, and lineup for the latest iStuff, developers ought to have another thing in common with chefs and curators. I would say software development is part engineering/science and part creativity, even as high 50/50 or maybe a little more.

Curators

The term "custodian of a collection" doesn't describe what curators really do. It almost makes it sound as if they just take care of a collection, but not necessarily care for it. A museum without a curator simply turns into a warehouse. It is the curators job to prevent that from happening. To care for the collection and keep an eye at the big picture.

Every piece, big or small, serves a purpose and delivers an essential part of the experience. The opposite of a curator is a hoarder.

Chefs

Similarly the chef does not just cook the food, they keep an eye on how the items on their menu works together, how the dishes enhance the experience, and how every ingredient in a dish works with the other ingredients. Every detail counts, and great head chefs will look after it all. They are food curators.

Musuems, food, and software is made better by what has been left out - purposely - and not what's included.

How do they do it?

Great museums don't happen overnight, they happen over time, time spent doing the same thing - improving the museum. The task is never done. It's iterative, and perpetual. Curators aren't afraid of tossing things out because they don't work, or something better came along. Curators are careful not to hoard shit, even if it's all good shit. They don't go about it alone, they get feedback from other curators, from their clients, and finally their gut & others' guts. Your unconscious brain has a lot to do with this task, sometimes it is hard to explain, but often your gut is on target.

Lessons from Chef Ramsay

The number one thing Gordon does to fix a failing restaurant is "cut the crap" - after he is done ripping through the owners of course. If you watch the show, you probably have seen him throw out half the menu - if not all of it in some cases. Take the episode of the "Curry Lounge", tons

of curry based dishes. None of the waiters guessed what any dish was during the blind fold taste test - except for the french fries; at an authentic Indian restaurant. Chef Ramsay tweaks and iterates over the food, how it's made and served over the course of the week. That's his formula. That is why he is a great head chef.

Don't be scared of "No"

There are many good reasons for saying "No". There are also wrong times to say "No". Say you are at a restaurant, and you ask the chef to skip the pistachio on your baked chicken because of allergies. That is a valid request you cannot say "No" to. On the other hand, don't be surprised if the chef says "No" while at an authentic Italian pizzeria and ask for extra cheese on your Pizza Terreno - he knows better than you. A good way to say "No" is to always provide reasons and alternatives. Most clients will consider alternatives, after all they are paying you to provide the best possible service you can afford them. Sadly, you don't always win, or you are just wrong and you lose the battle and have to provide exactly what you have been asked.

"But that is not how we do things around here"

There is always room for improvement, and there is always areas and times where you can play the role of the curator at what you do. Always start with the things you control. What if you work at a hypothetical restaurant that followed the Waterfall model? retarded right? but at every point in the process a curator could help, and a curator can make the experience better - even a little. This Waterfall restaurant basically takes orders at 5pm, by the time they are validated and cooking starts at 8pm. Then the dishes get checked, fixed and reheated. Food starts to come out at midnight. And into the wee hours of the morning the cooks have gone mad trying to

figure out what was ordered eight hours ago. Every single role in this kitchen can play the curator in what they are doing. As badly suited the experience is, it's much worse if everybody minds their own business and blindly follow the blind.

Kitchens get dirty one dish at a time

"Too many chefs spoil the soup" True, and applies everywhere. Why else do the Marines and special commandos operate in small, tightly knit groups? Do you seriously believe that anything will need an army of develop

ers yet the army elites can perform heroic missions with a team of 15?

Don't let your kitchen get dirty, it's easy to say you will do it later, but know that your effort to clean it does not have a linear relationship with how long you left it dirty.

Everybody can be a curator

Whatever business you are in, you are involved in curating and improving the product/service you provide. Whether you design buildings, write software, an author, or a sales guy, a president, or an army general. We all do it. We all know that the first draft of an essay is always the worst. When you walk into a board room to make a pitch, how many times do you revise and tweak that slide deck? how many times do you do it the night before? or even 30 minutes prior? We all do it.

So here is the big question, when did we say that code should be written once and done with? What tends to happen with development teams is this task is not performed as often as it should - specially as the team size grows. It gets worse when dates start to slip, as things like continuous improvement and cleaning up the kitchen are ditched. Here is the other problem, managers, executives, planners, etc. don't like to see tasks that don't have end dates on the plan. They want to know things like effort spent, time elapsed and percentages for each. An iterative task only has elapsed time, but nothing to identify how much is left because it's never complete. The affects of this curating task are phenomenal. Almost always you will be amazed by how little you changed or even better removed and how substantial the improvement was.

Making something better is never easy

...but the harder the decision, the better shape that thing is. To be successful at being a curator you really need to understand what your customer wants. Not just a little, you need to get in their head and figure shit out. You need to figure out how you can add value, or if you just can't. Value add is highly dependent on the context. If I am in a rush, fast food will be the best value for me at that time. I'm hungry, and need a quick solution. On the other hand, you wouldn't take your wife there on your 10th anniversary. The best way to bring yourself to a point where you can understand how you can add value, is by aiming for the simplicity on the other side of complexity. If you are looking for a good healthy relationship, you need to invest the time up front, you need to climb that complexity hill, sometimes it's steep, sometimes it's long, but rest assured it will flatten out after the peak. Thats where you want to be. Not many people make it to the other side, most will be hanging around at the base or on the way up. That region is highly competitive. The elite don't hang out there. Take Apple for example. We can consider Apple to be one of the elites of the tech industry - almost like they have the Midas touch. People have tried to replicate the iPod with little success. This week, slowly but surely Apple wrestled the 2nd highest market cap from Microsoft - without even dominating the market. They know their customers, and they don't even want everyone to be their customer.

Everything looks great on paper, it's not until it comes to life you start spotting glitches and things to improve. Good restaurants will shutdown for a day occasionally and just cook the whole menu and their staff will critique everything and make adjustments. Iteration is key. In school you are taught to review your essays, read them out loud, tweak and adjust the paragraphs, shuffle things around, all of this to find the essence and flow of what it is you are trying to accomplish.

There are only two kinds of developers.

Those that just get shit done - literally -, and those that will get it done very well. From a time line point of view, you won't be able to tell the difference. They both finish on time, and their stuff will work. However, the first, don't care about what it is they are building, don't care about who they are building it with, they put in their hours, get paid and that is it. Excellent developers don't have to be geniuses or come with Masters & Phds. These are the ones that want to be proud of what it is they are building. They are the ones that think several steps ahead, and design for change. They will embrace change if it makes what they are building better. They will try to resist change that adds no value. They are the ones that keep an eye on the big picture. Those are the ones that will invest the extra time to re-factor the redundant classes they spotted. They are the ones that experiment and try stuff out because they are always on the look out for a better option. They are the ones that will tell you "No, you shouldn't do that". That is how you separate the two. An excellent developer will wave his hands and yell when something is just not right. The first kind will shrug their shoulders and pile on the dishes.

The Mythical Man-Month

I think it was in first year software engineering that we had to read this book, and nine years later I really, really understand the underlying purpose of this book. It may just be yet another book back then, but the lessons that are hopefully learned from it will last a life-time - not just for software projects, but any project.

The Mythical Man-Month

Unfortunately on software project plans, developers, designers, testers, business analysts, product managers, etc. etc. are considered "just another resource" that are added and removed off of tasks. The assumption is that all are equally effective and skilled in all the required domains, and all will produce the same volume and quality. So in a perfect world it makes sense to scale the team to meet deadlines, although we don't live in a perfect and linear world, this is still the method of choice. Even though the biggest effect of this method; drastically increased non-linear communication time is widely known but mostly ignored.

Sadly this is the state of this industry, project plans that are too often disconnected from reality. I think part of the problem is driven by dividing tasks into a unit of time, after all that is how budgets are built, teams are put together, and progress is tracked. However on the other hand, this unit of time does not measure the real size of the task. Its just an illusion. Its like a building, we don't measure building size in number of months it took to build, we measure it by number of floors or in meters i.e. something relevant and real. If a 40 meter building was estimated to take 12 months, and in 6 months we are at 10 meters, then we are 25% done, and not 50%. However if this building were a software project its assumed we are 50% complete. Then at 10 months we realize we won't meet the deadline, forget about the Mythical Man Month and scale up. Why did this happen? Because software does not have a realistic metric, software is abstract.

Some say you get better at estimating over time, but that too assumes we live in a linear world. Ex. Project X took us 3 months, so we will estimate that project Y will take 9 months. We don't live in a linear world, and humans aren't good at estimating non-linear stuff. We may think that the second project is 3x as long as the first, but it could be x^2. However the hope is that over time you can make a non-linear project more linear by improving the processes for the non linear components. That effort is also non linear.

You can try to measure by team size, effort, or lines of code, etc. but all are just an illusion of measurement, none are real. Whether you measure buildings by floors or meters, you can translate between both. On the other hand, you can't translate lines of code into time, effort or team size.

I don't know what a better alternative is, but surely it is not this. Perhaps the problem is just trying to estimate that far into the future with too many unknown variables. Feel free to comment.

I recently read the book "ReWork" by the guys at 37Signals and one paragraph I absolutely loved has to do with project estimation.

The book is a must read.

Crash 'n' Burn: The 11th hour for Flash

Adobe's rhetoric continues after the curve ball Apple threw. The whining continues with this post: On Adobe, Flash CS5 and iPhone Applications.

Sadly, the whining doesn't change anything, and Adobe's argument would have been more valid if they didn't trying to lock developers into Flash/Flex and if it -Flash- were really open. Also, I think Adobe's Flash/Flex tools favor developing using Cold Fusion on the server side... you can use other server-side technologies however I believe the tools "play" better with Cold Fusion.

Apple's decision makes 100% business sense to me. They're advocating for their own platform, or open standards. Just like Adobe advocates for their own platforms, or open standards. What's wrong with that?

Flash filled a void in the 90s, but where is that void today? Is it even still needed? Yes its far superior technology, but its a closed technology. And to think that Android will succeed because it has Flash is just absurd. Android could be the iPhone's real challenger ONLY because it is open. The above post also seems to confuse "open" with "cross-platform". They're very different. Flash is cross-platform because its not open.

Flash needs something different right now, we don't need Flash to deliver rich content online anymore. We don't need flash to deliver sexy fonts. We don't need Flash to scroll and fade text. Soon we won't need Flash to play video - my Youtube embed below is still in Flash- . We don't need navigation built in Flash. So much stuff we needed Flash for (right or wrong) , that are just not needed today.

On to Flex, Flash's younger cousin. We - the majority - don't need that as well. Slowly but surely applications will move to the web. They may have some Flash components that could now just be as easily done in HTML5 or even HTML and some nifty JavaScript. Where I can see Flex fitting, is for these extremely specialized software, such as CAD or medical imaging. Such software is expensive and time-consuming to write, and would be a pain to translate into different operating systems. Such software also comes with heavy visualization, so its a good fit with Flash. Maybe thats where Flash will head, who knows? But there is definitely hardly any room today for Flash on the web.

This song is dedicated to Adobe Flash, I don't know who your savior will be, but you really need one right now...bad.