Search Results: Update pagination so that it works like angular-ui example

[wooldridge]

Mostly this has to do with making ellipses work as they do in this directive:

http://angular-ui.github.io/bootstrap/#/pagination

From @yawitz audit.

[laurelnaiad]

Are we using that component? Any reason not to?

[wooldridge]

I got my local Samplestack branch working with the angular-ui pagination component. The version I have working is basically the last one shown in the angular-ui examples, the one with the ellipses.

http://angular-ui.github.io/bootstrap/#/pagination

This example is most similar to the pagination shown in the @yawitz wireframes.

However, there are substantial differences in how this version of the pagination works and how the @yawitz pagination is spec'd. A few differences:

@yawitz: Persistent first/last buttons are inside the prev/next buttons UI Bootstrap: Persistent first/last buttons are outside the prev/next buttons

@yawitz: Button sets are adjusted so that size of pager does not vary for long result sets UI Bootstrap: Size of pager can vary for long result sets depending on where the user is in the set.

@yawitz: First/last buttons persist but are never duplicated UI Bootstrap: When first/last buttons are persisted (via the "boundary-links" setting), those buttons can sometimes be functionally duplicated (e.g., "First" outside, "1" inside)

Realizing the design in the wireframes will require either rewriting some of the angular-ui pagination component or rolling our own (starting with the version I had working already). So that's where we are with that.

[laurelnaiad]

I leave it to you guys with the hope that you'll find/choose the path of least resistance! :)

[yawitz]

I'm OK to ship with the default angular-ui pagination component, but would like to leave this open/deferred to revisit post 1.0, or at least convert it to a new task for later (keeping the wireframe spec as-is).

Background: The wireframe spec is a distillation of a number of pagination components I found in my research + some UX judgement calls. I'd like to revisit the details when we have a little more time.

[wooldridge]

Thanks for the input, @laurelnaiad and @yawitz. I think going with the angular-ui pagination as-is for now is a good idea given the schedule and bug list. I do like the concepts you've surfaced in your pagination diagrams, @yawitz.

I will tidy up the work and move to a PR.

[popzip]

@yawitz may need to open new issue/rFE to revisit in future release.

[yawitz]

Can you clarify the process here: if I want to keep the spec as-is, but note the difference between implementation and spec, is it appropriate to classify and log the spec details as an RFE, vs. leave this issue open and deferred to 8.0-2 or later? (I'm not sure forcing the spec to fit the incomplete implementation is the right thing to do; seems a little backwards.)

[laurelnaiad]

If we're leaving the spec as is and not implementing it, I think it's a Bug that we can leave untargeted or on 8.02 or something. If we're changing the spec, then a marker to revisit in the future is an RFE.... basically RFEs say "let's consider changing the requirements" and bugs say "The implementation doesn't match the requirements."

[popzip]

Defer for this release (1.1) - high effort / low priority. Leave open for a discussion next release to see if any other middle ground / configuration can be done to get implementation closer to spec, based on what is out of the box. Then update wireframe spec to reflect revised agreement. Not worth investing significant effort as a part of Samplestack to design a custom widget (but may be relevant for future/other projects to build reusable components in this design).