Responsive Classic (built in to Zen Cart v1.5.5) [Support Thread]

[schoolboy]

In all honesty I'm not a great fan of the picaflor azul templates for all sorts of reasons, which is a personal choice. I find they often don't work quite as well as they should and particularly from a design and layout perspective. So I don't think there is anything wrong with writing my own template to suit my requirements.

There's a lot I dislike about the "style" choices picaflor have made which is embedded into practically all their templates. But "style" features are very easy to remove and/or reshape. First thing I do with any template I get is to remove features that don't play well in the desktop/mobile "crossover". Mobile compliance is now more important than Desktop compliance, but template authors still seem to build for desktop, then bolt on bits that help it render on mobile.

It is believed that by 2020, almost 90% of interactive/transactional activity will happen on mobile devices - certainly in B2C environments, which is where most website owners using opensource platforms are active. Hence Google pushing the AMP protocol. Sites that are heavy in JS and CSS are already struggling to get to Google's preferred target of under 2 seconds for pagespeed.

Also, the way people use websites (especially for making purchases) has changed dramatically in recent years. With Google now increasingly capable of presenting search results which more and more accurately reflect what someone is looking for, people like to get straight to the page where they see on offer, exactly what they are looking for. So when they land on that page, the faster, simpler and easier it is to use, the more likely they are to not only stay-on-page, but also to expand their visit while they are there. They have no time for irritating banners, popups, slide-outs, and all these other techniques that remain popular with site owners (and developers - who are usually not very good at marketing and selling, and who know little about stuff like UX).

Templates should therefore achieve the following:

1. Be designed for mobile use, first and foremost.
2. Avoid using features that rely heavily on css and js.
3. Incorporate semantic data-markup, so search engines can more accurately determine the nature AND INTENT of page content.
4. Be clean and simple, with the main feature of any rendered page being largely what the visitor is expecting it to be.

Since we simplified all our websites (and those we continue to support for other customers)we have seen:

1. Bounce rate drop to BELOW 2% on almost all sites. No site has a bounce rate over 5%.
2. Time-On-Site (average) move to 6 minutes from 2 minutes.
3. Since 2013, a 450% increase in return visits. (And corresponding repeat/new orders).
4. Average pageviews (per session) increase from 7 to 22.
5. Order value increases of between 40% and 60% (depending on the site and products being sold).

So... to us... it's not really about the template as much as it is about making things cleaner, faster, easier and more focused, for the end user. That is our only benchmark for whether the technology is "good" or "indadequate".

We try lots of templates (both in their original form and customised) and if they don't first achieve a pageload speed of 2.5 seconds or less across a series of tests, we toss them out. Then, those we keep must achieve under 2 seconds. We use pingdom and gtmetrix as our main testing platforms for this purpose - not Google, who has "ulterior motives" in reporting "underperformance".

[Website Rob]

i wasn't asking for a style guide by the way, just the html 5 elements that was added into the code to bring mine in line with html 5. it doesn't matter too much, i can add basic html 5 elements if i wish though.

Whether it is called a; Style Guide, Documentation, Overview, etc., they all refer to some specifics of what is being used--which is what you were asking about. The thing is to "know" HTML5 so you can spot inconsistencies or errors whenever you see them and/or add code where you see fit.

As to what template you should "stick with" or use, it should be according to your needs. If it is correctly coded and you can use it start with it, then adapting it to your needs is a lot easier.

[DrByte]

Just wondering, is there a full list somewhere of all the HTML 5 Elements/Tags added to responsive classic?

Do you mean a list of every place where HTML tags like <input type="phone"> or <section> etc are used? Please explain why that would be useful.

Yes, and it would be useful as I have built my own responsive template and would like to add in the HTML 5 tags where possible otherwise it means starting from scratch again. Basically so i can edit what I have built and bring it up to date with HTML 5 Compliance.

I am basically asking for a list of what was added to the previous HTML 4 Templates in order to bring them up to HTML 5 Standards.

my question. Which was, Just wondering, is there a full list somewhere of all the HTML 5 Elements/Tags added to responsive classic? It would be good to have basically as a cross reference.

Simple answer is: no, there's no list of instructions on how to build responsive_classic from scratch.

But you're asking 3 different questions here:
1. "list of all HTML 5 elements/tags" (which is ambiguous as it's unclear what a list of tags would look like or be, or how it would be used)
2. "add in HTML 5 tags to my template" (again, ambiguous)
3. "a list of what was added to the previous HTML 4 Templates in order to bring them up to HTML 5"

Question #3 makes a lot more sense, but really isn't answered by #1 or #2. There isn't a list of "things added" because it's more about "things changed".

But here's the answer to your question:
Since it's finally more clear what your end goal is (update your own template to match the HTML5 template that comes default with Zen Cart), you can get a clear visual indicator of exactly what was changed, and decide whether to incorporate each change into your own template, by:
a - unzip a copy of v1.5.4
b - unzip a copy of v1.5.5 in a separate directory
c - use a text-compare tool like WinMerge or AraxisMerge or BeyondCompare to compare the template_default folders between both sites
This will give you a complete thorough list of all the changes made to bring things up to HTML5
(And if you do a 3-way compare you can slap your template alongside and literally click to copy things across where you identify changes that need to be brought into your own template files.)
There are a few files in /includes/modules and /includes/languages that were also touched, so a similar compare there is prudent.

And then if you want to take it a step further and see what's different between template_default and responsive_classic, you can simply compare those two template directories inside your v1.5.5 directory. Then also look for all the "override folders" where there's a "responsive_classic" subdirectory, and note what's been customized in there ... in the /includes/modules and /includes/languages/ areas.

The visual list will be far more useful than a text file listing a bunch of random html elements out of context.


And, frankly, this visual compare is exactly what you should do every time there's an upgrade anyway, if you want your customized template to be compatible.


If you're interested in the month's work I did to review and implement the changes, you can see all my code commits during that timeframe here:
https://github.com/zencart/zencart/c...81e6d0e62f9148

[Nick1973]

Ok no worries Dr Byte. I'll do what you said then as that basically gives me an answer. And I'm sorry for not sounding more clear. The cart was built on 1.5.4 so I do need to upgrade it anyway. It's taken me over a year to get it to the stage it is at, basically because I am dealing with clients and do not have much time to work on my own work. And that is also why it has fallen behind a little. I gathered it would be easier to continue on 1.5.4 and then deal with upgrades afterwards. I think Website Rob and Schoolboy went totally off track, but then perhaps they didn't understand what I was asking. In answer to Schoolboy regarding page speed though, my template is CSS driven and the only graphics such as PNG's and Jpegs are literally product images and the logo. I haven't tested page speed but I'd have thought as it relies heavily on CSS to render buttons, gradients, backgrounds, etc etc (note: no graphics such as PNG's or JPEGS applied into CSS) it would be pretty quick. And of course anyway, page speed is dependent on the end users internet connection. Google might well be going down that route now, but as broadband gets faster for everyone then people want more graphics and video which takes up more bandwidth so while I understand your point regarding mobile and page speed, you only have to look around at other platforms to see how heavily they make use of graphics etc...so it would not surprise me if google changes their mind. Certainly alot people I speak to have a tendency to use their mobiles for browsing on the go, and make purchases from their Laptop or Desktop PC. Partly because of security and also because certainly for some items a mobile screen simply isn't big enough to view a product in detail. I'm not saying I'm ignorant to mobile users, but while it is a trend at the moment, it doesn't mean to say the trend will last.

Anyway I didn't come on here to be told what is right and wrong, for which we could go on forever arguing about who has the most knowledge and talking about the weather etc, I came on to ask a question, for which Dr Byte appears to have answered and for that I am greatful for.

[marton_1]

I was also unaware that Google is now trying to be the Code Police and enforce their version of code review on people.

Google do a lot of things that I am less than happy with but they bring the majority of visitirs to my site so I find it pragmatic to do what keeps them happy :)

Hence Google pushing the AMP protocol. Sites that are heavy in JS and CSS are already struggling to get to Google's preferred target of under 2 seconds for pagespeed.

I am currently on V155d and I find the performance is good; I tested my main pages with pingdom again today and they all show up in 1.5 or 1.7 seconds.
To be honest I could do more to optimise image sizes but not sure how much improvement this would bring :)

[marton_1]

I am using v155d Responsive classic.

I just had a problem in the mobile view (tablet and desktop OK). Some of the small icons show up as full screen width which is quite ugly, examples are the free shipping icon in the product listing or the waste bin (delete) in the shopping cart.
I could fix this by adding a class to each image icon using "class =" and setting the class size in responsive mobile css.
Probably an impossible question to answer but any idea why this happened?

[schoolboy]

I am using v155d Responsive classic.

I just had a problem in the mobile view (tablet and desktop OK). Some of the small icons show up as full screen width which is quite ugly, examples are the free shipping icon in the product listing or the waste bin (delete) in the shopping cart.
I could fix this by adding a class to each image icon using "class =" and setting the class size in responsive mobile css.
Probably an impossible question to answer but any idea why this happened?

The recommendation is that images are sized appropriately, and then the size is declared in the <img src> tag.

So... if you have an image called "logo.jpg" 150px wide X 50px high. then it needs to be declared at that height and width:

<img src="images/logo.jpg" width="150" height="50" />

Google (and many others) do not like images to be RE-SIZED by the tag declarations. They like the declarations to be in-sync with the images actual dimensions.

[schoolboy]

Also, it's better to use images that can be compressed using a good image editor (adobe photoshop, for example). PNG images cannot be compressed, whereas JPG and GIF can.

I avoid PNG for this reason, and I avoid GIF as it can make images look "bitmapped" - and I use JPG images exclusively, all worked using Adobe Creative Suite (mostly Photoshop).

When you have your image at the dimensional size you need (150px X 50px), compress it down to as small a file-size that you can before it starts to look "smudgy". If you keep to JPG formats, you will be able to achieve very good compression.

[marton_1]

The recommendation is that images are sized appropriately, and then the size is declared in the <img src> tag.

So... if you have an image called "logo.jpg" 150px wide X 50px high. then it needs to be declared at that height and width:

<img src="images/logo.jpg" width="150" height="50" />

Google (and many others) do not like images to be RE-SIZED by the tag declarations. They like the declarations to be in-sync with the images actual dimensions.

Thanks for your answer, for example, my free shipping icon is like this

<img src="always-free-shipping.gif" alt="Always Free Shipping" title=" Always Free Shipping " width="94" height="54">

Why it shows up full screen in the mobile view I have no idea.

[schoolboy]

Thanks for your answer, for example, my free shipping icon is like this

<img src="always-free-shipping.gif" alt="Always Free Shipping" title=" Always Free Shipping " width="94" height="54">

Why it shows up full screen in the mobile view I have no idea.

INSPECT the actual image... what is its REAL size? The HTML <img> tag is telling it to show at 94 x 54 - but it could be 94000000 X 54000000 in reality.

The ACTUAL size of the image must match the DECLARED size.