Tue, Mar 2
Hey, @abian. Those are very valid and concerns, and we really appreciate you sharing them! We are aware that unfortunately some current issues will also be reproduced by the new application (e.g. querying for a specific date like 01-01-2021 will result in false positives, since 2021 with precision year will also be retrieved). In the context of the Query Builder, users will only be able to enter specific dates, and precision will be interpreted based on their input (we are yet to define how some values – e.g. years only – would be translated into SPARQL. This might be the key to alleviate some of the inherent issues with dates?). This data type is definitely a tricky one, and we wouldn't like to proceed being unaware of big problems. Since you seem to really have a deep understanding of the issue and its consequences, it'd be great if you'd be up for a chat?
Mon, Mar 1
Fri, Feb 26
Thu, Feb 25
Wed, Feb 24
Tue, Feb 23
Thu, Feb 18
Wed, Feb 17
Tue, Feb 16
Notes & doubts on initial attempt (WIP):
Sorry for not being more specific! There were yet some decisions to be made when I wrote this ticket. I think that those ("Add condition" and "Run query") are the only two buttons that should become full-width is smaller viewports, looking at @Charlie_WMDE's designs.
Mon, Feb 15
Fri, Feb 12
Thu, Feb 11
Thanks for the detailed investigation notes! The recommendation to not use the number input sounds sensible. Regarding validation, I lean towards embedding it in the QuantitySelector, since it would make the component reusable "out of the box" in the future, but 1. this is not a core component, so its reusage rate is way lower than that of a button, for example; and 2. I see how that contradicts the validation approach we've been following until now.
Wed, Feb 10
Hey, @Volker_E. The simple type=number input seems more convenient whenever users have to perform a single value input instead of modifying a default. We also considered this could be a core input type, on top of which the increment/decrement variant could be created.
Tue, Feb 9
Notes from Itamar's investigation:
Mon, Feb 8
Wed, Feb 3
It is entirely possible to instead have a prop that says something like inheritStyles=true or isStandalone=false.
The color of links should never be inherited, exactly; only the font-family, size, weight and line-height of embedded links should be adjusted.
Itamar and I had only an initial discussion on Mattermost, where the working idea of creating the WiKit link as a set of classes rather than as a component was introduced by him. I later brought up that approach to the hike while looking at the Link component ticket together, and detected the need for an investigation tick. I believe that the outcome of this investigation is an excellent starting point! Thanks so much, Bereket and Michael.
Please mind that our design system components (the ones already being used in new applications) actually live in this GitHub repo and this Storybook. You can also find our tokens and all sorts of documentation in both resources.
Tue, Feb 2
Feb 2 2021
Feb 1 2021
@Michael brought up this important question about the popover: