MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: When I started work at Google, I visited the Google Earth team, hoping to find a 20% project on my favorite Google product. There I met Bruno Bowden, who introduced me to a problem I had never thought much about: how to take browser sizes into account when designing a page.

Bruno had noticed that many people who visit the “Download Google Earth” page never actually download, even though, as you can see, the button is pretty hard to miss:



He wondered if a significant number of users might have their browser windows too small to see the button:



To analyze this, Bruno looked at how large people's browser windows were when they visited this page. His first key idea was to measure not the entire browser window, but just the client area -- no toolbars, status bars, or other chrome.

Bruno's second key idea was to render several weeks' worth of page visitor browser sizes in a contour visualization:



Using this visualization, Bruno confirmed that about 10% of users couldn't see the download button without scrolling, and thus never noticed it. 10% may not sound like a lot, but in this context it turns out to mean a significant number of people weren't downloading Google Earth. Using this data, the team was able to redesign the page to good effect.

Bruno and I realized that Web designers might benefit from this information if it could be made more generally available. We constructed a page that could overlay a DIV containing the contour visualization atop an IFRAME containing any other Web page:



This turned out to be a good way to see which controls were and weren't visible at typical browser sizes. The only problem was, the overlay DIV prevented mouse events from getting to the page IFRAME, so it wasn't possible to interact with the page.

To solve this, we split the overlay DIV into four:



Each of the outlines above (red, yellow, blue, green) represents a separate DIV. As the mouse pointer moves, we resize and reposition the DIVs to leave a small window of blank space around the pointer, and adjust background offsets for each DIV to make the overlay look like one seamless graphic. (We originally did this on a timer, but we found a simpler way: when the mouse touches any of the DIVs, resize/reposition all of the DIVs.) End result: a designer can click and otherwise interact with the page with the mouse, and thus interact with the site normally instead of repeatedly typing in URLs.

We are now making this tool available to the public on Google Labs. To try it, simply visit browsersize.googlelabs.com and enter the URL of a page you'd like to examine. The size overlay you see is using latest data from visitors to google.com, so this should give you a pretty good indication of what parts of your UI are generally visible and what aren't.

We look forward to receiving your comments at browser-size-external-feedback!

By Arthur Blume on behalf of the Google Browser Size team2013, By: Seo Master

Seo Master present to you: Update: Thanks for all the interest and feedback on 20 Things I Learned about Browsers and the Web! We hope to open-source the code in the coming months and will post an update when we do. Stay tuned.

Twenty years ago this month, Tim Berners-Lee published his proposal for the World Wide Web. Since then, web browsers and web programming languages have come a long way. A few of us on the Chrome team decided to write an online guide for everyday users who are curious about the basics of how browsers and the web work, and how their evolution has changed the way we work and play online. Called "20 Things I Learned about Browsers and the Web," this online guidebook is illustrated by Christoph Niemann, and built in HTML5, JavaScript and CSS3, with our friends at Fi.

In building an online book app, HTML5, JavaScript and CSS3 gave us the ability to bring to life features that hearken back to what we love about books with the best aspects of the open web: the app works everywhere, and on any device with a modern browser. Here are a few features of the book experience that we’re particularly excited about:

• After the app has been visited once, you can also take the experience with you offline, thanks to the Application Cache API.
• You can resume reading where you had left off as the book remembers your progress using the Local Storage API. We also mark the chapters that have previously been read by folding the top right corner of the page in the navigation.
• The app utilizes the History API to provide a clutter-free URL structure that can be indexed by search engines.
• The HTML5 canvas element is used to enhance the experience with transitions between the hard cover and soft pages of the book. The page flips, including all shadows and highlights, are generated procedurally through JavaScript and drawn on canvas.
• The canvas element is also used to animate some of the illustrations in the book.
• CSS3 features such as web fonts, animations, gradients and shadows are used to enhance the visual appeal of the app.

This illustrated guidebook is best experienced in Chrome or any up-to-date, HTML5-compliant modern browser. We hope you enjoy the read as much as we did creating it, at www.20thingsilearned.com or goo.gl/20things.

By Min Li Chan, Google Chrome Team2013, By: Seo Master

Seo Master present to you: Last week I was privileged to host PPK (Peter-Paul Koch) for a Google tech talk entitled "The Open Web Goes Mobile". Most developers building web apps have benefited from PPK's browser compatibility research hosted on his well known site quirksmode.org. Now, fortunately, PPK is turning his attention to the world of mobile web devices. To no one's surprise, browser compatibility on mobile devices is even worse than it is on the desktop. Or as PPK puts it on his opening slide "Hell is other browsers". Check out his slides or watch the video here.



PPK starts by identifying the four main problems with getting web sites to work well on mobile clients: small memory, small display, flaky browsers, and flaky connections. Memory is an area for more research, especially benchmarking. PPK offers some suggestions for dealing with a small display, including using media queries in CSS (@media all and (max-width: 300px) {}) and offsetWidth in JavaScript.

Mobile browsers themselves are flaky when it comes to advanced CSS and JavaScript. But PPK finds that even basic stuff, such as font-style: italic, has to be verified. As a result of his testing, PPK categorizes mobile browsers into three levels of compatibility:

• top level: Android WebKit, Safari, Opera Mobile
• mid level: S60 WebKit, Blackberry, Opera Mini
• bottom level: NetFront, IE Mobile

Obviously, this is not an exhaustive list of mobile clients. PPK also mentions OpenWeb, Nokia S40, Palm Blazer, Iris, Bolt, Skyfire, Obigo, Fennec, and Teashark. This is the challenge in developing for the mobile web - there are a large number of clients and they exhibit diverse compatibility behavior.

When it comes to flaky connections, PPK points out that your connection speed is affected by the activity of the people around you. It's unlikely that this is going to change any time soon, so it's important to reduce the size of your downloads as much as possible. The problem is that caching on mobile devices isn't always reliable.

The impact of flaky connections can be mitigated by saving your core files on the mobile device. W3C Widgets offers a solution for achieving this. They're local applications written in HTML, CSS, and JavaScript that run inside the mobile browser. Ajax is used to download what's required: data. An advantage of using W3C Widgets is that, if the specification gets wide adoption, widgets will run across multiple mobile devices, and companies won't have to build a custom application for each target device. Right now, W3C Widgets work in Vodafone and Nokia S60 phones and Opera/T-Mobile phones for Windows Mobile, so evangelism to other mobile devices is needed. But the possibility of sharing applications across phones is compelling, for both the user experience as well as reduced development costs for mobile app developers.

By Steve Souders, Performance Evangelist2013, By: Seo Master