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

[Jeffrey P Shell]

On Monday, October 7, 2002, at 11:42  AM, Paul Everitt wrote:
>>> 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.

I really really really hope there is some whispering of Data 
Components.  I still do a lot of SQL Method / Python Script / Page 
Template based sites where I'd love to have stronger components instead 
of a collection of scripts and scripts and scripts.  It's in these 
muddied situations that managing what a Site Designer may end up 
responsible for gets messy.

A benefit of it is that the Page Templates are rendered in the places 
that they live, since they're operating on data coming from another 
source.  The data is the second class Zope citizen in this case, with 
the Page Templates and helpers being first class.  The CMF reverses 
this situation, with the Content being first class Zope objects and the 
Page Templates and helpers used to render that content typically being 
second class, and are housed (as has been pointed out) in different 
locations from where they are rendered.  And, to some degree, this 
applies to file based Page Templates and DTML used for Management 
screens (and for ZClasses).

They're all valid development cases.  I'm glad that Janko tries to keep 
general Zope 3 site design separate from Web Content Management site 
design.

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

These are probably the most common users/actors, especially in small 
shops.  I know that for us, I'd love to be able to develop new 
components more easily but seldom have the time to do more than throw a 
bunch of pages and scripts together using a few common components that 
I feel are solid enough to be used, like Formulator.  I imagine many 
Zope shops are like this.  This is why I've always felt that a good 
Component Architecture would be beneficial - if it's easier for the 
good developers to craft and distribute components that these other 
shops can use comfortably, sites get done quicker and Zope developers 
are happier.

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

With the above mentioned tools, motivations can differ.  Just like one 
audio engineer will use the Audio capabilities of Logic, another will 
spend more time with the MIDI Automation capabilities.  With 
Dreamweaver and GoLive, most of the time the people we're talking about 
here are using the visual mode and the dynamic (client side dynamic 
HTML) capabilities.  But there is a fair sized crop of users of each 
tool that spends more of their time in the Source Code mode - in fact, 
DreamWeaver MX on Windows has the old Allaire 'HomeSite' application 
rolled in.  In HomeSite mode, the focus is almost entirely on source 
code.

And many users use the split-view mode, where most of the screen may be 
in the visual mode, but the designer is keeping an eye on the HTML 
being generated by the tool.

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

There's a good possibility that they will.  And I guess there is a good 
possibility that they won't.  But, to be on the positive humanist side 
instead of the bitter misanthrope for a change, I'll tell our current 
story.

The primary designer we work with has been a Page Templates client for 
a couple of months now.  He uses Dreamweaver and friends heavily, and 
doesn't do programming at all.  Typically, he comes up with the bulk of 
the main design, and I or another developer add in the page template 
components, and then he often continues tweaks and edits.  He hasn't 
had any problems with it.  He doesn't understand, nor really cares, 
what the extra attributes do (besides what can be inferred by looking 
at them - 'content' and 'replace' are different enough).  But he knows 
enough to leave them alone.

Usually, he knows from dirty quick pages I prototype to see the data 
what components/data are available to him and may design the visual 
page around that (for better or worse, since I usually pull those pages 
straight out of...um, a place), and he is usually involved somewhat in 
either the IA meetings about flow/navigation to know what is needed.  
But still - he's much more a "Dreamweaver jockey" than anything else.  
And again - we've had no problems with him.

His underling, however, can be a different story.  He's a good 
designer, but is not as involved in some of the above mentioned details.

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

Too true.

[Snip]

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

I think there really are different levels of designers.  For example, 
I'm usually responsible for doing the 'admin' screens, while the 'site 
designer' is responsible for the public views.  I really really really 
want component-based views for the admin screens because there's 
usually a lot of logic going on with them to edit and deal with 
components.  In many of these sites, the public site has less of that 
involved because the admin screens are separated from the public UI.  
But in a CMF type site, editing and administration may be more likely 
to happen in the Public UI (for better or worse).

So I design the admin screens (which are pretty good looking for what 
they are, I must say ;), but the non-programmer does the public.  This 
is a frequent scenario for us.  But again, we're also fortunate to have 
a really good designer who can handle what Page Templates throw at him 
(much more so than he could with DTML) without having to know the geeky 
details.

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

I'll Gulp too.  But, I do think Information Architect is a valid role.

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

Headers suck.  Whole page macros kick a million kinds of ass and are my 
favorite thing about Page Templates.  :)  But, point taken.

>>>   - Customize the common layout in some parts of the site.

Hopefully this applies to content management specifically.  I think 
there is a big benefit to the free-form nature of the current Zope 
setup.  It doesn't necessarily scale well as a web application grows, 
but some sites really only require a few pages, some helper scripts, 
and some smart admin screens.

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

Me too.  I'm just hoping that the point is not entirely focused on 
content management solutions, because there are many other types of web 
applications of varying sizes out there with different design 
(software-speaking) requirements.