Re: ACTION-961: usefulness of multipart-mixed [recent mobile CSS sprite case study]

Thanks Stephanie, that makes sense.

Completely understand about issues around releasing internal code publicly
-- I know how that feels :)

If that turns out not to be possible, even some thumb-in-the-air numbers
would be helpful so we can say something about the the kind of trade-offs
involved (perceived complexity vs latency improvement). Even something
really simple, like, say: For a start-up page containing XX icons, start-up
latency on 3G = xx seconds with individual images and yy seconds with
sprites...

Regards,

Adam.

On Wed, Jun 10, 2009 at 10:40 AM, Stephanie Rieger <steph@yiibu.com> wrote:

> Hi Adam,Let me get back to you on questions 2 and 3. While our tests were
> by no means exhaustive we did make use of some simple utilities which had
> been built into a series of widgets for easy install
> and dissemination during testing. I'm not sure however if we can release
> these to the general public so need to check with my client first.
>
> To answer your first question, this may seem a bit arcane and geeky but
> when working on large sites, with multiple teams and/or on long-term
> projects that require lots of maintenance, sprite sheets can help workflow
> in a bunch of ways. Firstly, you always know where the graphics files are
> because there are limited numbers of them vs the often huge folders of
> disparate graphics that result from the use of single images.
>
> Whether you're actually implementing one great big sprite sheet or
> sub-collections of smaller ones, the whole lot can be housed in one graphics
> file then sliced up using native slicing tools enabling you to export any
> number of sprites as needed.
>
> Re-skinning or making site-wide changes can also be much easier both from a
> visual point of view (checking the consistency of 30 sprites on one big page
> is far easier than trying to cross-check 30 separate images), and a workflow
> point of view (search and replace in most graphics tools can re-skin a whole
> site in minutes). It's also quite useful when obtaining sign-off from
> stakeholders as once again, you provide one big graphic which gives brand
> teams an excellent overall view of look and feel and adherence to
> guidelines.
>
> Will try to provide more input on the other items by the end of the week.
>
> Regards,
>
> Stephanie
>
>
> On 9 Jun 2009, at 15:03, Adam Connors wrote:
>
> Hi Stephanie,
>
> Thanks for that incredibly useful feedback. Your experiences tally well
> with my own and as you say it is extremely helpful to collate a good number
> of real-world experiences. Couple of further clarifications / questions if
> that's okay:
>
> 1. Can you explain to me what you mean by "helping workflow" ? I'm not
> quite clear on how css sprites help here ?
>
> 2. I'm very interested in your comments on how you decided to partition
> your sheets, trading off how many images to place on a single sheet. If you
> have some numbers / experiments to hand that can demonstrate the trade off
> and how to optimize latency that would be very helpful.
>
> 3. Do you have any measures / samples that indicate the latency saving you
> see over mobile networks, and / or memory usage on target devices ? Or if
> not, any code snippets that we could use as a starting point to create some
> samples ?
>
> 3. Have you any experience with using css spriting with off-line
> technologies (e.g. appcache). Is it still useful in this context? (My
> suspicion is that it is since an appcache reload happens in the background
> while the app is loading and can still impact latency, but I have no
> concrete numbers in this area).
>
> Many thanks,
>
> Adam.
>
> On Wed, Jun 3, 2009 at 12:42 PM, Stephanie Rieger <steph@yiibu.com> wrote:
>
>> Hello,
>> I've just joined the list so have not been privy to the entire
>> conversation however have just completed a large mobile web project that
>> made extensive use of CSS sprites.
>>
>> So I thought i'd pass on what we learnt during this project as real-world
>> examples on this topic are hard to find...
>>
>> The primary reason we decided to use sprites was to reduce lag when
>> loading rollovers and multi-state graphics. This worked remarkably well! We
>> successfully implemented and tested CSS sprites across all Nokia WebKit
>> browsers (including the earliest webkit versions and the newer S40 webkit
>> devices). After testing RAM consumption with a variety of sprite sheets (ie.
>> one large one for the entire web site vs various groupings of small ones and
>> executing comparisons of RAM consumption when larger or smaller numbers of
>> graphics are 'revealed' at a time,) we opted for a collection of small
>> sheets (ie. containing on average 2-5 states) rather than one or multiple
>> larger sprite sheets.
>>
>> >From a workflow point of view, this approach was far preferable to single
>> graphics and (with judiciously written CSS) eliminated common design
>> discrepancies caused by differences in pixel positioning across devices as
>> it allowed us to make extensive use of the 'top' and 'bottom' x/y positions
>> rather than set a pixel value for each sprite state.  It also allowed the
>> grouping of sprites by use-case/task to limit the 'accidental' download of
>> graphics that are not actually needed during common tasks or flows. Finally,
>> as the sprites were used for non-semantically critical elements (hover
>> states, tiled backgrounds etc), the need for alt tags was reduced. (In cases
>> where search engine friendly text-strings were critical, the sprite would
>> typically not have been the sole purveyor of this data anyhow).
>>
>> FYI - We also tested the entire project on Opera Mini (v4) and found that
>> the support to be excellent (i.e. it all worked fine :-)). The very same
>> HTML/CSS also worked perfectly on Maemo, desktop Firefox and Safari
>> (including the iPhone) so this was not 'Nokia-optimized' markup.
>>
>> If memory serves from a past projects, pre-webkit Nokia devices (and many
>> other devices of that calibre) do not support the necessary CSS to make
>> consistent use of sprite sheets. It is worth noting however that, when
>> formulating device groupings and design/adaptation rules, pre-webkit/less
>> capable devices will most often fall in to a separate category anyhow due to
>> their screen size and overall capabilities. These devices will most often
>> not share the same design/style sheet and will make far more extensive use
>> of native background colours than graphics for rollovers, backgrounds etc.
>>
>> It is therefore plausible to safely use sprites extensively within the mid
>> and upper range of your device groupings without necessarily compromising
>> design or performance on less capable devices. All this should be tempered
>> with a realistic assessment of just how many graphics you actually need as
>> it's by no means wise to implement vast numbers of graphics on a mobile
>> site.
>>
>> >From a desktop web best-practice point of view, CSS sprites remain quite
>> popular as they are extremely consistent in behaviour (notable exception
>> being desktop Opera 6) and are hugely useful from a workflow point of view.
>> I would also suggest that in recent years, they may have finally moved out
>> of the realm of 'hack' and into that of best practice on the desktop.
>>
>>
>> http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
>> (sprite usage examples from Amazon, Google, YoutTube etc.)
>>
>> Hope this was useful. Feel free to ask for clarification on points if
>> needed.
>>
>> Regards,
>> Stephanie
>>
>> On 3 Jun 2009, at 11:45, Eduardo Casais wrote:
>>
>>
>>> I am the one who originally suggested to look at multipart/mixed rather
>>> than
>>> sprites as a mechanism to reduce the number of HTTP transactions, and
>>> hence
>>> overall latency. I try to summarize the discussion so far.
>>>
>>>
>>> 1. SPRITES
>>>
>>> They require pre-processing (assembling a composite image and generating
>>> CSS
>>> directives to present the individual images from the composite bitmap).
>>>
>>> Because of the absence of the "alt" attribute, sprites are at most only
>>> suitable for decorative bitmaps, without semantic properties (alt is
>>> important
>>> for accessibility and search engine optimization).
>>>
>>> We are not sure the CSS required for sprites is available and implemented
>>> correctly in a sufficiently large proportion of mobile devices.
>>>
>>>
>>> 2. MULTIPART/MIXED
>>>
>>> Is a technique, defined by standards, to encapsulate resources of all
>>> types
>>> (not just images) into one package. There is a MIME type associated to
>>> it.
>>>
>>> It can be used both at the proxy and at the server (greatest benefits)
>>> side..
>>>
>>> Availability of implementation varies considerably:
>>>
>>> a) Desktop browsers have been generally lacking support for
>>> multipart/mixed
>>> (Firefox and Opera: buggy; Safari entirely absent; IE ok).
>>>
>>> b) Mobile browsers require accurate knowledge to avoid delivering content
>>> that is unrecognized by the device. From what I know, Openwave and
>>> Blackberries
>>> have had fair support for multipart/mixed, jataayu should have it too;
>>> Nokia
>>> was notable in not implementing it in its original mobile browser, and
>>> since it
>>> relies upon Safari/WebKit nowadays, I am not at all surprised at the
>>> results of
>>> Luca's quick test with a N95.
>>>
>>> c) It is reasonable to assume that mobile browsers derived from desktop
>>> technology (i.e. Safari/WebKit, Opera, Ozone) do not support
>>> multipart/mixed.
>>> Information about other major mobile browsers (NetFront, Obigo) or
>>> newcomers
>>> (UCWeb, Bolt, Skyfire, Android) is missing. Maybe representatives of the
>>> respective companies in the W3C can shed some light onto this.
>>>
>>>
>>> 3. CONCLUDING REMARKS
>>>
>>> Sprites appear to be a hack of a restricted scope and of limited
>>> interest, not
>>> really suitable as a best practice.
>>>
>>> I share the opinion of Magnus Lönnroth and John Hardi that
>>> multipart/mixed is
>>> not an obsolete technology, and can really help reduce latency while
>>> keeping
>>> resources of different types separate. However, one must be very
>>> knowledgeable
>>> about the target devices, and hence this is not a technique to apply
>>> blindly.
>>> It seems like a good practice for experts -- whether it is a best
>>> practice is
>>> doubtful.
>>>
>>> The fact that there are discussions about how to reduce the number of
>>> HTTP
>>> transactions for one page, whether by bundling resources into one page,
>>> using
>>> sprites or relying upon multipart/mixed, and that some of these
>>> approaches
>>> were developed or proposed in the _wireline_ Internet (and recently at
>>> that)
>>> means that 3G or 3.75G or 4G or whatever, latency remains and will remain
>>> an
>>> important factor when developing mobile services. I wish browser
>>> manufacturers
>>> would keep this in mind and implement standards that help address this
>>> problem.
>>>
>>>
>>>
>>> E.Casais
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> Stephanie Rieger
>
> http://yiibu.com
> Yiibu: lovingly crafted mobile experiences
> +44 (0) 7957 651 177
>
> Twitter: stephanierieger
>
>
>
>
>