I am trying to understand what makes the mobile world tick and how 2012 will pan out, from reading blogs, twitter and various resources out there. I felt that I would share my views on how I use apps and accessing website from my mobile.

I take on board the buzz around “apps” and creating an “app” and brands putting money and time into the development of these beautiful creations, but what should feel like ground breaking move into mobile and online for some brands does not have the desired marketing effect on me at the moment.

I take the view that when I am not on my mobile and I Pad they are mostly in the hands of my 7 and 4 year old boys and are the only times during a day that they are not constantly demanding things from me. To keep the peace I will download and use an app to entertain them and as long as it does not cost me any more than 69 pence then it’s a small but functional price to pay.

I have monitored over the past couple of weeks my habits when shopping, checking Facebook, finding insurance quotes, using Google etc.. And it is all done via url’s and 100% visiting and revisiting websites through my mobile or IPad. Websites (mobile optimised ones are preferable) are the key to me getting to what I want and quickly it’s that URL although some would say old fashioned but to me the content is perceived as being up to date, giving me the chance to experience and interact with the site.

If friends are recommending voucher codes , makeup, shoes, latest gossip on Facebook they don’t ever send an app link on email or text they send over the URL to take me to the place where I can most importantly buy or get the items/ info from. If I have to spend time downloading an app, reading and then worrying about it working on my mobile, by the time I have considered all these parts it’s too late and my life has moved on.

The route to market and how you want to connect with consumers is varied, I expect that when we purchase my sons first mobiles they might disagree with me on a couple of the above points but at least I won’t have to Google what it all means as I do for most topics for their homework as by then I should know.

for more information : www.bemoko.com

bemoko is the leading Multi Channel  Optimisation specialist, delivering Your Brand-Anywhere™

bemoko’s Multi Channel Optimisation Solution takes any website or content, optimises, customises and delivers fast and perfect user experiences on any device – every time.

Ah yes, the tired old Moore’s law thing. I’ve been guilty of worrying about that in the past, ever since I was at Volantis. I’ve always overestimated when it’s going to happen, but I think his timelines are a bit off. I’d say we’re probably 2 years off massive penetration of smartphones, based on the normal 18 month refresh cycle for mobile phone contracts. Some people; e.g. app.ft.com are happy to exclude a large percentage of the possible market. That judgement won’t suit all.

Anecdotally, I would say that mobile web developers are better positioned than desktop web developers, since we’ve got lots of experience about optimising (markup / payload / UX) which desktop people will get, but they need to learn it. That’s based on my experience of talking to other developers at conferences. So I would say that mobile developers are better positioned to deliver mobile and desktop sites, than desktop developers to do the same. The desktop web has got fat [1],and that doesn’t work well on mobile.

And so you have to worry about networks. 4G is still a nascent thing and poor 2G reception is still very common. Knowing how to use the mobile network again is something that mobile people are aware of. There is vast body of (mostly undocumented) knowledge here, in which we do stuff which is common sense to us, then someone else writes a blog and a book about it and gets mildly famous as a result.

Providing intelligent solutions for the web – on the desktop, you’re likely to want to browse and shop, whereas on mobile, you’re more likely to want to get to the store locator, etc.

I do see the distinction between mobile web and PC web being dropped over time, but contextual intent will remain a strong differentiator between good and bad web experiences, on mobile versus desktop.

As to having mobile only platforms; yes, I see them going away. Multichannel is going to become more common, and I would expect Apache to incubate something along these lines soon, if they aren’t already

What is it?

Responsive web design is the approach taken to ensure that the website layout adapts to the browsers viewport (the dimensions of the browser window in which the website is displayed, not including the scroll bars and address bars etc).

How is it done?

Responsive Web Design is traditionally made possible through the use of CSS Media Queries, JavaScript can then take this one step further, and can be used to modify the DOM (the structure of the markup)

CSS

These allow for a set of CSS styles to be applied when the browser is in a certain condition.
Typical queries are:

• Width & Height@media screen and (min-width: 400px) and (max-width: 700px) { … }
• Orientation@media all and (orientation:portrait) { … }
@media all and (orientation:landscape) { … }
• Aspect Ratio@media screen and (device-aspect-ratio: 16/9) { … }

Javascript

Using javascript it is possible to detect if the browsers screen has changed size by listening for the onresize() event.

When a screen change has been detected, you can make the required DOM modifications to adjust the layout of your content to the new browser viewport dimensions.

Problems with this approach

Responsive Web Design works best when used in small edge case scenarios, as it able to deliver rapid layout changes, without the backend heavy-weight that is device knowledge. However, when delivering sites outside of these edge-case scenarios, Responsive Web Design may not be the best approach. Particularly when targeting a wide range of devices and browsers. When using Responsive Design with the traditional methods of CSS and Javascript for this, a few problems are introduced:

Page Weight

With media queries, there is much redundant styling that will never get used by the device under any circumstance. All this redundancy dramatically increases the page weight, which in turn slows the browsing experience of your site down.

CSS

While CSS media queries are fast to adapt content upon viewport changes, the actual .css files are fairly hefty as all styling for all eventual layouts are included in the page. So you are potentially increasing the size of your style sheets by a multiple of the number of layouts you are targeting.

JavaScript

Depending on the size of your size, and the amount of DOM manipulation needed, your JavaScript files could also run the same issue as CSS.

Images

CSS can hide/display/resize images, but this does not help with the actual download of the image. If an image has display:none it has still been downloaded by the browser in its original format.

Unexpected onresize() events

When using onResize(), pay caution to the many unexpected events cause the event to trigger. These are the events known to trigger this event:

• User resizes browser window by dragging the corner or edge.
• Users enters fullscreen or window view of browser.
• The orientation of the device switches from landscape to portrait or vice-versa.
• Modification to the DOM which causes the scroll bar to appear within the browser, in effect reducing the viewport.
• When the users scrolls down the page, and the address bar is hidden, this increases the size of the viewport and hence fires this event.
• User changes the zoom level
• The viewport meta changes

Clunky Reloads

A technique that some sites have incorporated is to refresh the page upon a change in viewport. This will reset the users page view progress, and potentially also lose input field information as the page is in effect reloaded.
On smart phones, users tend to browse the site in ‘Portrait’ mode, but when they are then asked to input details in a complex form, they prefer the keyboard display in ‘Landscape’ mode.

Unexpected User Experience

As a user is browsing the site in a ‘Portrait’ mode, and they then switch to a ‘Landscape’ mode, the layout that the user should now see should not be dramatically different. Any adjustments to the navigation may throw the user off, as they will need to readjust their ability to use the site.

Hard to maintain and improve

Having multiple stylesheets for all the possible viewport groups that you wish to support which modify the layout of each, as well as handling the JavaScript interactions and DOM manipulations, can become hard to maintain. Especially when a new feature needs to be imposed on the site that requires specific JavaScript function or CSS styles, ensuring that it does not break on other devices remains a challenge.

Solutions

Many solutions can be derived through client-side javascript that will “pull” content from the server, and manipulate it to display the desired layout. Although possible, this approach has its inherent problems. These mainly boil down to:-

1. Latency
   The time it takes to pull content via javascript over the mobile network. For example updating images from a 240px initial load, to 980px will result in an increased page load.
2. Re-rendering
   The user may see the “lowest denominator” version of the site while content is being pulled and manipulated by the browser, resulting in a “Clunky Reload”.
3. Slow UX
   Javascript intensive pages will slow down the browsing experience, causing lags in scrolling and animations and other navigation elements.

A more practical approach to Responsive Web Design is to integrate the discovery services of device recognition, the processing power of server-side markup manipulation and image delivery, and the final tweaking using CSS media queries and JavaScript.

Using these combination methods, here are some suggestions for Responsive Design Practice to help reduce the known issues identified earlier:

Targeted Responsive Design

Using intelligent capability discovery will, through tools such as device databases, will allow developers to deliver content that is known to be supported by the requesting device, such as:

• Only deliver responsive style sheets to devices that support it.
• Only deliver stylings that will actually get used by that device (i.e. do not deliver a media query of width > 800px if that device can never achieve that width)
• Only deliver JavaScript to devices that can handle it well.
• Only deliver optimized images for that device.

Scale Up

If relying on responsive design, make sure that your page “scales up” to the highest denominator, instead of “scaling down” a PC based site to fit on a mobile.

This not only reduces page weight, but also ensures that the devices that can support the intensive DOM manipulation and enhanced CSS styling, will be using their full capabilities to do so.

Ajax Reload of Selective Content

Instead of reloading the entire window, use AJAX to reload sections of content that are effected by the new viewport. This technique will keep the page weight to a minimum, as content is only loaded when needed.
A great example of this would be to just reload the images when a browser orientation changes from ‘Landscape’ to ‘Portrait’.

Adaptive Personalisation

Users should always be given the option to view you site in Full mode. Some users prefer to pinch and zoom their way around a regular designed for pc website, as they feel that the content is more complete or that they are more comfortable with that navigation technique.

Allowing the user to toggle between the Full site and the responsive site will give that user the freedom. Once their selection has been made, their preference should be saved, and so on subsequent visits, the user will have their preferred view.

Use an onresize() Margin of Error

When using Javascript to adapt the layout of a device based on the onresize() javascript event, build in an margin of error to allow for accidental give and take. A margin of error of 15% should ensure that no DOM modifications are taken when the browser makes slight adjustments to the viewport as described above causing an overuse of DOM manipulation slowing the browsing experience down. Better still, only adapt when the onresize() will cross the threshold between viewport layouts that you have designed.

Benefits

Integrating a server-sided approach with client-sided responsive design has many benefits over choosing one over the other.

No Compromise

When developing a responsive site, you are taking a conscious decision to exclude devices that are unable to handle CSS media queries, javascript, or even heavy pages. Alternatively, development could follow the approach to design for the lowest common device, and so more advanced devices are suffering from lack of inclusion, rendering their technological abilities void.

Server Side Platforms

Integrating with a server-sided platform, these devices can still be treated equally, providing access to the same content through alternative means of navigation, layouts and styling.

Only delivering markup to devices that support it, and also delivering only relevant markup, not only reduces page size, but also reduces the risk of browser hangs and crashes. On mobile devices, it is common for websites with large amounts of Javascript and CSS to cause the browser to crash as the complex queries are too much for the browser rendering engine.

Easier to maintain and enhance

Using Bemoko’s hierarchy approach, breaking down your styles and JavaScript into your defined UI groups will make it much easier to know where changes need to be made, and what will be effected when that change has been made.

During testing, specific devices may throw up rendering abnormalities, and implementing work-arounds for these can be done effectively by targeting the specific device. With responsive design, the ‘work-arounds’ are all included in the CSS or JavaScript which gets delivered to all handsets, not just the devices that require it.

As the capabilities of devices improve, and new technologies become available, dropping these into specific UI Groups will instantly enhance the site. These groups can be targeted to ensure that these will work, and will not break existing functionality on older unsupported devices.

Faster page loads

Page weight is comprised of markup, CSS, JavaScript, and images. Therefor it is evident that reducing page weight will increase page load speeds, the most important factor in mobile web development. Consumers losing patience with the slow mobile web and How Loading Time Affects Your Bottom Line do an excellent job on describing how important page loading times are, and how it can effect business.

Conclusion

Standalone, Client-Side Responsive Web Design works best when the site is targeted to a particular browser or device class. For example, if you only want to support iPhone and Android devices, manipulation of layout via media queries and JavaScript will be a sufficient approach. However, when you wish to develop a site that will work across almost any browser (PC, Tablet, Smartphone, Feature phone, etc) a combination of both intelligent server-sided adaptation and client sided responsive tweaking will be best suited to the task.

So what is the best way to handle this support when developing for mobile browsers?

bemokoLive ui groupings make this easy.  We can define a uigroup in the site-config.xml file for devices that do not support the HTML5 Audio tag:


<!-- iOS 4.x+, Android 2.3+ or PC but not IE 6, 7 or 8 -->
<ui name="html5.audio" expr="(device.vendor == 'Apple' and device.version ge '4.0')
or (device.os == 'Android' and device.version ge '2.3')
or (!device.isMobile and !(device.vendor=='internet explorer'))
or (device.name.contains('xxxblackberry9800xxx'))" />


This ui expression categorizes devices which match as supporting HTML5 Audio.

In the root ui (for basic devices) – we default to not supporting HTML5 Audio and deliver a download option instead:

play.html from the root ui group:


<div><a href="${controller.audioUrl}"><img src="/images/download.png" alt="Download" /></a></div>


We can redefine play.html in the html5.audio uigroup as


<audio><source src="${controller.audioUrl}" type="audio/x-wav"/></audio>


bemokoLive will pick the relevant file for the device accessing the site at run time.

This simple ui grouping and one line file allows us to support all devices, whether they support HTML5 audio or not.

See more on how bemokoLive can speed up multi-channel web development here.

There are a number of ways of achieving this, one is to store all the relevant sizes of an image for later use, another is to store one version of an image and automatically resize it as needed.

Certain images, such as logo’s and images with text on them do not readily lend themselves to being resized as the text can become stretched, so the best option for these is to store custom built images for different size devices.  As these images do not tend to change frequently, the overhead of storing the separate images is not prohibitive.

For product images and other frequently changing media, storing multiple different versions of the image becomes a headache.

bemokoLive allows you to resize images on the fly and looks after caching of those resized images for future use.  The Image Transcoding addon used to be accessed via a Freemarker macro which was OK – but the developers have made it even easier in the latest version of the framework.

Image transcoding is now available as an HTML5 custom data attribute on the <img> tag itself, so transcoding an image in a page is now very simple.

As an example, if I have an image

http://blog.bemoko.com/wp-content/uploads/2009/09/radio.jpg

And want this image to be displayed 100px wide, I can do the following:

<img src="http://blog.bemoko.com/wp-content/uploads/2009/09/radio.jpg" data-rule="100.jpeg" alt="radio"/>

The data-rule attribute allows me to control the size of the image, so I can scale or crop to any size.  If I wanted the image to be 100x200px in size, I would say:

<img src="http://blog.bemoko.com/wp-content/uploads/2009/09/radio.jpg" data-rule="100x200.jpeg" alt="radio"/>

The tag can also be set as a variable, giving the ability to access device attributes, so I could say:

<img src="http://blog.bemoko.com/wp-content/uploads/2009/09/radio.jpg" data-rule="${device.displayWidth / 2}.jpeg"
 alt="radio"/>

To give me an image half the width of the current device.

To see an example of these tags in action, visit the image transcoder demo page.

For more details on the rules available see the documentation

If you are like me, you probably do silly things over and over again, get the same silly result each time but fail to rectify the situation, and so, your perpetuating scenario (whatever it is for you) keeps, perpetuating!

For me it’s the joy of finding a would-be clean and favourite pair of socks in the draw, unravelling them from their neat ball, only to find that one of them has, you guessed it; a hole in the heel! Do I put them in the bin? Not on your life, I roll them up and put them back in the draw! Why? I hear you ask – I can’t really tell you, but boy is it annoying!

Another question you are probably asking right now is: what the hell has a holey sock got to with e-mail marketing? If you are involved in any way with marketing and sending direct mail, and more specifically e-mail, then I have a question for you – if you know that at least 25% of the e-mail you send is opened on mobile phones, why can’t you send out mailers that are readable on mobile phones?

I guess there are only so many reasons, but the net result is that one out of every four e-mail mailers you send out will be opened on a mobile and simply deleted – but like the hole in the sock syndrome, you can’t seem to stop it!

The definition of madness is apparently doing the same thing over and over again, expecting a different result – I would say that there is something of more madness! And that’s paying for the same thing over and over, which under delivers by at least one quarter and not do anything about it! And madder still is the fact that mobile provides a stack of extra opportunities to get your campaigns more targeted, update databases with more information about the recipient and engage customers on a one-to-one basis and not tap into this power!

I’m not an e-mail marketing specialist, but I know that I get deluged with marketing e-mails – if the companies that sent them sent 75% fewer e-mails but made the perfectly optimised for every type of mobile device, two amazing things would happen: 99% of their e-mails would get read, and all of us would be freed from the curse of a spammed inbox.

Unlike my “hole in the sock”  I’m guessing that the reason for un-mobile optimised e-mail campaigns is not in fact madness but education – the technology is here to achieve amazing results with fully optimised HTML content rich mobile email. Demand it from your e-mail or marketing company and don’t be fobbed off with excuses that “it’s not possible”

Enjoy…

The next webinar is scheduled for 10am UK time on the 12th April.  Why not sign up and take advantage of more of Phillips words of wisdom….

The slides from the most recent webinar are below – enjoy!

Webinar – Mobile, choosing the correct channel

As part of the package, along with a shiny brief-case that opened up – James Bond style – into a rather snazzy presenter that aided the complex explanation of a seven cell repeat pattern followed by the “FAB’s” of mobile communications (that’s features advantages and benefits, for those of you that didn’t attend the rather corny 1980’s school of selling delivered by an ex-double glazing salesman sporting a pale grey suite and pink socks) were the keys to a Ford Sierra complete with a hanger in the back for my new Moss Bros suit jacket and, screwed rather unceremoniously to the dashboard was my mobile phone! I’d arrived!

But it got better, much better!  When I wasn’t in the car driving in the ‘fast lane’ of the M4 to Newbury (actually it was the middle lane, so that people passing me in the outside lane could see that I was on the phone) I could ‘do lunch’ and in the evenings I would frequent a highly popular wine-bar in Guildford where I could rub shoulders with other shoulder padded jacket wearing, slick backed haired “dealers”. Only I went one better.  I would park the Sierra somewhere obvious, remove the handset of my car phone from its utilitarian (Russian tank utilitarian) dash board clamp and go to the boot where I would unscrew, unclip, disconnect, slide, pull and twist a metal box from another utilitarian clamp, connect this to the handset that I had removed earlier and then attach a leatherette carry strap – I was now in “Transportable mode”!  It is now inconceivable to imagine that when this piece of hi-tech, high fashion equipment was on the bar next to me I was “It”!

The reason however, for having this amazing piece of equipment, was not as I believed to look cool, but was in fact to go out and convince other people that having a mobile phone was a good idea; it might save time, money or make them more efficient. (These are FAB’s!)  In fact we had to make up loads of FAB’s in order to try and get people to part with money for what at this time was a gimmick!  I can remember sitting in people’s offices, wearing my shiny suite, using, with great style and panache my shiny briefcase, flip chart extoling the virtues of owning a mobile phone; and the biggest objection I would get… “Why do I want a mobile phone when I’ve got a phone on my desk?” 

Back in the day, I knew mobile would be big, I knew that in time it would catch on and when Racal, the small telecoms company that I worked for eventually spun out a mobile company called Vodafone and  celebrated it’s twenty thousandth connection,  we all knew that mobile was the place to carve out a career. What we had no way of predicting was the sheer  scale to which mobile would change the planet, and how it would alter our lives to an extent that now, mobile is so much an ingrained part of human existence, it is inconceivable to imagine life without it. 

The other day, while sitting in the office with a new client, by the way I have dropped the shiny suit and shoulder pads! I was reminded of my early days selling mobile phones, when a remark was made about PC’s “why will people want a PC on their desk” my client hypothesised “when they can do everything on a mobile” and that got me thinking; during those very early days of mobile, none of us were able to predict the extent that it would change our lives  nor were any of us  able to truly imagine the size, success  and impact that the internet would have, what then happens when you converge these two, I would like to say technologies but these are more than simply technologies now, they are two of the bedrocks of human life. 

Can we use the history of the growth of mobile and the Internet as a measure what will be, or will something far bigger, far more monumental happen?

Whatever happens, I think it’s pretty safe to say that mobile web is going to be huge, which just for the record, I have been saying for about three years and just like my early days in mobile when people genuinely looked at me and said that mobile would never catch on, until very recently most people I spoke to about mobile web said exactly the same thing, thankfully this sentiment has changed in recent months and now everyone’s talking about it!

I love this; it hits the nail on the head! Perhaps I should not spend time writing blogs and just find some artistic talent and produce a piece of art to make a point…on second thoughts I could go to http://tomfishburne.com whose website and angle on marketing is great!