I took a shot at starting on a UI Toolbar to learn the widget factory. Sizing is not correct in guess what browser, but thought it may start discussion since I hadn't seen any here. I broke it into two widgets : one to create and manage items in a toolbar and another to wrap and manage the toolbars. http://daersystems.com/jquery/toolbars/

@Jason: Thats quite impressive! Would you be interested in commiting that to a branch, fitting your demo into the current format, or working on the wiki here to flesh things out, or both?

I agree, excellent work Jason!

Wow, Jason this is a really great start. Nice work with the css framework and theme switcher. I like all the flexibility you've added with the various options. The search box looks great too.

You might want to add an enable link to un-disable the toolbars :)

Now we just need to get all the button types worked out (toggle, split, menu, etc.) as a separate plugin and we'll have a slick little system here.

@Jorn : Thanks. I'd be glad to help out so what do I need to create the branch? I'll add some specs here and keep working on it.
@Steven : Much appreciated
@Todd : The enable option's in there, I guess I missed it in the examples. I'll take a look at the other widgets and see if I can get them in there as items. I saw the menu looked pretty far along so could be a good start.

@Jason: I created a branch here http://jquery-ui.googlecode.com/svn/branches/dev/toolbar/

I played with toolbars ages ago [1], I don't need them atm, but I'd be interested in joining the efforts of creating a decent toolbar.

Things that I've done differently:
- My markup is basically a <ul> (this is for the collection of toolbars,
one bar is a <li>) the toolbar buttons as <button>s.
- I've implemented someting called "groups", which is equal to one
toolbar in the current implementation. Those groups can have a name,
which makes sense if the user reorders the toolbars, as you can't access
them by index any more. This means you can add buttons to a toolbar, but
it doesn't matter where it is in the markup.

[1] http://vmx.cx/jquery/ui/ui-toolbar.htm

Jason - I've dropped your mockup into into the design section above. In general, I like the idea of having these 2 styles. In the second mockup, hovering over the buttons should assign the ui-state-hover class, right ? I think this direction with the UL/LI html markup input from Volker would be a great start.

Since it's impossible to create a toolbar without buttons, we should consider building out the button design page at the same time so these are built separately, then dropped into these toolbar containers.

A few design comments:
* Buttons need some horizontal padding _~3-4px so the text doesn't run up to the border.
* The font-family from the theme doesn't seem to be showing up on your coded page and your mockup uses Times New Roman which is really distracting. Can you update your code by assigning the ui-widget class to every button? This will assign the theme's font family and size.
* Lastly, the vertical lines used as separators seem really dark and don't seem to use the matching CSS framework color. For example, if the buttons sit inside a ui-widget-header container, the separators should probably be a 1px stroke of the ui-widget-header color so this separator should have that class.

One more thing to consider. All of our toolbar designs to date are modeled after the Windows Office style toolbars that use a docking toolbar metaphor where a toolbar consists of a bunch of small grouped button sets that can be dragged around. To edit the contents of a toolbar, you need to click a small down arrow and navigate a menu with a checklist of items to add/remove them. It's not clear how (or if) you can even re-order the buttons inside a toolbar group or if you can only hide/show the buttons and they appear in a set order. It is really hard to use and MSFT has somewhat abandoned this UI in favor of the Ribbon so is this a good model to follow?

I just want to float the idea that if we want to have functionality to re-order toolbar items or groups of items, we might want to consider the Mac model because it is much simpler to use and more direct. You click a "customize" button and a tray opens with the list of unused icons that can be dragged into the toolbar in any position. To remove an item, drag it back out to the tray. To restore defaults, just drag the default toolbar up. It's all pretty intuitive and eliminates all the fussy little checkbox menu interactions and extra grippy chrome for each group. See the screnshot in the design section.

How common is this type of toolbar re-ordering functionality in a web app? In it's simplest form, a toolbar is simply a bar that contains buttons that are grouped with vertical separators. However, if we do want to tackle re-ordering, we might want to seriously consider modeling this off Apple, not Microsoft because it would be a shame to copy a bad idea.

I think the toolbar itself should provide no means of sorting buttons or groups of buttons. Leave this to the sortable plugin, similar to how tabs are made sortable http://jqueryui.com/demos/tabs/sortable.html. Customization should be up to the implementer. The simplest would be to call .sortable on all the buttons within a toolbar. This would behave like the links toolbar in Firefox. You click a button to activate it, you drag it to reorder it. Same with separators. Again, this matches sortable tabs pretty well. You click a tab to activate it. You drag it to sort it. This should take care of a plenty common scenario with zero effort, and doesn't get in the way if someone develops their own more elaborate customization, since they wouldn't have to work around or on top of anything built-in to toolbar itself.

As far as the ribbon, what that adds is an additional level of hierarchy. It's really many toolbars available in a menu where one is always open. While that's an interesting model, and one we could support (perhaps by combining with the menu plugin?), I'm not sure I see how it relates to customization. It's still just a toolbar with groups of similar buttons. The difference is presentation.

Is there a standard for adding items through JSON? I like how the menu implemented it so the items property can either be a selector, function, or an object. I think this should be consistent across all controls since most of them like toolbar, menus, buttons, and accordion, to mention a few, could take type, text, icon, click, etc as properties. I was thinking it should always be an array and each actual item an object with text, icon, click as possible properties. Menu uses {text:properties} format which works well, but what if you just want an icon? The type property could be used to identify whether it’s a button, menu, etc and would just call that widget.

As Todd pointed out I was thinking of two styles set through a configuration option. Depending on the selection it would use a different set of classes for the items. Toolbar would have hover as an option set to ui-state-hover, but users could override any class setting in $.ui.toolbar.classes.

For buttons, I agree padding is needed, but should it be done in em instead of px? This way themes with large fonts (I’m thinking touchscreen systems) would have relative padding. The vertical lines should have inherited the ui-widget-header color, but a new icon might be best for the dividers. Maybe a new sprite that could handle horizontal/vertical repeats.

As for sorting, I initially thought it was so easy to implement why not just do it, but realized once you refresh the page, it’s gone. That type of functionality may be best reserved for a time when there is a state-management solution that could keep certain settings for a tool. Don’t know if that will ever be possible though. The ribbon effect is cool, but again, until your settings can be saved I really don’t see the point and agree with Richard that really specialized functionality like that may be best reserved for a plugin or at least future version.

For markup Todd mentioned UL/LI markup with buttons. I was thinking just DIVs, but make it work with UL/LI as well. Wasn't sure what to wrap a button set with using UL/LI and thought styling buttons caused issues cross-browser. What are the reasons for or against each?

I think UL/LI is more semantic and it played nice with the sortable plugin. I haven't had problems with styling (though mys styling wasn't very advanced).

I'm thinking that we should all take a look at working out the Buttons spec and markup first, then loop back and see how these need to sit in a toolbar. I know the buttons will need to be links, buttons (or anything else) and that certain buttons like the buttonsets needed an extra wrapper to create a grouping mechansim so a bottom-up markup exploration starting with buttons seems like the right place to start.

In the coded toolbar examples to date, we've only had buttons inside them but I think we should plan the toolbar as a container that can hold buttons, inputs (with autocomplete), checkboxes, radiobuttons, selects, pagination controls and any nimber of other UI elements. These elements can be visually grouped with separators at the minimum and these could be built simply as a new element type or as a grouping wrapper.

As Richard suggested, we can easily add sortables to the toolbar elements to allow users to re-order them. If we use a grouping markup style, these groups could also be sortable which is what a lot of the coded demos show now.

Does everyone agree that we should switch over to buttons and get those spec'd out first?
http://wiki.jqueryui.com/Buttons

@Volker, just wondering, is there a use-case for sorting buttons?

Just to add that the semantics of <dl><dt><dd> are suited for toolbars as well, in some cases perhaps better than <ul><li>.

In particular, given we need button groupings, <ul><li> requires 4-levels of nesting whereas <dl><dt><dd> would require just three, assuming that <dt> is flexibly defined, which it could be.

I don't mind either way, just a something to consider.

@Todd, yes, buttons first.

@Steven, to explain my <ul>/<li> semantics. The <li> is not a around a single button, but around a bar (with a handle to drag around and many buttons/separators). The <ul> is a collection of several toolbars. The use-case are context sensitive toolbars where you'd like to hide/show some bars.

#Feature add:
- demo link add http://daersystems.com/jquery/toolbars/
- Zoom in, Zoom out (for mobile platform forward, resizeable method )

The default demo in SVN is broken: http://jquery-ui.googlecode.com/svn/branches/dev/toolbar/demos/toolbar/default.html

Looks like ui.toolbar.js was rewritten to use the widget factory, but it specifies ui.tabs instead of ui.toolbar.

This is a little off-base, but I think all widget pages need an "iterations" or "priorities" section. Otherwise it seems many widgets, including this ones, are suffering from *scope-creep*. The core functionality needs to be clearly distinguished from 'bonus features', like popup control panels, sorting, auto-correct, etc.

I believe in the 80/20 rule - the functionality 80% of users 'need' can be produced in a relatively little time. The final 20% - the 'bonus features' - can take much longer and so should be added iteratively. I'm sure most agreed, but the widget pages and discussion do not seem to reflect this.

The UI collections NEEDS these *basic widgets* - buttons, menus, toolbars, trees, etc. I'd like to see them in the wild ASAP so jQuery developers can start using them, and providing feedback, ideas and code back to UI team. Instead, we are collectively wasting *thousands of hours* looking for and/or coding alternatives.

I realize everyone is working hard on these widgets, but I believe all features should be documented *and discussed* in a way that clarifies what are 'top prioritities' and what details can be finalized in future iterations. I think this might help accelerate initial widget releases. Personally, I'd rather have basic widgets than nothing at all. Of course I can use other plug-ins, but I'd rather use my time to enhance UI widgets and contribute that effort back to the UI team.

In the case of the toolbar, I think finalizing a markup structure is top priority. That might quickly facilitate a working prototype that can start being refined as a releasable widget, rather than demo after demo with new 'bonus features' added. As long as the core is solid, it's easy to keep adding iteratively.

Just my 2-cents. I hope there is something constructive here.

I think it is important to stress that these "widgets" need to remain as simple as possible in order to fit into all real world ideas as solutions. That said, here are my thoughts on what a "toolbar" is:

1) A toolbar is a container. Containers need a way to add/remove items from the container and methods for manipulating the container (such as swapping from horizontal to vertical). trying to be more than a container will result in reduced usage.
2) A toolbar could be moveable and thus should inherit from draggable (possibly sortable instead). By doing so, we have moveable functionality built in. UI developers should be able to use droppables to to define regions where toolbars can be dropped. For examples on the many different ways that just look at the many IDEs out there that allow a user to customize their "workspace".
3) A toolbar MAY have a label. Look at the MS Office suite for, what I would consider, stacked toolbars.
4) Lastly, UI Developers should be free to fully style toolbars in all settings easily (especially in the case of stacking).

While I might have missed a few minor things and presented this in an overhead, broad, manner, I think that giving/forcing much more than this is going to make a widget like this more and more bloat than would ever be used.

Oh, and other items in the UI suite should be able to use toolbars easily as well (as is the example of a ui-button dropping down a huge toolbar to "customize" the real toolbar)

Playing with buttons and Jason's toolbar code: http://workshop.connor.hu/jquery/toolbar/

My implementation drops everything from Jason's code, and starting at the beginning. I think this way is much simpler! Some unimplemented method: addButton(), addButtonset(), addSearch(), addDropdown() etc...