That is exactly what my "turn it in" queue is, but I'm sure there may be other ways to implement it ... email to the teacher with an attachment, etc, etc.<br><br><div class="gmail_quote">On Thu, Mar 19, 2009 at 10:16 AM, Wade Brainerd <span dir="ltr"><<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2009/3/19 Carol Farlow Lerche <<a href="mailto:cafl@msbit.com">cafl@msbit.com</a>>:<br>
<div><div></div><div class="h5">> A problem with the desktop-oriented printer support in Unix and in Windows<br>
> is that it has the underlying assumption that the person at the desktop<br>
> should be in unfettered control of the ability to print (with lip service<br>
> paid to an overall page quota). Where this breaks down for children is that<br>
><br>
> . kids love tangible output, so unless someone does something about it, they<br>
> will print everything.<br>
><br>
> . in a school the printer may be somewhere else than in the classroom, and<br>
> kids aren't allowed to roam the building picking up their output. So even<br>
> more than printer users in an office environment, they have no clue as to<br>
> why things don't show up as "printed", or why the print queue is long.<br>
> (Could be a printer jam. Could be a graphics-intensive prior job, or their<br>
> own job being graphics-intensive, could be an unwitting print of a 30 page<br>
> job on a slow printer, etc., etc.) Just as in the "hit the launch button<br>
> again" phenomenon when activity launching is slow on the XO, this leads to<br>
> printing the same document again and again.<br>
><br>
> I'd like to show you the scars from the arrows in my back after spending a<br>
> day a week in elementary school classrooms over a period of several years,<br>
> but it would scare the children.<br>
><br>
> So here is a scenario that I think would be better, especially in an<br>
> environment such as a third world school with few printers and scarcity of<br>
> paper/toner/ink.<br>
><br>
> Vamsi's default pdf printer is great...no consumables, no remote print<br>
> server, nice way to preserve the visual effect of a piece of work for<br>
> posterity.<br>
><br>
> But for printing real output, I think a more draconian control system is<br>
> needed. One possibility: submit pdf files to a Moodle-mediated "turn it<br>
> in" queue. This ensures that an artifact has been produced that the child<br>
> can review and is motivated to review before giving it to the teacher to<br>
> decide if it warrants printing. The teacher can then browse the turned in<br>
> work, printing those examples s/he thinks warrant the expense.<br>
><br>
> Should it be possible to configure a normal CUPS printer queue where kids<br>
> could "just print it"? Yes, there are probably circumstances where this is<br>
> appropriate. But even where kids make the decision about what to print, I<br>
> think having some kind of per-document filter, such as "has this document<br>
> already been printed in the last n hours?", "is this document longer than x<br>
> pages?", "has this child submitted more than y pages in the last time<br>
> period" is crucial. And so it would be good to build that into the journal<br>
> print interface. I don't think the ordinary unix print quota mechanism does<br>
> this, but I admit I haven't looked at it in detail recently.<br>
<br>
</div></div>I wonder if "printer control" could be managed in a social way rather<br>
than a technical one? Say, if a child wants something printed, they<br>
use Journal File Transfer to send it to their teacher, who prints it<br>
for them if they deem it appropriate.<br>
<font color="#888888"><br>
-Wade<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair<br>