Sweetness.

- August 03, 2010
Read more about:

When you see this kind of demo, you know a technology is just about to explode. It’s part of the lifecycle, people.

- July 26, 2010
Read more about:

ChatRoulette, Elevators, and Panopticons

My wife and I – and millions of others, I’m sure – are continually annoyed by folks who walk up to elevators and press buttons already lit.

Though not a new phenomenon, we think we have a solution.

If pressing a lit elevator button were to cancel the call and simply send the machine to the nearest floor in the current direction, there would be a penalty to pressing it more than once.

The interesting thing about this idea is that it need not be universal. Instead, elevator designers could follow the lead of Jeremy Bentham and create a panopticon-style system in which some small portion of elevators operate this way. It only takes the fear of looking like an idiot to regulate behavior (most of the time).

ChatRoulette Weirdos

As ChatRoulette takes off, it’s becoming plagued by pervs flashing their junk or otherwise being slimy. It’s certainly expected, as the anonymity provided by the web brings out that side of people. It’s just a fact of life on the Internet: if there is an opportunity for a guy to flash his weiner anonymously, he will.

And that’s fine. It’s the way of the world. It’s the way of the web.

But so, my friends, is community moderation.

Enter ChatSnapper

Let’s try an experiment.

  1. Follow @ChatSnapper on Twitter.
  2. DM or @reply to @ChatSnapper with a link to a screenshot from ChatRoulette (or other online chats) showing offensive (or just weird) behavior.
  3. Check posted links and help shine a light on the offenders.

Let’s see if the existence of a rogues’ gallery has any effect on the actions of folks.

If this works, I’ll start calling elevator companies.

ADDENDUM

Alex Bisceglie alerted me to a similar effort: ChatRoulette Cock Map. It includes an app that can track the IP of offenders as well.

The very moment that Alex sent that, I was working on a WebKit browser with screencap and yfrog upload. For now, grab a build at: ChatSnapper - Alpha.

- February 17, 2010
Read more about:

Too Much Buzz!

Today, Google launched a new product, Google Buzz, which is being touted as a Facebook killer, Twitter killer, and probably the killer of a few other things.

If the name – or functionality – sounds familiar, it’s because at least two other companies have launched (basically) the same service using the same name.

Yahoo! has Yahoo! Buzz along with status message integration into Yahoo! Mail.

The domain, Buzz.com, is owned by AT&T and is… a social network for small and local businesses.

I hereby decree, as a passive armchair quarterback of the internet, that we retire the word “Buzz” along with any associated products, from today forward.

BTW - there is only one true Buzz on the internet.

- February 09, 2010
Read more about:

Amazon vs Apple Has Gone Too Far

I received a message from Amazon this morning letting me know that the Kindle Developer Kit application process was ready for the general public. I clicked the link and was taken to the KDK site, only to be told that Safari isn’t supported.

Kindle Developer Site Screenshot Showing Blocked Safari

Amazon was nice enough to give me a link to download Internet Explorer, so at least their user agent sniffing is tuned to perfection!

- February 08, 2010
Read more about:

Marketing the iPad

Overall, I think the iPad is an interesting device and once the dust settles I think the price point will be attractive for a supplement to our “main” computers. The iPad will fill a spot for people who consume more than they create – a large audience, for sure, and one most of us fit into depending on context and day-part.

One criticism I have is the name. Many, many others have criticized the name because of the associations it brings to mind. There was a trending topic on Twitter called “iTampon” that sums it up.

Apple is smart, though, and a Wednesday release means the “iTampon” reactions will be old, lame, and boring by Monday.

No, the reason the name iPad bugs me is more subtle, and more of a long-term marketing problem.

My gripe: the name is differentiated from the iPod by one letter - a soft vowel. It’s an almost meaningless distinction, and crams the iPad into the same cognitive bucket occupied by the many iPod releases.

Why is that a problem? Because the strongest (non-tampon) negative reaction I saw was that the iPad seems like a slightly larger iPod Touch.

If Apple is ok with that comparison, and with these products being differentiated only by size…well, fine.

But I think the iPad will take on a life of its own if it can get footing, and that life will always be anchored, from a marketing perspective, to the iPod.

A more inspirational, open-ended, and differentiated name would have been Canvas. No “i” prefix. New cognitive space. New brand trajectory.

Instead, we’re stuck with (an image of) the iPod that won’t quite fit into our pockets. After the more immature associations fade, that is.

- January 28, 2010
Read more about:

Kindle vs Apple iPad

Many have chimed in, ahead of the Apple tablet announcement, on whether the new Apple device will be a “Kindle killer”

I don’t believe this will be the case. It’s not so much about the pros and cons of e-ink, backlights, or screen resolution.

To me, the Kindle DX is a brilliant device because it forces me to read a f’ing book.

No dock icons blinking. No compulsive checking of Twitter, email, or stock quotes (or Texts from Last Night).

By offering a limited set of functionality and doing less, better, the Kindle forces me to eschew the kind of distractions that make me curl up with a book in the first place.

Apple can create the be-all, end-all Surface or Canvas or Slate or whatever. I will buy it. I will buy the shit out of it. I’m a developer and UX geek (and yuppie hipster scum) - I have to.

I won’t use it to read novels, poetry, or prose. Magazines and news? Sure. Tech books? Maybe, if live docs and errata were part of the mix. But then, that type of reading is work, not pleasure. Not therapy. That’s where the Kindle shines.

I have looked at (an early version of) the Kindle development kit (the KDK) and though I’m tempted to create apps focused on distraction (Twitter client, anyone?) I don’t think I’d run them. Instead, I’m trying to dream up apps that boost the escapism the Kindle already affords me.

So far, nothing beats the core function: making me crave reading as much as my first library card did.

- January 25, 2010
Read more about:

Cartilage: A Monk Skeleton for DataMapper

I created a skeleton for MonkRb that leverages DataMapper and, of course, Sinatra. Check it out: Cartilage. Add it to your Monk set up with the monk command.

monk add cartilage git://github.com/tobyjoe/cartilage.git
Once it’s added, create a new project with the monk init command.
monk init --skeleton=cartilage myapp
Once that is done, freeze all the dependencies.
dep vendor --all
Easy as pie, right?

Contributions

I want to add optional memcached support to both Cartilage and Lazybones. If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker. Cartilage is based on the original skeleton that ships with Monk, by the way.

- August 28, 2009
Read more about:

Lazybones: A Monk Skeleton for CouchDB and Sinatra

I created a skeleton for MonkRb that leverages CouchDB and Sinatra. You can find the project over at GitHub. Check it out: Lazybones. Add it to your Monk set up with the monk command.

monk add lazybones git://github.com/tobyjoe/lazybones.git
Once it’s added, create a new project with the monk init command.
monk init --skeleton=lazybones myapp
Once that is done, freeze all the dependencies.
dep vendor --all
Easy as pie, right?

Contributions

I am working on skeletons for Postgres and MySQL as well, and adding optional memcached support to all of them. If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker. It’s based on the original skeleton that ships with Monk, by the way.

- August 27, 2009
Read more about:

UX in Bed

One of the questions I ask when working on a new project is, “Where will people use this?”

The question is obvious for mobile projects because highly variable environments are par for the course. It matters with all non-stationary touch points, though – from door handles on train cars to Android applications to the work we’ll surely be seeing from the new Schematic Touch group.

Asking the question is easy. Using the response may not be. I see mobile apps all the time that are clearly made for users who are stationary, physically stable, connected to a consistent network, and with both hands free for interaction. High demands, right? They conflict with my more common usage patterns, and those apps rarely get launched.

A great example of a more subtle conflict – and one being addressed without much fanfare by many app developers – is iPhone usage in bed and auto-rotation.

Welcome to My Boudoir

My wife and I are incredibly lame. We tend to lie, side by side, reading news on our iPhones before falling asleep at night.

Apps that auto-rotate when the device orientation changes suck in bed. Or on the couch. Or in a reclining seat in first class. Or in a hammock. You get the point.

The problem is that we all flip-flop all over the place in bed (va-va-va-voom!), changing the point of reference for orientation. What makes a lot of sense when we’re upright is a pain in the ass when we’re horizontal.

A Suggestion

I’d like to encourage developers to carefully consider auto-rotation. A lot of devs are starting to catch on to this one as customers complain or make feature suggestions. I thought I might provide an example illustrating a really easy approach to disabling auto-rotation globally in an app. There are more sophisticated and pattern-y ways for the clever.

Don’t get me wrong – auto-rotation can be a great feature. I am all for it. But I have decided the baseline rule should be: If your views auto-rotate, you should provide a (preferably in-app) preference for disabling the feature.

An Example

So how does a developer do that?

Well, the interface is up to you. Let’s assume you have a project with a button that brings up an in-app settings screen.

If you have a UISwitch in there that represents the global auto-rotation state, just save it to the user defaults when you close the settings.

- (IBAction) dismiss:(id)sender
{
    // Update the defaults.
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    BOOL autoRotationEnabled = self.autoRotationSwitch.on;
    [defaults setBool:autoRotationEnabled forKey:kAutoRotateKey];
    [defaults synchronize];

    // Close!
    [self.parentViewController dismissModalViewControllerAnimated:YES];
}

In your app delegate, declare a method to get the current global auto-rotation value.

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return [[NSUserDefaults standardUserDefaults] boolForKey:kAutoRotateKey];
}

Finally, in each view controller that should obey the globals, ask the app delegate for the scoop.

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    PillowTalkAppDelegate *appDelegate = (PillowTalkAppDelegate *)[UIApplication sharedApplication].delegate;
    return ([appDelegate shouldAutorotateToInterfaceOrientation:interfaceOrientation]);
}

Here is a quickie example project that illustrates the concept: PillowTalk.zip

- August 21, 2009