Given that we now know what the intended behaviour is, we can estimate it properly going into next sprint. cc @HSwan-WMF

realizes weeks later that he forgot to hit submit on this comment...

cc @lwatson Let me know if you have any questions about these. Also probably worth flagging @Jdlrobson-WMF for the paragraph hoisting bug.

In T413401#11562373, @lwatson wrote:

Regarding the editor help button: I logged in and enabled the newcomer homepage

Editors can toggle this feature at Special:Preferences → User profile → Newcomer editor features → Display newcomer homepage.

... but I don't see the help button or help panel appearing.

Also, the task description mentions https://en.wikipedia.org/wiki/Wikipedia:Growth_Team_features#Community_configuration

I've been playing around with quote cards a bit if we want to have something as a placeholder:

Ok, so lemme zag on this a little bit. We know readers are scanning text looking for links. Why not surface the 3-5 most-clicked links in a long section at the top of that section? Maybe we spike on what kind of section-level data we can get? This is a concept from last year that I adapted to show how this might show up:

For now, it might make sense to spike the highlight interaction without specifying exactly what we'll put inside the module that pops up when a user highlights something.

Had a look at this just now and there are a few improvements to the network view that would make it better on mobile:

Thanks for your work on this @matthiasmullie ! Answers below.

In T410325#11419281, @matthiasmullie wrote:

+1 for the sticky header option looking more feasible, and it looks pretty neat!

I'm not personally a big fan over floating buttons (option #2) obscuring my content, but that's very subjective.
My main concern with that option is the "search" addition: I would expect an in-page search here, but that feels like a can of worms:

• in-page search would behave differently from regular search (direct text match; no stemming, keywords, wildcards, ...)
• would require some additional UI elements (e.g. button for navigating to next match)
• does it find hidden text (e.g. within collapsed sections) or not? (window.find() does not), and if yes, how do we surface it?
• window.find() is not a standardized feature

Another good option with less fiddly interaction design would be to have a floating action button with search and contents buttons.

I did some design exploration on this yesterday. The appearance of the ToC pane itself is less of a worry to me, we can either adopt what we already have or re-build it using codex. I'm more concerned with IA and scrolling interaction.

In T410325#11393609, @lwatson wrote:

The TOC (#toc element) is hidden on smaller viewports via display: none. This is an example of the existing TOC if shown on a mobile device:

Collapsed	Expanded

In T410325#11383516, @A_smart_kitten wrote:

xref T366026: [Design needed] In-article navigation for Minerva: ToC and sticky headers

Our autoscroll requirement assumes that the reader wants to go down, not up. I think we should remove it (edited)

Bullet points "peak out" from beside the scrolling headers

Our experiment won't run on pages referred from "Related articles" e.g.

Closing sections jumps to random points in the section below

Two-line headers poke out the bottom

I agree. I think we should maintain whatever the font-size pref is from before the print mode was initialized. Readers can always change zoom as part of the print dialogue.

Analysis is now done, I just need to write up my findings. High level initial findings:

• Overall positive and useful
• Need a horizontal scroll affordance in the gallery
• Need to support pinching and zooming on mobile in a comprehensive way
  • Many participants pinched and zoomed the detail view. Probably to uncover the bits of the image that were obviously cut off by the crops. We need to be less worried about getting the crops perfect if we can support pinch/zoom on mobile in a comprehensive way.
• Detail view needs more metadata
  • Images without captions were less useful.
• No one read the paragraphs in the vtoc, but we also didn't ask them to.
• Long scrolling was mentioned as a problem in several instances. We need to cap the VTOC descriptions length
• Need to be explicit where the view in article button is going
• Need to figure out a way to keep the context of the article while in the image browsing experience
• Need navigation affordances to take away all the scrolling a bit.
• Didn't expect tapping on an image in VTOC to bring to the top
• Commons link was confusing. Commons link needs to open in new tab in the background and give a toast for feedback
• Media from other projects needs a new title
• Media from other projects needs more features so that it's not "just images"
• Less useful for specific facts or factoids
• Look out for a Hub and spoke pattern in the data between detail view and the main article gallery
• Favourable comparisons to other image browsing experiences
  • Google Lens, but better because faster and more reliable
  • Google Images, but better because safe
• We need to do community consultations on specific, common image types to get specific crop treatments
  • Signatures are a big one. They shouldn't be cropped.

@egardner have a look at the design guidelines and prototype above and let me know what other questions need to be addressed. :)

Pages with title= in the URL don't have galleries, even when they should
This might be a weird parser thing. But I was getting URLs with https://en.wikipedia.org/w/index.php?title=Voyageurs&wprov=rarw1 instead of https://en.wikipedia.org/wiki/Voyageurs .
I don't know what the circumstances are that makes the URLs resolve this way, but the image browsing feature doesn't work when this happens.

Detail view caption font should be caption-bold, not `UI-text-bold
The original spec for the caption in detail view was to have it be caption bold. We have it implemented as UI text bold.
The line height should be updated accordingly.

Detail view image caption is centre aligned, should be left aligned

Ok, if we can fit it in, I'd love to add some basic cropping behaviour to images in the vtoc. We want the images to fill an area that is 300 px tall and as wide as the vtoc caption frame as much as possible.

Nav box templates are sending images to the gallery and vtoc

Non-localized caption

Image appears twice
https://24f17e0e4a.catalyst.wmcloud.org/wiki/ChatGPT?imageBrowsing=1&useskin=minerva#/imagebrowsing/File:Countries_where_ChatGPT_is_available.svg
https://24f17e0e4a.catalyst.wmcloud.org/wiki/ChatGPT?imageBrowsing=1&useskin=minerva#/imagebrowsing/File:ChatGPT_availability_by_country_or_region.svg

Smart cropping doesn't work well with vertical positioning on desktop

Swapped captions
In the article for Katseye, they're using this pseudo gallery halfway down the page.

Full screen toggle tooltip
This should not appear. It has no close or dismiss affordance and persists after the new view loads.

Back to article button hidden, not rendering correctly
On iOS chrome it renders full width beneath my URL bar.

less button not visible

Decrease height of caption background gradient

strange vtoc text formatting

Carousel images failing to load

Weird grey boxes in vtoc in chrome iOS

max height of vtoc images should be 300px, not 160
The thumbnails int he vtoc are too small and there's a lot of awkward, inconsistent whitespace around them in the UI. The initial spec was 300px as the max height with a smart crop beyond that similar to the details view. Assuming the smart crop isn't in scope, can we resize the thumbnails to 300px high so they have a bit more presence in the UX?

Weird load in boxes
These boxes flash into view as the page loads.

"more" button disappears when directly linking to a page
repro:

1. find an image that has a long enough caption to warrant a "more button" and load it in the detail view.
2. copy link
3. direct link to the focussed image

what happens: more button isn't there
what should happen: more button should be there.

In T404719#11185532, @lwatson wrote:

@JScherer-WMF I noticed the fullscreen button isn't working on iOS Safari and Chrome, which got me thinking about the mobile user experience.
While desktop users can easily exit fullscreen mode using the escape key, mobile/tablet users might struggle to exit fullscreen mode, potentially creating a frustrating experience. However, I could be missing something.

Is fullscreen functionality necessary on mobile devices? (If yes, then let's investigate and fix it. If not, then we can optionally disable this feature on mobile entirely.)

One additional clarifying point:

In T402223#11169347, @ovasileva wrote:

Proposal after conversation with @egardner:

For the detail view

1. let's go with the caption only (it's a bit too much scope creep to show both caption and paragraph)
2. If no caption is available, go to alt. If no alt, nothing

For the ToC view:

• Exclude infoboxes from receiving text
• For all other images, use paragraph
• In addition, create QA ticket for @Edtadros and @Etonkovidova to review top 50 articles and note inconsistencies between paragraph text and image

@JScherer-WMF - how does this sound?

copied over

In T401221#11167810, @ovasileva wrote:

Another potential issue is that we are showing the paragraph in the detail view as well, which I think needs to be always the caption, independent of our decision on what to do in the visual ToC view. @JScherer-WMF - could you confirm?

In T402223#11164908, @egardner wrote:

In T402223#11164857, @JScherer-WMF wrote:

Thanks for flagging this @egardner @lwatson. This does indeed look broken to see the first paragraph over and over in the vtoc. I think for this usecase, seeing nothing in the caption area for the images that would repeat the same text as the previous image would be preferable to seeing the same text repeated.

All other images in the VTOC will have some text associated with them. Will it be strange when the first few images lack that information? We could try to show just the image title as a fallback (with the caveat that this is not always very helpful or informative). I'm not really sure what other data we have that we can rely on.

In T402223#11150068, @egardner wrote:

Hey @JScherer-WMF – I moved this task to "Needs QA" but I assigned it to you because I'd like some design input here.

Are you okay with the current behavior that uses the first paragraph of a given article as the text when images from an article Infobox lack both caption and alt text? In practice this means that on many articles, the users will be presented with many images that simply restate the first paragraph again and again (and these will be the first things the user sees in the VTOC). I think this might lead folks to conclude that the feature is broken.

You can see an example of the current behavior here: https://patchdemo.wmcloud.org/wikis/85fc46bc00/wiki/Paris – I suspect this will be an issue with many well-illustrated articles.

Added designs for each of these @egardner . I think it should be ready to estimate now.

marking this as done because I don't think any further concept testing is necessary for this work.

In T402964#11125021, @lwatson wrote:

they will not have fixed heights within these tracks. Height will instead be determined by the amount of text content.

I'm concerned about this, but maybe I just need a visual of some items with long content. If we expand and collapse the content like it's done in DetailView, then that may cause a lot of movement and tiles bumping each other for space. IDK