Presenting the Heroku Dashboard

Here at Heroku, we focus our energy on developer experience and productivity. Historically, this has revolved around command-line tools like the Heroku Toolbelt. As a polyglot platform, we have developers that come from all backgrounds — some that prefer command-line workflows and others that prefer web interface. Most use a bit of both.

Today, we're introducing a new first-class interface to our platform: the Heroku Dashboard.

App Awareness and Discoverability

The new Heroku Dashboard features a fresh look and feel, optimized for readability and workflow efficiency.

The more apps you deploy to Heroku, the harder keeping track of them becomes. With Dashboard, you can instantly filter your apps not only by name, but also by stack, and buildpack.

App List

If there's an app you access frequently, you can favorite it. This moves it to the top of your app list permanently.

Favorites

The new Activity view displays all code, config, and resource changes by every developer working on an app.

Activity

Additionally, if you specify an app's GitHub repo then you'll have clickable links to a diff of every deploy. Collaboration has never been easier.

New Horizons

As of today, the Dashboard is the default web experience for everyone on the platform.

Watch closely for updates and new features. Dashboard is a great foundation that allows for quick iterations and experimentation — a standard Heroku app that consumes our public API.

Introducing the Heroku Partner Directory

In 2007, Los Angeles web development shop Bitscribe loved the productivity gains they found by developing using agile methodologies. What they didn’t like was the labor-intensive process necessary to deploy applications. Bitscribe principals James, Adam, and Orion decided to build a company just to solve this problem. They called it "Heroku", a combination of the words "hero" and "haiku".

Hundreds of development shops from small shops like Bitscribe to large GSIs like Accenture now rely on Heroku so they can focus on building apps instead of deploying and running them. Many of these shops are now official partners. Their expertise ranges from web and mobile development, project management, design and agile training.

Find Partners in Our New Directory

From Fortune 500 companies to startups, we're finding there are a lot of companies who benefit from the agility these service partners can provide. We’re proud to announce a new Partner Directory as well as a revamped Partner Program.

Whether your company needs a few extra developers or an entire team for a big budget project, the Heroku Directory has you covered. Each company featured in the Directory is vetted by our team here at Heroku and is therefore familiar with best practices on our platform. Search for partners by language, competency, or geography, and check out samples of work. If you see a potential match, simply contact that company from their listing.

Become a Partner

We know there are a lot more dev shops using Heroku who can benefit significantly from this program. If your company is a development shop and would like to be featured, please apply at our website, It's fast, easy, and free.

Premium Support through Gold and Platinum Tiers

Some development shops deploy business critical applications for large companies and need a higher level of support and flexibility from Heroku. We now have new Gold and Platinum partner tiers that offer access to a named Technical Account Manager and co-branding options. Please contact us at partners(at)heroku.com for more information.

As a company created to solve the problems of a development shop, Heroku strives to offer the best experience for our current and future partners and their customers. Take a look at our revamped Partner Program and let us know how we are doing.

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.

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