Wedge

Unlike SMF's, which actually has no hover time at all because it's purely CSS driven, I believe there's a fraction of a second in Wedge's.

Does it still work without javascript?

I have a feeling it does, but honestly, the admin panel is somewhere we're likely to be expanding the use of JavaScript in (there is one place I know right now that *needs* JavaScript because of its current implementation) - it's not as if the general forum absolutely requires JS at the moment. The admin panel does have a much lower access rate and can afford to make more demands.

(But you cannot have a menu that doesn't pop up instantly without CSS.)

Cool!  :cool:

Re: menu delay, I'm afraid there's no delay when opening it. There is a delay -- but it is before *closing* it.
I could add a very, very short delay before opening it, but I didn't. (So far, at least.)
Since I wrote the damn thing, let me explain my point of view.
When you open a menu, you want reactivity. The first thing I always do when reinstalling Windows, is getting rid of the stupid hover delay on menus. I suppose people are used to it.
Now, when it comes to Windows, once a menu is opened and you've hovered somewhere else, it stays open until you click something, so I can understand the logic behind it. But in a web page, the menu will auto-close when hovering away. So there's really no loss in usability, just a minor issue with things showing up unexpectedly because you're aiming for a toolbar button.
All right.
Now, the thing that may bother you in SMF menus may not bother you as much in a Wedge menu, because it's a much more evolved menu system. I thought I'd described it in the Features area, but only wrote these two lines:
"- New menu system. Looks great, plays great, uses CSS3 but works in IE6, uses JavaScript but works when JS is disabled. Supports separators. Icons based on the Diagona set."

Okay, so here's what happens who you hover a menu: it starts opening, yes -- but with a fade in, and an animation. The animation isn't of concern here. What matters is the quick fade in. Because it shows up smoothly, it doesn't jump at you, and you don't get the same feeling as you'd get when opening a menu by mistake in SMF.

It may sound silly, but I literally refined my menu tech for years. I spent something like two weeks working on it for Wedge last year, to make it the best I could. I made tries with opening delays, but I found they bothered me when I actually wanted to open a menu item.
So, I guess you'll have to take my word for it, or wait a few more weeks until we make the demo site public.
But it's all thoroughly thought out really. I'm very serious about menus. I even considered using mega-menus at some point, for usability geeks. Tried it all, kept what worked for me.It does, as explained in the feature description. Another thing that I spent a lot of time on ;)

JavaScript is only used for a few things in the menu:
- setting up closing delays (to allow for a user's mouse pointer to hover outside the menu area, then quickly come back in, without having the entire menu get closed),
- specifying the position of submenu items (relative to their owner item),
- adding a shim for IE6 (in order to prevent form elements from being shown on top of the menu items),
- applying a special class to hovered items, so that I can keep a consistent trail of selected elements in the nested levels, i.e. if I'm highlighting an option in submenu level 3, the parent option in level 2 stays highlighted, and in level 1 as well. This can be done in CSS (IIRC, I actually gave SMF the technique to do that, I don't remember whether they implemented it or not, or whether I implemented it myself during my stint in their dev team), but it has limits and I don't like limitations.

So, until the menu JS code is loaded, it works perfectly well, in CSS mode. When JS is loaded, the CSS mode is disabled and we play with the big boys.Well, it does benefit from it ;)Completely agreed.

Thanks for the menu explanation. My only problem with the SMF menus is that it does not go away immediately when you move the mouse away. It stays there. Blocking access to where you really want to go. For example, if I move my mouse across a menu on the way to the menu I really want to get to, the first one pops open and when I get the mouse to the menu I want to open it won't open because the other one is still open. Drives me crazy.

It's been a pet peeve of mine for some time. I do use a Mac though. Maybe it doesn't do it with Windows. Or maybe I'm just stubborn in that I want to have to click it for it to pop open. I'll keep an open mind about it though. :eheh:

Then you have a non standard theme doing it. The standard SMF menu is strictly CSS only and *only* works if you remain on it, rather than anything else.Although I'm a Windows user and that same behaviour is commonplace for Windows, I prefer not having to click, it somehow makes it a more natural action for me - that instead of having to hit an arbitrary point so I can begin my navigation of the menu I can start above it and sweep down in a single move.

Is your menu 'stuck' to the very top of your theme?
Does it do that in all browsers?
URL?Doesn't sound to me like a 'normal' SMF menu...In Wedge, if you click a top menu item, you often end up in another page. SMF doesn't do it, but Wedge associates default pages to menu items to help with menu selection in contexts where usability is important (e.g. keyboard users, small smartphones...)

And yes, I'm not perfect, but I'm serious about what I do. :)

OK, since you mentioned other browsers, I am using Firefox 5.0.1 and there is a noticeable delay. 1-2 seconds but Firefox gives me the same delay when trying to scroll a page with the scroll wheel on the mouse or even typing. My display of characters being typed will lag behind a few seconds so this might be a Firefox issue. There doesn't seem to be a delay using Chrome or Safari. And the longer I use Firefox the worse it gets until I usually close it and re-open it and it's better...for a while anyway.

But since I was checking I think I realized what I really don't like about them is in the admin panel there are two menus and if the mouse hovers over the top one and pops open you cant get to the bottom one. And with the Firefox delay I usually end up moving the mouse to a blank area and clicking which forces the open menu to close. If there wasn't one menu directly above the other in the admin panel I probably would never have noticed such a thing.

See attached, if the mouse moves over the admin menu I can get to the menus underneath it. Maybe I just need to slow down so the mouse doesn't get away from me and move over the wrong menu. :lol:

And this is why we love you. :cool:

Oh and about admin panel javascript: Not a problem. I whitelist my own pages, haha.