You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
One of my first tasks as a new technical writer was to post a backlog of meetings with replay links and materials on our lab’s wiki space. I realized the only way to list events in event date order (not page creation or modification date order) was to reorder the pages manually in the page tree. This worked, but I knew I’d have to find a better way eventually.
Time passed. The list of meeting replays got longer. Then a second lab began to attend the meetings. Then a new video portal became available. Then a key URL changed. Then other kinds of meetings needed to be listed too. So I began a list of requirements for a more sustainable solution.
Ability to list or group events by topic (such as architecture, debug, Agile, testing, etc.)
Ability to list the same events on multiple wiki spaces
Ability to list the most recent one, or four, or ten events
Ability to sort by event date, not date created or date modified
Ability to distinguish meetings by type (forums, demos, training, etc.)
Easy enough for average wiki user to use
Scalable to multiple labs, years, event types, etc.
Use core Confluence functionality if possible, or existing add-ons or macros (no budget)
I continued to explore which existing macros and add-ons could potentially meet the requirements. These included,
Content by label - but could not sort by event date
Child pages - same
Page tree - same
Blog posts - could work, but can’t change posting date after the fact
Reporting - good, but could not specify event date (is not page metadata)
Scaffolding - could definitely work, but too complicated for average user
Page Properties / Report - could work, Confluence core functionality
After some experimentation, I decided to go with the Page Properties and Page Properties Report macros. I needed properties (or “fields” or “metadata”) for the PP table that would describe each event, and would be generic enough to work across multiple spaces, including,
Event name (this is usually the wiki page title as well)
Event date (in YYYY-MM-DD format for proper sorting)
Materials (such as PowerPoint presentation)
Not all of these would apply to every event, but the names of the properties needed to stay the same across pages. (Scaffolding plus Live Template would have been an ideal solution for keeping all event pages consistent, but this would have been too complicated for the average user to maintain.) I chose a Page Properties ID of “events” to use for all events, since “Description” was used in other Page Properties instances across the spaces. The current version of the Page Properties table looks like this (example data).
Adding the Page Properties table to each page in the large archive of events took some time, but I had to touch the pages anyway for other reasons. I was able to speed up the process a little by using wiki markup (Data Center).
The Page Properties Reports look somewhat like this (example data). They can be filtered by label to show all demos, all events related to a tool or product, all events on a specific topic, and so on.
This solution assumes one page per event, as this is the best method for filtering based on labels for topic, meeting type, product, etc.
It is possible to include multiple Page Properties macros on the same page, and the Page Properties Report generates as usual. However, the first column of the report is always the page title, which uses up screen real estate and may not be the desired effect, and filtering events by label won’t work when they’re all on the same page. For example,
I’ve used CSS to suppress the display of the first column, header and report pagination for a more streamlined display in a couple of use cases, which is why my Page Properties reports include a column for Event Name, which might differ from the page title. I can use or omit Event Name depending on where the list is displaying.
Event replay / meeting pages
Each meeting page includes a few sections, which are included in a standard “event replay” template.
Panel with event information inside the Page Properties table, as above
Panel with related pages, links and other resources
Panel listing attachments (such as text transcripts, presentations, etc.)
Panel with a replay preview from the video portal.
Our wiki spaces have several pages listing training, events, meetings, references and archive information. The Page Properties Report macro is used on those to list event replays.
On the home page of one wiki space, we list the most recent event in a streamlined display.
It was a lot of research and work to get to this point, but this solution is working well for our labs so far. Since the video replays are much-requested by developers (and the viewing statistics reflect their popularity), it’s useful to use Page Properties / Report to list them on any page where they might be relevant. Developers can see immediately the event date, a description, and a link that takes them right to the replay.
I will continue to monitor how well this solution scales. If you have a similar or different solution to listing events by event date I would be interested to hear how it works.
Michelle Rau good