Ecommerce - responsive or mobile site? - mobile

Been wondering lately about responsive vs mobile site, especially for ecommerce. I have a rather big project coming up and it seems like it will be a relatively heavy one (in terms of templates and functionality). So immediate thought is to do a mobile site to cut on certain functionality that may be performance heavy but not that required. But does this make sense these days? Would there still be advantage of going mobile with ecommerce, or perhaps should just do a responsive?

There are advantages and disadvantages of doing a mobile site and a responsive website. I've recently went through this decision in my work as well. The points below are the main points I looked at when updating my website.
Mobile:
- Specific site created for mobile devices
- New domain name needed for the mobile site
- This may need to be updated as new phones are developed or new screen sizes are developed.
Responsive:
- Site is adjusted based on the screen size of the users device
- Lots of up-front coding needed
- No specific mobile domain needed.
- Currently no new code needed for new device sizes.
Although there was a lot of back end work (and I'll be honest there was a lot of back end work!). I think choosing responsive was right for my situation.
If you plan to use the website for a long period of time and you have the resources and time to devote to a responsive design I believe it's worth it.

One of the most compelling reasons for making a responsive e-commerce website is that Google recommend it!
Bear in mind Google's market share and that most of your SEO effort will be for Google. The following configuration is detailed by Google, the highlight is their own:
Sites that use responsive web design, i.e. sites that serve all
devices on the same set of URLs, with each URL serving the same HTML
to all devices and using just CSS to change how the page is rendered
on the device. This is Google’s recommended configuration.
Moreover, with frameworks like Bootstrap responsive websites are relatively straight-forward.

committing to a separate mobile website is a commitment to its ongoing maintenance -- so there has to be the budget/resources to do that.
another alternative is to use a front end framework like (twitter) bootstrap 3 that allows the website to be 'mobile first'. this was the breaking change between bootstrap 2 and bootstrap 3 -- bootstrap 3 looks for mobile devices first to speed up the rendering.
http://getbootstrap.com
the code needed for bootstrap 3 is relatively easy to implement -- but it is a commitment because all of your templates and forms and layout all have to be done with its code.
i am using bootstrap 3 for e-commerce and its great. a huge advantage of using bootstrap 3 is that as new phones etc come out, they are testing etc. some people complain that bootstrap sites look the same -- but for e-commerce -- having the interface look and feel 'familiar' for customers is good for sales.

Related

How to convert a ReactJS web application into a mobile friendly application

I am currently working on a complex web application written mainly in ReactJS with Redux which uses Node and Docker containers for deployment.
As the app is currently mainly used by laptop users, our next goal is to make the application mobile friendly (mainly iOS) and allow the user to utilize the phone's camera to upload photos straight to the app.
It's my first time trying to make a web application mobile-friendly so I am wondering what's the best approach for doing so. I've considered using CSS media queries to adjust the layout based on the screen size but we've come across a few drawbacks such as pop-ups or modals not looking as expected.
Should we go down the route of rewriting the code in React Native (not ideal approach), or are there any other better suited solutions?
Thanks
There are a number of options, most of which would have been better if implemented at the beginning of the project. Mobile-first UI development is by far the easiest way to deal with different device sizes, as you have already guessed with elements such as reducing your modals.
I would absolutely recommend using a UI library that comes with a responsive grid solution if you're not already using one. Available ones include, but are not limited to, Material-UI, Bootstrap (using a react implementation such as React Bootstrap) and Ant Design.
As to whether you should do a rewrite, that is up to you to compare the costs and benefits. What I would suggest is, instead of planning to go for something specific such as iOS, plan to support device sizes instead. Any decent UI framework will work in terms of common breakpoints that abstract you from thinking in terms of "iPhone X in landscape" to something like "Extra small", "Small", "Medium", "Large" and so forth.

Mobile Website Platform Pros and Cons

I am in the process of converting a very large E-Commerce website into mobile website. I wanted to find out different options which can be used for this process. I am aware of different libraries in which jQuery Mobile seems like the most mature one.
I also glanced at Ionic but it is still in Beta. What are your thoughts on different libraries for implementing mobile websites?
Last frameworks like Ionic+Angular, lavaca, famo.us... have better performance and faster than ever for develop, but they have still some compatibility problems with "old" smartphones (i.e. Android < 4.1), when jQueryMobile works better in old ones. Of course, as time passes this problem gets less important.
Take into account also that these frameworks are based on the SPA paradigm (Single Page Application) that possible is costly to adapt from your current website (JSP or JSF...).
If your app is based on J2EE JSF you can take also look into JSF-Primefaces that uses jQueryMobile as a front-end framework. Perhaps is a shorter path to reach your goal.

HTML 5 Mobile Web App Workflows? --- (Advanced Questions)

I'm beginning to build my first mobile web app and I'll be using a combination of html5, css3, javascript, and at the end I'll be wrapping it up with Phone Gap (Cordova) then deploying it out to both the Android and iPhone marketplaces. I won't be using anything else like java, php, or c#.. This is strictly front-end based, so the questions below are in retrospect to the this and will play a big role in creating my mobile workflow.
As I'm fairly seasoned in the above front-end technologies, mobile apps are a different world, which leaves me with some questions...
Mobile App Questions (Workflow)
1.) Should I build it with 1 page (single page app) or multiple pages? I know I could us an AJAX solution here to give the "1 page" look/feel, but what's the smartest solution?
2.) Ad placement, in retrospect to 1 page/multi-page apps, I assume multiple pages would be a smarter choice? The more refreshes the better for CPM or is this considered bad practice? ...or can I achieve ad refreshes with smart AJAX placement inside a 1 page app?
3.) Gestures vs. buttons and css - I've been building responsive websites for the last year and have noticed that I can achieve a lot of effects with css alone (i.e. hover, focus, active, overflow... to name a few). When is it necessary to use gestures? Hammer.js seems to be doing a pretty good job of these effects and I'll definitely be taking a closer look at that plugin.
4.) CSS3 Animations vs. Jquery Animations vs. WebGL Animations - What's best? According to this link, CSS 3 wins... But I've heard about css3 REALLY slowing things down (i.e. using border-radius). What's safe to use for a mobile app?
5.) The "back" button on android phone, I assume it's used just like a web browsers back button.. So if I build a "1 page app" that could be a bad choice if a user clicks "back" then immediately exits your application. I'm sure I could use an alert box to question the user first, just curious on if their is any recommended solutions?
6.) The "settings/options" button on an Android phone, I assume it will do nothing if I don't tell it to... But, if I wanted to tell it to do something how could I?
7.) File System - What's the best way to access the file system (opening media, saving media, saving media to "custom app folder name", sharing media to facebooks/twitter/instagram, accessing contacts, texting, email, etc...), Since I'm only using front-end technologies, what's the best ways to handle this? It seems like I've read somewhere that Sencha and/or Phone Gap have JS solutions for this.., what's your preferred way and how does it actually work?
8.) Testing - When I start implementing all of these "File System" commands, how on earth do I test this? I'm of course coding on a computer, Will Android and IOS emulators really do the trick or will I have to manually load my mobile app to a server and check? Is their a way to test locally with my phone? (that'd be cool :)
9.) Performance - I know performance is key with any application but ESPECIALLY mobile apps. I use jQuery (hey, I'm a UI guy :), and I know I'll be using a few other smart scripts so mobile phones will play nicely (SouthStreet Progressive Enhancement Workflow)... but how much is TO MUCH?? In the future if I wanted to use more powerful js libraries such as knowckout.js or angular.js, how would this effect the performance of a REAL html 5 mobile app?
These are the questions that are running through my mind right now. If anyone has some good knowledge of a tutorial that explains these things or if anyone can point me in a good direction I'd really appreciate it! I also hope that these questions will help other poor lost souls like myself ;)

zurb foundation 4 mobile vs desktop content

I'm a big fan of Zurb Foundation. They just released Zurb Foundation 4 which was redesigned to be mobile first. I'm fairly new to responsive design taking into account both mobile, tablet, and traditional desktop experiences. I'm trying to wrap my head around how best to manage my site's content for these different devices. With Zurb Foundation 4, you can hide or show content based on small, medium, or large device sizes. So, it seems with Zurb's approach you drop all of the content down to the device and let the CSS decide what content to show depending on device (this is responsive design).
My question is why do we have to drop all of the content to the device? That seems like a waste of processing on the server, a waste of bandwidth, a slower experience as the browser handles the content some of which may never be shown to the user because of the device they are using. Am I missing something? Wouldn't it be better to go back to the server and let it send content to the client that's appropriate for the device type? Shouldn't we be concerned about mobile user's data plans and not send down content that's not appropriate for their device type? All the examples that I've seen on responsive design has content for desktop and mobile/tablet downloaded to the client which seems to be a waste.
I'm developing a time entry application that has a different user experience based on the device type. Desktops (when in full screen) have a more detailed data entry experience whereas mobile/tablets have a different experience because of device real estate is smaller. I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate? I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
Am I on the right track with my jQuery approach? Am I missing something regarding responsive design and needing to tailor the content to the device? Any ideas, suggestions, and guidance is appreciated. Thanks.
Mobile First with Zurb Foundation is basically a philosophy change by the Zurb team and if you want do develop a responsive site and not take a Mobile First approach then I suggest using Foundation 3 which is still available and fantastic. There is a book that I am reading that gives a great pitch for Mobile First, called Mobile First by Luke Wroblewski who is also listed as an adviser to Zurb.
here is an article by the same author that might be interesting:
http://www.netmagazine.com/interviews/luke-wroblewski-mobile-first
Basically: the premise is that you start your development and design for a mobile, meaning basically an iOS or Android style browser and then add features.
So instead of starting with a desktop / tablet experience and removing things as was commonly done with .hide classes in foundation 3 and could still be implemented in this way with foundation 4, they suggest using .show classes to add additional content.
This can be taken way further by using Compass and Sass Mixins. There isn't a lot of great documentation on how to do this, but you can basically keep your markup semantic, apply an id rather than a class and use the mixins to apply it to that id. There are advantages here in speed traversing the dom for an id vs. a class so it can be a good way to go.
Note: foundation 4 is using the drop in replacement (there are some limitations) for jQuery called Zepto. You can replace Zepto with jQuery if you really need it in foundation 4 or use foundation 3 instead. Zepto is much more lightweight and thus suited well for mobile.
As for it being faster by using jQuery to async load the data (I am assuming) based on the size of the browser, that is one way to do it. I am not sure if you are going to have a huge speed increase here. There are many strategies, pagination, async loading more data on the fly, and it depends on how you arrange the UX / UI around that data.
There are also many other issues such as caching resources, CDN, etc. that are typical in front end engineering that might give a faster load time. One resource you can check out related to this is ySlow.
There are also many design patterns such as off canvas slides, the 3 line (hamburger menu), loading more data on scroll, stateless apps, that can allow you to have the same functionality in a mobile app. If you go stateless, after the initial page load other pages should appear to be almost instantaneous.
I think the question here is more philosophical, in do you need all of the features, which is one thing that I believe taking a Mobile First approach is trying to approach.
Another thing to think about is the perceived loading time. I think I read about this is Seductive UX (another great read) but the faster you can get the page up with a loader or spinner, the faster it is perceived to be loading, even when in actuality it can be loading slower.
As a final note, if you plan on using foundation, you might look into using jQuery/Zepto with Modernizr to pull from the same media queries foundation is using. That way you don't duplicate or create something that is inconsistent with the rest of the responsiveness.
I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate?
It doesn't sound like a good approach do you take orientationChange in to account?
I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
If you are on most tablets visiting the website in portrait and change to landscape you'll have to download the >768px UI after already downloading the <768px UI.
The mobile first approach in zb4 (with media queries) allow you to prevent stuff that belongs to big devices to be downloaded in to small devices. Basically you start with mobile styles and if the device meets the conditions you set on your mediaqueries (you can have much more breakpoints than the zf4 framework gives you by default) then the next rule jumps in.
I have worked in several 'responsive' projects even back in the pre-mediaqueries days were I use javascript to measure windowsize
Regarding javascript and like #powjames3 said zepto is much lighter / faster than jquery and if you could write your own javacript functions will be much better than using a over-bloated library.
Nowadays I do mobileFirst responsive webapps and websites use a mix of user agent sniffing ( sometimes to decide what image src or script / style src to deliver), despite the decision of the user agent tests i always serve mobile first mediaqueries, and conditionally loaded content.
"As Ethan Marcote (and John Allsopp before him), were right to point out, the inherent flexibility of the web is a feature, not a bug."
Here are some resources that might put you in the right track:
User agent parse and detection:http://mobiledetect.net/
Tutorial http://www.html5rocks.com/en/mobile/responsivedesign/ that covers:
Why we need to create mobile-first, responsive, adaptive experiences
How to structure HTML for an adaptive site in order to optimize performance and - prioritize flexibility
How to write CSS that defines shared styles first, builds up styles for larger screens with media queries, and uses relative units
How to write unobtrusive Javascript to conditionally load in content fragments, take advantage of touch events and geolocation
What we could do to further enhance our adaptive experience
Hope it helps

Tip for developing mobile ste

I am creating a mobile site and working on WAP for the first time and my main concern is that the site should render properly possibly on all handsets.
So,I was thinking to adapt responsive design approach.
But then I came across this sites :
http://www.webdesignshock.com/responsive-design-problems/
http://dapurpixel.com/blog/articles/responsive-web-design-pros-and-cons/
So,please provide some best practices to follow while developing mobile site. I googled it but it showed my tutorial for responsive design and I am not sure that this is the optimum method.
Thanks
It all depends on the website you are creating. Some type of websites (such as blogs) are really easy to make as responsive design. But some other websites (e-commerce, news magazine, deep websites) should be adapted specifically for mobile and tablets. Why? Because making the website adapts its width and column layout is often not enough.
Also keep in mind some features such as mouseover is rather complicated for tablet users. So menus with click that opens an accordion menu is simpler and feels more right. Creating a design that would work for everyone (One design to rule them all) could take more time to implement than simply creating a specific version of your website for handheld devices.
So it all depends on the nature of your website.

Resources