The Roveb Blog @roveb-blog - Tumblr Blog

Leveraging Social Networks in Mobile Commerce

Lately there's been a lot of talk about many renowned retailers, like J.C. Penney, Gap, Banana Republic, Old Navy and Nordstrom, shutting down their Facebook stores due to lack of interest and activity from users. Why would customers go to Facebook to interact with a store when they can directly visit the store's website?

While many businesses have discovered that customers preferred shopping directly on their own sites, the impact of social networks like Twitter, Facebook and Google+ on buyers behaviour is significant.

Word-of-mouth recommendations strongly influences purchases. In one recent study, it was found that 60% people are willing to post about products/services [on Facebook] if they were offered a deal or discount. In another survey, 67% of Web shoppers said that they are more likely to buy a product or service when a friend recommends it to them.

This notion of social sharing and peer recommendations compliments our aim at Roveb to create a mobile commerce platform for small-medium businesses.

With an ever increasing number of mobile Web users (around 1.2 billion) and an increasing number (over 50%) of local searches done from a mobile device, businesses must have a mobile presence to engage their mobile visitors.

With Roveb, businesses can create a mobile website, feature their products or services with exclusive deals for mobile visitors and reward users who recommend on social networks or visit the business. This mechanism not only creates virality and awareness for the business but also brings new customers and helps retain existing ones through the in-built loyalty program.

Our Experience With jQuery Mobile and Sencha Touch

Before we started building Roveb, we spent some time researching and studying mobile Web usability on smartphones. Our main focus was on hand-held usability, small-screen aesthetics and Web standards. During the initial prototyping phase, we reviewed jQuery Mobile and Sencha Touch as two of the many mobile Web development frameworks out there.

We found that both of these frameworks are better for native app development (with the Web app running in a container) rather than for mobile Web apps or mobile websites, since they are not optimized towards a great user experience. Both try to mimic the native app look & feel, but in most cases their shortcomings make their use counter-productive for the mobile Web in its current state.

Here's a summary of our analysis:

1. Size and Speed

jQuery Mobile (1.0.1) CDN-Hosted JavaScript is 81.5KB (minified) in size or 24KB minified and gzipped.

jQuery Mobile (1.0.1) CDN-Hosted CSS with Default Theme is 48.6KB (minified) in size or 7KB minified and gzipped.

jQuery core (1.6.4, required for jQuery Mobile) CDN-Hosted JavaScript is 89.5KB (minified) in size or roughly 30KB minified and gzipped.

That's a total of 220KB (minified) or 61KB minified and gzipped, to be delivered on an average mobile network (remember smartphone users are most active outdoors, away from their home or office WiFi).

Sencha Touch (1.1.1) core JavaScript (no official CDN copy available) alone is a whopping 367KB (minified) in size.

These figures exclude any custom HTML, JavaScript, CSS and images that the final mobile app or website will hold.

The sheer size of these libraries made it unacceptable for real-world use cases. Even if the files are served from a CDN, it still leaves room for improvement, until 4G becomes a widespread standard.

So why is file size a major consideration for mobile Web apps and sites? Because not only does it affect the download time of the resources on mobile bandwidth, but it significantly increases the parse & render time (see below) in mobile browsers.

Sure, a CDN (with local fallback ofcourse) will provide slightly better downloads, increased parallelism and better caching, but those advantages are mostly made redundant due to the increased mobile network latency, mobile browser gzip decompression and script parse time.

2. Parse Time

Speeding up mobile websites is as important as having one. Google's mobile performance best practices suggests:

In our own tests conducted in early 2011, we found that on modern mobile devices, each additional kilobyte of JavaScript adds about 1ms of parse time to the overall page load time. So 100kB of JavaScript included in the initial page load would add 100ms of load time for your users. Because JavaScript must be parsed on every visit to a page, this added load time will be part of every page load, whether loaded from the network, via the browser cache, or in HTML5 offline mode.

That would roughly equate to 171ms of load time for jQuery Mobile and jQuery (minified and decompressed), and around 370ms+ for Sencha Touch, on each page request. Add the mobile browser gzip decompression time along with load time for other content on the mobile page and those numbers would go up even more.

With site speed becoming increasingly valuable in Web search ranking and overall online sales, even small changes in response times, specially in a mobile environment, can have significant effects.

Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20%. Tests at Amazon revealed similar results: every 100ms increase in load time of Amazon.com decreased sales by 1%.

3. Usability

In our prototype testing on iPhone and Android, we found that while Sencha-based pages were pretty responsive and swift, jQuery Mobile operated with sluggish transitions, scrolling issues with fixed toolbars and inconsistent look & feel between the two devices.

Between the two, we found jQuery Mobile more suitable for development due to its markup-based approach as opposed to Sencha's pure JavaScript code, despite jQuery Mobile being sluggish than Sencha in actual usage. Sencha has an Open Source version. jQuery Mobile is Open Source too, and it is backed by a smart community. It also has a wider device support, although 95% of current US mobile traffic is represented by Apple iOS 3+, Android 2.1+, and BlackBerry 6+ devices alone.

So when it comes to developing for the mobile Web, light-weight and more optimized alternatives like Zepto.js and HTML5 Mobile Boilerplate are more suitable.

Will You Pay for a Responsive Redesign?

That's one of the questions we asked in our online survey and interview questionnaire during the initial Customer Development for our mobile startup - Roveb.

We spoke to friends, relatives, existing clients, past employers, local shops and small businesses, people who were in a position to make decisions for their business or their employer. The response we got was surprising.

Nearly everyone understood and appreciated the importance of a mobile strategy for their business. Almost 65% of the respondents acknowledged that Responsive Design (as we briefly explained to them) is a good approach for designing device-agnostic websites and Web apps.

But an overwhelming 93% said that they will not undertake a redesign initiative for a Responsive Design. They would rather have a separate presence that's optimized and targeted for mobile users. (Update 17 Jan 2012: Of the top 100 sites most visited on the internet, 71 of them have content specifically designed for mobile devices. Source: BuiltWith)

A lot has been said about what makes Responsive Design unfriendly for smartphones in particular. It may still be a good idea for new websites/webapps to be built with Responsive Design principles in mind right from the start.

Speed, simplicity and engagement are the key factors in a mobile environment. It's highly debatable whether Responsive Design alone can directly address any of these factors for mobile users out-on-the-move.

Brian Fling, author of the book Mobile Design and Development, contemplated with good reason:

"Great mobile products are created, never ported."

Our initial discussion with businesses (prospective customers) and real-world mobile users helped us understand what both sides really want from a mobile website. Further research and analysis on hand-held usability and small-screen aesthetics has guided us in differentiating the core facet of a practical mobile presence.

The Other App Store

When it comes to mobile apps, the debate around the choice of Native or Web lingers on. Both have advantages and disadvantages of their own, and more than often the choice depends on the nature of the application itself. Web apps are quickly catching up due to HTML5 advancements and mobile browser performance improvements.

One way to look at the whole picture is from a distribution point of view.

A Native app has pretty much a single point of distribution - an App Store. On the Apple/iOS App Store, the biggest among vendors, 37% of the apps are free while the rest are paid. 30% of revenue from the store goes to Apple and 70% goes to the producer of the app. There are nearly 500,000+ third-party apps officially available on the App Store, with nearly 18 billion downloads.

A Web app on the other hand can have multiple points of distribution, like search engines, direct website redirection, QR codes, URL's on stationary and advertising, even word of mouth etc.

Say, Linda is driving back from work and she wants to lookup the closing hour of the nearest Indian restaurant for take-away food. She's not going to search the App Store for a suitable app to do that. She will most likely search the mobile Web (or let Siri do it for her) and she'll lookup the website of the first restaurant found. 9 out of 10 mobile searchers have taken action as a result of a smartphone search. But if the restaurant's website is not mobile optimized for Linda to be able to find their closing hour, then the restaurant would lose out one a potential customer -- and all this would happen within seconds.

Keeping the current usage trends in mind, I'd say that the biggest distribution point for any mobile Web app is organic search. Search is the most visited website via mobile, beating out even social networking sites. According to Google, 50% of all local mobile searches are now done from a mobile device, and by 2012, there will be 5 billion mobile devices in use, the equivalent of 70% of the world's population.

Google Search is undoutedbly the biggest and most effective rival app store. It's one of the best ways to leverage organic distribution. It may take a little time, less if you already create fresh unique content, which is also the best way of optimizing for search engines.

This strategy costs next to nothing, as it will incur minimum upfront and long-term expenditure. A Web app can work on multiple mobile devices and in-fact look and feel largely the same as their native counterpart. It has no entry cost, no revenue split, no restrictions, better security, instant updates, industry standards and much more. Moreover, businesses can combine their whole Web app strategy with smaller utility-driven native apps.

The Financial Times mobile is a good example of a mobile Web app done right, and some major publications and businesses have similar mobile presence out already.

How to Integrate Siri with your App?

Voice and speech technology is a hot topic these days, thanks to Siri on the iPhone 4S. Just the other day I read a tweet that said:

I'll marry you Siri if you can do my laundry?

Coming to think of it, most users perceive Siri as a female assistant, due to its voice. Scientific studies have shown that people find a woman's voice "more pleasing" than that of a man, and hence so many voice-enabled devices sound feminine. But, the question remains -- can Siri, touted as the coolest feature of the new iPhone 4S, really do laundry?

I was hoping to demonstrate that Siri is practically capable of doing your dirty laundry, if you really want it to, but to avoid any inclination towards chauvinism, misogyny or disrespect, I'll just stick to an example around a typical software application.

Apple hasn't (yet) released an API or SDK for Siri, so we are pretty much on our own. Having said that, we can exploit a workaround (or two).

Let's assume that my company makes a humble Project Management software, named ProjectTracker. I want my customers to be able to run various types of queries in ProjectTracker using voice-assistance on their mobile device.

One of the queries might be:

What is the current status of the Ford project on ProjectTracker?

Siri won't know what to do with that. If you ask Siri to use a specific app or website (ProjectTracker in this case) that isn't supported, it won't be able to take a relevant action besides a Web search. But, we can make Siri recognize the name of our app and communicate the transcoded query in text form back to us through an SMS or Email for processing and response.

First, we can create a QR code for a phone contact (vCard), which our users can scan to add our app's contact to their phone, primarily for automated voice-assistance. The contact will basically hold the name of our app (ProjectTracker) and a phone number (through Twilio for SMS processing) or an email address (for incoming message parsing with Mailgun, SendGrid or PostMarkApp).

Now when our users ask Siri, "What is the current status of the Ford project on ProjectTracker?", Siri will automatically route the query as an SMS or email message to the ProjectTracker contact we provided. So far so good, but what we also need is the ability to parse the message, preform a suitable action and send a response back to the user.

To achieve this, we'll use a natural language processing and text analysis API (like Alchemy, OpenCalais, Yahoo Term Extraction) for entity tagging, keyword extraction and even sentiment analysis if we want. In the context of our message, this analysis will be able to tell us that "Ford" is a company (entity tagging) and "status" is a matching command (keyword). We can then run a quick database query to find project(s) for a company named "Ford" and retrieve its current status along with other information like allocated resources and estimated date of completion.

Finally, we can respond back to the user with a meaningful reply:

The Ford project is 2 days behind schedule. Mark and Raj are working 80% on it. It's estimated to be completed next Friday.

Once this message arrives back on the user's mobile device (as an SMS or email), Siri can even read it back to them.

As an aside, if your app needs to be integrated with the phone calendar, then you can rely on CalDav as shown by the Remember The Milk guys.

Back to the question of laundry, maybe with a little bit of zest and some Ardrino magic you can work wonders with Siri. What do you say?

Trending Blogs

Recently Viewed Blogs

The Roveb Blog