cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] from linkmaps to flowmaps
Date Tue, 06 Mar 2001 15:24:59 GMT
Stefano Mazzocchi wrote:
> 
> Berin Loritsch wrote:
> 
> > >  3) agglomerate links dependening on their order of
> > >     degradation, possibly on different pages.
> >
> > Maybe this is because I never got anything above a Recording Arts
> > Specialized Associate Degree, and learned how to program later; but
> > I am not quite sure what you are referring to here.
> 
> Take the college course case where the course is linked to a professor,
> a room and the students attending in this semester. All links have a
> degradation time of, at last, the semester. You should not place
> assignments links in the exact page, if the degradation time is much
> frequent (say, 2 weeks)... this calls for a separate page.
> 
> This is what I mean for "agglomerate isodegradating links" and might be
> used to evaluate the 'beauty' of a link topology, given the history of
> link changes.

I see.  This is assuming links to static pages.  Many educational web sites
suffer from ergodic information on static pages.  Since my primary concern
is with dynamic pages where the ergodic information is tied to a database
or some other model, and then rendered to the user, I tend not to think of
those concerns.  The information is guaranteed to be "fresh" or as current
as the Webapp allows.

> This is not only useful for web-apps but for web publishing in general.

True.

> > > an 'identificated flow' requires that the user is identified.
> >
> > In other words: the user is logged in or Authenticated.
> 
> Yes, but your terminology is incorrect at this abstraction level: the
> action of "log in" or 'authentication' are technologically specific. The
> user could be identifier by a retinal scan placed in front of his
> monitor, or by a DNA analyzer on the keyboard.

Got it.  In my mind (probably due to the physical security training I had
from a previous job), Authentication is the action of Identification.
One does not have an identity to the system until Authentication.  The
DNA analyzer, retna scans, log-in screens, and certificates are all methods
of authentication.  If for the purpose of speaking the same language we
use the word Identification, I can do that.  But the difference from
authentication and identification is this:

You are Identified if you have a unique identifier and your movements can
be tracked so that state can be managed for you.  This happens as soon as
a Webapp uses Sessions.  Authentication is one step beyond that, and means
that the system has a method of consistently identifying you as "Joe Bloe"
no matter where you connect from.  Certificates, Logging in, security cards,
and other authentication mechanisms provide this for you.

With the example above are you talking about a positive identification of
a particular person (i.e. authentication), or are you talking about a means
of tracking state for an individual (anonymous or not)?

> > > a 'restricted flow' is a specialized 'identification flow' that requires
> > > identification and belonging to a specific identification group which
> > > has enough rights to enter.
> >
> > Restated, the Authenticated user must be Authorized.
> 
> Yes, this terminology is equivalently abstract.

I am using standard security terms here.  Authentication and Authorization
are the aquivelent of having a Badge identifying you (authentication) and
the proper clearance/need-to-know (authorization) to get at information in
a particular room.

> > Let me interject
> > that many times the same record has different views based on the Role
> > or Authorization of the user.  For example, in the afforementioned
> > WebApp, a new Product that is submitted to a Retailer has information
> > that the Vendor must enter and view.  Once submitted, the application
> > is in a read-only state for that user--BUT THE FLOW HAS NOT CHANGED.
> > The next person in the WorkFlow, typically the one who manages a
> > specific Category of products has to review the submitted information,
> > and enter some proprietary information for the Retailer that only
> > internal users can view.
> >
> > Again, the information shown has changed, but the FLOW is the same.
> > Flow being described as the movement between one page of the form and
> > the next.
> 
> Yes. Exactly like sitemaps are static but can represent all the possible
> dynamic publishing needs, flowmaps are static but the resulting behavior
> is not so.
> 
> I believe that this "staticity" indicates the "beauty" of the
> projection, its a measure of the minimum possible concern overlap. So,
> the more "static" representations we find, the more expressive Cocoon is
> at describing and implementing web sites in general.

I like the idea of specifying that once a user enters a URI space, the
flowmap takes over.  Practically speaking, This is achieved by specifying
the stage (equivalent of a form and it's handler), and it's navigational
connections.

For example, use this subflow (assuming the user is identified):

<enter>-(role)->HeaderPage-(role)->LineItemX-+-(role)->CommentPage-<exit>
                                   ^---------|

Where the stages are identified here:

HeaderPage
----------
Generator (file) = header.xml
Transformer (Trax) = (role)2document.xsl
Transformer (Trax) = document2html.xsl
Serializer (html)
Handler (action) = DatabaseUpdateAction - dbheader.xml

LineItemX
----------
Action (select-lineitem)
Generator (serverpages) = lineitem.xml
Transformer (Trax) = (role)2document.xsl
Transformer (Trax) = document2html.xsl
Serializer (html)
Handler (action) = DatabaseUpdateAction - dbheader.xml

CommentPage
-----------
Generator (file) = comments.xml
Transformer (Trax) = (role)2document.xsl
Transformer (Trax) = document2html.xsl
Serializer (html)
Handler (action) = DatabaseUpdateAction - dbheader.xml

This pairing of handler to the form page and describing it as one page
is eminently useful.  I would be able to rearrange the stages at will
without breaking the functionality of the webapp.  This would require
the webapp to use something like <form action="cocoon-handler"> to
have it map to the dynamic handler.

> Hierarchical flowmaps make it very easy to evaluate the 'fully
> connection' of a flowmap... and an algorithm can easily estimate this
> automatically (or even draw an flowmap overall SVG poster with different
> colors for 'dead end' stages). Wouldn't it be cool to show that to your
> customers? :)

Absolutely!  Rendered in our Modified FlowChart or UML would be excellent.

> Even more: a "usability engineer" is normally a person that doesn't have
> a strong technical background. The flowmap is sufficiently abstract to
> allow the usability engineer to play around with the usability of the
> system without touching technical details or impacting on them.
> 
> Guess what? SoC :)

To a point.  Sometimes the usability engineer will dictate changes to the
page itself.  But the flowmap fills a major void that would otherwise be
costly.

> I've recently met IRL a girl that does this job for a major italian
> portal and she amazed me with the amount of design effort that she puts
> into tasks that seem apparently obvious.

I have a saying:

"If common sense were truly common, people wouldn't act so stupid."
  -Berin Loritsch

Basically it means that what's obvious to you isn't so obvious to someone
else.

You would be surprised at how much planning and design work goes into the
useability of a webapp.  You really have to know who you are targetting
your application to, and how they work.  For instance, we put *alot* of
time learning how our customers do things, and our first version wasn't
very user friendly, although it did everything it needed to.  We reevaluated
the application in light of the extensive research we had already done,
and you would be surprised at how much more usable it was to them.

It required a little training (really coaching), but once they got a hold
of the concepts behind it they loved it.  The repitition of those concepts
throughout the subapps made its overall useability better.

> I admit that part of the flowmaps concept comes from understanding her
> mental and visual processes that go into web-app design. And one thing
> for all: error handling!
> 
> There is no suck thing as "user error", the very act of calling some
> user "action" an "error" is egocentric since it forces a world where you
> decide what is right and the user must understand this in order to get
> accepted.

In more formal webapps (since that is my basis of reference) where you are
automating business processes, there is a clear concept of correct and
incorrect input.  That concept is defined by business rules, and not the
egocentric whims of the developer.  The form needs to be narrow enough to
guarantee that the information is properly validated, by flexible enough
to allow a *limited* amount of freedom.  Surprisingly, this very
narrowness--or one correct flow ideology--is exactly what makes these
types of webapps useable.  In an online store, there needs to be alot more
flexibility, so again there are two very different methods of approaching
things because of the needs of the customer.

> This creates frustration, expecially on older people which are not used
> to learn rapidly new behaviors and new paradigms.

Again, who is the target audience?  What is useable for me may not be useable
for you.  That is why a Flowmap can really help.  Imagine a different flowmap
per demographic.  That would be RCT (Really Cool Technology), but FS
(Flexibility Syndrome).

> It may sound simple to draw a flowmap, but when you think at the
> psyco-cognitive requirements of millions of individuals, gosh, the more
> technological help you get, the better.

I agree.

> > > This creates a contract between the administration concern island (who
> > > is in charge of designing the restrictions) and the logic concern island
> > > (who is in charge of implementing them).
> >
> > It is important to point out here, that the role of the Administrator has
> > to be clearly defined.  The Sitemap merges the concern of administration of
> > publishing constraints and the selection of Actions for forms, etc.  This
> > is a clash as a multipage form navigation needs to be easily maintained by
> > a Developer--not an Admin.
> 
> Yes, but be careful: at this abstraction level, each 'stage' can be
> implemented with several web 'screens'... my goal is to allow Cocoon to
> automatically separate a stage into different screens and automatically
> manage flow.

Ok.  A definition of "Stage" must be clear.  A stage then is a screen or
group of screens that represent a part of the flow.  For instance, most
of our forms have a small header section.  However, on one particular
form, the header takes up three web pages.  They are all the "Header"
stage.

> This goes also along with the ability to fragment a page into its web
> construct (as Paul has done with the SVG fragment extractor).

So you are saying that a portion of a page can represent a stage?  My
head is swimming.

> Stage fragmentation and content deaggregation might not appear obvious
> for HTML pages, but it's automatically so for WAP and other devices....
> so my plan is to make it possible for Cocoon to exit pure
> request/response paradigm and enter a statefull ability to automatically
> handle more requests with the same information.

Ok.  Definitely.  WAP needs a sane method of breaking up a large page
into smaller chunks.

> > > A few questions need to be answered and I'll like to hear your comments
> > > on them:
> > >
> > > 1) can the flowmap be used not only for description, but directly for
> > > design like we do for the sitemap?
> >
> > Yes.  In fact, it could be designed like an orthagonal view of the sitemap.
> 
> Oh, here you touched the nerve: are flowmaps and sitemaps really
> orthogonal? I still haven't figure this out.

Maybe not completely.  The Sitemap identifies how to render a URI.  If we were
to draw a map, it would look like this:

ROOT/
     images/*.png
     images/*.gif
     *.html
     app1/
     app2/

A FlowMap would have a different view that manages movement between URIs.
The synergism of Sitemap to FlowMap would be this:

FlowMaps identify Stages and the connections between them (representing
this is XML is another can of worms).  The Stage identifies generators
and their associated handlers.  The Sitemap has views (Transformation
through Serialization) for the Stages (Generation/Handler combo).

> > > 3) if so, which contracts? is URI space enough?
> >
> > No. URI Space is only one of the flows that need to be handled.
> 
> The URI space is not a flow. Careful with terms or our friends here will
> be easily lost.

Sorry.

URI space are the points of connection.  Flows are the connections themselves.

This is a pure Sitemap view (in 2d space, X represents a resource):

+--------------------------+
|                          |
|       X X      X         |
|   X                  X   |
|           X              |
|      X            X      |
|                          |
+--------------------------+

This is a pure FlowMap view (in 2d space,
o represents decision, + represents a join):

+--------------------------+
|                          |
|      | - -o---- \        |
|      |    |      \+--    |
|    \ |            |      |
|           |-------       |
|                          |
+--------------------------+

The combined view (in 2d space)

+--------------------------+
|                          |
|      |X-X-o----X\        |
|   X  |    |      \+--X   |
|    \ |    X       |      |
|     X     |-------X      |
|                          |
+--------------------------+

Using this graphical view of the problem spaces,
you can see how this works in the big picture.
FlowMap is the connection of resource to resource,
and Sitemap is description of the resource.

> > We as a
> > company are going to use 3rd Party Workflow Engines to manage record movement
> > between roles, however that does not affect the flow of the form to the user.
> >
> > The concerns that have to be managed are:
> >
> > * URI Space
> > * Authentication/Authorization for certain URIs
> > * Action definition and use.
> > * Automatic backtracking based on errors.
> > * Back button and Stop button detection (some apps require that a transaction
> >   can only be executed once).
> >
> > > 4) where would actions be described?
> >
> > It should be able to be described in both places.  The FlowMap will need a
> > different set of Actions.
> 
> Ok, do you have more vision of this? just curious, I'm trying to collect
> info on others.

A stage will have a form page(s) and its handler(s).  Each handler does what is
necessary for the form page.  They cannot be separated--or you have just broken
the webapp.  Stages have no reason for existing in the Sitemap--they are a different
concern.  Conversly, if a web designer wants to personallize a site based on user
preferences (i.e. selecting a transformer to "theme" the site), that is usually
done in the sitemap.  There are some types of complex logic that cannot and should
not be expressed in a Sitemap with Selectors and Matchers.  This type of logic would
be done in an Action.  In fact, one Action can affect multiple aspects of the generated
pipeline.

> > > 5) whose concern would flowmap maintenance be?
> >
> > The developer's.  There might be a use-case for a Business Analyst to alter
> > the flow of the webapp--but form handling semantics and rules need to be
> > handled by the developer.
> 
> I disagree. Flowmaps contain almost all the usability energy and
> normally developers have no idea (rather than their own) on how to use
> this energy. Their concerns must be merely technical: write me an action
> that does this and that. But where to place it, where to direct users if
> they make mistakes, where to locate them is not their concern.

Ok.  I see your point.  Since I am the Alpha and Omega on some projects at my company,
I end up mixing concerns.

A business analyst (or usability engineer) would be handling the flowmap.  The major
issue is that the developer knows the mapping of the page to the handler (i.e. the
nuts and bolts of a stage).  There is some concern overlap here.  If the Flowmap used
complementary configuration (like my Database Actions), the Stages are able to be
manipulated in the FlowMap, and the Developer is able to define the mapping of page
to handler separately (preferably in one file though).

Also, it is probably preferable to have the concept of encapsulating a subflow into a
stage.  It allows for your multi-page stages to be defined properly.

> This is a very important point: separating concerns between technology
> and usability is something that has never been engineered before (not
> even for modern all-knowing web-app frameworks). We must at least try to
> do so here.

Hopefully the above will be helpful in defining the problem space.

> > > 6) would the introduction of the flowmap concept require changes in
> > > cocoon's core design?
> >
> > No.  It would require another MarkupLanguage that creates a Sitemap object
> > by the different semantics of the FlowMap.
> 
> Are you sure? The flowmap doesn't contain information on how to present
> information, or even on how to generate it. My perception is more like a
> flowmap is a "style" of the sitemap, it "connects" the URI space with
> flows...
> But one thing is for sure: a flowmap cannot generate a sitemap since it
> doesn't contain the required information (nor it should!).

Hmm.  I was thinking that the "FlowMap" would have predefined Pipelines
(aka stages), and would return the Pipeline back to the Sitemap.  After the
reevaluation above (farther above), This is not the case.  Now, in your
vision, does the FlowMap return a URI, or a Generator?

> > The functionality of the sitemap is same, but the semantics regarding flow
> > and definition of the pipeline are different.
> 
> I disagree: the flowmap "adds" information to the sitemap... information
> that is crosscut across resources and is normally left to the user to
> define in actions or generators.
> 
> For sure, the result is a sitemap object, but I percieve "flowmaps" as
> the information required to "fill" sitemaps with statefull information.
> 
> This is my perception, but I have no idea on the semantics required to
> do it.

Ok.  I like that.  The thing is, that sometimes the technology to implement
something is different than the concept implies.

> > There is a number of things that can be done by Actions--and careful planning
> > can yield some very flexible results.  For example, the DatabaseActions that
> > I created use an XML configuration file to determine how they are used in a
> > given flow.  This is sort of a secondary mapping of URI to logic.
> 
> Exactly, but not a "secondary" an "augmented".

Augmented/Complementary.  Much better words :).

> > OK, I think I just confused myself there:
> >
> > Database{Add|Delete|Update}Action is defined once.  However based on one
> > parameter, I specify a configuration file that maps the Request parameters
> > to database columns in a table.  This is very important as it enables the
> > Action to be reused with different mappings based on the URI space.
> >
> > However, it feels clumsy managing the Flow of a Webapp via URIs.
> 
> I agree, unless each "stage" is associated with a URI 'label' that is
> "augmented" directly by cocoon at "flowmap -> sitemap" transformation
> stage.
> 
> What do I mean?
> 
> Well, something like
> 
>  (enter) --> /login -()-> /home --> (exit)
> 
> but /login indicates both the /login URI and all the other screens
> required to terminate the 'stage'. Each "stage" can be seen as the
> simplest possible flowmap:
> 
>  (enter) ---> [(stage)] ----> (exit)
>                ^      |
>                |      |
>                +(self)+
> 
> where
> 
>  (enter) is the entry point (where we came from)
>  (exit) is the exit point (where we go next)
>  (self) is the same stage
> 
> the translation of these "flow events" to URI requests is done at
> another level even if it useful, at this point, to label the stages with
> URIs to create a strong contract between sitemaps and flowmaps....
> otherwise, this contract will have to be specified somewhere else.
> 
> Note: this would enforce the use of URI as identifiers rather than
> addresses and will very likely make it easier to design a URI space
> without all the problems that plague web sites today.

Mime
View raw message