Be able to add + remove labels from webcompat.com

[miketaylr]

Right now labels are READYONLY, e.g., http://webcompat.com/issues/122

The solution needs to allow non-repo collabs to set/remove labels (we can use our bot proxy to interact with the API here).

[tagawa]

Big +1 to this. Added to the initial form could be good, although maybe hidden behind an "advanced" button perhaps.

[miketaylr]

See #196 (comment). I think the chosen multiselect would make for a nice UI to do this: http://harvesthq.github.io/chosen/. We'll need to test how it pans out on mobile though, it seems there are some issues (see harvesthq/chosen#1388).

[magsout]

@miketaylr you're right. I'm thinking something like that https://dl.dropboxusercontent.com/u/54938109/chosen/index.html .

[tagawa]

According to the FAQs, Chosen is disabled on iPhone and Android anyway: https://harvesthq.github.io/chosen/#faqs

[magsout]

Yes, on iOS script is disabled, so it's not good for webcompat, Because a simple <select>isn't enough.

[miketaylr]

I wonder how terrible <select mobile> is on mobile... nevermind, seems like it's pretty broken on iOS: http://stackoverflow.com/questions/20039194/multiple-select-in-safari-ios-7

I really like the idea of something like https://dl.dropboxusercontent.com/u/54938109/chosen/index.html for Desktop users at least. Perhaps we do something like that for larger non-mobile-ish viewports and then do a simpler version of github's label picker for mobile?

Something without the filter wouldn't be too complicated to build. Maybe it's worth starting from that and deciding how it works on Desktop (and if the extra complexity/code of having two mechanisms is worth it).

[tagawa]

That StackOverflow page does say that it's mostly better in iOS 7.1.

[magsout]

Something without the filter wouldn't be too complicated to build. Maybe it's worth starting from that and deciding how it works on Desktop (and if the extra complexity/code of having two mechanisms is worth it).

I think of having two mechanisms is a good idea if we have chosen for desktop, and native <select>for mobile. Build two different element Is pretty hard to maintain and to detect where you display first mechanism or the second.: modernirz with touch, viewport with css etc...

Maybe we can starting to think about the idea of @calexity now : #196 (comment)

[miketaylr]

Agreed that detecting when to show native vs chosen will have its share of problems (and ultimately bugs).

Maybe we can starting to think about the idea of @calexity now : #196 (comment)

Yeah, this kind of thing could be really cool and would give it more of an application feel possibly.

I was thinking also of maybe building something like a "popover" (see http://www.pttrns.com/ipad/categories/14-popovers for a bunch of examples):

[magsout]

Yes, very interesting.

[calexity]

I like the popover idea @miketaylr - reminds me of how Gmail handles labels.

On desktop

On mobile - native

On mobile - web

[miketaylr]

Refactored things a bit to make proxying label changes to GitHub more modular: 438c17f. I've got the (uncommitted) backend changes to PUT/POST labels to GitHub in a branch as well.

I think I want to pull the labels out of the issue body view and create a view for just labels--this way we can just re-render updates to labels independently of the issue body. And then I can start work on the label UI component, something similar to how Gmail does it I think.

[miketaylr]

OK, progress update:

Everything should be in place in terms of functionality (minus the bugs I don't know about yet).

If you're logged in, you'll see either an "Add" or "Edit" button next to the labels. Open question: do we want to require people to be logged in to add/edit labels? Our bot is actually making the changes in the background on behalf of a user, so we could go either way.

So we probably want a smaller button style here. :)

That will open the "label editor", which is obviously unstyled here:

Adding or removing a label will update the issue label view, but I don't hit the GitHub API until you click Save and Close. Note to self: check that something actually changed before firing off a POST.

There's basic filtering in place, which works on a strict match from left to right. So "fi" will match "fire" and "figs", etc.

I'm not set on any kind of styling right now, open to all suggestions + improvements.

See 0330ad0 for relevant commits.

[magsout]

Something like :

[miketaylr]

wowowow.

[magsout]

last update :

[miketaylr]

Looking very nice. Just need to do a bit of x-browser testing + tests before pushing to production.

[miketaylr]

Gear overflow in chrome:

[magsout]

@miketaylr could you append label editor inside .issue__label_editorafter .issue__label--modify

webcompat.com/webcompat/templates/issue.html

Line 37 in df01146

<span class="issue__label_editor"><button class="issue__label--modify icon"></button></span>

[miketaylr]

@magsout done in fc3e51a. It sort of messes up the layout with the labels currently, but looks like some display: inline-block plus position tweaking will clear that up.

[magsout]

@miketaylr i modified name of Class :

issues.LabelEditorView = Backbone.View.extend({
  className: 'label_editor',

it's ok ?

[miketaylr]

@magsout yep, that's great.

[miketaylr]

💣

I went ahead and merged this to production. Thanks so much to @magsout for help with design + frontend stuff. Please file new bugs for any issues that we find.