Feature to display content in calendar from summary page

[Ian Lewis]

It would be nice to have a form of the simple calendar (not for tickets, though even there it would be useful) that would pull in content from a calendar summary wiki page.

Perhaps the major level 1 headings could delineate wiki calendar dates with a page per month following a template for the pages like summarypage=%Y-%m:

And on the page:

= 1/1/2012 =

do this

= 1/2/2012 =

do that

or

= Day1 =

Do this

= Day2 =

Do that

And then the calendar display could pull that content into the corresponding date boxes. The form could be quite restrictive and still be useable by normal users.

Calender then might look like:

Do this 1

Do that 2

3

...

[Steffen Hoffmann]

Do you really like the look of your table example?

Only one or two words per cell would be rarely useful, hm, maybe having some acronyms or short forms for internal use like cleanup, team meeting, ..., but it would certainly decompose the very compact and nicely aligned WikiCalendarMacro table.

Nevertheless it might integrate rather nicely with the WikiTicketCalendarMacro, and I see your point in providing easily editable content for inclusion into the calendar. The precise syntax for the wiki page could be agreed upon while evaluating this further on. Just I would refrain from parsing date strings like 1/1/2012, because this could be rather cumbersome and Trac 0.13 will support a lot more localized forms than I'd like to support.

[Ian Lewis]

Replying to hasienda:

Do you really like the look of your table example?

No, not at all. I was only trying to show the idea of pulling content into the cells. I like the way your calendar looks - especially the small form, though for this purpose the display would have to look more like the ticket calendar.

I would like to see wiki formatting in the pulled in content, but it seems that would probably be very easy to do compared with the content extraction.

I imagine that maybe 20 to 30 words could fit in a calendar cell quite comfortabely on a 1920 x 1200 display, which is the minimum size we have for our users. We have lots of much smaller displays on shared machines, machine controllers, and on servers, and it would be horrible there (many things are anyhow), but I do not think it likely that we really need a calendar in any of those places.

I may be wrong, but I think our users, at least, could live with almost any format you specified for the headings - or however you decidee to break up content for days. It might feel weird at first, but it is the calendar they would look at most - by a lot - not the backing page. Assuming people actually used it - and I believe we have a fair number of users who would - after doing a month or two of whatever the page format was they would get used to it.

Maybe:

= [[WikiCalendar(summaryday=1)]] <title text you want on your page whatever it is that makes you happy> =

Day1 content

= [[WikiCalendar(summaryday=2)]] <another day's title> =

Day2 content

and WikiCalendar produced no output when it sees the summaryday parameter. It just gives you a way to pick out the sections for the days.

I am not really advocating this form. Personally, I would prefer something where the wiki page has less clutter. But, I think I could even get users to do something like this. It would be all cut and paste. Or, probably better, we could set up a page template for a calendar summary page with 31 headings already in place in whatever the correct form is.

[Ian Lewis]

Replying to hasienda:

Just I would refrain from parsing date strings like 1/1/2012, because ...

Replying to [comment2: ilewismsl]:

Maybe: <box containing suggested markup>

Come to think of it (relative to my last comment), maybe you need no markup to tell you which sections to place in which cells. You just specify as part of your documentation that you pick out level 1 headings in the order they appear on the page with the first for day 1 and the last for the last day of the month. Anything after that you ignore.

This forces the user to fill in every day, which might not be that great if you only want summary content for one day a week, but with a template to build the page for you it would probably be ok and the headings could contain whatever you wished since WikiCalendar would not care about it.

[Ian Lewis]

Another related idea that could go with this would be an ability to set the page template to go to the section of the summary page related to the date. This would not likely take much change at all in the code.

For example, setting the page template to %Y-%m#Day%d could go to heading Day%d within the summary page. This almost works now.

Note: I tried to set up an experiment that looked like this using the current WikiCalendar code, and unfortunately it treated the hash (#) as part of the page name, not as a hash index into the page.

[Steffen Hoffmann]

Replying to ilewismsl:

... For example, setting the page template to %Y-%m#Day%d could go to heading Day%d within the summary page. This almost works now.

Note: I tried to set up an experiment that looked like this using the current WikiCalendar code, and unfortunately it treated the hash (#) as part of the page name, not as a hash index into the page.

Do you care, or better, do you see this useful application for the wiki calendars?

By now they've really been meant to do one page per day, not caring for page relative links (page sections) at all. OTOH not threading the hash character in an URL special seem still plain wrong.

Not sure yet, how to proceed with that, but that's already another ticket. You're good at throwing out issues for discussion, hope I can keep pace with that, given the need to share my attention for maintenance of other plugins.

[Steffen Hoffmann]

Nice that you've been thinking that hard about implementation details for what you call the summary page.

Consider my test page Test/Beratung/2010-04-CalendarEvents, that currently looks like this:

{{{
#!comment
# Repeated ISO date name prefix for confirmation, that this is indeed a Wiki(Ticket)Calendar supplemental events page
2010-04

}}}
= Events for April 2010
List relevant information for sourcing into the wiki calendar

 * 3.:: kick-off
 * 04-10:: 1st team meeting

== actual work done below
 * 2010-04-16 :: 2nd meeting
 24:: presentation
 25 :: docs revision

2010-04-25 :: project end

The overall concept is to enable both easy input with minimum of constraints, just a date or part of it - simple day number entries would be valid on monthly pages only, an optional dot for formatting, the double colon sequence as a delimiter, and the actual content for the day:

[*]* (YYYY-MM-DD|MM-DD|DD).*::(.+)

You could use simple lists or definition list or just plain paragraphs as you like, and you'd certainly not need to put placeholders to skip days. Any head line will be ignored. This is my idea of a page that could be parsed easily while not looking too technical at the same time.

Note the (invisible) page header meant for verification, that this should be really parsed (or to enable/disable unfinished pages).

The calendar is located on Test/Beratung and I envision to allow for yearly and monthly summary pages, even a mix of both by parsing available pages in the wiki path hierarchy below the current page (here: Test/Beratung) following just prefixes confirming to ISO dates:

• Test/Beratung/2010-04 - valid for Apr-2010
• Test/Beratung/2010-04-CalendarEvents - valid, same as before
• Test/Beratung/2010 - valid for all months of 2010
• Test/Beratung/2010_CalSummary - valid, same as before
• Test/Beratung/CalendarEvents-2010-04 - invalid

Comments welcome.

[Ian Lewis]

Replying to hasienda:

OTOH not threading the hash character in an URL special seem still plain wrong.

Not sure yet, how to proceed with that, but that's already another ticket. You're good at throwing out issues for discussion, hope I can keep pace with that, given the need to share my attention for maintenance of other plugins.

Independent of the summary page I do think this is a defect: ? and # should not be part of a page name. May I enter a defect ticket? And, yes, I do think it worth fixing, though this seems like another case where Trac should provide a service that defines a page name rather than having each hack figure it out separately.

If you do not have time, do not worry about it. The calendar is already useful and I do not really need anything more. I just think I could get more people to use it if they could see a month's overview.

[Ian Lewis]

Replying to hasienda:

[*]* (YYYY-MM-DD|MM-DD|DD).*::(.+)

I like the idea of year as well as month pages. That would work well for people with thin calendars. I was mostly thinking about users who make extensive use of a calendar (paper or Outlook now) and trying to see how to get them to shift to the wiki, at least for things they would like to make public or that we need to have public and tied in with milestone schedules. The users I have in mind do not have tickets for most tasks and if I try to impose tickets on them to set up a 10 minute meeting, it is not going to happen. And, in any case, I do not want tickets in our system for a 10 minute meeting.

They use their calendars to get an overview of where they stand quickly. They are not going to use the current page per day no matter what I do or say. They do not have a lot to say about each day. They have a little bit to say about every day and they want to be able to see how all those small pieces fit together. Certainly, they have days where a page makes sense, but not most days.

Detail comments:

1) The double colon notation looks fine, though, if you can. it seems that it would be good to use existing wiki formatting that people already know to mark day comments. Still, I believe my users could get used to that double colon fast.

2) Single year-month-day format, with shortcuts if you specify a default for part of the date, looks fine.

3) For the page marker, I would suggest using some form of your macro rather than a comment, but I see nothing horrible about the comment if that is easier. For example require:

{{WikiCalendar(calendarpage=2010-04)]]

at the start of each page. Or, maybe a different macro: WikiCalendarPage(...).

4) Are you imagining that the calendar invocation has a page template parameter? I would think that would make sense and it would be close to the same idea as what you have now for a page template. If so, I do not quite understand the reason for the restriction on page format (date at the start).

I really see no serious problem with such a format. It is just that, if there is a specified page template, I do not see the reason for it. Letting the user set a page template does seem like a good idea to me. Someone might want to use the same page template for six different invocations of the calendar on different pages - as we do with the ticket calendar - and with a page template they could do that. This does not strike me as a critical point, but it does seem like a real one and not just made up.

I think maybe you are suggesting searching for pages and merging multiple pages into one calandar. If so, that is an interesting idea, though on a first response I do not quite see how we would use it. Maybe for pulling mutliple user's calendars together into a master calendar. But, in that case we really need to be able to say where to find the pages, not just have you search automatically.

5) Now the only serious issue I see with your outline: It looks to me like you are aiming at a line oriented specification, if I understand your (.+). I think it would be a lot better to have a block oriented structure:

= 04-10:: 1st team meeting
Every think in this section pulled in to calendar whether it makse sense or not.
   * Point1
   * Point2

If you do not want a section pulled into the calendar, then do not put a date marker on it. Sure, the calendar might be a mess, but a user will figure out what makes sense fast enough.

Really, line oriented as you suggest would work fine. I think my users could live with it and would still use the calendar. But, it seems to me that some block oriented structure would be significantly better. I have done some experements and you really can get a lot of text into one of the WikiTicketCalendar cells.

Summary: If you implemented exactly what you propose I would try it on my users and I bet it would work. I, however, would prefer some kind of block oriented structure rather than a line oriented structure to the content you pull in and I would prefer that the structure be delineated by existing Trac wiki markup of some kind.

Note: Some of this is starting to sound like a scheduling program. That really is not what I was looking for. I just wanted to get people to move from paper or private Outlook to the wiki because doing that would encourage using the wiki and make it easier to share schedules person to person.

[Ian Lewis]

Replying to hasienda:

# Repeated ISO date name prefix for confirmation, that this is indeed a Wiki(Ticket)Calendar supplemental events page

Thinking about this some more, I do not like the idea of requiring the date repeated on the page. The page name already carries the date. I would like to be able to set up a page template that completely configures a valid page for the user. That - more or less - is what happens with a per day page. The page name tells you what day the page is for and the calendar constructs the page name with no user intervetion.

Allowing some control of what day a page is for on the page itself would be fine - valuable even - but I would prefer that you not require it.

[Steffen Hoffmann]

Replying to ilewismsl:

Replying to hasienda:

Do you really like the look of your table example?

No, not at all. I was only trying to show the idea of pulling content into the cells. I like the way your calendar looks - especially the small form, though for this purpose the display would have to look more like the ticket calendar.

Because we reached consent about that, let's consider the feature only for the ticket calendar due to massive space constraints for the simple calender form.

[Ryan J Ollos]

The plugin is deprecated. Feature requests should be directed to WikiCalendarMacro.