Swings and readouts

07 November 2007

My colleague Lars has just bought an Epson R-D1. If you’re not aware of it, it’s a digital rangefinder (roughly modelled on a Voigtlander) that takes Leica M Bayonet lenses, is hard to find, and noticeable cheaper than a Leica M8.

Epson R-D1

It’s obviously a niche camera: M lenses aren’t common nor cheap, the rangefinder is hardly a mass-market camera paradigm these days, and it’s largely manual – aperture priority, manual focus.

One thing that really caught my eye – and that I initially dismissed as ersatz Japanese retro-fetishery – was the readout on the top. Which looks like this:

To explain: the largest hand, pointing straight up, indicates how many exposures are left on the current memory card. As you can see, the scale is logarithmic – 500+ is the maximum, and as it counts down, the number of remaining exposures is measured more accurately.

The E-F gauge at the bottom measures not fuel, but battery power.

The left-hand gauge indicates white balance – either auto or one of several presets.

Finally, the right-hand dial represents the image quality: Raw, High, or Normal.

Once you know what it means, it’s a wonderfully clear interface: your eye can scan it very quickly. It’s also hypnotic watching it update. To alter the image quality, for instance, you hold the image quality lever with your right hand and move the selection knob (positioned where the film-rewind would be on a Leica) with your left. As the quality alters (and the rightmost needle flicks to the appropriate setting), the exposures-remaining needle swings around to reflect the new maximum number of pictures.

You can’t always see the benefits of analogue readouts in still photographs; this one is a case in point. Once it starts moving – and you start having a reason to check that readout – their clarity becomes immediately obvious.

So whilst I may have thought this kitsch to start with… it turns out to be one of my favourite features on the camera.

(As for that manual “film advance” lever… I’ll write about that in another post. It’s something I found similarly kitschy to begin with, but understood in the end.)

design , , , , ,

S60 Touch: flip-to-silence

02 November 2007

So, the latest version of Nokia/Symbian Series 60 has been previewed. There’s even a swanky video for it:

I’m still thinking about a lot of it. It’s clearly aiming at a slightly different market to the one Apple’s gunning for. There’s an interesting separation between “stuff that needs a stylus” and “stuff you can do with fingers/thumbs”. In reality, I think people veer towards thumbs if possible. Does that mean they’ll ignore the UI elements that are so small they need a stylus? Not sure. I haven’t given that enough thought, as I said.

The best bit of the video, though, is nothing to do with touch. It’s the bit where the model silences the phone ringing on the coffee table simply by physically flipping the phone over.

As an interaction, that presumes a lot. It presumes you leave your phone out, and if you do, you leave it face up. Many people leave their phones out (so they can see them skitter across the table when a call/SMS comes in) but face down, so the screen doesn’t annoy them. (Blackberries, with their persistent flashing light, are a prime candidate for face-downing). At the same time, it embraces that behaviour: when the screen lights up, you hide the screen and the phone silences. I like that.

Of course, you could do that on any old phone with a cheap accelerometer inside it. I wish it wasn’t part of some “premium” touch interface, but part of a lowest-common-denominator combination of hardware and software. Oh well.

design , , , ,

Connecting Rails to legacy databases

01 November 2007

Connecting Rails to legacy databases isn’t actually that hard – depending on the database you start out with. Recently, we needed to perform some statistical analysis on a large Movable Type database. Rather than wrestling with endless SQL queries at the prompt, it made sense to abstract out a little and build some kind of modelled front end to the statistics.

The most obvious tool for me to use was Rails; I’m familiar with it, I like the way ActiveRecord works, and it means that I can poke around the database from script/console if I need to.

The reason this turned out not to be too hard is because whilst Movable Type doesn’t conform to Rails’ opinionated ideas of what a schema should look like, it is still a well-designed and normalised database. Because of this, we can teach ActiveRecord to understand the database.

First of all, we start by creating our models: for our needs, Blog, Comment, Post and Author. We generate them in the usual manner – script/generate model blog. Once we’ve done that, we delete the migration files in db/migrate it creates, because we’re not going to use them.

Next, we point config/database.yml to the Movable Type database.

And then, we build our relationships thus:

class Blog < ActiveRecord::Base
  set_table_name "mt_blog"
  set_primary_key "blog_id"

  has_many :entries, :foreign_key => "entry_blog_id", :order => "entry_created_on"
end

class Entry < ActiveRecord::Base
  set_table_name "mt_entry"
  set_primary_key "entry_id"

  has_many :comments, :foreign_key => "comment_entry_id"
  belongs_to :blog, :foreign_key => "entry_blog_id"
  belongs_to :author, :foreign_key => "entry_author_id"
end

class Comment < ActiveRecord::Base
  set_table_name "mt_comment"
  set_primary_key "comment_id"

  belongs_to :entry, :foreign_key => "comment_entry_id"
end


class Author < ActiveRecord::Base
  set_table_name "mt_author"
  set_primary_key "author_id"

  has_many :entries, :foreign_key => "entry_author_id"
end

The set_table_name method tells the ActiveRecord class what table to look at, and the set_primary_key method does exactly what it says on the tin. (It also makes sure that #to_param works correctly based on whatever our new primary key is, which is handy). Beyond that, we simply have to specify the foreign keys on our relationships and everything plays ball; we can now access blog.entries just as we do with a typical Rails setup. It’s now easy to write the rest of our Rails app – model methods, controllers, views – just as we normally would. We’re just using the MT database to pull out our data.

And if you’re wondering: yes, it made the manipulation a lot easier, and a few hours poking at the console began to yield some interesting algorithms to apply.

code , , , ,

Rattling

30 October 2007

The other night, Matt was showing me his newly unlocked iPod Touch. I was playing with the shell application – just poking around, running top, etc – and rotated the iPod onto its side, just to see if the screen-rotation stuff worked in the third-party application.

After a while, Matt picked up what I was doing – as I poked around, when I found an app that felt like it should have a horizontal view, I would tip the iPod over, wait a second, and then tip it back.

It reminds me of a running joke my parents had with me ever since I was little. I used to pick up Christmas presents and shake them, and if they rattled, I’d assume that they were Lego (Lego, at the time, being the only kind of present I got that rattled). Ever since, we’ve always joked that rattling presents are Lego. And just like I rattled presents to see if they had the potential to be Lego, so you “rattle” the iPod to see if an application has the potential to be rotated.

You don’t necessarily need a visual signpost (an icon or alert) that such functionality is available; you just rotate the device, wait a second, and then flip it back. As a user, you’re interrogating the user to see if that particular interaction is possible. Is that good design? In some kinds of interaction, I don’t think so; you don’t want to poke every button or crawl through every menu just to find out what is or isn’t possible.

With the iPod/iPhone, though, we’re not crawling menus; we’re just interrogating the device to see if it supports a single kind of interaction. We only want a true or false back from it. Couple that boolean response with the simplicity of the accelerometer interface, and these “rattling” interactions come at a much lower cost.

I like rattling as a metaphor for this kind of interaction; it’s the equivalent of responds_to? in Ruby, I guess. What are other good examples of rattling-type interactions I’m missing? And how good are the implementations of it in software or on the web?

design , , ,
more recent posts | earlier posts