@Sharvaniharan we started to document possible UX copy recommendations for wikifunctions content here https://docs.google.com/document/d/1dCfN3T4kIJpDG2X3NxEaNCadYp7cu6iX2dBRirSk3IU/edit?tab=t.0

this week we continued to explore a few ideas for user education, specifically we focused on potential entry points to help/educational materials. all explored ideas are available in this figma file https://www.figma.com/design/NcbqS9U1Yyuc45BVGK7P8T/T376078-User-education?node-id=0-1&t=idkrppRIeCx19xov-1.

this week we explored a few concepts and ideas for an alternative function icon to be used on wikipedia. all explorations are available in this figma file https://www.figma.com/design/5hFEEZRe85C5W2pS4Bm2Ot/T378528-Rethink-the-function-symbol-on-WP?node-id=0-1&t=AGno4PqNsuO3z8rD-1

some updates, we started to explore a few ideas in this miro board https://miro.com/app/board/uXjVLIhSAkw=/?share_link_id=419846314922.

and here are the A/B test research results @Sharvaniharan!

In T378513#10294717, @Sharvaniharan wrote:

Hi @AAlhazwani-WMF
Thank you for exploring this!

A couple things I noted here:

1. While the design with only a search field might work well for more familiar aspects of a wiki, such as references and citations, I believe we still need a bit more guidance for users. Therefore, I’m not in favor of removing the function suggestions, even if they might be causing some distraction. I understand that eliminating them isn’t what you are proposing, but just wanted to share first thoughts.

In T377337#10295322, @gengh wrote:

Setting the visibleItemLimit does help in avoiding the problem.

When using a lookup that's set on the superior side of the page:

When using a lookup that's placed more towards the bottom, the menu options display above, but they fit the space properly:

I also agree that the result feels less overwhelming and still allows contributors to navigate through the options.

@AAlhazwani-WMF what do you think?

In T377337#10295348, @gengh wrote:

Additionally, although the use cases are not so common, this issue can also be replicated in our other instance of Codex Lookup, the ZObject selector.
For example, while using the language selector after expanding text to find the language of in the language of monolingual text/Z14404 function:

I would suggest making the same change to limit visible items to 5 in both our selectors (the Wikidata entity one referred to in this conversation, and also the ZObject selector).
This would be the outcome for the language example above:

specifically on the labels of the UI, both in the search experience

specifically on the label for the 'Insert' menu item

another note to self, the current codex dialog implementation tries to "focus on the first focusable element in the body", more on https://github.com/wikimedia/design-codex/blob/main/packages/codex/src/components/dialog/Dialog.vue#L453. this approach follows the current w3c guidelines on focus behavior inside dialogs https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/, however the guideline also includes the following

note to self, while testing this on mobile web, the pattern is not immediately clear. tapping on 'link' or 'citation', opens a full-screen dialog with the field focused, but the keyboard stays closed.

some initial thoughts, this is a screenshot from the prototype that we used during the usability tests.

found the existing task on empty list, lemme know what you think of the proposed design in the task description @gengh!

@Sharvaniharan given the recent decisions, should we mark this task as declined or invalid?

@Sharvaniharan we concluded our spike. we presented findings to both the design and abstract wikipedia team. as a summary:

In T377637#10249657, @GrounderUK wrote:

[...] I’m not sure about the usability of navigable link when the user is expecting to click to select.

@Sharvaniharan started to collect existing examples on this board https://miro.com/app/board/uXjVLPivGKo=/?share_link_id=135896437145

In T377337#10240459, @CCiufo-WMF wrote:

Got it, yes I'm able to reproduce this one. Still can't repro the example in the task description though. Either way, we can look into this issue.

In T350801#10235346, @bmartinezcalvo wrote:

We’ve been exploring ways to address the Wikifunctions and Translation use cases highlighted in this task. Since the need to implement a button loading state has not been decided yet, we could use existing Codex progress elements to solve these use cases. Given that the ProgressIndicator is not implemented yet (T373218), we could use the Inline ProgressBar to solve both cases now. See the following prototypes with the proposed solutions:

• Run function in Wikifunctions (@AAlhazwani-WMF)
• Select sections to translate (@SGautam_WMF)

We'll create a separate task to evaluate the need for a button loading state to solve other future use cases.

+1 on the menu being cut off/behind the header. this seems like an z-index issue. @CCiufo-WMF should we file a task on the design system board too?

given the (content) unknowns the design suggestion is to treat this as plain text, see example on codepen or gif below.

after chatting with @gengh we landed on

In T375206#10215622, @CCiufo-WMF wrote:

Hey @AAlhazwani-WMF, we discussed this as a team and feel that we haven't seen enough of a need for multicolored logo icons to warrant bringing them into the system just yet. There are a few different ways we could implement this and we'd want to see more examples before being comfortable committing to one approach.

Here are a few recommendations/workarounds you can pursue in the meantime:

1. When looking at the design, we noticed that the placeholder text already says "Search Wikidata lexeme", which is a indicator that the input is for Wikidata items that doesn't rely on the iconography. We think it might be worth exploring having that information somewhere more permanent than the placeholder text, like in the field "description", if there's a concern that users won't have that context when the input is filled in.

2. If you still feel that the icon should be multicolored, we recommend creating a custom version of the icon for now and using it for your use case. I'm told this should be pretty straightforward to implement using the Codex TextInput and Icon components in Vue, so you shouldn't need us to necessarily add the icon to Codex before using it :)

In T350801#10207273, @CCiufo-WMF wrote:

In T350801#10206203, @AAlhazwani-WMF wrote:

inactive/disabled state
i'm wondering if we should also consider stopping/cancelling the process. if we opt for disabling the button there might be no way to interrupt the action, eg. cancelling a download.

@CCiufo-WMF it would be interesting to test if on wikifunctions, or @SGautam_WMF example overlaying a progress bar over a section or page might be too disruptive. i personally like the idea that while something is running (in the background) i can still "look around" on the page. i'd suggest to try this function to test how an overlay approach might work out https://www.wikifunctions.org/view/en/Z10309

I actually think what's already implemented in Wikifunctions is a good example of what I meant. The "Result" section that opens up below is communicating that the process is in progress, while the button itself could be disabled or remain active depending on whether or not the process is interruptible.

currently, codex doesn't feature a clipboard icon, but cdxIconCopy might be a good alternative too

@bmartinezcalvo @DTorsani-WMF sharing some quick feedback, i hope this is helpful!

with the new FY, this work has been handed over to the movement insights team. for record purposes the FY24 dataviz are stored here https://www.figma.com/design/xKd8WxE5nQQ5YsZdQGqFGF/Core-metrics-report?node-id=194-2&t=guZEiTJDVnyRM9me-1

fair enough, i usually favor visual/optical balance over mathematical consistency, but you're the deciders :) thanks for the swift feedback!

In T375206#10187897, @CCiufo-WMF wrote:

In T375206#10187866, @AAlhazwani-WMF wrote:

@Volker_E agreed with you that the wikidata icon/logo is a false positive :) one spontaneous approach could be to start from the current monochrome icons

and selectively add 1, 2, 3, ... color(s) from the full color logos until those icons become more recognizable? i've quickly tried this idea out. i've picked 4 colors from the wikisource full color logo, and applied only those to the monochrome icon

If the goal is specifically about providing logos as icons, I think this is a worthwhile approach to consider, although it adds a decent amount of scope to this task. @AAlhazwani-WMF as I understand it, this is not an urgent request.

In T375206#10187741, @CCiufo-WMF wrote:

In T374731#10187707, @Volker_E wrote:

Coming later to the party, I've already been sharing some of the concern in a DST meeting before.

1. Most Wikimedia sibling logos were not made with a use case of this small canvas (20 x 20 dp) in mind. Normally a professional logo design would incorporate the question of the logo at a very small size with lesser details (if necessary) or a simpler logo overall
   1. The example of Wikidata logo might be misleading here, as it scales _ok_ on that canvas size on high definition displays and modern browsers (with latest SVG rendering libraries). A WikiSpecies or Wikisource logo might be completely broken at this size.

Example of logos at 20px width scaled down from wikimedia.org (only Wikiversity makes some sense to me):

2. This ask seems to also not take into account that not everyone is in the place of browsing the project on a high-definition display. If just 30% (no factual data, only for assumption) of users are seeing the interface on a 72 dpi display the downsampling of even the Wikidata logo gets really nasty.

My recommendation would be to not support this use case out of box and tackle this on a per-project base, eventually with a lo-dpi treatment of the logo.
But would love to gather feedback by @AAlhazwani-WMF how to go about above questions. Thanks for the attention :)

@bmartinezcalvo @DTorsani-WMF i wanted to share a few visual suggestions to the latest proposal. feel free to take those ideas into account or ignore them if it doesn't make sense.

In T370922#10167048, @RHo wrote:

hiya @AAlhazwani-WMF - is this backlogged/in progress/done?

In T365631#10142417, @Jdlrobson wrote:

One important clarification: mobile web here means "mobile domain" not mobile resolution and mobile domain may include tablet users not impacted by this. We'd need to look more closely at device browser resolution.

In T365631#10138803, @JScherer-WMF wrote:

Thanks @Quiddity and @AAlhazwani-WMF for the suggestions and notes here. Moving to groomed. Given that this primarily seems to impact Wikifunctions, @AAlhazwani-WMF how big of a negative impact on the experience would you say this is having right now? Just asking to help assign priority.

would it be possible to display the warning* more contextually? eg. above or below the code editor

In T370838#10032857, @DVrandecic wrote:

Ah, it only works int he Edit mode. I defer this question to @AAlhazwani-WMF : should we change the label, keep everything as is, or change the functionality (i.e. turn it into an explorer on view). We can then triage this again, based on the decision.

In T371469#10045850, @derenrich wrote:

do we want to prioritize that for this week's release?

marketing images have been uploaded

@FNavas-foundation it was hard for me to track all the copy changes, i've started this doc if we'd like to review this holistically https://docs.google.com/document/d/17L5yUF02w3cLE3m9droJJODNiqX4JCshlD4OVJLS0-M/edit?usp=sharing.

i've explored two options: the first where we display the disclaimer inside the grey box (in order to reflect the same hierarchy/structure on the talk page), and the second where we display the disclaimer next to the primary button (thou in this case the UI could became a bit messier in the scenario where we also have the "you're not logged in" or "you're not autoconfirmed" disclaimer)

In T371469#10039896, @derenrich wrote:

ok I tried to make this match. one thing I'm unsure about is what the background of the start page should be. your mockup shows gray but the text doesn't mention that and I don't think we were doing that before.

given that we're going to have a table for FA at wikimania, we're closing this task.

here's a first round of proposals @gengh

on F.1 and F.2

update from @gengh on P.1

In T369609#10035885, @Anujagrawal wrote:

I'm not able to replicate the error and find the same appearance dropdown.

In T362650#10033228, @bmartinezcalvo wrote:

I've been exploring possible solutions to make non-valid entries in the Lookup clearer. We could solve this issue by using some existing solutions from our Codex components:

1. We could prevent users from entering non-valid text in the Lookup by displaying the "No results" within the Menu if the typed text doesn't match any preexisting result from the Lookup.
2. If the user still enters that non-valid value, we could show an error state within the Lookup (that is pending to be implemented in T363515) and display the existing error Inline Message within the Field component that includes the Lookup.

This solution could also address the issue flagged in T362657. If the user starts editing a selected result within the Lookup and enters that non-valid text, the Field and Lookup will display an error.

In case we agree with this solution, we should first implement the error state in Lookup in T363515: Include error state in Combobox, Lookup, and Radio components.

In T369575#10030104, @FNavas-foundation wrote:

[...]

• Outside the grey box add text that say "Citoid will automatically templatize a reference to add"

In T369575#10030261, @derenrich wrote:

is it "Add-a-Fact" or "Add-A-Fact"?

@derenrich i've submitted a PR to break the URL https://gitlab.wikimedia.org/repos/future-audiences/citation-needed-chrome-extension/-/merge_requests/20/diffs#459c6c3b072c0abd7b8f607aa4f5c9bf625a7682_68_78

@AAlhazwani-WMF to explore if it's possible to keep the illo also in the Add-A-Fact proposal.

In T369060#9999507, @FNavas-foundation wrote:

oh yes, great adjustments. short and sweet. also really into the red to add a sense of importance. Do you feel it is important to distinguish the last two bad states more aggressively?

In T370065#10009287, @derenrich wrote:

my basic implementation looks like

looks like i'm using a different icon from you? this info icon is the one we were using before. looks like both are listed on https://doc.wikimedia.org/codex/latest/icons/all-icons.html should we swap all uses?

In T370309#10003385, @derenrich wrote:

This is a very fast change to make. The bigger question in my mind is do we want to keep the article descriptions?

to build on top of a slack comment from @derenrich we could tone down the first scenario. here's a follow up proposal. cc @FNavas-foundation

In T368963#9999485, @FNavas-foundation wrote:

@AAlhazwani-WMF only question is, if the user searches for another article after we've found the first one they search, does it appear below or replace? my sense is that it should replace. What happens to box where the found article is?