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._______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
