dotMobimobiThinkingmobiForgemobiReadyDeviceAtlasgoMobi
  • Best Practices - Posted by Veruska Anconitano on 17 Apr 2013
  • The most common mistakes in smartphone sites according to Google
  • Google are paying ever more attention to the mobile market and so, developers pay attention when the Big G is making recommendations. Google recently published a document on the main mistakes people make when working on mobile websites for smartphones. If you look through the list you can definitely recognize a cornerstone of Google's approach: focus on the end user. Or put another way, "adopt the approach you want but be aware of your audience".
  • Best Practices - Posted by ronan on 05 Apr 2013
  • Global reach and dynamic page weight – is there a correlation?
  • Many reports on web page sizes issued in recent years point to the same conclusion: the web has a weight problem. The web seems to be gaining weight each year despite the fact that study after study has shown a strongly negative reaction from users to heavy web pages and resulting loading times.
  • Best Practices - Posted by Veruska Anconitano on 21 Mar 2013
  • Why Responsive Web Design is not always the best option for a mobile SEO strategy
  • There are a lot of misconceptions about what Google is saying about mobile SEO. First and foremost, Google doesn't mandate the use of Responsive Web Design (RWD) as best practice for SEO. Google expressly says "Google does not favor any particular URL format as long as they are all accessible to both Googlebot and Googlebot-Mobile” the bots Google uses to crawl desktop and Smartphone specific content. And it’s worth noting here that Google is crawling desktop and mobile content separately.
  • Best Practices - Posted by ronan on 12 Mar 2013
  • Performance is money, part 1: the end-user's wallet
  • Most web developers are familiar with the maxim that light is good: the idea that page performance matters to the end user experience is a truism at this point, backed up by a tremendous amount of real-world evidence, summarised quite nicely at websiteoptimization.com.
  • Browsers - Posted by casaise on 06 Mar 2013
  • Developing custom pictograms for the mobile Web
  • A matter of trade-offs Pictograms – miniature graphical representations of states, actions and objects – made their way into the mobile Web over 15 years ago. Several normalized (UNICODE, WAP) and proprietary (Japanese emojis, Openwave) mechanisms are in place to enrich Web applications with pre-defined images.
  • Browsers - Posted by casaise on 06 Nov 2012
  • A Guide to Using Pictograms in Mobile Applications
  • A long-standing feature Developers inspecting the user agent profile of a modern handset like the Motorola XT682 ATRIX TV may be surprised to discover the following ImageCapable declaration which indicates whether a device can display images or not: <prf:ImageCapable>Yes</prf:ImageCapable>
  • Publishing - Posted by ronan on 01 Nov 2012
  • Introducing Prism, a tool for testing device adaptation
  • Due to the multifarious nature of the mobile web, developers tend to spend a lot of time testing their work. If your site is designed to adapt to multiple different devices this effort is multiplied because you need to ensure that your detection is working correctly across multiple devices and that your response is appropriate in each case.
  • Design Patterns - Posted by ronan on 11 Apr 2012
  • Anatomy of a mobile web experience: facebook.com
  • This is the second article in a series about how the major internet brands deliver their mobile web experience. The previous article is available here: Anatomy of a mobile web experience: google.com
  • Design Patterns - Posted by ronan on 28 Mar 2012
  • Anatomy of a mobile web experience: google.com
  • In a recent blog post that I did here on mobiForge (Server-side device detection used by 82% of Alexa top 100 sites) some people expressed surprise that a 47 byte difference in the HTML payload delivered by Google to different devices constituted a significant level of server-side adaptation. On checking my results, it turned out that this minor 47 byte file size difference actually masks an entirely different HTML document served to
Previous