Proposal

My proposal is basically:

• community repository: Make a community repository to host any dojo widgets from the community, or any that we don't want to release/maintain as part of the official dojo.
• behavioral widget project , and IxD widget project: Tom suggested making a new set of widgets that are behavioral and more lightweight.   I think that's a great idea.  I nominate Tom to write it.  We'll wait and see what comes out of it and maybe even steal some stuff to go back in the traditional widget space.  Similarly, Alex suggested a new project for the IxD stuff.  Go for it.
• dojo.widget (traditional widgets): (as Tom also suggested) vastly streamline and standardize the set of traditional widgets.  Move many of the current widgets to either the community repository or the behavioral project.

Here's the explanation:

There are two conflicting goals for the dojo widget system   (When I say widget, I actually mean any identifiable entity that appears in the browser window, such as an auto-completor, tree, or pie chart.)

1. encourage innovation by allowing dojo developers, or anyone else, to easily create and publish all sorts of widgets.  We shouldn't restrict people from releasing cool widgets like a FishEyeList, nor even checking in a new paradigm of widgets like Tom's suggested behavioral widgets
   
2. present a core set of (traditional) widgets with a common look and feel, that are all accessible/internationalized, with a common api, and high quality level that people can easily build apps with, but that are also customizable

Why are these goals conflicting?

• The  current widget set is too large to maintain, to test, to give a common look and feel, to standardize with a common api, to make accessible, etc.   At least given the number of people actually working on that.
  
• Paradigm wars: For example, RadioGroup and PageController do the same thing but with a different API.  FilteringTable and Editor work great, but don't interface well with dojo's layout controls (LayoutContainer etc)

The above suggestion will allow us to:

• reduce the official dojo widgets to a maintainable set WITHOUT throwing away anything.
• give the traditional widgets a standard kind of API (is that the right word?) without upsetting anyone.  For example, make a Table widget that can be a pane in a SplitContainer, responding to resize events etc.
  

Traditional Widgets

Here's my suggestion of what to do with the traditional widgets in dojo.widget, and which widgets should be moved to community repository or a behavioral widget project.

Goals

• standard set of widgets just like in swing or Windows Forms.  Should have a standard API, and a standard look & feel.   Focus on performance, bug fixes.   Also, all widgets need I18N and A11Y.
  
  
• Should support sticking some ajax widgets into traditional web pages, like adding tooltips to links, but also a full-on web application such as yahoo mail
  

• Unlike swing (or MFC), need to support customization, because web pages all demand to change colors etc.
  

Non-goals

• support an app that looks like windows

• support a webOS / eyeOS type system
  
  
• support mobile phones, or SWT, or anything else besides the browser
  
  
• free-for-all, allowing any wigets.
  

Customization

Give widgets limited customizability by letting users change the CSS (and maybe changing the class names themselves), but nothing beyond that.  For example, if the tundra tab container is square then we shouldn't use the sliding door technique, because that increases code size and slows down rendering speed (by requiring extra dom nodes).

Form widgets

There are a number of widgets in dojo that just correspond to (and enhance, visually or functionally) basic HTML controls.  They should have an interface as much as possible like the standard HTML controls.   And they should have a common API.

Input widgets:

• DropdownDatePicker - current design is too complicated, advancing week by week.  People may get confused and pick "Dec 17" when they meant to pick "Nov 17".  Do something like YUI's calendar.
  
• DropdownTimePicker (has to be redone; many issues; or maybe just drop it in favor of two drop-down lists)
• Validation widgets: integrate hinting into validation widgets; get rid of date and time validation widgets since we have DropdownDatepicker/DropdownTimepicker
• Spinner - useful for setting integer value.  For setting time/date value, we already have other widgets

Combobox, Select:

the Select widget corresponds to a <select> dom node and is fine; but the Combobox is confused, because it's like an auto-completor, but it still has the concept of key/value dichotomy.  Replace Combobox w/an Autocompleter widget that only has labels (and no values)

Editor:

Does the variable-sized editor window and floating toolbar make sense or does it just confuse people?  In any case Editor should be able to respond to resize events so that it can be a child in a layout control

Miscellaneous:

• Button, Combobutton, DropdownButton (no change)
• Checkbox, RadioButton (no change)
• Slider (maybe it's overcomplicated w/buttons, etc.)

Form, Repeater:

Form and Repeater are invisible to the user; just helpful for making forms (no change)

Validation Code:

Have to think about the validation code (for multi-field validation checks) and how that integrates w/form widgets

Layout Widgets

The layout code is basically a bunch of code for splitting up the screen into smaller sections, and is often used as an alternative to CSS floats or tables, for making Windows-style apps like Yahoo Mail.

• Layout engine like YUI BorderLayout?  (combine/replace LayoutContainer, SplitContainer and more into one widget)
• Accordion (no change)
• TabContainer (no change, except maybe )
• ContentPane (no change, I guess; this is more of an implementation detail than a user-experience)
• PageContainer - invisible to user but useful for tab-like controls
• TitlePane (no change)

Dialog

Dialog should be scrapped in favor of ModalfloatingPane, which is basically the same as the browser alert() functionality but with any choice of buttons, not just "OK" or "Yes"/"No".  But w/should vastly simplify the code because we don't need the FloatingPane features of maximize, minimize, taskbar support, etc., in relation to dialogs)

Menus, Tooltips

Right-click context-menus aren't webish (nobody knows to right click), so replace them with a drop-down icon next to the item.  Or alternately, context menus appear by just hovering.

MenuBar looks like windows too much; needs to be changed but not sure how.

Charting

These are fine (no experience with them other than seeing the demos, so no comment)

Tables

FilteringTable is good but it has no lazy-loading.  And it needs to respond to resize events so it can work w/Layout code.

Tree

This is a major widget (well actually it's composed of many different widgets and we need to think about that).  Probably we want a single Tree widget that's data-driven off of a dojo.data source.

Miscellanous widgets

• AnimatedPng
• ColorPalette
• InlineEditBox
• TitlePane (no change)
• Toaster (no change)
• ProgressBar (no change)
• Toggler
• Wizard (no change)

Move To Community Repository

• GoogleMap, YahooMap - move to community repository
  
• Clock - more of a demo than something customers would plug into their webpages
• FisheyeList - cool looking, but probably doesn't fit the standard "look and feel" of dojo
• MonthlyCalendar - more of an application than something customers would plug into their webpages
• Show (the powerpoint-like widget) - more of an application than something customers would plug into their webpages
• demoEngine - of course, this should go in the website directory, not be release as part of dojo proper
• SlideShow - more of an application than something customers would plug into their webpages
• ResizableTextarea - sort of duplicates the editor
• FloatingPane, Taskbar - these fall in the category of "windowing system" that we don't have the bandwith to support as part of standard dojo
• SlideShowBanner
• StretchPane
  

Move to Behavioral Widgets Project

• RadioGroup - duplicates functionality from PageController
  
• FilteringTable - current implementation doesn't have default CSS rules, etc.  Doesn't fit the paradigm of the other widgets
  

Delete

• HslColorPicker - we don't need a separate SVG version.
• LinkPane - remove; same as ContentPane
• SvgButton - normal Button is sufficient; don't need a special SVG button
• SvgWidget - is this even used?
• SwtWidget - let's stick to running dojo in the browser.  No need to take on another project.

Hidden widgets

These widgets don't need to be documented; they are/should be just used internally.

• DomWidget, HtmlWidget - shouldn't these two be combined?
• DatePicker, TimePicker - no need to expose these; interaction should always be through DropdownDatePicker and DropdownTimePicker
• Editor2Toolbar.js
• PopupContainer
• ResizeHandle
• RichText
• Toolbar
• DropdownContainer