Wed, Jul 17
Tue, Jul 16
Thanks, Eric. I think it'd be best to have the new element only show once (on the first image) in UW but if @Ramsey-WMF is okay just showing it on FP for now, that sounds good to me.
Wed, Jul 10
Hey Eric, here are the updated designs:
Mon, Jul 8
After I last checked in on it, we changed the placement of “Publish changes” to the lower right to match Captions… which has been great in terms of consistency for most users, except that it means more tabbing to actually publish any changes. @egardner, is it possible to enable “Enter” to publish the change after it’s been validated?
Okay, thanks @Cparle - never mind then. Ramsey's solution would work best. I think the text does a good job of explaining what'll happen.
@Cparle - Agree with Ramsey here that there needs to be a confirmation model. I'm assuming this kind of action won't be taken often (deleting all values, including the property) but I do think there needs to be sufficient warning that property and anything underneath it will be deleted.
Wed, Jul 3
All the proposed changes are on hold. The team will be implementing this for now: T227230
5 sounds reasonable. I do think we still need an "Expand all" button, just like the Captions panel has.
Tue, Jul 2
The important thing is establishing what user experience we want people to have. Some options:
- Always show anything marked prominent above the "fold", and show X number of items as default if none have been marked prominent yet
- Choose a number to show above the fold based on how many items there are already, such as if there are 3, show all; if there are 5, show 3; if there are 8, show 5, etc.
- Other options?
I've seen these designs for an OOUI datepicker.
Tue, Jun 25
@matthiasmullie agreed that this thread has become long/confusing! While you and I are thinking about the impact of a new tab design on Commons, @Volker_E and @Esanders are wanting this to be a widget that can be used elsewhere as well.
Jun 12 2019
Sounds good to me, thanks @Cparle!
Jun 11 2019
Jun 10 2019
Hey Matthias! I missed your comment from last week. I like your treatment of the dropdown being the length of both the input field and delete icon, so for sure let's keep that.
This ticket is related: https://phabricator.wikimedia.org/T225358
Jun 5 2019
Hey @Cparle, here's a version with barcodes:
Jun 3 2019
Wound up mocking up a quick visual:
I'd like to see the qualifier on the first line, and the value input on a second line. That would make both qualifier and value actually readable/editable. Let me know if this makes sense, otherwise I can do a quick sketch to illustrate what I mean, @egardner
May 30 2019
Per our design:dev chat earlier today, this is the direction we're going in. The templates already in use will show in between the tabbed navigation bar and the rest of the content on the page. Messaging remains regardless of selected tab.
May 29 2019
Made updates, and will be sharing them with the design team for feedback on visual design and style guide adherence: https://wikimedia.invisionapp.com/freehand/document/lZtXyDYNZ
Thanks for the visual, @matthiasmullie
May 28 2019
Volker, I like your furthering of the work.
@Ramsey-WMF pinging for input/acceptance criteria
Problem: when users attempt to edit a protected file page, they only find out after they've made edits and when they are about to publish them, they find out those changes won't be accepted because the file is protected. We want to tell users up front that a file is protected so as to not waste their time/energy.
Works for me!
May 24 2019
Pinging @Volker_E for feedback. What we have on Commons for tabbed navigation has been fine for now, but we should probably discuss this in the next style guide meeting.
May 23 2019
May 22 2019
Hey Cormac, I don't think the designs need to change much, other than the button for adding addition statements. I'd like to keep the styling of the buttons we use on Upload Wizard:
I like this solution. At what height on the screen would the spinner appear? I'd like to see it in the upper third of the screen, if possible.
May 20 2019
Thanks for pinging me, @egardner -- agree with the stacking here when there is not enough space. The latest patch looks good!
May 17 2019
@egardner sounds good! thank you.
May 16 2019
I'm leaning towards the last two options, and @Ramsey-WMF would like to go for the last option. I'm concurring.
Thanks for the updates, and especially for explaining that default iOS behavior. Consider this ticket confirmed completely then!
This mostly works for me with two exceptions:
Confirmed this is working on Beta. Thanks, @matthiasmullie
May 15 2019
Thank you, @JeanFred! Will be looking into this early next week & discussing with the team.
May 10 2019
When I'm logged in (with Chrome), I see this instead:
@Cparle looks good on beta!
Closing because Depicts on UW is launched now.
May 9 2019
makes sense to me, @Cparle
May 7 2019
Sounds good to me.
I'd like to keep it consistent with the right-justified spinner we already use on the Upload and Publish file steps -- with similar text as well to the left of it? We could say "Submitting structured data..." or something to that effect.
May 3 2019
RTL handling is up in the air regardless -- I'd rather us stay in keeping with Wikidata and wrap text than hide it.
Thank you, @matthiasmullie!
May 2 2019
From our meeting earlier, with an individual file, centering the content block looks weird. Should be left-aligned.
Recap from the earlier meeting:
- Max height is needed - Depicts should be visible on the screen no matter what (if users have a long image, and they don't see what's possible to add, they may skip this step). Could use a bounding box?
- MM: will do (landscape images won't be full-width anymore, though - do we center them or left-align?)
- Answer: left-aligned, probably
Well, we're planning on having label text wrap for mobile, can we do the same here?
Thanks for updating the copy a bit! It helps :D