Just a quick note that Stephen’s tutorial on building encrypted iPhone applications with SQLCipher has been published by the fine folks at Mobile Orchard. Thanks, Dan!

This post is mostly concerned with the beta version of our time-tracker, Tempo. Every time we do a redesign round, we try to fix nagging issues with the UI, and I think we may have actually made a long-overdue improvement to how tagging works.

Being able to arbitrarily tag time entries is one of the things that makes Tempo’s reporting so flexible and dynamic, but it comes with some trade-offs over more static associations that other time trackers use (e.g. Activities, Tasks). One of the many benefits of using tags over tasks is that there’s no need for an administrator to set up your activities in advance – when you need a new label for an entry, you just use it. However, such dynamism can be pretty confusing to those who are entirely unfamiliar with the ideas of tagging and meta-data — which is a lot of people. Some new users end up looking at the new entry form and ask, “how do I designate my time?”

Once you explain to new users how tagging works, their next obvious (and reasonable) question is “how do I know what tags to use?” We were recently assisting a new client shop that was starting to use Tempo, and one of the main concerns there was the possibility that people might use different tags to label tasks that needed to be grouped together, that one person on their team might bill their consultation hours as ‘meeting’, while another person might use ‘meetings’. Clearly, we want new users and teams to be able to hit the ground running, so this needed to be fixed¹.

To make matters more interesting, our current interface could become quite cumbersome for anybody using tags extensively. The control for adding tags is just a text-field, so all you need to do is type them in. But users sometimes want and/or need to see the tags they’ve already used. To solve this we provided auto-complete (a type-ahead suggest) on the field itself, so that if the user pauses while typing, suggestions are given based on tags they’ve already used. In addition, there’s an optional display of all tags on the selected project that the user can choose from. Predictably, this list gets pretty big, pretty fast:

What to do?

The first thing we decided to do was to give projects a set of “preferred tags”. When a user sets up a new project, she can now assign a list of tags that her teammates could/should use when billing their time:

From there we put together some custom SQL to roll-up the most frequently used tags on a project (the top ten), as well as a union of those frequently used tags with the project’s preferred tags. It’s this collection that we now display for a user in the entry form, below the tag field:

As the image shows, the preferred tags from the previous image now show up alongside popular tags on this project, such as “thuglife.” (Image was taken from our testing account.) If it’s not already apparent, the user can click on any of the tags, causing the tag to be added to the tags field. We think this solves a few problems:

• It’s more apparent now that the Tags field is for labeling one’s time.
• A new user can see what tags are commonly used and/or preferred.
• The list of tags shown will only grow to 10 + (Number of Preferred Tags).
• We retain the text field for quick entry by advanced users.

This updated interface is now in place on the Tempo beta site. If you’d like access to the beta, please get in touch, we could always use more help tightening all the screws.

¹ It should be noted that the batch tags interface allows a project manager to combine, add, and remove tags from all entries in a report. This provides a facility for cleaning up entries that may have been mis-tagged.

GUID collision
inevitable, but we
live with the odds

Lifted from Mr. Kradel. I know, I cheated a little.

As we’ve mentioned before, we’ve got a beta of the next version of Tempo running. Most of the changes we made were with regard to user interface, but there are a couple of changes and enhancements (we think) to the API.

Accordingly, I’ve updated the API documentation (this was long overdue), leaving a beta notice on new methods and methods that are changing or going away.

If you have code that relies on the Tempo API, please get in touch with us so we can point you at the beta URL and help with the transition.

To summarize the changes:

• We are introducing a reports API. It’s not complete, but it’s a start.
• By popular demand, /entries, /projects, and now /reports support an id[] parameter for pulling specific entities in one call.
• Searching for entries has been moved to /reports/search GET, replacing /entries/search POST. The /entries/search URL will redirect to /reports/search for now, but you’re better off migrating sooner than later.
• The /entries GET method used to provide the same data you’d get from /entries/search if you didn’t specify any search criteria — a default context. Instead, /entries will now provide a listing of your own entries.

Some folks have asked us for JSON support, and while we’d really like to provide that now, it will be somewhat burdensome to implement, and will be available to us out-of-the-box in Rails 3, thanks to the provides/display feature of Merb.

Dan Grigsby has put together a helper for doing simple Facebook status updates from an iPhone app with a minimal amount of fuss.

Ignore the pirate-speak, that’s my lang setting on Facebook

- (void)session:(FBSession*)session didLogin:(FBUID)uid {
    fbHelper.status = @"is learning to set Facebook status programatically from an iPhone";
}

Most excellent.