About 3D Timelines - Part II.

When I designed the first product (a web-based document management system) for Bee Documents back in 2002, I started with pen and paper and then used Adobe InDesign to complete the prototype.

Since that time I have used Apple's Keynote software to do design and prototyping for dozens of websites and desktop applications. For me it has several advantages over Photoshop, which is the classic tool of choice for this kind of work:

• I find it much faster to draw and make adjustments with Keynote.
• The effects (rounded corners, tinted fills, gradients, drop shadows) are all very Mac like.
• I can link up the Keynote presentation and add animated actions to simulate the interactive behavior of the application.
• People who are not designers can participate in the design with me since it is intuitive to drag things around and make changes using Keynote

As an example, see the following two screenshots. The image on the left is the Keynote file I used to design the "T2" website. This was one of several possible designs that I can created. When I played the Keynote file, I could interact with the links and videos as if it was a real website. The image on the right a screen capture of the real website.

However, as well as the current process is working for me, I keep thinking about cinematic software, touch interfaces, animation, motion, and "No Limits Design". The technical barriers are falling for this kind of software. I'm concerned that prototyping tools that encourage page-by-page designs may limit creativity.

To that end, I have been experimenting with video as a prototyping tool as well as some motion graphics tools such as Apple's Motion.

Several months ago, I transformed the 3D Timeline idea that I had sketched into the following video using Apple's Motion:

I wanted to be able to test readability of the timeline at distances and get a sense for whether this would be a useful feature that helps solve the challenges of presenting timelines or if it was only eye candy.

...to be continued...

Feedback Requested on Timeline Presentation

As I plan future versions of Bee Docs' Timeline, it helps me to think of the foundational goals of the software. I like to think of the challenge of great charting software as being divided into two main problems...

First is the issue of allowing people to creating compelling charts in an intuitive fashion. Since I began the project back in 2004, solving problems related to creating timelines quickly and easily has been a core focus. Of course, there are still more improvements to be done in this area.

The other major challenge is the issue of presenting timelines to an audience. How can chronological events be presented in a way that makes the relationships between events clear, tells a story, and engages the audience?

I have begun to develop a framework for thinking about the different ways that timelines are presented. Basically, I have divided the presentation of timelines into four categories based on the way the intended audience is consuming the information:

• DESK - Each consumer is sitting in front of their own computer. The distance from screen to viewer can be measured in inches. They are controlling, managing, and interacting with the content on screen. They and typically using a laptop computer. Content is usually published to this audience using the web or e-mail.


• LECTURE HALL - Many people are viewing the same computer display at the same time. The display is usually projected on a screen and the distance from screen to viewer could be measured in feet or yards. The presenter is controlling the pace of the information and is likely to integrate other types of multimedia in the presentation.


• LIBRARY - I am using "Library" to represent timelines that are shared in printed reports or published materials such as books or magazines. Print media is high resolution and portable, but non-interactive. Timelines are usually just a subset of the information in a printed work and must conform to size and layout restrictions of the rest of the printed work.


• POCKET - Rich mobile devices such as the iPhone allow people to access timelines from anywhere at anytime. Audience members in this category want to access information quickly and simply.

Now, it's time for some good old fashion customer participation! I'm blogging all of this because I would appreciate your insight and feedback as people who create and share timelines. I would love to hear your answers to the following questions:

1. Who is the main audience for your own timelines? (For example: yourself, university students, business clients, etc...)
2. What do you want your audience to learn, understand, or take away from the information you are presenting? In other words, what does "success" look like?
3. How do you present your timelines today? Does it fit into one of my categories above?
4. In an ideal world, how would you present your timelines to your audience?
5. What other kinds of materials / information are you presenting along with your timelines?

I look forward to your answers. Feel free to use the comments so that everyone can discuss, or send me an e-mail if you are shy. Thanks!

Making Design Concept Displays

My friend Tony J, of Ratio Interactive and I were talking a while back about presenting User Interface designs to team members and clients. The de facto standard for presenting designs generated on a computer seems to be PowerPoint but Tony was explaining how his team has begun to use prints mounted on boards, even for draft designs being discussed internally. He feels that having a physical object helps people "respect the design."

I also like the idea of presenting designs in a physical media because it allows me to leave the designs around the office for people to walk by, point at, and discuss. It is also great to make displays of competitor products to compare and contrast. The non-linear browsing just doesn't work as well with PowerPoint.

I asked Tony what steps Ratio takes to prepare a design exhibit. This is what he said:

1. create designs (of course)
2. print designs on ink jet printer
3. obtain black matte board (8-ply is nice and "substantial" feeling)
4. cut a trim print outs to size (if need be)
5. cut matte board to size based on print outs to be mounted. Make sure to lightly pencil in your mounting marks (the corners) so you can easily place the printed piece after it's sprayed.
6. use Super 77 (from 3m) spray mount. (very permanent, no second chances. But the paper becomes 1 with the matte) Home Depot sells it very inexpensively.
7. In a well ventilated area (stair-well, covered outdoor area, or garage) we place the printed piece face down in a box and spray the back until it's covered like a light morning dew.
8. after you've sprayed the paper you have a minute or two to place it on the matte. Be careful to not let it touch the matte until you're ready to commit. I recommend starting with the corners on one side and placing that side edge between the corners. Then carefully stretch the paper across the matte taught and bring the opposite corners to their marks on the matte. This will give you the opportunity to slightly stretch and align as you go to make sure you hit the marks on the opposite corners.

This week, I make my own exhibit for a project I am consulting on. I used a slightly different technique. Here is what I did:

1. Took screenshots of popular web sites as well as my own designs and imported them into iPhoto.
2. I cropped them into a normal print size and used iPhoto to order the images as prints. I did a second batch at a local Costco using their "matte" finish prints and like the look even better. 5 x 7 size worked nicely for me. The nice thing about photo prints as opposed to doing them on an inkjet is that the quality is high, the is no expensive ink to run out, and there is no cropping required.
3. I used black foam core for my backing.
4. Instead of glue, I tried this Handi-Tak Reusable Adhesive stuff that I found. I cut it into small pieces, roll each piece into a ball, and put a little ball on each corner of the print. Then I press it on the board using gloves or a tissue to avoid finger prints. I like that the Handi-Tak makes the print hover off the backing by about an 1/8". It also is easy to remove and reposition, which is nice if I don't get them straight the first time or so that I can reuse the backing board.

All in all, it costs a few bucks and about 10-15 minutes to make one of these boards once you have the supplies. I'm a fan of this presentation method so far. Earlier this week I did a Keynote walk through of a mock-up design idea, but had a board with all the screenshots too so that people could compare it against previous slides for discussion.

If you are a presentor or a designer, what is your favorite method for presenting exhibits?

The Elegant Solution - Book Review

We satisfice. Satisfy plus suffice, which is to say good enough. It's a term economist and Nobel Laureate Herbert A. Simon coined in his 1957 Models of Man to describe the typical human decision-making process by which we go with the first option that offers an acceptable payoff. We'll take whatever seems to meet the bare minimum requirement to achieve the goal. Then we stop looking for the best way to solve the problem. That flies in the face of ingenuity and the pursuit of perfection. In the end, it's selfish, because the customer loses.

- The Elegant Solution: Toyota's Formula for Mastering Innovation

I just finished enjoying Matthew May's book on innovation and the pursuit of perfection. If you resonate with the quote I listed above, you will probably enjoy the book too.

Here are a few tidbits that made me think (in my own words):

• Discipline and Creativity are partners, not enemies.
• Force an elegant solution by using paradox in your design goals (for example, in next version of Bee Docs' Timeline, I am trying to find a design that adds more features, while making it even easier for beginners to use).
• Contrary to many urban legends, constant baby steps are almost always the path to breakthrough, not radical new ideas.
• Build tomorrow's solutions to today's problems. There are enough problems in the world, we don't need to build products or businesses that are built around future or speculative problems.
• True innovation leverages every single person in a company. Not just a design guru, or a visionary CEO.
• Reflection is necessary for learning, and is not well practiced in western cultures (or dot-com cultures I would add).

Good stuff, I say. Give it a read and use the comments to let me know what you think of the book.

Hand-Made Calling Cards

For a while, I have wanted "business cards" that are more casual than business cards. It seems that most of the people that I want to give cards to are folks that are a friend-of-a-friend folks that I meet in coffee shops, or family, or people I happen to line up next to at conferences.

These people don't care about my job title or my fax number! Nor do very many people in my corner of the world correspond via snail mail. What I want is a card that expresses something about the way I approach life, reminds folks of my name, and sends them to my blog if they want to find out more about me or my company. More "calling card" than "business card."

On a few separate occasions over the past weeks, colleages have said that I take an artisan approach to business. I like this and have been embracing my inner artisan, looking for ways to be non-corporate while focusing on quality and detail.

For the cards, I have decided to try rubber stamping them. I love the look of hand screen-printed posters and letterpress cards. I thought I might be able to get a similar look at a cheaper price using stamps.

I started by designing a layout in Apple's Keynote (my favorite quick-layout tool) and then refined the design in Adobe Illustrator. I wanted a design that could be different for every card, so it has two pieces, the bee from my logo and a block with my name and blog address.

I ordered rubber stamp versions of the design elements from Simon's Stamps. You can upload a high-resolution black and white image to their site and they'll send you a stamp in a few days. Pretty cool, and inexpensive too. The two stamps cost under $30 including shipping.

Currently I am working out the paper and color options. I bought a bunch of different single sheets from a neighborhood craft store as well as a few different colors of stamp pads. I haven't found the perfect combo yet, but I am getting close. Some of the papers that I like don't work well with the ink, the yellow is too light and the blue was a syrupy texture that didn't show enough detail to easily read the URL. Based on my experiments, I am going to go back to the store this evening and buy another round of supplies.

I'll post updates as I move toward the ultimate calling card!

Does "User Interface" Reveal Bias?

The following "thought of the day" is by Michael Dougherty (co-founder of Redfin among other things). Michael is perched in an office down the hall from me and we often share hallway conversation about the way the business works, and what products would be fun to bring to market, etc... He sent me the following in an e-mail this week, posted here with his permission:

Something that just occurred to me: the very term "user interface" subtly betrays the behind-the-scenes bias of most of us who use it. It conveys our unstated belief that the real heart of a software product is its technical machinery - the algorithms, architecture, storage, hardware - and not the person for whom it is built.

Software architects obsess about technical engineering design. Building architects, on the other hand, obsess primarily about creating functional, beautiful spaces for human beings. In fact they obsess about many things that they won't actually build: the site context, the light, the way the space should make its occupants feel. Technical design comes second.

Saying "user interface" is like saying "stage left" - it reveals the gulf between us and our users. As designers & creators of software, we should get off the stage and take our seat where we belong - down in the audience.

Maybe we should call it "the machine interface".

Quote of the Day

"As much as possible, allow users to do whatever they want at all times."

-- Apple Human Interface Guidelines, 2006-10-03

T2 Beta

Are you planning on doing a public beta for T2 by the way?

Good Question!

Let's start with some history... I got the idea for Bee Docs' Timeline from a Mac Lawyer discussion group that I was hanging out on about 2 or 3 years ago. I decided to take on the project, spent a few days drawing timelines in Adobe Illustrator and two weeks later, released my first beta of Bee Docs' Timeline.

For the first beta (which was an extremely rough version), I only invited people from the Mac Law discussion group to participate. They gave me their e-mail address if they wanted to join and each and every Friday I released a new and improved version to the beta group.

As the software reached my own milestones of stability and functionality I expanded the invitation to more and more people. Eventually I sent out press releases telling people about the beta. When the software was about a month away from its final release, I no longer required that people sign up for my e-mail list, instead anyone could download the beta from my website or sites like version tracker.

Bee Docs' Timeline was in pre-1.0 development for about 6 months and by the end of it I had several hundred people on the e-mail list and hundreds more who downloaded it without officially signing up. Each week's release generated dozens of e-mail suggestions and bug reports. The process was lots of fun and highly collaborative.

For T2, I also want to involve customers in the creation process but I want to try something new. One thing that is different is that I now know, based on hundreds of customer e-mails, phone calls and blogs, what people as a whole would like to do with Bee Docs' Timeline that they can't do now. I also know which of those things I am going to tackle in T2. The trick to T2 is going to be how to provide the new functionality while increasing ease of use, which everyone wants but nobody every asks for (especially those who try the demo and don't end up buying).

I'm also dividing my time differently with T2. Instead of doing design, development, and testing on a weekly iteration, I am slowing the cycle down. I am doing most of the design up front this time. This allows me to focus on the integration between all the new features. It also gives Apple time to stabilize Leopard before I get too deep in coding. It may also allow me to hire outside help for some aspects of the development.

Consider this blog the first part of the process. I'm tossing out ideas here about basic design, features, pricing structure, beta, icons, etc... The reason I am doing that is so that I can get feedback.

I'm a little concerned about other developers copying my design ideas, so I'm being a guarded about some of the design specifics. I'd rather be completely open, even to a very detailed level. So, I'm thinking of starting a separate private blog that I could invite select customers to join and provide design feedback. It wouldn't be for people to tell me everything they've always wanted but rather for things like "Out of these two alternatives, which do you think would be the easiest method to add a new event" or "In which menu would you expect to find the event import feature?" The private blog would be invite only and I would want those invited to commit to regular participation, not just lurking to see what's coming.

After the design is complete. I'll spend a month or two (or three) implementing the design. As soon as it is stable (ie, won't screw up your data or your computer), I'll release it for other folks to try. Probably the private blog readers first and then expanding the circle of users like I did in the 1.0 beta. There will likely be a month or two of polishing the application while there is a public beta before the commercial release. There will likely also be some polishing after the public release in the form of point releases too.

To the readers of this blog, please let me know what you think of this plan. If you agree that this is a good strategy, I'll work out a process for choosing the "design team" participants and get it set up right away.

"No Limits" Design

My wife likes the quote "What would you attempt if you knew you could not fail?" It is a very interesting thought to ponder...

My buddy and sometimes collaborator Tony J, of Ratio Interactive, and I were chatting about a similar concept in software design. How would you want your software to work if there were no limits?

What if the screen was of unlimited size and resolution? What if all the features of the physical world could be implemented in software (weight, texture, temperature, sound, small, etc...)? What if all you had to do to create a software application was to imagine it?

However, getting away from my office and imaging software with no limits is a great exercise for me. It turns out that many things already are possible, but those of us who are software developers and software users tend to have minds that are clouded by the typical instead of clearly focussed on the desired.

Inmates are Running the Asylum

An associate from Exbiblio loaned me this book a few weeks ago. I've been doing a lot of thinking about project management and design processes lately, so it was an appropriate read.

The main theme in the book is that engineers should focus on implementation and leave design to product designers. Alan Cooper makes some valid points but seems like he has a big chip on his shoulder. Of course, I do both engineering and design frequently. In fact, for Bee Documents, I am also in charge of marketing, keeping the books, and customer support too.

In any case, I don't have the luxury of giving these tasks to specialists at this point. I do agree with Alan Cooper though, that it is best to keep design and engineering separated. For example, I try to do most UI design away from the computer, preferably outdoors with a sketch pad or in a completely non-technical environment. Design and Engineering are simply different ways of thinking and it is nice to be in one mode or the other. When I'm designing I'm looking for the "best" way to do something and when I am implementing, I'm looking for the "most efficient" way.

The book starts to get good when Alan begins to discuss design techniques including the use of personas. A persona is an imaginary person that represents a typical user of the product. I first encountered the idea of personas about a year ago and thought they were lots of fun and useful. Alan Cooper does a great job of explaining the personas and I have recommended this book to several folks already for the persona chapter alone.

I have developed three personas so far for T2. They include a high school teacher who teaches American Literature, a malpractice attorney from New York who loves gadgets, and a student from India who is attending the University of Chicago and studying Anthropology.

Each of my persona has an age, a photo, likes and dislikes, etc... They are very much based on real people and what I have learned from my current customers. In fact, the photos I am using are a real Lit Teacher, malpractice attorney, and student that I found on the internet.

When faced with design decisions such as whether or not to include a certain feature, I can "ask" my personas whether they would value such a feature. If my personas don't like something about the software than it has to change! They haven't argued with each other yet, but if they do, I will have to do my best negotiate a compromise.

What was that about an Asylum...?

Designing Discover - Part 4

In the last "Designing Discover" entry, I wrote about how I developed a document-centric user interface for our Bee Docs' Discover software and how we refined the interface by carefully considering the position of each element and by reducing clutter. The next design problem to solve was the use of color. Beyond everything else, we wanted the color to contribute to the users navigation of the documents. Of course, we also wanted it to look "good", but a useful design often ends up looking good automatically.

A primary color goal was for the software to feel very comfortable and nature based, not high tech. Our logo has a graphic of bee which has a little yellow on it, so I wanted the document management interface to feel like a field of yellowish green grasses that a Bee might land on. I also made the decision to be very stingy with the colors white and black. We would reserve these colors for items that require the users center of attention.

After I had a basic philosophy for the color palette, it was time to get out the Pantone Chips. I always like to pick colors away from my computer, preferably outdoors. Especially when selecting a natural palette, it is best to be influenced by the colors of nature, and not the colors of technology. Of course, I always check the colors on the multiple computer monitors before making a final decision, but I like to start with the pantone chips in a natural environment.

We picked a palette that included a handful of related colors, with a color for each function. White was reserved for documents or important text fields, black was reserved for the most important text, which in most cases is text related to the current document. There are several natural greens and tans including: a color for the background, a color for user interface elements that can be clicked, one for user interface elements that can't be clicked, a color for static elements such as lines and boxes. All of the colors are very similar because this provides a harmonious look. It also leaves the high contrast colors to the documents themselves which are the star of the show. In a similar way, we avoided using square rectangles in the interface except for the document pages. All the other buttons and boxes have rounded corners.

After all the colors were chosen from the pantone chips, I applied the colors to the interface, made some final tweaks, and it's done. The screenshot above shows the final color selection. If you want to see the interface in action, give Bee Docs' Discover a spin with the on-line demo account.