UbiquitySlideshow specification Wiki page shock and horror

[Dylan McCall]

> Indeed, the Ubiquity Slideshow team seem to have taken the specification from
> the 7.04 cycle and made edits from there, whereas I built on the one from the
> 9.04 cycle that we discussed at UDS Mountain View (which, confusingly, was the
> same name for the 7.04 UDS).
Aha! (Oops :P)
> 
> Not a problem though, I think we can reasonably merge the specifications and
> combine our efforts to make sure this happens in some form for Karmic.
Cool! Is there a place where we can take a look at the existing efforts,
or is that in specification stage right now?
> 
> I am however, concerned that rendering HTML might be a bit heavy for what we're
> trying to accomplish.  Assuming we wanted to use python-webkit for this, we
> would have to promote it to main.  I'm also concerned that we either have to
> restrict designers to layout each slide to a rigid specification, or force them
> to understand a specific set of HTML tags.
> 
> Also, out of my own curiosity, how do you plan on providing translation support?
> 
> At UDS Barcelona I had a discussion with Ted Gould of the Desktop Experience
> team and the Inkscape project, and he mentioned that the Inkscape project is
> able to provide translations in SVG by simply putting an underscore in the tag
> name and processing the text before rendering.  It should be fairly
> straightfoward to implement and we already have rsvg on the Ubuntu CDs.
> 
> I am not suggesting that we must implement it this way, though I do think it is
> the better approach for the reasons outlined.  Still, I am open to the opinions
> of others on this.
> 
> I also spoke with Gerry Carr, head of Platform Marketing at Canonical, at UDS
> and he expressed interest in taking on the task of creating the messaging for
> each slide.  This was a task that the Design and User Experience team had
> originally wanted to take on in the 9.04 cycle, but they could not fit it on
> their schedule and thus the specification was deferred.
> 
> Whatever we agree on, we'll have to act quickly as the deadline for
> specifications to be approved is Friday.
> 
> So, thoughts?

There are a few reasons for going with HTML:

      * Firstly, there seemed to be (and still is) a chance of GNOME
        adopting Webkit as a dependency for 2.28, which would /probably/
        hit Karmic (especially if we take in Empathy), and if not for
        that it would for 2.30. If Webkit doesn't happen, there's always
        Firefox's engine, although it isn't as suited to the 'embedded
        presentation framework' use.
      * Rigid and streamlined. The main frame is a 2 kb html file that
        links to a 3kb css file, while individual slides all hover under
        1kb. Not counting pictures, of course, which make up the bulk of
        file size. When I was doing it with SVGs, slides were all around
        10kb which is still nice and tiny, but is mostly made up of
        duplication - something that makes my blood boil. With HTML,
        things adopt the same visual style mostly because CSS allows it,
        and are automatically inserted inside the same
        'frame' (Slideshow.html), thus each slide just has its unique
        content and nothing more. There is room for full control over
        the slide content, but it's possible to just punch in some words
        and some pictures and get a slide that looks absolutely
        consistent. Then, a change to styling across the presentation
        can be applied in seconds.
      * SVGs are indeed great for translations. That's an interesting
        thing about Inkscape doing it directly. Is that new? ...Still,
        so is HTML! There is a handy little tool called html2po (and
        po2html) that can be used for this. Not sure if the live cd has
        that on hand, but if not it's possible to run it before
        shipping. That presents a case where the linking nature of the
        HTML design comes in handy: Each localization, in the current
        form, would be 10kb total for new text at most no matter how it
        gets done. (Although, granted, it would be nice if we could
        localize screenshots as well...).
      * With HTML, we can provide some extra interactivity like alt text
        for images (presented via javascript) at no cost. Also, we get
        working hyperlinks. While I don't think the latter is enormously
        useful given the simplicity needed here, it's still handy to
        have them. Also, again for localization: Where text absolutely
        will not fit, a scrollbar could appear fairly neatly, but let's
        hope that never happens.
      * By putting slideshow presentation into the slideshow project
        itself via Javascript, Ubiquity's end of things can be nice and
        simple. Details like how to switch between slides get to be
        handled by the slideshow people for particular flavours, which I
        think makes a lot of sense.
      * The slideshow renders in a web browser just like it renders in
        Ubiquity. Easy to test, and easy to reuse outside of Ubiquity if
        desired. For example, some people on the Docs mailing list
        expressed interest in having the same slideshow somewhere in a
        new system. Indeed, I think that may make some sense to have a
        launcher in example-content that just pulls open the nearest web
        browser.
      * Right to left language? Absolutely not a problem.
      * Accessibility :)
      * Worst case scenario: Have Ubiquity handle the presentation end
        of things completely (including drawing a background picture,
        rendering the text and the images, transitioning between
        slides). It could pretty safely parse the individual slide html
        files and do that, since they are that trivially simple (and
        consistent).


Looking forward to what Gerry comes up with. I'm thinking of the current
slides (and deeply sorry I never made this clear earlier) as almost a
skeleton. Although what is there is /nice/, there's a lot of time to get
these perfect, so a spirit of phoenix-like rebirth springs to mind. With
a skeleton (and some pretty good content and screenshots, if I may say
so), new contributions - be they new slides or amendments to slides -
can base themselves on what they know exists. Good stuff springs from
that.

I also have some simple writing guidelines in the Readme at
lp:ubiquity-slideshow-ubuntu (which the whole thing is currently not
compliant with, but dreams of being some day). I trust Gerry and the
design team to come up with some pretty brilliantly awesome stuff
regardless, but it's there if wanted.


Thanks for all the information, Evan.


Dylan McCall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-installer/attachments/20090617/01e8323d/attachment.pgp