Questioning convention as a programmer (was: Showing unsaved status for document-based windows)

[Ian Wood]

On 13 Jan 2008, at 00:06, Randall Lee Reetz wrote:

> These are just straight forward questions that question convention.

I think this is worth spinning off into a new thread as it's an  
interesting topic by itself, and particularly apt to Rev.

For many of us, questioning convention is a necessary part of the  
'creative' side of programming - by thinking outside the conventional  
way of doing things we come up with new ideas, shortcuts, workflows  
etc. and there can be a lot of enjoyment in it as an intellectual  
process.

The problem then comes when we evaluate whether this new method/ 
concept we've thought of is actually better* - sometimes the  
convention is that way because it's the best compromise for the  
situation.
To put it another way - clichés become clichés for the simple reason  
that they are based on situations that occur again and again (and  
again and...).

The reason I think this is particularly relevant to Rev users is the  
relatively low entry barrier in terms of programming background - many  
of us on the list have no formal background in programming (on my part  
nothing more than a bit of Basic and Logo 20 years ago at school) and  
therefore don't know any programming conventions.
The very structure of the system/language/whatever seems to inspire  
innovation - someone on the list several years ago (Richard Gaskin,  
Dan Shafer?) had a pithy phrase about the Zen of Revolution, about Rev  
being what you made of it.

EDIT -  a quick attempt to find the quote via Google throws up a  
surprisingly large number of references to Zen in this list. ;-)
<http://tinyurl.com/2lgjmj>

Or maybe it's just the various ways the docs have been (dis)organised  
over the years. Grin.


The other main consideration being the target market. If it's a bit of  
code or an app for your own use then you just use whatever works best.  
As soon as other people are involved it's a different matter,  
especially for commercial software, and doubly-so if aiming at the Mac  
market.
For distributed software, convention can be used as a type of  
shorthand - you don't generally need to explain that Command**-S will  
saved the document, or explain Command**-X/C/V. People like the  
familiar and feel comfortable with it. Then there are the exceptions  
that suddenly take everything in a new direction...


Now, to make this even longer, I'm going to look at a couple of non- 
Rev apps that have particular relevance to me as a photographer -  
Apple's Aperture and Adobe's Lightroom. Call it a case study, if you  
like.

When Aperture appeared on the market it revolutionised certain types  
of photographic post-processing - it was truly the first widespread  
application that combined RAW*** conversion, general image adjustments  
and cataloguing/DAM (Digital Asset Management) features. Before it  
came out, we had no choice when it came to integrated workflows -  
there simply WEREN'T any.
You'd use Capture One, Photoshop/Adobe Camera Raw or some other  
dedicated RAW convertor to change your RAWs into something normal like  
a JPEG, or preferably a non-lossy format such as a (huge file size) 16- 
bit TIFF or PSD. You'd then catalogue those in iView Media/Cumulus/ 
Portfolio etc. You might also involve other apps for fast addition of  
metadata tags, Photoshop for image manipulation, Photoshop, InDesign,  
Qimage or similar for printing, etc. etc. A complex workflow might  
involve up to a dozen apps, with a few rare individuals and  
organisations starting to tie it all together with AppleScript.

Suddenly there was an app that did (or attempted) to do it all - RAW  
conversions, cataloguing, metadata, printing, web galleries, book  
design, slideshows etc. As extra sauce, you didn't need to bother with  
all those cumbersome 16-bit files either, as the RAW file was  
converted on-the-fly each time you looked at it, with each different  
variation you wanted being a few KB for the instructions. You might go  
from 15MB for the RAW file plus 70MB each for the variant versions of  
the image, to 15MB plus perhaps 1MB for loads of different versions  
and their thumbnails.
Similarly, the organisational structure was virtualised - as each  
image on screen didn't correspond to a distinct file there was no need  
to correspond to a folder structure in the Finder, in exactly the same  
way that iTunes doesn't - you had your main container for images  
(Aperture Projects, roughly equivalent to an iTunes library), and then  
you had your lower level of organisational container, the Album -  
equivalent to a Playlist, so images could appear in multiple Albums  
without there being multiple copies of it.
Next, as you're virtualising the images and any adjustments made to  
them, you can copy any of the adjustments with a couple of keystrokes.
Plus the reliance of Core Image, doing most of the image processing on  
the GPU.

As I said, revolutionary within it's field - it moved the goalposts  
for the entire photographic software industry, overnight. Even with  
the bugfest that was version 1.0.

Then come the problems (apart from early versions being buggy, not  
supporting many cameras and having insane hardware requirements). It  
was different from everything that came before, so everyone was  
learning from scratch. The sheer number of videos that Apple made  
available for showcasing Aperture was amazing, from day one there were  
something like fifteen of them up on the website, many being 5-10  
minutes long. The box came with an entire DVD of tutorials and barely  
covered the basics. The support forum was so busy it took down the  
entire Apple discussion area several times, although nowhere near as  
much as the iPhone a few years later...

A lack of conventional ways of working made it hard to master for new  
users.

On to Lightroom. After a long and at times painful beta testing  
period, Lightroom came out sharing a lot of similarities with  
Aperture. Virtual versions of images, RAW conversions, image  
adjustments, cataloguing, printing, slideshows and web galleries built  
in.
Somef big differences in operation, though. Unlike Aperture it's much  
more tied to the folder structure of your HD, simultaneously making it  
more familiar to the new user, but losing much of the organisational  
power of Aperture's purely virtual structure. It used a familiar RAW  
conversion interface, sharing most of it's conversion code with the  
ACR plug-in from Photoshop.
It was still fairly revolutionary, but it kept a lot more familiarity  
with existing applications, as you might expect as Aperture was  
Apple's first move into the field of professional photography software.

Currently there are reputedly four times as many Lightroom users as  
Aperture users, as Adobe's John Nack likes to mention (http://tinyurl.com/yrnahr 
), even though Aperture had around a year headstart. There are other  
factors such as Apple's notoriously tight lips when it comes to future  
info, Aperture's high hardware requirements and slow support for new  
cameras, Lightroom being cross-platform and from a company familiar to  
everyone for imaging.

But at least some of it is down to convention with Lightroom sticking  
to convention closer than Aperture, where Apple started with a blank  
slate.


That was rather longer than planned, but hopefully interesting.
Anyone else have thoughts of programming and convention?

Ian

*For a given definition of better...
** if platform is "windows" then replace "Command" with "Control" in me
*** For the non-photographers, RAW files are basically raw,  
unprocessed data from the sensor of the camera, requiring conversion  
into a 'normal' image file. The advantage being much greater control  
over the image.