UbiquitySlideshow specification Wiki page shock and horror
dylanmccall at gmail.com
Wed Jun 17 15:53:19 BST 2009
> 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
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
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
* 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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-installer/attachments/20090617/01e8323d/attachment.pgp
More information about the Ubuntu-installer