Reading/Web/Desktop Improvements/Metrics and phases/zh
- Main page: /Research and design: Phase 1
We began by considering the current default experience on desktop (Vector) and asking ourselves: in what ways can we improve upon this? Where are opportunities to modify the interface in order to create a better experience for all readers and editors? How can we make it easier for people to do the things they want to do? How can we create a more pleasing reading environment? Of course while exploring these questions we kept in mind the project's constraints. The research and design activities we engaged in in order to explore these questions included:
- Understanding the history of the desktop interface
- Reading previous Wikipedia research conducted by the Wikimedia Foundation or other research institutions and individuals
- Discussions at our team offsite to develop a shared understanding of the project and generate ideas
- Winter, Timeless, and other Wikipedia redesigns
- Reading about redesigns/updates of other large websites (Reddit, Twitter, etc.)
- Conducting an audit of other large websites to try and glean common structural elements
The output from phase 1 was: a better understanding of the desktop interface, and proposed focus areas for improvements. We didn't have strict criteria for what a focus area could be. Generally speaking it was an idea of an improvement we could make, though at varying levels of specificity, such as: a less cluttered reading experience, or language switching ease. The proposed focus areas are:
- Creating a more focused and "quiet" reading environment by consolidating or optionally collapsing navigational links, including:
- Main sidebar navigation
- Article tools
- User tools
- Language switching
- Article navigation / table of contents
Additional, more feature-specific, ideas that came up: reading preferences (e.g. dark mode), share button, larger edit button / add new article button (for smaller wikis) / making it more obvious how to "get involved", article stats / activity summary.
A few of the many ideas that have been suggested are below. Please add any prominent ideas and links you know of:
- NOTE for editors: Please edit the English version to add ideas and links, or comment on the talkpage. Don't worry about the "tvar" markup if you don't know it. We will add it in afterwards.
Focusing on the content, distinguish content from user-interface
- Collapsible sections in sidebar
- Collapsible sidebar
- Floating sidebar
- Examples: FloatSide (enwiki script), ...
- Tabs in sidebar to organise all the tools and navigation: 1) TOC, 2) Site navigation, 3) Tools (for editing, page info, gadgets), 4) Bookmarks (feature request)
- The tab icons serve also to collapse/reveal the sidebar.
- TOC in sidebar: fixed to the screen, separately scrolled.
- Example: WikiWand
- Pin-able infobox: show a pin icon in top-right corner of the infobox. When pushed, pin the infobox on the right side of the screen in a column that stays on-screen and scrolls on its own, similar to the sidebar on the left.
- Collapsible article sections: see at the bottom of the WikiWand page + add a short scrolling effect.
- Responsive width
Easier access to everyday actions
- Sticky header with search, table of contents, edit links
- More prominent language switching (moving the language switcher to the top of the page)
- Examples: Timeless skin at 1325px or wider and at 1085px or thinner, ...
- Sticky table-headers
- Examples: Gadget-StickyTableHeaders (enwiki gadget)
- Jump to the top of the page
- Examples: ToTopButton (enwiki script)
- Paragraph (¶) symbols on headings: visible only when hovering, next to the edit icon, to easily copy links to sections.
Putting things in logical and useful places
- Consolidated user menu (e.g. collapsing things like "Log out", "Preferences", and "Beta", inside a dropdown menu)
- Preferences for logged out users
- Examples: Accessibility settings/preferences (T91201), ...
- Moving article actions from the sidebar to within the article
- Examples: Winter, Timeless skin at 1085px or thinner, ...
- Easily navigate through articles - load page content using JS in background without loading the whole page
Phase 2. Developing focus areas, sketching and prototyping ideas, starting conversations (July 2019 – November 2019)
- Main page: /Research and design: Phase 2
The research activities and conversations in phase 1 helped us develop a better understanding of the landscape we were working within (i.e. the desktop interface). It also helped us develop potential focus areas to further investigate (while still remaining open to new ideas). Our next goal was to dig a bit deeper into the focus areas through sketching, prototype, and most importantly conversations with the community. The research and design activities included:
- Understanding past work, research, and experiments in respective focus areas
- Obtaining general usage data about the respective focus areas
- Sketching out and prototyping early ideas to help facilitate conversations
- Forming early hypotheses
- User interviews and other feedback at Wikimania
- Community feedback via MediaWiki (happening soon)
- User interviews with newcomers and casual readers (happening soon)
- User testing on usertesting.com (happening soon)
The output from phase 2 will include: reactions to sketches of specific interface improvements within the focus areas, a refined (i.e. more opinionated and informed) sense of which improvements are worth pursuing, a proposal for the sequence in which we could implement proposed improvements.
Phase 3. Continued user testing and design refinements (October 2019 – January 2020)
Phase 3 will be a cycle of: further testing the specific ideas that came out of phase 2, then refining our designs in response to what we learn. There are potentially some things that need to be tested as betas on actual wikis. We will be working to identify these things and figure out how we plan to test them in beta (i.e. what data we would be tracking, and what decisions we'd be making based on what behavior we see).
The output of phase 3 will include: nearly finalized designs (though we usually leave room for additional iterations during implementation) and a plan for what we want to learn as we roll things out in beta, and what decisions/changes we would make based on that information.