sul-dlss / dlme

Digital Library of the Middle East web application, based on Spotlight
https://dlmenetwork.org/
Other
20 stars 2 forks source link

Update how date range slider displays Hijri dates #895

Closed ggeisler closed 4 years ago

ggeisler commented 4 years ago

I'm creating a new ticket for this to clearly separate this issue from:

As noted in #845, the concern is that (if I understand correctly) the Hijri calendar starts with year 1, so displaying a value like "-500" as a label on the x-axis of the date range graph and as a value in the date range inputs doesn't really make sense.

Preferred solution

It's not clear to @jacobthill and I what is technically feasible but here is our preferred solution:

  1. For negative year values displayed on the x-axis, drop the minus sign and append "BH" to the year
  2. For positive year values displayed on the x-axis, append "H" to the year
  3. Do the same as 1 and 2 above for years displayed in the input fields
  4. Do the same as 1 and 2 above for years displayed in the active constraint label
71283802-381bc300-232f-11ea-918a-59635810489e

(Ignore the flash message shown next to the facet title; this would be very challenging to display nicely in the sidebar version of the facet, and I'm hoping it is not really necessary.)

Potential lesser solution

This is not at all ideal, but I'm worried that the input fields (item 3 above) might be more challenging than the other items, because it needs to be strictly numeric. If that's true, we might be able to get away with just doing:

  1. For negative year values displayed on the x-axis, drop the minus sign and append "BH" to the year
  2. For positive year values displayed on the x-axis, append "H" to the year
  3. Do the same as 1 and 2 above for years displayed in the active constraint label

and leaving the input fields displaying a minus sign, to keep the field numeric-only. It would be very awkward to use different formatting for the input fields versus the labels, but perhaps it will nonetheless be clear to the user (because the numeric values will still match) that "-500" in the input box is shown as "500 BH" on the x-axis.

I really don't like this solution, but bring it up as possibly better than doing nothing at all, if we can't do all of the preferred solution.

cbeer commented 4 years ago

If we do the preferred solution, how should we handle user input? Will they be typing H + BH (and, what variants of that do we need to support?)?

jacobthill commented 4 years ago

I think we should opt for the "potential lesser solution". I think having users type letters will be just trading one UX problem for another. This is not perfect but it is an improvement. I think we should also do the same thing to the Gregorian calendar view for consistency (e.g. BCE and CE).

ggeisler commented 4 years ago

@cbeer Good point, maybe that is reason enough to go with the lesser solution as @jacobthill suggests.

I'm on the fence about whether we should do the same thing for the Gregorian calendar (which is why I made this ticket specific to the Hijri version of the component). It would be consistent within DLME, which feels right, but on the other hand aren't people who use Gregorian calendars familiar with the meaning of negative dates in a component like this? But I suppose if we can technically do it for Hijri, it is worth doing for Gregorian and see how it feels.

jacobthill commented 4 years ago

Yeah my thought is that there really is no difference between Hijri and Gregorian in this respect except that people are more likely to understand negative to mean BC. There is a precedent with Hijri. Its just not as commonly used because the Gregorian calendar is still in use and people can convey the same idea by referring to the Gregorian year instead of (e.g. 300 years before the Hijra). I think we want the UI to educate people in this respect and having consistency between the calendars will, hopefully, contribute to this end without having to add flash messages or other things to convey the point.

mejackreed commented 4 years ago

@jacobthill @ggeisler I've implemented this in English. But I'm curious, how should this look in Arabic?

Screen Shot 2020-04-03 at 3 10 26 PM Screen Shot 2020-04-03 at 3 09 57 PM Screen Shot 2020-04-03 at 3 09 53 PM Screen Shot 2020-04-03 at 3 08 23 PM

ggeisler commented 4 years ago

@mejackreed You mean how should the "BH", "H", "BCE" part of the labels display in Arabic?

If so, let's see if @jacobthill knows. I'm not really sure if there are Arabic translations commonly used for those, and if so, will they reasonably fit into the limited horizontal space we have to work with.

mejackreed commented 4 years ago

Yes exactly that question, thanks for clarifying Gary.

jacobthill commented 4 years ago

I have a message out to QNL.

jacobthill commented 4 years ago

This is what we should use:

CE: م H: ه BCE: قبل م BH: قبل ه

cbeer commented 4 years ago

To the left or right of the digits?

mejackreed commented 4 years ago

I've implemented it one way.. not sure if this is correct, but maybe something to react to?

Screen Shot 2020-04-07 at 8 37 58 AM

jacobthill commented 4 years ago

@mejackreed the green font seems correct but the black font at the bottom of the histogram should have the number to the right of the Arabic text

jacobthill commented 4 years ago

Which font are we using here? I think this was one of the problems mentioned: the م which indicates 'Milady' (Gregorian) is missing the tale that hangs down which makes it look very similar to the ه which indicates Hijri.

mejackreed commented 4 years ago

This is the current font deployed in our environments, Mada.