How to best design to take advantage of responsive grid? Menus, etc. [#1182950]

Hi fubhy, anyone else willing to provide feedback:

I just installed the beta1 and everything is working fine. I find myself kind of stuck with how to proceed on my site design. I am hoping that one or more of you would be willing to look at my site and give a couple (or more suggestions). I would really appreciate candid feedback. I am new to both Drupal and Omega.

I don't have any real content on the site yet, but the URL of a typical page can be found at:

[no longer relevant or available]

The site will eventually contain about 500, mostly PDF resources (a few mp3s). The taxonomy hierarchy is pretty deep, so I thought using a Taxonomy Menu in conjunction with the Superfish menu would help this. So, I had to make the fontsize get progressively smaller as the browser resizes. But this clearly does not work when I get down to mobile size.

Would I be better off using just menu blocks: say in the way that the Drupal website approaches its hierarchy for each of the main, top-level categories (Get Started, Community and Support, Documentation, etc.? I am willing to drop the whole Superfish Menu approach; perhaps using Books for a lot of my organization at the deeper, leaf level's of my hierarchy.

I love the Omega system and do appreciate all the work being done. Though new to both Drupal and Omega, I would like to proceed in direction that will properly use it's strengths, perhaps serving as an example for others.

I know I'm asking for a big favor: thank you for anyone willing to provide it. I'm primary afraid of continuing too far in one direction only to find I will need to start all over when I have a better understanding of what both Drupal and Omega are capable.

Kevin

Comments

Comment #1

kevin-bcr CreditAttribution: kevin-bcr commented 8 December 2011 at 14:55

Assigned:	kevin-bcr	» Unassigned
Status:	Closed (works as designed)	» Active

PS: It may help you to give me feedback if you see what the current site is like, the one I intend to replace with this new Drupal-Omega site. The current site, to be replaced [no longer available]

Kevin

Comment #1.0

kevin-bcr CreditAttribution: kevin-bcr commented 8 December 2011 at 14:56

Issue summary:

View changes

Link was no longer valid, relevant, or available.

Comment #2

fubhy CreditAttribution: fubhy commented 8 June 2011 at 22:49

Hello Kevin!

On the responsive CSS themeing question:

The font resizing works on your mobile version too, you just need to place that font-size on your mobile.css too. The mobile.css is loaded first and gets overridden by any of the styles that follow (and are active...). So on the mobile layout you get the font-size from the mobile.css. On the narrow version you get the font-size from the narrow css file, etc.. However I think that the font-size that you chose for the narrow version is already a little bit too small!

On the menu question:

Superfish menus in general are ok but please consider that you are designing a mobile first layout here and therefore (since you are already putting so much effort in making it responsible and well-working for mobile devices) you should really make sure that those also work for touch screen devices. Not all dropdown menus work well with tablets or such as some of those have issues with the touch screens.

There is a second disadvantage, especially in your use-case: You are saying that your taxonomy is going to be pretty deeply nested. Actually it already is quite huge (considering you plan on using it in a menu). The disadvantage here is the HTML Output. Please remember that for EVERY single site that someone loads on your website the entire menu tree gets printed into your HTML Output. This will be a huuuuge bunch of HTML Markup and therefore might increase the loading time of the website (especially on mobile devices) quite noticeably. You should consider re-thinking your whole menu and page structure and maybe consider splitting your content into main categories instead of showing the entire tree on every single page. This usually makes much more sense! Additionally you should consider building your content based on the Books module since it looks like it indeed fits the idea behind the books module. Taxonomy is nice and you can still use it for your book pages but in an even more advanced way (multiple taxonomy tags per books page, etc.). Taxonomy menus are great but, speaking for me, they should rather be used for browsing through articles or similiar content that is stored in taxonomy based archives. You, however, seem to be (ab)using (?) that to build one menu item per page while I rather see the taxonomy <=> content relation as a (N <=> N) relation (multiple contents can have multiple taxonomy terms). Correct me if I am wrong, but from clicking on a few of those taxonomy terms I always just saw one node attached to each of those terms. I, myself, would not use taxonomy for that! Give the books module a try!

You could, for example, build a main menu that just lists the main categories and then (upon visiting that category) you get a (sidebar? secondary horizontal menu?) that can then very well be based on a superfish menu OR something else (like a menu tree that can be expanded or such). That way your content is far more structured and also much easier to navigate! Imagine a user on a mobile device, trying to browser through a 8 level deep superfish menu with his index finger ;).

I hope this answers a few of your questions.

Comment #3

kevin-bcr CreditAttribution: kevin-bcr commented 8 June 2011 at 23:56

Thank you, fubhy -- very helpful.

You are definitely correct in assuming that I had a one-to-one relationship in mind between my main taxonomy and each menu entry. I see what you mean about not utilizing it. So, is the key to using multiple taxonomy terms per article that I would create a field for my content type that permits multiple entries?

You said, "Please remember that for EVERY single site that someone loads on your website the entire menu tree gets printed into your HTML Output." Do you mean each of the taxonomy terms (say, about 150 of them the way I was going about it), or, even more than that, parts of each of those pages? One way or the other, I hear your appraisal that it would be huge. Then, it probably won't be that much better, will it, to have a Superfish menu even for each of those main categories?

So, I have seven or eight top level categories. My font size for the narrow.css was determined by the need to make all of these, as well as other sidebar content, fit horizontally. I'm assuming anyone using the narrow size, would most-likely be viewing on a 600x800 size monitor (or, tablet?), so the text would still appear larger on their device because it was also at a different resolution. Is this a false assumption?

Yesterday was the first time I've ever used an iPod. That was definitely educational. Given what you've said, it seems like I need a vertical, one-level form of my main menu for the mobile size, then a horizontal, one-level menu for the narrow, normal, and wide -- but perhaps one that has to accommodate two rows when I'm at the narrow size? Then, when I clicked on one of the main menu links, for mobile devices, my users would immediately see the next level of menus and, perhaps, any articles that appeared at that level. Or, are you suggesting that at this point they would start seeing a listing of all Books in that top-level category. Given the nature of my content, sometimes it makes sense for the book to begin at what was the 3rd level of my hierarchy, sometimes at the 4th, the 5th level. So, would it be best to force each of these Books to be listed immediately after reaching this first level from the top menu?

Whew! I ask a lot of questions, I know. This will really help me overcome my "designers block." Thank you, again, for being so very helpful.

Kevin