Menu Planning

[Jörn Zaefferer]

Its been painfully obvious that our widgets and interactions are too
complex and cover to many options to be easily maintainable. The
planning page for the Menu shows the same tendency:
http://wiki.jqueryui.com/Menu

I'd therefore like to discuss a different approach to building a menu
widget. Instead of trying to provide something that can various
completely independent usecase with the setting of an option, we
should build just enough for other widgets to build upon: Want a
contextmenu? Then use menu to build a contextmenu widget. Same for
dropdown menus (for a toolbar widget).

If we break it down that way, all a menu would do is rendering and
handling focus and selection via mouse and keyboard. Looking at the
problem this way makes it much easier to see other usecases for a base
menu widget. To give a better idea how that could look like, take a
look at these examples:

http://jsbin.com/owewe/edit
This outlines a contextmenu widget: A handles the right click event
and event delegation, builds or find a unordered list, and uses
.menu() to render the actual contextmenu. The select-option is just
passed through to the contextmenu's select option, letting the plugin
user decide what to do when a menu item is selected.

http://jsbin.com/uxeli/edit
Here we have an autocomplete that uses .menu() to build the
suggestionlist and not worry about focus and selection: It just uses
the select-option to put the result value back into the input.
Note the use of data: While this is still just an idea, it could be a
good strategy to encapsulate arbitrary data structures in DOM
elements, and retrieve those back in the form of a DOM element, where
the data can be extracted again.

http://jsbin.com/egoco/edit
Here we assume that menu is able to render nested menus. And if it can
do that for a toolbar-menu, why not also use it for an autocomplete?

With the menu working off a nested list, there would be no need for it
to provide any methods for manipulating the menu content: Just modify
the DOM elements as you usually do with jQuery, and, if necessary,
rerender the menu.

What do you think?

Jörn

[Andrew Powell]

I completely agree. This is pretty much the same methodology I
suggested 6 months+ back. I also follow the same methodology in what I
develop.

I'd like to see more plugin dependence and reuse as opposed to packing
in every possible feature the team can think of (aka. bloat)

[Todd Parker]

+1. I do think menus need to support multiple level flyouts but the
iPod style isn't essential. To be useful for apps, the radio, check
behavior and icon support is pretty important bit maybe there is a
lightweight way to support that so it's not part of the core menu.
Keeping things simple is good.

Todd Parker
to...@filamentgroup.com

On Sep 19, 2009, at 6:43 AM, Jörn Zaefferer <joern.z...@googlemail.co

[Jörn Zaefferer]

A first prototype for menu:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/menu/default.html

A menu leveraged by autocomplete:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/autocomplete/default.html

Jörn

[Todd Parker]

This is a good start, I really like the idea a lot of keeping this
light and re-using the core component to build menubars, menu buttons,
autocomplete, etc. As I said, I think supporting multiple levels via a
flyout is going be be a pretty essential thing. I know a lot of people
have asked for our menu to work as a navigation component that is
always visible on the page so making it easy to either have this open
in an overlay or be embedded like the datepicker works will be a big
plus.

Can you drop the themeswitcher onto your demo pages so we can keep an
eye on theming as we go?


todd.parker .: . filament group inc.
102 south street #3 boston, ma 02111

email + to...@filamentgroup.com
phone + 617.482.7120
fax + 617.687.0212
web + filamentgroup.com


On Sep 20, 2009, at 2:35 PM | September 20, 2009, Jörn Zaefferer
wrote:

[Jörn Zaefferer]

I'll look into nested menus; just added themeswitcher to both visual tests.

Jörn

[Paul Bakaus]

Please take into account adding/removing tree hierarchies. Building a simple prototype is..well..simple.

But please take a look at the dev version of the menu I've worked on - it solves a lot of conceptual

problems in a really easy way, and many man hours from Filament Group and myself went into it.

Thanks,

Paul

--
Paul Bakaus
UI Architect @ smart.fm
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Jörn Zaefferer]

It is not simple to build a simple solution - just because it doesn't
do much doesn't mean its useless. On the contrary, the current dev
menu does exactly the right things to be useful for the autocomplete.
And currently its just a matter of building more tests to cover other
usecases.

The DOM-driven approach of just converting an unordered list provides
much more flexibility then a specialised API to add and remove items.
If you think thats not the case, please provide specific examples or
arguments that we can discuss.

Jörn

[Paul Bakaus]

Hi guys,

just wrote a mail to Jörn, and mentioned I still suggest the DOM approach is not best suited in the

case of the menu. However, since my time is extremely limited, it's unfair to just shout out DON'Ts

without really preparing arguments, so I'd say let's go with it for now, and as soon as I have a fair amount

of time, I will go into detail why I think we need to extend our menu thinking a bit.

Anyway, I think the current work of Jörn is great nonetheless, and we're already using the autocomplete+menu

in the newest relaunch of smart.fm!

Cheers,

Paul

[Jörn Zaefferer]

Ok, cool. The labs code is still there, we'll just replace the functional spec for now, after building more functional tests, including the ipod-style menu.

In terms of modifying menus: Autocomplete works fine with just replacing an existing menu with a new one from scratch, so there is no need to modify a menu. Do you have an example where that wouldn't actually suffice? Would be very helpful, otherwise I have still no idea what the actual problem is...

Jörn