Closed Zodiase closed 6 years ago
First draft of the multi-line block design. See 6305ff90bba981ae63dcaf6a0e056468a5a4ab15.
The slider occupies the entire width to offer more precision when dragging. The input field is used for both displaying the current value and taking input from user.
Since this component is only going to deal with numerical values, both the slider and the input field support stepping. While focusing on the slider, left and right arrow keys can be used for stepping down and up, respectively. While focusing on the input field, up and down arrow keys can be used for stepping up and down, respectively. The stepping size is defined by the step
property.
For inline/compact design, we could potentially adopt this design from Adobe Photoshop:
The slider pops up by clicking on the dropdown menu button.
For now the component allows overriding the following conversion functions:
toSliderValue
fromSliderValue
toInputValue
fromInputValue
so technically it can support any type of raw data (such as a Date), as long as the conversions are done properly. Next step is to write the conversion functions for the dates.
The challenge is to deal with different temporal resolutions. I have two different approaches in mind.
First is using a mapping function to project the dates to values on a continuous scale. For example, Feb. 2010 would be 2010 * 12 + 1 = 24121
, then 24122 = 2010 * 12 + 2
means it's Mar. 2010. This way, for resolutions at year or month, we have one point on the continuous scale for each date and the conversion only depends on the resolution. This approach would have trouble representing days as they are not evenly distributed on this scale so the projection needs to be more sophisticated. Fortunately I don't think we need to worry about presenting days.
The other approach is using the combination of a starting point and an offset. With this approach we can conveniently use utility libraries like moment
to determine the date from startDate + N * months
. But we also need to calculate, in this example, how many months there are in between the start date and the end date for the slider. Also all the calculations would depend on both the resolution and the start date.
The current implementation uses the second approach.
In workspace where changing the dates is more frequent, a slider helps make it quicker and easier to narrow down the range. The addition of a direct input (e.g. text field) makes up for the lack of precision of the slider.
Need design for: