Information Design vs. Interaction Design

This morning I read a really fascinating paper by Bret Victor. Bret is a person I'd never heard of before but wish I'd heard about earlier - he's done some really amazing work in the world of information design and I've really enjoyed the time I spent running around his website. His grasp of information architecture is uncannily good.

Bret's paper focuses on the limitations of interaction design and introduced me to a term I'd previously thought was synonymous with it: information design. Bret's thesis seems to be that most software is for conveying information - not manipulating it - and thus interactions are mostly harmful. If we can limit the number of interactions a user requires and increase the amount of information they receive, we do a better job and make better software.

I'd say this culminates in a better user experience. It's all very interesting to me because I've always just assumed that interaction design and information design were all about user experience and that the end goal was always making software that solved problems in ways people enjoyed. Apparently this isn't the mindset everyone has, but at least Adobe has gotten many of us on board.

The paper is long but very good. After presenting the current situation and problem with our current interaction models, Bret goes on to describe the method he used in creating one of his applications and how we as technologists can start doing a better job focusing on information design. He includes a call to action for information designers who haven't discovered the web yet to get in here and make things better. I agree. You can start with my blog, please.

It's time to kill the "Department" department

David Armano has a great post up on his blog titled "It's time to kill the art department."  The point of the post is that the idea that we build better products and ideas when the our company's structure is fluid - when the entire company environment, right down to the way we delegate and organize our responsibilities, is based on solving whatever specific problem your working on.  He talks about this specifically in light of not dividing your company into different departments.

This really resonates with me in our field of RIA development.  As a developer, I hate the idea that I don't have good ideas about design, and I'd hate to work in a place that didn't encourage everyone to get involved in building the solution.  Just because we're trained as software developers doesn't mean we don't have good ideas on usability, interaction and design too.

Honing our designer/developer work flow to the point that those roles don't exist in isolation has been a big part of the past year at Effective UI and part of my experience here that I've really enjoyed.  It's one of the best parts of our company and something that I feel gives us an edge over organizations who still isolate their teams.

Effective UI on Scoble

Our company president Anthony Franco and I were out in SF a few weeks ago and interviewed with Robert Scoble. We had a really good time - Robert's an excellent interviewer and asked really good questions. As a developer I was excited to get to talk about design some and our process of mixing dev and design work. It was also nice how he kept asking us to promote ourselves (give our web address, etc.) since those aren't things I ever think to say.

Each interview is kinda long - like 15 minutes. Check 'em out if you have the time:

My interview

Anthony's interview


Application demos


Scoble's original post: here

why I need an iPhone

If nothing else, I need an iPhone to have something to do in the bathroom (besides the obvious.) Right now I play a game on my current cell phone called "delete all the pictures of the inside of my pocket." It's not very fun and I win just about every time.

It's kind of cold in our office today:

Some important things to know about Facebook

I recently built a facebook widget out of one of our applications and I had a hard time getting started. Suffice it to say that Facebook's documentation is pretty limited for total newbies.

If you're new to facebook, you'll find the "getting started!" documentation more than frustrating: it's disingenuous. It promises an easy start-up - just read a tutorial, check out an example, and you're on your way! If only it were so easy.

The problem is that no one at Facebook ever stops to explain how Facebook actually works. For instance, there's a part of setting up an application where it asks for some default FBML, in case "setProfile" hasn't been called. What does this mean? Why would I call setProfile? What's the deal with that?

Maybe this comes naturally to most people, and so Facebook didn't feel the need to put it up there. I know I'm not the brightest developer to ever grace the web, but I'm not the worst either, so I figured it was worth a post outlining the things I didn't understand. On to said post.

The Two Main Parts
As far as I understand it, there are two main parts to any facebook application: a part of the application that can be embedded in the user's profile, and the actual application's page. These two things are totally separate. They can be related to each other, but don't really have to be.

Your Application Page
You'll need to host your application and all of it's data on your own web-server. Facebook has a service to allow you store data about a user on their server, but it's only in beta, and they still won't host your page or it's assets. Your application can be written in just about any language, though all of the Facebook supported example applications are written in PHP. When you get your application up on your own web-server, you can set your application page link under the "Callback URL" field in the application settings on Facebook. Why this isn't called "Application URL" or "Hosted Application URL" or "YOUR URL" or anything more intuitive than "Callback", I can't tell you.

Your application can either produce normal HTML output or custom Facebook-enabled HTML - called "FBML". If you use HTML, your application will be loaded in an iframe. If you use FBML, it'll be loaded directly into the facebook chrome on your facebook application page. You'll need to specify either FBML or iframe in your application settings to make this work.

Facebook's set of FBML tags is fairly well documented. Using their set of tags allows you to make some pretty good applications rather easily. Put these or your own HTML into your page, load it on your browser, and set it as the application callback url. Now when users hit apps.facebook.com//, they'll see your page loaded into the facebook chrome, but only on that application page. This page and this set of code has more or less nothing to do with adding the application to their profile, which is probably what you really want to do.

Adding your application to the user's Profile
As I said before, the user profile part of the application is more or less completely separate from the rest of your application. This is the part I really had trouble with. Nowhere that I could find in the Facebook documentation to they explain the relationship (or lack thereof) between your application, your application page, and the application that's viewable in a user's profile. Here's what I learned through a long week of dusty php:

User profiles are comprised of FBML tags. By adding an application to Facebook, you earn the ability to add FBML to a user's profile. Any FBML you add will be limited to your application's space in the Facebook profile page. FBML is added using Facebook's "profile.setFBML()" method.

For example, if you want to add a Flash application to the user's profile, you'd need to define the FBML tag associated with your flash app (the fbml:swf object) and then add it to the user's profile. I do this in my application using Facebook's php library. The code looks like this:

//set the flash fbml so that the widget shows up in the profile
$user = $facebook->require_login();
$fbml.= '< imgstyle="border-width:3px; border-color:white;" swfsrc="[Your Swf's External URL goes here]" width="300" height="500">';

$facebook->api_client->profile_setFBML($fbml, $user);

This adds the fbml for the swf directly to the user's profile, meaning that the user will now see your application as part of their profile page.

If the user has added their profile but this code hasn't executed, Facebook gives you the option of providing default fbml in your application settings. This default FBML will only be displayed if your application hasn't added a single line of FBML to the profile; as soon as you add anything, even if it's non-visual, the default FBML will go away.

Adding Custom Data Parameters to User Profiles
The last difficult thing I learned was about how to add custom variables to a user's profile. My application needs to store three short string values per user. I could've made and housed my own database to house this data, but that seems like a lot of work for just a few variables.

Though Facebook doesn't yet offer an easy way to do this directly, you can store variables into the non-visual fb:js-string tag, like this:

$fbml = '<fb:js-string var="VariableName">variable value</fb:js-string>';
$facebook->api_client->profile_setFBML($fbml, $user);

You can get this data back and parse your application using the profile.getFBML method and parsing the data by hand. I'm sure there's a good, easy way to do this in PHP, but the XML library included with the Facebook php 4 library by default is a pain. It doesn't recognize namespaces in XML elements (so the fb: tags screw it up) and it doesn't handle the dash in "js-string" well either. I used a few string replaces to clear these out and then parsed the data by hand, like this:

$scrubString = ereg_replace("fb:", "", $string);
$scrubString = ereg_replace("js-string", "jsstring", $scrubString);

//create a new XML object from our "scrubbed" string
$impl = new IsterXmlSimpleXMLImpl;
$sxml = $impl->load_string($scrubString);

//Get the "jsstring" members of our XML object, which is
//where our earth live specific variables are stashed.
$jss = $sxml->fbml->jsstring;

The variable "jss" now consists of an array of our js-string variables. Parsing the data is easy using a quick loop:

$variableName;
foreach ($jss As $result) {
$attributes = $result->attributes();
$var = $attributes['var'];
switch ($var) {
case "VariableName":
$variableName = $result->CDATA();
break;
//etc.
}

PHP 5 includes some native XML processing methods, so it's probably much easier - the server I was forced to host on only had PHP 4, so we had to make it work.

I hope this helps save you some time on your future facebook endeavors. Feel free to hit the comments if you have other questions about adding Flash apps to facebook and I'll answer if I can.

Amazon Kindle: Death by Bad UI

Jeff Bezos announced the Amazon Kindle this morning - the latest release in the long attempted and never perfected field of e-book technology. The Kindle is a device you carry like an ipod, no thicker than a pencil, that lets you download and read books and newspapers without carrying them all around.

The Kindle has a great business model. Once a customer purchases a book, they can download it forever for free, meaning that they can delete it to save space and buy without fear of losing their books if their kindle breaks. The device uses both wireless EVDO (cell phone) networks as well as traditional wifi, meaning connecting is easy. Users can purchase subscriptions to newspapers and magazines and get new issues instantly. I really like how accessible their making e-books and how easy the business model is on users.

As a business model, Kindle is really great and on par with iTunes - maybe even better - but the good news stops there. As a piece of hardware, it's a near total disaster. The UI isn't the worst I've ever seen, but, well, it's about as far from an iPod as you can get. The screen is black and white and grey. About a third of the real estate is wasted on buttons, and about half of that is for a keyboard. Yes, a keyboard. Because sometimes, when I'm reading a book, I like to type an email. Or something.

What the Kindle really needs to last is a total ui over-haul - a little iPhonization. The user experience has been totally neglected on Kindle; it looks like a bad, over grown palm Trio, which is the last thing I'd want to read a 400 page book on.

Books are a visual experience with very little interaction, and the hardware needs to reflect that - the entire device should be a color touch screen. If I need a keyboard, one should appear semi-transparent over my book. I should be able to shop for books on the device, dragging them from some amazon book store to a local hard drive my moving my fingers around. And the "next" and "previous" page functions are a perfect place to implement some of the touch-gesture technology we've been experimenting with: drag your finger in one direction and it goes to the next page, the opposite and it's the previous. This could change based on your region to avoid the prejudicial left-to-right metaphor it's currently shackled with.

I need to WANT to use this thing in order to buy it, and right now I just don't. The iPhone has ruined me and I won't settle for a device that doesn't provide just as good a user experience.

As it stands, unless Amazon plans to release an updated version 2 of this hardware ASAP, I think we can get ready to relegate the Kindle to the land of forgotten technology, along with Laser Disc and Betamax. Sorry Kindle - you're the best e-book reader to date, but you're still just not good enough to replace printed paper.

Help Stop Internal Build Errors

Internal build errors are the bane of my existence, and they oftenhave nothing to do with my code. I posted a large number of solutions and causes I'd found on my old blog, here, but sometimes they still happen and for no good reason.

From what I've seen, Flex Builder seems to crap out and stop compiling if there's more than a few hundred classes in your workspace. The best and most consistent solution I've found is to clean and rebuild until the error goes away.

Why can't Flex Builder do this for us, or at least try it a few times before throwing the error? The answer is: it could, but it doesn't, and all it takes is enough people asking Adobe to add this feature for it to become a reality.

Please join me in the fight against internal build errors by voting for this enhancement request.

Workspace Corruption and Moxie Beta 2

Moxie Beta 2 corrupts the .metadata files on close on my system (Intel Mac.) The workaround is to copy your .metadata file before closing flex builder and replace it with your copy before you restart.

Vote for the bug here.

Problems loading Workspaces or Projects in Moxie Beta 2

I tried to point my new Beta 2 version of Moxie to the old Beta 1 workspace, and it froze on me several times. I tried using a new workspace and importing the projects with the same result.

The workaround is to build new project files on the old project directories (back them up if you're worried.) You'll have to re-set all your project properties, unfortunately.

I logged this as a bug - please vote for it here.

AIR is......AIR?

Here's a question I thought of in the bathroom today:

If RIA's are about bringing desktop-like interaction and performance to the web, and Adobe AIR is about bringing RIA functionality back onto the desktop, are we really just bringing the desktop back to the desktop?

File a Bug!!

If there's one thing I learned at MAX this year, it's that the Adobe bug base is alive and kicking and that the Flex team is very focused on fixing the issues they've encountered.

If you find a bug, please file it here. And if you're a dedicated developer interested in making Flex better, please go through the weird UI to find some of the more important bugs and vote to have them fixed. :) My only complaint about this bug tracking system is that it's really hard to wade through the list of issues to find the one you want...voting for them without soliciting your friends and co-workers with a specific URL is a little difficult.

Here's to Flex, the Flex Team, and everything they're doing to make Flex better.

Blog kickoff!

Nothing starts off a new blog like a good youTube video. Today's lesson focuses on Maths and their importance in our society.



Thanks to John McRee for sending this out.