Responsive Design: How to address differences between touchscreen and desktop devices

[DivaVocals]

In examining some of the newest responsive template offerings some important differences between desktop and touchscreen devices has come to light. This is a continuation of a discussion started on the Stirling Grand Responsive Template support thread. I've also posted quotes from the important parts of the previous discussion just to get folks on the same page..

To me, it seems to be a problem if a responsive template only has full functionality when viewed on a desktop monitor.

To RikStix's point, I found the following awesome article on this topic (http://www.stucox.com/blog/you-cant-detect-a-touchscreen/):

Historically, two browser features have been used for "touchscreen detection": media queries and touch APIs. But these are far from foolproof.
Walk with me.
Device width media queries ¶

Mobiles have small screens and mobiles have touchscreens, so small screen equals touchscreen, right?

var hasTouch = window.matchMedia('(max-device-width: 320px)').matches;

So, so very wrong. Large tablets and touchscreen laptops/desktops have clearly proven this wrong. Plus thousands of older mobile handset models had small non-touch screens. Unfortunately, sites applying the mantra "If it’s a small screen, it’s touch; if it’s a big screen, it’s mouse-driven" are now everywhere, leaving tablet and hybrid users with a rubbish experience.

A GREAT example of this is my 10" tablet, and my 10" netbook.. The netbook is MOST DEFINITELY NOT a touch device.. Yet I would expect that if the full menu is presented on both devices that how I interact with it should be the same.. This might mean that the onHover is replaced with onClick for ALL devices.. (just thinking out loud)

Would love input from the Zen community..

[DivaVocals]

Wanted to recap the salient parts of the other discussion:

I know you have worked hard to put these responsive template together and it is difficult to anticipate every possible scenereo. Nice look Anne from desktop computers. I finally got tired of futzing around with Resp Shefield Blue and Resp AB and thought to try this one, which seemed fitting since most of our sales are Sterling.

Stirling installed without a hitch, I have yet to obtain a good functional install of the other 2.

There seems to be an issue with the Header buttons on my touch devices. Everything works as expected (so far) on desktop with a mouse. The Shop button functions as expected only every other time on my Window8 Pro tablet/FireFox 23.0.1. Just updated to FireFox 24.0 and functionality is different and worse (about the same as on my SurfaceRT). Sometimes the flyout disappears before I can get my finger to the next button. On the WindowsRT tablet, the header menu may as well not exist because there is no functionality at all.

Android ver 98.15.66, Motorola RazR-M . Display is about 4 screens wide in the portrait position instead of the width of the mobile device.

I am having trouble finding a "HOME" button on secondary pages other than the breadcrumbs and my fingers are too big to use that. No problems finding the Home button on the Home page.

To rule out the possibility of install issues, the above observations were made using your demo site instead of my install, though it was nearly identical.

Minor issues are alignment which does not affect functionality.

I could use any pointers that you may have.... OOPS.... internet connection seems to be dying......

What screen resolution is your windows tablet? If it is greater than 1024 pixels wide then you will see the full size version which uses the css mega menu. The css mega menu is not touch friendly. You would have to either change the menu or convert the mega menu to be touch friendly.

I have tested on the following: iPhone 5 with Mobile Safari 6.0; iPad 4 with Mobile Safari 6.0; Windows Phone 8 with IE10 Mobile; Blackberry Bold 9900 with Blackberry Browser 9900; and Android Nexus 4 with Chrome Mobile 18, Dolphin Mobile 9.3, Firefox Mobile 19, Marathon Mobile 4, Opera Mobile 12, Sleipnir Mobile 2.9. If you are viewing on a different device then it has not been tested. This is a free template and while I will do my best to always improve it, I would be surprised if it were perfect on every mobile device ever created ;)


Thanks,

Anne

Please, don't get me wrong, I love your templates and know that you spend a lot of time working through them. I know that it is impossible to test every possible combination of hardware/software. It is even more difficult when users start futzing around on their own and then asking how to fix their mistakes.

I'm sorry that I was confused because I was thinking the responsive templates were mobile device friendly/touch device friendly and didn't know that the menu bar was not intended to be touch friendly.

Both Windows 8 Pro tablet and Windows RT tablets are 1368 x 768 or 768 x 1368 resolution.
RazR-M resolution is 540 x 960

picandnix
Your site is setup a bit differently since it has sidebars on each side of the homepage. Screenprints of Windows 8 Pro tablet attached of HomePage both portrait and landscape. Login page portrait. I forgot to powerdown the RT and it's dead this morning.

Your install has a button to get back to the homepage where the demo does not.

Attachment 13171Attachment 13172Attachment 13173

I have the same issue with the mega menu on my phones and tablets. The biggest issue is that there is no such thing as an "onhover" or "onmouseover" event for touchscreen devices.. To remedy this, when I use this template (hoping to do so soon), I'm thinking that I'm gonna swap the included mega menu out with a responsive megamenu which supports "onclick". This will work well for both desktops and larger touchscreen devices..

The issue with that Anne is the larger touchscreen devices which may have the SAME screen resolution as a desktop computer (like my Netbook or Surface device, and even my Android tablet).. I don't necessarily want to replace the mega menu with the responsive drop menu for all devices.. I rather like the mega menu. I think the solution for me will be a mega menu presented on larger mobile/touchscreen devices which supports onClick versus onHover actions.

Basically I'm looking for a responsive mega menu similar to the one you are currently using, but I need one that does more than simply use media queries to detect screen resolution.. I would prefer that the menu also detect whether or not the viewing device is a mobile/touchcreen device and present an alternate version of the mega menu which supports onClick actions. That kind of functionality requires some javascript or jQuery magic to make it work.

Ideally this would mean that if the device detected is a mobile/touchscreen device, and IF this device is one of the larger mobile/touchscreen devices (meaning that it will not hit one of the media queries which presents the responsive drop menu), THEN present a mega menu which the action for the menu will be an onClick action versus onHover.

I just wanted to note that I can not test all touch screen devices in existence. On the list of handheld devices I have tested my responsive free template packages on, the only place where the mega menu is shown in on the full screen resolution of a desktop. On the tablets, ipads, and smaller the menu always switches to the touch friendly menu. Your's was the first time I saw the full resolution with the mega menu showing on a hand held device. Since this has been brought to my attention, I have been working on a solution.


Thanks,

Anne

Creating different menus for different devices is very easy.

Anne, I apologize for the hijack of your support thread. Last post regarding this.

Take a look at the responsive classic to see how swapping the category tabs for a select is done.

Take a look at the responsive cold steel to see how the product listing header is swapped for the SNAF filter.

Simply using the minWidthHide and minWidthShow CSS classes at the appropriate CSS media query handles swapping with ease.

Keep the current mega menu for desktop.

Using minWidthHide and minWidthShow CSS classes to hide (ids and classes for the on hover CSS) and adding new (ids and classes for the on click CSS)

Example of new on click link

<a id="WHATEVER" href="<?php echo zen_href_link(FILENAME_DEFAULT, zen_get_all_get_params()); ?># " onclick="('');return false;">

Then using minWidthHide to hide both above and minWidthShow for the toggle menu on phones.

I have several new responsive plugins, just trying to find the time to get them packaged up.

Okay.. playing the devil's advocate here, I have some questions.. Are media queries going to REALLY be enough??? Why not include javascript to detect when the device is a touch screen device versus a desktop device?? How does this code distinguish between my 10" tablet and my 10" netbook?? Which device will use an onClick action and which one will use an onHover action?? How does this code know when I am viewing from my HP - ENVY TouchSmart 23" Touch-Screen All-In-One computer versus my HP desktop computer with a 23" monitor??



I agree.. There's no way to test for ALL devices.. I personally don't own a iPhone or a iPad.. So while I could have my client's who own these devices test things for me, or I could enlist friends and family who own these devices to help me test, this isn't really a realistic or reliable means to test..

What about a device independent testing tool like the Responsive Design Mode tool that comes as a part of the Web Development tools built in to the latest versions of Firefox. The Responsive Design Mode tool will allow you to test what your site looks like a certain resolutions.. Couple that with the Web Developer tools other features which will allow you to tweak your stylesheet live and see what those changes yield before you add them to your stylesheet. The tool covers the most common device resolutions, and allows you to enter in custom resolutions if the resolution of the device you are testing isn't included.

Then there's a whole slew of site's with webbased responsive testing tools popping up:
http://beta.screenqueri.es/
Brief Description: Pixel Perfect Media Query Debugging Tool* Test Responsive Designs Across 60+ Device Viewports. Also allows you to enter custom resolutions
if the resolution of the device you are testing isn't included.
This one rivals the functionality of the FireFox Responsive Design Mode tool.

http://mattkersley.com/responsive/
Brief Description: This tool has been built to help with testing your responsive websites while you design and build them. You can enter your website's URL into the address bar at the top of this page (not your browser's address bar) to test a specific page.


http://www.studiopress.com/responsive/
Brief Description: This tool has been built to help with testing your responsive websites while you design and build them. You can enter your website's URL into the address bar at the top of this page (not your browser's address bar) to test a specific page.


I wanted to add to this that on my tablet (Samsung Galaxy Tab 2), the mega menu displays the full menu in landscape, and a "partial" mega menu in portrait. This is just fine except for the onHover vs onClick "issue".. On my LG Optimus Pro smartphone, the mobile menu displays in both portrait and landscape.. The Samsung Galaxy Tab 2 tablet isn't what I'd consider a terribly LARGE tablet at all.. In fact it's the size of my 10" netbook. (which also displays the mega menu at full size)

[rbarbour]

A GREAT example of this is my 10" tablet, and my 10" netbook.. The netbook is MOST DEFINITELY NOT a touch device.. Yet I would expect that if the full menu is presented on both devices that how I interact with it should be the same.. This might mean that the onHover is replaced with onClick for ALL devices.. (just thinking out loud)

Would love input from the Zen community..

Thought complete

There is no code to convert ones site to be "touch friendly", there is code to detect if ones device is capable of touch features at which point you could render a new CSS file to enlarge text and buttons.

IMO - a true waste of time.

For tablets and phones, simply replacing the onHover with onClick should cover 99.9999% of the devices out there that use touch features.

Responsive is not mobile and should not be treated as. Using CSS to alter the layout for different devices with minor css tweaks is what responsive is about. If one wants completely different layouts, mobile detection, touch detection, websites that resemble apps, the responsive code is not for you, you should be looking at mobile templates.

Again MO.

[DivaVocals]

Thought complete

There is no code to convert ones site to be "touch friendly", there is code to detect if ones device is capable of touch features at which point you could render a new CSS file to enlarge text and buttons.

IMO - a true waste of time.

There are PLENTY of business cases where this is not necessarily going to be true for all..

For tablets and phones, simply replacing the onHover with onClick should cover 99.9999% of the devices out there that use touch features.

And this is the direction I am thinking of moving in for my own purposes.. However this means replacing the onHover with onClick will have to be applied ACROSS THE BOARD unless and until there is a reliable way to distinguish touchscreen from desktop devices

Responsive is not mobile and should not be treated as. Using CSS to alter the layout for different devices with minor css tweaks is what responsive is about. If one wants completely different layouts, mobile detection, touch detection, websites that resemble apps, the responsive code is not for you, you should be looking at mobile templates.

Again MO.

I don't agree with this last part for a few very simple reasons.. The most important reason being that I do not want to have to manage TWO different templates for ONE site.. and a mobile template will mean that's just what I am doing.. any design (responsive or otherwise) that doesn't take this into account that there is a difference between a 10" tablet and 10" laptop/netbook is going to prove problematic in the long term..

[DivaVocals]

Found another article that is also on point..The part that resonated with me is quoted below..
6 Epic Forces Battling Your Mega Menus

Epic Force #6: Hover

Having originated around 2005, mega menus haven’t dealt with the reality of a hover-less device, such as a touch screen or screen reader.

Today, anything that uses hover events should send up a red warning flag to the design team. If current trends continue, it’s likely there’s a not-too-distant future where the majority of users are not using a mouse device. Hover doesn’t fare well in that future.


It’s possible to implement a click-based, non-hover-dependent mega menu. However, that adds more effort to manipulate the interface, which distracts the users from their goals.

Mega Menus Aren’t Evil, Just Troubled

We’re not suggesting that mega menus are the ultimate enemy in some good-versus-evil battle against the users. It’s just that they are a troubled lot, with the world biased against them.


If your design would benefit in some desperate manner from this navigation cliché, go ahead and use it. However, you probably want to watch it real close. Make sure you’re watching your users and your key performance indicators (especially revenue, if you’re an e-commerce concern).


Nothing comes for free and it seems the idealism of mega menus comes at a price. Make sure your organization is aware of what it’s paying for that slick design.

Begs the question I've been asking lately.. What is the BUSINESS BENEFIT of the onHover state used by so many navigation menus (not just mega menus)?? How does supporting onHover in menus that help with sales conversions?? Should designers and site owners just NOT to worry about the user experience on hover-less devices?? (many of which are NOT simple "mobile" devices anymore)

IMO media queries based solely on screen resolution are NOT by themselves adequate to determine how a responsive design should behave. I'll also say again that I disagree that the simple answer here is to just use a mobile template and forget about responsive design.. My 10" netbook is not a "mobile" device in any "traditional" way we typically think of mobile devices.. (which today is still considered by most to be tablets and smartphones) I wouldn't want to view ANY website via a mobile template on my netbook anymore than I would want to view that same website on a mobile template on my 10" tablet..

[rbarbour]

Okay.. playing the devil's advocate here, I have some questions.. Are media queries going to REALLY be enough???

Enough for what, media queries are intended for 1 purpose (to detect the browsers screen size) and apply the css rules applied.

Why not include javascript to detect when the device is a touch screen device versus a desktop device??

Because you would have umpteen amount of code to detect each and every device.

How does this code distinguish between my 10" tablet and my 10" netbook??

It doesn't, media queries detect the browsers screen size not the device.

Which device will use an onClick action and which one will use an onHover action??

Use the one that will work on the majority of devices.

How does this code know when I am viewing from my HP - ENVY TouchSmart 23" Touch-Screen All-In-One computer versus my HP desktop computer with a 23" monitor??

It doesn't, media queries detect the browsers screen size not the device.

I don't agree with this last part for a few very simple reasons.. The most important reason being that I do not want to have to manage TWO different templates for ONE site.. and a mobile template will mean that's just what I am doing..

Then keep it simple and design using features that compliment all devices.

any design (responsive or otherwise) that doesn't take this into account that there is a difference between a 10" tablet and 10" laptop/netbook is going to prove problematic in the long term..

There a services that offer device detection and redirect to specific template or load specific files (CSS) based on that device, their DB of devices is larger than 100 installs of ZC and continue to grow everyday and even with the millions of $$ spent on servers, data collection and operations they only deliver a 87% success rate.

Point being, there is no code that renders correctly for every given device. We can all agree that the onHover and onMouseOver event handlers DO NOT WORK on touchscreens, so when designing or implementing these APPEARANCE PLUGINS and or CUSTOM SCRIPTS, design or code ones that account for the majority.

[DivaVocals]

Enough for what, media queries are intended for 1 purpose (to detect the browsers screen size) and apply the css rules applied.



Because you would have umpteen amount of code to detect each and every device.



It doesn't, media queries detect the browsers screen size not the device.



Use the one that will work on the majority of devices.



It doesn't, media queries detect the browsers screen size not the device.



Then keep it simple and design using features that compliment all devices.



There a services that offer device detection and redirect to specific template or load specific files (CSS) based on that device, their DB of devices is larger than 100 installs of ZC and continue to grow everyday and even with the millions of $$ spent on servers, data collection and operations they only deliver a 87% success rate.

Point being, there is no code that renders correctly for every given device. We can all agree that the onHover and onMouseOver event handlers DO NOT WORK on touchscreens, so when designing or implementing these APPEARANCE PLUGINS and or CUSTOM SCRIPTS, design or code ones that account for the majority.

You are right.. There is no code TODAY that detects devices correctly.. but clearly times and things are a-changing.. there are already frameworks being developed to close this gap.. So yes I asked are media queries enough?? they aren't.. Browser screen size is not enough to determine what is and is not presented to a site visitor.. So yes you get no disagreement from me that TODAY design (responsive and otherwise) needs to design or code for the majority of devices, but I see signs that the gaps between web browsing using these devices will have viable solutions in the NEAR future. Technology allow designers to take advantage of the best of both desktop and touchscreen devices isn't far off though IMHO..

However this still leaves open the question on how to FIX the mega menu to resolve the gap in these devices that RixStix has pointed out.. Yes, convert hover to click.. great.. I am not seeing HOW to do this (and I've been messing around with the mega menu code to get this to work), and I'm sure I am not the only one who would just like to see a usable mega menu that works with hoverless devices..

[RixStix]

I feel like I'm responsible for mucking up Anne's support thread for Responsive Stirling with my questions. By no means, did I mean to say the template was junk. Anne has some of the best templates available to the zen-cart community, IMO.

That being said, maybe I misunderstand the intent of responsive templates. I am not a coder but have enough technical ability to make minor tweaks if I have an example of similar functionality.

My real job is to fabricate products for sale to our customers and to optimize our online store by making it as easy as possible for customers to spend money. We have learned that online shoppers seldom read help files, FAQs, etc.; thus requiring everything to be as intuitive as possible.

One thing that I have found by allowing a single customer using an iPad to look at the responsive template installed in our sandbox is. We have already discussed the the Hover vs On-Click issue....

• On the first step down from full desktop, there is no HOME button and the customer could not get back to a known starting point. This seems to be common to every responsive template that I've viewed. I'm guessing that this screensize step is used by MOST tablet devices. That WILL affect how customers spend money. If it is a issue of screen space, then maybe something needs to be sacrificed for the sake of HOME. Most of our customers do not understand breadcrumbs and don't even see them on the screen.
• On the smallest width, the customer could not find a way to see the store categories. So far, no one that I have shown has been able to figure that the button with 3 horizontal lines is the button to click to see the entire store categories. Again, this seems to be common to all responsive/mobile templates. That also WILL affect how customers spend money. If this icon is considered to be a universal standard, like a rabbit/turtle for speed, well, our customers have not received the memo yet. I don't know of a better icon.

Today's figures of our website stats:

• 67% of mobile devices are iPad, iPhone or iPod.
• 98% of sales dollars completed from mobile devices are iPad, iPhone or iPod.

I can only surmise that the sales dollars are not closer to the proportional figure due to less than optimal user experience with website functionality. Be it due to specific browser or basic website functionality, your guess is as good as mine but responsive templates on my Android phone do not function as expected, nor do responsive templates on my Windows 8 tablets (Pro or RT). That might change after tomorrow's update to 8.1.

[DivaVocals]

Let me throw in my three cents here.. You didn't muck up ANYTHING sir.. I moved this to a new thread because though this discussion was RELATED to the Responsive Stirling template, it was really a discussion that applies to not just this one template, but as you pointed out ALL responsive templates and it even extends to the many appearance mods that are popular here.. I ran in to "responsive" issues when looking at CSS Mega Menu, Horizontal Menu w/jQuery, Tabbed Products Pro, Image Handler (specifically that blasted image hover feature I DESPISE, but everyone seems to LOVE), Zen Lightbox, and Zen Colorbox just to name a few..

So on the contrary.. you didn't muck anything up at all.. You started a discussion that is necessary.. There are some real USABILITY issues here you discovered that need solutions..

I don't think you misunderstood anything.. You discovered what any good QA Analyst would have pointed out.. So BRAVO.. that is the point of testing.. to discover gaps, errors and omissions. This discovery will lead to solutions..

I feel like I'm responsible for mucking up Anne's support thread for Responsive Stirling with my questions. By no means, did I mean to say the template was junk. Anne has some of the best templates available to the zen-cart community, IMO.

That being said, maybe I misunderstand the intent of responsive templates. I am not a coder but have enough technical ability to make minor tweaks if I have an example of similar functionality.

My real job is to fabricate products for sale to our customers and to optimize our online store by making it as easy as possible for customers to spend money. We have learned that online shoppers seldom read help files, FAQs, etc.; thus requiring everything to be as intuitive as possible.

One thing that I have found by allowing a single customer using an iPad to look at the responsive template installed in our sandbox is. We have already discussed the the Hover vs On-Click issue....

• On the first step down from full desktop, there is no HOME button and the customer could not get back to a known starting point. This seems to be common to every responsive template that I've viewed. I'm guessing that this screensize step is used by MOST tablet devices. That WILL affect how customers spend money. If it is a issue of screen space, then maybe something needs to be sacrificed for the sake of HOME. Most of our customers do not understand breadcrumbs and don't even see them on the screen.
• On the smallest width, the customer could not find a way to see the store categories. So far, no one that I have shown has been able to figure that the button with 3 horizontal lines is the button to click to see the entire store categories. Again, this seems to be common to all responsive/mobile templates. That also WILL affect how customers spend money. If this icon is considered to be a universal standard, like a rabbit/turtle for speed, well, our customers have not received the memo yet. I don't know of a better icon.

Today's figures of our website stats:

• 67% of mobile devices are iPad, iPhone or iPod.
• 98% of sales dollars completed from mobile devices are iPad, iPhone or iPod.

I can only surmise that the sales dollars are not closer to the proportional figure due to less than optimal user experience with website functionality. Be it due to specific browser or basic website functionality, your guess is as good as mine but responsive templates on my Android phone do not function as expected, nor do responsive templates on my Windows 8 tablets (Pro or RT). That might change after tomorrow's update to 8.1.

[rbarbour]

You are right.. There is no code TODAY that detects devices correctly.. but clearly times and things are a-changing.. there are already frameworks being developed to close this gap..

I will believe it when I see it, there has never been a universal code for the far less "Browsers" being used.

This would imply that somehow the manufacturers of the world are all going to agree to device specific resolution and browsers. What a monopoly. Will never happen IMO.

So yes I asked are media queries enough?? they aren't.. Browser screen size is not enough to determine what is and is not presented to a site visitor.. So yes you get no disagreement from me that TODAY design (responsive and otherwise) needs to design or code for the majority of devices, but I see signs that the gaps between web browsing using these devices will have viable solutions in the NEAR future. Technology allow designers to take advantage of the best of both desktop and touchscreen devices isn't far off though IMHO..

I disagree and many world renowned web designers would also.

Media-queries do exactly that - present different content layouts based on browser size.

Back when I started designing using javascript, a fallback using CSS was always implemented (why?) because back then non-javascript users were of the majority. If one is going to use media queries and a responsive design for presenting content correctly in all devices. One should design for the smaller devices and their features first, meaning using onClick instead or as a fallback to onHover.

It is possible for I posted a linked example using the original templates Mega Menu in question.

However this still leaves open the question on how to FIX the mega menu to resolve the gap in these devices that RixStix has pointed out.. Yes, convert hover to click.. great.. I am not seeing HOW to do this (and I've been messing around with the mega menu code to get this to work), and I'm sure I am not the only one who would just like to see a usable mega menu that works with hoverless devices..

It it as easy as I say it is, check the original templates support thread, I have also emailed Anne the code used I would expect updated templates to implement this onClick fallback for the whatever % of devices that will use it.

Crystal - @DivaVocals
There aren't many individuals that I even consider their advice, opinions or arguments to be worth validating but yours always seem to be "in truth" to a higher percentage than most.