Skip to main content

User Interface and Market Size

When cars were new, a hundred years ago, each had different arrangements for the controls. There were hand throttles, foot throttles - originality was more important than consistency. Those were the days when a European automobile executive foresaw a market for a million automobiles, since that was his estimate of the number of peasants intelligent enough to be trained as a chauffeur!

The consistent user interface observed in all cars is a prerequisite
to their omnipresence. Imagine getting into a rented or borrowed car
and needing to figure out where the controls are. In the late eighties
I remember being unable to use a friend's car, unaware you have to
push a button to turn the key. But muscle memory is even more
important. Driving on British highways is not a problem, you stay in
your lane with all the other people. But when you're going down a
narrow country lane with hedges either side, and a lorry comes around
a corner up ahead, my Canadian instincts take me the wrong way, and I
need to make myself pull to the other side to allow him to pass.

Until a couple of decades ago, motorcycles focused on creativity
rather than consistency in their user interface. It's so much easier
now, when you can get on any bike and know the left hand controls the
clutch, the right hand controls the throttle and front brake, the
right foot has the rear brake, and the left foot the gears ... one
down, four or five up. While a distinctive arrangement traps users
into sticking with the brand they know, consistency across brands
increases the market. Once someone learns to ride a bike, they can get
on any machine and go for a ride. You might stop riding for a while,
focusing on family or work or other activities, but you can come back
to it.

Similarly, consistent, well defined mechanical and electrical designs
allow for a wide range of third party accessories. At one time, some
cars had six volt batteries and some had twelve, so you had to be
careful buy the right bulbs. Imagine if you needed to get the correct
voltage GPS. Oh yeah, cell phone adapters.

Currently, camera flashes and studio lights are seen as a high markup
product which trap users in a particular brand. If you use Canon
flashes on Canon cameras, or Nikon flashes on Nikon cameras, the
camera can control the flash to get the right amount of light. With
the right brand of wireless controller, the flash can be used
off-camera, allowing more sophisticated lighting design. But the
camera companies can't be bothered to get approval in every country
for a radio device, so you're limited to lilne-of-sight, and to
moderate distances. There are wireless systems that trigger any flash
or any studio strobe. But if you want more sophisticated control, you
need the brand that goes with the strobes you have.

Why can't flash and strobe and trigger designers be creative, instead
of slavishly imitating what's been done before?

I hardly ever use my flash actually on the camera ... David Hobby
would scold me if I did! I don't need a hot shoe on a flash, but a 1/4
x 20 threaded hole would be nice. The flash might come with a post to
fit in a light stand swivel. But that swivel might be totally
unnecessary if the flash head had something to secure an umbrella
shaft.

How about providing some of the flash's battery power to feed a
third party wireless trigger? It's stupid to need one set of batteries
for the flash, and a separate set for the trigger. How about providing
a small space within the flash itself where a third party trigger can
go? It only needs to be one inch by two inches by half an inch. Two
small screws, one at each end, physically secure the trigger and
provide electrical connections as well. A micro-power bluetooth
connection with a range of a few inches would provide the interface
between trigger and flash. A flexible protocol along the lines of
MIDI could provide universal requirements while allowing customization
and expansion. If a company can't be bothered to deal with the US
regulatory body, or the Canadian, or the British, someone would fill
the gap. Cameras and studio strobes could similarly allocate a small
space for a transmitter.

Imagine if you could position your lights and then control them from
the camera, to adjust levels, and perhaps other characteristics, for
key, fill, rim, hair and the Joey chin light. The camera isn't a
very convenient interface, usable if necessary, but perhaps the
Photoshop operator can double on adjusting lights, at the computer. If
you're a location kind of shooter, maybe an iPhone interface is what
you want.

It's only taken me a few minutes to conceive of a better world. If
camera and strobe manufacturers worked together to standardize a
single interface, imagine what some really creative designers might
come up with.

Comments

David said…
Tom-

Whoa, man -- pretty deep thinking there. There are actually people thinking of using the flash power to do the remote thing. But it is a can of worms because there is no power connector standard.

Keep it up. The world will catch up to you one day.

Best,
David H
Holly Cornfield said…
Would you like some cheese with your whine? ;-D Sounds like a good idea. Why not go patent the idea and wait for someone to design it for you and make you fabulously wealthy?

XOXO,
Holly

Popular posts from this blog

Creating Perl5 Objects with Moxie

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless()-ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core.

One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict. As well, the features or the perl you are using are enabled, among them say, state, signatures, and post_deref.
A Simple Moxie Class package Card { …

Perl5, Moxie and Enumurated Data Types

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language.

I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz<. So I was delighted to recently see an announcement of the module Moxie, and decided to try implementing a card game.

While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets.
Creating an Enum package Ranks { use Moxie::Enum; …

Adventures in Autovivification

Having recently started a new job, I was exposed to old code with multi-step tests against autovivification in multi-level hashes. You get used to the code you have seen, but in a new environment it‘s irritating and jarring.
Moose does not generally have the problem, first because class structure is pre-declared, because values are accessed using accessor functions rather than directly, and because responsibility is delegated down to attributes, avoiding long chains. On the other hand, Moose has it's own overhead, so hand-rolled objects, and bare structures still have their use.
If you don‘t protect against autovivification, then mis-spelling a key, or referencing keys which haven‘t been instantiated in this instance, causes those keys to instantly come into existence.
#!/usr/bin/perl use warnings; use strict; use Data::Dump 'dump'; use 5.024; my $var = {key1 => {key2 => {key3 => 'a'}}}; say dump $var; if ( $var->{key1}{key2}{key3b}[13]{foob…