[MKDoc-dev] Proposed event/calendar functionality

[Chris Croome]

Hi

On Mon 18-Oct-2004 at 11:02:09AM -0400, Sam Tregar wrote:
> On Mon, 18 Oct 2004, Chris Croome wrote:
> 
> > For the listing of events I guess we also want this to be
> > adjusted based on audiences?
> 
> Yes, that's the plan.  I included statements to this effect in
> v1.1 of the tech spec.

Ah, cool, sorry I missed that.

> > By default it should list upcoming events with the soonest one
> > first, but it might also be useful if it could be used to list
> > past events (say for a history web site)?
> 
> That sounds useful to me, although it has the potential to make
> the interface more complex.

Yes, perhaps we should leave it out for the moment...

> > I guess the most minimal addition to the Headlines component
> > would be to add an additional tickbox for "Only list pages with
> > future events on them"...
> 
> Bruno's request, if I understood it correctly, was to add a
> selection to the headlines editor with two options - "show recent
> changes" and "show upcoming events".  The first would follow the
> current behavior and the second which select documents by their
> event dates rather than last modified date.  Does that sound ok to
> you?

Yes, that's fine, though we should probably have it labeled as "list
new documents" since it only lists new documents and not ones that
have been changed recently, and at some point having the ability to
list "recently changed documents" would be good...

> > If a document has multiple events components will it be listed
> > multiple times?
> 
> I can code it either way, although listing multiple times seems
> more useful in the cases I've considered so far.  For example,
> imagine a play with multiple show-times.  Just showing the first
> one will give the impression that it's a one-shot performance.

Yes, I agree.

> > If the Headlines component is being redone to add support for
> > events then perhaps it could also be changed so that it can be
> > used to generate lists of child documents, again there is an old
> > mockup of some ideas for this here:
> > 
> >   http://testers.mkdoc.com/ideas/components/list/child/
> 
> I think this is outside the scope of the project, although it
> doesn't seem too complicated.

Agreed.

> > Also perhaps we need to someday look at getting rid of the
> > distinction between the document properties and document content
> > -- orginally the idea was that the document metadata would be
> > edited on the properties page but since we are now looking at
> > adding components for documents metadata it might make sense to
> > have one page for editing documents and not two seperate ones...
> 
> I tend to agree.  When we redesigned Bricolage's interface in
> Krang we moved a number of fixed meta fields into the element
> system, which corresponds roughly to MKDoc's component system.
> This improved flexibility and allowed for content which didn't
> naturally have "keywords" or a "description."  This is
> particularly useful if you also adopt the concept of document
> types which only allow a subset of available components.  As the
> list of components grows larger I imagine this will seem more
> attractive!

Yep, one for the wish list I think :-)

Chris

-- 
Chris Croome                               <chris at webarchitects.co.uk>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/