Huge list of projects hard to use, consumes excessive d.o. bandwidth, can hang browser

I too have noticed this problem, but most people feel that the reply on the same page is a big improvement from the ifac upgrade. (e.g. http://lists.drupal.org/archives/development/2007-11/msg00145.html "The fact that you can add a comment/follow-up without having to click a 'follow-up link' is a nice improvement. Good idea.")

I can think of a couple of alternate solutions:

1) make the location of the followup form a user preference - this might be confusing in terms of UI and hard to make discoverable.
2) Split apart the form so that it becomes a multi-step - this would make it annoying to re-assign issues which happens pretty often
3) We trim the list of projects - to be useful we'd probably have to trim a few hundred of them which might not be possible

Any other ideas other than moving the form to a new page?

Option #4: Could the project select box be converted to an Ajax autocomplete textfield?

Option #5: What if it was split into a 3-step rather than 2-step select box set? Currently Component ajax-reformats with the correct options for the selected project. What if Project were split into Project type (Drupal project, Install Profiles, Modules, Themes; the stuff that's currently optgroups), and then have another Project selector that was just the projects of that type? That would at least reduce the amount of data that had to be sent on initial page load.

Option #4 is what I thought also, but it requires you to know (about something close to) the name of the project you reassign to. Anyway, this is the route I have taken in recent (local to my dev box :) revisions to l10n_server, where I also need to present a project dropdown with possibly all drupal.org projects. I display a radio button list when there is space and the number of projects is < 6. Then up to 30 I show a dropdown, and an autocomplete field above that.

Option #5 is probably not a solution, as the project list is big enough in itself. IMHO Opera has problems with the huge drodowns not the amount of data to process.

True, although #5 would make the Project drop-down smaller. The modules list would still be large, but not as large as it is now.

Would it be possible to do both? Make Project type a very short select box, and then Project a restricted autocomplete? Or would that require more context for the Project autocomplete than we can send right now?

I'm also reassigning this to project*, since that's where it would need to be changed, AFAIK.

No time to look closely at this now, but I will in the next few days. Moving to the right queue.

Yeah, I'd really prefer not to make the project an autocomplete text field, since it's too hard to know the project name of what you're looking for (especially given the split between the project title and the project's "shortname"). :(

Moving the form to another page is obviously easy, but not necessarily desirable. Not only does it slow down users in the common case, it doesn't actually speed up the process if you need to reply and you're on a slow machine. It just means you can view the issues more quickly, but it's still a drag to reply. If you want to view quickly, you should just browse d.o logged out.

In terms of the split JS/AJAX UI stuff, that seems fairly complicated, and not *all* that helpful. The lion's share of the projects are modules, so you're still going to have a huge project list whenever the "Project type" is set to "module". The restricted autocomplete seems difficult, and fairly confusing. If we're going to use an autocomplete text field, I don't see that the "Project type" restriction really buys us much.

subscribing

How often does the Project get changed after the issue has been created, and how many power users are actually doing this on a regular basis?

Before my comment, this page is 142K, but without the Project select box it's 26K, so we're spewing out an extra 116K with every issue page for logged in users, which is probably bad no matter what the circumstances are.

How about making the Project select box static with a link out to let the user change the Project? Or add a "This is in the wrong project" checkbox, which will bring up another form after the comment's posted allowing the user to change the Project...

This is a duplicate of #106950: Use autocomplete field for project selection on issue tracking pages.

I don't agree this is duplicate. These are separate questions, and I already mentioned earlier in this issue why I don't think an autocomplete box is the best UI for this. It's still obviously bothering people, so those who are bothered are encouraged to find a reasonable solution and code it up.

Cheers,
-Derek

I marked this as a duplicate because I don't see any other practical solution other than using an autocomplete box. We either have to load all of the projects or we don't. If we don't, the only FAPI element that I'm aware of that would be useful is an autocomplete box.

I seem to recall seeing that in D6 you can define your own FAPI element, so theoretically after we do the port we might be able to cook up something, but still I'm not sure how that would work.

But sure, if someone is willing to create a solution that's better than an autocomplete box, we could go with that.

Surely either this issue is a duplicate of #106950: Use autocomplete field for project selection on issue tracking pages or we have to won't fix one of them, unless you want us to provide yet another knob for an admin to choose which type of element to use for this field?

I see what prompted unmarking this as a duplicate. See #259110-3: Unpublished a project.

As suggested in #8, what about having a disabled single-value select box by default (trivial bandwidth), and then a "change this" link that will AHAH replace it with an enabled select box that has the full list? That reduces the size of the initial page drastically, while still offering a select box for usability in the rare case that it's needed.

I'm not opposed to #8. We already have some AJAX that repopulates the version and component choices whenever you change the project. This seems like a pretty slick approach to the browser-hang problem (though it doesn't solve the general usability of the fact that the drop-down sucks). I think the less bandwidth/faster page loads in the common case outweighs the inconvenience of an extra click in the infrequent case that you have to change the project. It'd certainly be nice to avoid a per-user setting (esp since we'd just have to pick one and stick with it for anonymous).

Historical note: this whole UI was designed and implemented back when Drupal had dozens of projects. As the # of projects on d.o has exploded in the last 2 years, a lot of things about d.o are straining at the seams, about to break -- this being one of them. I still don't think an autocomplete is the best solution here, at least not just that.

What if we merged the two ideas? Something like this:

- The default UI is an autocomplete text area, with the current project name as the default value. Takes almost no bandwidth to load, and would provide native autocomplete for folks who know the name of the project they'd like to move something to.

- There's a radio in front of the autocomplete (selected by default) and another in front of a label called "Full project list" (or something).

- If you toggle the radio, the autocomplete field is disabled, and the Full project list turns into a fully-populated dropdown (care of AJAX). This might take a while, so the select box wouldn't be marked as an enabled form element until the data finished loading. Maybe we even have a little "loading..." message or something that appears in the meanwhile, until we're ready to put the giant select box there.

- 2 answers for the non-JS case: 1) Use the text field and know what you're looking for (it won't be autocomplete, but it's still a text box, and we'll catch you on validate if you mess up). 2) Have a little help message inside a div that's hidden by CSS if JS is enabled (using the html.js class from core, e.g. html.js div.js-hide { display: none; } which says something like "To use the full project list, select the radio button then click on the 'Preview' button below to reload the page.". Sort of a hack, but it'd work for the non-JS people, too.

Is that way too complicated? ;) Would that make the form even less usable? I'm brainstorming here, since I'm opposed to only using an autocomplete for this problem.

The radio-button triggered magically morphing autocomplete box to select list is a fine idea.

Another possibility: instead of the radio buttons, have a "Don't know the correct project name" link (or something like that) which either does what you are saying or creates and populates near the autocomplete a select box that allows the user to select the project name. When a selection is made in the selection box, the autocomplete field gets filled with the correct project name.

The non-JS case for this should be as simple as possible -- there may not even be a single non-JS enabled user who would ever be doing this. So your first non-JS fix is sufficient, especially to get this out the door. If anyone actually requests a better non-JS solution, then that would be a follow-up patch.

I'm going to work on this.

Basically an autocomplete is disliked because if you don't know the name, you're stuck. So, we have to revert to a normal select in the case the user doesn't remember the name of the other project (as dww said in #16).
I think reverting to a normal select doesn't help at all. Who's insane enough to go through >2000 modules/themes? I'd just google on a keyword. So, why don't we make it possible to use the autocomplete to match any part of the project/theme name (this would effectively be a keyword search)? I think that's the easiest to develop *and* easiest to use approach.

Comments? :)

P.S.: No matter what the general idea is of how this should work (i.e. my idea or dww's or …), I'm going to work on this.

If you plan to work on the autocomplete that's over there: #106950: Use autocomplete field for project selection on issue tracking pages.

I do agree, though, that autocomplete is the most sane solution - both for users and programmers. As I said over there, I think it should be "smart" so that if you have X (50? 100?) or fewer projects it is a drop down and if you have more than that it's an autocomplete.

Agreed greggles :)

And I'll work on this over here, because I want to reach a consensus first :)

Thanks Wim! I'd say either an autocomplete like you suggest or dww's suggestion in #16 should work. Since one is a prerequisite of the other, let's start with what you describe and build from there.

#309463: Replace the huge project selection in issue submission with something more efficient has been marked as a duplicate of this issue.

Wim, are you still planning to work on this?

79% of the bandwidth to load this page was dedicated to filling the Project: select box in the submission form. There must be a lot of logged in users visiting multiple project issue pages every day. Did make me wonder what % of the total d.o. bandwidth is currently dedicated to sending multiple copies of this module list out every day, repeatedly to the same users... So would be interesting to track d.o. bandwidth before and after any improvement is implemented...

(Subscribing.)

This patch enables autocomplete in the D6 version.

had forgotten to run cvs up

Another shot, using keyup instead of keydown, works in safari and ff now.

Committed to HEAD and now deployed on the D6 test site!!! ;)

http://d6.drupal.org/node/201435

Nice. :)

Will be interested to follow that staging site too...