With retina displays becoming more and more common both on desktops and mobile devices, supplying appropriately high-resolution imagery is an important consideration. Blindly providing high-resolution images, however, wastes bandwidth – a resource in short supply, especially with mobile devices.

New specifications allow websites to provide an array of images at different resolutions to the browser so that it can pick the best fit for its display density and bandwidth availability. Adding support for this ensures that cutting-edge devices (and their lucrative owners) enjoy the best possible experience, while not penalizing traditional devices and users with traditional display densities with increased bandwidth usage.

Native RWD theme support

By default, the native rwd/default theme makes a very modest attempt to supply high-resolution images on the product detail page and no attempt on product list pages.

Product list pages load a conservative image that never exceeds its max render size. Since there can be many images loaded on a single category page, loading a higher than necessary resolution image for every product would have resulted in significant bandwidth increase while only improving the experience for high-density displays.

Due to the importance of product imagery on the product detail page, however, the product detail image gallery intentionally loads a 1.5x image. Product detail images are usually reasonably few, so this approach doesn’t require excessive additional bandwidth. The extra .5x leaves a little extra resolution for lower density displays and meets higher-density display halfway, all without cluttering or complicating the often-customized product media template and javascript.

Adding support for high-resolution images

In order to provide native support for forward-thinking browsers while maintaining high-performance backward compatibility for older browsers, the Picturefill polyfill is an easy choice. This polyfill uses the standard DOM structure to express image choices so that native browser support can be used where available, and fills in the gaps where necessary.

This polyfill supports both standard markup patterns:

• img element with srcset and sizes
• picture element with source nodes

While the picture element provides incredible flexibility, a standard img with appropriate 1x and 2x srcset values goes a long way with minimal impact.

Adding picturefil polyfill

After downloading picturefill.js, move to the /js dir to make available to all themes. Then, add a few lines to your theme’s appropriate layout XML update file to include it on all pages.

Product List

Product list images are very simple. By default, they are a simple img element, duplicated on both sides of the grid/list conditional.

Images will never exceed 400px rendered size, so a reasonable and bandwidth-friendly 300px max was chosen.

While this is acceptable for low-density displays, the stingy resolution shows up on high-density displays.

Due to the effective use of a simple img element, this is a textbook example of the implementation of 1x/2x images. Lower density displays are already accounted for, so the 1x image remains the old 300px standard. Adding a value to srcset for high-density displays is as easy as another call the Magento image resize helper, asking for an image 600px in size.

This simple change results in significantly sharper images on high-density displays.

This usage can be directly replicated on the other side of the list/grid conditional.

Product detail

Product detail images are only slightly harder. Due to the Magento’s gallery functionality, the product media template has an img element for the base image, followed by each gallery image.

By default, images are loaded at no higher resolution than 1200px – roughly 1.5x the actual max render size.

Again, due to the use of a simple DOM structure containing simple img elements, the switch to responsive images is not rocket science. After experimentation, images are never rendered more than 700px x 700px. This gives the target for the baseline, lower density, 1x target size, with 2x images targeted at 1400px – twice the baseline size.

Finally, a zoom size must be selected. Elevate zoom, the zoom library used by default only supports a single zoom image per img element. In order to provide a sufficiently bigger image for all display densities, a size adequately bigger than the high-density image size (1400px) must be chosen. This decision depends on the original resolution of product images available.

With the main product detail media image out of the way, updating gallery image thumbnails is a breeze. Simply switch to srcset, request a doubled image size from Magento’s image helper for the 2x image, and move the image size into a variable, just for good measure.

Product image considerations

No good deed goes unpunished, and neither does responsive image implementation. In order to actually provide high-resolution images to high-density displays, the original uploaded product images must be the highest resolution available. In particular, they must be at least ~2000px x ~2000px – enough to satisfy the resolution demands of the product detail zoom image.

Where to go from here

This article only scratches the surface – the more flexible picture element support allows for a wide range of sophisticated image use such as

• providing images in different formats to take advantage of the latest standards
• art direction for product images at various render resolutions

The code for this walkthrough is available on GitHub and can easily be installed via modman – use it wisely.

This post was the first in Classy Llama’s technical blog series on RWD on Magento.

We experienced the development of RWD theme first hand and want to share our learnings with you. In the next few weeks you can look forward to learning about the topics listed below:

Compile Compass in PhpStorm, Netbeans, or Sublime with source map support– The new Magento responsive theme uses Compass to compile Sass into CSS. In this article, learn how to automatically compile your Sass files whenever they are changed in your favorite IDE.

Sass Deployment Structure– In this article, we’ll cover how Classy Llama incorporates Sass compilation into our development and deployment workflow.

Interested in a responsive image implementation on your website? Let us know at our contact page.

In late 2013, Classy Llama released our PayPal Credit Card Tokenization extension. The primary feature of this extension is to introduce a “saved credit card” option for merchants without the necessity of compliance with PCI DSS standards, by leveraging card data stored securely on PayPal instead of on a merchant’s site. Read more of the details in the original post.

When we first introduced it, the extension’s compatibility was limited; it supported only the latest version of Magento at the time. We promised that support for earlier versions of the platform would come eventually, and we’re happy to announce that the extension’s latest release implements compatibility back through Magento Community 1.5 and Enterprise 1.10 (as well as officially certifying compatibility with the latest versions of 1.8 and 1.13). Now a much broader segment of merchants has a great option for allowing their customers to save and reuse their credit card details!

Get the extension here: http://www.magentocommerce.com/magento-connect/paypal-credit-card-tokenization-extension.html. As ever, the best thing about the extension is that it’s free!

Magento is built to be an extensible multi-lingual, multicurrency, and multi-national platform. Its flexibility can create significant challenges for merchants and developers alike. This has led me to dig deep into the currency systems that are built into the pricing and sales portions of Magento.

At a basic level, native Magento currency options can be expressed as three possibilities. The first option is to simply have your base price set on every product using a single currency. This base price is the one that you set when you are setting the price value on a product at the default level.

The second option is to use Magento’s native currency conversion that operates at runtime on a per store basis. As a Magento merchant or developer, you have the option of allowing your customers to view prices in a different currency from the one in which they will be charged. This conversion is merely for evaluation purposes since the customer will still be charged in the base currency but they will at least get an idea of the approximate amount they will be charged after conversion. These conversion rates can be pulled from a conversion rate service or entered manually in the admin. If the rates are pulled from the external service, they can be set to automatically update daily. This type of conversion is often sufficient for merchants who do the majority of their business within one country and merely have the option of other currencies for those few countries that make up a minority of their sales.

For those who are targeting a larger percentage of sales in more than one country, Magento has a third option. A merchant can set a different currency at the website level from the one set at the default level. This allows the merchant to do everything from setting prices that are specifically formed to look good in that currency to charging the customer’s credit card in their native currency. This third option is the most time consuming and labor intensive of all of the currency options, but it also has the greatest potential benefit.

Using the Same Base Currency and Display Currency

Anyone who has worked extensively with prices in Magento knows that there are quite a few ways to modify those prices. Within native Magento Community Edition, you are required to set a price on a product at the default level. You also have the option to set a website specific price. Each of the following elements also has options to set pricing at default or web site levels, in addition to adding other more specific limitations upon who receives the price as implied by their names:

• special pricing
• customer group pricing
• tiered pricing
• catalog price rules
• shopping cart price rules

All of these will be combined, along with any other pricing modifications that might come into play, to form the product’s final price. This final price is the total price of the product itself and excludes things like shipping, tax, and certain discounts which are applied to the entire order.

Both the base price and the display (converted) price are stored on the cart and both are transferred to the order at checkout. When the only allowed display currency is also the base currency, the base price is always the same as the display price. Both of these prices are then used throughout the life of the order. The display price is primarily used for display to the customer, and in certain places in the admin, while the base price is used primarily for calculations.

Differences when using Currency Conversion

When Magento is set to use a conversion rate other than 1 (which produces no conversion) it converts the base price to the display price before performing any other calculations. All other calculations are then simultaneously performed, using identical operations, on both the base price and the converted display price to arrive at the final totals for each price.

It is important to understand that, depending on the situation, the final display price total may differ by a cent or more from the value that would be generated by taking the final base price total and converting it. How much the values differ depends on the number of line items included in the calculation – though it should never be more than a few cents.

When a customer places an order, they will be charged the calculated base price total converted, by the payment processor, into the customer’s currency. Since this is not the way that the display price total is calculated, the display price total will only give the customer a close approximation of what the charge will be in their currency. It will not be an exact representation of actual charges.

Impact of using Multiple Base Currencies

Using multiple base currencies may seem confusing at first and it does require that the person who imports products is thorough. Because of this, I recommend that you have a strategy in place for implementing products with multiple base currencies before publishing them to a live production environment.

To understand the importance of being thorough in a situation where you have multiple base currencies, consider a scenario where a US run company has a large customer base in Europe and the UK. The merchant has already imported their entire product set that is offered across all of their stores. This merchant opens their European and UK websites with Euros and GBP as the websites’ respective base currencies. The merchant also has general shopping cart price rules set up for all websites giving customers 10% off Product A when purchased with Product B and 5 off Product C when it is in a cart where the cart totals 100 or more.

Some interesting things happen when you create websites with different base currencies to include these products. When a customer browses to the new website, he/she will find that the price has the same numerical value on the two new websites as on the US website. The product that is $100 on the US website will be €100 and £100 respectively on the European and UK websites. This is obviously not accurate and will happen whether or not you have currency conversion rates set up.

If each website has a different base currency, each website should have a different base price to go along with that currency. This different base price could be set by either having a separate product that is exclusive to each website or by having a product in multiple websites with a different website level price for each website.

By extension, the shopping cart price rules which were originally made for a scenario involving only dollars should either be split into multiple shopping cart price rules, converted into percentage based rules, or accepted as different value rules on each website. Some of these rules may still be logically similar, for instance, the rule that gives $5 off Product C when it is in a cart where the order totals $100 would be valid although slightly more expensive rule when it was offering €5 off a €100 cart.

The most important thing to realize with using different base currencies is that you cannot simply assume that all of your configured prices and rules will work as expected, but instead, each area of the admin where a price is entered must be evaluated for consistency with the new multiple base price structure.

Alternatives

While Magento has a few ways to deal with currency conversion, it is important to consider the implications of each of the factors for your customers when they are paying in a currency that is not your Magento Installation’s default base currency. There are other possible pieces to this puzzle that can come into play if native Magento alone does not suit your needs.

One possible option is to use PayPal Express as the only or primary payment method on websites that default to a display price other than the base price they will be charged. PayPal will show the user what they will be charged in their currency according to its conversion rates. This can protect your users from potentially having to pay credit card surcharges when they pay in a non-local currency.

Another option is to use a third party or custom solution that uses multiple base currencies. Classy Llama has built a currency conversion automator which allows the merchant to have the increased functionality and usability that comes with using multiple base currencies with a lot of the convenience of using multiple display currencies. This extension allows the merchant to enter a default price for a product and 1 or more website level prices. It then uses a set of rules and order of priority to convert one of the manually set currencies to each of the other website’s prices using the conversion rates set in the admin. The extension then round the price to make prices look consistent across the entire site.

For example, a product with only a default price of $10.00 where the system used USD as its default base currency, would have its base price on the UK website that used GBP as its base currency calculated by taking $10.00 times the conversion rate from USD to GBP and rounded to the nearest pound. So assuming that the conversion rate was $1.85 to £1 the product would have a UK website level price of £19.00 which is the converted price of £18.50 rounded to the nearest pound.

This type of solution obviously has certain limitations. For instance, shopping cart price rules are unaffected by this extension and tiered prices and customer group specific pricing likely would have used their own native currency selection options, but it is an example of how a combination of the manual and yet more precise and flexible nature of using multiple base currencies could be combined with the simple and automated nature of display price currency conversion.

Conclusion

As merchants and developers consider how to handle multiple currencies, it is important to consider the implications of each currency option. The merchant may choose to ignore currency conversion altogether, use currency conversion with display prices, or introduce multiple base currencies and accept the extra overhead incurred. The effort involved in using multiple base currencies is likely only necessary or beneficial to merchants who do not do the majority of their business in a single currency or who have separate distinct web presences for countries whose native currency is different from that of the merchant.

The use of multiple currencies on a website should not be considered lightly but should be approached from a strategic perspective that will allow for long term maintenance of the solution while still providing sufficient functionality to the merchant and customer alike.

Amongst the leaders of eCommerce, it is widely known that mobile devices are increasingly comprising a very large segment of web traffic, one which cannot be ignored. The eCommerce Quarterly by Monetate reports that tablets and smartphones accounted for > 21% of all eCommerce traffic in the US during the first half of 2013, compared to only 2% two years ago. These users need an experience designed for them. Something which allows them to get what they want when they want it, and without having to deal with the hassles (and emotional trauma) of wading through a cluttered desktop-centric design on a screen the size of one’s palm. Enter mobile friendly web design!

There are two widely accepted means of appealing to mobile device users: responsive design and targeted design (i.e. the practice of having an independent desktop and mobile site). There are many advantages to using responsive design. It also has its cons…targeted designs do as well, like generally being more difficult to maintain feature parity.

Ok, so you need a mobile site, and quick. You don’t want to rebrand, rebuild, or risk upsetting your existing desktop-centric design. Or maybe it’s something you need to plan for in next year’s budgets — and you decide to go for building a mobile site which will serve your mobile customers better without changing anything on the existing desktop-focused design you have already.

Implementing a mobile site on Magento doesn’t have to be hard, and Magento includes one out-of-the-box, which is also available on Connect.

Turning this on for mobile devices is pretty simple. Just don’t forget that you do still need to change the stock orange to something fitting for your brand…unless you just love orange, then you can keep it! You can set this up in the Magento admin by navigating to System -> Configuration -> Design and setting a “Design Exception” — I.e. you tell Magento what theme you want to apply for browsers with a User Agent string matching a given RegEx pattern. One commonly used pattern is this one:

iPhone|iPod|BlackBerry|Palm|Googlebot-Mobile|Mobile|mobile|mobi|Windows Mobile|Safari Mobile|Android|Opera Mini

Another common use would be to use the above, but with “Mobile” excluded from the list of matching User Agent strings so iPads will (as Apple suggests) still serve up the desktop theme.

Given this approach, and seeing how it’s so easy to have disparate features between the Mobile and Desktop versions of your site, it’s not uncommon to hear something like, “It’s simple and beautiful, but I can’t switch to the desktop view when I want to.”

The ability to switch to the desktop theme from a mobile device is unfortunately not supported by the native iPhone theme out-of-the-box. However, this is definitely possible and not really that hard to accomplish!

Since the site is actually running on the same URL and serving up a different theme based on the User Agent, the technique here is to utilize a cookie to override the design exception and prevent it from being applied. Having implemented a number of mobile sites, we put together a small module to allow adding this sort of behavior to the mobile theme, complete with support for the Enterprise Edition’s FPC.

The critical piece of functionality is as simple as this: rewrite the core/design_package model and override a method to check for a cookie before allowing the design exception to be applied:

  class CLS_DesignSwitcher_Model_Core_Design_Package extends Mage_Core_Model_Design_Package
  {
      /**
       * Get regex rules from config and check user-agent against them. We override to
       * determine if the design exception should be ignored based on presence of a cookie.
       * 
       * @param string $regexpsConfigPath
       * @return mixed
       * @see Mage_Core_Model_Design_Package
       */
      protected function _checkUserAgentAgainstRegexps($regexpsConfigPath)
      {
          $ignoreException = null;
          if (isset($_COOKIE[CLS_DesignSwitcher_Helper_Data::FULL_SITE_COOKIE])) {
              $ignoreException = $_COOKIE[CLS_DesignSwitcher_Helper_Data::FULL_SITE_COOKIE];
          }
          return $ignoreException ? false : parent::_checkUserAgentAgainstRegexps($regexpsConfigPath);
      }
  }

I’ll not post the entire source here on the blog, but you can grab a copy from GitHub. There are complete instructions on how to use it in the included README file. Essentially though, all it takes is the installation of the small module, and inserting the following snippet into the footer of your site:

<a href="<?php echo Mage::helper('cls_designswitcher')->getMobileToDesktopUrl() ?>">View Desktop Site</a>

We are increasingly seeing a demand for responsive designs, but still get a lot of requests to simply build a separate mobile site as well, so I hope this will prove useful to some of you. Feedback, questions/comments are welcomed! Or if you have a mobile site (or responsive design) you need built, drop us a line via our contact page.