[Sugar-devel] [DESIGN] Browse PDF handling

[Gary Martin]

Hi Daniel,

On 15 Feb 2012, at 22:29, Daniel Drake <dsd at laptop.org> wrote:

> 2012/2/2 Manuel Quiñones <manuq at laptop.org>:
>> I'm proposing, for the new and fresh Browse wearing WebKit, the
>> following behaviour when clicking on a link to a PDF:
>> 
>> - the PDF is shown in a new tab, next to the current
>> - basic document navigation is provided to the user
>> - as well, a button to save to Journal is provided
>> 
>> Using the save to Journal button, the kid can now read the PDF
>> starting the full-featured Read activity.
>> 
>> This behaviour is similar to what Safari does, and I think it fits
>> Sugar user interface better than other approaches we where thinking
>> before, like start Read directly, which provokes an interruptive
>> activity switch.  Also this way, an entry in the Journal is made only
>> if the user ask for it, and allows a quick read of the PDF then you
>> can decide on storing.
> 
> I don't think this is the right direction, personally. I agree that
> right now it is a horrible user experience to open a PDF file from
> Browse, but this is something that we should fix at the Sugar/Journal
> level. From a technical or design standpoint I don't see what's
> stopping us in making a click on a PDF download link in Browse
> immediately open Read, solving the interruption described above.

FWIW, even with the latest XO hardware Read takes about 15sec to launch (and then more to load/display the pdf). This would make for a rather jarring experience, along with jumping you out of the browse UI. Casually hitting pdf content while web browsing, perhaps not even realising the next link is to pdf content, seems to be a separate workflow/use-case than using a dedicated reader (annotations, bookmarks, resuming at the page last viewed).

> The storage aspect is a little more interesting, but doesn't really
> follow the rest of Sugar where the Journal records what the user has
> done without considering otherwise.
> 
> Your proposal seems to be basically bundling Read into Browse, and
> this will result in the usual side effects of code duplication: having
> to fix bugs and add new features in 2 places,

Yes, agreed this is the cost if we want to smooth the workflow when web browsing pdfs.

Regards,
--Gary

> confusing the user by
> having 2 ways to do the same thing, providing a strange user
> experience of switching from one to the other, using more system
> resources than otherwise, etc. And as soon as another file format gets
> popular on the web we'd be pushed to roll another activity into Browse
> as well.
> 
> Either way, I definitely applaud the effort to make the textbook
> experience better in sugar, many thanks for spending time on this.
> 
> cheers
> Daniel