Enhance year filter to indicate the full temporal range of returned results

[mradamcox]

Our first implementation of a year filter (driven by the index_year field) is a basic slider like this:

One way we want to improve upon on this is to indicate to a user that while a result may fit in their desired range, that result itself may actually contain data that extends beyond the filtered range. For example, a certain item may be released every year from 2010 to 2020, but the user has set a range of 2012 to 2018 in the slider. Of course, this item should be returned, but we want to go further to communicate the dataset's full range to the user.

In other words, nothing will change about the input of the filter, selecting 2012 to 2018 will still only return results with an index_year that falls within that range. However, an extra, calculated piece of information (the true min/max of the returned filter results) will also need to be passed to the filter and displayed somehow.

Here is a design that @shubhamk008 has drafted for doing this, with the lighter-purple bars extending beyond the sliders to indicate a full returned data range of 2010 to 2020.

Implementing such a slider would be a fair bit of work, as it's unlikely we would be able to adapt the basic MUI slider we have to add these components. So, we wanted to discuss details of this implementation further before diving in.

Other ideas that came up during discussion:

• In addition to the bars, perhaps a hover "tooltip" would have an explanation when the user moves the cursor over the extended bar.
• Instead of the extended bars, we could add a text notation below the bar, something like

  Current results include data from before and beyond your selected filter (2010-2020)

[Makosak]

It may be a lot of work to investigate all the potential actual years of data used in each data product/data release. In lieu of that, potentially we have a fuzzy bar on either side that's just a visual, and notes that "actual data may cover multi-year ranges in the data products selected" etc?

for ex, ACS data from 2019 can be a multi-year average at 5-years, 3-years, or 1-year. We're recommending folks to go with 5 years because it will have greater precision. If we really want to drive home that the year of data release is a multi-year range, that visual trick could help...

Or if it ends up being more confusing, we could just put those notes elsewhere! If it's too much for now, okay to boot to "future work" to be discussed, etc

[pengyin-shan]

As a reference on the development side, the MUI library, which serves as the foundation for most of our components, allows some customization of its slider component, including start and end labels, ticks, and a customized background color (though only one color), as shown below:

We used this to save development time and ensure all components maintain a unified style so far in the discovery app.

The challenge with our customized slider (above) is the second layer for the actual years (the purple area around both arrows) and the "2012-2018" label. To my knowledge, the MUI library cannot be customized to this level. Therefore, we would need to create this from scratch for the full implementation of this design or find a new library.

As a result, developing this component will take significantly longer than other components, but it is totally achievable. For now, I'm considering drawing each segment on a <canvas> element and then adding animations. The advantage of this approach is that everything will be fully customizable; however, the downside is the time required. If we choose this route, we could postpone the development of this to the second stage after the soft launch in September so that we can focus on major functions first.

Alternatively, if we modify the design so that the design requires only archievable customized from the MUI library, the development time might be shorter. For example, if we display "2012" on one tick and "2018" on another instead of doing "2012 - 2018" as a whole, we could leverage the MUI library and save some development time. I'm open to either approach.

[mradamcox]

@Makosak The Aardvark schema does have more date-related fields that we could take better advantage of, like "date rage" or "temporal coverage." So, we could fill these out more regularly, and utilize them to provide this range to the front-end.

Personally, I think this could be created and implemented by the end of Sept, we would need to budget 1-2 wks for it. But we would need a little more clarity on the design, specifically (building from what @pengyin-shan has mentioned above):

• What do the top labels look like when the sliders are farther apart?
  • Does each label follow its slider? If so what happens to the hyphen/emdash that is in between them?
• What happens when they are very close together?
• Should text be introduced below the slider that explains the expanded visual range, when applicable? If so, what does it say?
• Are there other hover tooltips associated with the slider?
• How does a user disable the filter?
  • With a single time range, the intuitive way to do this would be sliding each mark to the far end. However, with the multiple time ranges depicted above (when the toggle is clicked the min of 2000 would change to the real min of the data, currently 1963) this method for deactivating the filter wouldn't work.

I'd say that once we have the answers to these questions we can start on it.

[shubhamk008]

Would something like this work for React?

import styled from '@emotion/styled';

// ... (other imports)

const StyledSliderTrack = styled('span')`
  position: relative;
  height: 4px;
  background-color: #ccc;
  border-radius: 2px;
  cursor: pointer;

  &::before,
  &::after {
    content: '';
    position: absolute;
    height: 4px;
    background-color: #ccc;
    border-radius: 2px;
  }

  &::before {
    left: -2rem;
    width: 2rem;
  }

  &::after {
    right: -2rem;
    width: 2rem;
  }
`;

I did some research and of course I'm not sure if it would work because it's React. If this helps:

• Rail: The base track of the slider that runs horizontally or vertically.
• Thumb: The movable element that represents the current value on the slider.
• Track: The part of the slider that appears to be underneath the thumb and may change appearance based on the thumb's position.
• Mark: Small vertical lines or ticks that indicate specific values or steps along the slider.
• Value label: A label that displays the current value of the slider.
• Handle: Another term for the thumb.

So what this code is supposed to do is add a 2rem the left and right of the thumb.