1.0: Simple and Lame

The first iteration of the app was simple. That was my design goal: really simple. There were only two views: the money counting and the settings. I limited input to two pickers for people and average salary. I designed the input this way to force the user to estimate the numbers, rather than be exact. I wanted people to use the app to estimate meeting waste.

The app was simple but lame. It lacked personality. Just look at it. I’m bored already. I even shipped 2.0 and 3.0, and both were such lackluster releases that I don’t remember what they included. Something about iPad support and VGA support, I think. And that’s my point. Even the developer didn’t care about the app.

4.0: Snarky and Deeper

Recently, I decided Dollar Clock needed some love. The app needed a personality. What goes with a depressing clock counting monetary waste? Interesting images and uplifting messages.

I gave the app a voice. It iterates through a set of Flickr photos, each with a number of messages associated. Here are a couple examples:

• You’re not special. Neither is this meeting.
• Does someone have the notes from the pre-meeting?
• More people make meetings less effective. Leave. It’ll help.

Furthermore, I was wrong about input. The most common request for the app is more customization for salary input. My original problem with this was complexity. I didn’t want to make the salary input hard, for people to use or for me to code. But I like this new version. People click the “Add Salary” row. They can type in number for people and a salary and save it. It’s just another salary row. Simple but flexible.

Dollar Clock is available on Apple’s App Store, free for iPhone and iPad. Try it out! Let me know what you think.

Inspired by infosthetics’s google adsense sparklines post, I’ve added a couple interesting streams of data to the sidebar, both from this website and from my iOS App Store apps. Sparklines are an excellent visualization for conveying a large amount of information in a small space. Here’s what I display now:

• site: bdunagan.com blog visits per day (Google Analytics)
• rml: Remind Me Later downloads per day (Appfigures)
• dc: Dollar Clock downloads per day (Appfigures)

I’ll walk through how I get the data from those sources into sparklines on my blog.

Getting the Data

First, I needed to get the data from its original location to my blog’s server, in a form Javascript could easily find and read. Using Ruby, I extract the data from its service and then write it in JSON to a local file on my web hosting server.

The site data comes from Google Analytics. Getting data from Google is a bit complicated due to its adoption of OAuth. To access Google Analytics information, I wrote a Ruby script leveraging Garb, a great gem from Viget.

# Require libraries.
require 'rubygems'
require 'active_support'
require 'oauth'
require 'garb'
require 'json'

class Time
  def to_js_date
    self.utc.strftime("%Y/%m/%d")
  end
end

# Setup OAuth. (See http://everburning.com/news/google-analytics-oauth-and-ruby-oh-my/.)
# Register a domain: https://www.google.com/accounts/ManageDomains.
oauth_consumer = OAuth::Consumer.new(consumer_key, consumer_secret, {:site => 'https://www.google.com', :request_token_path => '/accounts/OAuthGetRequestToken', :access_token_path => '/accounts/OAuthGetAccessToken', :authorize_path => '/accounts/OAuthAuthorizeToken'})
session = Garb::Session.new
session.access_token = OAuth::AccessToken.new(oauth_consumer, request_token, request_secret)
profile = nil
Garb::Management::Profile.all(session).each |current_profile|
  profile = current_profile if current_profile.title == site_name
end

# Visits/day over last week: bar chart
class RecentVisits
    extend Garb::Model
    metrics :visits
    dimensions :date
end

stop = Time.now
start = stop - 60*60*24*30
start_date = Time.utc(start.year, start.month, start.day - 1)
stop_date = Time.utc(stop.year, stop.month, stop.day - 1)
results = RecentVisits.results(profile, :start_date => start_date, :end_date => stop_date, :sort => :date)
visits = {}
results.each { |result| visits[Time.parse(result.date).to_js_date] = result.visits }
# Save to a file.
f = File.new("ga.txt","w")
f.write(visits.to_json)
f.close

The app data comes from Appfigures. Their API access is based on credentials, but SSL is always required. Below is the Ruby script I wrote to fetch that data.

# Require libraries.
require 'rubygems'
require 'time'
require 'net/http'
require 'net/https'
require 'json'

class Time
  def to_short_date
    self.utc.strftime("%Y-%m-%d")
  end

  def to_js_date
    # Safari Javascript doesn't parse to_short_date format.
    self.utc.strftime("%Y/%m/%d")
  end
end

# Set up environment.
rml_key = 'app_id'
dc_key = 'app_id'
rml_data = {}
dc_data = {}
af_response = nil
day_length = 86400
stop = Time.now
start = stop - 60*60*24*30
start_date = Time.utc(start.year, start.month, start.day - 1)
stop_date = Time.utc(stop.year, stop.month, stop.day - 1)

# Prepopulate dates to ensure range. Appfigures's API is not great about including every day.
current_date = start_date
while current_date <= stop_date
  rml_data[current_date.to_js_date] = 0
  current_date += day_length
end
current_date = start_date
while current_date <= stop_date
  dc_data[current_date.to_js_date] = 0
  current_date += day_length
end

# Fetch data from Appfigures.
http=Net::HTTP.new('api.appfigures.com', 443)
http.use_ssl = true
http.start() {|http|
	req = Net::HTTP::Get.new("/v1/sales/apps+dates/#{start_date.to_short_date}/#{stop_date.to_short_date}/")
	req.basic_auth 'username', 'password'
	response = http.request(req)
	af_response = response.body
}
af_data = JSON.parse(af_response)

# Parse data.
af_data[dc_key].keys.sort.each { |date| dc_data[Time.parse(date).to_js_date] = af_data[dc_key][date]['app_downloads'] }
af_data[rml_key].keys.sort.each { |date| rml_data[Time.parse(date).to_js_date] = af_data[rml_key][date]['app_downloads'] }

# Write to files.
f = File.new('dc.txt','w')
f.write(dc_data.to_json)
f.close
f = File.new('rml.txt','w')
f.write(rml_data.to_json)
f.close

Displaying the Data

Second, I needed to visualize the data. I’ve been looking for a lightweight graphing library ever since I wrote my post about measuring design changes. For that chart, I used Excel and Acorn. It was slow, painful, and manual. No fun at all.

I asked a friend at LinkedIn for recommendations, and he pointed me to Raphael, an excellent open source tool written in Javascript. I used a higher-level version of the tool called gRaphael.

Infosthetics’s sparklines used color to give context to the data: black bars for weekdays this month, dark gray bars for weekends this month, light gray bars for weekdays last month, and a single red bar for today. Small but data-rich. I tried to bring a little of that context to my sidebar’s sparklines by coloring the weekends in red but the weekdays in gray. Below is the Javascript code that reads the generated text files and creates the graphs:

<script type="text/javascript">
window.onload = function () {
// Include the following scripts in the header:
// * raphael-min.js
// * g.raphael-min.js
// * g.bar-min.js

// Add hover functions.
var fin = function () { this.flag = r.g.popup(this.bar.x, this.bar.y, this.bar.value || "0").insertBefore(this); };
var fout = function () { this.flag.animate({opacity: 0}, 60, function () {this.remove();}); };

// Getting Data: fetch data from local files and separate into weekdays and weekends to allow grey/red bars in sparklines.

// Get cached GA data.
var ga_xhr = new XMLHttpRequest();
ga_xhr.open('GET', '/files/ga.txt', false);
ga_xhr.send(null);
var ga_response = ga_xhr.responseText;
var ga_data = JSON.parse(ga_response);
var ga_dates = [];
for (var ga_key in ga_data) { ga_dates.push(ga_key); }
ga_dates = ga_dates.sort();
var ga_weekday_values = [];
var ga_weekend_values = [];
for (var ga_dates_key in ga_dates) {
    var ga_key = ga_dates[ga_dates_key];
    var key_date = new Date(ga_key);
    var key_day = key_date.getDay();
    if (key_day == 0 || key_day == 6) {
        ga_weekday_values.push("");
        ga_weekend_values.push(ga_data[ga_key]);
    }
    else {
        ga_weekday_values.push(ga_data[ga_key]);
        ga_weekend_values.push("");
    }
}

// Get cached RML data.
var rml_xhr = new XMLHttpRequest();
rml_xhr.open('GET', '/files/rml.txt', false);
rml_xhr.send(null);
var rml_response = rml_xhr.responseText;
var rml_data = JSON.parse(rml_response);
var rml_dates = [];
for (var rml_key in rml_data) { rml_dates.push(rml_key); }
rml_dates = rml_dates.sort();
var rml_weekday_values = [];
var rml_weekend_values = [];
for (var rml_dates_key in rml_dates) {
    var rml_key = rml_dates[rml_dates_key];
    var key_date = new Date(rml_key);
    var key_day = key_date.getDay();
    if (key_day == 0 || key_day == 6) {
        rml_weekday_values.push("");
        rml_weekend_values.push(rml_data[rml_key]);
    }
    else {
        rml_weekday_values.push(rml_data[rml_key]);
        rml_weekend_values.push("");
    }
}

// Get cached DC data.
var dc_xhr = new XMLHttpRequest();
dc_xhr.open('GET', '/files/dc.txt', false);
dc_xhr.send(null);
var dc_response = dc_xhr.responseText;
var dc_data = JSON.parse(dc_response);
var dc_dates = [];
for (var dc_key in dc_data) { dc_dates.push(dc_key); }
dc_dates = dc_dates.sort();
var dc_weekday_values = [];
var dc_weekend_values = [];
for (var dc_dates_key in dc_dates) {
    var dc_key = dc_dates[dc_dates_key];
    var key_date = new Date(dc_key);
    var key_day = key_date.getDay();
    if (key_day == 0 || key_day == 6) {
        dc_weekday_values.push("");
        dc_weekend_values.push(dc_data[dc_key]);
    }
    else {
        dc_weekday_values.push(dc_data[dc_key]);
        dc_weekend_values.push("");
    }
}

// Graph GA sparkline with gRaphael.
var r = Raphael("gadata");
var chart = r.g.barchart(10, 10, 160, 50, [ga_weekday_values, ga_weekend_values], {stacked: true});
chart.bars[0].attr({"fill": "#666"});
chart.bars[1].attr({"fill": "#CD0000"});
chart.hover(fin, fout);

// Graph RML sparkline with gRaphael.
var r = Raphael("rmldata");
var chart = r.g.barchart(10, 10, 160, 50, [rml_weekday_values, rml_weekend_values], {stacked: true});
chart.bars[0].attr({"fill": "#666"});
chart.bars[1].attr({"fill": "#CD0000"});
chart.hover(fin, fout);

// Graph DC sparkline with gRaphael.
var r = Raphael("dcdata");
var chart = r.g.barchart(10, 10, 160, 50, [dc_weekday_values, dc_weekend_values], {stacked: true});
chart.bars[0].attr({"fill": "#666"});
chart.bars[1].attr({"fill": "#CD0000"});
chart.hover(fin, fout);
}
</script>

These scripts are also available through my GitHub repository.

Remind Me Later

Remind Me Later had this problem. When people downloaded the app from the Mac App Store, the app went to their /Applications folder, and its icon was added to their dock. So, the user clicked the dock icon. Remind Me Later’s dialog appeared, because on launch, I show the dialog. However, some users associated the dock icon click with the dialog’s appearance, because they didn’t notice the menu bar icon appear. People complained.

My first pass at a solution was a pulsing menu bar icon. When someone clicked the dock icon to launch the app, the app’s menu bar icon pulsed blue four times. I thought people would notice this. Wrong. People still complained.

My second pass acknowledged the root problem. Some people don’t understand the dock. They don’t get the menu bar. They just want the stupid dialog to appear. The first click on the dock icon makes the dialog appear; that means the second click should. Luckily, Cocoa’s NSApplication provides that exact delegate method:

# NSApplication method
- (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication hasVisibleWindows:(BOOL)flag;

Now in Remind Me Later, clicking the dock icon makes the dialog appear. Every time.

LaunchBar, Alfred, and QuickCursor

I’m not alone in coming to this conclusion either. Those popular productivity apps, LaunchBar and Alfred, both support that interaction. Click on the dock icon; the main window appears, every time. However, I’ll bet both of them added that workflow after someone complained. On the other hand, QuickCursor provides no help when I click the dock icon. The first click puts the icon in the menu bar, but I might not notice that. The second click does nothing. (Keep in mind that QuickCursor is a brilliant app, along with the rest of Jesse Grosjean’s Hog Bay portfolio. This post was written in WriteRoom.) Every dock icon click should open the menu in the menu bar. That interaction should help the user associate the menu bar icon with the app.

Jing

Jing takes a different approach. When I click on the dock icon a second time, it pops up this explanatory message. Yes, it’s better than nothing. But no, it’s not great. Why not just trigger the menu in the menu bar? Or the “Capture” action? TechSmith produces great software, so I find it strange to find such an odd workflow from them. Show the user; don’t tell the user.

So, developers, just handle it. Because your mental model isn’t the only mental model.

In the week leading up to Apple’s WWDC keynote last Monday, everyone seemed convinced that Apple’s big announcement, iCloud, would be a cloud-based streaming service. (In fact, NPR reported that after the event before amending the article.) But music streaming would be such an odd service from Apple. They make money on hardware. All their other businesses fuel their hardware business. How would music streaming fit into that story?

As it turned out, iCloud is not music streaming. It’s a wish list of features to fix what’s broken about iOS. Think about it from Apple’s perspective. Their online service has never been a success. MobileMe offers an excellent interface to mail, contacts, calendar, and photos; iDisk has never been exceptional; Find My iPhone was their first hit because it leveraged their unique hardware. But at $99/year, only Apple fanboys (like me) and a minority of non-techies opted to pay for the bundle of services. MobileMe just wasn’t very compelling compared to the multitude of free services from Google, Yahoo, and Microsoft. In that respect, MobileMe was a fresh coat of paint on .Mac, but the underlying business simply wasn’t exceptional.

I wonder if Apple’s executives sat down last year to brainstorm a better online service. You can imagine the sort of wish list they would come up with. Anyone who owns an iPhone or iPod understands the frustrations with syncing.

• sync app data between devices, because I don’t want to start Angry Birds over again
• sync music between devices, because I forget to plug my iPhone into my computer
• sync and backup magically, because I don’t own a computer
• include MobileMe for free
• in fact, make the whole service free at some level

Out of these frustrations, you can see a service forming. It would be a massive service but a compelling one. The iOS ecosystem has been hampered by its own success, and this service would solve many of its current problems and fuel further growth. And that’s the key: fueling hardware sales.

So, Apple announced iCloud. Lion and iOS 5 are evolutionary steps, but iCloud is revolutionary. As Ben Brooks put it, iCloud is Apple’s magnum opus. Kudos to Apple for understanding their business and its problems so well and for attempting a comprehensive solution. I wish more companies were as self-aware and motivated.

Remind Me Later 1.3 is now live on the Mac App Store and this blog! First and foremost in this update is the improved Launch, Help and Support. The first launch experience of previous releases has proven to be an unmitigated failure, but I’m pretty happy with this new workflow. And in case people have trouble, the Support links in Preferences should help users contact me more easily.

In addition, I added a number of features:

• Durations: “4pm to 5pm”
• Delays: “in 1 hour”
• All-day events: “Monday through Friday”
• “Add and Launch iCal”: Cmd-Enter to add an event and open it in iCal
• Configurable global hotkey
• Fixed the clickable icon issue on Leopard (10.5)

Download this new release from the Mac App Store or this blog!

For version 1.2, I’ve added UI hints. The menu bar pulses blue when launched to make its location clear. When you add an event, the icon pulses blue when all goes well and red when something goes awry. Hopefully, these small visual hints will help people understand the app a bit quicker.

Remind Me Later is a very simple app, but even the smallest apps need design work. Also, it’s free. Give it a try.

When consumers have a great user experience, they don’t notice. They don’t wonder how you designed the product so well. They just use it and move on, but that’s a good thing. They shouldn’t feel bad while using your product. Don’t make users feel bad because eventually they’ll choose a better user experience as a coping mechanism.

User experience: Because your users internalize your product’s failures.

Today, I checked the numbers in iTunes Connect for Dollar Clock. At first, I only looked at the total downloads, in the left graph, where the hash mark notes the header change. Clearly, the header change increased the downloads. Then I looked at the purchases and updates separately, in the right graph, and the pattern was less clear. During the week after the header change (the bar after the hash mark), more of the downloads were updates, not purchases.

During the same week I changed the header, Dollar Clock 2.0 was posted to the App Store, and many people downloaded the update that week. The total downloads indicates my header change had a significant effect, but the breakdown reveals confounding variables. Perhaps if I had more variables, I would find that the header change had absolutely no effect.

Or maybe I just wanted an excuse to use Tufte’s small multiples.

Tracking Changes

I’m using git and GitHub, but any scm would be fine. I’ll run through the steps here. (Keep in mind I use WordPress’s update system for version and plugin updates; I just want to track my own changes.)

1. Removed unused themes and plugins to reduce installation size to 25MB (du -h)
2. Created a private repo on GitHub
3. Setup git in blog’s root directory on DreamHost:

   git init
   # Didn't bother ignoring any files.
   git add .
   git commit -m "current state of blog"
   git remote add origin git@github.com:username/myblog.git
   git push origin master
   

4. Edited the CSS file using WordPress’s editor then listed the changes (git status) and diff’d the changed file using git (git diff style.css)
5. Decided my edits didn’t look good on the live blog and reverted them (git checkout style.css or git reset HEAD --hard)
6. Ran mysqldump then gzip on the blog db and added it to git also
7. Updated .htaccess to hide the new .git directory (DreamHost): RedirectMatch 403 /\..*$

Seeing the changed files in git is fantastic, and at this point, I wonder how I got by for so long without versioning my WordPress changes. But tracking changes isn’t enough.

Staging Changes

Now, I can easily revert horrible template changes, but anyone hitting the blog during that time will still see it. It reminds me of how the early Facebook team used to directly edit the HTML on the production site when they were adding features. Debugging changes on a live site is annoying and unnecessary. Instead, just use a subdomain. Here are my steps:

1. Created a subdomain on DreamHost for the staging area and assigned it a private IP/enabled SSL (I require SSL for administration)
2. Pulled the current repo in that new subdomain’s root directory on DreamHost:

   git init
   git remote add origin git@github.com:username/myblog.git
   git pull origin master
   

3. Pointed this instance of WordPress to the new subdomain by adding WP_HOME and WP_SITEURL in /wp-config.php according to WordPress’s “Changing The Site URL” page (I want to use the same database so I didn’t change those entries)
4. Waited a couple hours while the DNS changes propagated for the new subdomain
5. Logged into WordPress on the subdomain and changed a couple lines of CSS
6. Checked out the result on the subdomain and committed it to GitHub
7. Pushed the commit to GitHub and pulled it down in the live blog
8. Verified the change on the live blog

Staging changes is so much more comforting. Before, I wondered how many visitors hit my site mid-change (which sometimes took hours) and left annoyed. At least now I can think, “Actually, I designed it that way intentionally…”