Sneak Peek: OpenCart 1.5.0 *ALPHA*

marc_cole wrote:

For those not sure about mega drop-downs...

I, for one, cannot stand drop down menus. They may look nice, but anything that covers up information on a page, unless it is specifically clicked on, is a bad idea. I hate it when I'm browsing a site and accidentally move my mouse over one of those menus and something else pops over what I'm looking at! ("What??? Who said I wanted to see what was under that menu???)

I agree, mega drop downs can use up a lot of screen estate.

I still prefer conventional drop down menus as a good compromise, see e.g. http://www.derrys.com/retail/

Chones wrote:For those not sure about mega drop-downs, Jakob Nielsen, THE usability guru, gives them his seal of approval, and thinks they are much better than drop-down menus:
http://www.useit.com/alertbox/mega-dropdown-menus.html

I knew nobody would read it

marc_cole wrote:I, for one, cannot stand drop down menus. They may look nice, but anything that covers up information on a page, unless it is specifically clicked on, is a bad idea. I hate it when I'm browsing a site and accidentally move my mouse over one of those menus and something else pops over what I'm looking at! ("What??? Who said I wanted to see what was under that menu???)

Ok, so since you didn't read Chones' Nielsen links, here's the rundown

Jacob Nielsen wrote: the timing should be:
1. Wait 0.5 seconds.
2. If the pointer is still hovering over a navbar item, display its mega drop-down within 0.1 seconds.
3. Keep showing it until the pointer has been outside both the navbar item and the drop-down for 0.5 seconds. Then, remove it in less than 0.1 seconds.
Exception to #3 - solve the diagonal problem - sense when a user is moving the pointer from the navbar item to a destination within the drop-down. When the pointer is on such a path, the drop-down should remain visible.


Accessability

Even if coded correctly, mega drop-downs can cause problems for low-vision users who use screen magnifiers to enlarge tiny portions of the screen. (The same issue impacts iPhone users and other users of zoom-capable mobile devices.)

improving the accessibility of mega drop-down menus:
Simple: Don't bother making the drop-down itself accessible. Instead, make each top-level menu choice clickable, leading to a regular Web page where you present all drop-down options in plain, fully accessible HTML.

Don't get me wrong. I won't be using mega menus for a long long time - my customers aren't there yet...I need to have simplicity even if the cost is efficiency. Also, top menus don't suit me because I have many top level categories...

However, as Q said earlier, Categories left menu module isn't going anywhere, and the top mega menu will be a module so you can switch it off if it isn't appropriate for you

Qphoria wrote:I like this theme:
http://www.tradetang.com/

would be a good base and has another cool hover menu with separation by subcat

At the very least this menu solves the issue of uncertain number of top-level categories - whether you have 3 or 25, this can work for you.

gocreative wrote:The least they could have done is made the list alphabetical.

In 99% of the cases, alphabetical sorting is a stupid thing to do. You sort by volumes, importance, or better still, run card sort tests. Alphabetical sorting has any number of problems, not the least of which is the words you use are not necessarily the words your customer will use. Also, how do you implement alphabetical sort on multilingual sites?

I think one thing is clear... everyone has different preferences for menus so the megamenu will need to be made modular so that it can be disabled/modified easily. It is hardcoded at the moment, against my wishes. So that is something we will have to do.

Purebeads wrote:I think the stars shouldn't show unless a product actually has a review. Otherwise, I'll end up with all my products having 5 gray stars under them, and that would look awful.

You should be able to disable reviews altogether - they should be a module, as should specs

What does Daniel use for the slideshow?

I quite like jShowoff (http://ekallevig.com/jshowoff/) - it is flexible, configurable, pretty and intuitive...

If it is possible to add creating pdf catalogue for the products, and to make search suggestion in search box. I think they are important features

Something ate my post, so I apologize if this is double posted.

Qphoria wrote:I think one thing is clear... everyone has different preferences for menus so the megamenu will need to be made modular so that it can be disabled/modified easily. It is hardcoded at the moment, against my wishes. So that is something we will have to do.

As long as there is something in the category module's controller files that just lets me spit out the categories into an unordered list, I as a template author will be happy, as that allows me to make basically any type of menu I want (or atleast some sort of for loop in the template file that allows me to do so).

The problem I have always had with hardcoded modules is it encourages other module developers to follow the same practice, which is wrong. They start including the classes and containing html from the default theme, instead of just the markup for the content of their theme. I strongly think this is the WRONG way to make modules yet it is how most developers seem to currently be doing it (have only downloaded some free modules, so I obviously can't speak for everyone).

Example: someone makes a module to display a list of social bookmarks and inside the module's template file they have the same containing classes from the default theme such as div class="box", or the dreaded div class="left, right, center" mess that is currently around. Instead the module's template files should just be the list of social bookmarks. In a custom theme I'm more likely going to use my own classes to put modules in so that they can pick up the styles to match my theme. Or, checkout some WordPress widgets. Most of them are just basic markup, and if they do include special classes of their own, they package them up with their own stylesheet if its important for them to look a certain way (or at least some documentation explaining).

I hope that made sense.

My initial impression of the megamenu was that it was excessive to show all sub Categories across the navbar when a single Products option could have sufficed - sub Categories would then appear in the drop-down itself. See Aria's 'quickfind' example to see what I mean +they've also retained a left nav option. Only obvious difference I can see which may prove contentious is that their design is a full screen width concept & therefore there's plenty of room for this.

http://www.aria.co.uk/

ps - has someone deleted/replaced the demo's navbar content?

sooskriszta wrote:What does Daniel use for the slideshow?

I quite like jShowoff (http://ekallevig.com/jshowoff/) - it is flexible, configurable, pretty and intuitive...

Believe it's this:
http://nivo.dev7studios.com/

sooskriszta wrote:

Purebeads wrote:I think the stars shouldn't show unless a product actually has a review. Otherwise, I'll end up with all my products having 5 gray stars under them, and that would look awful.

You should be able to disable reviews altogether - they should be a module, as should specs

You can already disable reviews as of 1.4.9

sooskriszta wrote:What does Daniel use for the slideshow?

I quite like jShowoff (http://ekallevig.com/jshowoff/) - it is flexible, configurable, pretty and intuitive...

Currently it is nivo. This is another point, the banner module code should be in the banner module, not have its own section under Design for this same reason. A banner is a module and should be configured like one, then people can make their own banner modules: banner_jshowoff, banner_nivo, etc and all the code will be part of the module

gocreative wrote:

deeve wrote:My favourite example to date has to be this one but I understand mootools can cause numerous conflicts with jQuery [they do also have a hover version]:

http://blog.medianotions.de/assets/demo ... rdion_1.2/

There's a jQuery version as well:

http://jqueryui.com/demos/accordion/

actually there is one built into jqueryui which The new theme is using extensively, so it should be trivial to create a category module using it.

ikhlief wrote:make search suggestion in search box

I know Daniel has expressed interest in this before, and jqueryui which he is using does have an autocomplete function in it, so I would imagine this will get done. If not I'm sure there will be a mod out for it rather quickly as it will be fairly easy.

hbuchel wrote:inside the module's template file they have the same containing classes from the default theme such as div class="box"

not really sure what you are expecting mod makers to do. It makes perfect sense for them to use the standard box class as in 99% of ecommerce applications you want all your modules to look the same and have consistency throughout your site. By reusing this standard class it allows the module to look the same as all the other modules and have consistency so when you create your new theme and stylesheet you only have to change the box class once and it applies to every one. If you absolutely need that box to look different you can create your own tpl in your theme folder which may be a bit of a pain, but when you are in the minority you sometimes have to deal with things like that.

Xsecrets wrote: not really sure what you are expecting mod makers to do. It makes perfect sense for them to use the standard box class as in 99% of ecommerce applications you want all your modules to look the same and have consistency throughout your site. By reusing this standard class it allows the module to look the same as all the other modules and have consistency so when you create your new theme and stylesheet you only have to change the box class once and it applies to every one. If you absolutely need that box to look different you can create your own tpl in your theme folder which may be a bit of a pain, but when you are in the minority you sometimes have to deal with things like that.

I am expecting module makers to leave the containing div and extra markup out of their module and let the template take care of that. Obviously you are going to have to customize any module's template files anyways to match your theme completely, but I think some general guidelines should be in place. I can give on the box class. Can't give on the other classes like left, right, center, bottom that are specific to just the default theme. I guess I prefer a cleaner, more minimal way of coding. And I'm not sure I'm in the minority for that.

hbuchel wrote:

Xsecrets wrote: not really sure what you are expecting mod makers to do. It makes perfect sense for them to use the standard box class as in 99% of ecommerce applications you want all your modules to look the same and have consistency throughout your site. By reusing this standard class it allows the module to look the same as all the other modules and have consistency so when you create your new theme and stylesheet you only have to change the box class once and it applies to every one. If you absolutely need that box to look different you can create your own tpl in your theme folder which may be a bit of a pain, but when you are in the minority you sometimes have to deal with things like that.

I am expecting module makers to leave the containing div and extra markup out of their module and let the template take care of that. Obviously you are going to have to customize any module's template files anyways to match your theme completely, but I think some general guidelines should be in place. I can give on the box class. Can't give on the other classes like left, right, center, bottom that are specific to just the default theme. I guess I prefer a cleaner, more minimal way of coding. And I'm not sure I'm in the minority for that.

I think you are not looking at it correctly. the left right and center classes are for the headers and footers of the box and used to do the rounded corners. The have nothing to do with box positioning on the page.

Qphoria wrote:You can already disable reviews as of 1.4.9

Ah, sorry! Didn't see the option in Alpha, thought it won't be in 1.5.0

Yes I know they are for rounded corners. My point was that they are not needed as part of the module's template files, not every template uses those classes for rounded corners. And I am not talking about the modules that come packaged with OpenCart. I understand the default template files for those will obviously be coded to match the default template. I am talking about developer's modules that you can download, be they free or commercial, that are continuing to use these extra classes, when I think we should be encouraging these developers to create cleaner, more uh.. adaptable modules.

hbuchel wrote:Yes I know they are for rounded corners. My point was that they are not needed as part of the module's template files, not every template uses those classes for rounded corners. And I am not talking about the modules that come packaged with OpenCart. I understand the default template files for those will obviously be coded to match the default template. I am talking about developer's modules that you can download, be they free or commercial, that are continuing to use these extra classes, when I think we should be encouraging these developers to create cleaner, more uh.. adaptable modules.

so a mod maker should code his module to some undetermined schema to match what you one person may want that you are not even sure of from project to project rather than code them so that most of their customers who are not theme makers can simply upload them and they look right in the default template? Is that what you are saying?

hbuchel wrote:Yes I know they are for rounded corners. My point was that they are not needed as part of the module's template files, not every template uses those classes for rounded corners. And I am not talking about the modules that come packaged with OpenCart. I understand the default template files for those will obviously be coded to match the default template. I am talking about developer's modules that you can download, be they free or commercial, that are continuing to use these extra classes, when I think we should be encouraging these developers to create cleaner, more uh.. adaptable modules.

If I understand it right, you are saying modules should supply the content, not how it looks...