NASA Science Case Study - Part II - Design and Development

Now that we had picked our technology, it was time to start in on the design.

The ideas! They burn!

One of the funny things about taking on a large project is you either have a group with no ideas at all, or way too many. We had the latter. As someone who was on the project from the beginning, it started to feel like we had a new idea for the look and feel of the site every week. We had dozens of comps and wireframes that all had things we liked, things we hated, or things that, well, we had no idea how we felt about them.

IA

Designs aside, we also had ideas for the content. SMD had a lot of information, and in order to make a site for them, we had to get our heads around what they did. One of the funny facts about NASA is that it is very good at talking to itself, but sometimes forget that it's audience includes people who are not astrophysicists. We used ourselves to play the ignorant public, reframing their information in ways that would make sense to an everyday user.

We got into information architecture in a big way.

The first question we asked was how information was usually presented, and could we do something new and cool? Normally, as kids, we're taught about the planets: size, location, color, maybe a feature or two. But what use was that? Winning questions on Jeopardy?

Instead, we chose to present data in the context of missions and questions. What were we doing, and why? Why bother to look into deep space? Are we doing it just for pretty pictures? Why send a satellite to look at Saturn, or a Rover to Mars? One of the edgier, early IA's had no traditional context, but had the site completely based off of missions and questions. Other IA's had the questions and missions, but still used some other more traditional groupings (Our Solar System! The Stars! Our Planet Earth!). A last one mimiced the internal structure of SMD (Earth, Sun, Planetary, Astro).

Usability

You'll notice we had a lot of questions at this point, and few answers. This is where usability stepped in.

We had all become so close to the IA's and designs that we couldn't see them without seeing the debates, the tweaks, the moments of irrational design by committees or bad ideas that snuck in because we were too tired to kill them on sight. We decided to do some usability testing.

We chose a few designs and a few IA's, then a couple dozen willing victims. The testing came in three parts:

1. Answering questions about a functional design
2. Attempting to complete tasks on a fake site
3. Evaluating several designs on various attributes, such as font and color usage, or look of professionalism or crediblity
4. A card sort, where they sorted similar information into categories and then labeled them
   

We got to watch in a dark little room behind one way glass, which, while cramped and a little muggy, was an excellent and sobering experience. You get to see the things you loved, the precious darlings of the designs, get ripped apart without sympathy. You get to watch your grandiose ideas that were going to revolutionize the web get frowned at and cast aside. It sounds painful, but really, it brought us all back down to earth. It also brought our customer, who was dead set on some design matters, to see the light.

The card sort also illuminated a lot of things for us. For one, people didn't want a strange new order for their information. They wanted planets grouped, things about the sun grouped, things about earth grouped. Every person came up with almost identical IA's of their own (something I duplicated at the last Plone conference).

We ended up picking the most popular design from the study, and going with an IA that mimicked SMD's internal structure. But wait, isn't that a bad idea? Usually, yes. However, SMD's internal structure mimics its science: Earth, Planetary, Sun, and Astrophysics. We simply lucked out, that way. This way, each division had a place to call home and exert their will, and users could still find their way around.

Train the designers

Now we had a design and a technology! All we had to do to get the two talking was to hand it over to the designers, right?

Well, not quite.

Our shop was mostly filled with Photoshop experts who knew little about the inner workings of CSS. Previously, they had created sites in various Adobe or Macromedia products, exported, then uploaded. This method wouldn't work with Plone. The CSS had to be tooled by hand, as did the HTML and javascript.

Boy, did they love us.

What we ended up doing was turning our designers into developers. They resisted at first, used to their cycle of design in Photoshop, export, upload, then move on to the next project. Instead of beating them with tools, however, we showed them the beauty of what we were giving them.

• Version control. How awesome is it to have every version of every image you've ever made at your fingertips?
• We got the site loaded on their machine. This way, they could make minor changes and see them right away
• SVN updates. They could update our machine! No emails necessary! It just happened!
• We taught them TAL, and showed them some cool tricks they could do, like styling things zebra-style, or hiding or showing things as they wanted

One of the most important things we did, however, was find ourselves a CSS guru by the name of Bill. He really cinched the design for us, translating the comp and our many ideas into one site. We love Bill. We'd hide bodies for him. If you have a design group like we had, get a guru as early as you can.

So, what were the developers doing?

Our philosophy in the early days was to have a different content type for every kind of item we were going to have in the site. So, we ended up with some crazy UML that looked like this:


We also spent a lot of time stressing about how we were going to handle getting slashdotted. Our customer (and some people on our contract) were unaware of the roaming DOS attacks known as Fark and Something Awful.

It was a hectic time for us all. A year of development, shifting requirements, and a schedule that we couldn't nail down lead to some crazy weekends and some seriously frayed spirits. We prepared more for that site than one does to prepare for a new baby (I know. The site development and my second pregnancy were parallel events). But finally, on [DATE], NASA Science 1.0 deployed, and the team just about fell over in a heap of tired developer and designer flesh.

Some details about what we had:

• 4 Zope Instances
• 1 Zeo Instance
• Varnish
• Apache
• LDAP
• Parts of many, many Products
• A few Products used in toto
• One monstrous custom Product
  

We were now in maintenance mode.

(Part I and Part III)