[Zope3-dev] DISCUSS: Consolidation of Zope 3 UI wiki pages

[Paul Everitt]

On Sunday, Nov 10, 2002, at 09:21 Europe/Paris, kit blake wrote:

> Hi everybody,
> After reading the UI pages that Paul listed, I'd like to propose an
> audience breakdown, which has the advantage that the naming is simple
> and easy to remember. This take was actually developed for Silva, but  
> it
> applies equally well to Zope3.

I believe Zope 3 is trying to define some standard audience names.   
Thus, I think you'll find agreement for your motivation.

> To define the audiences, we used a device taken from use cases, from
> this book: "Writing Effective Use Cases", by Alistair Cockburn (ISBN
> 0-201-70225-8). Cockburn suggests the use of icons, and in our
> experience the icons aren't very useful, but their names are.
>
> Icon               Level               Audience
> -----------------------------------------------------------------
> Clouds             High summary        upper management
> Kites              Summary             managers
> Waves (sea level)  User goal           designer/programmer
> Fish               System (app)        developer (also SysAdmin)
> Clams              Components          zen master
>
> We often talk about the 'cloud level' or the 'sea bed'. (To be  
> rigorous,
> we're twisting it a little by considering components to be software
> architecture.)
>
> Please note that I'm not arguing against the more fine grained audience
> breakdown in:
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ 
> ZopeTop
> However I question the exclusion of ComponentDeveloper and SiteDesigner
> from the target audience. For instance, designers who live in WYSIWYG
> need Zope3 interface facilities that help launch their favorite tool.
> ComponentDevelopers need text mode and command line navigation.

I don't argue that they don't need facilities.  Rather:

1) The two other audiences need a different facility, as they think  
differently from the Site Developer.

2) They are more entrenched in their existing tools, thus you have to  
do more development to please them (and you still might get them to  
switch).  Site Designers need Dreamweaver. Component Developers need  
Emacs.

3) Even if (1) and (2) are wrong, there's still the problem of  
manpower.  We don't have enough to build a broad "studio" environment.   
Thus we have the practical problem of needing to *ruthlessly* narrow  
the scope.

> Currently Zope2 is most successful on the underwater level. It's for
> developers. But that is also its shortcoming. "Steep learning curve"
> prevents designers and junior programmers from diving deeper. And  
> bottom
> dwellers get lightheaded if they have to use a browser based interface.

One of the conclusions from Zope 2 was that it tried to be all things  
to all people.  This applies to the ZMI as well, IMO.

> One goal of the UI should be to expand to other audiences. Otherwise
> we're in danger of "designing for the converted". This means making
> Zope3 more accessible. What 'accessible' means depends on the audience.

In a perfect world I agree with this statement.  However, when it comes  
to the tools that people are going to use to interact with the site, I  
think we're better off not trying to force people to switch on the  
entrenched tools.  Instead, we should try to accommodate the tools  
(hence, Jim's sync proposals).

> Cloud      The UI should be very attractive and look like
>            professional software (this is pure image).
> Kite       Acquire above and add user friendliness combined with
>            valuable and visible built-in functionality (fulfill
>            policy needs).
> Sea level  Ease of use (hands on), guided learning, help/support,
>            linked documentation, customization, and interoperation
>            with existing tools.
> Fish       Acquire sea level and add advanced (sexy) conceptual
>            approach, supple navigation, clear distinctions
>            between activities, include below.
> Clam       80 character access, smart symbolic linking/structure

These are all good points, but it is also pretty ambitious.  I can  
agree with setting it as the long-term vision, but I think we need to  
get something more limited out the door in the near-term.

> The Zope3 UI discussions could follow this same format. The cloud and
> kite level need to 'sell' Zope3 based on semi-tangible attributes. Sea
> level needs to coax designer/programmers to dive a little deeper. And
> all the water craatures need protocol based paths into the environment.

One place where I'll diverge from your outline, though: I don't think I  
can agree with putting so much on the table right now.

I guess I've been down this road too many times.  I'm most interested  
in getting something done now, then see where it leads us.

> ---------------------------------
> Zope3 for the Board of Directors
> Zope3 for Managers
> Zope3 for Designers & Programmers
> Zope3 for Developers
> Zope3 for Zen Masters
> ---------------------------------
>
>
>> 3) Choose a name for the UI effort:
>>    c. Other.
>
> Zope Environment.  To my ears, ZopeTop refers to desktop, which sounds
> old and flat. An environment is a (variable) spatial concept.

Not too bad.  However, I don't think it makes a distinction between the  
view of the object system, versus the entire object system.  For  
instance, the following statement would likely be true for a Zope UI:

"Python is not part of the Zope Environment."

I don't think we want to say that. :^)  Still, I support the idea of  
coming up with specific jargon to refer to the visual environment and  
the elements therein.  When teaching, it always bugs me to say, "In the  
Zope Management Interface, click in the left-hand side on Root Folder,  
then choose DTML Document from the add list".

> From Webster's Revised Unabridged Dictionary (1913) [web1913]:
>   Environment \En*vi"ron*ment\, n. [Cf. F. environnement.]
>      2. That which environs or surrounds; surrounding conditions,
>         influences, or forces, by which living forms are
>         influenced and modified in their growth and development.
> From WordNet (r) 1.7 [wn]:
>   environment
>        n 1: the totality of surrounding conditions; "he longed
>             for the comfortable environment of his livingroom"
>        2: the area in which something exists or lives: "the
>           country--the flat agricultural surround" [syn:
>           {environs}, {surroundings}, {surround}]
>
>
>> 4) We then need to digest the contents of the Joachim's page,
>> the ZopeTop page, and the CMSUI page into a consolidated page.
>
> Hope I didn't just muddy the waters,

A little, but that's ok.  Motion is as good as forward motion at this  
point. :^)  Still, we have only a couple of weeks before we need to  
finish this inception stage.  I think every possible choice is still on  
the table.  We need to start refining the choices by taking some things  
off the table.

I suppose this means that the do-ers need to get together.  I'm not  
sure who are the do-ers on the UI effort, and I'm not sure who is  
spearheading the effort.  I'm afraid we'll show up at your place and  
spend the first few days rehashing previous territory.

As I mentioned in my response to Joachim, I think consensus might be  
hard on this.  Everyone has wildly different opinions.  Thus, this is  
going to be one of those things where the decisions lie with the ones  
willing to do the work.  It's going to take some asbestos underwear,  
that's for sure.

--Paul