Also, I prefer the single word all lower-case we currently use Ex. progressbar instead of Progress Bar or progress bar. But maybe it depends on whether you're talking about the specific jQuery UI control (progressbar) or a progress bar in general? To me the name of the control should be progressbar.

I guess I'll add a few reasons as to why I still feel that way, because it was a conscious decision when we made it. The plugin name is used in the filename, in the code, in the name of a wiki page (url). In all of those case there will be no space. So I guess it's more consistent and more easily consistent. Otherwise if you called it progress bar in a lot of places, there would be some places where you would still see and write progressbar (the name of the class, the name of the file etc.). So imagine someone goes through and fixes all those instances, but without recognizing which should remain progressbar (one word). So, because there will be many cases with no space, it seems simpler to never have a space.

Also, as far as spaces in the urls, I'd much rather see /progresbar than /progress+bar (try as I might, I can't read that as anything bug progress PLUS bar). And thanks to Murphy's law someone is bound to end up typing 'progress bar' and ending up with /progress%20bar in their address bar. Yuck.

Hmm, I just tried space ( ) and plus ( + ) in the url in mediawiki (jQuery Docs, end-user jQuery UI Docs wiki) and it converted both to underscore ( _ ). -1

I understand the rationale and I think what you have now for names works for the limited set of widgets (you have been lucky so far!). But as I think about some of the new widgets on the horizon, trying to shorten these or jam them into a single word with no spaces could be really ugly -- "collision detection" is a good one. Maybe we can always shorten these to make a single word work. I welcome people to just re-name the items in the matrix to work out a system. Here are the tougher ones I see already in the matrix:

image preloading
data visualization
textarea list builder
infinite scrolling
layout manager
multiple checkbox picker
form validation
collision detection

image preloading - just preloading? preloader?
form validation - just validation
layout manager - could be just layout
multiple checkbox picker - checklist? checkboxlist?
data visualization - just visualization?

I'd much prefer the one-word varations: Easier for development, and the style is much more common in german, eg. collision detection is Kollisionserkennung. The development argument is the strong one: In the end, we have to find names for the plugin methods, its good to have them 1:1 to the specification.

I agree with Jörn and Richard here - in the code, we try to use short, easy naming, as much as possible, the jQuery style. Something like data visualization could be "$([]).visualize()" in the code. Also, introducing whitespaces will likely introduce problems in many instances, as Richard pointed out, so if we can find single words to describe certain functionality, we should.

I think we should also be consistent in the names on the frontpage aswell so they follow the shortened one word name. i.e. "progress indicator" should be referred to as "progressbar" everywhere.

Also are we to continue with the old convention? Should it be Timepicker or timepicker from now on?

What if a widget really could not be shortened into one word? This might be an edge case but is a possibility. What convention should we follow then? lowercase, lowerCamelCase or UpperCamelCase?

Ca-Phun, that depends on the context. Take data visualization: The plugin method would be named dataVisualization, while the wiki page could be DataVisualization.

Still, I vote for working hard on finding short names. It probably results in a few less then optimal names, but that trade-off seems to be worth it to me.

As a personal preference I like Timepicker more than timepicker but then positionTo looks better than Positionto. :-(

I'm not too anxious to change (all) the names on the front page, because we don't have a 1:1 match (though we could work toward that). The front page currently contains pattern names, not component/plugin names. Progress Indicator is a good example. When create round spinner indeterminate indicators, I wouldn't think they'd be called progressbar.

Good point. Though that just means we shouldn't be calling this plugin method progressbar as it doesn't fully reflect the widget. Unless the idea is to have a different method per type of progress indicator?

I don't have a problem calling this widget a progressbar. That's what it is, and someone looking for a progressbar is going to say, "I want a progressbar. Oh here's one - jQuery UI Progressbar" As far as what to call the others, and whether they'll be incorporated or separate, that's still to be decided. But they all/both fit into the progress indicator pattern.

I see. Well that's where the confusion lies (for me at least). For some reason I thought that each row in the table on the front page refers to a single widget / utility / interaction. If a page refers to a pattern of widgets rather than a single widget then I agree we do not have to necessarily match the two.

We're in transition mode. This page (really this whole wiki) started as a way for the interaction design team to plan, collaborate, and design interaction patterns. It's getting closer and closer to a 1:1, especially with the recent prioritization, but there will be a lot of changes/renames still. And that'll continue.

Yes. I understand. And discussions of this type also help with the progression. So debating can only lead to a win win situation. :)

I just changed "plug-in" to plugin here. Please try to fix these elsewhere. On the topic of naming in general, I'm ok with using singel wrds like you do now as much as possible so this matches what's already out in the world.

This bigger issue we need to deal with is the difference between how we call things here for the purposes of planning and coding vs. how they may be consumed in the outside world. For example:

We're releasing the "Progressbar" plugin in rc3. In the wiki, this is a small part of the larger set of "Progress indicators" that includes determinate/indeterminate types in both bar and circular styles. Do we keep a single "Progress indicators" page with all the sub-types listed as have now or break these into pages the match the final plug-ins? Will the indeterminate bar be a future option of the determinate bar like Apple handles it (the current value is ignored I guess) or will this be a new plugin called "Indeterminateprogressbar" which would mean we should re-name "Progressbar" to "Determinateprogressbar" (yuck). Where would the circular ones fit into this world? We can handle each one as a separate plugin, group them by type (determinate/indeterminate) with shape as a secondary option under each or group them by shape (bar vs. circular) with type (determinate/indeterminate) as a secondary option under each.