users@javaserverfaces-spec-public.java.net

[jsr344-experts mirror] Re: [jsr344-experts] Re: [730-TaskFlows] NAMING

From: <chris.muir_at_oracle.com>
Date: Fri, 16 Mar 2012 00:09:12 +0000 (GMT)

I might as well butt in here, it's a good place as any. My name is
Chris Muir, I'm a new ADF product manager at Oracle, run a user group
of ADF practitioners of around 750+ members (known as the ADF EMG), and
I know Ed from his kind assistance when he presented for us a couple
years back. I've followed this group for a little while, I've
hopefully the etiquettes down before posting, but please let me know
otherwise.

Returning to naming task flows, from experience working & teaching
developers and ADF solutions (in a life before Oracle) none have had
problems with the name task flow, they just accept it on face value.
It's always been the power & versatility of adding task flows to their
applications they haven't understood, not the name.

Personally I also like the name because it aligns with the User
Experience idea of breaking your application UI design into "tasks"
with encapsulated flow to satisfy user use cases rather than conceiving
the application as a bunch of pages or flow or just UI components
separately.

As a separate point we (in ADF) have the concept of Unbounded Task Flow
& Bounded Task Flow & they roll off the tongue nicely as UTFs & BTFs.

I'm not a fan of too cute names as Flowlets (reminds me of towelets for
some reason) as such names distract people when introducing the
concept. As a side example when introducing customers to the fact ADF
has "Groovy" support, I seriously think half after tittering at the
name never take the option seriously.

Any name that is picked should also be versatile enough such that when
the spec expands to support using these in portlets (a.k.a. ADF
regions) the name doesn't imply pages exclusively.

My 2c worth.

Regards,

CM.