Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T309471: Testers struggled to understand what "Add Topic" button copy meant on user talk pages
    • Task
    **Issue:** When testers read the "Add Topic" button copy, many continued to hunt for a different venue to start their conversation. "As I am scrolling I'm looking for something that would say "new discussion." UT- 10 "...what i was able to find was "add topic." I am unsure if this is the same or not [as new discussion]. UT-3 **Possible Solution:** - Consider alternate button copy (perhaps "add discussion")
  • T309469: Testers struggled to make sense of information on user talk page
    • Task
    **Issue:** Most test participants (desktop and mobile) struggled to make sense of the User Talk Page. "I can't understand what I'm looking at, this is very, very confusing. This kind of looks like a forum post but I can't understand what I am looking at." UT-1 (test E re-run) "The discussion isn't related to the posts that come after it (if you scroll down) leaving me very confused as to what I was looking at" UT-1 (test E re-run) "The exact topic I have to read and explain. The first was about solve a doubt about a program, then an invitation for edit in Wikipedia about POI and finally I had to write about NY crime. It was confusing." UT- 10 (test E) **Possible Solutions:** - Consider creating an unique exploration for the user talk page (not re-using the design from the article talk pages).
  • T309468: Enable people to sort talk page discussions
    • Task
    === Issue Testers across all tests and all devices struggled significantly to make sense of the timeline. "It would have been better if the most recent (conversation) was at the top of the page." UT-7 === Possible Solutions - Review earlier explorations of the talk page which flipped the timeline upside down - Introduce functionality that would enable people to: -- **A)** Sort the discussions on a given page based on criteria like: discussion start date, comment count, participant count, most recent update -- **B)** Decide how talk page discussions are sorted by default on the talk pages they visit
  • T309461: Improve in-page search/topic discoverability
    • Task
    **Issue:** When asked to see if a topic had been previously discussed on a page, testers expected to be able to use the search bar within the sticky header to do an in-page search (a functionality that we don't currently have). **Possible Solution:** - extend the functionality of the search bar within the sticky header to include in-page search - visually highlight topics discussed more prominently with tagging or other component.
  • T309459: Make latest comment indicator more discoverable
    • Task
    **Issue:** Many testers struggled to correctly identify the most recently edited conversation. While testers who discovered the freshness feed found it very effective, there are some discoverability issues - particularly the size. As a result, many testers incorrectly assumed that the first entry on the top of the talk page was the most recently updated post. **Possible solutions:** - adjusting typographic treatment (particularly on desktop)
  • T309457: Make discussion heading (topic title) more visually distinct from the conversation
    • Task
    **Issue: **When testing the empty state page (both on mobile and desktop but more specifically on mobile), testers did not expect the conversation to appear as it did. "I was kind of expecting to see more like a headline and a click to open, I wasn't expecting to see it automatically." UT- 9 "Maybe have a box around the [topic container] so it could look like a thread." UT- 2 **Possible Solutions:** - revisiting earlier design explorations that provided visually distinct treatments for topic containers.
  • T309455: Make link editing more user friendly on mobile
    • Task
    **Issue:** When testing the prototype for creating an article from an empty state page on mobile, testers struggled to add links successfully. Many testers could not get the combination of highlighting, clicking, searching and editing text to work with ease. **Possible Solution:** TBD
  • T308029: Usability Problem: Make search for users using the @mention feature a more obvious affordance
    • Task
    **Problem: **When usability testers were asked to add @-mention a username that had not previous been involved in the conversation, they struggled to use the tool to search for usernames. Where struggled here means that they didn't use the search functionality or used the search functionality but didn't scroll down to the correct username after search or expected to be able to autocomplete the username addition. **Proposed Solution**: TBD
  • T308025: Usability Problem: Ensure mobile reply tool is in visual editor mode by default.
    • Task
    This task involves the work with updating the prototype we are using as part of the usability testing happening in T307840 [i] so that people who open the Reply and New Topic Tool enter both tools' `visual` mode by default. === Desired behavior People who open the Reply //or// New Topic Tool on the Usability Improvements prototype [i] land in either tool's `visual` mode by default. --- i. https://patchdemo.wmflabs.org/wikis/916be355b2/wiki/Talk:Climate_change
  • T308024: Usability Problem: Consider a different icon for switching modes in mobile
    • Task
    **Problem: **During usability testing for replying on Talk Pages T307840, testers struggled to identify what the purpose of the icon was for switching modes. {F35125752} **Possible Solutions:** - redesign icon - remove source mode in mobile {F35125741}
  • T307724: Make highlighting scheme consistent
    • Task
    Right now some of the post edit highlights appear in blue, others in orange, some disappear and others don't. We should review and make recommendations for how they look holistically.
  • T289192: Make it easier for people to identify talk page comments that they haven't seen
    • Task
    === User stories As a **Contributor,** I want to see a visual indication of read talk page threads in context so that I can focus on comments and discussions that I haven't seen and feel less overwhelmed by the information overload. (Note: this use case was brought to my attention by @APerson) === Conditions of Satisfaction This should be on mobile and desktop. This is specifically referencing the in-context reading experience of Talk pages. == Possible Solutions - @APerson and I were discussing this at Wikimania and suggested that we review the treatment of this on [[ https://lobste.rs/ | https://lobste.rs/]] == Done - [ ] a solution to this problem - [ ] mockups
  • T284322: Bug: Update contextual Subscribe/Unsubscribe button in real time when Unsubscribing from Echo Notification
    • Task
    === Behavior **Actual** - When I get an Echo notification, - I click unsubscribe from the overflow menu - It displays an unsubscribe confirmation message and removes the overflow option from the Notifications window - I need to reload the page for the "unsubscribe" button next to the actual conversation to return to "subscribe" **Expected** - When I get an Echo notification, - I click unsubscribe from the overflow menu - It displays an unsubscribe confirmation message and removes the overflow option from the Notifications window - It automatically changes the "unsubscribe" button next to the actual conversation to "subscribe" This was experienced in T279150 === Environment Browser (version): Chrome (89.0.4389.114) Platform (version): Desktop OS: MacOS (Big Sur 11.2) === Done - [ ] "Expected" behavior is implemented
  • T282764: Optimize Replying Experience for low bandwidth/slow loading environments
    • Task
    === Objective Display a loading affordance that indicates to users in low bandwidth or slow loading environments that their reply conversation is loading and not crashing. This ticket is being filed as an outcome of the usability testing performed in T281438 where a contributor in such an environment had this exact experience with the reply tool and thought that the tool had crashed but it was in fact just loading. === User stories As a Junior or Senior Contributor in a slow loading environment, I want to know that the reply widget is loading so that I can I continue to wait for it to load in order for it to display the inputs required for me to finish editing. === Possible Solutions - a loading animation - a notification == Done This section contains what needs to be true in order for the task to be resolved - [ ] a proposed solution designed - [ ] an implementation plan
  • T282269: Make it easier to identify and understand the relationships between the threads and comments
    • Task
    === Objective The goal of this design refresh is to improve talk page legibility. Currently the way that conversations and replies are presented on the Talk Page can feel overwhelming and challenging to parse. === User stories As a** Junior or Senior Contributor** I need/want to **see how conversations relate to each other** so that I can **scan and respond to the appropriate conversation in the expected location**. === Requirements - Mockups that can be prototyped - Reviewed by PM - Reviewed by Engineering for feasibility - Aligns with OOUI (possibly WVUI) == Done - [ ] Mockups with proposed design --- === References - [Discussion tools data structure](https://en.wikipedia.org/wiki/Special:DiscussionToolsDebug?pagetitle=Wikipedia%3AVillage_pump_%28technical%29%2FArchive_207) via @DLynch - @isaacl [wrote a custom stylesheet](https://en.wikipedia.org/wiki/User:Isaacl/style/discussion-threads#Example) for making the distinctions and relationships between comment more legible (great spot, @Whatamidoing-WMF): {F37639477} - [User:Wedhro](https://www.mediawiki.org/w/index.php?title=User:Wedhro) raised this issue in [this conversation on mediawiki.org](https://www.mediawiki.org/wiki/Talk:Talk_pages_project/Usability#A_question_about_reading_talk_pages): //"Another thing that could help people understand what's going on (but it's unrelated to the matter being discussed in the page) is how comments from different users are only differentiated by the final signature, which doesn't help even if users heavily customize them. Maybe a visual break would help, such as a horizontal line after each comment, or a different background for each comment."// - [User:Greatder](https://www.mediawiki.org/wiki/User:Greatder) suggested adding some kind of visual indication to clarify the relationship between comments as is done on reddit. //See: [Topic:Wvy2k0mom3qvdra9](https://www.mediawiki.org/wiki/Topic:Wvy2k0mom3qvdra9) - @Ed6767 [raised this issue on en.wiki](https://en.wikipedia.org/wiki/Wikipedia_talk:Talk_pages_project#c-Ed6767-2022-05-21T00:28:00.000Z-Feedback:_Ed6767) - @catsmoke [raised this issue on mediawiki.org](https://www.mediawiki.org/wiki/Topic:X0es4qsrld78mdva): //"I wish it was easier to tell the row where one comment ends and the next comment begins. Differently shaded alternating backgrounds would do this."// - [User:Jay](https://www.mediawiki.org/wiki/User:Jay) [raised this issue on mediawiki.org](https://www.mediawiki.org/wiki/Topic:X09un3g2mwskzic2): //"I would like vertical lines indicating threads like [this](https://www.mediawiki.org/wiki/File:Nntp.jpg)."//
  • T279312: Clarify the relationship between notification and watchlist workflows
    • Task
    ===Opportunity: A core part of being an editor on Wikipedia is watching over things. Different types of users use the tools that we have for watching content in different ways "depending on the level of experience and the decade in which they started editing" (according to @Whatamidoing-WMF). Generally, we have a two workflows to consider: **Watchlist **= a [[ http://learningplatforms.org/activity-feed-design-pattern/ | feed ]] of all edits to pages I am interested in that come with a powerful set of tools that enable me to customize how this **Notifications **= [[ http://ui-patterns.com/patterns/notifications | alerts ]] about specific kinds of edits I am interested in Most edits/actions/events that trigger notifications are represented as "news items" within Watchlists. In various usability tests, I've informally observed that //junior //**contributors are confused by, and/or are having difficulty with:** 1. the **relationship** between these two workflows 2. **discovering** the location of the watchlist and in turn, knowing where to go to **manage** their settings 3. the workflows **purpose ** Additionally, there have some attempts to allude to or integrate the experiences. For example, currently on Flow when you want to watch a topic, you click a star icon (the icon used for watchlists) and while you receive notifications via the notification alert system, you also have the ability to manage the topics that you are watching in the Watchlist. As a bonus, you also have the ability to stop watching conversations directly in your notifications alerts. //Screenshot of notification alert where you have an overflow menu with the "watchlist star icon" to stop watching topics// {F34256996 width=600} ===Considerations: There has been a proposal for quite some time to unify the notification entry points (T142981). This proposal being approved would allow us to focus on unifying one notification alert experience with the watchlist experience. === Possible Solutions: - **Connect the two experiences**. What would this look like? Would this be a major infrastructural undertaking? Would this completely disrupt senior contributor's workflows? - **Differentiate the two experiences** in a more obvious and extreme way. What would a real activity feed look like? Is this something that would appear on your [[ https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage | Home Page ]]?
  • T276258: Increase contrast of active state buttons in the special character dialog
    • Task
    **Problem:** When selecting characters, it's very challenging to tell if the character button is active {F34131976 width=600} **Possible Solutions:** - swapping buttons with an [[ https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop | OOUI treatment ]]
  • T273921: Notifications: Research
    • Task
    === Why are we doing this? TBD === What do we hope to learn? TBD
  • T273920: [Interventions] Notifications
    • Task
    This parent task represents the work of experimenting with different notification-related interventions (see table below) to increase the likelihood people receive timely and relevant responses to the comments they post and conversations they start on talk pages, across Wikipedia's namespaces. === Interventions The work to increase the likelihood people receive timely and relevant responses to the comments they post and conversations they start on talk pages is comprised of the following interventions. |Ticket|Intervention|Description|Status |---|---|---|--- |T263820|Manual topic subscriptions|Enable people to elect to receive notifications when new comments are posted in topics they've chosen to "subscribe" to|In progress| |T263819|Automatic topic subscriptions|Enable people to elect to receive notifications when new comments are posted in topics they've participated in.|Up next |T263821|New topic notifications|Enable people to elect to receive notifications when new topics are posted on talk pages they are interested in.|//Not yet prioritized// === References - [[ https://docs.google.com/presentation/d/1sL5dKl0W8oPWdItC9n7UXkiCJVf2Ky2o4xw4SIt8iW4/edit#slide=id.g9d2db28c66_0_0 | Slides: Notifications overview]]: these slides offer an overview of: 1) the impact these notification interventions are intended to have and 2) the order in which we will work on these interventions. - [Project page on mediawiki.org](https://www.mediawiki.org/wiki/Talk_pages_project/Notifications)
  • T271846: Deleting Posted Comments
    • Task
    Problem: It's not obvious to (yet desired by) junior contributors, how to delete a posted comment. This came up in the New Discussion prototype usability testing, when testers attempted to delete their post after it was published, they struggled. Possible Solution: TBD Related Tickets: * T243249
  • T271839: Language Selector confuses junior talk page contributors
    • Task
    **Problem:** 2/10 test participants saw the keyboard for language selection and thought that would help them format content, before realizing they were in the wrong section. {F33996859 width=600} **Possible Solution:** - Changing the location of the language selector **Related Tickets: ** * T243249 | New Discussion 1.0 - Usability Testing * T255191 | ULS IME icon partially obscures Reply button
  • T269001: Improve experience of adding and editing an infobox
    • Task
    **Problem ** As a junior contributor I want to add and edit an infobox but it's hard for me to figure out how to do it, where to put it and what template to use. When I do copy and paste a template using wikitext I then have to go in and figure out what fields I can add to edit (again by copying from another article). This is hard to do in wikitext and VE. **Possible Solutions** - Make an "add an infobox" button (or just make adding an infobox a more discoverable workflow) - Make a "Suggested infobox" experience
  • T268423: Design icons and add sections on site for blog and research
    • Task
    == Background/Goal All icons in [[ https://design.wikimedia.org/ | design.wikimedia.org ]] should follow our [[ https://design.wikimedia.org/style-guide/ | style guide ]]. {F33922421 width=800} === Acceptance criteria (or Done) [] Adapt all icons to the Style Guide **Illustrations of the following concepts** [-] Design Style Guide [-] Participate [-] Blog [-] Research **Blog** [] Update illustrations here [[ https://design.wikimedia.org/ | design.wikimedia.org ]] {F34974018}
  • T264148: [SPIKE] How might we enable people to "invoke" templates on Talk Pages?
    • Task
    **Opportunity:** There are several templates that could be integrated into conversations and we could make this easier for experienced contributors and integrate teachable moment touchpoints for junior contributors. **Examples:** - I'm using a workflow that kind of hacks the talk page template, so i can just type a command that invokes the template in context - I'm writing about a policy and want to reference it easily, so I can type a command that pulls up all the policies to choose one **Possible Interventions:** - slash commands **Useful Links:** - T250768 - [[ https://support.google.com/hangouts/thread/46465375?hl=en | Slash commands ]] in Google Hangouts - [[ https://api.slack.com/interactivity/slash-commands#:~:text=Best%20Practices-,What%20are%20Slash%20Commands%3F,context%20provided%20by%20that%20payload. | Slash commands ]] in Slack - [[https://www.pcgamesn.com/minecraft/minecraft-console-commands-and-cheats | Minecraft console commands ]]
  • T259266: Evaluate Talk Page taxonomy
    • Task
    ==Problem In T257281 we learned that users are confused and sometimes unable to understand the words on buttons and navigations in the Talk Page interface. We've observed issues particularly with the following terms: - User Page - User Talk - Talk - Reply - Edit Source - Discussion ==Possible Solution Evaluate Talk Page taxonomy holistically with a taxonomy audit
  • T259263: Differentiate User page and Article page
    • Task
    == Problem Users come to Article Talk Pages and User Talk pages with different goals. Through usability testing such as T257281 we've learned that on article talk pages contributors are going with the intention of discussing ways to improve the article. Conversely, there isn't one standardized thing that people do on user talk pages. The issue is that many junior contributors come to the user talk page expecting to see some kind of inbox or user message center. ==Possible Solutions - [ ] Treat user talk pages differently than article talk pages - design a different ui and possibly ux
  • T255454: Initial messages/ topics on Talk page are challenging to identify in the context of the page
    • Task
    ##Problem Usability testers have reported that it's challenging to scan the page to find the conversation initial messages. Junior contributors noted this on pages that were not populated with a table of contents due to fewer conversations on their user page. ##Screenshot {F31866799 width = 600} ## Possible Solutions - Style the initial comment/ message to look distinct from the replies - Add a TOC to the user page as soon as a topic is added to a page.
  • T255451: "From Wikipedia" page metadata/subtitle confuses junior contributors on Talk pages
    • Task
    ##Problem Several usability testers reported that they thought the conversation on the talk page was from Wikipedia or some kind of admin after reading this interface elements text. ##Screenshot This screenshot is from the prototype server, so it says "From devwiki" but just imagine that it says "From Wikipedia" {F31866769 width=600} ##Possible Solutions - remove from Talk page
  • T255448: Consider changing the segmented navigation titles (visual/source)
    • Task
    ## Problem Several usability testers were confused by the terms "Visual" and "Source" - which indicates to me that the terminology is [[ https://en.wikipedia.org/wiki/Inside_baseball_(metaphor)#:~:text=In%20American%20slang%2C%20the%20term,wonks%2C%20insiders%2C%20and%20aficionados. | inside baseball ]], in that the terms might be familiar to us as product names, but not recognizable or actionable for the average user. ## Screenshot {F31866740 width = 150} ##Possible Solutions - changing the terms - aligning the ui with visual editor - something like this mockup from @schoenbaechler {F31866745 width = 300} - moving this into a toggle to minimize source mode
  • T229429: Highlight if there any places the mobile Save dialog needs to behave differently than desktop
    • Task
    Confirm the applied changes to the Save dialog on desktop doesn't cause any issues, and highlight if there any places we think mobile needs to behave differently.
  • T229428: Tweak the mockups legal message placement to account for keyboard being up
    • Task
    As @Esanders said in Zeplin "Currently we focus the edit summary text box when opening this page, which means the keyboard is visible, so we should reconsider what it means to bottom-align this." Note: before we implement any changes to how/where the "legalese" is presented, we should get legal's approval. See: T229462 {F29920046 width=300 }
  • T227894: [EPIC] User Testing Outcomes
    • Task
    Let's link out to all bugs, outcomes, and implementation fixes related to V2 here. === Blocking === - [ ] T228227 //in QA// - [ ] T228229 //in Code Review// -- Context: //"...After changing the target of an existing link, you go back to the updated card. However, it does not feel as going back, since the card is not there for an instant and opens after a fraction of a second.// === Backlog === - [ ] T228232 //Stalled// - [ ] T227899 //in QA// - [ ] decide if "remove link" button is obvious - [ ] Add instructions to wiki and external link search T229877 - [ ] T228230 //Depends on "✔️" first being removed from Toolbar// - [ ] Revise "?" icon for red links (Wikipedia pages that do not yet exist) - [ ] Make sure undo button is always accessible - [ ] Add "globe" icon to external link search - [ ] Autocomplete external site inputs with correct preface T229839 - [ ] Create simplified error messages - [ ] Improve search with table of contents, search bar or some other design fix
  • T227658: Find an easier way to put testing content on server(s) for testing purposes
    • Task
    ==Why are we doing this?== Every time that we've run a test simultaneously on usertesting.com and on-wiki, the Editing team has encountered several issues, including: * inability to give consistent instructions to tester due to potential edit conflicts * inability to have each tester test an article in a pristine state
  • T219869: As a Reactive Corrector using the mobile web editor, I want to easily find and access Visual Editing mode.
    • Task
    ===Why are we doing this? During usability testing, we found that most users did not realize how to access Visual Editing mode when Wikitext is the default editing mode. ===User story As a user of the mobile web editor, I want an easy way to find and access Visual Editing mode so that I can focus on editing and publishing. {F28560985 width=600} ===Proposed solution TBD
  • T219812: Editor wants to quickly move back to whole page editing
    • Task
    This edge case was identified in T209984 If a user wants to edit a section and then quickly move back to editing the whole page, it takes a handful of (unnecessary) steps. This could be mitigated with a some ux improvements.
  • T216162: Decide on strategy for how many sub-levels to support in section editing
    • Task
    In multiple user tests the topic of [[ https://www.mediawiki.org/w/index.php?title=Topic:Uu6k1y7go907coti&action=history | "too many pencil" ]] buttons has come up. This also came up in the design review for section editing. The purpose of this ticket is to explore the maximum number of sub-levels that should be exposed to the Editor without giving them cognitive overload. //Example//: {F28217492 width = 300}
  • T211787: Design a Test for prototype
    • Task
    As a designer I need to design a test for the toolbar prototype for usertesting.com primarily, and onwiki secondarily.
  • T209091: [EPIC] Clean up UI bugs in Visual Editor
    • Task
    **Background:** There are a handful of design bugs that are blocking the fluency of the current user experience of Visual Editor. The goal of this task is to capture those bugs so that we can do a test to see what pain points still exist after this clean up is complete. --- **Bugs:** - [ ] Publish button state changes (from button to link) when user moves into providing Edit summary mode - [ ] Input box overflow in Edit Summary - [ ] Language used to indicate state is confusing "save your changes" vs. "publish" - [ ] Review your changes requires awkward/unexpected double tap - [ ] Toolbar height should be reduced T209015
  • T208744: Perform comparative analysis of copy and paste UIs
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T208743: Perform comparative analysis of feedback UIs
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T208742: Perform comparative analysis of UI mode differentiation
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T208740: Perform comparative analysis of table of contents UIs
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T208739: Perform comparative analysis of scroll position remembering UIs
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T208738: Perform comparative analysis of editing toolbar UIs
    • Task
    Background: As part of the 2018 Annual Plan work for the foundation, the Editing team is looking at ways to improve the mobile editing experience on the web. In order to make sure that we are taking into account best practices, we need to research common patterns for UI. Research goals: - Explore the patterns on the existing interface for Wikipedia on mobile web - Explore what kinds of UI patterns other editing tools are using
  • T207517: EPIC: Synthesize VE Brainstorms and Share with Community
    • Task
    **Background:** We conducted initial brainstorming sessions for improving basic functionality of Visual Editor T204628 - before we can take any next steps, we need to synthesize the outputs from these sessions. **Goal:** 1. Share work that has been done up until this point 2. Begin to develop a plan for prototyping. **To Do:** - [ ] Design intervention ola
  • T206463: Holistically review OOUI components used in Visual Editor dialogs
    • Task
    **Background:** Some of the OOUI components behave unexpectedly on different screen sizes. **Proposed Solution:** We need to audit the screens of the existing userflow (for persona Yanko) and identify visual inconsistencies and pain points. **Useful Documents:** - [[ https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide | Visual Editor User Guide ]] - [[ https://phabricator.wikimedia.org/maniphest/task/edit/202575/ | recent dialog improvements ]]
  • T204192: Research text input support for Indian scripts
    • Task
    **Background:** As part of the annual plan for editing with Visual Editor on mobile, the Malayalam, Bengali, Hindi and Marathi wikis were identified as some of the [[ https://www.mediawiki.org/wiki/Mobile_editing_using_the_visual_editor_report#Target_wikis | target wikis. ]] Recently, @dchan shared with me that he learned that many people in India use Latin letters to write their Indian language on mobile. This is relevant to our user stories, because our Indian-language wikis use native script not Latin, so basically every contributor must be tech savvy enough to have taught themselves mobile text input in the native script, which is not the norm. **Goals of Study:** 1. Confirm how rare it is for Indian language speakers to know how to perform mobile text input in their native script. 2. If this is a pain point, incorporate this into our personas and user scenarios for the [[ https://www.mediawiki.org/wiki/Mobile_editing_using_the_visual_editor_report#Background | Annual Plan ]] on Visual Editor
  • T201877: EPIC: What are the current best UI practices for mobile editing?
    • Task
    ===Planning Document(s): === [[ https://etherpad.wikimedia.org/p/MobEditingReview | Etherpad ]] ------- ===Background:=== Before diving into any edits, tweaks or redesigns that will aim to [[ https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2018-2019/Audiences#Outcome_3:_Mobile_Contribution | increase mobile contribution to Wikipedia]], we need to now take a look around to gain an understanding of what are the current best practices and trends in mobile editing user interface design. A comparative analysis will give us an opportunity to methodically review the different kinds of editing experiences that are happen on the mobile web, i0S and android platforms. ===Goals of Study:=== 1. Collect data by category of editing experience type, focusing on both long and short form editing experiences. 2. Identify specific features/characteristics that might allow for a consistent mobile ui across products. 3. Set the stage for prototyping of new ideas. ===Notes:=== The study will be conducted by three designers: - @RHo - @cmadeo - @iamjessklein ------- ===To do after study:=== - [ ] synthesize findings - [ ] present/share findings
  • M269: VE-mobile section edit web flow
    • Mockup
    This is a web flow for a user making an edit in Visual Editor on mobile using section editing functionality. see: T208737
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL