We Blog

August 15, 2012

Updates from the Mobile Trenches (Part 2)

Share |

In my last post I discussed changes in our process over the last 18 months, as well as looking at the choice between apps and sites and the potential of responsive design. In this installment, we will continue our strategy discussion by touching on iPads, testing mobile projects, and how to select target platforms.

 

 Does ‘Mobile Design’ include iPads?

 Ok, so iPads aren’t mobile. Sometimes they’re grouped in with mobile devices, but they aren’t really mobile devices. While they may be physically portable, shoppers don’t use them like mobile devices, their screens are bigger, and they have different (overlapping, but different) design metaphors and styles. However, they convert like crazy. Shoppers on iPads convert at roughly the same rates as full-size computer shoppers. Making your full (i.e. non-mobile) website compatible with iPads is relatively straightforward for most companies, and will absolutely have an impact on your bottom line.

 Other tablets are coming onto the market over time, and if iPhones and Android phones are any indication, Android tablets will eventually be more numerous than iPads, but will probably not convert at quite the same rates. However, the same compatibility work you should be doing for iPads will also help with Android tablets, which will eventually make up a significant source of traffic.

 

Target Platforms- Who Do You Love?

 One key thing our mobile teams have learned about mobile projects is to identify your target platforms early in the process, as early as is practically possible.. This is important because the breadth and types of target platforms can have a big effect on the effort involved in the project. Using analytics to look at the current usage patterns is very helpful in identifying which platforms should be targeted. Analytics can also be used to justify weeding out platforms that will be expensive to develop for and will represent a small minority of visitors- I’m lookin’ at you, Blackberry! According to our stats, Blackberry users are both less common and less likely to purchase than iPhone and Android users. When you consider the additional effort that is required to get mobile sites to function properly on some Blackberry phones, it can be more practical to drop Blackberry (or at least their older phones) from the target platform list.

 Android can also be a bear when deciding on target platforms. Different versions of Android add new features and drop old ones, leading to increasing unpredictability about how an individual phone will display or handle sites. Manufacturers are notorious for not allowing Android system upgrades, so individual phones are locked to one or two versions of the OS. One way to manage expectations is to agree on a target Android version and use that version during development, QA testing and customer acceptance testing, ensuring that the functionality delivered works as promised without sinking into the quagmire of which features are supported in which versions. 

 

Testing Your Patience

 Testing can be another trouble spot with mobile development, but of course with testing, the harder it is the more essential it is. We are seeing challenges with devices, simulators and connection speeds.

 The first area is with getting the devices into the right hands. It’s essential to ensure that all stakeholders (both client and vendor stakeholders) have access to the targeted devices in an effective and timely manner. That means that they need to have received the appropriate mobile devices before the beginning of the testing window at the latest. IT groups everywhere are struggling to make these devices available to stakeholders, so it’s essential to get this ball rolling months ahead of schedule (another reason to decide on your target platforms as early as possible – see above). That way the inevitable questions that come up can be answered and the phones procured early enough to complete testing on time. Under ideal circumstances, stakeholders would have these during the comp review process, so they can view the comps in context and understand how the site will look when built. 

 The second area is testing on simulators. Testing on simulators, while convenient and often easier than trying to procure a specific device, does not accurately reflect all of the features, constraints and limitations of the actual device. Simulators almost all consist of some kind of browser or browser add-on that simply presents the site in a window resized and decorated to look like a mobile phone. It’s not using the actual mobile browser code, it’s not subject to the processing power limitations or  bandwidth limitations present on the phone. For many of these reasons it will mask problems that later appear on the real mobile devices. On the flip side, simulators can be buggy themselves, forcing developers to spend time fixing bugs that don’t exist on the actual mobile devices at all.

 Finally, testing at multiple connection speeds is essential. The site should be tested on Wi-Fi, 4G, 3G, and 2G/EDGE networks to ensure that performance is acceptable in all cases.  It’s important to do this not only in QA but also as the code is written, so that the development team understands the constraints present when shoppers are using the site and can tweak things as they’re being built, rather than coming back later and fixing finished code.

 

In Closing

 Hopefully the lessons we have learned and described here will be helpful while planning and executing your own mobile projects. Maybe the time we have spent metaphorically smacking our heads against these tiny computers can save you a few headaches down the road.  

 

August 14, 2012

Updates From the Mobile Trenches

Share |

A little over a year ago, I wrote a blog post called “Notes From the Mobile Trenches” (http://blog.fry.com/my_weblog/2010/11/notes-from-the-mobile-trenches.html) that discussed some lessons I learned while implementing my first few mobile sites. Now, with several more launches under my belt and plenty of time to talk to other smart people about similar experiences, I have some additional thoughts.

 

The Times They Are a-Shakin’

Looking back at least year’s post, a few changes jump out at me. Now that mobile sites have been around for a while, better stats are available and better planning is possible. This is an example of how the field itself is maturing. In fact, with more than a year of measurement on some sites, we now have enough stats on sites we’ve built to move beyond  generalized stats from early adopters to make strategic and tactical decisions.

 

Another change in the field: the browser wars are slowing down as the Blackberry continues its decline. iOS and Android now dominate the mobile arena in terms of visits. While more Android phones are in use, it’s our observation that iPhones are still responsible for many more visits- as many as double the rate of Android phones- and also convert at a higher rate. Windows phones are still a blip in terms of traffic, but that is something that is likely to change. How much it will change is yet to be determined.

 

Also, networks are also continuing to improve as mobile carriers add or update towers and an ever-growing set of providers get access to the iPhone and top-tier Android phones. 3G network capacity is expanding, and 4G networks are becoming more common- at least if we can trust the phone providers’ definition of ‘4G’. This reduces some of the issues I previously discussed with dial-up-like performance, which is a step in the right direction. On the other hand, there are still areas where my iPhone doesn’t get 3G network connectivity, like my mother-in-law’s house in one of the ritzier (and hillier) Detroit suburbs. What this means is that 3G performance for your shoppers becomes more likely every year, but won’t be guaranteed for some time to come.

 

To App or Not to App

The ‘site vs. app’ question is still out there, and still a bit murky for new entrants into the mobile world. One important thing to consider is that every site will have visitors from mobile devices, whether you have a mobile version or not. This really means that the question isn’t whether to do a mobile site or an app; if your company is launching an effective mobile strategy, a mobile-optimized site is required. Only the app is optional.

 

Given that ecommerce sites must be mobile-friendly, how do we assess whether an app is needed? Really it is a simple choice: If the requirements for a mobile project include features that aren’t available or appropriate for a mobile site, an app will be necessary. If all the features can be implemented and perform well on a mobile site, the app can be skipped In essence,  if the mobile feature being requested requires access to the phone’s camera, microphone, accelerometer, or other sensors, an app will be necessary.

 

For most phones, access to the location services (including GPS) is available from the browser. We have had good results implementing location-aware features on mobile sites, but some more processor-intensive uses of location services might be better in an app. Under ideal circumstances this could be decided by some proof-of-concept development, to get an idea of performance impact. 

 

Finally, an app may be necessary if some features are very processor-intensive. Even the most modern phones still have much less processing power than a ‘real’ computer. While a site will always have the browser’s overhead and will be doing calculations in scripted code, apps can be doing the same calculations in compiled code, optimized for the specific platform it is running on. This can (in some cases) result in better performance in an app.

 

As alluded to above, one drawback with apps is that, although they can be optimized for each platform, a separate app must be written for each platform that will be accommodated. Although most of the user experience and visual design work can be re-used in most cases, at least some of the design will need to be tweaked on a per-platform basis. The actual coding work, on the other hand, will need to be almost entirely re-written for each distinct platform and they will then need to be maintained separately.

 

What the Heck is ‘Responsive Design’?

One approach to addressing the needs of your mobile web users is to build a separate mobile-optimized site and redirect mobile users to that site. This is a common and effective approach, and one that Fry / MICROS-Retail frequently uses with ecommerce clients. This site accesses the same catalog as the main site, but the HTML served to mobile users is different.

 

Another approach is to build a single site that will change depending on the user’s device. Because this type of site ‘responds’ to the device the customer is accessing the site with by adjusting its layout to the user’s device, it’s referred to as ‘responsive’. This approach has become more popular recently as our clients look for an approach to handle the new landscape of dozens of different mobile, semi-mobile and non-mobile devices.

 

So which approach is better? It depends! Specifically, it depends mostly on your content, and it depends a little on the way that you want your site to be perceived by shoppers. Some content is well-suited to responsive design, other content is less so. Going with a responsive design if you are a big-box retailer, for instance, may make it hard to show off the wide breadth of your retail offerings. On the other hand, a small boutique retailer with only a few types of products may be well-served with a responsive design that emphasizes their brand. In any case, responsive design is often appreciated by more web-savvy or design-savvy users, so it can add a bit of cachet to your site if you expect to serve that audience.

 

The Fry design team and MICROS-Retail development team have together implemented both mobile-optimized and responsive sites. Deciding which approach to take requires getting together with your strategy, UX and visual design team members and thinking through which approach is best suited to your content and goals. Remember that the responsive design will also replace your full site, so that may change the scope of the project, especially if the existing site is heavily customized.

 

Tune in Next Week…

So far we have discussed general updates in the mobile space, the app vs. site debate, and responsive design- just the tip of the iceberg! Part 2 of this post will discuss iPads, selection of target devices, and testing considerations.  

 

December 06, 2011

Same-day delivery, soon to be a reality?

Share |

Fast, reliable fulfillment is part of consumer brand perception, and a key driver in the purchasing decisions.

There is no bigger success story of fulfillment as a brand element than the internet behemoth Amazon.com. Amazon itself does not sell unique products or always even offer better pricing (for years they have allowed their marketplace sellers to consistently undercut them on price). What they offer is a bulletproof fulfillment experience and a breadth of product unmatched anywhere, period. This strategy, along with their ingeniously addictive “Amazon Prime” has allowed them to continue to win the consumer’s dollar online, while the rest fight to maintain their market share.

With the recent buzz circulating about a possible Google quick ship service, there may finally be a viable challenger to Amazon’s dominant market position. If it comes to life it could prove an interesting opportunity for retailers to play catch-up and finally be able to compete with Amazon’s core competency of being the fastest shipper in the biz.

One of the purported aspects of Google’s strategy is the ability to take the goal of instant gratification for the consumer one step closer by offering “same-day” delivery service for certain products. It is speculated that same-day delivery will be accomplished through leveraging the existing store inventory of Google’s retail partners. In theory, a customer searching for khaki pants could start their search on Google, select a product from one of Google’s partners, for instance GAP, if GAP has that particular SKU in stock at a surrounding store the same- day delivery option would be enabled. From there, the order would be parsed out to the store for fulfillment and a courier, or shipping partner (there’s been some speculation even of a Google branded delivery service) would transport the purchase the customer’s door.

Although it is early yet to gauge the feasibility of such an offering, it certainly seems like a natural extension of the cross-channel experience. Already customers expect the ability to search store inventory or ship-to-store. Companies like Best Buy, Wal-Mart and Sears offer same-day store pickup and Nordstrom has seen success with their ship-from-store program.

In the wake of such continuing innovation, retailers need to be proactive to ensure that they continue to keep pace with customer fulfillment demands. This is especially true during key selling seasons when retailers should be looking to put their best foot forward and impress their web shoppers with unprecedented service.

Jennifer Ulrich is Director, Supply Chain Services at Fry.

November 29, 2011

2011 Holiday Online Spending on the Rise

Share |

Fry/MICROS-Retail is happy to report that sales over the past holiday weekend have boomed for its online retail clients. Of the 25 websites monitored, these clients enjoyed an almost 30% increase in year over year revenue from Thanksgiving Day through Sunday. The total number of orders is up almost 23% over last year for the same time frame. Average order value also increased by an average of $6.86 per order. 

The big story, however, is that revenue taken in on mobile devices is up significantly, five times more than last year’s figure and accounts for 2.5% of all revenue. Tablet shopping is up seven times 2010’s figure and accounts for 5.4% of all revenue.  This is up from 0.8 and 0.9% respectively. 

We will report on Cyber Monday activity once the day is complete and data has been analyzed, probably late Tuesday or early Wednesday.

 

Emily Kania is Fry's Marketing Manager.

November 14, 2011

Where Have All the Visited Links Gone?...

Share |

Perhaps you haven’t noticed, but the visited link –- once a staple of website design -– has all but disappeared from many websites.  And eCommerce websites are some of the worst offenders.  In fact, of the Internet Retailer Top 10 Retailers for 2011,  only three (Amazon.com, Walmart.com, and Dell.com) include a visited link color.  And a quick survey of the Internet Retailer Top 10 Retailers for 2011 suggests that the overall percentage of eCommerce websites using a visited link treatment is well below 30%.  Compare this with Jakob Nielsen’s estimate that 74% of websites were using different colors for visited and unvisited links in 2004.

What’s the big deal?

Alright, so fewer sites are making use of a visited link treatment – why does it matter?  Why is the visited link so important?

The benefit of the visited link has to do with the difference between recall and recognition.  In recall, a user first has to retrieve past information from memory and then identify the correct item.  Recognition, on the other hand, only requires the identification of the correct item from a number of possible choices.  Therefore, in many cases, recognition should be faster and more accurate than recall.  The visited link enhances recognition in website navigation by providing cues as to where one has already been.

Jakob Nielsen has been arguing for the use of the visited link color since 2004. And it continues to be the number 3 pet peeve on his 2011 version of the Top Ten Mistakes in Web Design. So why aren’t people listening to him?

One of the primary hurdles to wider use of a visited link color likely is the notion that visited links are ugly and detract from a website’s visual design.  Beyond aesthetic concerns, the visual clutter caused by a mix of very incongruous link colors on a website could actually cause more usability issues than it solves.

What are my options?

A few years ago, a number of people were actively exploring alternative methods of indicating visual links – options that might be more aesthetically pleasing and usable than a link color. Simon Collison explored using background images to place checkmarks next to visited links.   Others explored a strikethrough font for visited links. And some even experimented with more advanced page manipulation for visited links, such as hiding article summaries after the article has been viewed.

Unfortunately, complex styling of visited links opens a security hole that can allow a website to determine a user’s browser history. So called “history sniffing” can then be used for targeted advertising, and potentially to track users. Therefore, most of the major browsers no longer support the creative treatments described above. For optimal cross-browser support it’s best to rely on the tried-and-true color change for visited links.

When using color as the visited link indicator, it’s common to use a more muted version of the primary color (thus making the link look like it is worn, or used). It’s also important to ensure there is a significant difference in the brightness of visited vs. unvisited links, in order to make the difference perceptible to color-blind users.

Zappos_Visited_LinksA number of sites are now using visited link colors that are aesthetically pleasing. Zappos, for instance, uses the visited link effectively in both category navigation and product selection. Though a stronger brightness difference between visited and unvisited links would enhance the usefulness, the color change for visited links is effective, while still visually appealing. Additionally, the idea of providing helpful cues enhances the Zappos brand, which is all about helping the customer.

Are you sure I need a visited link color?

Certainly, there are situations in which visual indication of visited links may not be necessary.  For example distinguishing visited links may not be critical when the site is small, or when the available navigation options are clearly distinct (e.g., the top-level categories on most eCommerce sites). However, there are some compelling reasons for including a visited link color in your site navigation.  Here are just a few…

Products Listed in Multiple Locations within Product Hierarchy:

Walmart_Category_NavOn Walmart.com, the baby clothing category is duplicated in two locations in the product hierarchy, and it is named differently in each location.  Imagine going to look at baby clothing one day and then coming back the next day to find that cute baby dress you liked. Would you know where to look?  Fortunately, when you visit either category, Walmart.com marks both categories as visited.  Therefore, though you might not remember which path you took to find the dress, the visited links would give you confidence that either path would correctly lead you to your destination.

Visually Similar Products on Product Thumbnail Page:

Amazon_CamerasAmazon.com sells millions of products – which sometimes can be a little overwhelming.  Suppose you were browsing a list of digital cameras on Amazon and you decided to click through to view the details of the camera. If you then clicked back to the product thumbnail page, how difficult would it be for you to determine where you left off browsing, if it were not for the visited link color?

Product Lists that Update Regularly:

Powells_Books_BestsellersOn Powells.com, the bestseller list is updated hourly, meaning that products come and go on a regular basis. Therefore, the product you saw an hour ago at position #2 may no longer be in the same position (or even on the list!).  Given that this feature likely is intended to help people discover books with which they’re not familiar, the use of a visited link color helps people to remember whether or not they have viewed a given book (since the user might not remember the book’s title).  Additionally, if a book were to appear on multiple lists (e.g., best sellers, highest rated, new this week, etc.) the visited link color would be helpful in identifying previously viewed books across different contexts.

…When will we ever learn?

Though the disappearance of the visited link has happened without fanfare, you should be aware of its impact on your web browsing experience.  Specifically, pay attention to the cognitive effort you have to expend on sites without a visited link color, just to keep track of where you’ve been.  You’re sure to develop a renewed appreciation for the visited link.

 

Kevin Simons is a Senior Information Architect in Fry's User Experience Design group.

August 15, 2011

PCI: A Daily Reminder

Share |

By Trish Rocco -- Director, Product Management

After just completing the PA-DSS assessment for latest release of MICROS-Retail’s OMS solution, CWSerenade, I got to thinking that adhering to strong security guidelines should be a reminder on every retailer’s corporate calendar. That reminder should include both internal operations as well interactions with your software vendor. Below is a list of some security guidelines specifically related to dealing with your software vendor:

  • Only use payment applications that are PA-DSS* compliant.
  • Be sure to review and adhere to the software vendor’s security guidelines document. Software vendors who develop payment applications for resale are required to provide a guide to instruct their customers and resellers/integrators on secure product implementation and on-going use.
  • Restrict your software vendor from maintaining user accounts and any security related data.
  • Ensure the software vendor has no access to encryption keys and remember to change your encryption keys every six months. 
  • Ensure the software vendor delivers software updates in a secure fashion.
  • If your software vendor requests that you turn on logging to diagnosis a problem, be sure to turn off or lower the logging level as soon as the issue is resolved and purge all unnecessary logs.
  • Provide your software vendors with the lowest level authority necessary for them to perform the required tasks. Ensure your software vendor has no access to encrypted credit card data in database tables or displayed on screens.
  • Configure communications with your vendors so that communication is initiated by you rather than the vendor. Configure vendor’s user ID and password to expire or be disabled daily.

Refer to the PCI Security Standards for a complete list of security guidelines.

Taking these simple steps to ensure that your applications are protected can save you much in the long run.  You know the old saying: an ounce of prevention is worth a  pound of cure.

 

* PA-DSS (Payment Application Data Security Standards) applies to software vendors and others who develop payment applications that store, process or transmit cardholder data as part of the authorization or settlement, where these payment applications are sold, distributed or licensed to third parties.