LinkedIn Facebook Twitter bemoko blog bemoko technical pages
Tel: +44 1256 581028 Email: info@bemoko.com

Bemoko blog > mcommerce

31

Jan

Responsive Design “delving deeper”

Posted By Emily Nicholls Thursday, January 31, 2013. No Comments

With so much interest in ‘Responsive Web Design’ in 2012, we have delved deeper to see if this is the right approach for Web Development moving forward. For many it offers a low cost approach to a write once web development. However, there are limitations and this article tries to explain these, and how the Responsive Web Design concept can be taken to a more dynamic and vastly improved user experience.

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 view port 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 full screen 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 view port.
• When the users scroll down the page, and the address bar is hidden, this increases the size of the view port and hence fires this event.
• User changes the zoom level
• The view port 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 style sheets 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 mark-up 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 styling 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 affected 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 mark-up to devices that support it, and also delivering only relevant mark-up, 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 affected when that change has been made.
Through a combination of our deep mobile expertise and unique technology capability we help our clients to become class leaders in mobile.

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 affect 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.

By Olaf Dunn @olafdunn on twitter

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: fundraising, mcommerce, mobile, mobile design, mobile search, mobile technology, mobile UX, mobile web, multichannel, responsive design, web optimisation

21

Nov

The Camera API – More than just your name in lights!

Posted By Emily Nicholls Wednesday, November 21, 2012. No Comments

New mobile technologies are nothing new! Javascript geolocation functionality has become common place in mobile websites over the past 3 years, allowing a mobile site to pinpoint user location.

Other breakthroughs include sensory device capabilities.

“Accelerometers in mobile phones are used to detect the orientation of the phone. The gyroscope, or gyro for short, adds an additional dimension to the information supplied by the accelerometer by tracking rotation or twist.” – GSM Arena glossary (sensors)

Such sensors, inter alia, permit the user to control the device in new ‘never before imagined’ ways.

Probably the newest kid on the block, however, is the Camera API. This API gives the user the ability to take an image from their device’s camera and upload it to a mobile site. The possibilities are endless. For example, the uploaded picture could be used as the user’s avatar. A mobile site could facilitate the sharing of the image on social networks. But, being at mobile’s bleeding edge, we refuse to halt our imaginations there.

The most exciting innovations in mobile have always come through the collaboration of new mobile technologies with pre-existing services. For example, geolocation when coupled with readily available public APIs permitted not just location detection but location information. The user is now advised that Acme Plc’s nearest store is situated 5 miles away and is presented with a map detailing user and store location information plus driving directions.

And so it shall be with the Camera API. It’s most exciting uses shall emerge through innovation. What would happen if we coupled the camera API with the HTML5 canvas’ 3D rendering capabilities? One could imagine a spinning 3D bauble with the user’s face painted on it and light reflecting therefrom.

A festive treat for any web user. Or let’s twin the camera API with Google Maps, geolocation and a social network. We can now plot the user’s friends on a Google Map, detailing not just their current locations but using their latest uploaded photos as map pins.

The possibilities are endless.

Of course, the bemoko platform not only supports such functionality but seeks to enhance it. The bemoko platform, for instance, is readily used to dynamically transcode images received from the camera, making the photo web-ready for the accessing device both in terms of file size and image size.

Other issues remain. For example, the orientation of the image has proved a challenge, the device having no knowledge of which way up is the right way up.

bemoko, however, being experienced market leaders have everything needed to respond to such emerging concerns. The first ingredient is awareness – know your enemy – and the second item for the pot being the expertise to confidently tackle such issues. Yet more reasons why the bemoko choice is the right choice.

By Dan Lewis- Senior Developer

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: iphone, java, mcommerce, mobile, mobile design, mobile search, mobile technology, mobile UX, mobile web

1

Oct

Where are you in the digital evolution of your business?

Posted By Emily Nicholls Monday, October 1, 2012. No Comments

I was at a mobile conference last week (yes another one!) and the speaker… a “leader” in mobile (yes another one!) asked the audience if anyone 5 years ago thought that mobile would be as big as it is today.

I was the only one in the audience to put up my hand. “really?” the speaker boomed over the microphone! Looking particularly annoyed as I had seemed to have completely ruined his presentation…”how can you justify that?” “well” I replied. “In 2007 I along with three other like minded mobile experts put a little over £1m of our own money into building a mobile platform that would deliver mobile web and cloud based apps to any and all mobile devices regardless of OS, screen size and network”

My point here is that if you are still evaluating if mobile is a good idea for your business then it might already be too late for you! The debate has moved on I’m afraid, it’s now not whether to do it but how to do it well – those that are doing mobile are using old techniques adopted from creative agencies still stuck in the dark ages of PC web and are gradually feeling the pain of cost, complexity and poorly performing mobile sites.

 

blog Where are you in the digital evolution of your business?

I think

There is a repreave for anyone without a mobile site…skip the “early adopter” poor attempts and move straight into dynamic delivery using tools and software designed for mobile, this might just speed you through the process and might even leapfrog you past your competition.

Please feel free to share or comment

by Phillip Clement

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: iphone, mcommerce, mobile, mobile design, mobile UX, mobile web, multichannel, web optimisation

18

Sep

4 Easy Steps To Mobile Web Payments

Posted By Ian Homer Tuesday, September 18, 2012. No Comments

Mobile has always thrived for applications where immediacy is paramount and retailers should not fall short of allowing the customer to complete their transaction whenever and wherever the customer may be. Waiting until the user is back at their PC may push your customer to connect with one of your competitors. Taking payments is not difficult, so let’s take a look at how you can take payment on your mobile web site and complete the customer’s journey.

Payment options at your disposal include:

  • Online wallets
  • Credit card – similar to what you might expect on a PC site
  • Direct operator billing – payment taken of the customers bill
  • Premium SMS (a.k.a PSMS) – SMS sent to customer that gets

Various on-line payment service providers, such as Bango, CellPoint Mobile, Braintree and PayPal provide hosted solutions that allow you to get up and running quickly for these different payment options. Note that service providers may not give you all of the 4 payment options above.

These hosted solutions work by taking the user to a payment page provided by the payment service provider so that payment can be taken. A typical flow for this is :-

  1. The user makes the product choices on your web site filling up their basket
  2. When the user is ready to purchase the products the user is directed the payment service provider page. This is typically by an HTML form that takes the user off your site, although you should be able to customise this page so that it looks like your brand.  If you decide to take payment details on your site rather than redirecting, be sure you understand the PCI compliance rules that govern storing credit card data.
  3. When the payment has been confirmed a back-end callback can be made to your web site to confirm the purchase is OK and the user is taken to a thanks page on your side. The callback is necessary to reduce chances of unscrupulous users fooling your site into thinking that the payment has been received.
  4. Your site delivers a thank you page AND sends out email or SMS confirmation to the user that the order is on its way.
  5. Note that the callback may occur in a couple of stages 1) payment has been authorised – i.e. funds reserved and 2) payment captured – i.e. funds transferred to your account. So do be ready to handle either of these signals – if you’re dealing time sensitive products, e.g. take away delivery, then you’ll want to put the order in motion as soon as the payment as been authorised. Otherwise you may want to hold off on putting the order in motion until you’ve had confirmation that the payment has been captured.

Note that Braintree has a nice variation on this where you can handle this payment integration with a javascript client library.

Do compare the commission that each of the service providers takes on each payment as this can vary significantly from one provider to another and from one payment option to another (e.g. credit card vs PSMS).

When it comes to 3D secure, the user experience has not yet been optimised for mobile, although it does work. If you choose to disable it then you may improve the user experience, but you will be taking the risk that payment is fraudulent since 3D secure does give you extra security for your payment.

As always – monitor your site. When you start taking payments, ensure that you monitor how much your site takes every hour and send out alerts if orders drop off during an hour.  This can be an early warning signal that something is misfiring.  If you are using a platform to deliver your site, such as bemokoLive, then these alerts and the monitoring come built in, making it much easier to ensure that every order gets fulfilled.

If you want to talk to us about how to start taking payments on your mobile web site and take use of some of our existing payment integrations modules then please get in touch, feel free to share or comment on this blog

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: business, iphone, java, mcommerce, mobile, mobile design, mobile search, mobile technology, mobile UX, mobile web, multichannel, public website news, responsive design, smartphone, social, tablet, transactional, web optimisation