isaiah’s web log

If you’ve kept up with my tweets over the past year, you’ve probably seen a lot about something called OAuth. OAuth is a new mechanism that some websites use to authenticate users and track client applications that use their API. Flickr, Twitter, and a bunch of other sites are already using it today. Clients like Kiwi, Tweetie, and Twitteriffic have been slower to take it up. Don’t worry, though, that’s all about to change.

OAuth was built as a way for apps to access Twitter without requiring users to give away their passwords. How many times have you opened a web-app, been presented with the, “Sign in with your Twitter username and password,” and then just closed the window. I have.

After being burned more than once, I just don’t give out my passwords any more.

OAuth was designed to help with exactly this problem. OAuth allows websites that need access to your account to send you to the Twitter website to explicitly grant access to that app. If it turns out you don’t like the app, you can disable it in the Twitter settings.

What makes great sense for web-apps seems out of place for Mac Apps. Having a browser open up to Twitter.com is not how you want to sign in to every account. And being dumped out to Safari on an iPhone is even more painful. Most Mac/iPhone developers sensed this and held off integrating OAuth.

Twitter tried to sweeten the pot by only displaying the name of apps that used OAuth. But it changed the game very little. A few apps were motivated enough to suffer the user experience, but most didn’t. It set the stage for a stalemate between frustrated client developers and unbudging API developers.

A new tweak to the OAuth system was proposed specifically for desktop and mobile. In short, it has most of the advantages in tracking client apps, but allows users the expected experience of signing in with their username and password, without a web browser. It’s the best of both worlds.

Twitter has added this modification and has been hinting about it for a while. It finally leaked out a few weeks ago that it was already beta testing. And yesterday it was switched on.

Most users won’t notice any change. And that’s a good thing. But behind the scenes there will be some important differences.

• Separation from passwords — done well, a client should ask for your password, use it to get authentication from Twitter, then forget your password. The client remembers the authentication token from then on. The authentication token is like a key to your Twitter account, and it continues to work even if you change your password.

• Increased rate limits — because Twitter can keep a closer eye on specific client apps, they allow more API calls. Basic Auth allowed 150 calls per hour; with OAuth/xAuth, it’s at least double that. This means more cool Twitter client features, and more refreshes.

• Attribution — you may not care very much. But the attribution line on a tweet says which client app was used to create that tweet. It’s like a little teeny tiny ad on every tweet. That’s good news for underdogs like Kiwi that are trying to get noticed.

And all this, without so much as a hiccup in the user experience.

I released a first Kiwi 1.2 beta a few hours after xAuth was turned on, but a second beta was released tonight. It’s a bit more stable, but probably still has a few rough corners. If you’re feeling daring you can grab it here: Download, Release Notes. Or if you’d rather wait for the real thing. Then just hang on a few days. We’ll roll out the final version and Kiwi will automatically update when it’s ready.

Beta 3 is out now, I’ve updated the links.

The ad shows that greatness is achieved through often painful repetition. And success, regardless of the vocation, is a measure of how quickly you can recover from adversity.

Or something like that. Catchy tune too.

It’s good to remember, while watching the Olympics, just how much work goes into every moment. And also to keep to keep you going when it seems that elusive bug is unfixable.

Human Chain - Nike (Sorry, not in English.)

Better direct Vimeo link

I’ve just finished recording a Kiwi intro screencast. As usual, I’m trying to get the most out of the compression, deciding on what a good size is, and try to make it sound loud enough to enjoy without hearing the fan on my Drobo too much.

I have three versions and I’d love to know which one you think is best. I’m really looking for feedback on the video production, but if you want to give me feedback on the video that would be great too.

My goal was to make a 5 minute intro video that touched on Kiwi features; starting from simple and making it all the way to rules.

So here are my candidates:

1. size: 75% audio-compression: lots audio-filtering: bandpass audio-volume: louder Watch

2. size: 50% audio-compression: lots audio-filtering: bandpass audio-volume: louder Watch

3. size: 50% audio-compression: some audio-filtering: none audio-volume: quieter Watch

If you have feedback send a message to me on Twitter.

There’s a cool new HTML5 video player out called Sublime. It looks great, has slick transitions, and a user experience that leaves everyone in the dust. It’s been mentioned on the biggest blogs and many are hailing it as one more nail in the coffin for Flash.

With all the awesome, it’s easy to see how this is a much better player than anything available for Flash. Then again, slick UI was never really one of the problems that Flash solved. Back in the days before Flash there were really three significant problems:

• splotchy interoperability.
• complex web design for the player.
• complex video encoding.

Prior to 2002 and Flash 6, there was no standard (de facto or otherwise) way to present video on the web. This meant serving video in many formats: QuickTime, Windows Media, and Real among many others. It also meant that what you had installed was often not what every site encoded: lots of blue lego.

Flash changed all that by providing a populist solution: no frills, no high-tech, no politics, it just works. Click to play! They beat everyone else at interoperability and won the game.

Now, let’s jump back to the fancy new HTML5 player that’s going to kill Flash with its awesomeness. Did it solve the problems that we had back in 2001? Well, yes and no.

The current batch of techies, especially those that bleed in six colors, will likely point to the fact that HTML5 works very well on iPhone and any other WebKit based browser. That’s a definite yes.

Unfortunately for HTML5, most of the world is not running WebKit. IE is somewhere in the neighborhood of 50% of the browsing public. IE does not support HTML5 of any sort. And despite recent gains by WebKit, Firefox is still much more popular than any WebKit based browser. Firefox supports HTML5, but not the h.264 codec. It only supports a vastly superior and almost totally unused open codec called Ogg Theora.

The new player is indeed awesome, but it just reintroduces the pre-Flash problems: interoperability, design complexity, and encoding complexity. No one wants to choose the right video badge to watch grandma’s LOLCat video. No one wants to have the OS that only supports 50% of the videos. And no one wants to encode 3X the number of videos to ensure that you’ve covered most of the audience.

No web designer will go back to those days when deploying Flash alone solves all these problems.

I refuse to use Flash on any of my sites because I hate the current Flash situation. It’s like having great public libraries and only one printing press in town. No matter how great the company that owns the press, they’re going to become evil; bet on it.

And then there’s the crashing. That sucks too.

But I do give Flash credit for being the Model-T of video. They solved the problems that no one else could. And that’s why this new player is not really going to hurt Flash: it forgets that we already played the interoperability game and Flash won. And if we play the same game again, without changing our moves, they’re going to beat us again.

It is a nice player, though. If something does beat Flash, I sure hope it looks as good as this.

A few weeks ago I started using Tender to do my support. It’s an online, hosted web-app that provides a combined email, FAQ, and all around support-sytem for companies. Overall, I really like what they’re trying to do. And compared to the competition that seems stuck in the mud in Redmond somewhere, they’re miles ahead.

My old system was Mac OS X Mail. My wife and I both answer email as it comes in and place it into an answered mailbox. We have a few other mailboxes for various regular support requests: serial number lookup, nfr requests, etc. This system works well, but after storing over 5 years of support email, email tools start to groan under the weight of it all. That said, the simplicity of the system was great, the searches via Spotlight are fast, and the automation through rules reduces a lot of complex tasks into effortless things that happen in the background.

I’ve started to keep a log of things that I like and don’t like about tender. I did it with the hopes of convincing myself to pay for the service as well as sharing with them with the hopes of improvement. The list has really grown, though, and I thought it would be worth sharing with everyone. Not just in hopes of making Tender better, but in making all other future similar services better too.

Update: The guys from Tender have already responded to this blog post. It took them less than half an hour I think (awesome!). They addressed a number of my nit-picks. I’ve tried to note those below.

Here’s my big list. Not in any real order. I’ll continue to add/modify as I learn more.

• It’s a web-app and always online — even for customers.
• The integrated wiki/public comment area makes FAQs simple.

• Pages often reload before the processing queue has completed. This leads to showing items that have already been acknowledged or trashed. It’s as if Tender just missed the last change. I always reload pages twice.
• Tender is almost unusable on an iPhone. > update: tender says they have several things planned here.
• Spam filtering seems a bit aggressive. I’d rather deal with spam than deal with an angry customer who feels ignored. Angry customers will post to other sites and do real and costly damage. Spam is just annoying.
• A 10MB attachment limit. My customers often send me big files. It would be great if there were an integrated drop-box like system in place. I’d pay for that service.
• after various operations i seem to be sent to places other than the inbox. I’m not sure of the logic of this, but it’s annoying.

• If a person starts a new conversation, it would be great to see their older conversations in the sidebar.
• A way to reverse the conversation order. The comment at the very bottom of the page is the most pertinent — and the most difficult to get to (especially on an iPhone). It would be great to be able to: only show the newest update or show the newest first.
• The “assigned” state is only for people that use your bug-tool too. I don’t need/want your bug tool, but would really like to assign things to staff members.
• Links that people send to me are not clickable. I actually have to select them and copy and paste them into my browser.
• Images that the customer thinks are sent inline in the email are treated as attachments and hidden at the bottom.

• filters/rules/scripts/automation. If i can automate something, then it’s something I don’t have to do. If there is any automation in Tender it’s very well hidden. > update from Tender: “filters are our next big feature.” I can’t wait.

• Five years of support messages. I sure wish there was a way to import those mbox files. I’d pay for this service. Having to start over from zero is really painful. It means that I can’t really ever switch 100% to Tender. For as long as i run my business i’ll need to keep the old system close at hand. > update: it sounds like they’re actually planning for something like this! that’s pretty amazing, i had pretty much given up hope here.

• Organizing is a three step process of:
  1. Adding to a queue.
  2. Acknowledge the email
  3. OK the acknowledgement.
     I don’t think it could possibly be more difficult. Not only is it three steps, it’s three different paces on the screen (left for the drag, right for the acknowledge, middle for the OK button) and three different types of UI (drag, menu, button). This is the most common action, why make it so painful?
• I can add to a queue with drag and drop, but I must select from a menu to put something in the trash or mark as spam.
• When looking at the list view I can drag and drop to queues. When looking at the detail view i have to:
  1. expose the queues in the toolbar.
  2. click to add a queue.
     why not just use drag and drop to the sidebar for everything? the master/detail metaphor is broken by inventing a new UI for each different page.
• The action menu (the gear thing on the lists) is very annoying. There are only three things in it — just give me buttons. That way it would at least be usable on an iphone. Putting it in a menu only saves two button locations, but adds another complication of exposing the menu (with a hover!!?? again, nutty) and then selecting the menu item.
• You use a checkbox to note “selected” and a color change to note “hover” — this is craziness. Use your color change to denote selection, checkboxes are just out of place here.
• The checkbox also does double duty by changing color as well. Save UI invention for something that needs it. Any badge/mark/color would work fine — there’s no need to entangle the selection mechanism with the status of the message. Keep it simple folks. Selection and tagging are not new or unique. Use some of the tried and true metaphors here and save the complex UI for the stuff that really is new.
• The “sort” box takes up useful screen real estate and yet needs to be changed almost never. Tuck it away, put it in a menu/pref/whatever. I’ve set it now, I’m done with it, I don’t want to see it anymore.
• “You have 23 pending issues.” Nice sentence structure, but just a nice big “23” would do fine, thanks. This little sentence looks like you forgot to delete a console log message in your Javascript.
• I can’t figure out what the little pin is for. “stick this queue with you?” — what does this mean? If it’s something useful, then expose it more. If it’s not, then get rid of the little pins, they just clutter up the place. update: they politely explained this to me. i’ve left it here so you can watch me eat my humble pie. note to self: RTFM, this is actually a really cool feature.
• the “State” of issues seems whacked. “assigned” does not seem mutually exclusive to “open” and “closed”. “new” seems useless. I would like “open” and “closed” — you know, can I safely stop looking at this thing or not — that’s all that really matters. > update: it sounds like they’re going to do exactly this.
• “Resolving” an issue sets its state to “closed” make the action/state/property all having related names.
• In some places the thread is referred to as a “conversation” in others it’s referred to as an “issue” and at the end it’s referred to as a “discussion” — pick one.
• The markdown Preview is modal. This means the Esc key should be used to dismiss it.
• Keyboard equivalents sure would be nice everywhere.
• Every comment is editable by me (admin). I don’t feel like i should be allowed to edit other people’s comments - at least not without passing through a few “are you sure you want to exercise your admin privileges like this.”
• In a conversation there is an “edit remove/spam” for the whole conversation in the toolbar. then at the top of each message there is an “edit remove/spam” for each comment in the conversation. It took me quite a while to figure out how these were different. It would be nice if they were differentiated in some way.