DC vs MC for novices (was Re: [RevDocs] Sorry for barging in, but..)

[Richard Gaskin]

Hey Jerry -

Good to see you here.  I'm very, very late getting back to you on a kind 
email you sent a few weeks ago, but I got it and am glad to see you 
participating in yet another developer community I hang out in:

 > The point at issue is the extent to which the Dreamcard
 > (DC) interface is "too complex" to be dealt with effectively by a
 > novice, and whether MetaCard (MC) is a better alternative.

As the project manager du jour for the MC IDE, I can say that most 
daunting thing about it is setting it up.  I've created a Rev plugin 
called FlipsIDE which allows one to easily flip between multiple IDEs, 
but it may be some time before I'm able to resolve a few niggly tech 
isues with RR on that.

 > I personally think MC's interface is too lean;

I agree.  I've been lambasted for this, but I often use the term 
"Spartan" to describe it, and I don't mean that in the sense of being 
"strong" or "a good fighter", but merely as an abstract reference to 
Sparta's near-poverty by having one solider for every seven citizens. ;)

Those of us who use it do so for specific reasons, but it's worth noting 
that it was designed for Raney's core audience, comprised mostly of pros.

 > and I've seen kids work with programs that seem visually overwhelming
 > at first, like Dreamweaver, quite effectively.

Agreed.  Review the use-rev list:  the UI isn't where people are getting 
stuck.  It's the conceptual underpinnings that drive the UI (and the 
language and everything else) that people ask about.

Learning conceptual abstractions like the message path, using 
parameters, different types of variables, etc. can often be tremendously 
aided with conceptual illustrations, but it's not possible to address 
them at all with videos of the UI.

 > ...some of these icons (Geometry, Database, Property Profiles)
 > will also go mostly unused by novices.

I've always considered those as advanced features, along with most of 
the options in the App Builder.

While time-saving, they introduce more stuff to learn between first-run 
and making one's first standalone, and it benefits the user (and one's 
conversion rate) to removes as much as possible from that "Critical 
Path" of the learning process.

Some day I'll have time to put my time where my mouth is and write an 
Absolute Transcript Virgin's 'Hello World' Tutorial, which emphasizes 
the shortest path from double-clicking Rev to double-clicking their own 
standalone.

It's absolutely essential to establish a simple "confidence target" as 
soon after first-run as possible.  Even if the standalone does nothing 
at all of significance, the act of creating a standalone is inherently 
satisfying and tremendously motivating toward learning more.

If the path between first-run and first-standalone gets cluttered with 
too much detail, even if that detail would eventually become useful it's 
the wrong moment to introduce it.  Be patient, explain the nitty gritty 
later after you've unquestionably grabbed their attention.  Without that 
first moment of satisfaction there is a high risk that none of the other 
details will be ever used at all, as the user may have lost interest 
before then.

It's that "Critical Path" that gets lost with so many app designs, when 
designers get so enamored of the features they've worked so hard to 
deliver that they forget the single most critical reason people want to 
use their app.

That's one of many lessons from film school that's served me well in app 
design:  it doesn't matter if a shot took several days to get and cost 
you a fortune -- if it doesn't drive the story forward it gets left on 
the cutting room floor. :)

The nice thing about software is that we don't really need to leave 
anything out entirely, just use careful judgement about the order in 
which we introduce things, as you suggest here:

 > ...one could try to impose something like HyperCard's old "User
 > Levels" where lower levels simplified the menus and some of the
 > dialogs.

While user levels per se may not be the answer, the broader principle of 
Progressive Disclosure is likely very relevant to adoption.

I agree that an entry-level product requires a separate UI, for both 
learning and marketing reasons.  We've already seen one scathing review 
which occured only because the reviewer couldn't adequately distinguish 
between DreamCard and Rev; he was applying professional criteria to the 
entry-level product.

So bringing this discussion full-circle, there may be one area where the 
MC IDE can be useful:  It's free and open, governed under the very 
liberal X11 license.  This means that anyone can take it and morph it 
into any other flavor of IDE they want.

At one time Alain Farmer started down the road of making a fork of the 
MC IDE aimed at delivering the HyperCard experience to the Transcript 
world.  The project is not complete, but could be carried forward with 
some assistance from others.  It's home is 
<http://groups.yahoo.com/group/freeGUI/>.

And once I finish FlipsIDE, users can flip between the IDE of their 
choice in one click.

So ultimately one vision for this is an engine so powerful that it can 
flex its muscle in an infinite variety of customized workflows, so that 
no matter what the user's preferences are the answer with Rev would 
always be a resounding "Yes!"

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev