Re: iWork Pages
Re: iWork Pages
- Subject: Re: iWork Pages
- From: has <email@hidden>
- Date: Wed, 26 Jan 2005 11:38:03 +0000
Bill Briggs wrote:
my first reaction to [Automator] is that it will be lame for anyone who can't
already engage in the mental process that you do when you write code.
There are lots of ActionScripters, AppleScripters, JavaScripters who
aren't very good at that either, yet they still manage to achieve
some very useful results for themselves. And Automator is much less
conceptually complex than a general-purpose programming language:
from the information available it doesn't appear to have datatypes,
variables, flow control, higher-level structures, or any of the other
things you have to learn to become productive in a general-purpose PL.
About the only two things Automator does seem to have is commands and
pipes, which puts it just about the same conceptual level as DOS.
However, unlike the DOS CLI, which is cryptic nor opaque, Automator
is completely WYSIWYG, therefore:
- It's highly transparent. Users don't have to memorise a bunch of
invisible commands and their arguments before they can use it. All
available operations are visible on-screen in a scrolling list,
allowing users to browse, search, and hunt-n-peck for commands
(Actions) as they need. And each command displays up-front all the
options/features/arguments/modifiers that it supports via a
collapsible window pane. Hopefully individual tool tips and full help
are built-in too.
- It's much more robust and forgiving. Only those interactions that
make sense are permitted. Unlike the CLI where any old gibberish can
be typed in, commands only accept those arguments (clicks on
checkboxes, text typed into text fields, etc.) that make sense, and
will provide instant interfactive feedback if the user tries to enter
invalid settings. And the composition of multiple commands into
longer workflows is assembled via drag-n-drop, so should be pretty
immune to input errors too.
These are the essential advantages that won the GUI/CLI war at the
application level, because they meant users could more easily learn
how to use the system as they went along, and wouldn't be punished so
badly when they make an honest mistake. And that matters, because the
shorter the learning curve to the point where users can start to do
something productive, the more useful that system is to them.
Remember, most folks aren't in it for the abstract joys of ivory
tower learning: the _only_ thing they care about is Getting Things
Done, and as quickly and as safely as possible.
I'm open to being proved wrong, but I think there are limits to what
you can do to simplify things that require a logical thought process
to implement.
I see very little 'logical thought process' in many first-time
scripters' attempts to code (including, from memory, my own). What I
do see are things like guesswork, intuition, borrowing and tweaking
of existing third-party material, construction via accretion,
trial-and-error testing, wing-and-a-prayer usage, rolling back
changes where things go wrong and trying again (undo),
run->stop->perform a step manually->resume, and so on. All of which
are perfectly valid approaches to Getting Things Done by the way, and
hopefully Automator will go an awful lot further than most -
including AppleScript - towards acknowledging and actively supporting
this way of working. Cos there's an awful lot more of them than there
are of us, and I think it's about time they had some champions too.
Power to the People, baby!
I guess we'll all find out.
Indeed. Fun, isn't it? <g>
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden