You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sorting by the Baseline column, the order seems to be (when "ascending" is chosen):
Limited availability
Wide availability
Newly available
That is not logical in any way. Since "ascending" is normally equated with "chronological", it would make more sense to order the
Wide availability (these became available first)
Newly available (these became available later)
Limited availability (these are currently becoming available)
Very conveniently, you could use an alphabetical sort as a proxy, where an "ascending" (chronological) sort of the Baseline would be a descending alphabetical sort.
The best solution might be to use an actual availability date (when and if you have it) even though the image in the Baseline column implies all properties in a given availability category are equivalent. But I don't think it's worth delaying a change to the sorting until then. This should be a very simple fix. No point in letting the perfect prevent the very good.
The text was updated successfully, but these errors were encountered:
Since the Baseline designation for a feature indicates a point in time, the sort order should reflect the date a feature became Baseline, which naturally produces the order you mentioned (newly, wide, limited - by default). This has the bonus side effect of showing more timely and useful information to page visitors compared to the order you suggested (which was also considered), given that widely available features tend to remain unchanged going forward. With the current setup, every visit to the website will show the features that most recently reached Baseline status, without any need for further clicking and scrolling.
@jcscottiii did I get anything wrong in the above?
the sort order should reflect the date a feature became Baseline, which naturally produces the order you mentioned (newly, wide, limited - by default).
This is correct and intended.
If you look at the raw data from the backend call and examine the low_date, you will see that the features are listed in chronological order of when the feature reached baseline.
@brandondrew: If you have any ideas on how we can make this clearer, let us know.
When sorting by the Baseline column, the order seems to be (when "ascending" is chosen):
That is not logical in any way. Since "ascending" is normally equated with "chronological", it would make more sense to order the
Very conveniently, you could use an alphabetical sort as a proxy, where an "ascending" (chronological) sort of the Baseline would be a descending alphabetical sort.
The best solution might be to use an actual availability date (when and if you have it) even though the image in the Baseline column implies all properties in a given availability category are equivalent. But I don't think it's worth delaying a change to the sorting until then. This should be a very simple fix. No point in letting the perfect prevent the very good.
The text was updated successfully, but these errors were encountered: