Grants:IdeaLab/Timeless
Abstract: A new skin, Timeless, has been deployed to the Beta Cluster, but to make it worth eventual deployment to all Wikimedia projects, we need a better understanding what's needed from a better skin, and the ability to devote development resources to making it meet these needs. This grant will serve to address this by compiling research into the current skinning usage and pitfalls on the Wikimedia projects, and developing Timeless into a complete product that may later be used as a baseline for further work in follow-up projects intended to develop on many of the underlying issues with MediaWiki's user-facing interfaces.
Project idea
[edit]What is the problem you're trying to solve?
[edit]Wikipedia and its sister projects have major problems with their front-end interface (skin), and yet there exists very little research into how they are used or what problems exist. The existing interface (primarily skins Vector and MonoBook) works, but is difficult to develop and design for; convolutes the Wikimedia and Wikimedia projects brands with every other wiki using the same interface (as the MediaWiki default, Vector is used on over six thousand sites[1]); and is often very difficult for new users to learn, with even long-term editors being slowed down by often convoluted workflows.
We need an upgrade, and have needed one for years now. However we lack any research into exactly how to make this happen in a way that does not interfere with existing workflows and which takes into account all stakeholders - editors, uploaders, backend developers, front-end designers, template and gadget creators, and every combination thereof, on all the various projects.
As such, the below are only examples, and are not comprehensive of the specific problems faced by users and developers.
Problems for end users
[edit]
Tools as they are in Vector: toolbox (1); content actions (2); personal tools (3); subtitle tools (4); footer tools (5)
- Unintuitive tool organisation - MediaWiki has many available tools (from editing and deleting pages to user lookups to various ways to organise and look at existing pages), and yet these are not organised in a way that users can easily find them, or even in a way that avoids perceptory clutter. Instead, they are splattered all over the page. This is because there are basically only four places tools can go:
- Toolbox (1) (sidebar, under the site navigation): contains a blend of site-wide and page-specific tools, this is usually where extensions add new buttons
- Content actions (2) (tabs on top of the page): contains editing-specific actions; broken up further by Vector into namespaces, views, and actions; difficult for extensions to add things to and gets cluttered up rapidly
- Personal tools (3) - the user links and actions (at the top of the page, the login, contributions, etc) - is basically a long string of links across the top of the page
- Special ContentSub tools (4) - added as a string under the page header for specific pages (user contributions, history, etc)
- Sheer excess of tools for all user groups - the sheer number of tools is also often far more than given users need, especially readers. Wikiwand, an app that gets rid of all of this, is intensely popular, and apparently received 600,000 USD from investors.[2] It is also likely that, were the option more discoverable, readers would be more likely to try to edit, or even realise that they can.
- Poor handling of different devices/screen resolutions in the skins - Vector and MonoBook are both full-width skins with no mobile support. This has led to various workarounds, including setting random chunks of content to fixed-width (not recommended, as this introduces design clutter that is often not compatible with different skins and mobile) and the deployment of a separate extension skin specifically for mobile, MobileFrontend, which introduces its own raft of problems.
- Content is created/previewed for whatever device the user is on, and does not display correctly on different devices/sizes - this usually shows up as a problem where content created on/for desktop does not translate well to mobile. Because mobile is currently served a completely different skin (Minerva, part of MobileFrontend), previews cannot preview this unless the user was already in that skin, and even different screen resolutions on desktop can look wildly different in MonoBook/Vector due to non-fixed-width layout. Related: Community wishlist item Mobile preview from desktop editing.
- Scant built-in support for reusing skin colours, or configuring skin styles - it's possible to make an infobox match the toc and catlinks colours, but only if you don't want to use highlights, or use any special functions. Generally the only way to perform content styling that matches the skin is to write new CSS to match the skin: which then won't work with multiple skins; or when you want a night mode or high-contrast mode.
- No built-in modes for different use-cases - night (inverted dark version), high-contrast, content only (hides usually unneeded tools in order to make it easier to focus only on the content), larger text. See T91201: Accessibility settings/preferences, which includes a prototype for such tools on Vector.
- Poor integration of new features - per the difficulties below in adding them, this also impacts the users themselves.
Problems for developers and designers
[edit]| “ | Isn't our ve-mw integration code disgusting. And the worst part is that most of this gross mess is actually needed. | ” |
— Some dev | ||
Essentially, skinning is a mess. The code is HTML soup; the hooks are lacking and inconsistent; what APIs exist are confusing and keep changing; documentation is old, only addresses very specific target uses, and often flat-out wrong; and most of the existing codebase is ancient, to the point where it even appears to predate much of the coding style guides, let alone the various abstractions and interfaces that would significantly improve its handling/functionality. Even the attempts to resolve these problems have often made them worse; various extensions and libraries exist attempting to provide their own themeing frameworks, but they are not consistently used and generally lack any way for the skins themselves to hook into/extend them.
What this means, and other problems:
- Difficult to add new features - even a simple link to a new special page requires knowing what tools groups are available and then specifically adding it to that, as opposed to telling the skin 'link is this kind of tool, handle it'. Adding something new to the general interface such as a notifications badge or new editing interface is incredibly complicated and requires special handling in both the extension and the skin, as the interfaces are incredibly basic and lack any built-in methods to communicate and handle needed information between them.
- Difficult to design more complicated features and workflows while maintaining coherence with skin styles - there is no standard way to reuse skin colours, there are almost no skin-set definitions for what different types of UI components should look like. Even OOJS UI, which defines themes that are supposedly for use with particular skins, does not support creating a theme in the skin itself, the themes themselves are consistent with almost none of the existing skins (the exception being the Apex theme and skin, which do go together, but are not used on Wikimedia projects), and it is very difficult to reuse for more than basic forms or widgets without significant development of OOJS itself or overrides.
- Poor guidelines on best practices when developing around skins - each extension/feature essentially needs to build its own interfaces, and how it does this is totally up in the air. There are few guidelines even for as simple of things as to what to expect from the DOM, or what is reasonable to expect from the DOM.
- Resistance from end users/editors - interface changes have a history of making things worse for them, not better, due to only being made for a specific skin and breaking others, inadequate research, and poor communication. As a result, there is generally a fair amount of resistance to any potential change especially on larger projects such as the English Wikipedia, but any project can potentially be affected by this. Changes need to be based on research into specific problems, providing features users actually want, and tested effectively before deployment. Developers also need more information on what these would even be and how to go about this.
- Archaic and messy code - the core and skin code is old, and the source shows it, but there is also little to be gained from doing a refactor for a refactor's sake. Often even when someone does refactor them, it doesn't actually improve things, as unlike other parts of MediaWiki, we have few set standards as to how these files should look.
- Wikimedia branding and visual identity - current skins have no themeing support, and cannot be set to use project-specific colours in order to emphasis branding, nor are any really consistent with the overall visual style of Wikimedia and Wikimedia-produced extensions.
What is your solution?
[edit]-
Screenshot showing the Timeless skin running on Devwiki
Timeless is a new skin based on the existing layouts of MonoBook and Vector, but designed after the Winter prototype by Brandon Harris as well as various styles by the Wikimedia Foundation, with a more modern, flexible appearance and responsive layout. This skin has been going through the review queue in preparation for deployment to Wikimedia projects, but in its current state, it is very basic in its feature set and support for other extensions and does not serve as a significant improvement, if any, over the existing skins.
Examples:
- https://timeless-skin.wmflabs.org/wiki/Main_Page - a Labs wiki specifically for testing Timeless.
- https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page - the Beta Cluster clone of the Simple English Wikipedia. I highly recommend checking this out to see what it currently looks like and how it would act in production. You can see what any page would look like in Timeless by appending
?useskin=timelessto the end of the URL string, or simply create an account and in your preferences, under appearance, set your skin to Timeless.
The skin is far from complete. Thus I would like to be able to dedicate time to working on this, both the development aspects of the Timeless skin, and especially the research and outreach that is sorely needed to determine what, exactly, our needs are, in order to address them in an organised fashion and establish best practices moving forward.
Project goals
[edit]The two primary goals of this project are as follows:
- To solve the most significant underlying problem of all of our current front-end interfaces, which affects everyone who tries to work on these: we do not know how they function or are used in practice, and thus we have little idea how to fix them.
- To progress toward fixing these problems, through Timeless, thus showcasing the results of the above in the form of a much-needed deliverable product.
Measurements for success: outputs
[edit]Things I will do/produce over the course of the project:
- Documentation of interface practice and expectations as pertains to Wikimedia projects
- Best practices, existing usage of, and problems with currently used skins and the MediaWiki skinning system in general
- Research into the various aspects, summed up in discoverable, applicable documents
- Develop the Timeless skin into a complete product
- 'Complete' being defined as no major compatibility issues, no major bugs, and all primary features implemented. (workboard)
- People need to actually be happy with it.
- Work with pilot communities to test the Timeless skin
- Projects listed on phabricator:T154371
- Reports to keep all stakeholders in the loop
Specifics, including timewise, are laid out in the Project plan.
Measurements for success: outcomes
[edit]Things that will ideally happen as a result of the things I do/produce over the course of the project, but I will not do myself (or if I do, it will not be as part of this project):
- Research and documentation are used by others
- Documented usage patterns enable WMF or other teams to more effectively choose their own project directions, and save time and effort in producing a better product
- Documented problems are resolved by other developers
- Other, better skins are also produced by volunteer, WMF, and third-party developers based on a better understanding of how skins work
- Timeless is deployed across all Wikimedia projects
- A good number of users adopt it as their preferred skin
- Stretch: a cross-project consensus to establish it as the new default
- If Timeless proves a viable default, resolved problems increase new editor retention and long-term editor effectiveness
- Best practices are established for skin coding and applied to other skins
- Common elements are abstracted out, allowing for better extension hooking and more predictable DOM
- Existing skins are refactored to behave consistently
- VE- and other wanted extension-integration into non-Wikimedia-deployed skins becomes the norm, not the exception
Existing data on skin usage: T147696: Statistics about /active/ users of skins on the Wikimedia cluster, done in December 2016. Lacks information about users who may log in for settings, without actually editing (may not be possible; user_touched is apparently unreliable, or at least was fairly recently).
Project plan
[edit]The grant will be broken up into four activities: research and documentation, software development, community outreach and collaboration, and reports.
These will overlap considerably, and each activity is intended to help drive the others forward concurrently. Example: community outreach establishes need for feature X, research into existing implementations of feature X results in an implementation in the software, implementations are all documented in the documentation, along with reasons for the need in the first place. Could also easily happen in the exact opposite order.
Research and documentation
[edit]Goal: Create documentation of existing usage of and problems with currently used skins and the MediaWiki skinning system in general as it pertains to Wikimedia projects
- Issues with specific skins
- Various workflows across the projects, from countervandalism to tracking related content to dealing with very specific kinds of content
- User expectations surrounding existing interfaces
- How specific tools are used, and if they are used at all
- What users typically add with gadgets, or override, which gadgets are popular (what do users want/add that is not provided by the software itself)
- What all insane hacks have been required by various interface extensions to do interface things
To do this, we need outreach to and research into the needs and existing practices of all stakeholders, such that the development work may be guided to optimally serve their use. Stakeholders include:
- Wikimedia content editors (across all projects)
- Wikimedia file uploaders and curators (especially on Commons)
- Wikimedia Foundation and volunteer MediaWiki developers
- Wikimedia Foundation designers
Software development
[edit]The technical application of everything dredged up elsewhere. Will also serve as a coping mechanism.
Goal: Develop the Timeless skin into a complete product
- Features development
- Built-in modes for a dark layout (Night) and a content-only layout (Winter)
- Theme support, to allow projects to set the skin to use their own custom colours in a consistent, cohesive manner, such as to emphasise the Wikimedia branding or do something distinct for a specific project while still maintaining the general look
- Support for inheriting skin styles in extensions and templates
- A backend interface for other extensions to hook into the new tool organisation
- Bug fixes
- Compatibility fixes for existing extensions, gadgets, and workflows
Community outreach
[edit]This includes a lot of overlap with the research aspects, and will also serve as much of the testing for the software development.
Goal: Work with pilot communities to test the Timeless skin
- Current projects: fr.wiktionary, fr.wikinews, fr.wikiversity, commons, en.wikisource (may want to include some specific others: meta, mw.org, a wikipedia)
- Create and maintain hubs/designate specific users for triaging/reporting issues so they are all consolidated in phabricator
- Solicit specific stories/feedback/testing for features undergoing development/design
- Investigate normal usage and practices on the projects in order to better understand the perspective of the users
Reports
[edit]This is essentially a combination of outreach and documentation, but an important and oft overlooked aspect thereof, taking form in reports that will go out from time to time.
- Updates on relevant mailing lists directed at the particular audiences (wikitech-l, wikimedia-l)
- A hopefully regular cross-project newsletter for anyone who wants that
- Grant reports (hello this is a grant proposal)
Budget
[edit]This project is designed to function as a full-time job for the duration of its occurrence, so that I don't need to worry about juggling other jobs at the same time and can properly focus on making it succeed.
A general breakdown of expected proceedings is as follows:
| Item | count | time per | total cost |
|---|---|---|---|
| Research and documentation | |||
| Specific skin issues (what affects already-deployed skins) | 4 | 4 days | |
| Stakeholder outreach (mailing list emails and the like) | 5 | 10 hours | |
| Existing workflows | 15 | 2 days | |
| Existing tool usage | 40 | 2 hours | |
| Existing gadgets | 20 | 1 hour | |
| Insane extension hacks (how do extensions like VE and the like actually hook into mw?) | 6 | 3 day | |
| 516 hours | 25,800 | ||
| Software development | |||
| Miscellaneous bugs (minor features, errors, etc) | 50 | 3 hours | |
| Features development (major features) | 6 | 2 weeks | |
| Extension compatibility bugs | 20 | 4 hours | |
| Gadget compatibility | 20 | 2 hours | |
| wtf | 2 | 1.5 weeks | |
| 870 hours | 43,500 | ||
| Community outreach | |||
| Hub creation, management, and solicitations | 5 | 20 hours | |
| Learning how to use the project (how can I design for it if I don't even know how it works?) | 5 | 1 week | |
| 300 hours | 15,000 | ||
| Reports | |||
| Newsletter | 17 | 1 hour | |
| Notifications | 8 | 3 hours | |
| Grant reports | 4 | 1 day | |
| Arguing with people | 7 | 2 hours | |
| 71 hours | 3,550 | ||
| Subtotal | 87,850 | ||
| Miscellaneous other things | |||
| Buffer: Either not accounted for at all and/or total miscalculations in the above
This includes expenses (travel, hardware, etc), unexpected blockers, and anything else within scope that might turn out to be important |
n/a | 12,150 | |
| Total | 100,000 USD | ||
Disclaimer 1: This is probably an understatement. The buffer is intended to resolve this, but may also be an understatement.
Disclaimer 3: All numbers are qualified prognostication only, designed to give a general idea of what will be required. All time estimates are based on guesses as to total time spent on each over the course of the project.
The number of hours and total cost, assuming 50$/hr (usual charge for non-profits and the like) and accounting for holidays and the maximum grant times/amounts, suggests that this project requires a 100k USD grant spanning 12 months.
Meta
[edit]This proposal has been announced on the following objects:
- Commons (primarily a proposal to test the skin, also mentions the grant)
- en.Wikisource (primarily a proposal to test the skin, also mentions the grant)
- phabricator:T154371#3132832
- Have also emailed wikitech-l and wikimedia-l. Not sure the best way to link this here.
Others may also happen per the Project plan.
Get Involved
[edit]Volunteers are welcome to join or endorse - using the buttons in the infobox is the easiest way to add yourself to this section!
Grantee
[edit]Isarra is one of MediaWiki's foremost experts on skin development, specialising in tracking workflows and addressing the overall user experience of a product in its design. She worked on creating the extension CollaborationKit as part of another grant, WikiProject X, which was based on similar research into what users were already doing. Along with Timeless, she has created/worked on several other skins as well: BlueSky, GreyStuff, Splash, Mask, Example.
See, I'm amazing and I know what I'm doing, and I've done things like this before. Sort of.
Participants
[edit]Want to join this idea? Add your name by clicking the button in the infobox, or edit this section directly.
- Jack Phoenix is helping. He's the co-maintainer of Timeless. -— Isarra ༆ 07:58, 4 April 2017 (UTC)
Endorsements
[edit]Want to endorse this as a good idea? Add your name by clicking the button in the infobox, or edit this section directly.
- This looks like a carefully thought out proposal with a lot of potential to make significant improvements in UI. In the work we're doing to bring in large groups of diverse new volunteers, we'd be happy to connect with you! DrMel (talk) 04:47, 15 March 2017 (UTC)
- I think that the proposed version still has a lot of problems, and many improvements will be required. But on the whole, I support this proposal. We need a new light and customizable skin. — putnik 05:00, 15 March 2017 (UTC)
- I was recently requested to do a pre-deploy-to-beta-cluster security review of the current version of this skin, which resulted in me playing with the current version. This is the most excited I've been about a new skin in a long time. I am very excited to see where this goes when completed and think there is a lot of potential here. Bawolff (talk) 05:54, 15 March 2017 (UTC)
- Yes. --MZMcBride (talk) 00:07, 16 March 2017 (UTC)
- There is a desperate need to update and modernize our outdated interface. While the last revamp occurred in 2010 it was still only a very minor step from the older interfaces, and still includes some very clunky interface choices. Building something which strongly considers community feedback — and which at the same time is easier to adapt and build upon upon in the future makes this project very well planned. Isarra is probably the best person for the job, with considerable interface knowledge and with good insight into the editing community. CFCF 💌 📧 09:07, 19 March 2017 (UTC)
- Please, please make this happen. I've been a Wikipedian for 13 years now and yet every time I want to find the Latest changes, I have to use Ctrl+F. The current skins are so cluttered that it makes our interface a labyrinth, not only to newcomers but to grognards like myself as well. Halibutt (talk) 11:11, 27 March 2017 (UTC)
- Isarra is an active participant to Wikimedia and MediaWiki development. There is at least already one Wikimedia community currently excited to get a responsive skin, so a public has been found. Code has been reviewed from a security point of view and is live on our beta cluster. This grant will allow to demonstrate the skin viability, which could have a great impact on our design research and user experience, and as such, is aligned to our goals. No particular WMF engineering access is needed to go on this work: the work is delivered as commits to a dedicated repository, and beta cluster picks automatically changes from master branch without any deployment access requirement. So the "independant" criteria for technical grants is satisfied too. Dereckson (talk) 15:29, 27 March 2017 (UTC)
- 100% endorsement. Active and dedicated volunteer with proven track record, tackling a problem that has been ignored for too long. —TheDJ (talk • contribs) 14:51, 28 March 2017 (UTC)
- Afair, the current skin was made in the pre-Wikidata, pre-VisualEditor, pre-ImageViewer era, so a lot has changed since then. Looking into the future, I'm sure the Structured Data project could benefit from a collaboration, so please check with them whether it would make sense to invest some additional time/money into that. I also see this as a chance to fix at least some of the many UI-related bugs and feature-requests (e.g. my personal pet phab:T102776). --El Grafo (talk) 14:54, 31 March 2017 (UTC)
- I cannot endorse this enough. Vector and Monobook are dated and painful to use. Timeless is clearly a dozen steps in the right direction. Issara, as TheDJ rightly points out, is a proven contributor in our technical spaces. I have no doubts on their ability to get this done. ^demon (talk) 22:17, 31 March 2017 (UTC)
- Not sure if I like everything with it (it is way to much blue, and green, and red, and…), but it is probably wise to start working on a next generation skin. — Jeblad 14:08, 1 April 2017 (UTC)
- isarra starts from the right end, really commit code. think about it. stay on it. try it. have a vision. --ThurnerRupert (talk) 00:36, 2 April 2017 (UTC)
- cheap dev, potential big impact. Slowking4 (talk) 14:20, 4 April 2017 (UTC)
- I am thinking for long time about new skin in which all things organised better. Go ahead.-Nizil Shah (talk) 14:47, 4 April 2017 (UTC)
- Isarra has been skinning MediaWiki for years now, and has built tremendous expertise in designing interfaces around its idiosyncrasies. I'd love to see what MediaWiki looks like in a skin designed from the ground-up to be extensible, accessible and to make common tasks straightforward, and I hope she's funded to work on it! Gaurav (talk) 01:24, 5 April 2017 (UTC)
- So many of our problems with making progress on improvements to Wikimedia projects' interfaces begin and end with the skin. An overhaul is much needed. I have worked with Isarra and she has a good sense of how to design for the Wikimedia projects. I see no reason why this wouldn't be a high-value, high-impact project. harej (talk) 16:48, 5 April 2017 (UTC)
- I support this. The two defining features that came from Winter, namely persistent personal and search bars and more prominent placement of interlanguage links, are by themselves much-needed. There are other advantages in this skin as well. Vector is seven years old and it's time for an update. --Amir E. Aharoni (talk) 15:30, 12 April 2017 (UTC)
- I support the project; progress with our interfaces is a must, and this seems like a project with good progress and future success. ~SuperHamster Talk Contribs 06:32, 15 April 2017 (UTC)
- MediaWiki and WMF desperately need a fully-featured skin which is usable on both large and small displays. I think it would be feasible to deploy Timeless as a non-default option within the time allowed by the grant. Deployment will make it much easier to collect user feedback on the skin's benefits and shortcomings. I support fully funding this proposal. -- Tim Starling (WMF) (talk) 06:28, 30 May 2017 (UTC)
- I thought I had already left a note here, but I definitely endorse this proposal. Isarra is very passionate about skins and has the skills and resources (she's never afraid to ask for help!) to make this project a success. Legoktm (talk) 18:39, 30 May 2017 (UTC)
![[1]](https://i0.wp.com/www.adpushup.com/blog/wp-content/uploads/2015/02/f_reading_pattern_eyetracking.jpg){kind=link}
![[2]](https://i0.wp.com/www.adpushup.com/blog/wp-content/uploads/2015/02/grazehawk-wikicomparison-resize.jpg){kind=link}