Support instructors/teachers/professors using DW for class-related projects

[denise]

Title:
Support instructors/teachers/professors using DW for class-related projects

Area:
posting, communities, using DW to conquer the world

Summary:
We get at least three or four instructors per semester asking for promo codes for account creations for their classes (which we're always happy to give!) Since DW is so well-suited to keeping class journals, submitting writing assignments, or requiring class participation, I'd love to be able to code some more support for academic use.

Description:
Obviously each teacher's use of DW would be different, depending on the type of class they're teaching and the level at which they're teaching it (high school, undergrad, graduate work, adult enrichment, etc). This suggestion is less "we should add this" and more "we should brainstorm what we can add that would actually be most helpful".

I'm basically proposing a new category of accounts: "instructor accounts" or "academic accounts" and "student accounts" or "learner accounts" (names obviously subject to change, yadda). This will allow us to set different capabilities for these accounts.

The "academic package" would consist of:

* one promo code per class/class section;
* one "academic community" account per section, with slight changes to the standard community model to make them more appropriate for teacher/class interaction;
* one (or more if co-taught or if class has a TA) "instructor account" to be the admin of the community (or the instructor could use their standard DW account, but all of the instructors I know don't want their students finding their regular DW account!)
* a number of "student accounts" created via the promo code, where the students can choose their own usernames and migrate the student account to a standard account later if they'd like.

Things I can think of, off the top of my head:

* the ability for the instructor to "clear out" a community's posts and comments, moving them to some form of archive (essentially a community rename?) each semester/quarter/marking period/etc in order to store each semester's classwork separately and start each semester with a blank slate

* ability to force a student account created with a specific promo code to be subscribed to/a member of the community for the project, without having to check the checkbox during account creation

* ability to designate an instructor account for each "academic package" that will automatically subscribe to any account created from the promo code (so the instructor won't 'lose' students or have to get them to submit their username to the instructor through some other method)

* ability for the instructor to subscribe to all posts and comments made in the community (without the comm needing to be a paid community, I mean)

What other things would instructors using DW for academic/teaching purposes want to see, or would find useful?

(Edited to remove poll #7997, since this is more of an information-gathering entry than a suggestion!)

Comments

[jumpuphigh]

I think it would be helpful for students to be able to auto-subscribe to tracking all comments on comm posts as well so that they can follow/participate in conversations.

[foursweatervests]

Ability to keep the comm only viewable to those with a code/invite. (Apologies if this is already possible.)

[denise]

It is! You can set entry security in communities to be public (viewable by anybody), locked (viewable only by people who have joined the community) or admin-only (viewable only by the community admins), just like an entry in your own journal can be public/locked/private. There's no equivalent to posting security filters in communities, to let you only display a post to a subset of community members, but everything else works in a comm just like it does in a journal.

[foursweatervests]

Not exactly what I was aiming to convey, but I can see that you've basically covered it anyways. I was thinking more along the lines of locked, yes, but that the admin would distribute invites to certain journals and not have to bother approving each specific request to join. In the end, the difference is probably negligible. Thanks!

[denise]

That's actually almost possible now, too! (Although the people being invited would have to accept the invites.) You can manage membership (including adding members) of a community at the manage community page, and if you put in usernames into the boxes at the end of the membership list, it sends them an invite to join the comm.

But, yeah, one of the things I suggested in my bullet points up there was forcing an account created with a "class code" to be a member of the class community -- like, if I'm a teacher, and I have the code "ENG131-3" associated with the community "eng131-3.dreamwidth.org", right now when a student signed up for the class they'd see "Join eng131-3?" as an option during the signup process. The way I'm proposing it should change would be that any account created with the "ENG131-3" code would be automatically a member of (and subscribed to) the eng131-3 community.

[foursweatervests]

Ohh, clever. Okay, excellent! And thanks for taking the time to explain everything; it's a huge hindrance not having any idea how to code, at times.

[busaikko]

I teach jr/sr high, so students who are not adults. The ability for the instructor to age-lock the student accounts in some way would be good. This could be difficult if the accounts are non-expiring or if, at the end of the term/year accounts can be rolled over into regular accounts. ("Ms. Teacher, my son used the account you gave him to read porn!") (It might be better to actually make this a university deal at first *ponders*)

Some kind of export function, preferably to PDF, for posts and comments, preferably selectable by tags (so for example, you could print to PDF all posts tagged "Creative Writing Project", but not "brainstorming" or "teacher announcements"). This would be great for making class books, and for keeping feedback.

[denise]

If somebody gives an age that's under 18 when they sign up, their account isn't able to view posts labeled (by the poster) 18+ content, or join a community that sets itself as suitable only for 18+. So that part is taken care of! (Although it does depend on people accurately age-labeling their stuff. Some people do, some people don't, and we don't ever override the account owner's chosen settings.)

[busaikko]

Would it be possible for the instructor to set the whole group as one age? For example, if the youngest kid in a class is 13, then set all accounts to 13? And can an account holder change their first-given age at a later point (change from being 13 in class to the alarmingly sudden maturity of 19 when switching to a regular account 6 months later)?

[denise]

I should first mention: we don't allow kids under 13 on the site, because dealing with COPPA is ridiculous.

That having been said, there's no difference between "13" and "17" -- anybody under the age of 18 can't see material marked 18+. LJ has two levels of "adult content" (14+ and 18+) but we only have 18+ (blocks access to anyone not 18 or older) or "NSFW" ("this post is probably not work safe, are you sure you want to see it?" but not tied to an age restriction.)

Anyone can change their birthday with the site at any time, but the 18+ restriction uses the DOB given at registration, not the one given on the profile edit page. So a kid who switched their DOB on their profile after class was over would get points for trying, but no smut. *g*

[kyrielle]

Hmmm.

I definitely do see the concern with parents deciding to jump all over a teacher because their kid lied and got access they shouldn't.

I can see a couple ways to address it, but honestly, none of them really help, because all the kiddo has to do is wait until they get an invite code distribution (or hit up dw_codesharing if it has any) and create an account for themselves with a different birthday. A parent who was going to blame the teacher would still blame them at that point.

[azurelunatic]

Hmm. Sounds like student accounts should be ineligible for invite code distributions; if they need codes they should be able to ask their teacher.

One can't really do anything about a student getting a code through Other Means (aka dw_codesharing) but I don't see any reason a student account would need extra invite codes.

[niqaeli]

Well, no, there's no reason why a student account currently being used as a student account would need invite codes, but if they roll it from a student account to a standard account after their class, they will be receiving invite codes at distribution time and the kid can do what they like with those invite codes.

That's not the teacher's doing, of course -- but the point is, there's a real limit to what you can do to prevent a parent freaking out at a teacher if a kid is smart enough to get access to porn via DW but not smart enough to keep their parentals from finding out. *shrug*

[kyrielle]

What about a student who is in multiple courses using this, either over the course of one term or several, but doesn't want to accumulate Dreamwidth accounts like some kind of trading card? Some system for a student to take the code they were given and tie it to their existing account, thus being allowed (forced) into the class community and signed up, might be good....

I do not know how instructors have used or might use Dreamwidth. But would the ability for the student accounts to post "instructor-visible-only" posts in the community (as an option, that the instructor could enable or not) potentially be useful?

[anne]

I second both of these ideas.

[mirthalia]

+1 to the first half.

For the second half, I do believe it's currently possible to specify "admin-only" privacy when making community posts, which is the same thing.

[tinyjo]

I was going to offer some suggestions for ways to make it more usable with the children I teach, but then I remembered that of course they're all <13 so actually, that's not feasible/relevant - ah well.

PS Not intended to be a passive aggressive whine - I totally understand why you don't want to tangle with COPPA :) It's just that with so many of my 11 year old students having Facebook, etc accounts, it's easy to forget what the legal restrictions are!

[existence]

One thing I can think might be useful is the ability to have certain categories of pages that may or may not change with each semester "wipe." Like syllabus, or readings, or other material links. This may be covered better with shiny things to come to the site in general, though.

[beatrice_otter]

Having participated in a couple of online courses, I can think of a few things. first, it needs to be really easy to PM people (like, have links on the sidebar to PM each person in the class). Because there's a lot of discussion, yes, but there's also a lot of needing to talk to a specific person about specific things that you don't want to clutter up the main group. Second, it needs to be really easy to download stuff (syllabi, articles, videos, etc.) Also, there needs to be group settings within the class--some way to facilitate group projects, small group discussion, etc. For example, the ability for the instructor to post a question/discussion topic that actually posts x number of times (x being the number of small groups) and each person only gets the one for their particular group show up on their reading page. Or for the link-on-the-side thing, links to PM the instructor and PM each group (where sending a PM to that group automatically sends the message out to everyone in the group, and replies automatically go to everyone in the group). Those would probably require some fancy coding, but that's the only function of the class websites I've used that DW doesn't duplicate already in some way.

[mirthalia]

+1

[foxfirefey]

Quite possible the ability to automatically subscribe/access every member in the class to every other member of the class. Don't know if it needs to be enforced (aka, journals would be able to unsubscribe/unaccess afterwards), but it might be nice and help clear initial hurdles of having everybody do it manually.

[annotated_em]

+eleventy to this. Or, heck, just an autosubscribe to the instructor/TA account(s) in addition to the autosubscribe to the class community. My experience in using DW for teaching is that there's always a couple who don't do a universal subscribe/access, which is inordinately frustrating.

[feathertail]

How about an informal usability study of some kind (even just a survey) focusing on how they use Dreamwidth, and/or a theme designed just for them?

[deborah]

As an instructor, it would be really important to me to have a straightforward way to export all of the student work at the end of the semester into a simple, readable, platform-independent format.

[jeshyr]

+1 to this, and all the other sensible comments here. I am not an instructor so I'll bow to their wisdom :)

[deborah]

oh, and also, integration with Sakai and Moodle would make a huge difference. Although my teaching is at a school that uses Blackboard, so it wouldn't help me, unfortunately.

Pipe dream here, but a way to forward authentication from some LDAP/active directory-based system so the students wouldn't need to login multiple times.

[deborah]

I know this conversation is old, but now that I'm into the semester, I've thought of some more things that I would really like as an instructor:

1. The ability to have certain posts that are drafts and can be seen only by the creator and the instructor, until both the creator and the instructor mark them as published for everyone to see.

2. The ability to assign group work. I'm not sure what this would really mean any dreamwidth framework, but maybe if everyone in the course could be put into sections where things which are limited to creator are limited to all of them. Communities would take care of this, possibly with some wiggling.

3. The ability to grade posts, which would have to be visible only to instructor and creator. Probably the best way to go about this would be integration with Sakai and Moodle, so you are using LMS grading tools instead of trying to write a whole new grading system into dreamwidth.

4. Okay, this one is going to be controversial, but. The ability for the instructor to see which logged in users have viewed a thread. Maybe when this is turned on there could be some kind of banner at the top of the page which indicates that your reading is being tracked in the appropriate communities, I don't know. But right now I would really like to know which of my students are reading the discussions in Blackboard, even if they aren't participating, and that's not a feature I currently have.

[mirthalia]

The ability for the instructor to set alerts for certain posts (ie. assignment posts) that will go out to all members subscribed to said post. Instant upcoming-deadline notification for students.

Some way to privately submit text assignments to the instructor outside of using screened comments, maybe. Though I can't quite think of how at the moment.

All that aside, this is a brilliant use for the DW service. A++.

[mirthalia]

Oh, some way to forcibly rollover student accounts might be useful. Once the kids have all finished the class and moved on I doubt the teacher will want them continuing to hang around the comm. And of course exceptions would need to be made for any kids retaking the class, so maybe a checklist of all the student users (with a "Mark All" option to make it less painful).

[azurelunatic]

Would private messages work for submitting text assignments?

[mirthalia]

Not really. Firstly, the instructor would need a method to export all private messages that are assignments in their chosen format (eg. PDF or .doc). Secondly, private messages are plaintext and refuse HTML, so you lose any ability to format things like bold, italics, or links. Thirdly, I don't think anyone who's taking a programming course and is submitting a code assignment wants to risk throwing it into a form (or having it rejected).

Finally, there's a 5,000 character limit on PMs! Not much help if you have to submit a 5-page paper.

[azurelunatic]

So in order to make private messages work for submitting assignments:

There should be a way to distinguish between "this is a message sent to communicate" and "this is a message that contains a submitted assignment"
Private messages should be exportable (bonus points for exporting in chosen format), and the export function should be able to allow exporting all messages, or only assignments
Private messages should allow attachments, because of the markup, format, and size limit issues.

[mirthalia]

Personally, it seems rather unnecessary to do it that way when some of those changes could likely be better implemented through entries or a direct submission form (which could then either forward to a proper email address or possibly some kind of document management system).

For non-attachment assignments, things like the length limit and lack of formatting are covered by standard community entries; the only issue with submitting assignment posts straight to the community is that they might get difficult for the instructor to pick out after a while. (And I think posts also have a character cap, it's just way higher.)