[MKDoc-dev] Proposed event/calendar functionality

[Chris Croome]

Hi

On Thu 14-Oct-2004 at 06:18:19PM +0100, Bruno Postle wrote:
> 
> I'm preferring 2, we add to the existing Headlines component,
> because I do think the list of components is too long.  We could
> take the opportunity to rename it Listings.
> 
> At some point I'd like to merge the RSS component as well since
> the functionality is identical to Headlines.

Actually, in addition to the fact that the Headlines component is
for listing documents on the local site and RSS is used for linking
to external sites there is also another difference -- the listing of
documents generated using a headlines component is different for
logged on users, if you are logged in then the listing changes based
on the audience preferences you have selected, nothing like this is
done with the RSS component.

Say for a school web site, with 3 audiences, kids, teachers and
parents, and a front page with a headlines component, if a teacher
has indicated that they are not interested in articles for kids or
parents then they won't get to see articles written for these
audiences on the front page headline listing.

For the listing of events I guess we also want this to be adjusted
based on audiences?

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

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

If a document has multiple events components will it be listed
multiple times?

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'm not really sure if craming lots of features into a small number
of components is the best thing to do or if having lots of
components, some of which do similar things makes most sense... (for
example why have seperate HTML and Text components?)  

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

Chris

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