Friday, December 28, 2007

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.

Saturday, December 22, 2007

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.

Monday, December 17, 2007

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:

Thursday, December 13, 2007

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.