@AronManning I think a tool like MMV is exactly the kind of thing that could really benefit from a Vue.js re-write. The UploadWizard tool is another.
Thu, Jan 23
We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).
@dbarratt regarding need for a build step: there's some discussion of this in the original RFC; it's true that React can be used sans build-step with the CreateElement API.
Wed, Jan 22
I wanted to join in this discussion earlier, but I spent the last two weeks fighting off the flu. Thanks to everyone who has participated so far, it's great to see interest in this topic. I'd like to try and speak to a few points that have been raised so far. I'll paraphrase some of the questions I've seen upthread:
Tue, Jan 21
Thanks for the feedback about real-world use-cases here, it's useful.
Mon, Jan 20
Fri, Jan 17
Mon, Jan 13
Thu, Jan 9
@AnneT this was bugging me a little bit too. The problem is that ItemWidgets appear directly beneath their statement input widget in all other cases. If the map is part of the ItemWidget, it will appear flush with the input (leading to confusion about which map relates to which element).
One thing we should keep in mind is how the proposed changes here would impact the "copy to all" functionality.
@kchapman I assume that after Last Call, there is some kind of official vote on whether or not to adopt a given proposal – is this correct?
Wed, Jan 8
Here are some new screenshots representing the approach described above:
In that case, I think the best way forward would be to introduce this functionality in a new patch that builds on top of the two previous ones. I can start on that tomorrow.
Tue, Jan 7
Right now I can think of two ways to try to support the use-case you are describing (make it easier for the user to visually see previously-entered coordinates on a map):
@Ramsey we don't currently support a lot of edit-in-place functionality anywhere in the SDC UI – users are encouraged to just add new values or delete old ones. Compare with cases where a string or URL field is entered – if a user sees a typo in a URL, they can't just edit that value; they need to delete the old one and add a new one. I think that this is all a legacy around the initial designs assuming item-types and dropdown inputs everywhere. (Qualifiers do allow edit-in-place functionality however – so we are inconsistent in our inconsistencies).
Ok, I've updated the design a bit of the expanded/collapsed map. Here are some new screenshots:
I'm in agreement with @matthiasmullie that the map is very prominent by default, probably too much so. It will also cause a bunch of image tiles to be loaded which is a consideration for bandwidth.
@Ramsey-WMF if you want, we can merge the first patch (that enables the map feature at all) and then wait to merge the second one (which hides it by default and consolidates the input fields to a single row), adding further tweaks if necessary.
Mon, Jan 6
@Ramsey-WMF the map itself works OK on mobile, but we could probably stack the compact row elements a little more nicely. I'll take a stab at that next.
Hi @SBisson, I agree that this would be a useful feature. I'm happy to turn this ticket into a formal request (not sure if there are any tags that I should add for that).
There are currently two patches which are ready or near-ready that address this issue. Currently the UX for "enhanced" coordinate input looks like this:
Thu, Jan 2
Mon, Dec 30
Dec 20 2019
Dec 19 2019
Dec 18 2019
Don't worry, nothing is obvious as far as I'm concerned. This is my first attempt using Echo (most of my work is on the JS side).
Dec 17 2019
In the short term, we may disable the email notifications entirely – it's likely that very few users have opted-in to this in the first place.
@Ramsey-WMF I'm able to reproduce this locally, but I don't understand why email notifications are not bundling; I've followed the instructions in the Echo docs but I must be missing something. I'm pinging the Notifications project and @Catrope in the hope that they can shed some light.
Dec 16 2019
Everything here looks good.
I've added a new ticket to track this issue at T240878 – feel free to add this screenshot there.
Dec 11 2019
Dec 10 2019
Here's a question – where do the units come from? Are we using a hard-coded list, or somehow fetching a list of appropriate units based on the property? Units will also be property-specific (a "length" property will have different units from a "weight" property).
Dec 9 2019
To echo what @Ramsey-WMF said, the read-only/delete-able label for somevalue is a short-term solution. We understand that this feature is important and plan to support it eventually, just as we are working to enable support for the various other types of statements (https://phabricator.wikimedia.org/T233036). We plan to roll out support for new types as they are ready but this is something that will begin happening soon.
Dec 5 2019
Dec 3 2019
Dec 2 2019
Dec 1 2019
I opened a new subtask for the specific issue of updating the FormatValue element and related logic. I have a WIP patch for it as well (still trying to figure out how to implement the changes on the PHP side): https://phabricator.wikimedia.org/T239552
Nov 27 2019
From a technical perspective, it's probably easiest to add support for both special values at once (though this will depend somewhat on the proposed UI).
Nov 25 2019
This assumes that constraints for Wikidata are the same as constraints as for Commons. I don't think this assumption will hold. For example on Commons we currently don't add P31 (instance of) yet. So every item with a creator will get a constraint violation. See for example https://commons.wikimedia.org/w/index.php?title=File%3ATerWorm.jpg&type=revision&diff=374654987&oldid=365995523
Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.
Nov 16 2019
@PDrouin-WMF here's what I was thinking for an updated input UI here (this would actually apply to all "string" types: URL, external-identifier, plain string, maybe monolingual-text).
Nov 15 2019
Here's a question about this datatype RE: acceptance criteria.
We have the ability to display these properties in a very basic way right now, but we have not enabled yet because we are working on updating the UI. Most of the team's energy has been focused on getting the machine vision tool out, but that work is mostly complete now so I'm hoping we can improve the situation here shortly.
Nov 12 2019
The widgets in the WikibaseMediaInfo extension use templates and render() methods to ensure that the visible UI remains in sync with the structured data as it changes. Existing DOM elements are often thrown out and re-rendered from scratch to ensure consistency. Our introduction of this workflow into the Captions widget is probably what initially broke this gadget.