• Intervention area: the bottom of infoboxes
• Move related articles up the page on Minerva, and create a place for it on Vector
• A mobile-first media viewer
• An "article detail page" as a home for a lot of the nitty gritty could free up reading UI
• Create multi-tasking affordances : browse while you listen
• "Super links" that launch you into an "explore" experience
• A mind map button that launches a galaxy-brain view of the the article and it's place. in the knowledge network.
• A "read next" affordance that brings you to the next item in a linear reading list.
• Re-design the homepage
• A floating drawer that as the intervention area
• A reading queue
• Link to articles from citations
• Save a reference
• References direct you back into Wiki
• Recommendations in page previews
• An "ask professor wiki" affordance in search
• Bring article summary paragraphs into search results
• Provide machine-translated search results from other languages for multi-lingual readers
• Pull items from the navbox into empty state search
• Put recently visited articles in the Search bar empty state
• "try searching for..." search hinting
• HMW recommend orphan articles?
• Extending existing search interface to allow more intuitive discovery of collections of articles a reader doesn't know the name of
• Re-design search on mobile to make it more prominent
• Mobile should expand all by default
• Re-design the TOC on mobile

Had a look at all of these. I agree that they would benefit from type exceptions that force the small font size on them. Moving to ready for signoff so we can make an implementation ticket next sprint.

The fact that the original design of letting users change settings even though those settings are not applied on exception pages and giving them a notice to explain why the changes are not taking effect, was relatively complicated for implementation.

In T361299#9724051, @stjn wrote:

In T361299#9723798, @JScherer-WMF wrote:

Would you mind letting me know the device / viewport width with which that screenshot was taken so I can replicate it on our end?

This is also related to T356532. Even without the block quote styling, the new large text setting can create less optimal character per line numbers, especially in languages with longer words.

This was just my Android device. Obviously the most glaring problems would be seen on 360px, this is somewhere like 480px width and 720px height.

I don’t think maintaining a margin is necessarily required to do, https://web.archive.org/web/20230116110600/https://en.m.wikipedia.org/wiki/New_England_(medieval) demonstrates this styling, which makes the new styling seem like much more of an error:

Here's the before/after on a German language article, which typically have longer words:

Playing around with the CSS on my end a bit. We don't want the margin to be 0 because we want the block quote to have some margin / indent on the left and right compared with the typical paragraph styles. So if we trim those down and trim down the padding between the text and the border on the left, we get something much more readable, even at larger type sizes.

Thanks for raising this @stjn! This is definitely not ideal.

Walkthrough of the affinity here:

Affinity in this Miro bard

I processed the ideas, and on the first pass they inspired 17 possible interventions. cc @ovasileva

Thanks for a great session, everyone!

In T361047#9682954, @Jdlrobson wrote:

Rendering Codex Dialog's requires pulling down additional JavaScript and CSS that isn't loaded on page load so this has some performance implications to think through. With this in mind I'd suggest limiting the audience somewhat and delaying the display.

Would any of the following options work for this?:

• Display the dialog on 2nd or 3rd page view (at this point most JavaScript and CSS should be in cache
• Delay the overlay display until a certain time has passed e.g. after 5 seconds
• Show the dialog only on the main page
• Show the dialog after the user has scrolled down the page a certain amount
• Show the dialog on a % of page views. For example 1 in 100 page views has a chance of displaying the dialog.
• Limiting the dialog to logged in users.

Miro board link
https://miro.com/app/board/uXjVKVik9bM=/?share_link_id=308304734579

@bwang is there a stable link to the page with all of the possible vertical spacing element interactions available?

This will be fed by the activities in T362120, T362116, T362117, T362120

Thanks @ovasileva ! Moving to design review to check all of these.

We want to let them change the settings on the overridden page, still. This is primarily to address the edge case where someone might want to make a change to the settings while on an overridden page. e.g. If you change the text size from large to standard on a small page, the a change will still take place. Also: if they want to change the settings for when they are back on the normal pages, they aren't limited while they're on overridden pages. Let me know if that makes sense!

Resolving this because I'll be folding in the concepts for empty state of search with the rest of our content discovery concepts.

In T358583#9691070, @Sneha wrote:

@JScherer-WMF thanks for tagging.. I looked at some of the ideas here and some related thoughts below:

Some context first: our project was focused on what happens when the users do not find what they are looking for in their search query. At the time we focused on improving the display of results on special:search page however we saw lot of opportunities in showing useful content to users in the main search box drop down itself even when article matches were not found. In our research we saw that users go back to google when they do not find an article match. However the content may still exist under a section or under an article with a different name or on a sister project. Right now if the article match is not found its just an empty drop down and so this is a good opportunity to surface relevant information there based on user query.

However, since the focus of this project is on the empty state before a search query is initiated, here are some related thoughts:

• Since most users come directly to wikipedia article through google, not many actually go to the portal/homepage and even if they go there we suspected very few use search there. We do not have data to support it but it might be worth looking at it to see if it is even worth the effort to have a different solution for home page.

• The native apps have recent searches but on web I wonder if any data that rely on users’ browsing behaviour such as recent searches, nearby, or personalized recommendations would move us away from our pro-privacy stance. (May be it is something the user can opt in rather than default) Here is an old write up on various ways in which Wikipedia search is different from other searches on internet. And if one requires to be logged in for these features then it may create inconsistency with logged out experience.

• Re: discovery related to article user is on, wanted to share what we had explored in our project for discovering content related to article in article preview. I wonder if having article related discovery in search empty state would be the most natural place. It seems anything related to article would be best suited to be in or around the article.

• There are many apps and services that treat search as an explore feature since most of them have dedicated tab or page for it. Whereas the way search is on our website it is essentially a search box and I assume users when they go there have different expectation and a specific query in mind. And so would having recommendations distract rather than help? Perhaps there is another place for all the discovery related things or we change the search affordances in a way that it becomes more like a UI destination to both explore and search.

• And lastly, another idea for enhancing empty state in search is by providing more options for readers to search Wikipedia. This is a different approach than using empty state for discovery. It is more in service of searching information that could eventually lead to discovery. I am not sure what is more useful for our readers within search interactions. But we have a lot of interesting ways to search content on wikipedia on the special:search page and I wonder if in the empty state we gave readers more ways in which they can search the information…for e.g. search articles, search categories, search in sections, or other ways of searching and dissecting information.

Hope this was helpful. Let me know if I can clarity anything.

I need to run through this with our devs @ovasileva to determine what they would need to estimate this re: @Pginer-WMF and @santhosh 's comments above.

Current behviour:

@santhosh Thanks for the context on this! I'll add it to the backlog and we can triage it.

@sgrabarczuk and I decided that polling internal contractors and ambassadors will suffice for this ticket.

@JScherer-WMF @ovasileva need to finalize copy/illustration.

In T361047#9682954, @Jdlrobson wrote:

Rendering Codex Dialog's requires pulling down additional JavaScript and CSS that isn't loaded on page load so this has some performance implications to think through. With this in mind I'd suggest limiting the audience somewhat and delaying the display.

Would any of the following options work for this?:

• Display the dialog on 2nd or 3rd page view (at this point most JavaScript and CSS should be in cache
• Delay the overlay display until a certain time has passed e.g. after 5 seconds
• Show the dialog only on the main page
• Show the dialog after the user has scrolled down the page a certain amount
• Show the dialog on a % of page views. For example 1 in 100 page views has a chance of displaying the dialog.
• Limiting the dialog to logged in users.

If it's not a significant change in scope, I'd like to propose using the onboarding dialog variant with the illustration/image.

assigning for review.

@Escargot_rouge Thank you so much for reaching out.

Added intended designs to description.
Created implementation ticket T361717 for next sprint.
Moving to sign off and assigning to you @Jdlrobson to make sure that the spec makes sense.

@bwang I updated the figma file, and that should fix the discrepancy. If you come across any other discrepancies like this, please take note of them, but you need not let them block development. You can continue based on the variable names if there are discrepancies in the hex values and I will check everything during QA.

Spoke to @DTorsani-WMF yesterday. I will make mocks for this this morning and unblock it.

@DTorsani-WMF ^^ did we change the figma colours since we implemented the palette?

@bwang we lost the estimation on this. Can you add points to it?

@Sneha some of the above is based on the search work you've done in the past. Are there any other content types that we could suggest before a reader starts typing in the searchbar that you think would be worth exploring?

Empty state content ideas to sketch out for homepage

• Recently visited articles from the homepage

from @Catrope in Slack:

It looks like it's not used by Minerva itself, but there are other extensions that use it, and you can presumably view those pages using the Minerva skin (the Growth team's newcomer homepage for example)

Added designs and a video walkthrough to the description above.