Designing Discover - Part 4
Friday, May 27, 2005
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.
Labels: design, discover, document management
Number Stamper Released
Thursday, May 26, 2005
Today I released a new Macintosh software product which is an Automator Action for creating electronic bates numbering for PDF files. Its called Number Stamper 1.0.
In the past, we have made several other Automator Actions available for free. This will be my first attempt at selling an Action. It is significantly less expensive than other bates number programs, so we'll see how it sells.
If you are using Mac OS X 10.4 (Tiger) please download it and let me know what you think.
Labels: automator, bates numbering, mac software, number stamper
Marketing Bee Documents - Measuring Success
Wednesday, May 25, 2005
Bee Docs' Web Stats Graph
I'd like to share some of my experiences marketing Bee Documents and our products. One of the first things I did when I founded Bee Documents was define the metrics by which I would measure my marketing effectiveness. Here are some of the things that I track over time.
- Sales Revenue - Of course the most important measurement of marketing effectiveness! Several years of working with an accountant has taught me the power of a monthly profit and loss statement.
- E-mail and phone communications - I also track and chart the number of phone calls and e-mails that I receive requesting information on our products.
- Google Ranking - Besides referrals, most of our new customers find us on Google. We use Google's web service API to daily track and chart our position in the search results of 10 keywords that are important to us. On some future date, I'll show you how we track this metric.
- Web Traffic - We really work hard to make our web site interesting, relevant, and up-to-date. The amount of traffic coming to our web site is a good way to see how many people out there are getting our message.
- Press and Blog Mentions - The best advertising is the kind that other people do for you! Google and Technorati both have tools for tracking what other sites are linking to our site.
By establishing good tracking methods for these metrics, we are able to judge the success of various marketing efforts. For example, is it better for us to pay for print ads or is it more effective to give away free software? While, I have certainly made mistakes over the first three years of running Bee Documents, having solid measurements allows me to avoid repeating expensive mistakes and refine our marketing strategy as we grow.
Labels: beedocs, marketing, statistics
Designing Discover - Part 3
Monday, May 23, 2005Previously, I discussed the redesign of my document management software from a table-centric design that was easy to program to a document-centric design that is easier for users.
What I liked about the redesign was that the most important thing, the document, was now in the center of the screen. We also give some context to the document by showing its position in the organizational hierarchy (for example, it came from a binder that was in the box labeled "2003"). Also, by using the page browsing metaphor, a customer does not need to add coding data in order to start working with their documents.
The next step was to create a computer rendering of the design. This image was created with various Adobe tools and gave me a more realistic look at the proportions and layout that I would use. The design shown here had several faults. For example, displaying the document groups at the top of the screen limited the amount of room to display pages, most of which are in a portrait orientation. I also wanted to fit thumbnails of the pages across the bottom of the screen and did not want the users to have to use a scroll-bar in order to view the whole user interface. Also, this interface had a lot of boxes which make it harder for the eye to quickly identify the document which is also a rectangle.
Here is the next revision. You can see that I eliminated the boxes around the comments and page information as well as the box around the documents. I also moved the document groups to the right side and added the thumbnails to the bottom of the page. I also worked entirely in grayscale at this point as I wanted to approach color as its own user interface element and did not want to get used to anything yet.
Next blog, I will talk about the all important color selection process.
Labels: design, discover, document management
Designing Discover - Part 2
Wednesday, May 18, 2005
There are several problem with the table-based user interface show in my last entry:
- If scanned documents do not have any coding data associated with them, the table view is worthless
- The original context of a document (where it falls in the stack, how it is bound, etc) creates meaning for its reader and is lost in the table interface
- In a table-based design, the image of the document is so small as to be unusable.
After thinking about the table based interface for a few days, I decided that I should either scrap the whole project or come up with something much better.
I started over from scratch, this time with a pen and paper instead of sitting in front of a computer. I drew a design that restored the document image to center stage and displayed its original context using a row of graphical icons at the top of the page. The document data, which used to be the primary way to find a document, is now sent over to the left side of the screen. I also wanted to create use thumbnails at the bottom of the screen to give the user an idea of what pages come immediately before and after the current page.
I was much happier with this design as it would more closely match the physical way of handling documents and has a more more document influenced design rather than a database influenced design. However, implementing this radical new design brought new design challenges and technical issues to the project. I'll show you the next phase tomorrow.
Labels: design, discover, document management
Designing Discover - Part 1
Three years ago, I was working on an insurance dispute involving several thousand pages of documents. I spent several weeks sorting, labeling, and duplicating invoices as well as recording the vital information from the invoice into an Excel spreadsheet. The work was tedious for me and expensive to the client (because it took so much time).
Of course, I had heard about the promise of a paperless office which I had never really paid attention to, but the concept was now starting to sound really good. Unfortunately, I couldn't find any software products that made economic sense for a managing few boxes of documents and that were less trouble to set up then doing the work by hand. To make a long story short, I quit my job, formed a new company, and locked myself in an office for two years to create such a program.
I decided to build a hosted solution, meaning that I would host the software, database, and scanned documents on my secure web servers and customers would access their documents and related tools through their web browser. Providing a hosted solution meant that I could get customers up in running in a very short amount of time. It also meant that smaller customers could get started for a much lower price than if I was selling "shrink-wrap" software to them.
My first design of the document browser interface is shown in this screenshot (click it for a larger version). This user interface is pretty typical of database centric software. The pages are displayed in rows with the associated data in columns. The boxes on the left allow users to "filter" the results by building database queries. However common this interface is, it isn't a very good one for documents.
Tomorrow, I'll share the next revision of my interface design. Until then, think about the following question:
Why isn't a table based interface user friendly for managing scanned documents?
Labels: design, discover, document management
Tuesday, May 17, 2005
As an inventor of legal technologies, I have lurked on a lot of law-related newsgroups and mailing lists in order to keep my ear to the ground for technology needs. I have to say that best group I have found so far is the MacLaw mailing list. This group is very active and the members are tech-savy, entertaining, and friendly to new Mac users.
In fact, it was a conversation on MacLaw that inspired me to create Bee Docs' Timeline as well as some other new products that I have yet to announce.
If you are a lawyer interested in using Macs, a creator of Mac products, or simply a Mac user looking for good friendly technical advice, you should sign up for the mailing list today.
Monday, May 16, 2005
I'm writing this entry from the Jury waiting room at the King County Superior Court Regional Justice Center. We just listened to a speech on the importance of Jury Duty to Thomas Jefferson and now we sit and wait...
If I end up on a jury, it will be interesting to see how technology is used in the courtroom and how it affects the trial from my perspective as a juror.
While I wait, I am also sketching out a series of blog entries on the design of Bee Documents' document management software. I thought it would be fun to show some of my initial design sketches and talk about how it evolved to its current form. Stay tuned!
Saturday, May 14, 2005The Elements of Typographic Style by Robert Bringhurst How could a book on typesetting be one the best books that I have ever read? Robert Bringhurst takes the most humble of crafts into the realm of high art and poetry. There is plenty of practical advice you can use every day on subjects like reducing unnecessary spaces and punctuation. However, the book really gets fun when Bringhurst starts talking about forming page ratios based on musical frequencies. His passion in contagious and the book itself is beautiful. More than anything, this book expresses great joy in detail. Like peering through a microscope for the first time, this book opened up new worlds for me that have been there all the time, but that I never noticed before. It is a book that I've read multiple times from cover to cover since I discovered it a year ago and have on constant loan when I'm not reading it myself. Pick up a copythen share your thoughts in a comment.
Weekly Shout Outs:timeline software in your blogs!
Labels: book review, shout outs, typography
Software Design Tutorials
Friday, May 13, 2005This morning I posted two new software design tutorials to the Bee Documents web site. I originally wrote them for the MacDevCenter section of O'Reilly Network. If you are interested in enterprise development for the Macintosh, you should check them out. Enterprise Software Design Series:
Article 1, Applying "Digital Hub" to Enterprise Software Design
Article 2, Designing the Database
Article 2, SQL Code Addendum
Article 3, Designing the XML
Article 4, XML Data Transfer with WebObjects
Article 5, Creating a Data Entry Tool With Cocoa
Article 6, Web Services and Informative Data Display Easy code documentation with Xcode
Inspired by Nature
Thursday, May 12, 2005
Here is a photo that I took yesterday of a flower in my yard. When ever I get stuck on a design or technical problem, I often try to get outside and away from technology for a little while. It is amazing how nature is full of elegant examples to design problems.
That is one of the reasons that I chose "Bee" for the name of my company instead of "info-digi-doc-tech-sci.com" or something like that.
For example: When you think about "documents," what comes to mind? For me, it is fluorescent lights, paper cuts, messy desks, and 3-ring binders that rip the paper because the rings don't line up exactly. The goal of our company is to change the way that information is managed from these very cumbersome and artificial means to something much more natural, elegant, and simple. Instead of digging through file cabinets looking for a lost receipt, imagine yourself a bee, hovering over a field of wildflowers, looking for a flower to pollinate.
Though it is much easier said then done, I think software developers in general can do a better job at elegance. Rather than copying each others bad designs, we can look to the way complex information and functions are organized in nature. I'm not just speaking about user interface design either. All the parts users can not see- classes, functions, data, code... can be beautiful too.
This week was an exciting week for us. We released our timeline software that we have been working on for the past 6 months. It is always fun to send out press releases, watch the web hits spike, and make a little money.
I am using Apple's Mail client that ships with Tiger (Apple's new OS) and I've got a "smart folder" set up so that I can see new orders as they come in. Getting e-mail feedback and props on people's blogs is great, but we take it as a biggest complement each time someone pays us their hard earned cash for one of our products.
If you are a Mac user and haven't checked it out yet, download the free trial and see what you think.