It’s bound to happen sooner or later. Every so often Scoble (Microsoft blogging wunderkind) posts something that makes me question his sensibilities. One of his latest posts stopped me dead in my tracks. The post was a reply to a Jon Udell post on UI technologies in Longhorn. I thought Udell’s post asked questions any professional should be asking. Scoble tries to bring it into focus by saying:
Ahh, but Jon, the real play here is one of programmer productivity
Programmer productivity. As if every new technology/language introduced in the last few decades failed to deliver on that same promise. As if Longhorn and .NET are the productivity “tipping point.” As if being fluent in multiple technologies/languages is a bad thing. As if being fluent in multiple technologies/languages will go away.
Robert, your overselling the reality. I will use .NET to create commercial, shrinkwrap and enterprise software someday. I am becoming fluent in .NET technologies. But you should take a break from the Kool-Aid (although I hear the grape flavor is hard to put down). I see an advantage in understanding multiple technologies/languages and being able to choose the best for a particular situation. If anything, .NET will make the technology soup developers work with worse, not better. Just like every other “productivity improvement” before it.
I have talked about our experimentation with XML as a file format. This is going very well. Since we started working with XML and its related technologies, other ideas started popping up. It’s not like XML is some magic concept, but it does open your mind enough to see other opportunities. Like creating a centralized Web Service to act as a repository for projects. You don’t need XML to do something like that, but since XML and Web Services go together, it’s easier to visualize how a service like that could be built off of (or into) our persistence system.
I think it’s because there are so many examples of XML being used for various things. Anytime you see XML being used for some purpose, you can ask yourself if your use of XML, whatever that may be, can be applied the way someone else uses XML. Another example could be syndication. RSS and Atom are XML-based syndication formats. Can I syndicate our file format? Maybe just modifications. I’ll have to float that one internally…
Developing new products is great for trying new things. There is no legacy and lots of freedoms. One of our areas that is screaming for experimentation is the UI. UI models have been changing in recent years. Many products are taking more of a Web-look. If you start digging into the design reasons, you’ll run across discussions of Task-based UI or Inductive UI. It’s not hard to find examples, especially from Microsoft: Windows XP uses Task Panes and Web-isms in many parts of the Shell; Office XP also makes heavy use of Task Panes; Applications like Quicken and Money have very Web-like UI’s.
According to Microsoft, Task-based UI’s are suppose to address the following problems:
- Users don’t seem to construct an adequate mental model of the product.
- Even many long-time users never master common procedures.
- Users must work hard to figure out each feature or screen.
The solution provided by Task-based UI’s is to provide simple, task oriented views that show the user what can be done now and what they can do next.
Obviously, slapping some Task Panes in your application doesn’t magically make it easier to use. This method is focused on the User Experience, but I would go further and say it’s User Assistance. As such, we are involving our Documentation team in establishing the design and guidelines for use in the application. In addition, this method also seems to play well with the teachings of Cooper and Raskin. We are looking forward to see the effects on overall usability.