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

[Paul Everitt]

This is a damn good conversation!

On lundi, oct 7, 2002, at 17:19 Europe/Paris, Jim Fulton wrote:

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

Agreed.

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

I'm glad to see this separation.  I think it will be comfortable to 
people from the ASP/JSP background.

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

I also like this emphasis on the tools the people use.  It helps paint 
a portrait of their motivations.

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

Yep.  More on this below...

>   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

All I can say to this is, "omigod".  Right on, brother.  I once tried 
to teach a sysadmin how to do templates for an intranet reporting 
application.  I realized at the fourth layer of indirection that I was 
losing him. :^)

The Funky Namespace Notation, despite all my kvetching about it, helps 
on this.  But IMO it is still really important to pretend to be the 
Dreamweaver jockey and ask if they'll grok what Zope 3 puts in front of 
them.

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

Obviously the thing above would take tool-side automation to accomplish 
the scenario you described.  Thus, while we're in blue-sky mode, I'll 
note that the DAV src property isn't a single item but a sequence of 
URLs that contribute to the rendering of a resource.  The template 
could be one of these.

Thus it might be possible to leverage something in a standard, albeit 
something impossibly unlikely to ever be implemented except by us.

But we're way far way from choosing implementations...

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

Lemme put on my object zealot hat for a moment and say, "Views are 
components."  I realize this is a bit pedantic, but it tries to 
underscore the point: what amount of Zope 3 component architecture 
stuff will a designer faced with?

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

Good point.  Besides UI, there are other design things that shouldn't 
go to the site developer.  For instance, site structure.  Let's say we 
settle on XTM (topic maps) as the model for structuring a site.  (This 
is just hypothetical).  Is that a responsibility for the Site Designer 
or Site Developer?

Workflow designs are another activity that is up for grabs on the 
current list of actors.

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

Gulp.

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

In practice, the convention is "document_view", "folder_view", etc., 
unless I'm missing the point.

--Paul