Convert separate Hijri and Gregorian calendar view to single view with toggle

[jacobthill]

The separate calendar views have led to some confusion during our user testing. The behavior was initially confusing and was made more so by https://github.com/sul-dlss/dlme/issues/1027. Some users expected the two calendar views to stay aligned (e.g. sliding one would slide the other). The use case for two separate calendar views is also non-existent; the user would choose one but never need to use both together. I believe it was implemented this way because it was less challenging technically but a single calendar view with a toggle to switch between Hijri and Gregorian would be preferable. This is a request from our colleagues at QNL and the user experience angle makes perfect sense to me. We need to either implement the single calendar with toggle view or, if this is not technically possible, we need to document in a clear and succinct way why it isn't possible so I can communicate this to our colleagues.

[ggeisler]

I think the first pass at this is a technical feasibility discussion and the outcome of that might very well be that it just isn't feasible to do what QNL is requesting. But in case it is feasible, here's the UI approach for using a single Date range slider I proposed earlier in the project:

Single date range facet in sidebar

Single date range facet in the "view larger" modal

[cbeer]

Anything is technically feasible. I think we rejected this approach earlier because we'll need to completely rewrite the date range widget to get the interactions you might expect (like being able to flip between the calendar systems and have the same range selected).

[ggeisler]

Yep, I believe you're right. I just couldn't find any Github documentation of that concern (I think it was discussed in standup or planning conversation and so my first ticket on this assumed the two separate calendar-specific facets) so want to document what I think QNL is suggesting, and what the challenges with it would be.

So far the only other approach I can think of is to make the user select the calendar system first, then show the date range slider in that calendar system:

But I don't know how easy it would be technically to present that to the user first and then replace it with the actual date range slider. And it seems like a less-than-ideal user experience to have to make that explicit choice every time the user wants to use the date range slider.

[jacobthill]

If we go with the toggle option in the mockup I don't think it will be necessary to keep both calendars synced. I think that is only important when both calendars are displayed at the same time. If we implement the calendar toggle the default behavior could be to reset the range on toggle, if that is easiest.

[ggeisler]

If we go with the approach in the mockup in my previous comment above, it might help the user experience if we can make the Gregorian/Hijri choice "sticky" so that a given user's previous choice is shown by default on a subsequent visit to the Date Range facet.

[jacobthill]

@mejackreed if we decide that it is not necessary to keep the range synced when toggling between calendar systems does that make this easier to implement? I think this is one of the tickets that a rough estimate of time required would be helpful.

[mejackreed]

@jacobthill both of the approaches seem to go outside of current bounds of what the Blacklight Range Limit plugin can offer out of the box. Because of this, I estimate this as a large piece of work for initial implementation. It also has longer term maintenance ramifications by diverging from community maintained software to a custom solution.

if we decide that it is not necessary to keep the range synced when toggling between calendar systems does that make this easier to implement?

Yes, probably. But still does not make creating a new range limit system from scratch a small effort. It is still a quite large piece of work to implement the requested functionality.

[mejackreed]

It is also unclear to me if this ends up helping with #1027. Without exposing in some way the genesis of the date range data, it seems like #1027 might persist.

[jacobthill]

@mejackreed thanks for the clarification. It seems like a dual calendar plugin could be useful in other exhibits as well. Is there a way to implement this so that it could be pushed back up to spotlight, and maintained by the spotlight community?

[mejackreed]

I don't yet see that path of reuse at the moment because this is the first time I've heard of the use case of the multi-calendar year range problem. If we have a better understanding of the other use cases this type of plugin might solve that would help, but I'm not sure I've heard of similar things within the broader Blacklight/Spotlight communities before.

[ggeisler]

I'm also not aware of any other use cases in the community for this.

[jacobthill]

I just want to through this out for consideration. There is a project–LODE (Linked Open Date Entities)–that is thinking about this in a sustainable way. The idea is to standardize date metadata for use across applications. Adoption will enable:

• Finding equivalent dates across calendars
• Translating date strings to other languages
• Standardization of visualization and navigation software

I only found one other aggregation project that provides date search at all. It is a hard problem. We are asking for date search in two calendar systems. I know this is a big ask. I think this highlights two things for me:

• maybe we are trying to do too much; we should revisit this with QNL
• maybe this is more useful than we might think. I mean, the fact that we can't think of any other use cases may not be due to the fact that there are none; it may simply be due to the fact that most developers think it is too complicated to be worth implementing, and most metadata would not support it. Clearly date search is useful but Europeana, DPLA, etc. don't implement it. This is not because there is no use case; its probably just too much work. Which makes me think that maybe use cases will emerge if the technology exists.

I'm wondering if we can actually adopt something like LODE (Linked Open Date Entities) and build a tool that could be more useful for other projects. I'm just throwing this out there for consideration. I think it might be more work in the short term but may make maintenance easier. I'm curious what others think. I realize if this gets more complex, it may get pushed (at least in part) to a future work cycle. It also might be something that we could seek out dedicated funding for.

[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 decision/proposal from your side. Looking at the discussion above, it's hard to see any clear conclusion.

[jacobthill]

@mwerla this is the proposed design solution

A user selects Hijri or Gregorian. One will be the default and we will try to make this selection sticky so that if a user selects Hijri the default will stay Hijri for that user.

[mwerla]

@jacobthill Thanks for the clarification. This option is fine for us. Looking at the usage stats, Gregorian calendar should be the default selection.

[ggeisler]

EDIT: I guess this was already discussed above and it was decided it is okay if the calendars aren't synchronized when the user switches between them (hard to remember all the past discussion). So I think you can safely ignore this comment.

@mejackreed You might already have a plan for this, but note that if we go with the mockup version @mwerla okayed above, we need a strategy for the case where a user has made a range selection using one version of the calendar and then switches to the other.

The ideal strategy would be to just translate the user's current selections to the other calendar system (e.g., I've selected Gregorian with a range of 300 to 1900. Then I change the radio button to select the Hijri calendar. We ideally update the inputs to whatever the Hijri equivalent to 300 and 1900 are). But based on prior discussion, I thought that was not feasible.

If it is feasible, great, we should go with that. If not, I assume we will just reset the date range selections to the defaults. That will be a minor annoyance to the user who then has to reenter the values, but I don't think necessarily outweighs the simplicity of this approach (versus the mockup I did after that, which avoids the problem by making the calendar selection a separate step, but makes it more complex and an extra step for the user that is always using the same calendar system -- which I expect is most users).

[mwerla]

@ggeisler I checked in DLME's Google Analytics, and it seems that in the period of Sept-Dec 2020 there were in total 23 sessions where both Hirji and Gregorian filters were used in the same session. It's a bit less than 0.6% of sessions from this period. For me, it confirms, that the resetting of date ranges to defaults on the switch between calendars will be a minor problem.

[ggeisler]

Great, thanks for checking that @mwerla.

[mejackreed]

@asmaaalkuwari Could you please assist with the translation of Calendar: to Arabic?

See below for context

[mejackreed]

Note: "View larger" piece spun out into another ticket #1112

[jacobthill]

@ggeisler, @caaster and I are having trouble finding the Date Range (Gregorian) facet label. Do you know where that is?

[mwerla]

Testing on dev environment. Missing label for the Hijri version in English interface.

[mejackreed]

Thanks @mwerla we saw this too and are tracking here: https://github.com/sul-dlss/dlme/issues/1132

[mwerla]

Test case: 1) I open DLME main page 2) I expand Date range facet - I see Gregorian filter with date range -11000 to 2020 3) I switch to Hijri - I see Hijri filter with date range -11979 to 1799 4) I change my mind and switch back to Gregorian - ERROR the result is mixed Gregorian/Hijri:

• Chart axis is Gregorian
• Chart tooltip is Hijri
• Date range is Hijri

5) I continue with buggy Gregorian and set the filter to 210 - 1800 and click apply - ERROR I get search results filtered by Hijri

[mejackreed]

Tracking this in #1134

[asmaaalkuwari]

@mejackreed the translation of the word "calendar" is : التقويم