Month: January 2010

A last-minute thought on Apple’s mythical tablet

It is widely rumored that Apple will be introducing some kind of tablet gadget about half a day after I write these words. It is also widely rumored that a key aspect of this introduction will be deals with major print-media publishers, who will be offering electronic versions of their books and periodicals on the mythical tablet.

Based on some of Apple’s recent work (eg, the iTunes LP format), it is reasonable to assume that these electronic text publications will be marked up in HTML5, CSS, and Javascript. Companies like the New York Times and McGraw Hill are going to need a production tool for flowing their content out in this new format, as well as all the other formats that they’re currently distributing. In short, they’re going to need something like InDesign, but designed for HTML and with the ability to include video, dynamic content, etc.

Ben Hammersley has been writing about electronic media and the future of journalism, but more from a different angle—from the original act of creating stories. But I don’t doubt he’s been thinking about the production side too.

What tool will that be and where will it come from? I doubt it will be Adobe’s GoLive, although that might work. I suspect (assuming all these other suppositions are correct) that Apple will be announcing their own software, taking another dig at Adobe. If all this is correct, it’s going to become an important software market.

And while Apple gets dinged (often justifiably) for a walled-garden approach to their products and services, in this case a win for Apple would be a win for the public interest. A publication format based on existing standards lowers the barrier to entry for other players; if Amazon decides they want to support this new format in the Kindle, they’ll just need to ensure they’ve got a standards-compliant HTML engine on it, and publishers will just retarget the Kindle with the same output. The formats may involve some kind of quirky or proprietary wrappers, but these would get laid on at the last step in the production process. It would be trivial to re-wrap the same payload for multiple devices. For any of these devices to succeed, of course, is another matter entirely.

Survey of iPhone bike-computer apps

I’ve written before about the iPhone’s potential and drawbacks as a bike computer. And there are a lot of bike-computer apps available for it right now. Let’s take a look at them.

I’ve gone on a bit of a kick lately and tried out four different ones. There are one or two others that I haven’t gotten around to yet. I hope to eventually, and will report on them in this space when I do.

Executive summary: Rubitrack for iPhone and Cyclemeter are clearly oriented towards performance cyclists; right now I’d give the nod to Cyclemeter. GPSies seems almost like a toy, but might be of use to hikers. Motion-X is for GPS otaku.

Chile Recipe 2010

For the past four years, I’ve been making chili for a new year’s day party, a tradition I borrowed from my mom. Every year I’ve varied the recipe a little, and I think this year’s batch was the best yet. I am documenting what I did here.

I’ve always used the Pedernales River Chili recipe as my starting point. This year I also consulted The New Best Recipe, an excellent cookbook with a recipe for Texas-style chili that looks very respectable.

This is a very large recipe. Most chili con carne recipes start with 4 lb of beef, so scale accordingly.

Ingredients

  • 9 lb chuck roast. It should be no surprise that the cut of beef makes a big difference in the quality of the final product. I’ve tried stew meat and it’s nowhere near as good. I also don’t care for chili based on ground beef (leaving aside the potential food-safety issues with that).
  • 2 large onions.
  • 3 cans diced tomato.
  • 18 tbsp chili powder. New Best Recipe observes that 2 tbsp of chili powder per pound of beef seems about right, and I agree. Speaking as someone who likes spicy food and has a reasonably good tolerance for spice, I’d describe the level of spiciness as a mild slap: enough to get your attention, but not enough to slow you down. Central Market has an outstanding selection of chili powder in bulk, and I probably spent 10 minutes sniffing at different jars. I brought home both New Mexico chili powder and House Blend. Gila Flats also seems like a good candidate. I wound up using about 10 tbsp of the New Mexico, 5 of the House Blend, 2 of ancho, and 1 of chipotle.
  • 4 tbsp cumin seed. As per New Best Recipe, I toasted this in a dry pan first. Actually, I only had about 2 tbsp and wound up adding cumin powder to compensate.
  • 4 tbsp dried oregano
  • 3 cups water. This is a very dry recipe. Partly out of necessity: I was running out of room in my stewpot.

Directions

  • Cube the chuck roast into roughly 1″ chunks.
  • Chop the onion coarsely.
  • In a large stewpot, brown the chuck roast in small batches and set aside.
  • Sautee the onions in the stewpot with the beef fat, adding oil as needed.
  • Add all the spices to the onions and continue sauteing for a minute.
  • Return the beef to the stewpot and add the canned tomato and water. Add a few dashes of hot sauce. Bring to a boil and then reduce to a simmer while covered.
  • After about 2 hours on the stove, the flavor wasn’t didn’t seem properly rounded out, so we added over a tablespoon of salt. That helped but didn’t quite do it either, so we added a tablespoon of cocoa powder, which did the trick. The chocolate turned out to be the magic ingredient.
  • Continue simmering for a couple hours, store the whole pot in refrigerator overnight, reheat the next day for serving. At no point did I skim the fat off.

Pulldock

The “unofficial Apple weblog” had a post calling on readers to submit their wishlist for future iPhone OS features, which got me to thinking.

Multitasking is an obvious shortcoming on the iPhone right now. Multitasking is possible: some of Apple’s own apps run in the background, and there are jailbreak apps that allow apps to run in the background and for the user to switch between running apps. But Apple does not allow app-store apps to run in the background at all, presumably because of performance and battery-life problems.

I believe that multitasking on the iPhone can be broken down into two functional categories: apps that you want to run persistently in the background, and what I’m calling “interruptors”: brief tasks that only take a few seconds to complete, and where you don’t want to break out of your current app. I’m concerning myself with the latter case here.

A jailbreak Twitter app, qTweeter, has the kernel of an approach to presenting these interruptors: it pulls down from the top of the screen like a windowshade, and is accessible any time.

This approach could be generalized to present multiple apps in what I’m calling a pulldock. There could be one pulldock that pulls down from the top, another that pulls up from the bottom, to present up to eight interruptors.

I envision these interruptors being stripped-down interfaces to existing apps or services, such as twittering or text messaging, that would appear in some kind of HUD-like view superimposed over the running app. Interruptors should be lightweight enough that they wouldn’t overburden the phone. I can also imagine new ways of passing information between a regular app and an interruptor—such as launching a camera interruptor while in the mail app as a way to take a photo and insert it into a mail message, which would save a few steps.

Here’s a screencast:

Yeah, there’s a lot of “umms” and sniffing in there. It’s the first screencast I’ve ever done. The visuals were done in Keynote using the template from Mockapp.