Thanks Nico! Consider my anxieties assuaged ;)
= nate On Mon, Apr 23, 2012 at 10:04 AM, Nicolaas Matthijs <[email protected]> wrote: > Actually, the design definitely doesn't rely on a large set of small images > for it to work. We used to have a lot that were used for lay-out purposes > (rounded corners, gradients. etc.), but gradually we've been phasing those > out for CSS-only solution that tend to degrade gracefully as well. This > hasn't been completed yet, but would be completed during the architectural > work. > > The thing that's been increasing is the number of images outside of a sprite > (not necessarily the number of images) as the team was short on time to keep > adding/removing to the existing sprites, which is also why Christian's > solution is appealing. The main reasons for using images right now is for > icons, thumbnails, etc. In other words, things that images are supposed to > be used for. > > Therefore, I'm no longer very worried about a multi-device strategy, but it > will definitely still requires some work to get there. There's another > question as to whether it makes sense to expose the whole of OAE on a mobile > device, but that's a different discussion that we'll definitely be having > soon ... > > Hope that helps, > Nicolaas > > > >> I do take pause however at what Nico points out: that the OAE design >> relies on an increasing number of (small) images. While I generally >> think the OAE design work has been awesome, I wonder if a design that >> relies more on images will also serve a multi-device/multi-display >> strategy going forward. >> >> On one hand: clearly different output scenarios sometimes call for >> very different designs, and thus one should not have to hamstring one >> design just so it can play well with others. On the other hand, given >> that we have limited design resources, any time we can kill two pigs >> with one angry bird is a win. Would a more style-based, less >> image-based design help OAE deliver better to a wider variety of >> clients? >> >> Perhaps the existing design work is better suited to a variety of >> clients than I imagine. I would love to have my anxiety assuaged. >> >> = nate >> >> On Mon, Apr 23, 2012 at 8:46 AM, Nicolaas Matthijs >> <[email protected]> wrote: >>> >>> Hi Christian, >>> >>> I actually like this idea a lot, especially as we have a lot of smaller >>> images that we are using to support the design. >>> >>> During a previous performance sprint, we actually created CSS sprites for >>> the entire application, but as you say, they are hard to maintain and the >>> number of individual small images outside of sprites has increased >>> significantly since. So in terms of maintainability, this is potentially >>> a >>> great solution. >>> >>> Currently, 55.9% of our requests and 42.8% of all data traffic are >>> images. >>> This means that for an unprimed cache, this solution should actually make >>> a >>> huge difference. For a primed cache, it will matter a lot less though (as >>> they should be cached from that point on), but for the sake of >>> maintenance >>> it's probably still quite valuable. >>> >>> Once we get into the architectural work and have our measurement >>> environment >>> set up, we can properly evaluate it and hopefully use it as well ... >>> >>> Thanks! >>> Nicolaas >>> >>> >>> On 23 Apr 2012, at 03:41, Christian Vuerings wrote: >>> >>> Hey, >>> >>> >>> Over the last couple of days / weeks, I've been thinking a lot on how we >>> might improve our performance on the UI side. >>> >>> One of my previous suggestions was to use CSS sprites. >>> While it would be a good thing to have, it can be tedious to make and >>> it's >>> hard to maintain/update. >>> >>> An alternative solution would be to convert the images that we use in CSS >>> to >>> data URIs [1]. >>> There is currently a library which would do this for us, called CSSEmbed >>> [2]. >>> >>> Benefits: >>> - Doesn't need any extra request, the images are embedded in the CSS (A >>> sprite would still require a request) >>> - Since the CSS is cached, the images are cached as well >>> - Way easier to maintain >>> - We would find images that are referenced in the CSS but not exist >>> anymore >>> (found this while testing) >>> >>> I made a proof of concept (for the CSS files in /dev/sakai/css) on github >>> [3] which we could hook into our release build. >>> >>> Try it out by doing: >>> mvn clean install # will create the necessary folders >>> ant cssembed # replace the images in the CSS with data URIs >>> >>> Some extra features/comments: >>> - Browser support is ie8+ >>> - We can/should limit the size for which we allow generation of data >>> URIs >>> >>> >>> -- Christian >>> >>> [1] http://en.wikipedia.org/wiki/Data_URI_scheme >>> [2] >>> Repo: https://github.com/nzakas/cssembed >>> Usage: https://github.com/nzakas/cssembed/wiki >>> Article: >>> http://www.nczonline.net/blog/2009/11/03/automatic-data-uri-embedding-in-css-files/ >>> [3] https://github.com/christianv/3akai-ux/tree/cssembed >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> > _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
