Ok, this will get yer knickers in a twist. Lately I've been looking into concrete5 CMS as I might need to make a site for someone. Some of the custom themes for concrete5 (and the default theme for SilverStripe, which I also checked out) use an interesting method of dealing with responsive menus.
Instead of swapping it all around into little buttons with icons, they just switch to a vertical click menu that's at the top of the page. This is very neat and clean, and allows for as much menu content as you want. Live examples are available on the links below.
Concrete5 custom theme demo (http://c5themes.metaphorcreations.com/?theme=neuron)
SilverStripe default theme demo (http://demo.silverstripe.org/)
Frankly I think this is a better way of dealing with menus than the current Elk system.
Is that sufficiently annoying? :D
The second one isn't bad but the first looks like a full desktop site on my phone. Tiny tiny text in a very wide layout.
The one menu as on the silverstripe site is nice in that I don't have to guess what the tiny icons actually mean. But every action being two clicks would probably be annoying once you know what the various icons do.
The coding of the first site might be interfering with the coding of the theme, since the theme is embedded in another page which may have the wrong doctype meta tag (haven't checked). It should be easy enough to get it working properly on a real site. You can see the effect if using it on desktop and pulling the window size around.
I think the best point about this sort of menu, apart from not having to guess what buttons do what, is that you're not limited on menu content. It should also be simpler coding.
Oh and probably simpler customisation too.
I agree there is definitely an upside to it. (Not even mentioning less font icons is a good thing. :P )
It always seems odd to me that when I turn my phone to landscape mode I can do more things than in portrait. Like say the admin button disappears in portrait.
Actually Elk already does drop menus. Most of the menu icons themselves just drop menus down. How hard would it be to make the top level menu be a drop down in small screen mode?
Should be very easy, which is why I said something along the lines of those demos would probably require less code. Should automatically be click-to-open on small screens too, since hover menus aren't much chop on touchscreen.
TBH, given that mobile-first (or at least touchscreen-first) is the way to go these days, I think the whole menu suystem is far too bloated. The whole reason Superfish* was used to start with is that I talked the SMF crew into using something that would improve the accessability of their drop menu system. Now Elk has Superclick as well as Superfish, and you also have the menu changing to icons with all the rigmarole that involves.
What Elk needs (IMO) is for someone to fork it and clean the menu system up. Just give it one simple and responsive system that works well. That means ditching the sidebar/droppy option too.
*Although Superfish is pretty good for improving general usability of hover-activated drops, it's still far too bloated IMO. Really needs a complete revamp.
You say fork it because this discussion has been had before and this direction has been rejected for Elk?
Yup. Although "fork" perhaps sounds more severe than it really is, since the sort of changes that would be required would not affect the rest of Elk. It'd basically be a (fairly substantial) mod instead of a full-on fork.
the menu needs an overhaul, yes.. There are far to many options: dropdown vs. sidebar, click vs. hover.... But that's something we should IMO address in 1.1 or 2.0, definetely not in 1.0.
The problem with all those menus is: You'd need at least 2 touch gestures: one touch for opening the menu, another one for selecting the action, e.g. recent posts.. That's why I personally prefer our current icon menu variant, just one touch for the common actions.
Yeah but if you use the FastClick or tap.js plug-ins then there's no 300ms delay on touch, so you could double click so fast that it actually wouldn't be inconvenient in practice. It'd become just as fast and easy as doing a double click with a mouse on desktop. And it's more readable for anyone not familiar with the software. No guessing about which icon does what. And there's no restriction on menu content, and no shenanigans swapping icons and text around. And no problem with icon fonts breaking if people use their own browser settings. Etc, etc.
ETA: I've come to much prefer click droppies instead of hover droppies on desktop, even though I have to do more clicks. They're just so much better behaved than hover drops and the extra clicks are no real drama.
I noticed that the hover drops here have had the mouseout delay pruned back to try and get better all-round behaviour, but it's now so fast that it largely defeats the purpose of having it in the first place (better a11y for anyone with less than perfect tracking skills). Use click menus = no problem. Always predictable and well behaved.
TBH I don't remember any similar proposal because otherwise I'd have said "do it, it's what I was thinking since a long time".
Anyway, since this is done with javascript, it shouldn't be too difficult to create an addon that overrides all the existing settings and implants this system. ;D
ETA: and that last bit means I agree with TE that is now a bit late to change that too (unless we want to take "beta forever" route... :P
Btw this isn't needed in chrome mobile because they eliminated the 300ms delay months ago for web pages that declare a width to be responsive. (Device-width)
mmm... well, what you suggested there look slightly different from what I read in the OP here (here seemed more related only to mobile/low-res converting the menu to a "click here to see the menu" kind of stuff), but okay.
I was not against click, see reply #24, I like hover but I'm not against click (at least not to the level Norv was, I may consider them an annoyance the first times but I would get used). :P
TBH, the main one may have to behave a bit differently from the others, because it is different (for example I'd like to have the click only on the arrow and not on the name, just because 90% of the times I just want to go to the main stuff, the only times I use the entries in the droppy of the main menu is for profile).
And (as I told you already) it uses depreciated and outdated jQuery, Really you should consider making it a menu project so others would use it and provide broader testing and usage cases, like superfish or superclick, (where Joel even purchased various touch hardware to test it on instead of just saying yuppers it works everywhere). To many menu systems out there that are nothing more than demo's with no support and no real testing.
Yes, how dare anyone have, or provide, an opinion on what they like, specifically if its now what you want. When that happens, the best course of action is to proclaim all else bloat :-\
Agree with what TE said about them and look forward to what can be done with them in 1.1 ! Or if you feel its impossible to contribute due to things like, gasp, someone may say they like drop menus, then you can fork the project, change the menu, and call it yer own.
@Ema: What main stuff?
It uses jQuery that works for the version of jQuery that site is running. Obviously it could be altered for different versions of jQuery. That's not a big deal.
Well it's been running live for yonks now, with people using a range of touchscreen devices, and nobody seems to have a problem with it. But sure, it could probably be improved, which is why I suggested combining it with tap.js.
So you don't think the current system is at all bloated? Ok. Fair enough.
I don't mind people having an opinion, but you seem to mind me having one. :P Yes, I think things have become ridiculously bloated, and that one good menu system should be perfectly adequate. It's an opinion. It seems to be an opinion shared by most other projects, so I doubt having one good system would result in Elk being regarded as unusable.
Like I said, it's probably worth playing with as a mod for 1.0. I've said that a couple of times already.
ETA: Although Superfish and Superclick work, they try to do a lot of stuff that Elk doesn't need them to do. This makes them far more complex than required. Examples are extra js for adding drop menu indicator and various other things.
Also, as it turns out using jQuery for animations on mobile isn't as quick and clean as using CSS3 transitions, so that's another avenue for improvement (yes, applies to my code too).
Come to think of it, the best solution, if anyone wants to keep a hover menu option, would probably be to ditch javascript entirely and just rely on CSS3. With XP being dead and buried next month, IE8 usage will probably decline significantly and almost immediately. That means any browsers worth worrying about will be able to do mouseout delays and whatever without any js at all.
Question: what does Elk do about tablets? I know you have the smartphone icon-based menu for small screens, but what about tablets with large res? Do they automatically go to a click menu or do they currently default to the hover menu?
ETA: Seems to me the current system is plumbers crack about in a way. It developed piecemeal from the CSS2-only SMF 2.0.x drop menu system, with more and more stuff added on as time went.
Given that things are supposedly touchscreen-first these days, which really requires click menus, and given that some very sane and intelligent people (not mentioning any names or projects) actually prefer click menus even with mouse and desktop, as far as I can tell the best way of dealing with it would be to make click menus the default. Naturally these would have full CSS fallback in case js was disabled for any reason, which means that if anyone does want to keep a hover menu option, all it would have to do is disable the js on the menus.
I replaced all of my painfully written js from menubvode a few weeks ago, and it felt liberating. There's so little you can do in js that css3 can't do with transition tricks!
Menu code, not menubvode. Damn spell checker not doing its job...
Yeah but CSS3 is only good for hover drops. Still need some js for click drops.