Kizmo

I’m rather fond of Jesse James Garrett’s blog. Garrett, who should need no introduction, is in the habit of posting very short missives, and his entries often end up making me think much more than do longer essays.

Today, his entry touches on a question which we’re often asked, which is why we don’t feature our portfolio work on our site. Our designs, especially for applications, are often fundamentally influenced by business, technical, and user-related needs that aren’t immediately obvious.  As a result, we prefer to present portfolio work in a manner that allows us to provide some context and understanding of why we do things the way we do.

Garrett, as usual, sums our thinking up quite effectively.

As more material is published in PDF format (including most of our documentation), we find ourselves keeping more of these documents open or handy. Reference books in PDF format, particularly, are nice to keep close.  However, neither Acrobat nor Preview (because we’re a Mac office) are really designed for keeping a bunch of PDFs open for quick reference. Perhaps the designers of each of these need to take a fresh look at how they’re being used.

However, when Michael asked this morning why neither of these applications supported tabs, it occurred to me that there is a PDF viewer that does exactly that. I suggested Safari, and that appears to work nicely.  Browsers are designed to keep multiple sources of content available, and Safari supports PDF viewing within the browser.  With the Acrobat plug-in installed, you even get a lot of the functionality from that application within Safari’s tabbed interface. Check out the video below for an illustration.

It’s the small victories that can make a day.

An interesting wall I walked by while in Boston over the weekend

Smashing Magazine featured more than +40 Excellent Free Fonts For Professional Design back in November. However, I just found out about them and am rather excited.

It seems as though every week there is a new website, webapp or some such thing to try out. The problem is that when these are released for beta testing it is by invitation only. Being invited only makes sense from a development point of view because the producers need to work out how the back end will scale with hundreds, then thousands of users. And if you give out invites, how many should each person get? 1? 5? 10? If you are the developer, giving out 1 invite per person can help control expansion. But on the other hand, not being invited to participate can feel elitist and exclusionary. You have to know someone to be let into the party, otherwise you have to stand outside in the rain looking in.

Here at Kizmo we are in the process of beta testing a website. Only a few people have been given permission to hand out invites. This is very important so that we can control the scale of use. We are not being elitist. In fact, we want to release the website to the public but we don’t want it to crash with potentially thousands of people using it.

When does something stop being a test for the developer and become an elitist product?

It could be because I’m a sucker for purple and black but this little blog is just so neat.   Using the horizon line as the beginning of the interface… love it.

The blog makes me want to sit on a hill, under a tree and watch the sunset.

As usual today, I went to see what was happening out there in the world. I typed in nytimes.com and was hit in the face by a full page ad instead of the website I was expecting to read! A big, bold ad on a nice white page with the Times’ logo above it and a “skip this ad” button to the right. It happened on my first run experience of the day, but on subsequent hits of the site I did not encounter an ad. Glad it happened only once. Interesting that they rolled this out on a friday too.

The New York Times ran an article last month about some very intense user research. “User Anthropologists” travel cross continents for Nokia to determine how the design of phones can be informed by the needs of people who live anywhere from mud huts to tin roofs and beyond.

Cell phones typically conjure up images of gab and high-energy (annoying) commercials. An except from this article provides a much more wholesome take, one that highlights in-country development and women’s empowerment:

“After Muhammad Yunus, the Nobel-winning founder of Grameen Bank, began making microloans to women in poor countries so that they could buy revenue-producing assets like cows and goats, he was approached by a Bangladeshi expat living in the U.S. named Iqbal Quadir. Quadir posed a simple question to Yunus — If a woman can invest in a cow, why can’t she invest in a phone? — that led to the 1996 creation of Grameen Phone Ltd. and has since started the careers of more than 250,000 “phone ladies” in Bangladesh, which is considered one of the world’s poorest countries. Women use microcredit to buy specially designed cellphone kits costing about $150, each equipped with a long-lasting battery. They then set up shop as their village phone operator, charging a small commission for people to make and receive calls.”

Last time, we compared XAML to traditional web development, and discussed the fundamental flaw in its design. By flattening the hierarchy of behavior, appearance and structure, XAML requires developers to understand very deep aspects of it’s behavior and design to make informed decisions about what type of controls to use.

Desktop developers are used to this depth of decision making. It is understood that modern frameworks require a certain depth of knowledge to achieve certain goals and developers have the background to make informed decisions and troubleshoot them if required.

Designers by and large are not.

A designer is concerned with appearance above all else. They have a mindset that demands they get the screen looking correct first, worrying about behavior later. Structure is often the absolute last thing on their mind. A quick review of the history of web development would show that in service of appearance, designers were willing to abuse such atrocities as single-pixel gifs, nested tables and font tags to see their designs take form on screen. Even in modern web development, where hacks within the markup itself is discouraged, clever tricks are often advocated to accomplish otherwise simple appearances such as rounded corners or drop shadows.

As the industry has matured, it has become very prevalent that being a web designer implies you understand and know HTML, CSS and JavaScript. Those that don’t are at a competitive disadvantage. The approachability of HTML has encouraged this shifting of roles and the most prolific web designers are often those with a deep understanding of their (tools)[http://www.37signals.com]. Which is what one would expect. The more you understand the technical limitations and capabilities of your platform, the better your work will be — so long as you don’t get lazy.

Desktop development remains a very different world. It is rare to find talented interface designers capable of writing even a working prototype of their application in their target framework. In many cases, HTML prototypes are cobbled together to “get the idea across.” Worse, often nothing beyond paper prototypes are produced leaving numerous questions unanswered until deep into the development life cycle. And the deeper you get into the cycle, the more costly incorrect assumptions become.

If we accept that markup is more approachable than other programming languages, it stands to reason that if given a chance designers will take to XAML and begin to explore the capabilities of the platform. This will inform their design decisions which will improve the final result and reduce the possibility of costly design revisions late in the cycle. If WYSIWG tools are available that allow a designer to explore the platform without necessarily writing code, all the better. Utopia at last!

For now that utopia remains out of reach. Despite the platforms capabilities, it remains firmly in the realm of the developer and not the designer. While the simple has been made simpler, and yes the complex made more plausible, the overall experience of the platform will leave a sour taste in the mouth of any designer without a strong engineering background.

Microsoft’s Expression Blend, its XAML WYSIWYG tool, has yet to hit it’s stride. It’s not quite sure what it wants to be. Is it a timeline-based interaction modeler? A fast prototyping tool? An interface construction tool? Attempting to serve too many masters is hindering the application and stretching the learning curve as features are piled on. Worse, since it’s little more than a code generation tool, changes in the design view often have strange consequences on the code generated. As with other WYSIWG markup tools, such as Adobe’s Dreamweaver, developers will find themselves using it more as a tool for exploration that actual development. More often than not, they’ll find themselves resorting to hand coding to create anything production worthy.

The coupled nature of XAML’s behavior, structure and appearance elements adds additional frustration to the designer. If, in service of an appearance, the designer chooses a collection of control elements that performs poorly or does not provide the programmatic hooks required by the engineering team, the application will require re-architecting. In many cases, the changes will go beyond a simple re-factoring and entail a full rebuild. This problem could be lessened if the design tools available were capable of intelligently deciding which controls and structures should be used given the intent of the designer but Blend is not yet up to this task.

It’s clear that for a XAML application to succeed, the design team either needs to have a strong background in desktop engineering, or the development team must be brought onto the project incredibly early. Certainly much earlier than in traditional projects.

Despite these compounding issues, XAML and WPF present a way forward for companies seeking to create better applications for the Windows desktop. Over the next few years, you will see more and more commercial applications released into the marketplace which utilize the platform. And as one company releases a WPF-based application you can be sure their competitors will follow.

Will it ever completely replace the traditional programmatic workflow? It’s hard to tell. So long as it remains unapproachable for most designers, I personally doubt it. But if Microsoft has any salient quality as a company, it’s their willingness to stick it out and iterate. If version one isn’t great, just wait for version two. And if version two doesn’t float your boat, we’re working on version three right now and man it’s awesome.

Steve Ballmer has said, “It’s a joke in the technology world that Microsoft takes three versions to get anything right”.

I guess we’ll see.

As I said last time, XAML is intended to bridge the gap between the markup-based world of web development and the more structured world of traditional desktop application development, with all it’s classes, libraries and overly verbose code.

Compare creating a window that says “Hello World!” in C#, to doing the same in HTML:

<html>
    <body>
        <p>Hello World!</p>
    </body>
</html>

And in XAML:

<label>Hello World!</label>

The similarities are striking. And the contrast with traditional development should be clear.

Cleverly, Microsoft went a step further and removed the traditional compile phase of development for simple XAML applications. If you’re running Windows XP, have Internet Explorer 7 installed and the .NET 3.0 framework installed, you can copy the above XAML code into a new text document, title it “Hello.xaml” and open it. It should display.

In later articles, I’ll provide more concrete examples of XAML and what can be done with it. For now, I wanted to give you a taste of the language for comparison.

Despite the visual similarities in code, there are serious differences between XAML and HTML. These differences help to explain why it may never be as accessible as HTML and why it’s a damn lie when folks advertise XAML to be similar to HTML in anything but superficial ways. Yes, they’re both markup languages, but the similarities end there.

HTML is primarily a visual formatting language, and when combined with a style sheet is incredibly flexible. The interactions between CSS and HTML allow the developer to adapt nearly any structure to suit his visual purpose. Sometimes those transformations get messy, but their possibility is what allows for the language to feel forgiving.

Behaviorally, HTML is quite limited. Aside from links and form elements, which are relatively immutable, HTML offers no true interaction model. Instead, these behaviors are applied separately via JavaScript and basic mouse events.

Notice how separate each aspect of web development can be. Content is represented in the HTML structure. Appearance is represented in the style sheets. Behavior is applied by scripting. While it may seem that these separations create complexity, it practice they simplify the developers world by isolating problems to specific domains.

XAML is a radically different beast in this regard. Elements in XAML come with an implied behavior and appearance and structure. Changing any one of these elements can be a chore. In fact it can be said that behavior, not appearance, is the primary domain of XAML. You select the element to use not based on what it may be — a header, a window title, or a grouping — but instead based on how it will behave. If you need an area that includes a scroll bar, you’ll need to use a ScrollView. If you need an menu to appear beneath or over an item when clicked, you’ll need to use a Menu. The goal is to make the common case relatively easy to develop, while relegating more custom needs to advance techniques.

This may sound logical at first, but in use it changes the nature of development in fundamental ways. Because XAML documents describe behavior, structure and appearance all at once, a developer has to be overly careful in what elements he uses, where he uses them and how he expects them to appear. In the most basic cases, the decisions are evident and clear. This can and does simplify the act of creating desktop applications by reducing the amount of redundant code and making the application’s markup more closely match both the behavior and appearance of its interface. The robust and varied capabilities of the built-in controls provides the interaction designer or developer with a richer set of tools than in most desktop presentation frameworks. Perhaps the only richer toolbox is Apple’s ApplicationKit.

However, this coupling of behavior, appearance and structure creates definite gotchas during development. If a developer uses the wrong element he’ll often find himself painted into a corner where the appearance he needs is impossible to achieve with the control at hand without essentially rewriting the entire control. Or he may find the reverse is true. He has the appearance he wants, but the behavior is out of reach. XAML isn’t exactly intelligent about performance either. To achieve certain behavior/appearance combinations, the developer will need to nest several controls within each other. But once he does, he finds his application is eating up memory or that window resizing is unnecessarily slow. Or worse, that the application crashes because some combination of controls refuse to work together.

Without a clear division between the behavior, appearance and structural realms of the application the developer is tasked with understanding at a very deep level how every decision he makes will impact his application.