Computers as Theatre (was Re: Signed RSL from Apache)

[Alex Harui <ah...@adobe.com>]

On 2/21/12 2:33 AM, "David Arno" <da...@davidarno.org> wrote:

> Is this on your whiteboard yet so that we can all take a look? If not, I
> look forward to you putting it there soon as I'd be interested in how you
> achieved this.

I don't even have a whiteboard folder yet.  And it looks like these
prototypes needs legal clearance before checking in.

The basic principle is that once you have carved UIComponent and other
framework classes up into chunks the core UIComponent, LayoutManager and
StyleManager needed to render a Label and TextInput and some graphics fits
in about 80K which can be downloaded and rendered in about 1 sec over DSL
and VPN.

Let's say you have an app with a login dialog.  Instead of a making the main
screen the initial state, your initial state is the login dialog, since
that's what the user will see first.  As the player displays that login
dialog, the rest of the code is streaming in in the background.  It is the
developers job to design subsequent states that don't have huge
dependencies: putting a DataGrid in the second state would be a bad idea,
putting a wireframe image of a DataGrid would be a valid substitute.

Usually, it takes a person two or 3 seconds to log in so by then you've got
a whole bunch of other classes downloaded.  As long as you don't switch to a
state that requires a class you haven't downloaded, you are fine.  I added
some logic so that when a state finishes rendering, you can automatically
switch to a next state.  That way, you can effectively script a "reveal" of
the main screen.

By reducing the interdependency of classes in the framework, it becomes
possible to pack various classes on different frames and carefully
choreograph the "opening act" of your app, which sounds like a lot of work
(and is), but brings me to the inspiration for this scheme: Brenda Laurel's
book "Computers as Theatre".

The book was a difficult read, and not quite targeted at standard apps, but
my takeaway is this:  Theater play designers have to deal with reality (as
opposed to movie directors who can make any reality).  In live theater, you
can't just cut from, say a busy street seen to inside someone's house.  It
takes time to move people off the stage and move a sofa onto a stage or lift
or drop a backdrop.  Theater play designers use lighting, focus,
distraction, suspension of belief and other tricks to make it all happen.
This prototype explored allowing SWF designers to employ similar tricks in
the setup of their SWF in order to leverage the frame-based nature and
streaming capability of Flash to carefully script the opening of their apps.

The main screen then isn't the initial backdrop (state) because it requires
a lot of code the create it, but you can design a sequence of initial states
to get there.


-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

RE: Computers as Theatre (was Re: Signed RSL from Apache)

[Rui Silva <fl...@rduartes.net>]

Computers as Theatre it is, Alex.

I'm liking a lot what I read and start to understand what you've been
hinting at in other posts. Looking forward to look into your code and
understand your ideas in more detail.

Rui