[Blacklight-development] Clean(er) document urls

Jennifer Vine jvine at stanford.edu
Tue Mar 24 18:55:45 EDT 2009

> I'm sure Jennifer will weigh in when she gets a chance.

*cough* oh sure, I've had the email open on my desk for 5 hours now...

I don't see a real user scenario around browsing Next/Previous through the
entire collection, with no facets or search terms applied. 

The individual item pages are essentially splash pages for individual
resources, either physical or digital. We expect links to these pages to be
shared in many different ways, including as links in external documents such
as bibliographies and CVs. When you arrive at a resource splash page
directly from an external link, the page is a destination, not part of a
larger set - and in that context I think the Next/Previous links should not
be present.


> -----Original Message-----
> From: blacklight-development-bounces at rubyforge.org [mailto:blacklight-
> development-bounces at rubyforge.org] On Behalf Of Naomi Dushay
> Sent: Tuesday, March 24, 2009 2:28 PM
> To: blacklight-development at rubyforge.org
> Subject: Re: [Blacklight-development] Clean(er) document urls
> I'm sure Jennifer will weigh in when she gets a chance.
> See inline:
> On Mar 24, 2009, at 11:20 AM, Jonathan Rochkind wrote:
> > I'm missing the use case for needing next/previous buttons that page
> > you through the entire list of documents when there's no search
> > criteria in session? What do we lose by losing this? It does not
> > seem to be useful functionality?
> just consistency.  personally, I don't mind next/prev links disabled
> when there are neither selected facets nor query params.
> > Jamie Orchard-Hays wrote:
> >> See inline:
> >>
> >> On Mar 24, 2009, at 1:30 PM, Naomi Dushay wrote:
> >>
> >> I agree with Bill that we want to support the search
> >> breadcrumbs ... and maybe our answer is there rather than
> >> sessions?  And if folks don't want the breadcrumbs ... uh ...
> > I don't follow the breadcrumbs idea WRT paging through docs.
> > Rereading Bill's comments--what he's suggesting takes us back to the
> > ugly URLs we just got rid of, as far as I can tell.
> I mispoke.  What Bill said:
>    "One option I've thought of is to use the search terms (which need
> to be on the page so they can go in the search box anyway) to key the
> session hash (e.g., session[:search]["search terms"]). Then the next/
> prev buttons could pass a munged version of the search terms, which
> could be used to pick the rest of the variables out of the session."
> This might address the multiple windows open fooching the session
> correspondence for next / prev  problem.
> Bill also said:
>    "The downside is that the next/prev URLs get a little uglier, but
> they're not supposed to be persistent, anyway."
> Well, we want the *displayed* url in the web browser to keep the clean
> urls -- that's the point, whether the document is arrived at from
> clicking a link in the search results, or from a next/prev link.   If
> the messiness with this approach can be hidden from the user somehow,
> then fine by me.
> 	"And, of course, a person could be doing two searches with the
> same
> search terms but different facets, but there are always pathological
> cases. "
> We would have to add the selected facets to the key for the session
> hash.
> >> If I have to choose, I prefer clean urls over coping properly with
> >> searches from different windows.
> >>
> >> I would defintely prefer to have next/prev links disabled when
> >> there's no search ... but would this affect a "default search" in
> >> the UI where there's no query or selected facets?   Again, at this
> >> time, I would prefer to disable the links if I have to choose.
> >
> > Yes, this would. We either leave the Next/Prev on all the time or we
> > turn them off when there are no search criteria. Take your pick!
> >>
> >> - Naomi
> >>
> >>
> >> On Mar 24, 2009, at 8:30 AM, Jamie Orchard-Hays wrote:
> >>
> >> Right, and the whole point was to clean up those URLs.
> >>
> >> The consensus seemed to be that clean URLs were highly desirable.
> >> If we want to support multiple search windows open, then we'll have
> >> to revisit this.
> >>
> >> Enabling/disabling the Next/Prev when there's no search would
> >> probably be trivial. I'm curious what others think.
> >>
> >> Jamie
> _______________________________________________
> Blacklight-development mailing list
> Blacklight-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/blacklight-development
> Blacklightopac Blog http://blacklightopac.org/

More information about the Blacklight-development mailing list