As we’ve mentioned previously, big changes are coming for Tempo in our next release, codenamed “Teams”. After this update you and your company will be able to login to your own private Tempo address, e.g zetetic.keeptempo.com. However, we’re not telepathic and we can’t tell what domain you’d prefer to use, so we have provided a way for you to choose the preferred domain for your account before the migration:

1. Log into Tempo at http://app.keeptempo.com
2. Open your preferences by clicking Account on the Left-side menu
3. Click “Subdomain!” From the top Account menu
4. Enter your preferred sub-domain
5. Click “Save Changes”

If you follow these steps your account will use the new subdomain after the release. If you choose not to set a preferred domain the system will automatically choose one for you based on your login name, e.g. username.keeptempo.com. Don’t worry, you can always change it at a later date.

We are currently planning to release the new version of Tempo on Saturday, the 21st of November, late in the evening US-time. After the conversion, you and all of the users on your account will be emailed with the new URL so you can update bookmarks and widget configurations. We’ll provide an update here on the blog later this week to let you know exactly what time we plan to launch the new version.

Thanks so much for your continued business, and extra thanks to those of you who’ve helped us test this update, we really appreciate your feedback.

Since the topic is going around lately, I figured we’d chime in. Max Cammeron of Big Bang makes a strength-in-numbers appeal to consultants everywhere to abandon RFPs, while Carl Smith from nGen Works has a post up making a strong case that RFPs aren’t good for his clients. We don’t respond to RFPs either, and this isn’t because we’re starving artists/consultants. Many of the comments on Max’s article at Hacker News seem to be pushing this notion that responding to RFPs is the cost of business for a consultancy, and they couldn’t be more wrong.

We don’t respond to RFPs, and all of our business comes from repeat customers and referrals. And we’re not exactly making web sites for Jumpin’ Jack’s Chicken Shack, we’ve got some really big clients. Stephen gave a really good run down of why we don’t need ’em in a recent interview with Subvert.ca (emphasis added):

When we get a referral or start a new project for a past customer, there’s already a relationship in place. The client already knows that they can trust us, and it cuts out the entire “dance” that we’d otherwise have to do to prove ourselves. There are other benefits, too.

People only ask us to prepare a proposal when they are seriously considering a project. Plus, we rarely find ourselves as column fodder behind another incumbent company — we call it column fodder when you have no hope of winning a deal and your estimate is just filling in a cell on a spreadsheet for comparison purposes.

This level of trust also means that we can work more closely with our customers to develop requirements. They take our estimates and advice seriously. In the end it works out better for everyone involved.

We can talk ourselves blue in the face about the effectiveness or lack thereof in the RFP process, as I’m sure they will remain in the industry for some time, but in the end, nothing replaces good work combined with good communication, and trust. We only work with people we trust, and so do our clients.

Stay tuned, sports fans; later this morning I’ll post a run-down of where we’re going with Tempo, our time-tracker. Change is afoot!

Over the last year a whole lot has changed with Tempo, our time-tracking system. Actually, in the last two years the system has seen constant development and two major re-designs as we added features, responded to our customers’ feedback, and addressed rather-justified gripes about our lack of design skill shown in the early revisions. At this point Tempo has a fantastic look and feel, is extremely stable, and has a satisfied and steadily-growing base of free users and paid subscribers.

However, all that work takes a long time and involves a great deal of testing, usually with a number of our customers helping us beta the changes before release, for which we are quite grateful. After a major revision of Tempo is released, there’s always a period of adjustment for our users, too, so there’s a hidden cost there as well.

With that in mind, I’m happy to say that the next major revision of Tempo, Teams, is almost here, and should involve very little adjustment for those who are using the system every day. The changes are big, but they are mostly below the surface. This revision makes Tempo a lot more flexible for us and our customers, and is allowing us to implement some oft-requested features from our long-time users. This revision is called Teams because it is specifically aimed at making the management of a team on Tempo as easy as it ought to have been in the first place.

If you’d like to get an early look at the new system, please get in touch with us and we’ll send you the link and some short instructions.

Here’s a list of the bigger changes:

• Quick assignment of users to multiple projects.
• All paid users will have an account associated with their user identity.
  • Free users working on their own will also have accounts generated.
• All of these accounts have their own subdomain (e.g. zetetic.keeptempo.com).
• Accounts can have managers with more control than project managers.
• All people on your projects have been copied or moved into your account.
• Paid plans will be scaled by people-per-account, not people-per-project.
• Every paid account is gifted an extra two users to accommodate that change.
  • e.g. Moderato accounts with 10 users on various projects would be get 12 users.
• Auto-detection of mobile browsers for an updated mobile view.
• Legacy support for the ‘m.keeptempo.com’ mobile address.
• Saved Reports can be organized into groups.

We haven’t set a release date just yet, but we’re aiming for the middle of November, so that we can address any issues before the end-of-month billing period.

Bret and I have been working on a pretty extensive update to Tempo, our time-tracking service, that required revisiting how we detect mobile devices and provide mobile views where appropriate and/or available.

To that end I took a look at mobile-fu, a Rails plugin by Intridea’s Brendan Lim, which automatically detects mobile devices and sets the request format to :mobile, a commonly used mime-type alias for those looking to provide mobile views. You can check out his blog post on the plugin for full details, but the basics of it are that by setting the request.format to :mobile, you can automatically serve up custom views (e.g. new.mobile.erb), perhaps in a custom layout, etc. The plugin also will automatically attempt to include mobile_blackberry.css if you are already including a mobile.css file and the user is working off of a blackberry.

That’s almost perfect! However, we don’t support mobile views all over Tempo, it’s a bit impractical at the moment, especially given how well smart phone browsers like Mobile Safari handle normal web pages. Instead, we provide a basic mobile interface for logging in and logging time. We do want that to render automatically, but we also want the user to be able to exit out of the mobile view easily, and have that stick with his session.

So I forked mobile-fu on github, got things working the way I needed ‘em, and posted the changes back up. It now provides automatic detection of mobile devices with more dynamism (you call before_filter yourself, where you want it, with the options you need), and you can use the ’bypass’ parameter on any request to toggle the session-based bypass of the mobile view that allows the user to avoid it if he doesn’t actually want it.

Pushed-to-github-and-blogged-too-soon Update:

The use of a ‘bypass’ in the way I’ve done it here becomes somewhat less useful when you want a user to be able to easily enable the mobile view when their mobile device is not detected (e.g. a ‘Switch to Mobile View’ link on the login screen). So, I’ve hacked away at this a bit more and I’ve got another implementation to commit and push to this fork when I get a few minutes.

The main problems I ran into in all of this were not really the problem of mobile-fu, but more of an issue with how Rails handles the use of request.format, the aliased mime-type (i.e. :mobile => 'text/html'), and forwarding from one domain to another. Will try to detail how we’re handling it all shortly.

Designed by Mr. Matt Jones, of the British Experimental Rocket Group (BERG):

You know you want one. I just ordered mine.

BERG does amazing things like this:

Immaterials: the ghost in the field from timo on Vimeo.

Been real busy here at Zetetic HQ. Bloggery to resume soon!