If it's helpful at all: in my poking at the current widgets in iOS 13, the only functional element I worry about (if we were to simply bring existing widget functionality into the new iOS 14 modality) is the "Save for later" button in the "Featured Article" widget. Unlike iOS 13, iOS 14 doesn't allow for interactive mutation of the widget content (like toggling the state of the "Save for later" button in iOS 13).

To be clear though, as far as I understand, we can still have discrete "buttons"/touch areas that trigger actions (so tapping from a list of articles can then take you to that article in app), we just can't interactively change the content of an iOS 14 widget.

Doh @Dmantena I'm so sorry I never put these widgets on Zeplin, but they're up now! https://app.zeplin.io/project/57a120ce9787dcf26230651f/dashboard?seid=5f247d3bb4f49a20ef4cd7d2

@cmadeo 💪🏽no worries, thanks!

Updated to include dark modes for all widgets, separated "Featured article" design from "Continue reading" and added skeleton states.

Updated to reduce the opacity of the placeholder elements :)

Here's another option for Continue reading:

I wonder if we might need to revisit the sparkline positioning in the small-sized top read widget. I feel like we might more often than not run into this type of unfortunate positioning on the photo:

Not a blocker right now, just wanted to mention.

Some follow-up with more sample data. Here are some top read results in the small widget, culled from the last month or so and ignoring duplicates (also attached are original thumbnails in zip).

For the image in the widget, we're content filling while maintaining aspect ratio. From this limited sample size, it seems the majority of the time the top read image is a portrait of a person and the view count is in the 6 figures. This leads to the sparkline/view count bar in practice being at minimum half the small widget's width. Face detection might be an option to help us out of the bar over person's face/eye issue, but for now it's questionable if WidgetKit can support it - we have very limited execution time and memory in widgets. Even so, looking at a lot of these photos, the majority of them aren't framed such that there's enough vertical space above a person's head to use face detection to reposition the image and make any meaningful difference in resolving the bar over their eyes/face issue.

I'd love your perspective on this when you're back next week. I'm wondering if we reduce the content in the sparkline/view count bar to just have either one of the other, would it obviate our "bar over eyes/face" issue? Or if you feel like in general this face bar issue isn't as big of a deal as I'm making it out to be?

Thanks @Dmantena! Just writing in here what we discussed during the meeting: Definitely the 'bars over eyes' issue feels like a big one, I like your suggestion to disclose more information as the widget sizes up, so trying out just the sparkline in the small view seems like a great idea. Thanks also for all of these examples!

@ABorbaWMF can you give the 3 widgets (Picture of the Day, Top Read, and On this Day) we have our in the latest beta (1753) a bit of an early smoke test? We aren't done with development yet, still have some polish, localizing and data loading issues but would like you to play around with them and see if you discover any bugs we haven't caught yet (such as with deeplinking, etc.) When these are fully done we will move the individual widget subtasks to Needs QA for final testing.

@ABorbaWMF the big 3 PRs for these 3 widgets are now merged into the main branch (as of build 1756), so I'm moving this parent task back into the Epics column and will move those specific subtasks to Needs QA for you to test against. Thanks!

Nice work on the widgets, been testing with iOS 14 beta. I have a question regarding multiple languages, in the preferences I can set several languages for the "Top read" widget, but in practice I only see items in one language (the first in the list). I'd expect to see a mix of entries for all languages, maybe the top read in each language.

Regarding the use of language as a content filter, for global languages (Spanish, English etc.) this quickly breaks and you end up getting very broad results across the whole language area. It might be interesting to do a more fine-grained filtering there.

@jberkel Thanks for testing them! Currently, the widgets display content in the "Primary" language you select in Settings > My languages in the app. Seeing all the languages you've added in the larger widget families is an interesting idea. But I think the ideal scenario for us is to utilize what Apple refers to as customizable intents in order to make each individual widget customizable to whatever language you'd like. These widgets seem like a fine candidate for customization, especially when considering the challenge of trying to mix both LTR and RTL language results into a single widget.

You can see this customization behavior now using something like Apple's Weather widget. Add two of the small class weather widgets to your homescreen, then long press and tap edit. They can both be set to different locations.

@cmadeo I forgot we had the option to change this, but in addition to the order of the widgets, we can also change the "accent color" used in the widget gallery. Currently we're using the Apple default blue left one, but wanted to check with you: is there a particular custom color you'd like for me to update this to?

@jberkel Thanks for testing them! Currently, the widgets display content in the "Primary" language you select in Settings > My languages in the app. Seeing all the languages you've added in the larger widget families is an interesting idea. But I think the ideal scenario for us is to utilize what Apple refers to as customizable intents in order to make each individual widget customizable to whatever language you'd like. These widgets seem like a fine candidate for customization, especially when considering the challenge of trying to mix both LTR and RTL language results into a single widget.

Ok, so instead of having one large widget I would add two or more individual "top read" widgets, and configure them to use different languages? That is a good solution, although it might take up some more screenspace.

Right now the widget doesn't seem to be using the primary language set in the Wikipedia app. My primary language is "DE", in the "explore feed" setting I've set "top read" to "CA, PT".

The top read widget currently displays only Portuguese items, probably because it is listed first (however not in the overview screen, where it seems to be alphabetical). To get Catalan entries I have to switch off Portuguese.

Right now the widget doesn't seem to be using the primary language set in the Wikipedia app. My primary language is "DE", in the "explore feed" setting I've set "top read" to "CA, PT".

Sorry, let me clarify – the displayed widget content language should match the top most language in your "Wikipedia languages" that is also enabled in the widget's specific feed content group. So if your "Wikipedia languages" page is ordered top to bottom as DE, PT, CA, and your customized explore feed subtitle for top read is CA, PT (or PT, CA), then the displayed widget language will be PT (because it's the highest priority language enabled for the group).

The top read widget currently displays only Portuguese items, probably because it is listed first (however not in the overview screen, where it seems to be alphabetical). To get Catalan entries I have to switch off Portuguese.

You're right, this is confusing – the order of the languages listed in the subtitle circled in your screenshot should match the order on the "Wikipedia languages" page to help make it more clear what the expected display language in the widget will be. I'll make a separate ticket for us to look into this.

You're right, this is confusing – the order of the languages listed in the subtitle circled in your screenshot should match the order on the "Wikipedia languages" page to help make it more clear what the expected display language in the widget will be. I'll make a separate ticket for us to look into this.

Thanks! I realize it's quite a challenge to build a multilingual app/UI. The best solution would be to have the language selection in context (tapping on the widget, as you suggested earlier). The app settings have become rather big, and it's not clear that "Explore Feed" settings also affect the widgets.

Thanks! I realize it's quite a challenge to build a multilingual app/UI. The best solution would be to have the language selection in context (tapping on the widget, as you suggested earlier). The app settings have become rather big, and it's not clear that "Explore Feed" settings also affect the widgets.

@jberkel Just wanted to provide an update on this for you. We made a change (not yet available for testing) where the widgets now always use the primary language you have selected in your "Wikipedia languages" settings, regardless of your "Explore feed" settings. Ideally, we'd still like the widgets to have further independence (the tap and edit an individual widget to set its language approach), but hopefully this helps clear up some confusion in the interim.

I created T263283 for the multiple, independently customizable widgets.