Feature/export selected

[lloydmeta]

Addresses #163

Works by:

• Adding an export-selected anchor selector parameter to the datatable template
• Adding a listener for clicked events on the table and updating the clicked row's style to be selected(natively supported by Jquery datatables)
• Adding a select all button
• Find the list of selected rows, get their respective ids, and then update the URL on the aforementioned anchor, disabling it if there are no items selected for export.

[mauhiz]

The are a LOT of unrelated changes because a formatter went crazy

[xevix]

Awesome, this will help a lot in exporting several things quickly.

The flow I had in mind was something like:

1. Filter using the Search box on the right for just the sets of endpoints desired
2. Click some "select all" kind of button, and adjust selection if desired
3. Click export

The style changes themselves aren't an issue, but it's not possible to isolate the semantic changes. Maybe have 1 commit with the semantic changes, and a different one for the style if desired.

[lloydmeta]

@xevix cool, added a select all button.

[lloydmeta]

The are a LOT of unrelated changes because a formatter went crazy

:( this is getting fairly old now.

[lloydmeta]

Reverted most of the style-changes caused by Scalariform.

2 are kept because they actually make sense (aligning the routes file and the keyword arguments of a method call)

[lloydmeta]

Updated screenshot with the "Select all" button

[xevix]

Not a dealbreaker, but often a few quick clicks on selecting rows can lead to a text-area selection as seen in the URL field here. I like the idea of clicking directly on a row to select, but perhaps a selection column on the left, with or without checkboxes, might work better here. A user trying to select the URL for copy+paste will also find themselves inadvertently selecting a part.

The rest looks awesome. Great addition.

[lloydmeta]

Not a dealbreaker, but often a few quick clicks on selecting rows can lead to a text-area selection as seen in the URL field here. I like the idea of clicking directly on a row to select, but perhaps a selection column on the left, with or without checkboxes, might work better here. A user trying to select the URL for copy+paste will also find themselves inadvertently selecting a part

Reimplemented with a checkbox column.

[mauhiz]

Very nice feature! I'll test it some more locally. Meanwhile, could you please reorganize your commits between formatting changes and the core of this PR?

[mauhiz]

The checkbox column is sortable but likely does not need to be.

[lloydmeta]

The checkbox column is sortable but likely does not need to be.

The column was actually not sortable but DataTables was showing it as sortable (annoyingly). This is now fixed.

[mauhiz]

LGTM

[xevix]

@lloydmeta Awesome. One final nitpick is the following sequence:

1. Click select all
2. Manually deselect selected boxes
3. Select all checkbox should be uncleared

[lloydmeta]

@xevix good idea. sounds like a good way to improve the UX. done.

[xevix]

@lloydmeta It seems like the last commits changed existing behavior for this flow:

1. Click select all
2. Unselect an item
3. Select all remains checked, so that you can click it after to deselect all

As a reference I'm using GMail's behavior. This flow did seem to make sense, as when a person clicks select all, then deselects an item, it's more likely they may later wish to deselect all, rather than click select all again. Thoughts?

[lloydmeta]

Yeah, I changed the SelectAll checkbox behaviour on purpose based on logic. The idea is that when you check it, it selects everything and is directly tied to that state: unchecking any checkboxes causes the SelectAll checkbox to change to something other than "all selected"; since a checkbox is binary, it would be unchecked. LinkedIn's messages select all checkbox does this.

Gmail's select all isn't a checkbox, it's a triple (possibly more?) state custom thing with a dropbox containing other actions (let's call it an uber-select-check). When you check it and unselect some items, it changes into a "some selected" state that is distinct from it's "all selected" state.

Short of having data from user-testing, in our select-all-then-unselect-some scenario, I think it would be hard to say whether a simple checkbox should remain checked based on what a user is more likely to do because it involves successive second guesses on user intent/ability/mistakes. In addition, StackExchange has a couple threads where people say this is an inherently tricky thing to decide. I think the confusion stems from the fact that the checkbox is simultaneously used as a way of invoking an action and as an indicator of current state (are all things checked?).

After reading a few posts, I'm in favour of having separate Select All and Select None buttons; this keeps things simple and never incurs the cost of extra click on behalf of the user.

[xevix]

Yeah, I wasn't saying to emulate the GMail checkbox's other behaviors which we don't need, just those related to the select all/none functionality. I'm certain that the efficacy of that UI had user-testing backing it as that's Google's general policy, but it's true we don't have access to said data.

Go with whichever one you think makes the most sense.

[lloydmeta]

I've pushed an update that implements 2 select toggle buttons.

At the end of the day, the checkmark solution implemented either way would have only resulted in at most 1 extra click required in case we guessed wrong, so it's not a huge deal. I think we should go with this for now, try it out, and if we don't like the real estate that this solution takes up, switch it to the tri-state checkbox à la Google or back to LinkedIn (fairly trivial)

[xevix]

@lloydmeta Awesome, LGTM, merging.