Facebook: Everything but the Kitchen Sink

When working on a project, I look for ways to minimize the amount that
any one item is trying to do at once. It seems reasonable that each
button, screen, image, etc. should have one job. In the end, I want a
system that is graceful, does a lot of thinking for you and makes life
a joy, it its own little way. Does this seem like idealistic egotism?
Probably, but it's my goal all the same. Sometimes I even get there.

Facebook seems to be the antithesis of this. They want to cram
everything they can think of into a social environment. They have
games, chat, messaging, stuff for sale, billboard ads, Mr. Coffee in
the corner and the corpse of Billy Mayes to ensure you get one free
while you're at it. The question then becomes, is this really what
users want?

It seems most users pick a particular part of the FACEBOOK
MEGAVERSE©®™ (add LOTS of echo). I personally use it
as a means to make my friends stop yelling at me because I'm not on
Facebook. Facebook's user experience for me is unparallelled. I
don't use it for anything and my friends don't yell at me. I call it
a win. That said, so many people use Facebook for communication, or
something akin to Twitter, or gaming, or... you name it. There are so
many pieces of Facebook it's overwhelming.

The first time I set up a Facebook account, the interface was
reasonably simple. Then I killed that account without mercy. Now I
have a second account. It's quiet and private. When I first logged
in, I screamed and logged out. It was awful. There is so much going
on, it feels like I am walking into a video arcade at a mall. Have I
mentioned large crowds, flashing lights and too much noise freaks me
out? It does. So does Facebook.

A while back, designers were given a challenge: redesign the Facebook
interface. There were several people who submitted ideas. (Not to
Facebook, of course. Just to the guy who started the whole thing.) In
the end, I felt that many people had great ideas for how to present
the mess Facebook has made its bed, but I think they all missed a key:
Facebook is just too much.

I just picked up the scent that Facebook is looking to do Music sales,
if they aren't already. I also read that they are trying to beat
Google. Let's not go into the discussion that if you feel there is
someone out there you want to beat, they have already won. So, they
are going to add search. To their games. And their messaging. And
their news feeds. And their photos. And their chat. And and and.

Facebook is working on becoming the next Ma Bell. Dismantled and
cannibalized for parts. Come on, guys. If you really want to do
this, can we break it up a bit so the luddites like me can actually
make sense of your craziness? Thanks!

(Please note, I state I am a luddite. This is not entirely true. I
think progress is awesome. I think misdirected progress that makes me
want to weep in a corner is bad.)

How Not to Release Software ( #newtwitter )

The Twitter redesign has been live for three weeks, or so they say. I
wouldn't know because I still haven't seen it for myself. My friends
all have it. People have had it so long it's not even interesting to
them anymore, yet I'm still out in the cold.

Why?

Twitter opted to release the design extremely slowly to random people.
Actually, that's not true. Twitter hand selected special people to
receive the update on launch day, then they provided the update to
people who they thought were important to their PR. After that,
everyone else is getting the update as they are randomly selected. As
important people and friends of Twitter squawked, they were updated.

This wouldn't be a problem if they had done this over a week or,
perhaps, two. The very first people would still be excited about the
new design and the last people wouldn't feel left out. Two full weeks
after the launch, Twitter announced that "about 50% of Twitter users
have the new design."

Doing a little math, it means that about 100% of the people will
finally have the new design almost a month after their big hubbub
about the release. When I say "about 100%" I mean that I'd lay odds
they padded their numbers and less than 50% of Twitter users actually
had the new design available to them.

Moreover, this means that the people who get the redesign at the end
can't turn it on and off and compare the old and new designs for any
length of time, while the first people have a full month or more to
play before Twitter flips the switch and enforces the "new design
only" rule.

Why is this a bad idea?

If you are one of the first people to play with it, it's great. The
latter 50+% of the people who are still awaiting the update are
feeling alienated and disenfranchised. We are watching all the other
kids play with their new toys from Christmas while we are decorating
for the 4th of July while staring at our packages under the tree.

Since the first users are now over the novelty of the new design, the
users who get it last get to hear things like "why are you still
talking about new twitter? It's old news." This is a good way to
leave your users cold. Twitter has managed to turn one half the
community against the other half.

In short, when you prepare to launch a new piece of software, think
about all of your users and find a better way to do things. Release
software so all of your users can get excited. This isn't the fashion
industry where the buzz just makes it more exciting when the normal
people finally get a piece of the action. Software moves fast and web
apps move faster. Keep up and make your users comfortable in their
skin. Make your release fast and make the web a better place.

Strange Days on the Web

Since I started my latest project I've been thinking about my very
first jobs on the web. I distinctly recall the job I had back in
1997. I was working in the merchant web design department for College
Club. At the time, College Club had an affiliated company called
Public Online. Now the site redirects to teen.com. Sometimes I wish
I'd bought a really cool domain back then. There were so many to pick
from...

Anyway, working for Public Online, we built websites, lots of them. I
probably built 60+ sites in my 3-4 month tenure. They were probably
all really lousy. I was a recent high school graduate with an above
average proficiency in HTML and Javascript for someone of my age. I
was no master, but I didn't know that then.

I recall one client actually coming into the company to discuss his
website. He owned the, now defunct, Family Fun Centers chain. He
brought along his ten-year-old son. It turns out, the owner of the
company wasn't going to talk about what he wanted. His son did all of
the talking.

"I want fireworks and explosions when the site loads," he said. "I
want it to play some loud music and be really cool."

I was 19 and didn't understand it then, but seeing an exec show up
with his pre-teen son is never a good sign. Children, typically,
aren't the best people to talk business decisions. This one was no
different.

Those were strange days on the web. They were the cowboy years. I
feel really lucky to be old enough to remember them from within the
industry. When the internet bubble burst, I took it as a personal
blow. I didn't know better. I was an early twenty-something with
little job experience and I just watched the beginnings of my career
head straight for the toilet.

It was probably the best thing that could have happened to a kid like me.

I revel in the wonderment on the web now. I think it's fantastic how
everything has grown, but sometimes I yearn for the days where
anything went and you could get away with murder. The web wasn't
pretty and we all had a lot to learn, but it was so damn much fun.

I know this is a departure from my usual posts, but I just felt an
overwhelming need to reminisce. Okay, let's get back to making the
web a better place. ; )

Engineers, Designers and the Process

I have a diagram of a design process on my office wall. This diagram
is a designer's take on the design/development process of a web
application and it frightens me just a bit. I often find myself in a
room full of engineers defending the choices marketing and creative
team members make. In the end, I can only say one thing.

Come on, guys, I need something to work with.

The diagram I am referring to offers up a great timeline for designers
to work their magic. There is lots of room to collect information,
talk to clients, get user input and then test drive the comps to the
ends of the earth. Then, the very last segment of the diagram is
given to developers to "just finish up the bits and pieces."

When you are working on a website which is essentially static content,
leaving the developers little extra time is fine. They don't have to
do much so, giving them a small piece of the pie is fine. For most
web projects, however, the developers need lots of time to implement
the work which needs to be done.

I worked on a medical provider search for American Claims Management a
year, or so, ago. The design and preparation went rather quickly,
though I wish I could have the chance to rework the UI. The bulk of
the time, however, was dedicated to the tricky bits which did things
like the actual search.

I had to work out what I was doing mathematically across a paper
globe. I had to spend time playing with set analysis and preparing to
collect information in the best way I could find. Then I had to write
the whole thing.

It took a lot of time.

To suggest that developers aren't doing any work or, worse, that they
are just finishing up the dirty bits since the hard work is all over
puts ME in a bad position. See, designers, I fight for you. I am the
guy that speaks engineerese and fights the good fight for you. The
least you could do is cut me some slack and give me something I can
fight for. If I walk into a meeting and say, "okay, people, we have
three days to develop the system," they are going to tell me to shove
it.

In the end, the only way you are going to meet the engineers in the
middle is if you give them something to work with. Just like you,
they have to go through problem solving sessions and testing. Just
like you, they have a lot of work to accomplish in less than adequate
time. Just like you, they are killing themselves to meet the
deadline. Let's cooperate and make the web a better place.

A Sneak Peek

User-falloff-nofunction

Here's a little sneak peek of what I have coming for you on Monday.
This is a graph of predicted user falloff while waiting/seeking
behavior is occurring. No, I won't tell you the function (yet). Yes I
think this will help (a LOT). I'm excited to share my research in
theoretical user behavior with you and I just couldn't wait to share
this little bit!

When in Doubt, Throw it Out

It seems like, with the proliferation of the "Web 2.0" philosophy,
sites have become gluttonous. There is a strange movement afoot, the
cult of more. More widgets, more navigation, more content, more MORE!
Ultimately, I have to wonder if more is really what we need.

Luke Wroblewski is calling for designers to design for mobile first. Although his reasoning is sound regarding
mobile-specific reasoning, I especially like his point that designing
for mobile requires designers to focus.

This type of laser-focus should extend beyond just the designers and
should, in fact, touch everyone involved with a project. The less fat
you build into your application, the better off the user will be.
This goes not only for core site function and the resultant navigation
bloat, but also for non-essential things like Javascript effects.

It is becoming more and more common to rely on Javascript to do
everything. Unfortunately, this leads to sites functioning poorly
when scripts are turned off or are unavailable. I visited a site a
while back which required Javascript in order to perform a search for
local pharmacies. I found this requirement to be profoundly stupid. I
personally know blind people who use as few browser extras as possible
to keep their experience reliable.

These people are the kind of people who would perform a search for a
local pharmacy. Unfortunately, they would never know why the search
didn't work. What's worse, the site was intended for Workers'
Compensation claims, which means, if someone were impaired and injured
on the job, this tool is the ONLY available tool.

Old web works.

Old web isn't pretty and it may not make you the hottest thing on the
block, but old web works. When you build your application, the first
thing you should do is build it, not only from a mobile mindset, but
also with old-web tools. A page request works the same with any
browser, essentially. You send a Get or Post request and the server
replies with a success (200) or an error (just about everything else)
code, followed by some sort of content.

Throw out everything you don't absolutely need. Trim the application
down to the very core of what the user will interact with. Use
Javascript only if it makes the user journey through your site better,
don't use it as a crutch to hold up a failed application. On the
other hand, you should only trim those things which you don't NEED.
This is not the same as trimming everything and leaving a bare site
with a text entry box (unless you're Google).

While working through your design think about the core of your system.
Build the simplest journey for your user and make your site a joy to
experience. Encourage user interaction through ease and clarity.
Trim the fat, cast off the excess and make the web a better place.

The Unplugged Sessions

You know how they say "the best things in life are free?" Though
that's not entirely true in Ux and development, it's still darn close.
After trying out all kinds of tools, toys and other things to make my
life just a little better, I have discovered something I should have
known a long time ago: The best tools are a pencil, an eraser and a
blank sheet of paper.

Much like MTV unplugged which features acts doing what they do best
without an effects rack that would make most sound engineers quake
with excitement, I find myself doing my best work when I step away
from the computer. In the end, I have to hop back on the computer to
produce something I can deliver but, in the meanwhile, there is
something about turning off the screens and simplifying the creation
process.

I've learned to enjoy these unplugged moments so much, I have gone so
far as to institute unplugged sessions at work. So far I have only
had a couple, but I found myself being far more constructive during
these hour-long breaks from the computer than I often am while the
screen is on.

Little is more distracting than having e-mail screaming in like
tactical missiles and messages from coworkers looking for insight on a
project or system you touched once upon a time. When the screens go
off, the productivity goes into high gear. The hardest part is to
mentally unplug even though you have done so physically.

In your mind, the first time you try it, you'll find yourself saying
"but someone is surely e-mailing me right now. It's important."
Resist the urge to turn the screen on to check. Instead, set a timer
and know, in an hour, you'll get to everything people are chomping at
the bit about. In the meanwhile, just turn off the noise and focus on
the task at hand.

Consider it a mini sabbatical in the middle of your day. Make a list
of things to get done which do not involve the computer and work
through that list during your unplugged session. When you plug back
in, you will be light years beyond the point you would be at if you
let the computer consume that hour.

The brain is an incredible tool. When it is not distracted, your mind
can perform all kinds of gymnastics you would never expect. Give
yourself a chance and let your mind do a few laps around the paper,
without a screen to distract you. Unplugged sessions will give you
the freedom you need to really make the web a better place.

Don't Just Stand There, Do Something!

Oh, my dear Posterous account, it's been a while. I've been busy
getting things done which has left me little time to write much of
anything. Since I'm not completely wiped out and I have a spare
couple of minutes, I thought this would be a great time to write
something new. What better to write than about doing stuff?

There are two distinct types of people I've met, those who think about
stuff and those who do stuff. I don't care who you look at, everyone
falls into one of these camps. The people who think about stuff are
the people who sit around saying "one day, I'm going to do stuff.
Right now, I'm planning but some day I'll be done and ready to
execute."

The problem with planning and thinking indefinitely is that you never
do anything. You spend so much time worrying about whether this
solution or that solution will be the right one to score your
millions. Guess what, no solution will ever do anything for you
unless you actually execute it.

I prefer to be someone who does stuff. I'm not saying I do it right.
I'm also not saying my answers are the right ones, but my first
instinct is always to DO. I do a little planning. I anticipate as
many pitfalls as I can, I jot down a basic plan and direction and then
jump into the thick of it.

There is a down-side to taking the 'do' attitude: you will fail. A lot.

Honestly, I can't say that I have actually created a single
"successful" project since I started doing. Things just don't go the
way I want to. Success, however, is in the way you look at things.
In a sense, every project I've ever undertaken has been a success
because I did it. It might not have been the best or brightest way to
do whatever i took after but, by God, I did it all the same.

After doing, I reflect. I review what worked and what didn't. How
did people react? How do I feel about continuing down that path?
These are important things to note. I also review technical failures
and successes. Did hackers take control of my site? Yes, that
happened to me once. I was miserable. Did a bunch of junk commentary
get posted? Did things work the way I wanted them to?

Every failure is a success.

In failing you learn something you didn't know before and you learned
something about yourself. Learning is always a win. The only way to
fail, however, is to do something. Once you have taken the steps to
start doing, you'll start succeeding and failing. Take everything in
stride and give yourself the chance to grow in ways you never thought
possible. I usually end with "make the web a better place," but today
I have a different message:

Don't just stand there, do something!

Visual Limits

It seems to be fairly well known that people scan in an F pattern. Moreover, Jakob Nielsen states people can scan the first 11 characters of a string without moving their eye. This is commonly implemented information on the web and aids users in selecting information in a faster, easier way.

Something occurred to me today while looking at a list, there is a  vertical limit for skimming as well. This is, by no means, scientific, but I noticed that I could look directly at the page and gather 3 lines of text formatted at roughly 1.6em. In other words, I could, reasonably, skim information at a little less than 5 characters top to bottom on densely packed lines with a 12pt font size.

This leads me to a conclusion about information stored in any kind of horizontal display element: the taller the element, the harder it is for users to skim. It takes work to scan across the page seeking information when you can only see 3-5 elements at a time. For typical site navigation at the top, this isn't much of an issue as links are usually only 1-deep.

Footers, on the other hand, must be managed carefully, however. There is a trend to place lots of information in a footer, currently. When done well, this kind of supplemental navigation can be quite helpful. When executed poorly, the information at the bottom of the screen tends to look like a big lump of text which people won't read.

In order to keep this post characteristically short, I'll just offer a quick thought, and write a full blog post later, on how to think about your footer for maximum impact.

  • Keep the list of links short. People can't effectively scan several long lists horizontally so cut the less important data.
  • Organize your links into clear groups. If you have grouped links where the user can immediately discern which links are related to which, they will choose the correct list by quickly scanning horizontally and then scan vertically to locate the particular link they are seeking.
  • The footer is no place for huge tag clouds. The bigger the tag cloud, the harder it is to find anything, especially because of the font-size variety. Keep any tag cloud which lives in the footer trim -- about 3 or 4 lines.

When you start putting together what my friend calls a "fat footer" think about how your user will scan and collect data from it. Provide them with the easiest way to get as much from your footer as possible. Make the web a better place.