456137 - [W-1.3] Collection Creation

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Collections, defect, P1)

Description

[Justin Scott [:fligtar]]

From the specs:
    *  The first part of this page will be an explanation of how the collection creation and publishing process works, with pretty graphics and screenshots.
    * If the users opts to create a collection, the page will switch AJAXily to be a Collection Creation form.
    * The user must be logged into an AMO account. If the user is not logged in, they will be presented with a login form to AJAXily log them in, then proceed to the next part of the form.
    * Fields needed are: Collection ID (required; non-localizable; never changeable), Collection Name (required; localizable), Collection Description (required; localizable; maxlength of 200 characters), whether the collection is open (anyone can write to) or closed (must have collection password to write to), a password if “closed” was selected, and whether the collection should be listed in the Collection Directory.
    * Each collection must also pick at least one category that it falls under.
    * The Collection ID shall be validated to be unique and include no spaces and only alphanumeric characters plus ’-’
    * The Collection Creation success page will include instructions on how to start publishing and telling your friends about the collection, and how to embed a subscribe button on a website or blog.

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

Attachment: draft 1: creating a collection

Login, Collection creation, and success screens are shown here.  The missing screen that Justin mentioned is the "what is a collection" intro.  I think this is a very important part of the final product, but wonder if it really needs to be shown every time the user wants to create a collection.  Perhaps just having that be an option, and a link on the page, would be enough.

Comment 2

[Wil Clouser [:clouserw]]

(In reply to comment #1)
> Login, Collection creation, and success screens are shown here.  The missing
> screen that Justin mentioned is the "what is a collection" intro.  I think this
> is a very important part of the final product, but wonder if it really needs to
> be shown every time the user wants to create a collection.  Perhaps just having
> that be an option, and a link on the page, would be enough.

I think that would be fine, we could emphasize it.  Like, maybe a few hundred pixel box with a pretty graphic or something.  Like one of those crappy banner ads but integrated into the page more so it blends in.

Also, On the creation form, what do the "who can edit" and "who can view" dropdowns contain?

Comment 3

[Justin Scott [:fligtar]]

Sorry for the delay in my feedback. The collection creation mockup looks good, just a couple minor things:

* The collection ID won't necessarily only be seen by the author, it will likely be in a number of URLs and other places.
* The "Who can view this collection" field is no longer needed, as we decided not to do private password-protected collection viewing, at least in this phase.
* The "who can edit this collection" box should probably be phrase as "Who can publish add-ons to this collection?", and there will need to be a space for the write password if anything but "Everyone" is selected. The default should probably be "Only people with the password". I think the only two options would need to be "Everyone" and "Only people with the password", so we could probably switch to radio buttons instead of a select box.

Comment 4

[Jennifer Morrow [:Boriss] (UX)]

Attachment: draft 2: creating a collection

Changing mockup per Justin's feedback:
• Colection ID description changed
• "Who can view" removed
• "Who can edit" rephrased, made into radio buttons.  If "everyone" is selected, the password input boxes would not display.

Comment 5

[Jennifer Morrow [:Boriss] (UX)]

Attachment: draft 3: creating a collection

I've been thinking about collection ID - the collection designation that will form the URL.  The question is whether we want users to be able to define this or generate it automatically based on the collection name.  I'm actually fairly confident that we want to generate it based on the name.

The problem is much more complex if the Collection Name and the collection ID are different.  This means that the collection "Bob's Amazing Ski Addons" could be found at .../collections/amazing, or ..../collections/3463465. It introduces all sorts of problems regarding mismatches between the name and URL.  So, why should the name and URL be different at all?  By having each name (and thus URL) be unique, we're simplifying search and URL duplications: one name = one URL = one user's collection.

Also, I don't feel much is gained by giving the user this one more field to deal with.  Why would a user need their URL to be different from their Collection name?

The mockup I'm adding now has removed the unique ID space, and shows what the user would see if they select an ID which has already been used.

Comment 6

[Justin Scott [:fligtar]]

Based on the new spec, we should make the following revisions to the draft 3:
* Login step is unnecessary - users will already be logged-in via normal AMO methods
* The creation and management process should be broken into 3 separate areas:
1) Collection Properties/Metadata - where things like name and description are created/edited
2) Permissions - Where you can add and remove users' access and roles
3) Add-ons/Contents - Where you can mass add and remove add-ons to/from the collection
* Categories have been eliminated. We will eventually have tags, but not yet.
* Collection ID is an auto-generated number that shouldn't be part of the form process. A nickname can be requested in the management area after creation (more details in the management bug)

For creation, the process should go something like:
1) Intro to collections and how they work (copy to be written by me, just leave a placeholder)
2) Collection Properties
3) "Should anyone else be able to publish add-ons to this collection?" permissions page
4) Mass add add-ons by name find-as-you-type. Similar in style to Facebook inviting friends to an event or adding friends to a friend list.
5) Success and view new collection page

Comment 7

[Justin Scott [:fligtar]]

Working on the final wireframe copy now and then will be over to Fred for implementation.

Comment 8

[Justin Scott [:fligtar]]

Attachment: creation wireframe

Okay, this is a new mockup of creating a collection based on the new spec. Most of the steps are on one page and transition by AJAX, ending up at the final created collection.

This is really adding on to the scaffolding that's already there for collection creation -- it shouldn't look pretty, but should be functional. Once Clearleft has designs, we'll be able to add in colors and design elements, but right now I'd just like to get the initial frontend components of creating a collection setup.

Any feedback on the mockup before it's passed for implementation?

Comment 9

[Justin Scott [:fligtar]]

Attachment: creation wireframe, v2

This new mockup greatly simplifies the process. Like the add-on upload process, it only collects needed information and then creates the collection in one step. After, the user can manage optional and advanced settings like permissions and icon and nickname from the edit page.

The edit page mockup will be coming later and is bug 456132. Please give any feedback soon. I'll probably pronounce it ready for implementation in a day or two otherwise.

Comment 10

[Nick Nguyen [:osunick]]

Looks great- really like the one step process.  Only two things, which we discussed in the 1:1 but I'll record for posterity:

1. A little more detail on what 'additional options' are possible, like icon upload.

2. even though the URL shows the collection id- repeat the URL in the page so users know that it's something they can share.

Comment 11

[Justin Scott [:fligtar]]

Attachment: creation wireframe, v3

Okay, this is ready for implementation. As I mentioned before, this is mainly adding to the existing scaffolding and not about making it look pretty quite yet.

Also, don't forget that we're using the bandwagon branch now. Thanks Fred!

Comment 12

[Fred Wenzel [:wenzel]]

(In reply to comment #11)
> Also, don't forget that we're using the bandwagon branch now. Thanks Fred!

Thanks for the reminder, I'll make sure to write code for the right branch :)

Comment 13

[Fred Wenzel [:wenzel]]

Regarding the "secret" that's needed for not-public, that doesn't seem to exist quite yet. The "view" page will just return an error for non-public collections. Is there a bug on this?

Other than that, I am almost done with this.

Comment 14

[Justin Scott [:fligtar]]

Hmm, I mistakenly thought it was built into the API already. I'll file a bug for that. Thanks.

Comment 15

[Justin Scott [:fligtar]]

(In reply to comment #14)
> Hmm, I mistakenly thought it was built into the API already. I'll file a bug
> for that. Thanks.

Oops, this is incorrect. I had forgotten that one of the reasons we switched to using a UUID was so that we wouldn't need the secret key stuff. As long as the user hasn't set a collection nickname, the collection id won't be guessable. So scratch the secret key part.

Comment 16

[Fred Wenzel [:wenzel]]

All right, I'll remove the restriction to "listed only" then on the view page.

Another question: The wireframe says "localizable" field: Does that mean it's supposed to be our awesome "localebox" element, or is it merely stating the fact that this is a localizable field in the database, but it's supposed to be a regular input element?

Comment 17

[Justin Scott [:fligtar]]

I think having the translation box will be pretty confusing for most end-users creating collections, who have probably never been given the option to localize something before. Let's having the strings default to the current locale, and we can use the translation box on the manage page for translations to be added there.

Comment 18

[Fred Wenzel [:wenzel]]

Attachment: Patch, rev. 1

Here's some collection creation goodness for your enjoyment.

Comment 19

[Ryan Doherty (:rdoherty)]

Comment on attachment 369574 [details] [diff] [review]
Patch, rev. 1

Functionality works well, just a few minor issues.

I noticed the AJAX search requests have a timestamp, which is usually used for cache-busting, but we don't want that, do we? I have a feeling this type of search is expensive considering the join with the translation table. A few users creating collections could hammer the database. 

I think the autocomplete feature could be turned into a jQuery plugin. It could then be used across the entire site as needed. (We could easily add it to the main search bar.) It would also make the JS cacheable (as it would be part of another JS file) and would avoid polluting the global namespace. 

I would like to see some graceful degradation for non-js interaction. I think it's possible, but will be a bit of work. 

Can we add the bandwagon css to one of the main css files? Avoids an extra HTTP request and makes it cacheable.

I also don't see any error messages or styling when I submit a blank form.

The form seems pretty busy, could we move the help text below the inputs? It will speed up completion by allowing the user to quickly scan from form label to input.

Comment 20

[Justin Scott [:fligtar]]

(In reply to comment #19)
> I would like to see some graceful degradation for non-js interaction. I think
> it's possible, but will be a bit of work. 
> 

This isn't the only way to add add-ons to collections, so I think people that have disabled JS can just use the drop down menus on each add-on's display page instead.

Comment 21

[Ryan Doherty (:rdoherty)]

(In reply to comment #20) 
> This isn't the only way to add add-ons to collections, so I think people that
> have disabled JS can just use the drop down menus on each add-on's display page
> instead.

wfm, we'll just have to build that module dynamically so there's no UI visible to non-js users.

Comment 22

[Fred Wenzel [:wenzel]]

(In reply to comment #19)
> I think the autocomplete feature could be turned into a jQuery plugin.

autocomplete is already a jquery UI plugin.

I'll fix the other problems though at the very least, thanks.

Comment 23

[Ryan Doherty (:rdoherty)]

(In reply to comment #22)
> (In reply to comment #19)
> > I think the autocomplete feature could be turned into a jQuery plugin.
> 
> autocomplete is already a jquery UI plugin.

I meant the autocomplete for searching add-ons. There are a few places we have a searchbox for searching add-ons (developer control panel, search and now this page). Creating 1 component (JS and backend) for this functionality makes it easier to implement elsewhere (and possibly guaranty we won't duplicate efforts).

Comment 24

[Ryan Doherty (:rdoherty)]

Actually, after talking with Fligtar, I see now that the autocomplete functionality for this can't be easily reused. So making it a plugin for use elsewhere isn't important. My bad.

I would still like the JavaScript moved out of the global scope if possible.

Comment 25

[Fred Wenzel [:wenzel]]

Will do. There's not much of a reason why I need to name these functions anyway, if I format the code pleasantly I can probably keep them anonymous.

Comment 26

[Fred Wenzel [:wenzel]]

Attachment: Patch, rev. 2

I addressed your comments as follows:
- timestamp in requests was part of the plugin -> setting disabled
- not turned into a jQuery plugin, but cleaned up JS namespace
- non-JS users do not see the "add add-ons" part anymore
- CSS moved to screen.css
- error messages added (note everything is still un-styled)
- the descriptions are now underneath the fields.

Comment 27

[Ryan Doherty (:rdoherty)]

Comment on attachment 370305 [details] [diff] [review]
Patch, rev. 2

Patch looks good, but autocomplete isn't working. Not sure why, I stepped through it with a debugger and the JS executes to setup the autocomplete, but the $.result() callback doesn't fire.

I wasn't able to debug any further because it's using the packed version of autocomplete and when I switch it to the non-packed version, I get a JS error stating '.result(functio...' is not a function.

I'll poke around some more, but Wenzel might have a better understanding of how it works.

Comment 28

[Fred Wenzel [:wenzel]]

The non-packed version of autocomplete in the code is old and does not have the result() method. I should probably update that first, then fix other problems. Let me give you a patch for the autocomplete update first, so that we can get that out of the way.

We can then test against the non-packed, current version of the plugin and should probably be able to find any problems that may still be there.

Comment 29

[Fred Wenzel [:wenzel]]

(In reply to comment #27)
> Patch looks good, but autocomplete isn't working. Not sure why, I stepped
> through it with a debugger and the JS executes to setup the autocomplete, but
> the $.result() callback doesn't fire.

Oh, boy, I think I became the victim of some cached code :( I can now reproduce and I'll fix this minor problem.

Comment 30

[Fred Wenzel [:wenzel]]

Attachment: Patch, rev. 3

I fixed the problem with result() not firing. Note, this patch relies on jquery.autocomplete.pack.js already being there and does not include it anymore as that is bug 486336.

Comment 31

[Ryan Doherty (:rdoherty)]

Comment on attachment 370617 [details] [diff] [review]
Patch, rev. 3

Tenative r+ if the scrollbar issue in bug 486336 is resolved.

Comment 32

[Fred Wenzel [:wenzel]]

Since the scrollbar issue is resolved for now, committed to r24093 in the bw branch.

Comment 33

[Fred Wenzel [:wenzel]]

Oops, forgot to add the ajax views: r24096.