Add "Browse by Issue Number"

[asmecher]

See http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8943 for details.

[asmecher]

@NateWr, if you have a sec, I'd suggest considering the linked entry for OMP's front end.

[NateWr]

@asmecher I don't know what "browse by issue number" means or what's being asked for here. Let's clarify this at next UI/UX meeting.

[asmecher]

Followed up with SI and then John.

Currently the metadata field SI is using is called "Position in this Series":

Clarified with John why we didn't call this Volume in the first place:

Books in series, especially in the humanities, aren’t always numbered but are listed by reverse chronology, thus our use of ”position.” That said, it would not hurt the humanities to have a little more order and number in their lives, so I can see having the option of placing a book in a series, and in doing so having the system provide the prompt “Series volume number: [7].” It can be manually changed — to create some special order — but by default is the next volume number in the series.

SI's description of how browsing would work (paraphrased):

• Readers would hit the press homepage
• Readers would pick a series
• Readers would be presented with some form of listing (dropdown or list) of volumes, which they could click to open.

[asmecher]

@bozana, another one to consider! I think this might've also come up at Free University Berlin?

[NateWr]

Given the Smithsonian's description of how their users find monographs by volume number, it would be great to be able to sort and search by this value.

[asmecher]

@NateWr's emailed mockup:

[bozana]

Yes, that could be the way to correct the values i.e to determine the order, if necessary, but maybe we don't have to do this -- if the browsing by series position is enabled, then the editors will see if there is a mismatch/mistake and can repair it manually? Also, having "Book 2" or "Vol. 2" displayed to the user would indicate more information, what it is meant to be? Would also something like "Vol. 2 Book 2" be possible?

[bozana]

I was wondering how would be best to display the series positions for browsing. Maybe as they are (i.e. using the same string entered in the form field and saved in the database) on the series content page, between the series description and the monograph list:

When clicking on a series position, only the monographs with that position would be displayed:

All series positions would always be displayed, only the breadcrumb would change and the current position could be highlighted (e.g. bold).

What do you think about it? Do you maybe have a better solution where to list the series positions? How to display the series positions list best if it is a huge one? Is it OK to stay on the same page when filtering by a series position? Should all the series positions be visible on that page as well? How to present best the current selected series position?

[bozana]

Maybe to see here, what everything could be the series Position: http://www.editeur.org/files/ONIX%203/ONIX_Books_Sets_and_Series_3.pdf. Search for "PartNumber" -- I think this is the ONIX element where the seriesPosition field is delivered into. It could be just a number e.g. "2", but also something like: "_#_2", "II", "2-4", "2 of 4", "Set 2", "Series 2", "Volume 2", "Book 2", "Part II"... :-)

[asmecher]

Agreed, ONIX is the driver of this.

I think what we're trying to do is guide consistency, not specifically to parse a number out for other (e.g. metadata) uses. Frankly, I lean towards just letting the user enter whatever they want rather than working too hard on this, but something like an autocomplete field might be a useful way to hint what they've used in the past.

[NateWr]

I'm still not sure where we're going with the "browse by issue number" thing. Smithsonian asked for it in relation to the old navigation paradigm of dropdown menus. They wanted an additional dropdown menu on the left which would be a quick-jump to a book number because most of their users locate monographs by a book or volumn number that they assign:

The question is a) how many people are going to be using this and b) how are we solving the navigation problem?

To me, just listing out the seriesPosition field at the top of the series page is not going to be useful for most publishers and is really duplicating what's listed immediately after it: all the books in the series.

I only recommended pulling a number so that we could have efficient ordering and searching on this field. For presses like the Smithsonian, it makes more sense to me to simply order their series catalog pages by seriesPosition and surface this number prominently in the monograph_summary.tpl.

Then we don't need a new, duplicate navigation pattern. The question is: is this a setting that we offer on a series-by-series basis for how catalog pages are ordered (ie - Order this series by: title, series number, etc)? Or a feature we build into a plugin? Ideally the overall listing template wouldn't need to change, just the data that we pass to it could be ordered and the one monograph_summary.tpl could be adjusted.

Thoughts?

[bozana]

Sorry for late response because of the holidays :-\

I think that the different sorting and filtering options on all book listing pages (catalog, series and categories) would be helpful for everybody -- i.e. something like @NateWr suggests: "Order/filter by: series, categories, title, author, date, series position, ...". -- I've already heard of the similar requirements from LangSci and Edition Romiosini. I am not sure if this should be solved as a plugin :-\ -- The only problem I could think of i.e. we could eventually consider is that there will surely be different requirements on the elements/attributes the sorting and filtering should be provided by. The Smithsonian would like to have the ordering or filtering by series position, the LangSci by forthcoming books, etc. On the other hand, I believe we cannot consider them all i.e. in a generic way.

Some main filtering options (by series and categories) already exists, thus if the further sorting options (e.g. by title, author, date, series position,...) would be OK for Smithsonian -- if it doesn't necessarily have to be a filtering option -- I think we could solve it like @NateWr suggested i.e. providing the sorting/ordering options on all book listing pages and surfacing/displaying the series position (and other attributes we provide the sorting/ordering by) prominently.

I agree with @asmecher to let the user enter whatever they want for series position and not work too hard on this and its intelligence -- i.e. sort/order it as is, as entered -- and eventually only provide an autocomplete.

[asmecher]

@bozana, I think your proposal is a nice synthesis of the various requests we've seen. And it sounds like it's general-purpose enough that it would be better built into OMP rather than written as a plugin. @NateWr, do we have quorum?

[bozana]

@NateWr, if you agree, what would you recommend, how the sorting possibility could look like on those book listing pages? E.g. a pull-down list or ... :-)

[bozana]

What sorting options would you prefer:

As links, where number indicates the sorting direction (asc or desc) and should maybe be exchanged with the up and down arrows:

or As drop-down:

Or any other suggestions?

[bozana]

Any idea how to sort by author when multiple authors exist? -- I leave it out for now...

[asmecher]

@bozana, my first thought was "by primary author", but I don't think it'll be a very useful approach. A separate author profile area would cover the same requirement but do a much better job. Leave author sorting out of here, I think.

[asmecher]

As for presentation, I prefer the drop-down (less real estate), but @NateWr's opinion trumps mine here :)

[bozana]

Maybe another question, if it should be drop-down: should then be also another drop-down for the sort direction (asc and desc)?

[NateWr]

I am a little sceptical of putting the sorting options on every page as a UI control on the frontend. What I suggested earlier was having it be a backend option that editors can set for the catalog as well as per-series and per-category.

This would mean that each series or category could have its own preferred sort order, but not necessarily that the visitor would re-sort according to their preference.

My main interest in resisting user-sorting is in keeping things simple and preserving the focus of the page. There may be other options if we decide context sorting is important, but let's ask that question first.

For a custom sorting tool to be valuable, I'd think that you would need to be showing 30-40+ monographs on a page. How common do you think this is? And how valuable are the sorting options we're providing in a context where the press might have already determined a "best sort"?

To answer this, let's presume the following (if these are bad assumptions let me know):

• By default we'll sort by publication date.
• In cases where users are likely to want to sort by series position, the editor will have already set this as the default sort.
• If a user wants to sort by title, they are looking for a specific title they already know.

That leaves us with sorting by title as the one option that users are likely to want to do that doesn't already match the list's presentation. In this situation, I would think searching would be more useful than sorting anyway.

My sense is that we're already well-covered for the use-cases I've discussed with our browsing and searching tools. But I could be wrong.

I can see value in a context-specific search/sort panel (maybe a dropdown next to the number of titles). But I think it's still fairly low priority until presses become very large (hundreds or thousands of publications).

I do think an option to configure sort order in the backend is a high priority and would resolve a lot of the primary concerns of presses who have particular series' or categories' that shouldn't be sorted by publication date.

Happy to be contradicted on this, though, if you really feel user-controlled sorting is important.

[NateWr]

And either way, dropdowns are out because they're not keyboard accessible. If we do go with a sorting option, just leave the links in and let me know and I'll handle the markup and styling as needed.

[beghelli]

I can think of some categories of sorting that people would benefit from, like by author, or most popular ones. But those can be achieved in a more efficient way by searching or via block plugins, in the case of most popular ones.

I agree with @NateWr that unless we have another specific use case, we can hold the sorting implementation for now.

[bozana]

@NateWr, ah, sorry, I didn't understand that you were suggesting to have the sorting options in the backend :-\ I think that both features are good to have, but maybe, as @NateWr said, maybe not now, as long the presses don't have so much books. LangSci plans to have 20 books per year and Edition Romiosini would like to import 200 digitized books ... thus I do believe that more sorting and filtering options for the reader would be good to have in the future. OK, I would then take a look at how to provide those different sorting options in the backend. Maybe to have the possibility (of defining how the books are sorted) for every series and category? Sorry for the misunderstanding! :-\

[bozana]

For series and categories there could be a new form element "orderBy" in their editor form. (The setting would be saved in the series/category_settings table, and the classes would get the appropriate get/set methods). OK? @NateWr, should the new form element "orderBy" be radio buttons? Or could it here be a drop-down-box? Or something else? Where to put the new form element for the catalog page? Somewhere on the dashboard > catalog > homepage page? Or settings > website > appearance? Or somewhere else? Thanks!

[bozana]

The sorting possibility for series and categories look like this now: Series and categories edit form:

Series and categories book listing page:

OK so?

[NateWr]

That's looking good @bozana. A couple of thoughts:

1. Go ahead and make the form field full width by removing the size restriction on the form section.
2. Try to get the form label ("Sort By") above the description. I think if you use a "label" value instead of a "title" it might work, but I can't quite remember. Might take some tinkering. Let me know if you can't get it going and I can play with that.
3. What do you think about changing "Sort By" to "Order of monographs" or "Sort Order"?
4. Would it be a pain to get options for order direction (without a second field)? I'm thinking options with names like this:
   • Title (A-Z)
   • Publication date (newest first)
   • Publication date (oldest first)
   • Series Position (Highest first)
   • Series Position (Lowest first)

[bozana]

@NateWr, cool, I think everything you mention is possible for me ;-) I will change it...

[bozana]

Maybe one more thing left to do: autocomplete for series position field.

[asmecher]

Thanks, @bozana! Merged.