Revise browse category feature to include sub categories

[jacobthill]

We decided to use the browse categories feature for time categories initially rather than building a dedicated feature. The downside of this is that now we can't use browse categories for other things. As an exhibit curator, it would be ideal to be able to create more useful categories for the landing page, etc. Things like "Arabic Manuscripts", "Modern Art", and "Cairo Genizah" would be useful but we need to keep the 'browse by time' feature we've already implemented. I'm not sure how this should be implemented technically but one possibility would be to simply duplicate the browse by category feature and call the copy browse_by_time or browse_by_category_two. I don't know if that will work or lead to other problems.

[ggeisler]

@jacobthill @anarchivist Below are some mockups of the proposed solution from the access team. This solution involves creating a new feature that enables the exhibit curator to create "browse groups" and then assign browse categories to a given browse group. The browse groups are then displayed to the exhibit visitor on the browse landing page as filters; the visitor can see all browse categories as a flat list (first mockup below), or can select a filter to see only those browse categories in the associated group (e.g., in DLME, select the "Time period" filter to see only the time period categories, as in the second mockup below).

This solution would be a new feature for Spotlight generally, and would be useful to several existing and upcoming Spotlight at Stanford exhibits, and potentially useful to other institutions that are using Spotlight. The access team estimates 2 - 4 weeks of development time to complete the feature.

Not mocked up yet but we also discussed making a related new feature page widget that would enable the exhibit curator to embed a browse group on a page, similar to how we can already embed browse categories on pages. For example, when this feature is completed, we could supplement or replace the three browse categories tiles on the DLME homepage with several similar browse groups tiles, which would take the user to the browse landing page showing only the browse categories for that group (e.g. Time period categories or Type of manuscripts categories, etc.).

Exhibit visitor examples

---

---

Exhibit curator example (creating groups and assigning categories to a group)

[anarchivist]

Thanks @ggeisler.

Are there any presumptions in the "All" display regarding sort order, or the number shown? (I'm a little confused since "All" in the first mock shows a subset.)

For example, would the expectation be that it would list all the categories within the time periods browse group first, and then cultural artifacts, etc.?

[ggeisler]

@anarchivist Good question. The mockup only showing a subset was just an artifact of trying to fit enough to show the idea in a reasonable amount of space.

My assumption is we would just follow the order of the browse categories on the Browse categories admin page, as we currently do, just ignoring the group. So the result is yes, the order would follow the grouping order, in the order the curator has positioned the groups on the admin page.

There can also be categories that haven't been assigned a group, and they can be positioned anywhere (a category not indented under a group heading would be displayed under "All" but not under any specific group filter). So for example in the arrangement below:

the browse landing page order when the "All" filter is on would be:

• Paintings
• Calligraphy
• Graffiti
• New Museum of Contemporary Art, 1986

(Not represented in the mockup, but non-grouped categories could also come at the top of the list, or in between groups. So there could be categories interleaved between the categories that are part of different groups.)

Definitely let me know if you have other suggestions (I still have some work to do on mockups before creating tickets for the feature), but this approach would, I believe, be the most straightforward to implement it given the way the browse categories admin page already works.

[anarchivist]

OK, thanks! I think that's fine and I have no concerns. I might be curious to get some feedback from the Spotlight service team on this too.

[ggeisler]

I described it at our last service team meeting a couple of days ago. Everyone liked the idea (though I described it verbally since I wasn't screensharing). In fact, Andria said it would solve a problem with an upcoming exhibit she is working on.

[anarchivist]

Great, thank you!

[jacobthill]

One potentially new requirement of QNL's request for a Netflix like browser on the home page is the ability to link one sub category to multiple top level categories. (e.g. the sub category "Persian Literature" could be linked to a top level category of "Literature" and also a top level category of "Language Learning")

[ggeisler]

@jacobthill I'm not sure what you mean by "could be linked" and so I'm unclear whether you mean:

1. A browse category ("sub-category" in your description) should be able to be part of more than one browse group ("top-level category" in your description)

2. When a browse category is displayed on the page using the browse categories widget, it should be linked (i.e., when the user selects it, they are redirected to) to a browse group page (or, somehow, the user can choose from more than one browse group page to be redirected to)

I could use a more concrete description of what the expectation is, from the end-user perspective, and how this relates to the idea of a horizontally scrolling list of browse category tiles on the homepage.

[jacobthill]

@ggeisler I mean option 1; a browse category can be part of more than one browse groups. I think the idea requested by QNL is that browse groups can be displayed on the homepage as rows that scroll horizontally. The items in each row would be the browse categories created by the curator. One of these browse groups could be "Language Learning", for example, and another could be "Literature". The browse category "Persian Literature" could be found in both rows so that we aren't forced to implement the relationship between browse groups and browse categories as a rigid hierarchy. I think this will improve discoverability in some cases and enable us to meet our obligation in year 2 of this grant to adapt DLME for specific user groups (e.g. foreign language teachers/learners, or art historians).

[ggeisler]

@jacobthill Okay. I think this something we'll need to discuss as a team when we get to evaluating resource and priorities. It's not a trivial change. When designing the browse groups feature, we purposely designed it as a 1:N relationship (a browse group can have many browse categories, but a browse category belongs to at most one browse group). For it to be a M:N relationship significantly complicates the design of the admin UI to support assigning browse categories to groups, so I'd have to start over on that, and it might or might not complicate development of the feature.

Note that for your use case, it would only be necessary to make the feature a M:N relationship if we were creating a new widget that enabled the curator to simply pick a browse group and then for the rendered widget to display all browse categories in that group. That would certainly be quick and easy for the curator.

However, if the curator had to select the browse categories manually then there would be no requirement for a M:N relationship; the curator could select to include the "Persian Literature" category for the "Language Learning" instance of the widget, and then select it again when setting up the "Literature" version of the widget. The result on the rendered page would be the same for the exhibit visitor, it just requires some extra work for the curator when configuring the widget.

Alternatively, we potentially (meaning, I'm not considering technical feasibility concerns that might come up) could implement the easy version of the widget (where the curator just selects the browse group and it automatically includes all that group's browse categories) and satisfy your case without requiring a M:N relationship if the curator creates the "Persian Literature" multiple times, once for each browse group they want to assign it to. Again, it requires a bit more work for the curator but it would produce the desired result for the exhibit visitor and eliminates the need to figure out a new admin UI design and deal with possible related technical complications to support a M:N relationship.

[jacobthill]

@ggeisler I'm not sure I understand but I think you are suggesting three possible approaches:

1. Implement a M:N relationship and a new widget that enables the curator to create a group and then select which categories belong to that group. This is easiest for the curator and hardest for the design and possibly technical implementation.
2. Sounds like the only difference from this option and option 1 is the widget that displays the categories in a hierarchical relationship under the group. This one seems the least clear though so I may be misunderstanding something.
3. No changes are needed on the design or technical implementation; the curator makes duplicate copies of the same categories and assigns them to groups as needed.

I would like to avoid option 3. I think it will be really hard to keep copies of groups in sync. I imagine they will drift quite a bit over time. Option 2 sounds like it may be the way we want to go. Can we clarify if my understanding of this option is correct? If I can create one "Persian Literature" category and then select which groups it belongs to I think that will be sufficient.

[ggeisler]

@jacobthill Yes, I guess I was suggesting are three potential approaches, though I'll restate them below to be more clear.

1. Change the current design to make browse groups to browse categories a M:N relationship instead of a 1:N relationship. This would be easiest on the curator if we implement the requested feature in #1066 as one that automatically includes all browse categories in a browse group. It would require a significant redesign of the curator UI and interaction related to creating browse groups and assigning browse categories to them (because the UI would have to support the curator putting a browse group into more than one browse category). It might or might not be more difficult to implement than the current design.

2. Instead of the requested feature in #1066 as one that automatically includes all browse categories in a browse group, require the curator to configure it by manually assigning browse categories to the #1006 widget. It would be more work for the curator, who now has to manually assign the categories in the widget (though this is the way other Spotlight widgets work), and wouldn't automatically reflect new browse categories added to a browse group. But it wouldn't require changes to the current design, because the browse groups to browse categories relationship could remain as 1:N.

3. To overcome the drawbacks of Option 2 and enable the #1006 widget to automatically include all browse categories in a browse group, but also not require we change the relationship to M:N (and redesign the curator UI), we could require the curator to create multiple instances of a browse category (based on the same underlying search parameters) and assign each instance to a different browse group. I'm not sure your concern about keeping these multiple instances in sync is something to worry about; browse categories are based on one or more search parameters and automatically reflect whatever items match those parameters, so two browse categories based on the same search parameters will always contain the exact same items, with no manual syncing needed by the curator. The only issue there would be if the curator decided to change the underlying search parameters for a category with multiple instances; they'd have to make the change to each instance. But changing the underlying search parameters for a browse category seems like a really rare thing to want to do.

So to answer this:

Option 2 sounds like it may be the way we want to go. Can we clarify if my understanding of this option is correct? If I can create one "Persian Literature" category and then select which groups it belongs to I think that will be sufficient.

If by "If I can create one "Persian Literature" category and then select which groups it belongs to ..." you mean doing that work in the homepage widget represented by #1066, yes that's Option 2 as described in this comment. But that does mean the homepage widget would not autopopulate; the curator would need to do the manual browse category assignment (I don't see that as a big deal, personally. You'd likely configure it once and maybe update every now and then when you've created some new browse categories or want to vary the look of the homepage).

A previous conversation I had with @mejackreed might raise an additional option:

Rather than try to satisfy #1066 with a generalizable Spotlight widget, we could potentially do something completely custom for DLME, in which case there might be some variations of the above options that would be quicker to implement. We'd just give up the potential of applying this effort to a Spotlight widget that could be used in implementations other than DLME. If we went that way, this ticket is not affected, and we'd just have to work out a DLME-specific solution to #1066 based on browse groups/categories having a 1:N relationship.

[jacobthill]

@ggeisler thanks for the clarification. I think option 2 is fine.

[jacobthill]

@asmaaalkuwari, @mwerla, I'm assuming you are ok with the design on this ticket. Our developers are going to start working on it.

[mwerla]

@jacobthill We don't know what is the final design that you are planning to implement. Can we discuss that on Wednesday's call? One thing that doesn't make much sense for me, looking at the designs provided in the beginning of this issue discussions (https://user-images.githubusercontent.com/101482/88421756-f14aeb80-cd9d-11ea-94ba-c1de8477b91d.png) is the "All" option for the public part of the interface, where the user will see mixed tiles from different browsing categories.

[jacobthill]

@mwerla I have added it to our agenda for tomorrow's meeting.

[jacobthill]

@ggeisler, @caaster in our meeting today we discussed the need for the "all" category and it wasn't entirely clear. One thought was that maybe there are categories that a curator doesn't want to put in a group, e.g. a one off category with no siblings. This category would still need a place to show up, hence the "all" category. But then we thought maybe an "uncategorized" or "other" category might be a good catch all for this case and there wouldn't be a need to include categories that were assigned to another group. But we realize this is a feature with broader interest and so maybe we are unaware of some other needs for the "all" category. Are you aware of other use cases? Or, of not, how do you feel about the "other" or "uncategorized" option?

[ggeisler]

@jacobthill @mwerla The "All" group might not make sense if you only think about it from a DLME perspective and the DLME plan is to put every browse category you create into at least one browse group. But we're developing this as a general Spotlight feature and from that perspective I believe we absolutely need an "All" group:

• I don't expect the curator of every exhibit that chooses to use browse groups to assign every browse category to a group. In fact, I think it will be fairly common to create a few browse groups for special "topics" useful for organizing some browse categories but have other browse categories that don't fit into those topics and aren't assigned any group. In that situation, the only way a user will ever see those unassigned browse categories (unless they happen to be used in a browse category widget) would be in the "All" group. Note that this situation of unassigned browse categories might occur intentionally or unintentionally (many Stanford exhibits have multiple curators working on them and in that scenario it will be easy for one curator to have a plan for the browse groups that the other forgets when creating a browse category; or, even a single curator can forget when creating a browse category to assign it to a group. We've effectively done that ourselves on exhibits.stanford.edu where we've published a new exhibit and forgot to assign it to a category).

• Even if the exhibit plan is to assign all categories to a browse group, the "All" category is useful:

• First, just because you have filters the user can use to see the different browse groups doesn't mean some users might not prefer to just see all the categories at once. It's arguably a bit easier to scroll a few times and scan over 100 browse categories than it is to click on 5 or 6 filter buttons and scroll once on each of those group pages.

• Second, if you don't have an "All" group, what is the default page for the "Browse" link in the main menu? It would have to be the first named group you have ("Time period" or whatever is your first filter). That's not a terrible UX issue, but I don't think it's ideal to put a user who selects a general menu title like "Browse" to next find themselves in a specific subset of browse like Time period. The user should choose which subset they are interested in, not be forced into it.

(To understand more concretely my argument above, visit https://exhibits.stanford.edu/ and imagine we don't have the "All" filter. When a user clicks a link somewhere to https://exhibits.stanford.edu/ they would find themselves looking at the Arts & Humanities subset even if that is not at all interesting to them.)

So, again, I am certain we want to include the "All" filter as outlined in https://github.com/projectblacklight/spotlight/issues/2567

That said, I'm much less opinionated on what we do in DLME. If you two want to override the default behavior to either rename the "All" filter, or eliminate it altogether for DLME, I'm not opposed to that. Renaming the filter is probably a very simple i18n override. Eliminating would certainly be more complicated but perhaps possible. I'd suggest, however, we wait until the feature is developed and integrated into Spotlight. We can then see how it looks in DLME discuss how strongly you feel about overriding the default behavior and what technical effort would be required to eliminate it.

[mwerla]

@ggeisler I get your point. I think it strongly depends on the nature of browsing group definitions. In the Stanford exhibit case, the groups are defined in a way, that makes them still look "good" when mixed together. I was initially thinking about other, much simpler approach - for example, categories like MENA countries, types of objects, date periods, content by language, and so on. In such a case, having one huge list with categories from all the simple groups mixed together would be quite confusing. That's why I proposed to remove the All button.

After re-thinking this, I agree - let's go ahead with the "All" button included for now and we can revisit if we really need to hide it, once we have the groups and categories defined for DLME. From the discussion yesterday, if we remove the "Browse" button from the DLME top menu and link the "Browse" page a way that it will be applying one of the categories filter (the per category "View all" button), I think the "All" button will not be a big issue.

[ggeisler]

@mwerla

After re-thinking this, I agree - let's go ahead with the "All" button included for now and we can revisit if we really need to hide it, once we have the groups and categories defined for DLME.

👍

From the discussion yesterday, if we remove the "Browse" button from the DLME top menu and link the "Browse" page a way that it will be applying one of the categories filter (the per category "View all" button), I think the "All" button will not be a big issue.

I wasn't involved in the discussion and I don't think it's important now, but I'm surprised to hear there is a plan to remove the "Browse" link from the main menu. After we expand the browse categories it obviously should be renamed from "Browse by Time Period" to just "Browse" (which will fix the wrapping issue at some viewport widths), but it seems important to have a prominent link to an important mechanism that enables users (especially new and non-expert users) to explore the DLME collection without having to make the effort to formulate a search on their own.

[jacobthill]

@ggeisler I think the point is that in DLME the "Browse" view will be superseded by the categories on the home page. The results will be exactly the same with a slightly different presentation. All categories and groups that would show up in "Browse" will be available on the home page. There is no real value in providing the same results in this slightly different way, at least none we could think of. However, if you can think of something we didn't consider, we can revisit this decision.

[ggeisler]

@jacobthill Okay. Again, I'm happy to wait until we get the browse groups feature and home page thing done and we can see how it all works together. I will say two issues immediately come to mind:

• Are we really going to put all browse groups on the homepage? If we only create three or four groups that might work. But how would six or seven rows of that widget look on the homepage? It'll make for a long homepage, requiring scrolling to see everything even on a large display. And if we assume we won't create more than, say, four groups, I'd worry that we're limiting our possibilities of useful groups because of a dependency on having to display them all on the homepage.

• Do we really only want to provide access to the browse categories from the homepage? A user might notice them on the homepage, visit another page on the site or do a search, and then decide they want to check out the browse categories. With a "Browse" in the main menu they can immediately find and go to the browse categories; without a "Browse" in the main menu we're forcing the user to remember and go back to the homepage to find them.

[ggeisler]

@mwerla To your earlier comment about the "All" filter:

In such a case, having one huge list with categories from all the simple groups mixed together would be quite confusing.

Note that the exhibit curator (e.g., Jacob) can easily control the display order of browse categories. So, for example, if we have groups called "Cultural object", "Time period", and "Geographic region", we can order the categories such that all of the "Cultural object" categories are listed first, followed by all of the "Time period" categories, etc. I don't think this is likely to be that confusing to the user.

[jacobthill]

@ggeisler I think the assumption was that we would put all categories on the home page but if I am happy to try that and adopt a more selective approach if it effects usability in a negative way. The second point is well taken, but I'm not sure an almost identical copy of the same information is the solution. I think we could fix that by renaming the "home" page to "browse" or "explore" for example. In any case, I think the plan is to see what everything looks like before making a final decision.

[mwerla]

@ggeisler I will try to summarize the "design process" that we had: 1) We wanted to have an engaging main page, which will present the rich and diverse collections of DLME and will make the user go deeper. The "Find items by" section on the left didn't look very engaging and the clickthrough stats were showing that the time-based browsing available from the main page is quite popular. So the idea was to have more visual browsing capabilities right from the main page. I assumed that, going "Netflix style" we could have all browsing on the main page - many rows (yes, require scrolling down) and many items in a row (yes, requires scrolling/navigating horizontally). 2) As a part of the UI design, it came out that the controls for horizontal scrolling within a row are problematic we also want to have the "View all" option, which links to the Browse page with a preselected category. This way we ended up having two places on the website (the main page and the browse page), doing very similar things in a bit different way. And this has the potential to cause confusion among users.

I see the two possible options:

1) We assume that the main page is also the main browsing page. It has all categories presented as rows (requires scrolling down to see all categories). From a single category row, we can navigate to the "View all" page (the original "Browse" page), which shows groups from a given category (pre-applied category filter). If the user wants to go back to see all browse options, he/she has to navigate to the main page (which may be also linked from the "Browse" button in the main menu).

2) We assume that the main page is just something that fits one average (desktop) screen, without scrolling. It has the "Find items by" box, it also has a few (I guess 3 max if we want to avoid scrolling) rows presenting selected categories and something that encourages the user to "Browse all categories", which links to the Browse page. The Browse page is the with all browsing groups, with the possibility to filter by categories.

In both cases, to see all groups and all categories, it will require scrolling - on the main page (in option 1) or on the Browse page (in option 2). In my opinion, option 1 utilizes the main page much better and increases the chance of keeping the user. In option 2, we have a clear Browse page, but the main page is something that is not intended to entertain the user - he/she is supposed to click on something that will take him/her further into the page. I think that option 2 will result in a higher bounce rate because in option 1 the users will immediately (without leaving the page) see a broader scope of content than in option 2.

If the implementation of all the discussed features will be done in a flexible way, and the final choice between the options above will be just a matter of configuration, then let's wait for that opportunity to experiment. But if the developers will not be able to make it flexible, then we should choose one option now.

[ggeisler]

@mwerla I think we can move forward with the design of the horizontally scrolling row of browse categories (#1066) without deciding between the two options you present above (I'm working on finalizing the design details of that now).

But I don't think we can easily move forward on how the site is going to work in terms of what the user sees when they select the "View all" link from a horizontally scrolling row of browse categories, or what the user sees in the site main menu, until we make a decision between your two options. The first option would involve customizing several aspects of the application, while the second option would mostly involve adding something to the homepage to encourage the user to "Browse all categories" as you said (although I'm not convinced that is necessary with option 2, since the user who selects the "View all" link will see the availability of other browsing filters and the "Browse" link in the main menu is always visible).

So option 2 is less work and less divergence from the Spotlight codebase.

But you seem to prefer option 1, so I'll offer a couple of examples of how I think could work, though again, that option requires more customization of the application so we'll need @mejackreed to look at feasibility if we decide we want to go with that option.

First, if we went with option 1, I'd suggest we use the term @jacobthill suggested, "Explore", instead of "Browse". In English, at least, I think Explore is a better term for the homepage than Browse, and Explore feels a little more broad so it can include the search facets within it a bit more naturally than Browse.

Assuming we did that, below are some examples of how it might look:

Homepage, renamed to Explore, contains all browse groups in horizontally-scrolling rows:

Group page (when user selects "View all" for a row):

Category page (when user selects a browse category from either a homepage row or from the group page):

---

This option (at least as I've represented it above) would involve customizing at least these things in the DLME application; that is, overriding default Spotlight behavior (there are very possibly some other things I'm not catching):

• Main menu to rename home (not currently part of the main menu configuration)
• Updating breadcrumbs to eliminate use of "browse" and reflecting there is one less level of hierarchy
• Removing "browse" from the category page search label
• Overriding how the new browse groups feature links to browse group pages (to omit the filters)

[mwerla]

@ggeisler Thanks for the latest design, I really like the simple user flow that we would achieve with it. If there are no serious technical difficulties to implement this (@mejackreed ?), my opinion would be to go ahead with it.

[mejackreed]

Divergence from upstream codebases does cost overhead here. One thing that might cause some problems are:

Updating breadcrumbs to eliminate use of "browse" and reflecting there is one less level of hierarchy

I'm not sure how much of a problem until we get into it.

Also:

Overriding how the new browse groups feature links to browse group pages (to omit the filters)

May also become troublesome.

None of this is "we can't do it", but more along the lines of will we have the time.