| paul@290 | 1 | Navigation Controls
|
| paul@290 | 2 | -------------------
|
| paul@290 | 3 |
|
| paul@290 | 4 | The "New event" link should probably not be present when only remote events
|
| paul@290 | 5 | are being aggregated by a calendar.
|
| paul@290 | 6 |
|
| paul@368 | 7 | Improve the accessibility of controls by providing links with titles and
|
| paul@368 | 8 | offering links as alternatives to pop-up elements.
|
| paul@368 | 9 |
|
| paul@218 | 10 | Points in Time
|
| paul@218 | 11 | --------------
|
| paul@218 | 12 |
|
| paul@218 | 13 | Consider making dates convertible to timespans of the form (start of day,
|
| paul@218 | 14 | start of next day).
|
| paul@218 | 15 |
|
| paul@211 | 16 | Localised Keywords
|
| paul@211 | 17 | ------------------
|
| paul@211 | 18 |
|
| paul@211 | 19 | It should be possible to define events using localised equivalents of "start",
|
| paul@211 | 20 | "end", "summary" and so on. To achieve this, the page language would be found
|
| paul@211 | 21 | and regular expressions built to use the localised keywords, falling back on
|
| paul@211 | 22 | the English keywords, would then search for event details.
|
| paul@211 | 23 |
|
| paul@211 | 24 | Recurring Events
|
| paul@211 | 25 | ----------------
|
| paul@211 | 26 |
|
| paul@232 | 27 | Recurring event information from iCalendar sources should be considered in
|
| paul@232 | 28 | order to avoid showing incomplete or incorrect event datetimes. Ultimately,
|
| paul@232 | 29 | such information may need to be parsed and incorporated into the general event
|
| paul@232 | 30 | recurrence processing.
|
| paul@232 | 31 |
|
| paul@211 | 32 | Having events recur at certain intervals would potentially involve the
|
| paul@211 | 33 | expansion of events to produce multiple instances within a specified period of
|
| paul@211 | 34 | interest, and such expansion could occur after an event's details have been
|
| paul@211 | 35 | read. Care would need to be taken in cases where no limits are placed on a
|
| paul@211 | 36 | calendar: the expanded instances should not be allowed to recede into the past
|
| paul@211 | 37 | and future indefinitely; where no other events exist to provide implicit
|
| paul@211 | 38 | limits, some other default limits might be required to let the expansion
|
| paul@211 | 39 | occur.
|
| paul@211 | 40 |
|
| paul@211 | 41 | The description of recurring events could be based on the iCalendar
|
| paul@211 | 42 | specification, although simpler schemes could be preferable. Recurring event
|
| paul@211 | 43 | descriptions might start with "every" and then provide a time period ("day",
|
| paul@211 | 44 | "week", "month", "year") for offsets from a specified date or time, perhaps
|
| paul@211 | 45 | using qualifiers ("first", "second", "other", and so on), or instead provide a
|
| paul@211 | 46 | more complete description using additional qualifiers that may override any
|
| paul@211 | 47 | specified date or time for instances other than the primary occurrence. For
|
| paul@211 | 48 | example, "every second Wednesday of every other month".
|
| paul@211 | 49 |
|
| paul@356 | 50 | The resolution of each successive <recurrence> would need to be lower than
|
| paul@356 | 51 | those it follows. Thus, "every second day of every second week..." would be
|
| paul@356 | 52 | valid whereas "every second week of every second day..." would not.
|
| paul@227 | 53 |
|
| paul@204 | 54 | Map Views
|
| paul@204 | 55 | ---------
|
| paul@204 | 56 |
|
| paul@218 | 57 | Other projections might be supported. This would be necessary for various
|
| paul@218 | 58 | retrieved map images.
|
| paul@218 | 59 |
|
| paul@204 | 60 | Dynamic images obtained from other sites or generated locally might provide some
|
| paul@204 | 61 | enhancements to the map view. For example, a weather/radar image might show the
|
| paul@204 | 62 | cloud or rain forecast either for the current situation or, if forecasts are
|
| paul@204 | 63 | available, for the times of events shown.
|
| paul@204 | 64 |
|
| paul@204 | 65 | Consider having day numbers down the side of a map view with highlighted days
|
| paul@204 | 66 | indicating days having events, and with pop-up elements shown upon hovering over
|
| paul@204 | 67 | each highlighted day.
|
| paul@204 | 68 |
|
| paul@204 | 69 | To Do Items
|
| paul@204 | 70 | -----------
|
| paul@204 | 71 |
|
| paul@204 | 72 | Consider adding support for "to do" items. These might have time-related details
|
| paul@204 | 73 | such as deadlines, but are more likely to have relationships with other items,
|
| paul@204 | 74 | potentially forming a hierarchy of items.
|
| paul@204 | 75 |
|
| paul@204 | 76 | Event Section Parser
|
| paul@204 | 77 | --------------------
|
| paul@204 | 78 |
|
| paul@336 | 79 | Events in page sections/regions could be presented using more sophisticated
|
| paul@336 | 80 | methods and potentially be editable. To support direct editing, the parser
|
| paul@336 | 81 | would provide a hidden form field indicating the location of the section in
|
| paul@336 | 82 | the Wiki text, and the new event action would be enhanced to read existing
|
| paul@336 | 83 | events from the indicated page region, populating the form fields with the
|
| paul@336 | 84 | data found in the page.
|
| paul@242 | 85 |
|
| paul@242 | 86 | UID Properties
|
| paul@242 | 87 | --------------
|
| paul@242 | 88 |
|
| paul@242 | 89 | Especially in the case of aggregation from multiple sources, the only reliable
|
| paul@242 | 90 | way of avoiding repetition of the same events described in different places is
|
| paul@242 | 91 | for authors to include a UID property identifying each event, using the same
|
| paul@242 | 92 | value regardless of where the event is being published.
|
| paul@265 | 93 |
|
| paul@292 | 94 | Formatting in iCalendar Output
|
| paul@292 | 95 | ------------------------------
|
| paul@292 | 96 |
|
| paul@292 | 97 | If there is a reasonably standard way of incorporating Wiki text in iCalendar
|
| paul@292 | 98 | output alongside plain text, this would enable events aggregated from Wiki
|
| paul@292 | 99 | sources to use Wiki text to describe things like the location and topics of an
|
| paul@292 | 100 | event with links and other formatting that could then be reproduced in the
|
| paul@292 | 101 | aggregating Wiki.
|
| paul@292 | 102 |
|
| paul@265 | 103 | Remote Source Timeouts
|
| paul@265 | 104 | ----------------------
|
| paul@265 | 105 |
|
| paul@265 | 106 | Sometimes, network problems can cause delays in accessing remote sources. The
|
| paul@265 | 107 | library should support either a timeout mechanism or asynchronous retrieval of
|
| paul@265 | 108 | remote source data.
|
