[Zope3-dev] Basis for use cases for the Site Designer

[Jim Fulton]

Janko Hauser wrote:
> Hello, in the following I want to make a first start at some use cases
> for the Z3WCM. I post to the mailing list, to hopefully start some
> discussion as all this should not to be meant as complete proposal,
> although the result of this should be put into the wiki.

Much thanks Janko!

> I will concentrate at what was the Site Designer actor in the context
> of the CMF.

Note that Zope 3 abd CMF actors don't overlap. We need to straighten this
out.  In Zope 3:

- Developers write software:

   - Component developers are focussed on component development,
     especialy low-level components.

   - Site developers are focussed on assembling components to build
     a site. They often customize component and may develop new components
     from time to time.

- Site designers in Zope 3 (as opposed to the CMF) are focussed on look
   and feel. Thier main tools are tools like Dreamweaver, Go Live, and
   perhaps Javascript.

   This actor presents some real challenges. It's not clear that a
   component-centric view is best for them (although, it's also
   not clear that it isn't ;).  This is an area where there's a lot of
   room to innovate.

   One big issue they have is that they can have trouble finding page sources,
   since the place where a page is rendered is often very different from
   the place it is edited. This is complicated further when pages are assembled
   from components. Something we've been meaning to do for some
   time, but haven't gotten to is to have a ZPT (or DTML) mode that includes
   source page locations in comments in rendered output. It would be way
   cooler if a designer could somehow click on an area (e.g. a special link)
   of a page and be taken to an editing interface for that part of the page.

> First some links and words to the mental environment. The use cases
> for the CMF build a strong starting point.
> 
> http://cmf.zope.org/rqmts/new_use_cases/index.html
> 
> Jim added some more thoughts to the Wiki, in this context
> specifically (sorry for the wrapping):
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture
> 
> [1] /ContentTypesInZope3
> 
> [2] /CMFContentTypeDesign

Note that this is pretty old. (It was also written
by shane. [1] is a bit more in line with current thinking.

It's also worth noting that this is a concept that we're struggling
with a bit.


> [3] /ThroughTheWebDevelopmentInZope3
> 
> [4] /SiteDesigner
> 
> I hope I use a similar wording, as is used in the wiki pages.
> 
> Goal: (Z3 goal) The Site Designer is responsible for producing and 
> maintaining
> the "look and feel" of a site. This includes graphics, layout,
> navigation and other human factors.
> 
> (Z3WCM goal) The Site Designer is responsible for the views of the
> different content types. There a different views for the managment
> and for the presentation of content types. I see here two different
> actors. The CMS-Designer and the Deployment Site Designer. They are
> working at different times and stages of development, they do not need
> to have the same technical knowledge. The first is doing it's work
> once and then build on top of this, the second does need to redo
> everything for every new customer.

But keep in mind that, by Zope 3 actor jargon, "designers" just
do UI.  Designers don't do components. The designer is probably
not responsible for the views, but for the templates use be the
views. Note that we are talking about actors, not people. A person
could fill the rolls of muiltiple actors. So a single person
could be both a site developer and a site designer.

I think that you make a good point that there are really two
different designs, the CMS design and the "retail" site design.
I'm not positive that these deserve separate actors thougk.


> Use cases for the CMS Designer:
> 
>   - Identify content-objects which should be managed by the CMS

No, this is done by the site developer.


>   - Identify services which should have customized integrated views


No, this is done by the site developer.


>   - Customize the look and feel of the managment views of the included
>     content objects.

Yes.


>   - Define the look and feel of meta views. These are views which are
>     the basis of the implemented CMS. Navigate a site on the managment
>     side, integrate short cuts or menues to other managment screens
>     (user mgmt, login, contact, feedback forms etc.), present
>     collections of content and mgmt. views for them.

Yes, maybe.  I wonder if we need a separate role for "Information Architect".


> 
> Use cases for the Deployment Site Designer:
> 
>   - Define common layout characteristics for a site.
> 
>       This is related to the current skin mechanism in the CMF. Global
>       stylesheets, common blocks, like header, navigation views.
> 
>   - Customize the common layout in some parts of the site.
> 
>   - Define actual layout and presentation of content-objects.
> 
>       There are centralized places for theses views.
> 
>       This is different from the skin mechanism, as it is strongly
>       conntected to one content-type. There could be many different
>       layout views for the same content-type. But each layout view is
>       only connected to one content-type.

Don't skins/view components support this?  I'm not sure I get your point
here.

 >       A discussable example would
>       be lists. Are they a content-type, or just a view on a bunch of
>       similar items?

I'm not sure what you mean here. At some level, the discussion lists and
their items (and maybe their threads) would be content objects, although
they might not be considered "content types", depending on your definition of
content types.

>    - Manage the mapping of layout views to content-types and define
>      names for them.
> 
>        The names are possibly customer related. Not all content
>        providers can see the same list of possible layout views.

I don't follow this. Who is the customer here?


> As a note I want to raise the question, if "Designer" is really the
> right word vor these actors, especially for the CMS Designer actor. 
> Every designer needs at least to know, how to get simple information 
> from the corresponding view class. She needs to be able to navigate the
> managment screens, and have a little overview about the functioning of
> the CMS. That's more than a typical dreamweaver artist.

Unless they:

- Work with the site developer, who knows how to access the view components, and

- Have some view on the templates that either hides a lot of the component details
   or at least makes them less important.

But you raise a valid question.

 > Suggestions
> for other names are Implementor, Integrator, Layouter.

Well, I think the Site Developer is pretty equivalent to "Implementor" and "Integrator".

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org