cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] from linkmaps to flowmaps
Date Tue, 06 Mar 2001 10:26:07 GMT
Berin Loritsch wrote:

> >  2) estimate link degradation
> In a real Web Application, the links between pages are relatively
> constant--the information displayed on the pages changes with the
> underlying data.

I was talking more generally than web-apps.
> >  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.

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

> > To answer such a question we must define what a "linkmap" is: a
> > collection of relations between resources.
> >
> > XLink provides sufficient expressivity to write such a thing and
> > XPointer provides sufficient granularity to link very specific parts of
> > a resource.
> >
> > But is this really useful?
> No.  The Flowmap or automatic navigational components are required.

This is my perception as well.
> > The solution I envision is the creation of a "flowmap" where the web-app
> > designer is not focused on intermediate locations (resources), but in
> > the flow of the application, much like you procedural languages let you
> > program by writing a flow, not filling memory slots declaratively with
> > instructions.
> I have a navigational Action that I developed that will only let a viewer
> see pages after they have logged in.  When fully fleshed out, it will
> fill the "void" in my immediate need.  However it only solves part of the
> problem--so the FlowMap concept looks very interesting to me.

> > So, what is a flowmap?
> >
> > Take a piece of paper, avoid thinking you are writing an application for
> > the web, so avoid taking into consideration technical constraints (like
> > the request/response paradigm, intrinsic statelessness, low bandwidth,
> > proxying, etc..) and draw a diagram of the latest application you wrote.
> >
> > What you should outline, at this stage, is the 'skeleton' of the flow:
> > this should be drawn to give the other people in the team the overlall
> > picture of what the application is doing.
> >
> > So, let's see, let's take something like
> >
> >
> >          identification
> >                ^
> >                |
> >                v
> >  (enter) ---> home ---> (exit)
> >                ^
> >                |
> >                +--> read article <-()-> post comment
> >                |
> >                +-()-> set preferences
> >                |
> >                +-()-> add article
> >                |
> >                +-(editor)-> accept submission
> >
> > where:
> >
> >  (enter) indicates the entrance of the application
> >  (exit) guess what? :)
> >  ---> indicates a 'general flow' [no restriction on identity]
> >  <---> indicates a 'bidirectional flow'
> >  -(???)-> indicates a 'restricted flow'
> >  -()-> indicates a 'identificated flow'
> This is very similar to the Modified Flow Charts we use to map the
> Flow of the Application.  In fact, we will typically break up one
> large webapp into smaller ones.  For instance, we have a product
> called VendorExchange that is designed to act as an interface
> between Vendors and Retailers.  It manages the workflow of getting
> a product approved for sale in the Retailer's stores.  There are
> several smaller Webapps in the larger one, namely: Product submittal,
> Product Display submittal, Promotion information management,
> and Cost Changes for existing products.
> Each of these smaller webapps have some similar structure (to make
> it easier for the end user).  So a FlowMap to be really useful has
> to support the notion of of Sub Flows, or Heirarchical Flow Maps.

Totally. Yes. It is easy to extend the above model to provide hierarchy,
in fact:

  (enter)---> stage1 ----> (exit)
                +-------> [flowmap]

where [flowmap] is

  (enter)---> stage2 ----> (exit)

Where (enter) means move to the linked flowmap and (exit) means go back
to where you came in from.
> > 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.

The "aspect" we care here about login or authentication is
"identification" of the user.
> > 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.

> 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.
> > We can starting noting a few properties of a flowmap:
> >
> > 1) there must be no end stages, the flowmap must describe a fully
> > connected graph between the (enter) and (exit) dummy stages.
> True.  For our workflow apps, the "enter" would start at login, and
> the "exit" would start at logout.

Again, this is not sufficiently abstract: in fact, for sub-flowmaps,
this is not true. So "enter" and "exit" points are just dummy
representations that allow you to connect the flowmap to the real
world... in fact, "login" is a stage, not the implementation of the
"enter" entry point.

 (enter) ---> login -()-> home --> (exit)

> > This is very important: the absence of such a fully connected graph does
> > *NOT* make the application unusable, but this is only because of "back"
> > functionalities in your browser.
> I would venture to say that the "back" button in a webapp with
> important information is a dangerous thing.  There are methods of detecting
> if the back button or stop button has been pressed so that you can force
> a "forwards only" flow for the user.

Yes, the "back" button is a hack, a client-side usability patch to bad
hypermedia design.
> > In short, a fully connected flowmap avoids the 'dead end' problem.
> Absolutely necessary.

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? :)
> > 2) the site of the flowmap represents a good estimation of the web-app
> > complexity and gives an fuzzy metric.
> Pre-planning the flow of information gives you a better idea of the useability
> of the webapp.  Too much recursion is a *bad* thing, but carefully managed
> flow can help a user use the system.

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 :)

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 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

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

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.
> > 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.

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

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.

Think of multiple WAP decks out of the same page or SVG internal
fragments taken out as images, etc... but this is meat for another RT. 
> > This is already long enough so I'll stop here.
> Alot has been said, but most in the last section.
> > 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.

> It needs to describe the flow of Form pages and implicitly their handlers.
> There also needs to be a method of conditionally selecting pipeline elements
> and flow based on runtime information such as variables returned from an
> Action.

> > 2) if so, is there a way to completely remove aspect overlap between
> > sitemaps and flowmaps and make them totally independent given a few
> > solid contracts between the two?
> It would be equivalent to Mounting a SiteMap.  In fact, to the Cocoon system,
> they would both be a SiteMap--however the semantics of specifying flow, error
> handling, and navigational rules needs to apply here.  Actions have there
> place in both views of the URI space, but they are more pronounced in the
> FlowMap idea.

Good terminology here: sitemap and flowmaps are different view of the
same URI space.

Please understand that different views (projections) are not necessarely
orthogonal and if they are not, a modification on one requires
modification on the other, thus breaking SoC and increasing the
constract costs.
> > 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.

> 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.
> > 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.

Just like sitemap's administration.

Careful: this doesn't mean that a developer can't be the flowmap
manager, it sure can, but my point is it must not be *required* that the
flowmap manager needed technical skills.... just like we did for the

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.
> > 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
But one thing is for sure: a flowmap cannot generate a sitemap since it
doesn't contain the required information (nor it should!).
> 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.
> 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".

> In other
> words, one Action is used in multiple locations, but the specifics of its
> action are handled by an orthagonal view of the semantics.

Yeah, more or less.

> 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

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)
               ^      |
               |      |


 (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.

> Thus the
> Navigation Action I am developing.  It will follow the same semantics of
> the DatabaseActions, as the flow of navigation will alter the stylesheet
> based on Role, and status of the transaction (draft, pending, approved, rejected).

At the end, I'm not sure where these RT lead to, but it's great to
exchange visions on these things and keep them sufficiently abstract to
provide R&D ground for future innovation.

Thanks to all for your patience and hope this will be useful someday :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message