OK, I'm jumping in here, and I have a functional question (below), and a simpler question I'll start out with:
1) Would it be helpful to others to annotate your functionality list as found on the front page of the DrupalEd install (and copied here) with a list of actual Drupal modules? It's one thing to know the list of 20-odd modules in the package; it's another to know that the "formal class spaces" is (or is not) a Groups home page? Or whether the class blog is also part of the Groups setup, or is it a Views configuration? I know this would help me think about the site - and I am offering to guess for the first pass and have Bill correct me (based on the published list of modules). :-)
2) I've mostly examined DrupalEd in the context of on-site, class-based use. What is your recommendation for using this on a combo-site: public facing school site, plus classroom pages. I am planning on building a public-facing website for our K-8 school; in recent conversations with teachers, several of them would love classroom pages, calendars and student blogs. I would prefer not to build (and maintain) two sites -a public one, and then install DrupalEd locally - but there are some functional / security questions. We don't plan on having full contact information listed for any student (LisaK would be as far as we got), but still....
- Is having (under-18) student logins on a Internet-accessible site more security and monitoring work than it's worth?
- Would it be ridiculous to consider hosting this on an ISP server?
- Finally, my DrupalEd functionality question - how much of the internal classroom working is completely hidden from anonymous users, so I can have a regular Drupal web-publishing platform for our public school site, with public blog, public calendar, etc....
Bill, as I hope you are well aware by now, I count among the deeply grateful for your and Marc's work on this. :-)
Comments
Hello, Greg, A few quick
Hello, Greg,
A few quick thoughts here:
First, I'd gladly trade places with you about now :) -- this trip sounds like a whole lot of fun.
Now, to the geekery --
RE the annotated functionality list, I agree, it would be a good thing -- some of the functionality involves using a few modules together -- for example, the courses are created using OG, CCK, Views, and Viewfield -- this will make sense to users more familiar with Drupal, but could potentially scare the bejeezus out of non-technical users.
RE a combo public/private site, this is certainly achievable, but there would need to be some attention paid to the UI -- all/most of the blocks that create the navigational structure of the public-facing site would need to be swapped out when a user entered the private work area -- while this is possible, it adds an additional level of admin complexity to running the site -- combine this with the attention to detail that would need to be paid to user roles and access control, and it will probably be easier to maintain two separate sites: one for the public presence, and the other for the private working site.
RE: under 18 -- IANAL, but assuming you are running the site as a walled garden, with teacher/staff approval needed to make student content public, this would be a lesser issue. 13 is an important age, as that is the cut-off point (in the states, anyways) for COPPA -- A quick conversation with a lawyer is my recommended course of action on this one --
While the class functionality can be completely invisible (by having the classwork private within groups), it is possible to have the classwork be private, with teachers/staff publishing selected work publicly. In the two-site scenario described above, you could use feedparser/leech/aggregation modules to import selected feeds from the private site to the public site.
RE: grateful -- thanks!
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Thanks - and ugh
(Yes, France was a blast in many ways. :-) You sure you can't go to Barcelona?....)
Annotated list: I agree, not something to put on the front page, but perhaps useful as part of the documentation. I'll make a first swipe, and I'm sure you'll have to clean it up. I'll post as a text entry here?
Dual (duelling?) web-sites: Ugh. I was afraid you'd say that - although it makes the most sense. I'm NALE (not a lawyer either), so the two-site walled garden solution is also partly driven by the desire to reduce unnecessary security patching and lawyer referring..... :-)
A random question on this topic (as opposed to one of several dozen other random questions) - how is the "posting to public site" handled? I understand the xml feed import on the public side, but from where? Would a separate page need to be built (using taxonomy? and views?) to publish a "export to public site" feed? I assume we could always mis-appropriate the "publish to front page" for that purpose, assuming you've redirected the front page in the settings..... ;-)
The Smoking Goat aka Greg Beuthin
http://www.commerceguys.com
Hello, Greg, RE security
Hello, Greg,
RE security patching and lawyer-referring --
The need for security patches will be driven by the integrity of the code. Since we released DrupalEd, there have been no security patches on any of the modules used in the install profile, therefore the choice of whether to upgrade or not has been exactly that: a choice, as opposed to a security necessity.
RE lawyer-referring: while it's high on the PITA factor, it can save you hours of unpleasantness, and it's part of the groundwork I recommend preparing prior to rolling out a site for younger students. And, the 2 site solution can actually increase parental comfort with elementary and middle schools -- For example: "No, Mrs. Jones -- Sally only works on the site that is private for her and her classmates."
RE Barcelona: I wish, but it's not in the cards for me this year. Oy.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey