Shifting this over from schooltool-dev: On 10/22/05, Philipp Schröder <[EMAIL PROTECTED]> wrote: > Hi, > > Philipp Schröder wrote: > > +1 for all :-) > > Tom Hoffman wrote: > > Well, "fix everything" is not a plan ;-) > > Which ones will be fixed first, and how that will mesh with new > development? > > Point taken. :-) Ok, here is my view, see comments below. > > Albertas Agejevas wrote: > > > * Things that Tom must decide how they should work, then we'll come > > up with a way to implement it: > > > > - Security > > This is a difficult one, IMO. I think it needs consideration of who > needs to do what, i.e. what roles are supported in the system (learner, > instructor, school clerk, sys admin, ...?) and what are the tasks the > need to achieve. I think it is clear to everyone that the "object > oriented" ACLs security offers way too many options to be effective.
Right now, the access control view is simply a re-skinned version of the Zope 3 access control panel. It will have to disappear in SchoolTool 2006, because it would give the site manager far too many opportunities to expose confidential data accidentally. The entire security system will be much less exposed to the site manager and much less flexible, particularly for data related to persons. Things that can safely be shared will probably end up with something like a simple (relatively) "sharing" form, similar to Plone's. We're definitely bumping up against the need for default roles, but they seem pretty well established at this point: teacher, student, clerk, school administrator, site manager. More will be necessary, but we should see if that's enough to get us through the first year. This is definitely something we could use concrete feedback on from people who are using the system. > > - Sections, their titles, etc. > > I have brainstormed over this one and am preparing to send my thoughts > to the list. > > There is no quick'n'easy solve-all solution in my view. Course sections > appear in various places and it depends on the context of a particular > screen what the exact amount of information is that a particular user > wants to see. I think I would be helpful to talk, for example, to school > clerks to learn how they think about their tasks. Right now, the section object is just a mess of problems and mis-understood solutions. Fixing it shouldn't be hard. We mostly have to just rip some bits out and work on iterations of the relevant forms over the next eight months or so. We will also be able to make some improvements to how we display the section title when we have built in roles. But yeah, this is someplace we've already gotten user feedback on, and we'll need more as we go forward. > While Schooltool's "object-relational" system is very powerful, I'd > argue this isn't the way "normal" users think. It's necessary to provide > the right amount of information at the right place, for a specific task. I'm not sure what you mean here. > > - Attendance tracking > > (This needs more thinking). > > There are at least two seperate aspects: 1.) taking notes about > attendance and 2.) tracking that data, drawing conclusions and taking > action, like 3.) informing parents, for example. Question: Who is > supposed to be in charge of (1),(2) and (3)? Is it (i) the teacher, (ii) > a school clerk or (iii) a school manager? > > To me, 1-i, 2-ii and 3-iii make sense (but it depends on the school > environment!). At our school, teachers take notes about attendance on > paper and then hand that to the clerk, who enters the data. The clerk > will notify the appropriate school manager if attendence is low, who > will then decide what further action to take. > > BTW, I have talked to a teacher about attendence and he felt it's > problematic to put attendance into "hard numbers". He said that he > prefers to be able to "weigh" the overall performance of a student > during a term and then give a "justified" final attendance record at the > end of term. But this is wandering into educational politics now! ;-) > Bascially, I think the important questions to answer are: > * Who enters the data initially? > * Who evaluates the data and decides on actions? > * To whom are "low attendence warnings" given? (to the learner directly > or their "guardian", who ever that is?) > * How is that warning given? (simply a record of individual absences? a > text paragraph describing the problem?) Different types of schools have more or less strict requirements for how attendance is handled. All public US K-12 schools are very strict, or at least are supposed to be very strict. It seems to me that it makes more sense to start with the strict cases, and the more slack cases will be relatively easy to take care of by just turning things off. As far as the "business processes" around attendance, there will always be a lot of variation across different schools. We'll build up enough options around this as we can as we work with test schools. I don't, at this point, feel like we can plan exactly which features we're going to need. That's why we're going to line up some more formal test schools and put an alpha release in their hands in January. They'll be able to tell us what additional features they need. > Another question: Is the assumption that the teacher has their own > networked computer running during every class? I don't think that's a > good general assumption to make. And even if so, I think the attendence > GUI needs to be separate from the other Schooltool GUI. The GUI would > need to be able to tie-in with the upcoming "Teacher's tool" in > Edubuntu, for example, or any other equivalent (commercial) teacher's > classroom tool, ideally. The assumption in SchoolTool 2006 is that every teacher has their own networked computer running in every class, and that the teacher will enter attendance data in real time, via the SchoolTool web interface. I don't know why, in this iteration, we would be worrying about interfacing with other applications, which probably won't be used at our test schools. I'm sure we'll also come up with forms to allow relatively efficient entry of data by a clerk who is entering the data for the whole school, but I'm more interested in the case where every teacher has a computer. In the longer run, we'll want to add support for taking attendance via pda, cell phone, & scanned paper forms, but that's down the road. > > * Missing functionality that we can live without for now: > > > > - Storing timezones other than UTC in calendars. An example > > use case: I set up a recurring event to wake me up at 9:00 > > Vilnius time. That's 6:00 UTC. Then the summer time ends, > > and SchoolTool starts waking me up at 8:00 Vilnius time! > > Some events must disregard DST (SchoolTool meetings), some > > must regard them (people's daily lives, timetables, etc.) > > Personally, I agree that this use case isn't a pressing need right now. :-) Hm... Well DST is ending soon here, so I guess we'll see just how big a problem it really is. > > - Support VTODO in iCal. Users get upset when SchoolTool eats > > their TODO items in their calendars. > > I agree that this is a pressing need either. > > > * Missing bits of functionality that are really important to have: > > > > - Resource management/booking in timetables. It disappeared > > somewhere when SchoolTool was ported from Twisted to Zope 3. > > Relatively straightforward, plus we have done it before. > > +1 definitely! > > I think this would really advance the usefullness of Schooltool a great > deal with comparatively little effort. Yes, this needs to go back in. > However, I think the resource object needs to be improved. The most > obvious that comes to mind: 'seat capacity' for locations! > If it is decided to improve the resource management component in > Schooltool, I'd gladly volunteer to help with establishing the > requirements and drafting an implementation sketch! :-) > (There are some ideas to be taken from existing resource management > systems). :-) We still don't seem to have the permissions completely straightened out on the new site, but you specifically should be able to add proposals to the SchoolTool 2006 roadmap (the intent is that everyone can, but that doesn't seem to be working yet), so go nuts: http://www.schooltool.org/products/schooltool-2006/roadmap/ > > - Deleting School Timetables and Terms. Many users complain, > > and it is quite easy to implement. > > +1 > > Since the main concern is that deleting a schema can destroy an entire > school's set of scheduled events: would it be possible to make this > action undo-able somehow? I may be overstating the difficult of this. > > * Bugs -- missing functionality that is already supposed to be there > > - Section permissions -- sections should be Zope 3 security > > groups in order to let their members access their info. > > I just noticed this problem yesterday, myself. > > Alga, it would be helpful to provide 'use cases' when you are making > such comments, otherwise readers might not follow what you are talking > about! ;-) (Ok, ok, this went to the developer list). > > Use Case: Teacher Anna Shepherd needs to take over a section from her > colleague who is ill. The clerk now assigns Anna Shepherd certain rights > for that section, so Shepherd can view the list of all students > participating in that section. > > Alga, would my above use case apply to what you were saying? Yes, I think that's what he's talking about. --Tom _______________________________________________ Schooltool mailing list [email protected] http://lists.schooltool.org/mailman/listinfo/schooltool
