[MKDoc-dev] Proposed event/calendar functionality

[Sam Tregar]

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.

> There is a (very old) mock up of an events listing component here:
> 
>   http://testers.mkdoc.com/ideas/components/list/event/
> 
> 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.

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

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

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

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

-sam