Schooltool Calendaring

  1. --- th1a (~hoffman@pool-64-222-39-13.prov.east.verizon.net) has joined #schooltool [18:21:23]
  2. --- philipp_s (~philipp_s@49.116.62.81.cust.bluewin.ch) has joined #schooltool [18:23:47]
  3. <th1a> Hi all. I made a list of the calendaring issues I want to quiz Kellan about at http://schooltool.org/wiki/IrcChatWithKellan [18:45:10]
    • mgedmin is lurking here [18:50:46]
  5. <SteveA> th1a: I can't attend this meeting, sorry. But, if you can mail a transcript to the list, I'll read it later and comment on it. [18:53:05]
  6. <th1a> No problem. [18:53:27]
  7. --- kellan (~kellan@c-67-170-58-50.client.comcast.net) has joined #schooltool [19:00:21]
  8. <kellan> hello [19:00:39]
  9. <philipp_s> hi [19:01:09]
  10. <mgedmin> hello [19:01:10]
  11. <kellan> i'm tom's friend, he asked me to drop by this morning [19:01:51]
  12. <philipp_s> greetings from switzerland :-) [19:02:05]
  13. <th1a> Hi Kellan. [19:02:34]
    • kellan notes he also seems to be pretty seriously lagged to this server. [19:02:57]
  15. <th1a> I guess we should get down to it. Thanks for coming, Kellan. [19:04:05]
  16. <th1a> The first thing I'm wondering about standards. [19:04:21]
  17. <philipp_s> BTW i'm interested in the schooltool project, haven't contributed so far, just observing... [19:04:22]
  18. <th1a> is standards. [19:04:35]
  19. <th1a> It seems like the calendaring standards world is even more of a mess than the syndication standards world. [19:04:58]
  20. <th1a> We're supporting ICal, and it doesn't seem like anything else is established enough to even bother with in the short term. [19:05:45]
  21. <kellan> true. their has only recently been a push to adopt ical (rfc 2445) in the last couple of years, and there really aren't any worth bothering with [19:05:54]
  22. <th1a> The CalDAV proposal didn't seem to gain any traction. [19:06:19]
  23. <kellan> unfortunately the calsch wg has pretty much killed the space by a serious of poor tech choices (bng syntax, beep vs http) [19:06:23]
  24. <mgedmin> I've heard that there was an XML version of iCal [19:06:48]
  25. <kellan> no it hasn't. it might get recycled through. but the working group doesn't drive the standards. [19:06:51]
  26. <mgedmin> how is that one faring? [19:06:51]
  27. <kellan> mgedmin: its lapsed. [19:07:00]
  28. <kellan> as has the only parser for it. [19:07:11]
  29. <kellan> which was sad. actually tbl did the intial translation [19:07:20]
  30. <kellan> the one standard which is emerging is the RDFiCal [19:07:59]
  31. <kellan> the eventsherpa kids have actually implemented a parser (in C#) for it, and are using it in their product [19:08:22]
  32. <kellan> however no one else has, and it isn't stable yet. [19:08:32]
  33. <kellan> what are you looking for a standard to provide you? [19:08:49]
  34. <th1a> I'll keep an eye on that for the future. [19:08:53]
  35. <th1a> I'm mostly just want to know that we're supporting standards when it is appropriate. [19:09:30]
  36. <th1a> So we don't really need to linger on the topic. [19:09:45]
  37. <kellan> iCal over WebDAV is the only thing we [19:09:51]
  38. <kellan> 've got close to a standard (bless Apple) [19:10:02]
  39. <th1a> OK. [19:10:20]
  40. <kellan> though iCal.app implementation has some serious limitations as they're trying to drive you to iSync. MozCal is the gold standard in my book. [19:10:33]
  41. <th1a> I think we'll end up recommending Mozilla as a client. [19:11:04]
  42. <th1a> We aren't very Mac-oriented anyhow. [19:11:27]
  43. <mgedmin> I have a question about one corer case we've stumbled upon in schooltool so far [19:11:36]
  44. <kellan> iCal.app is a lot more stable for now. probably want to recommend iCal, MozCal and eventSherpa (for Win) [19:11:40]
  45. <mgedmin> iCal requires a calendar to have at least one component [19:11:49]
  46. <kellan> mgedmin: yes [19:11:56]
  47. <mgedmin> so what's supposed to happen when you delete all events from a calendar? [19:11:59]
  48. <mgedmin> when I tried it, mozcal just uploaded an empty file via HTTP PUT [19:12:22]
  49. <mgedmin> but it refused to accept the same empty file back [19:12:34]
  50. <kellan> mgedmin: its undefined, what we did (Palm/Protest.net) is we added a placeholder event without a starttime [19:12:44]
  51. <kellan> that seems to work [19:12:51]
  52. <mgedmin> that's exactly what we did too [19:13:00]
  53. <mgedmin> "without a starttime" sounds interesting -- does it prevent clients from displaying that event? [19:13:30]
  54. <kellan> it did in my tests [19:13:50]
  55. <kellan> i tried to get a comment from the wg on it, but didn't get anywhere. [19:14:05]
  56. <th1a> Are there any guidelines for doing RSS feeds of events? [19:14:57]
  57. <th1a> For example, are they sorted by date added or date of the event? [19:15:27]
  58. <kellan> there is mod_event which is pretty simple, adds start and end times, plus a location field. [19:15:34]
  59. <kellan> oh, those sort of guidelines. no. not really. because there aren't any guidelines about how an rss parser/aggregator returns the records [19:15:59]
  60. <th1a> So we should just wing that. [19:16:34]
  61. <th1a> If we decide to do RSS feeds. [19:16:53]
  62. <kellan> at protest.net we sort by date of the event because we assume that most people using the feed are trying to display their own calendar. if most people were wanting to monitor the feed to check for "whats new" then you would want to sort by creation. [19:17:05]
  63. <kellan> just depends on what your target consumer is. [19:17:13]
  64. <kellan> you should definitely do an RSS feed, its the new glue. [19:17:21]
  65. <th1a> That makes sense. [19:17:38]
  66. <mgedmin> RSS 0.9/1.0/2.0? [19:17:50]
  67. <mgedmin> what about Atom? [19:17:55]
  68. <kellan> mgedmin: i always say RSS 1.0, Atom is excellent for various micro-publishing uses, but it isn't a good general purpose XML data stream [19:18:23]
  69. <kellan> and the Atom kids know this [19:18:28]
  70. <th1a> I'd say definitely not 0.9, and also not 2.0. [19:18:55]
  71. <mgedmin> ok [19:19:10]
  72. <kellan> just an fyi, mod_event is supported by mark's feedparser.py [19:19:41]
  73. <th1a> That's good. [19:19:50]
  74. <kellan> as i know you're a python shop [19:19:52]
  75. <th1a> Hm. Yeah, I hadn't even thought about the server consuming feeds. That's a good point. [19:20:24]
  76. <kellan> i'm kind of curious what kind of calendar you're building, there are a number of different activities that people use calendars for [19:20:24]
  77. <kellan> th1a: i tend to use a lot of RSS internally just to tlak to myself, but i'm weird i'm like that [19:20:53]
  78. <th1a> Well, on one level it just tracks a student's repeating schedule. [19:21:13]
  79. <th1a> Or a teacher's or a resource's, like a room or a projector. [19:21:41]
    • mgedmin googles for mod_event and learns that it is a RDF module, and not an Apache module [19:21:58]
  81. <th1a> So there's one ICal file for each thing that is their repeating schedule. [19:22:21]
  82. <kellan> mgedmin: sorry. i tend to apporach apache'ish. [19:22:24]
  83. <kellan> th1a: makes sense [19:22:39]
  84. <th1a> And then there is another URL where each thing can post or get their ICal calendar. [19:23:14]
  85. <kellan> kellan: for MozCal you'll just need one URL, for apple you can either post, or subscribe, but not both. [19:24:06]
  86. <kellan> so have you done any thinking about public event calendars (which leads quickly to eventreg) or on the other end of the spectrum, personal scheduling? [19:24:38]
  87. <kellan> (which is kind of what you're already doing, except just for their repeating institutional events) [19:24:56]
  88. <th1a> I mean, there is another URL where you can post or add a separate calendar from your repeating calendar. [19:25:08]
  89. <th1a> A personal calendar, that is. [19:25:28]
  90. <th1a> One personal, one autogenerated schedule. [19:25:43]
  91. <kellan> cool. [19:26:01]
  92. <th1a> But we haven't gone into any detail about handling public/private things. [19:26:23]
  93. <th1a> What is eventreg? [19:26:27]
  94. <kellan> th1a: sorry. Event Registration. RSVP handling, limited seats, online sign up, potentially taking payments. [19:27:03]
  95. <th1a> Hmm... I haven't seen those things as important use cases. [19:27:32]
  96. <kellan> once you give someone a public event caledanr, they ask for it. [19:27:35]
  97. <kellan> doesn't mean you have to give it to them :-) [19:27:59]
  98. <th1a> So that might be something that is more important for institutions other than schools. [19:28:06]
  99. <th1a> We are planning a non-school distribution. [19:28:41]
  100. <kellan> admittedly my experience is in more public events, and scheduling, but i've found school are actually a huge source of events. [19:29:01]
  101. <kellan> there were about 50 schools (k-12) using the metaevent's calendar [19:29:26]
  102. <kellan> besides the university who used it [19:29:35]
  103. <kellan> not saying that is what you should do. [19:29:48]
  104. <th1a> Hm... Yeah, I guess RSVP-ing and such are important for meetings. [19:29:53]
  105. <th1a> I'm used to thinking of a small school. [19:30:09]
  106. <th1a> Where sign-up and RSVP-ing is easily done face to face. [19:30:44]
  107. <kellan> quick side note about RSVP, don't get sucked into Outlook's claim that it supports iCal, or get attached to those cool like scheduling button it can produce. it only really works outlook-> outlook [19:30:46]
    • kellan notes he can't type at this time of the morning [19:31:06]
  109. <philipp_s> RSVP=? (thanks) [19:31:42]
  110. <th1a> I guess right now we don't even have the concept of an event, when you get right down do it, do we? [19:31:48]
  111. <th1a> RSVP is French actually... [19:32:09]
  112. <mgedmin> Revolutionary Surrealist Vandal Party [19:32:14]
  113. <mgedmin> just kidding [19:32:16]
  114. <kellan> philipp_s: RSVP means replying and saying whether you're planning to attend an event or not. [19:32:25]
  115. <kellan> like if you've used evite.com [19:32:30]
  116. <th1a> Respondez S'il vous plait [19:32:42]
  117. <philipp_s> cheers! [19:33:10]
  118. <th1a> mgedmin: we don't really have event objects, do we? [19:33:23]
  119. <kellan> ohh, i would definitely model this at both the event and calendar level [19:33:43]
  120. <mgedmin> we do have VEvent objects that are used to represent parsed iCalendars [19:33:48]
  121. <mgedmin> we do not use them for anything else at the moment [19:33:56]
  122. <kellan> people are going to want to attach comments, and .doc files and what not to events. [19:34:01]
  123. <kellan> plus you need a way to cancel a single instances of a recurring event [19:34:11]
  124. <th1a> OK, this is starting to make sense. [19:34:38]
  125. <mgedmin> we also have calendar events (ICalendarEvent in schooltool.interfaces) [19:34:40]
  126. <th1a> This might be helpful: http://schooltool.org/wiki/CalendarTimetable [19:36:09]
  127. <kellan> interesting. never really encountered the timetable concept before. but it makes sense. [19:37:49]
  128. <th1a> OK, so here's a use case, an administrator is setting up a professional development session, with 15 available slots. [19:39:25]
  129. <kellan> ok [19:40:19]
  130. <th1a> He enters the event into the system, reserving a room (resource) in the process, and specifies the number of people who can join, and that they have to be part of the group teachers. [19:40:35]
  131. <th1a> Teachers are notified of the opportunity via RSS and other means. [19:40:57]
  132. <th1a> They go on the web and add themselves to the list. [19:41:23]
  133. <th1a> So the event object has to build a list of people attending, and when it is full, notify the administrator and stop taking submissions. [19:42:05]
  134. <kellan> basically. in practice you often hold a few back. [19:42:35]
  135. <th1a> So we'll have to build a lot more logic around the ICalendarEvents. [19:43:43]
  136. <th1a> This is at least starting to make a lot more sense to me... [19:44:35]
  137. <th1a> Do most orgs consider it a must to allow one person to edit another's schedule, like allowing someone's secretary to edit their boss's schedule? [19:45:29]
  138. <kellan> th1a: in larger orgs it is neccessary. in a smaller org they might tell you its neccessary but in practice anyone who is editting your schedule probably can figure out your password. [19:46:11]
  139. <th1a> :-) [19:46:24]
  140. <kellan> also having one or two admin users is more then sufficient [19:46:28]
  141. <kellan> we just went through this conversation for our new project at Groundspring, and decided to go with a very flat permissions structure [19:47:07]
  142. <th1a> What do you mean by very flat? [19:47:23]
  143. <kellan> not a lot of levels of hierarchy, a few simple roles, skip any sort of delegation, don't track ownership of objects [19:48:01]
  144. <kellan> they all seemed to cause lock out issues, and IT headaches [19:48:17]
  145. <th1a> Yeah, we need to keep this simple. [19:49:19]
  146. <kellan> the once place where it can get to be an issue is when the principal is trying to schedule an event, and the room thinks it is already booked. [19:49:59]
  147. <th1a> Ah. Overriding things. [19:50:16]
  148. <kellan> that said, i wouldn't try to capture how to resolve that as every org does it differently [19:50:18]
  149. <kellan> just allow an admin to override and cancel [19:50:35]
  150. <kellan> there might have to an email fired off, or a phone call, but allowing for out of band communication (which happens anyway) really simplifies the spec [19:51:18]
  151. <th1a> I have been thinking that managing a personal private and personal public schedule will be more than most teachers would want to deal with. [19:51:27]
  152. <kellan> agreed [19:51:39]
  153. <kellan> a teacher would probably want to add any public events to their schools public event calendar [19:52:05]
  154. <th1a> I was thinking that a teacher's schedule would just return available/not-available info to other users. [19:52:08]
  155. <kellan> freebusy [19:52:18]
  156. <th1a> Yeah. [19:52:21]
  157. <th1a> Is that a reasonable way to handle it? [19:52:33]
  158. <kellan> hard to know, i haven't worked in schools, i would tend to say that the institutional events (the recurring classes and such) are public or at least common knowledge [19:53:05]
  159. <th1a> Yeah. [19:53:12]
  160. <kellan> if you're logged in, why not show the actual events [19:53:15]
  161. <th1a> But a teacher's individual meeting. [19:53:26]
  162. <kellan> for everything else, blacking it out makes sense, yeah. [19:53:36]
  163. <th1a> Right. [19:53:44]
  164. <kellan> that acutally sounds to like an argument for allowing events to be flagged private/public, and having intelligent defaults [19:54:09]
  165. <th1a> Well, that pretty much gets me through my list of issues. [19:54:09]
  166. <philipp_s> th1a: regarding the topic list you posted for this irc session, is there room for more topics at the end? i would like to discuss the * timetabling vs * calendaring issues a bit more... will it fit into the schedule of this irc session? :-) [19:54:29]
  167. <th1a> Absolutely. [19:54:41]
  168. <th1a> If Kellan can stay. [19:54:45]
  169. <philipp_s> just to get a rough understanding of the differences involved... [19:55:08]
  170. <kellan> i'd through out that people are going to want email integration (reminders, newsletters, and scheduling in that order), probalby is a bit more work to do in private/public conversation, and the most annoying feature request i got over and over was to support gantt charts [19:55:12]
  171. <th1a> If not we can certainly still talk among ourselves. [19:55:17]
  172. <kellan> i should probably head into work [19:55:37]
  173. <kellan> but i'm happy to chat with folks if questions come up. [19:55:49]
  174. <th1a> This has been really helpful, Kellan. [19:56:04]
  175. <kellan> kellan@protest.net [19:56:06]
  176. <mgedmin> kellan: thanks for your insights [19:56:07]
  177. <th1a> phillipp_s: let's keep talking about calendaring vs timetabling [19:56:26]
  178. <kellan> it was fun. look forward to seeing what you come up with, the current state of open source calendaring (or calendaring in general) is pretty dismal [19:56:30]
  179. <th1a> Yeah. People who are discouraged by the state of syndication should look at calendaring to feel better. [19:57:09]
  180. <philipp_s> http://www.gnu.org/directory/productivity/cal/ [19:57:15]
  181. <philipp_s> i haven't looked in depth, but it does look dismal [19:57:57]
  182. <kellan> alright, talk to you folks soon. [19:59:16]
  183. --- kellan has quit ("Leaving") [19:59:19]
  184. <philipp_s> maybe i can just fire off what i understand are the rough issues about timetabling vs calendaring... [19:59:28]
  185. <th1a> Fire away. [19:59:36]
  186. <philipp_s> timetabling in my school is coordinated by one single person [20:00:07]
  187. <th1a> You mean, that person creates the student schedules? [20:00:32]
  188. <philipp_s> ... who does the basic timetable for each semester [20:00:36]
  189. <philipp_s> it's basically quite tricky juggling of resources [20:01:03]
  190. <th1a> Assigns students to classes? [20:01:06]
  191. <th1a> And classes to rooms? [20:01:28]
  192. <philipp_s> at my school that comes later [20:01:31]
  193. <philipp_s> my school first tries to assign teachers and rooms to the overall schedule [20:02:05]
  194. <philipp_s> there are a lot of constraints that need to go into the equation [20:02:27]
  195. <philipp_s> because it is a school specialised into part-time education [20:02:58]
  196. <th1a> OK. [20:03:19]
  197. <philipp_s> teachers teach part-time and students attend part-time [20:03:28]
  198. <philipp_s> so you first need to get an overall schedule worked out for the teachers and rooms [20:04:05]
  199. <th1a> Right. So you're thinking about applications to generate that timetable automatically. [20:04:16]
  200. <philipp_s> well... [20:04:34]
  201. <th1a> Or mostly automatically... [20:04:45]
  202. <philipp_s> they currently do it with excel [20:04:47]
  203. <philipp_s> but it is a headache [20:04:57]
  204. <philipp_s> there are commercial solutions that offer some form of automation [20:05:26]
  205. <th1a> That functionality is definitely going to be a part of SchoolTool. [20:05:33]
  206. <philipp_s> i don't really know how good that works, but my school thinks they would want it... [20:06:02]
  207. <th1a> We've kicked around some proposals, but we haven't come to any resolution, mostly because we haven't clearly defined how to extend SchoolTool. [20:06:29]
  208. <philipp_s> what do you mean by "extend"? [20:06:54]
  209. <th1a> Well, that's not entirely clear either, actually. [20:07:14]
  210. <philipp_s> :-) [20:07:22]
  211. <th1a> Have you used Zope? [20:07:34]
  212. <philipp_s> yes, we are running the school's website with zope... I will introduce myself properly by email shortly! :-) [20:08:47]
  213. <philipp_s> but if you don't mind, i am really keen on talking about the general timetabling/calendaring issues, to get a rough idea about the scope of it all... [20:09:54]
  214. <philipp_s> what do you think? [20:10:33]
  215. <philipp_s> maybe i first do the introduction, and then we can talk more on irc another time... :-) [20:11:45]
  216. --- tom_hoffman (~hoffman@pool-64-222-39-13.prov.east.verizon.net) has joined #schooltool [20:12:13]
  217. <tom_hoffman> wow, my Mac just totally kernel paniced. [20:12:30]
  218. <philipp_s> oops [20:12:44]
  219. <tom_hoffman> I hadn't saved a log of the chat, so if someone can send a copy to the list, I'd appreciate it. [20:13:11]
  220. __

Automatic markup by irc2html.scm in 3 second(s) runtime