Read about: Everything, Advertising, Apple, Events, Media, Projects, Tech, UX, Web, Work, Writing, or Me

Subscribe via: Email or RSS

TobyJoe

Toby Joe Boudreaux on Tech, Creativity, UX, and All Things Digital

Check Out: True 8-bit Color Cycling with HTML5

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.

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.

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

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.

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.

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

monk init --skeleton=cartilage myapp

dep vendor --all

Contributions

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

monk init --skeleton=lazybones myapp

dep vendor --all

Contributions

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

Building Erlang on Snow Leopard

The macports install of CouchDB requires Erlang (naturally) and Erlang requires WxWidgets and Tk, which are probably pointless for most uses, and won’t compile on 10.6. Here is a patch for the Erlang Portfile that will let you build on pre-GM 10.6. Save the patch to ~/Desktop/erlang.diff

Patching icu

sudo port install icu

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/icu

sudo patch 

Patching Erlang

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/erlang

patch 

CouchDB?

Microsoft Deprecating IE6 the Right Way

I am pretty far from a Microsoft fanboy. In fact, most of what MS produces scares, worries, and downright nauseates me: UX, security, maintainability, compatibility…

Still, I like two things about this blog post about their Office web apps.

First, I like that they are officially focusing on (admittedly, a subset of) modern browsers for their very dynamic web apps. Developers and designers at Microsoft are just like the rest of us, after all: they want to do great work and hate clunky platforms and unfortunate constraints. Bravo for continuing the baby steps forward.

Second, I like that they aren’t blocking or filtering user agents. They are offering “unofficial” support to semi-modern and modern browsers. They aren’t showing upgrade notices that make users feel like losers. They aren’t blocking access as some goofy religious mission. They’re just being practical.

From the post:

If you prefer to use another browser you should still give the Web Apps a try. While we cannot officially support all browsers, customers will not be blocked from using them. It is a goal of the Web Apps to have broad compatibility and reach.

I hope (oh dear lord am I gonna say this?!?) others can follow in Microsoft’s footsteps here and be respectful to users.*

* Yes, I also know Microsoft isn’t the first to do this. I’m being snarky.