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..

RixStix:

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;

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..

Wanted to recap the salient parts of the other discussion:

RixStix:

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......

picaflor-azul:

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

RixStix:

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 no longer available][Attachment no longer available][Attachment no longer available]

DivaVocals:

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..

DivaVocals:

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.:smile: 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.

picaflor-azul:

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

rbarbour:

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.

DivaVocals:

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)

DivaVocals:

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 :smile:

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.

rbarbour:

Thought complete :smile:

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..

rbarbour:

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

rbarbour:

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..

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..

DivaVocals:

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.

DivaVocals:

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.

DivaVocals:

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.

DivaVocals:

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.

DivaVocals:

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.

DivaVocals:

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.

DivaVocals:

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.

rbarbour:

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..

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.

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..

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:

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.

DivaVocals:

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.

DivaVocals:

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.

Again you get no argument from me about design approach with regards to responsive design.. doesn't change the fact that changes to some of the popular appearance mods is ALSO required to address some of the usability issues if they are incorporated into responsive templates/sites. The Mega Menu is but one appearance add-on with usability issues on small and/or touch-screen devices..

I've implied no such monopoly or even that device manufacturers are going to agree to any universal spec.. what I did imply/state was that technology changes all the time, and software dev has always responded to those changes.. Given the advances in hardware technology and the usability challenges that they bring, browsers, the W3C, and innovators in software dev are responding with ways to address these issues and close these gaps.. these are not all perfect solutions, but that doesn't mean that there is NO solution.. just one yet to be discovered.. frameworks like Modernizer, and even jQuery Mobile are designed to try and close these gaps.. other solutions will follow.. now you may not believe until you see it, and you are entitled to see things from that POV:smile:.. but I look at some of the first webbased apps I was a part of implementing and laugh that the solutions we would use today without batting an eye were seen then as "not doable".. So I know like everything in technology, a change is a-coming..

I saw your posted solution for the Mega Menu.. I am not at home, so I can't look at the code to see, but can your solution also be applied to that categories generator class file used by the Mega Menu (and every other menu module)

rbarbour:

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.

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.

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.

DivaVocals:

I saw your posted solution for the Mega Menu.. I am not at home, so I can't look at the code to see, but can your solution also be applied to that categories generator class file used by the Mega Menu (and every other menu module)

I only applied the javascript to the top level links of the Mega Menu for an example and that was all I emailed Anne. It requires adding a id to the link so I imagine it can be applied to the category_tree_generater file just like any other category plugin.

Surely you don't expect me to test on "every other menu module".

rbarbour:

I only applied the javascript to the top level links of the Mega Menu for an example and that was all I emailed Anne. It requires adding a id to the link so I imagine it can be applied to the category_tree_generater file just like any other category plugin.

Surely you don't expect me to test on "every other menu module". nope.. because I didn't imply or SAY that you should test every other menu module..:smile: I asked about the category generator class file because nearly EVERY dropdown menu add-on uses the SAME class file.. So logically I would think that fixes/changes to the Mega Menu can be applied to other menus modules..

DivaVocals:

nope.. because I didn't imply or SAY that you should test every other menu module..:smile: I asked about the category generator class file because nearly EVERY dropdown menu add-on uses the SAME class file.. So logically I would think that fixes/changes to the Mega Menu can be applied to other menus modules..

I read very quickly, my apologies.

Wanted to bring over a related conversation from another thread to continue the discussion here.. (this was clearly off topic) Seems more appropriate to continue the conversation here..

ultimate_zc:

This is way off topic but it is the direction this thread has taken...

I’m currently working in a theme for Zen Cart using Bootstrap. Building a responsive theme is a little more tedious than I expected. Building it in what I consider to be the proper way. I have built Bootstrap themes in the past following the Bootstrap guidelines which is “hide this from this device, show it on this other device” as in the example shown below:

<div class=“hidden-lg hidden-md col-sm-6 col-xs-12”> <p>Content Goes here</p> </div> ``` > > The html shown above basically says hide it from desktops, display it using half the screen on tablets, display it using the full screen on smartphones. The problem is when it comes to hiding portions from mobile devices using for example the html shown below: > > ```html <div class=“col-lg-6 col-md-6 hidden-sm hidden-xs”> <p>Content Goes here</p> </div> ``` > > The code shown above says display it using half the screen on desktops but hide it from tablets and smartphones. If we are to hide it, why load it to begin with? For that reason a mobile detection script is much better. > > Using Google Code’s mobile detect, I can write the following: > > ```php <?php if (if (!$detect -> isMobile()) { ?> <div class=“col-lg-6 col-md-6”> <p>Content Goes here</p> </div> <?php } ?> ``` > > The code shown above, displays the content on the desktop and keeps it from loading on mobile devices. This makes it convenient when we don’t need large portions of code, javascript or css files that don’t do any good loading on mobile devices. > > As I was thinking about the theme that I’m working on. It is getting a little complicated because of all the bells and whistles that I’m adding to make it themeforest worthy. It seems that adding a truck load of sliders and extra pretty CSS for commerce websites sells... at least there > > The essence of building responsive websites is building sites that basically have not one but three templates, at least. One for desktops, one for tablets and one for smartphones. With that in mind, I realize that there is no need to make things so complicated and here is how. > > Let’s just say that I need to build the product info page. I need to build three designs, I’ll use three conditionals inside my /My_TEMPLATE/templates/tpl_product_info_display.php > > ```php <?php if (!$detect -> isMobile()) { ?> Content for desktops goes here <?php } ?> ``` > > ```php <?php if ($detect -> isTablet()) { ?> Content for tablets goes here <?php } ?> ``` > > ```php <?php if (($detect -> isMobile()) && (!$detect -> isTablet())) { ?> Content for smartphones goes here <?php } ?> ``` > > I could either add the content accordingly or perhaps, call for three different files maybe named tpl_product_info_desktop.php, tpl_product_info_tablet.php and tpl_product_info_phone.php. > > On that same note, I could add new statements into the sql for additional image sizes. Instead of MEDIUM_IMAGE_WIDTH and MEDIUM_IMAGE_HEIGHT, why not DESKTOP_IMAGE, TABLET_IMAGE and PHONE_IMAGE etc. This could be a good idea to use with something like an image handler. There is no use on creating this new sizes if the intent is to serve the same large image. The point is to load a smaller image on mobile devices to make it load faster…

DivaVocals:

I've been doing a fair amount of research lately on the topic of responsive because I am realizing that many of the popular appearance modules need some massaging to make them mobile/touchscreen friendly.. So I do have a question.. It is my understanding that "Google Code’s mobile detect" code will not work on ALL devices.. If this is true what's the stopgap measure??

ultimate_zc:

I use php-mobile-detect and have used it on my mobile theme for quite some time. I have yet to hear from a customer stating that there are any issues with it. I'm not saying that it is perfect. There are entirely too many different devices, models, brands out there to actually test for. There are other free open source scripts available. I'm sure if you do a google search you'll come up with several.

There are also several paid-for scripts which involves adding a code to your site and pay what I considered to be a really big fee for something that to be honest, I have no way of testing for in order to make sure I'm getting my money's worth.

As stated on the site, you can detect specific devices by using case-insensitive pseudo-methods.

Phones

• isiPhone()

• isBlackBerry()

• isHTC()

• isNexus()

• isDellStreak()

• isMotorola()

• isSamsung()

• isSony()

• isAsus()

• isPalm()

• isGenericPhone()

Tablets

• isBlackBerryTablet()

• isiPad()

• isKindle()

• isSamsungTablet()

• isHTCtablet()

• isMotorolaTablet()

• isAsusTablet()

• isNookTablet()

• isAcerTablet()

• isYarvikTablet()

• isGenericTablet()

Operating systems

• isAndroidOS()

• isBlackBerryOS()

• isPalmOS()

• isSymbianOS()

• isWindowsMobileOS()

• isiOS()

• isFlashLiteOS()

• isJavaOS()

• isNokiaOS()

• iswebOS()

• isbadaOS()

• isBREWOS()

Mobile browsers

• isChrome()

• isDolfin()

• isOpera()

• isSkyfire()

• isIE()

• isFirefox()

• isBolt()

• isTeaShark()

• isBlazer()

• isSafari()

• isMidori()

• isGenericBrowser()

By all means, if you come across any other good sources, please let me know.

DivaVocals:

Wanted to bring over a related conversation from another thread to continue the discussion here.. (this was clearly off topic) Seems more appropriate to continue the conversation here..

The google mobile detect code has actually came along way and it is very close to detecting the majority of devices out there.

It would be counter productive to include with any responsive code that utilize media queries IMO for this renders files based on the device.

This would be no different than creating a desktop website template, a tablet website template and a phone website template.

Again you would be managing the code for 3 website templates.

HOWEVER, taking the rules under certain media queries and putting them into their own css file and calling that css file for (specific) devices using the google mobile detect code may be just as easy as using media queries.

rbarbour:

The google mobile detect code has actually came along way and it is very close to detecting the majority of devices out there.

It would be counter productive to include with any responsive code that utilize media queries IMO for this renders files based on the device.

This would be no different than creating a desktop website template, a tablet website template and a phone website template.

Again you would be managing the code for 3 website templates.

HOWEVER, taking the rules under certain media queries and putting them into their own css file and calling that css file for (specific) devices using the google mobile detect code may be just as easy as using media queries.

Perhaps (still not sure of I totally agree with this yet:P..).. BUT.. this might be useful for SOME appearance mods where you might need different flavors of the code depending on the device..

:yes: > rbarbour:

This would be no different than creating a desktop website template, a tablet website template and a phone website template.

I agree with this above.

:shocking: > rbarbour:

It would be counter productive to include with any responsive code that utilize media queries IMO for this renders files based on the device.

HOWEVER, taking the rules under certain media queries and putting them into their own css file and calling that css file for (specific) devices using the google mobile detect code may be just as easy as using media queries.

I don't agree with the latter.

It is true that using a mobile detect script with a responsive design may very well be somewhat of an overkill, however, website owners are much more concern about the look of their site for multiple devices yet when they test, they do so by increasing and decreasing the size of a browser on a desktop site. There is a small percentage of website owners that are aware of the multiple tools to test their site by either visiting actual websites that provide agent switchers or even have the time to install additional extensions to their browsers to test as well.

A website owner and for that matter, their developers are concern with "does it look good, yes, no, move on". To develop a "useful" and fast website for mobile devices, I do not think is enough to use CSS media queries because it only hides the content you don't want shown on the device.

Take for example Bootstrap. For a desktop, I could very well design a product info page with the regular Zen Cart default style or give the option from the admin to use tabs. On a tablet I could do the same, therefore I could use the mobile detection script to load the tabs.js file for both desktops and tablets. As for smaller mobile devices such as the smartphone, tabs may not necessarily be a great idea so I could just give an option from the admin once again between the default or an accordion therefore, for small mobile devices I would use the detection script to load only the accordion.js. Why load both scripts if I'm only using one of them. That is additional bandwidth that the mobile user is using and more time to load risking losing that user.

The same goes for scripts that belong only in the mobile device. There are plenty of scripts that will enhance the performance of the scrolling, touch events etc... Why load those scripts on a desktop if there is no need for them?

In my opinion, a responsive website should use both, CSS media queries and mobile detection.

For the sake of my argument above. Once again taking Bootstrap for example. Lets just say that I decide on displaying tabs on desktops, regular Zen Cart style on tablets and accordion on smartphones.

Using only CSS media queries means loading the same content three times hiding two versions of it. Now that is counter productive.

There are several reasons why in the example above CSS media queries alone may not be a good idea. Lets say that the desktop visitor does not have a fast enough connection, while the website is loading the page content, the user may very well see the display of the content three times making the site look unprofessional.

The website may also be penalized by search engines for stuffing content. Remember the search engines are going to read the entire content. They don't care whether the content is visible or not, it is all about the source code.

If I don't want the same content to load several times on a desktop in addition to the extra CSS and javascript on a desktop, why would I do so on a mobile.

One thing we do agree upon and it is the fact that you are designing three themes and not just one regardless. You have no choice. Perhaps you are designing for more than three if you also take into account landscape and portrait modes.

The same goes for the subject of the thread. There are several ways that I'm aware of to make sites responsive to either click events or touch events. For this instance you may need to totally redesign all of the link tags on the site using jQuery. This is another good example that shows how mobile detection is a handy tool.

By detecting whether the device is mobile or not, we can deliver a better experience to the user by making mobile sites even faster using touch events yet making sure those touch events are not loaded on desktop sites rendering the pages unusables (if that is even a word).