Making a Web App: Part 13 – Designing for Speed

Common application design goals are:

• Stickiness: To encourage people to stay as long as possible.
• Personality: To set a mood or personality such as friendly, exciting, young, bold, or reliable.
• Buzz: To get people to share the site with others.

For PlaybookIQ, most of these design goals are important, yet I do not have any of them as the primary design goal. For Playbook, I have one design goal:

• Speed. How fast can people enter, find, read, and update information. How fast can they get in, get the information they need, and get on with their real work.

The faster, the better. The application’s personality, stickiness, buzz, and revenue drivers will come from the application’s website. The application itself is designed for speed.

Here’s where the other design goals fall.

Stickiness: great for the product site, ok for the product. In a business app, people want to be “in” the app as little as possible. They have a job to do, a business to run. It is not their job to be using the application. In most cases, their business is not the app.

Personality: great for the product site, also important for the product. People want to have an enjoyable experience in any application, business or consumer. But for this application, I do not make design decisions based on trying to create a personality for it: other than the trait of “fast”.

Buzz: great for the product site, ok for the product. If the product does what businesses need it to do, and does it well, it will generate buzz. Again, I don’t let yearning for buzz get in the way of what people really need in the day-to-day use of the app. I don’t add a slick feature or integrate with a product just to get press. That buzz from that feature will eventually wear off, but we’ll be left to support it forever.

What Makes for Speed?

So, speed is the primary design goal, but what does that mean for the app? Here are a few thoughts that came to mind when building Playbook.

Show more fields by default:

It is a popular design decision to hide fields until they are needed. This makes for a clean look and less clutter. While less clutter initially makes for a more efficient form, the extra clicks necessary to “show more fields”, for example, slow down the use of the product.

Focus

Always through focus to the first field on the form to that someone entering new information can simply open the form and type.

Color and Contrast:

Generally, the higher the contrast, the quicker the read.

Position:

In a previous post, I’ve already talked about little things like persistent search box and the position of elements. For example, people need sign-posts and context to efficiently navigate and understand information.

English language readers scan from top left to bottom right. So, the most commonly sought information should be at the top left. Less commonly used information, or sections of the screen that do not change often, should be to the right and bottom.

For example, when someone opens up an Opportunity sheet in Playbook, I do not want them to have to glance past the “New”, “Edit”, “Add Person”, “Add Comment”, “Add Task” and other buttons to get to the information they seek. The goal is to imagine someone scanning from top-left to bottom-right and get everything out of the way. Because these buttons are there in the same place every time someone opens that screen, they will easily find them if needed. They do not need to be reminded of them each and every time they want to look up notes on an Opportunity. So, supporting information and navigation items having to do with this opportunity, go to the right of the opportunity detail sheet.

There is one exception to this guideline – context and sign-posts.

Context and Sign-Posts:

The importance of context and sign-posts trump the importance of placing commonly sought information to the top left. For example, persistent navigation tabs should be above the detailed information being presented. The app’s name or the current screen is commonly found at the top. This is not typically information someone is seeking, yet to provide context (e.g. you are in ABC app, at the “Add a widget” screen), it is important to show it.

Because people think of things that are under and to the right of something as being “within” or a “subset” of things above and to the left of them, context indicators and sign-posts should be at the top and left.

For each screen, I like to think of someone scanning it from top left to bottom right.

Switching Gears

After spending too much time playing around with different fonts, color combinations, and field and button placement to get a good “look”, I decided to switch gears and read empirical research on what layouts provide the fastest user experience.

While there is no definitive evidence for color and font selection for web applications, there are many studies. I’ve taken the results of those into account in a new design for PlaybookIQ.

For this reason, the resulting product screens are different than what I have been previewing here. Just how different will be revealed when the product is ready for beta testers.

Apple or Dell 30″ Monitor (subtitled: how the new iMac validates my Dell Decision)

I have been looking at 30” monitors for some time. I feel constrained on the 19” monitor I use and get easily excited by those that report productivity improvements on 30” monitors (even if the productivity benefits are dubious, it can’t hurt).

Black or Silver?

In reading reviews of the two monitors, several reviewers point out the beautiful looks of the Cinema display. Especially important to Apple fans seems to be the silver casing instead of Dell’s black. It’s just a matter of personal taste though, and personally – I like a black case. In my environment, a black case better disappears into the background.

Yet as I kept reading reviews, I started to wonder if something was wrong with me for preferring a black border over silver. Then, at just about that time, Apple rolls out the new iMac and – what do you know – its screen is encased in a black border. Not that I needed Apple’s validation, but at least I know I’m not crazy for thinking a black border is a good idea. Now I feel better about buying the Dell. Even without an anodized aluminum case.

The one place I would recommend the Cinema display is in an area that presents an image to customers or clients or that you simply want to look sharp from the back. I use it alone in my office, so I only look at the front and no one ever sees the back. From the back, where visitors or co-workers would see it in an open environment or reception area, the Cinema display looks more professional.

Decision

I love Apple, love my MacBook Pro and OS X. I couldn’t imagine having to go back to PC and Windows. But little appeals to me about the Cinema display. Dell has as good or better specs (higher contrast and nominally faster response time), 3x the warranty, and many happy users. And, as a bonus, is at least $300US less.

I hate to say it, because I am a Mac fan. I love hanging out at the Apple store and can no longer stand to go to any other “computer” store or electronic big-box. So I do reward Apple with my pocketbook on their other innovative and beautiful products. I just don’t see them getting it for this monitor purchase.

The Dell 30” monitor is ordered and I’ll let you know how it works out.

Details

For the detail inclined, here are comparison of current specs:

Apple M9179LL/A

Viewing angle: 178° horizontal; 178° vertical

Brightness: 400 cd/m2

Contrast: 700:1

Response time: 14ms

Pixel pitch: .250mm

Case: anodized aluminum – silver

Warranty: 1 year

Price: $1,799.00 US

Cinema Display product page

Dell 3007WFP-HC

Viewing angle: 178° horizontal; 178° vertical

Brightness: 300cd/m2

Contrast: 1000:1

Response time: 12ms

Pixel pitch: .2505mm

Case: plastic – black

Warranty: 3 years

Price: $1,499 from Dell or $1,388 at Sam’s Club

Dell Monitor product page

Making of a Web App: Interlude – Importance of a Blog

In Startup Marketing: Big Bang vs. Darwinian Evolution, Dharmesh Shah highlights the importance of getting feedback early in a Darwinian evolution approach compared to the “stealth mode” approach with a big-bang launch. His insights are well stated and recommended reading to show the design and development of a new product should be accompanied by, or even preceded by, a regularly updated blog that reaches your intended audience. I recommend you read it, and if starting a new product, create and regularly update a blog about the product.

Making of a Web App is Synap Software’s blog about our upcoming web-based sales team collaboration app.

Making of a Web App: Part 12 – Payment Processing

Most of the Making of a Web App series follows a typical path from idea to implementation. In that path, payment processing and subscription management is one of the last items to be implemented. There is no reason to do it now for PlaybookIQ except that we need subscription (i.e. automatic recurring payment) capability for another project so I deployed it today.

For the technically inclined, here are some notes from that experience.

To implement credit card processing you need a merchant account, a payment gateway, and a secure website for collecting billing details. It can take some time to compare the merchant account and gateway options available to find the ones that are right for you. And the paperwork and setup tasks with your selected merchant account provider and payment gateway vendor can take several days, so keep that in mind when planning a project.

For these components we used our local bank, TrustCommerce, and Ruby on Rails respectively.

A Personal Relationship with Our Local Bank

When you have a good, existing relationship with a vendor I think it is important to continue with it. It is important to have someone to sit down with in person if you need help straightening out payment transactions. So we choose our local bank of ten years to provide our merchant account. They offer competitive rates and were knowledgeable and helpful in getting us set up with our payment gateway.

TrustCommerce.com

TrustCommerce is our payment gateway. Like our local bank, they are knowledgeable and offer competitive rates. They have an extensive open-source API library and good documentation. By connecting through their TCLink API we get the benefit of a failover system offers “virtually” 100% reliability (e.g. it has no single point of failure). Finally, they maintain the credit card information for recurring billing so we never retain credit card numbers on our servers. Instead, they create a six digit billing ID and that billing ID is our reference to the credit card details.

Ruby on Rails TrustCommerce Subscription Plugin

Here is Zack Chandler’s blog entry when he released the plug-in in October, 2006. Following the steps in that post and in the plugin itself, I was able to run the tests Zack included shortly after starting. When fully configured, the plugin makes easy to understand code like this possible:

#Create a $12.00 monthly subscription for Jennifer Smith
response = TrustCommerceGateway::Subscription.create(
  :cc =>        '4111111111111111',
  :exp =>       '0412',
  :name =>      'Jennifer Smith',
  :amount =>    1200,
  :cycle =>     '1m',
  :demo =>      'y'
)

if response['status'] == 'approved'
  puts "Customer profile created with
     Billing ID: #{response['billingid']}"
else
  puts "An error occurred: #{response['error']}"
end

The Devil’s in the Details

Though the plugin is great, don’t let it fool you into thinking that implementing the code around the plugin is easy. You still need to build the code to create and manage TrustCommerceGateway::Subscription objects, all the while ensuring everything is done under cover of SSL and with consideration for several other security issues. For example, don’t forget to include:

filter_parameter_logging :cc

in your controllers to ensure credit card numbers do not get written out to the logs.

As is usually the case with programming, implementation of the blue-sky-all-is-approved case was the easy part. Wanting to ensure all types of responses from the payment gateway were handled properly (and being hooked on TDD) I spent much more time writing and running tests than I did writing models, views, or controllers.

Questions?

Unlike with the Deprec setup, I did not write detailed notes. Yet, if you are a Rails programmer implementing the TrustCommerce Subscription Plugin and have any questions, send me an email and I’ll be happy to try to help out.

Purposefully Limit Subscriber Count: Could This Work?

In “The Innovator’s Dilemma”, _ says that one reason companies loose their leadership position to disruptive competitors is that the established companies base their product designs and strategies on the needs or current customers and existing markets. Disruptive competitors, meanwhile, don’t have long-standing relationships with existing customers upon which to base their decisions and are often going after non-existent markets that cannot be analyzed at any rate.

His is sound advice: if your company is simply an order taker from existing customers, you likely will not be tomorrow’s leader in the marketplace.

Make sense so far? While it does to me too, I find that personally it is much more enjoyable to have ongoing conversations with people and to see their joy in a product when their ideas and feedback are quickly implemented. While there are those that say it may not be the best competitive strategy, it is the best approach for me because one has to enjoy their work to be good at it. I enjoy that continuous cycle of discussion, product enhancements and feedback with people.

So, for PlaybookIQ, I’m considering ignoring that prevailing wisdom and instead going the opposite extreme: limit the number of people using the application so that everyone’s voice is heard.

Why Limit Subscribers?

50% of Revenue from 11% of Customers

SaaS providers offer a wide range of subscription offers in order to appeal to as many people as possible. Yet, look at this breakout of number of users per plan from Ryan Carson. He reports that “50% of our revenue comes from only 11% of our customers”. Now, that other 50% from 89% of the customers is nothing to ignore in the long run. But if one purposefully wanted to start slow and small, to ensure the people who do subscribe are as satisfied as possible, then it makes sense to start with those 11% of customers that bring in half the revenue. Ryan stated the case well: ”$5 plans are a lot of hard work, for very little money.”

Homogeneity

So, offering just one price plan will naturally limit customers anyway. Why not present the limited price point choices as an advantage for people that do sign up. I would offer just one pricing plan in order drive toward a more homogenous user base so that say, the feedback and requests of a “one user” subscriber would not compete with those of someone leading a team of twenty. With one price-point, the product and product roadmap are more likely to satisfy their expectations than that of an application aimed at a broader audience.

Salesforce has over 32,000 customers, Freshbooks has over 190,000 users, Basecamp has over 1 million users, and 37signals has over 6,000 registered users on their forum alone. How would one person’s voice filter through that of 32,000, 190,000 or 1,000,000? A limited subscriber base keeps the conversation manageable.

Can It Work? Has it Been Done? Is it a Stupid Idea?

What do you think?

Making of a Web App: Part 10 – UI Evolution and Screenshots on Flickr

Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article I share one iteration of an evolution of web application design layouts for PlaybookIQ.

I set up a flickr photostream to show screenshots as they evolved. Read the rest of this blog entry first, and then go check it out.

Key points of visual design for web applications stated as expectations from people using your application:

• Proximity: items near each other are related to each other..
• Relative size: larger elements are more important.
• Relative position: elements to the top and left are more important. Elements to the bottom and right are subsets of ‘parent’ elements above and to the left of them.
• Consistency: consistent fonts and colors make an application feel more reliable and well constructed.
• Inconsistency: an occasional inconsistency should mean that something is important or needed to be called out for some reason (e.g. red text when all other is black).
• Persistent elements like ‘home’ or ‘search’ provide confidence to roam around knowing they can always get back to familiar territory.
• Sign posts: let people know where in the app they are.
• Alignment: an application in which elements line up neatly vertically and horizontally feels more professional, is more trustworthy, and easier to use.
• Whitespace is easily understood as way to separate elements that are not directly related, while a line, shading or other elements must be processed by people scanning a page.
• Context is critical. Metaphors like tabs, sign posts, and grouping help people understand what to expect at a given point in the app and helps people focus on one thing at a time.
• Choice is painful and slow. People simply want to get something done. People do not want to be asked to perform the work of making choices. Keep navigation and activity choices to a minimum.

Refreshing But Professional

In a B2B app such as PlaybookIQ, my design goal is to offer a refreshing, yet still professional experience. I do not want to get too innovative or revolutionary and design and development time to create a wow factor could be better spent on additional features that make people’s professional lives more productive. So, you should expect to see common design decisions here.

A Case Study

This series could be subtitled ‘A “Designing the Obvious” case study’ because it follows along with suggestions made by Robert Hoekman Jr. in his book. Click here for details on the book and here for his blog. [Full disclosure: when I write reviews or references to books, I usually link using my Amazon affiliate link. If you do not want to visit my affiliate link, simply do not click the links in my blog to books and instead search for the book directly at Amazon or your favorite source. Note that so far in this series I’ve made a whopping $5.15 from this practice – early retirement, here I come! ]

Screenshots on Flickr

For the rest of this blog entry, I have set up a flickr photostream with a description on each photo in that outlines the thought process behind the incremental change from screen shot to screen shot. I put the screenshots on flickr because I like the way you can page through them and it is easy then to pick out the changes from screen to screen. If I just listed them here, readers would be scrolling up and down to compare one screen shot to the next.

Click here for the photo stream. You can leave comments on this blog entry or on flickr.

Making of a Web App: Part 11 – Reduce and Refine the UI

Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article I show an example of reducing and refining an interface.

Reduce to:

• Make it easier for people using the application.
• Remove unneccessary clutter.
• Expose the level of development work required.
• Are the easiest way to iterate, collaborate and communicate.

Use Cases

Business of Software Conference 2007

It’s an impressive speaker line up at the Business of Software Conference, October 29th and 30th in San Jose. Scheduled to speak: Guy Kawasaki, Joel Spolsky, Eric Sink, Rick Chapman, Bill Buxton, Jeffrey Pfeffer, Hugh MacLeod, Dan Nunan, Tim Lister, Jennifer Aaker and others to be announced.

In the words of organizer Neil Davidson:In October 1999 Simon Galbraith and I [Neil] set up Red Gate Software. Over the past 8 years we’ve grown from 2 people to almost 100. Although we have had our successes, we’ve also made plenty of mistakes. The people who I’ve invited to speak at Business of Software 2007 are world-class thinkers, doers, writers and speakers who I wish I’d heard of earlier, and listened to more. I’m hoping that by bringing them together in one place, over two days, we will all learn how to set up, grow and run our businesses better.

Sign up for their mailing list here and you’ll get a free 319 page e-book:Eric Sink’s ‘Business of Software’.

Is Anyone Else Seeing Duplicates?

I’m asking for some help. If you can help me troubleshoot this, please respond in the comments section of this post.

Is anyone else seeing my blog posts duplicated in their reader? Has it been going on for a while? What reader are you using? Have you ever experienced this on your blog and what was the cause?

Thanks! And I apologize for the clutter.

Why a Big Budget Will Kill Your Software Project

Money, get away.

Get a good job with good pay and you’re okay.

Money, its a gas.

Grab that cash with both hands and make a stash.

New car, caviar, four star daydream, Think I’ll buy me a football team.

Everyone, sing it with me:

New box, database, VP daydream, Think I’ll buy me an IT team.

Money

In Making of a Web App I said that new software projects should simplify scope for increased likelyhood of success, greater end-user satisfaction, and key stakeholders who get what they need instead of a version diluted by dozens of others’ desires.

Yet, on large projects with dozens of stakeholders – such as is common on corporate IT efforts – it’s impossible to effectively reduce and simplify. There are decades of project management best practices and strategies for helping large, complex projects succeed. This post is a warning to those new to the industry and new to corporate IT efforts: don’t try reduce and simplify at your office. It won’t work. And here’s why.

Follow the Money

It all starts with the money. Everyone wants to have big budget projects, because:

• They never know what the next budget cycle looks like, so will go after what they can now.
• “Use it or lose it.”
• Empire builders.
• Large budget must = “Important project that cannot be cut”.

More Money = More Stakeholders = No Way to Simplify

Then, when project get the big budget and the staff they desired; the scope grows, more people latch onto the effort and it becomes impossible to say “no – we’re keeping it simple”. Projects are then left trying to make everyone happy. And you know that those that try to make everyone happy usually end up making no one happy. That’s just the nature of life.

The Alternative

Happily take the small budget, quick-win projects and build a raving fan-base of people that love what you do and actually like the software you deliver.

Lower budgets equal lower profiles. A low profile is not good for advancement-by-politics, but can mean less people looking over your shoulder which means more freedom to focus on the people using the systems you build. Without everyone in the company jumping on your gravy train, you can focus on the business needs of one or two key stakeholders and can quickly gain happy users that have come to expect corporate IT projects to take a long time, cost a lot of money, and only partially represent their real business needs.

Your newly estatic community of people that use your software will do what it takes to keep you and your team around through good times and bad. You will have an advocate outside of the IT department. And in corporate politics, any cross-departmental advocate is a good thing to have.

To those with grand plans of enterprise domination, let me ask that you think carefully before jumping into those choppy seas because maybe, just maybe the small, focussed projects are the place to be.

Sing It Brother!

New start, raving fans, it’s my daydream, Think I’ll like my new small team….it’s a gas…