[Sugar-devel] Web activities and responsive design: the dark side

[Gonzalo Odiard]

Thanks Lionel, is very valuable.

Gonzalo

On Fri, Oct 24, 2014 at 12:21 PM, Lionel Laské <lionel at olpc-france.org>
wrote:

> Hi all,
>
>
>
> As I've worked on Sugarizer v0.5, I was faced to the need to adapt web
> activities to a responsive design.  Shortly, it means that activities could
> be usable with different screen resolution from smartphone to PC. I would
> like to share with you some lessons I've learnt.
>
>
>
> 1) Think to multiple screen
>
> "old" activities was conceived for the XO resolution (1200x900) or at best
> for a PC screen size. With possibility to run activities on any device, you
> have to support lower screens too. I've choose to support 480x320 (small
> smartphone), 1024x768 (small tablet), 960x540 (medium smartphone). It could
> be interesting to support greater resolution too like 1920x1200 (HD
> Tablets). More on current screen sizes here [1].
>
> Note also that smartphone screens are used in portrait mode but to avoid
> complexity I've choose to force landscape in Sugarizer. So you could
> consider that the width is bigger than height.
>
> Note that Firefox include a very nice tool to test multiple resolution [2].
>
>
>
> 2) Use percent instead of pixel
>
> To set size of objects, you should replace in your CSS file pixel size by
> percent. Instead of pixel, percent is size independent. Do the same for
> positioning too. For example, in one of my activity I've replaced:
>
>
>
> .game-popup {
>
> left: 400px;
>
> top: 460px;
>
> width: 250px;
>
> }
>
>
>
> by:
>
>
>
> .game-popup {
>
> left: 25%;
>
> top: 55%;
>
> width: 40%;
>
> }
>
>
>
> Note however that it don't work for height because height is computed
> during page rendering.
>
> In that case or when you really need to use pixel size, you could use
> max-height and max-width like in:
>
>
>
> height: 300px;
>
> max-height: 30%;
>
>
>
> Finally, note that as specified on 1), screen resolution are not only
> different but has different width/height ratio. For example ratio is 1.5
> for 480x320 and 1.7 for 960x540. You should take that into account when you
> compute size of page elements.
>
>
>
> 3) Adapt content
>
> Using percent is not sufficient. You will have to change your page
> depending of the screen resolution. The better place to do that is in the
> CSS file. More precisely, you could use media queries to adapt dynamically
> items size to the current screen size.
>
>
>
> Let's take an example from one of my activity. As you could see: width,
> font and border are specified for each resolution.
>
>
>
> @media screen and (max-width: 480px) {
>
> .shadowbutton-image {
>
> width: 60px;
>
> }
>
>
>
> .card {
>
> border-width: 3px;
>
> box-shadow: 3px -2px 2px 1px black;
>
> }
>
>
>
> .cardText {
>
> font-size: 12px;
>
> }
>
>
>
> .home {
>
> top: 24%;
>
> }
>
> }
>
>
>
> @media screen and (min-width: 481px) and (max-width: 640px) {
>
> .shadowbutton-image {
>
> width: 80px;
>
> }
>
>
>
> .card {
>
> border-width: 4px;
>
> box-shadow: 4px -3px 3px 2px black;
>
> }
>
>
>
> .cardText {
>
> font-size: 14px;
>
> }
>
> }
>
>
>
> Sometimes, playing with size will not be sufficient. In that case, you
> could think to hide or shorten some items in your UI.
>
>
>
> For example Gears activity automatically hide help button if the screen is
> too small.
>
>
>
> @media screen and (max-width: 567px) {
>
> #main-toolbar #help-button {
>
> visibility: hidden;
>
> }
>
> }
>
>
>
> Or GridPaint activity compute in JavaScript a canvas zoom to adapt drawing
> to the screen size.
>
>
>
> var wsize = document.body.clientWidth;
>
> if (wsize <= 480) {
>
> zoom = 0.353;
>
> } else if (wsize <= 640) {
>
> zoom = 0.501;
>
> } else if (wsize <= 854) {
>
> zoom = 0.565;
>
> } else if (wsize <= 960) {
>
> zoom = 0.645;
>
> } else if (wsize <= 1024) {
>
> zoom = 0.95;
>
> } else {
>
> zoom = 1.10;
>
> }
>
> document.getElementById("canvas").style.zoom = zoom;
>
>
>
>
>
> 4) Set viewport in your HTML pages
>
> Since emergence of smartphone and thanks to the first iPhone, smartphones
> automatic zoom pages to ensure that it could fit into a small screen. This
> feature is great when you want to display a HTML page adapted to a PC
> screen but it's not at all practical when you write a responsive design
> interface where you try to adapt yourself the content to the screen size.
>
>
>
> A specific tag on your HTML allow you to tell to the mobile browser that
> you don't want an automatic zoom. It's:
>
>
>
> <meta name="viewport" content="user-scalable=no, initial-scale=1,
> maximum-scale=1, minimum-scale=1, width=device-width,
> height=device-height"/>
>
>
>
> Shortly it means to use device width and height and to ignore zoom. Always
> think to include this tag in your HTML header. More on the viewport tag
> here [3]
>
>
>
> 5) Take care to DPI
>
> Managing screen width and height is not sufficient. Rendering on
> smartphone and tablet screens depend of pixel density or DPI (i.e. Dot Per
> Inch). The more the density is the more it impact the real width and height
> size. Recent smartphones and tablets use high DPI as a marketing argument
> to sell devices (think to "Retina"). Shortly, on high density screens 1
> pixel width could be represented by 2 (or more) real pixels width. So of
> course, testing on a PC screen (where 1 pixel = 1 pixel) will not give the
> same result than on the real device. Only testing on real device with
> different DPI size will guaranty that your activity will fit correctly.
>
> A good explanation of DPI could be read here [4].
>
>
>
>
>
> Hope that all these explanations will help you to write adaptive
> activities.
>
> Do not hesitate to have a look on activities include into Sugarizer to a
> better understanding of how responsive design work. Do not hesitate too to
> ask me for help.
>
>
>
> Best regards from France.
>
>
>
>                  Lionel.
>
>
>
>
>
> [1]
> http://brandongaille.com/10-most-common-screen-resolution-statistics-and-trends/
>
> [2] https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_View
>
> [3] https://developer.mozilla.org/docs/Mozilla/Mobile/Balise_meta_viewport
>
> [4] http://developer.android.com/guide/practices/screens_support.html
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Gonzalo Odiard

SugarLabs - Software for children learning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20141024/9a18aaa1/attachment-0001.html>