Design of the Status Site

A couple months ago, we launched a completely redesigned Heroku status site. Since design is important to us and, we think, to many of you, we're taking a break from our usual blog posts to dig into the Heroku approach to visual product design.

Read on to experience the twists and turns on the way to the final design and let us know in the comments if you want to see more posts like this.

Old Status Site New Status Site

The Premise

For platform providers, a status site is a way to build trust with your customers, and in some cases, future customers. Heroku is no different. Our existing status site hadn't been updated in over two years and was showing its age. We took this as an opportunity to go back to basics; drafting up user personas and goals. The previous status site was designed around the persona of a Heroku user checking to see if Heroku is working this very second. We realized there is an equally important persona — a user or prospect trying to understand how reliable the platform is.

Of the many things we could improve, we focused on three primary areas:

  • Status is as much about uptime as it is downtime.

  • We wanted to increase transparency.

  • We needed to streamline the admin experience (which we won't show here).

When it came time to start visual designs, we did some research to get a sense of existing solutions and user expectations. After some intensive brainstorming, we came up with the idea of a timeline.

A timeline felt like the perfect device for what we were trying to achieve. Not only does it show downtime and uptime in proportion to one another, but it includes a really key piece of information: time to resolution.

Prototype

It started as just a hypothesis, and we needed to test that hypothesis with real customers as quickly as possible. It's easy to get tied down by visual design and lose focus on what really matters: the product. Instead of spending a lot of time in an image editor like Photoshop making the page look beautiful, we wanted a working prototype with real data from the get-go. Setting aside visual design and best practices, we created a simple Sinatra application using spaghetti code and inline styles, with read-only access to a live database:

First Prototype

We tested the first pass with our customer advisory board by inviting them to do a 5-minute OpenHallway user study. It was important to set the right expectations (and context) for this survey:

This prototype is not representative of final visuals.

OpenHallway allowed us to capture the screen and audio of our testers and follow alongside them as they explored the site. Incidentally, our first tests had way too many questions and instructions. Eventually we converged on five simple questions:

  • What are your first impressions?
  • Is it clear what the page is about?
  • Does it quickly convey the current platform status?
  • Does the page increase or decrease your trust in Heroku?
  • How does this site compare to the old status site?

We also added keyboard shortcuts so our testers could simulate outages and scheduled maintenance ('o' and 'm' if you want to follow along).

Mobile

When we reviewed the OpenHallway videos, we noticed a concerning trend; several people commented that there was "too much whitespace". We knew we had taken a risky approach with the timeline and wanted to make sure we weren't committing too early to a design and ignoring actual user needs, so we (incorrectly) interpreted this to mean that the timeline wasn't working.

In an effort to clear ourselves from an arbitrary commitment, we took a step back. Simplify the constraints. Think mobile. We asked ourselves what the status site would look like if we only had 320x480 pixels.

Mobile Prototype

Responsive

Following this promising direction, we created a fully-responsive version that would work for iPhones, iPads, and desktops. We added a little more information in this version; and even more information as you increased screen real estate. But in all these versions, the timeline was gone.

Responsive Prototype

This again looked promising, but it was hardcoded and no longer using live data, so we started wiring it up to live data. Then a surprising thing happened and we realized that the site completely failed to satisfy our first goal of visually conveying uptime as well as downtime. In fact, once we had live data in there, we realized that if 3 consecutive days had something minor happen, like a single shared database server offline that affected significantly less than 1% of our users, it looked like our entire platform was down for 72 hours straight! It was so bad, we knew it didn't even deserve to go through customer validation.

Hybrid

In a last ditch effort to save the responsive design, we tried adding a timeline back into it.

Hybrid Prototype

At this point, the design had all of the "features" we needed. It showed a simple list view if you were on an iPhone, added a timeline for anything larger, and progressively added more information as the screen widened. It seemed like a design win, and fit with our new guiding principles of mobile-first and responsive design. Besides, it was fun to resize the screen and see it change! (Give it a try!)

There was only one problem: we didn't like it. It's hard to describe exactly why; it wasn't clear enough, the emphasis was in the wrong place, the meta data (Affected, Scale, and Duration) was supposed to add value but seemed to distract from the overall site. Design had been replaced by detail.

Bezier

So we took another step back. We took what we had learned so far and re-applied it to our initial gut reaction — the timeline.

Bezier Prototype

We added some meta information (e.g. duration), but not all of it (e.g. scale). We realized the App Operations / Tools split was very important to our users, but didn't go far enough. Too much counted as App Operations that had no impact on our paying customers, such as the unidling of 1-dyno free apps, or the free shared database offering. We thought about having one status light for each major component of our platform, such as routing or git push, but the complexity didn't add enough value. We then toyed with the idea of splitting based on Production vs Development instead, and it turned out to be such a great fit that we split the timeline into two columns to show it.

By this time, we had already approached all of our customer advisory board and needed more fresh eyes to look at it, so we invited random beta users to do the OpenHallway studies. This time, the comments were different: we had a winner.

We called this version bezier because we intended on having bezier curves to join the incidents with their timeline markers. We didn't get around to implementing them until later in the beta process, but when we did, it really brought the design together, simplifying a lot of hacks we put in place to handle overlapping incidents.

Here's the JSFiddle sandbox we used to get the right shape for the curves. It's not exactly how we implemented it, but it's where we started, and just knowing it was feasible let us move on with the design.

Beta and Release

All of the designs above were intended as throwaways since they were prototypes solely designed to be validated with customers. But as sometimes happens, we got such great response from the last design, that we decided to go into beta with the design largely unchanged.

Status Beta

We're happy with the final design; we use it internally and even have it up on a big screen in our office. But like anything we build, this is a perpetual work-in-progress. The new status site provides more value than the previous one, but we're going to continue iterating and improving, so keep the feedback coming!

Announcing Support for 16 new Postgres Extensions

Databases are the well known solution for storing data for your application. However they sometimes lack functionality required by application developers such as data encryption or cross database reporting. As a result developers are forced to write the needed functionality at their application layer. Postgres 9.1, which already has an extensive collection of data types and functions, took the first step towards mitigating this by creating an extension system which allows the database’s functionality to be expanded.

Today we are releasing support for 16 new Postgres extensions which add exciting new functionality including the ability to query from multiple database (dblink), a case-insensitive text datatype (citext), in-database encryption (pgcrypto), and UUID generation (uuid-ossp). A list of the new extensions is available below.

Extensions allow related pieces of functionality, such as datatypes and functions, to be bundled together and installed in a database with a single command.

We began supporing extensions in March with our release of hstore - the schemaless datatype for SQL. Users have taken advantage of hstore to increase their development agility by avoiding the need to pre-define their schemas.

These extensions are available on all Heroku Postgres plans, including the Starter tier dev and basic plans as well as our Production tier plans. To install an extension, use the CREATE EXTENSION command in psql:

$ heroku pg:psql --app sushi
psql (9.1.4)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)

=> CREATE EXTENSION citext;
CREATE EXTENSION

DBLink

In a class by itself, DBLink allows data from multiple Postgres databases to be queried simultaneuosly.

DBLink is useful for sharding, distributed application constellations, or any other environment where data from more than one physical database must be compared, joined, or collated.

=> CREATE EXTENSION dblink

Data Types

  1. Case Insensitve Text: Case insenstive text datatype. Although strings stored in citext do retain case information, they are case insensitive when used in queries. create extension citext.
  2. Label Tree: Tree-like hierachies, with associated functions. create extension ltree
  3. Product Numbering: Store product IDs and serial numbers such as UPC, ISBN, and ISSN. create extension isn
  4. Cube: Multi-dimensional cubes. create extension cube

Functions

  1. PGCrypto: Cyptographic functions allow for encryption within the database create extension pgcrypto.

  2. Table Functions & Pivot Tables: Functions returning full tables, including the ability to manipulate query results in a manner similar to spreadsheet pivot tables create extension tablefunc.

  3. UUID Generation: Generate v1, v3, v4, and v5 UUIDs in-database. Works great with the existing UUID datatype create extension "uuid-ossp".

  4. Earth Distance: Functions for calculating the distance between points on the earth. create extension earthdistance

  5. Trigram: Determine the similarity (or lack thereof) of alphanumeric string based on trigram matching. Useful for natural language processing problems such as search. create extension pg_trgm.

  6. Fuzzy Match: Another method for determining the similarity between strings. Limited UTF-8 support. create extension fuzzystrmatch

Database Statistics

  1. Row Locking: Show row lock information for a table. create extension pgrowlocks

  2. Tuple Statistics: Database tuple-level statistics such as physical length and aliveness. create extension pgstattuple

Index Types

  1. btree-gist: A GiST index operator. It is generally inferior to the standard btree index, except for multi-column indexes that can't be used with btree and exclusion constrations. create extension btree_gist

Full Text Search Dictionaries

  1. Integer Dictionary - A full-text search dictionary for full-text search which controls how integers are indexed. create extension dict_int
  2. Unaccent - A filtering text dictionary which removes accents from characters. create extension unaccent

New Heroku Postgres Plans GA

In past months we've release the public beta of our dev, basic, crane and kappa plans. We've received positive feedback from everyone using the new database plans.

Based on this strong positive response and adoption during the beta, we're officially moving these plans to general availability starting today.

In conjunction with the GA of our starter tier, we're deprecating our shared database plans. The new dev and basic plans offer many improvements including Postgres 9.1 with schemaless SQL, data clips, direct psql access, and a web management interface.

Beginning August 8, 2012, we will begin migrating shared database users over to the new starter tier. Users may control their application down time by migrating their databases ahead of August 8.

For steps in migrating to the starter tier please read here.

New Heroku Postgres Plans GA

In past months we've release the public beta of our dev, basic, crane and kappa plans. We've received positive feedback from everyone using the new database plans.

Based on this strong positive response and adoption during the beta, we're officially moving these plans to general availability starting today.

In conjunction with the GA of our starter tier, we're deprecating our shared database plans. The new dev and basic plans offer many improvements including Postgres 9.1 with schemaless SQL, data clips, direct psql access, and a web management interface.

Beginning August 8, 2012, we will begin migrating shared database users over to the new starter tier. Users may control their application down time by migrating their databases ahead of August 8.

For steps in migrating to the starter tier please read here.

Release of new database plans on August 1st

We are happy to announce that our new line-up of database plans are being released on August 1st. The dev, basic, crane, and kappa plans make many of the most exciting features of our fully-managed database service available to a wider audience. They are now ready for all users.

We will also begin billing for these plans as of August 1st. If you have been beta testing one of these databases and do not wish to incur charges for it going forward, please remove it immediately via the web interface or the command line:

heroku addons:remove HEROKU_POSTGRESQL_COLOR --app app_name

If you have been waiting to use these plans because they have been in beta, then your wait is (almost) over. They can be provisioned now by all users via the web interface or the command line:

heroku addons:add heroku-postgresql:[dev | basic | crane | kappa]

Starter Tier

The dev plan (free) brings many of the best features of our production database plans to development users. This includes Postgres 9.1, data clips, hstore schemaless SQL, direct psql access, support for most pg commands from the Heroku client, a web interface, support for multiple databases connected to a single application, and Continuous Protection. The dev databases are limited to 10,000 total rows. For users that need to store more data, the basic plan ($9 / month) raises the row limit to 10 million rows but does not increase availability or add any additional features.

The dev and basic plans both belong to our Starter tier. These plans are designed to provide 99.5% availability and are ideal for trial, development, testing, and other basic usage. For serious production applications, we recommend using one of our Production plans, designed for 99.95% availability. Please note that these are design parameters, not SLAs, and availability can be further increased by taking advantage of followers.

Production Tier

With this release, the Production tier is expanded to include crane ($50 / month) and kappa ($100 / month). These will also be released on August 1st. They offer all of the same features as our other production databases at an incredible price point. These benefits include production-grade monitoring and operations, as well as support for fork, follow, auto backups, and fast changeovers / upgrades.

Migration From Legacy Shared Databases

For those users that are still using the legacy shared-database plan, we encourage you to upgrade as soon as possible. We will be announcing a deprecation and migration schedule for these plans shortly. We will be working to migrate all users onto these new plans, but we encourage you to move as soon as possible to enjoy the advantages of these improvements. You can also opt-in to creating the dev plan by default for all new applications by enabling the Heroku Labs flag.

If for any reason the scheduled release of these plans causes hardship for your business, please open a support ticket so that we can individually address your needs.

Browse the blog archives or subscribe to the full-text feed.