At least that’s what ESPN says they did in “A Guide to the new ESPN.com navigation.”

What is the easiest way to navigate ESPN.com? We’ve created a special guide for you.

Is it 1994, when you had to explain navigation to people? When’s the last time you read a how-to guide regarding Web browsing?

This is design by fear, admitting that maybe the design won’t work as well as the old one or reaction to it will be worse than expected. Good design shouldn’t have to be explained—especially when that design is the first thing a user experiences when navigating to your page.

If ESPN were so fearful of making this change to their site, why not make this “special guide” part of the experience? Better yet, why not test the design with people or use the time spent creating this page to make it better in the first place?

As people use information appliances more and more as part of their daily lives their experience with interfaces increases to the point where handholding isn’t as required as it once was. Having a manual should be seen as a design failure for an application. For navigation it’s simply bizarre.

(Thanks to Jason for chiming in!)

Now I can give my nephews a little math lesson with that “shiny glass screen thing” instead of throwing YouTube videos at them. Awesome.

Tech

For our purposes, we decided that a PHP script would be a simple yet effective way to retrieve and combine all of our data.  In addition to all the ease of OOP, PHP allowed us to make easy calls to the various APIs we would be using via the cURL module and handle XML via SimpleXML.  We also ended up utilizing the GData package from the creators of the Zend Framework.  This made the authorization process with Google all too easy.

Google (settings spreadsheet and authentication)

In addition to info like hours and project status, Fuzzy Math keeps track of several indicators on a daily or weekly basis.  Financial information, project proposals in the works, etc.  By keeping this info in a Google Spreadsheet, we not only had an effective method for storing this information and allowing multiple users to update the file, but our dashboard could display the relevant data.  Using Zend’s Gdata package, we can authenticate with Google and access the data.

We also use the spreadsheet as a means to store configuration data for the rest of the script, rather than hardcoding the variables in the file.  Variables like the Twitter screenname to use, the mapping between blog usernames to Basecamp usernames, Basecamp company ID, and any other information the script needs are stored here.  This also acts as a form of security, as only users with access to the spreadsheet will be able to see see the dashboard data.

Basecamp

Chances are you’re already using Basecamp for something, it is a pretty standard tool for group management, time tracking, and more.  In our case, we wanted to pull the time tracking data and project milestones for use in our dashboard.  Luckily, Basecamp has a pretty expansive API to help users access their data.  We wanted our data organized as “milestones by project” & “hours per project & total hours by person.”  This meant that we needed that we would be making several calls to the API to get everything we wanted.

Before we get into specifics about queries, let’s talk about tokens.  Tokens are used by Basecamp to restrict who has access to what resources.  Each call to the API includes a token for security purposes, and this token acts as a filter for what will be returned.  You can find yours on the “My Info” page.   With that in mind, if you’re using the Basecamp API to develop a multi-user application, make sure you’re using an appropriate token.  You wouldn’t want too much or too little information shown.

Back to the queries.  The first thing we need to do is get our companies projects & employees.  Well, actually, the first thing you need is your company ID, but we didn’t feel this was necessary to retrieve every time the dashboard updates, as it isn’t too likely too change.  The easiest way we found to look this up (although there is probably a much more obvious way we just didn’t know about) was to look up a known user’s data.  User’s ID’s are shown when looking at their “My Info” page, and a person’s info includes the company they are working for. Viola, company ID.  Write it down somewhere, you’ll need it.

With company ID in hand, you can get lists (formatted as XML) of current projects & company employees, via the appropriately named “get projects” and “get people” functions.  We only needed the names and IDs for these so that we could look up further details and show their names on the dashboard.  Iterating over the list of IDs you can retrieve the project milestones (upcoming, completed, and overdue), and time reports for each employee.

Other companies might also be interested to know that the API allows access to “To-do Lists.”  We at Fuzzy Math aren’t big users of the feature, so we didn’t include it in our dashboard.

Twitter

Within Fuzzy Math, there isn’t one person who has responsibility for the Twitter account, and as such it was deemed a helpful addition to the dashboard.  As you would expect, Twitter has an API for developers to make use of .  We didn’t need to do anything too fancy, so we didn’t have to bother with authentication.  Essentially all we did was pull in the recent timeline for our Twitter account (FuzzyMath), and do a count of messages over the given time period.  The user_timeline function gave us an xml feed with just this information.  A quick parse with SimpleXML and we were all set.  If we were to start using separate twitter account for each employee or somehow differentiate between who tweeted what, things could get more complicated.

Blog

Similarly to the Twitter account, the Fuzzy Math blog is updated by several employees.  Unlike Twitter though, we could actually tell who wrote what, as each has their own username.  To keep the process simple, we made use of the existing blog feed, parsing the xml for the authors and post count information.

Putting it all together

With all of our data in hand, it was just a matter of combining the information together as needed.  Through a bit of haphazardly written PHP, we built an XML string containing milestone info, company-wide totals, and individual totals.  Getting the blog info to play nicely was a bit of a snag, as the Basecamp user names didn’t match those from the blog.  A simple mapping array solved that problem, and after a bit of debugging, we had our info ready for display.  Of course, actually displaying the information is a whole other story.

Inspired by other small business dashboards we decided to create one for Fuzzy Math. The first iteration is going to be geared for the three co-founders by providing a heads up display of company performance. Normally we send out a series of emails or Basecamp posts to each other. It’s tedious and doesn’t really provide all of the right information at a glance.

Here is Brett’s early design for the page. Ben Worrel, one of our interaction designers, will have a follow-up post next week on how we hooked all of the various data sources together to make it work.

Any interest in this for your own small business? Anything you’d add or remove?

Let us know what you think.

We still have a good deal (lots) of work to do before we can say it is polished, but we are definitely on the right track. Please cruise the new digs and let us know what you think (or if you find any errors — I blame Brett if you do).

More changes coming, but this is the biggest for a while.

We are off to enjoy an adult beverage and think about what just happened. A more thorough recap of the process will be up in a day or so.

I was going to leave my first blog post as just that but felt the need to clarify one thing. I was BORN in Omaha (*), but I’m not sure I can say I am FROM there. It is one great Midwestern town — and I have still have family there — but I’ve lived 66% of my life in-and-around Chicago. Chicago is my jam. It is where I am from.

I’ve spent the last few years freelancing for various agencies here in the city and felt it was finally time to settle down. As Ben mentioned, I’ll be leading the front-end charge here; coding up sites, html’ing our crazy ideas and promoting Web standards to our clients and comrades. I am very much looking forward to the challenge and am excited to be a part of the team here.

Good design deserves good code.

- Brett

p.s. If anyone has a recipe for a veggie Runza, please contact me. Those things are pipin’ hot!

We have experienced growing pains here and there, but now we have something to show for it! We are super excited to announce that we have made our first full-time hire in front-end ninja, Brett Meisinger. Brett has worked with Fuzzy Math a couple of times over the past 12 months as an independent contractor, but this time it’s for keeps.

Personally, I have known Brett for about a decade, where we have spent loads of time together at DePaul University, liQuidprint, the Fireside Bowl, and multiple road trips across this great land of ours.

He will have a bit more to say for himself in a bit, so I will leave this short and (relatively) sweet.

Welcome aboard, Brett!

* Even though we have “Math” in our name, don’t trust us as math tutors. We were 3 and now we are 4, sooooo 33% bigger? I have no idea.

Two data visualizations from two very different sources caught my eye in Google Reader yesterday because they both told stories through a simple visualization.

#1 The illustrated guide to a Ph.D.
by Professor Matt Might

via Andrew Sullivan

His visualizations and simple one-liners not only tell a complex story but motivate his students with a real purpose.

#2 Kurt Vonnegut explains storytelling using graphs

via SwissMiss

The second is a bit meta since it’s a graph about storytelling which itself tells a story. But through the use of simple graphs makes a powerful insight concerning truth in storytelling.

Here at Fuzzy Math we’re big on storytelling in UX design. We stitch user scenarios together based on personas and tasks in order to produce a realistic user story. We believe these stories can better aid our clients in understanding their users and their users’ needs and build consensus among their team.

But it’s a lot of work and in no way do I want to imply that the above examples are easy to create. In fact that’s the beauty of a great visualizations, they explain something complex in a way that makes it seem effortless. There’s a lot of power in that ability.

You’re reading an article in the Fuzzy Math design series. These articles talk about our practice: why we do what we do, and how we do it.

« previous article: Omnigraffle Table of Contents Generator

A few months ago we were tasked with a redesign of a pretty large site and we had to get a grasp on what was out there quickly. We saw they had a sitemap.xml file, and it kicked off our innate laziness: someone on the internets must have made something to suck this XML into Omnigraffle, right? In fact, several someones had wrangled with this quite a bit, but there wasn’t a nice and easy solution out there. Just lots of hair-pulling.

I had a lot of the same types of problems getting this script to work, so it was time to roll up the sleeves and spit out something better! Hair or no hair to be pulled! Let me introduce you to the Fuzzy Math Sitemap.xml to Omnigraffle Sitemap Generator. It’s super-simple to use:

1. Download the file from the link above, or from this link right here!
2. Drop your sitemap.xml file onto the application.
3. Watch the Omnigraffle goodness spill right out of the file.
4. Use the same manner of selection and mass formatting I outlined in the previous article to apply your particular doc style to all the elements.
5. Save your document and PAR-TAY!

Ker-bang! You should have an awesome Omnigraffle sitemap. Here’s a picture of what you’ll see happening along the way: