[IAEP] The User experience/interface for Printing

[Albert Cahalan]

On Mon, May 4, 2009 at 1:47 AM, Andrés Ambrois <andresambrois at gmail.com> wrote:
> On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote:
>> Vamsi Krishna Davuluri writes:

> The priority is on sending the docs to cups-pdf for conversion and then
> talking to Moodle for teacher review. It is a good idea to have the code
> that sends docs for printing (to Moodle, a local printer, or one discovered
> by avahi) in a reusable module that a /usr/bin/lpr script can use.

Sending the docs to cups-pdf for conversion and then talking to Moodle
for teacher review can be done via /usr/bin/lpr, eliminating the trouble
of having multiple data paths.

> Adding a print dialog to every activity (e.g. Adding some gtkprint support
> in sugar-toolkit) should be optional for GSoC. First we should concentrate
> on getting entries printed, and getting teacher review right. Then we can
> move code around for legacy support and nice "print me" buttons.

If you start with what you disdain as "legacy support", then you
can trivially test "getting entries printed" from the command line.
The same goes for "getting teacher review right".

You could even test with the TuxPaint activity, using real kids.

>> > the teacher checks his print page in moodle, views the file (either
>> > through fancy javascript or a download) and approves/disapproves
>> > for printing. Kennedy then logs into his moodle print page and
>> > checks if the job was success or not, and if he has a comment from
>> > his teacher.
>>
>> I can barely imagine that happening in a real classroom. Try this:
>>
>> The student brings his XO to the teacher's desk, with his work shown
>> on the screen. The teacher looks at the work, then lets the student
>> plug his XO into a printer which sits on the teacher's desk.
>>
>> > Printing resources can be very expensive for most schools, so
>> > the system should include a way for students to submit jobs to a
>> > queue and for an administrator to preview and approve or denie them.
>>
>> Tux Paint can rate limit a student's printing. For example, a setting
>> of 60 will be once per minute.
>>
>> Do not forget that this issue is more social than technical. In addition
>> to any discipline, the teacher can simply turn off the printer. This is
>> advisable in any case; many printers use excessive power in standby.
>
> I dont see a teacher having a printer on her desk. Most schools here in
> Uruguay (and I dare say in Perú) don't even have printers. If there is one,
> it will be where the server/administration is. And possibly locked in a cage
> (like we have the servers now). So that scenario is going to be priority
> one.

That sounds like a printer that students aren't allowed to use.
Such a school might not need printing support at all.

Teachers are unlikely to learn a complicated (probably slow too)
interface for approving printer use. I just don't see it happening
with regular normal everyday human teachers.