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

[Jim Fulton]

Paul Everitt wrote:
> 
> This is a damn good conversation!

And damn important.

I HOPE EVERYBODY IS PAYING ATTENTION! :)


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

...

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

Not necessarily. We could embed some extra links in the page that only show
up if the designer makes some gesture (e.g. add something to the url). I think
Silva uses something like this. I suppose the links don't even have to show
up but could be tied to clicking on the page they relate to.

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

But this is an area where we will need be aware of what's possible.

I wonder if XOPUS/BitFlux provide any opportunities here.


...

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

That's exactly the point I was trying to raise. I don't have the answer.
I'm not sure that a component-based view is necessarily bad, but I strongly
suspect that there need to be other views too.  We've already mentioned a
page-oriented view.

It is probably useful to have an organizing mechanism that the designer can
use. Components provide one such organization. It may be as good as any other,
especially since I can't think of any others. ;)


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

The current jargon for this role seems to be information architect.

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

Possibly. The CMF has a separate actor for this.

   http://cmf.zope.org/rqmts/new_use_cases/index.html

Maybe we should add this.

...

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

I've lost tracl of this particular corner of the thread. I'm not sure what
Janko was refering too.  I think I'll drop it and see if it comes back up in a form
I understand.

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