[IAEP] The User experience/interface for Printing

[Albert Cahalan]

Vamsi Krishna Davuluri writes:

> So, talking to Tomeu, we agreed that for Write and Read using
> the gtkprint would be best as both support it as a printing API.

The focus on "Write and Read" is short sighted and may lead
to inflexible solutions.

> Now, the current plan is:
> 1) We do journal printing only, albeit, the respective
> activity opens the file.

Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf
or directly runs gs. This lets normal software, which is already
designed to output standard Postscript to lpr, work just fine.
After conversion, put the PDF into the journal.

Better yet, just toss the file into the journal without conversion.

BTW, this can also be implemented as a filter script that the
normal lpr program invokes for the default printer.

> Now here a cross road is presented:
>
> 1) Do we use a print dialog inside each activity that can save it as pdf,
> print or export a pdf to moodle
>
> 2) Do we use separate buttons for each of these operations?
>
> What of the user experience?

Separate buttons provides a distinction that will be important
in some environments. Some places will want immediate printing.

For now, the "print" button can be almost the same as the other,
but with the output PDF marked for near-term deletion.

"Make PDF" and "Print now" seem like fine names.

> The initial plan was to make Read the global printing station,
> how do you find this idea?

Starting up Read just to print something is not nice. Read may
even cause an out-of-memory condition. For sure, there is no need
to very slowly render a big document that doesn't even need to be
seen on the screen.

> 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.