Per https://www.mediawiki.org/wiki/Review_queue, we need to perform a design review before to deploy this skin.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Isarra | T154371 Review and deploy Timeless skin | |||
Resolved | • Nirzar | T158012 Design review of the Timeless skin |
Event Timeline
From https://www.mediawiki.org/wiki/WMF_Project_Design_Review_Process, I'm not really sure this applies? Or what it entails, at least, as that page is technically archived.
I don't believe a WMF staffer needs to perform a design review to deploy a new skin. I've never heard of or participated in a formal vetting process for skins. That said, if @Isarra would like input, I am happy to provide some and/or suggest other (more qualified) designers who may be willing to give the design a look.
@Isarra I can ask the designers. Just to get a sense of your timeline: How urgent is this? If you got feedback two weeks from now, would it still be useful? A month from now?
Not at all urgent - either of those would be useful. This whole thing started up rather sooner than I expected because other people too an interest, but there aren't any real deadlines that I know of - the thing could bear improving no matter what stage any of the current stuff is at.
just a note that I am taking this off the 'design research' workboard for now, since that board is used to triage solely my work and @aripstra 's. But as soon as I get the requested info from @Isarra, I'm sending out an open call to everyone design-adjacent at WMF to test it out and provide feedback. We'll see who bites. If no one does, I'll do my best to provide some meaningful feedback myself.
@Capt_Swing: You can check it out on social-tools.wmflabs.org (also see T154371#3023907 where @ashley answered that question and also provides some more info about it)
No labs wiki yet, but it's currently the default here: http://wiki.zaori.org/wiki/Main_Page. I recommend http://wiki.zaori.org/wiki/Category:Random_test_pages. I can create accounts for people if they want, but ideally we'd just have a labs project specifically for this, with some sort of proper auth thingy. Or something.
Working on that.
@Capt_Swing To help a little bit to prioritize: the initial security review has been done, with some little development tasks as actionables
Thanks @Dereckson! @Isarra I reached out to a bunch of WMF designers yesterday, and @Nirzar responded (almost immediately!) and agreed to provide design feedback. So I'm going to tentatively assign this task to him.
Ah, cool. Also as a general note, there are basically three layouts - the desktop layout (large with columns), the small desktop layout (probably also used on at least some tablets, where the menus are collapsed into dropdowns in the header), and the mobile layout, which is more... mobile-y.
Wiki specifically for timeless: https://timeless-skin.wmflabs.org/wiki/Main_Page
To see what it looks like and how it acts on a copy of production, I highly recommend checking out https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page - it's a database copy of the simple english wikipedia running all the pre-productions software, including timeless. Just make an account, set your skin to timeless, and see what various workflows look like.
I am not a designer neither I know anything about UI and usability (I am just an editor). I like the theme, but there is something that bothers me about it. The skin is supposed to be "responsive" (whatever that means)- but it creates gray bars taking 50% of my screen state- the following is an exaggeration by reducing font size just to get my point:
That doesn't happen with any other theme I tested (CologneBlue, Vector, Modern, Monobook) all adapt to my screen size and if I make the font smaller, I still get 100% of my screen used. Yes, I know, #firstworldproblems
I can report it as a separate ticket if preferred.
@jcrespo This is by design. Responsive means it responds to device size in order to be usable and readable regardless of what the device is. On small devices, this means the text fills the entire screen (sidebars go away). On very large devices, this means the max width caps in order to prevent the text from becoming overly long on each line, which, like excessive narrowness, also impacts readability (though this can also mitigated by one being used to it, or by there simply not being much text to read at any given time (very short or separated blocks)). Basically it boils down to the block of the text exceeding the extent of the viewer's field of vision: it becomes very difficult, at the end of a line, to then locate the beginning of the next; and it impedes scannability of surrounding text and subsequent lines because it just plain can't all be seen at once.
With MonoBook and Vector etc, the main reason they are full-width is simply because their base design predates this really being an issue anyway. Such large monitors were much rarer back then, so there was no reason not to just use everything available.
This all being said, there are definitely use cases for using the full width of the screen (File pages potentially come to mind, as with some content models, extensions for side-by-side viewing of things, etc), which probably should be properly looked into. And I'm also considering just plain upping the max width in general, since it could still be wider without any real harm and I don't think the (end) number was really chosen that carefully to begin with.
@Nirzar So, the skin can now be tested on https://en.wikipedia.beta.wmflabs.org/ (create an account and switch to Timeless in the preferences).
@Nirzar Unfortunately Timeless appears to currently be broken on the beta cluster because I screwed up. So if there's a grey bar on top and the edit links are in a weird place, that... would be why. >.>
@Nirzar Could you give us an ETA for the design review?
Security review is done and we're so waiting for you before deployment.
@Isarra Hey!
Here's a preliminary review based on first impressions - 1 of 3
It talks about Layout, color, and typography. again, I haven't gone deep into the subjects here but it tries to surface some topics.
In next 2 documents I want to compile following topics
2 of 3
Iconography & UI components
3 of 3
Navigation & hierarchy
Each will be accompanied with quick and dirty recommendations to illustrate and brainstorm ideas to solve the problems surfaced.
Hope this helps! We can also help you by running usertests and set a time to discuss in depth.
Thank you!
@Nirzar Thanks! It's very helpful to get a separate opinion on these things. I've got a few questions about some things, which I'll try to actually follow up with in the next few days.
And I'll file/link specific tasks for the rest of it.
@Isarra that sounds good. As I mentioned before, we can also set up a work session/meeting or we can do it on Phab for better documentation. whichever works for you.
@Nirzar I've gone through and filed some more tasks. Some thoughts/questions:
Audience: Unknown
- What does this mean?
A lot of layout problems from Vector still persist like navigation hierarchy
- What exactly is meant by 'navigation hierarchy'?
- You mention that a lot of (other) problems persist. Can you think of any others offhand?
Sidebar is a critical space. Value of the real estate could be evaluated more seriously
- Are you recommending some other sidebar usage besides the site navigation (such as for the ToC or page tools), or is the issue here more that the sidebar is making the content too narrow, especially at mid-lower resolutions? (T165945)
Duplicate site branding is redundant
- Agreed, but this is an issue with how MediaWiki defines and handles graphic logos, more than anything else. Would this be adequately resolved by removing the wordmark from wiki.png, bearing in mind that this would result in no wordmark in legacy skins such as vector and monobook?
- Possible solution: separate out the wordmark in these, too, and essentially add an extra element to p-logo to put both components in the same place.
- Investigation into a long-term solution is needed - different/more flexible approach that handles various aspect ratios of logos, different types of logos - are there only certain kinds that are commonly used anyway, for instance, such as banners/wordmarks/square logos? Etc.
Header breaks on small screen sizes, might be a bug
- T161461 - it's actually a bit worse than the task makes out, but yeah.
Color is perhaps the most concerning part of this design review. The overall use of color seems abrupt and noncoherent. The purpose of using these bars is very unclear. They do not reflect a functional use.
- Essentially: branding. This would likely be improved by consolidating a site's colours more into the header only, and updating Wikimedia's to match more current visual identity/style guidelines, but if the colours are only in the header, this creates an imbalance between this and the rest of the content, so the same hues need also to be incorporated into the rest of the styles in order to create a more cohesive overall design.
- How does the style guide currently suggest handling this? How well will this work with existing OOJS themes?
The horizontal bars create an effect called visual banding.
- What is 'visual banding' in this context?
Colors used are not accessible according to WCAG guidelines
- All content text colours are AAA-conformant, with the exception of links. Link colours require high contrast with the primary text colour to be immediately identifiable, or their colours become meaningless as well. Do we have any skins currently that do this properly that you would recommend using as an example?
Larger base font size breaks the notification UI by making it extra large. The echo panel is huge. might be a bug
- T165924 - This happens in nearly all skins. I'm not even sure it's a bug (it appears intentional), but I've filed a task against it regardless.
Single column reading to focus on content
- This is the case at lower resolutions, but at high resolutions the extra space should be put to use. There is a difficult trade-off, here, however, as to how. The point of MediaWiki is editing and becoming involved in the community, as much as it is reading, and to de-emphasise one for the sake of the other harms both. We need a balance, essentially - make the content easily read without distraction, but make important tools and spaces easily discoverable, to all classes of users.
- We do need more research into what actions and links are useful for what users, which will also depend much on what their intent on the project is, what project they're even on, etc. Do we have anything cohesive on this that's more recent than the Usability Initiative?
Use WMF color palette for accessibility, brand, and consistency
- Agreed, but where is the current one documented? Timeless was loosely based on the WMF colours of the time, with adjustments made for improved contrast and usability, but there has been a fair amount of change in the interim.
Hidden sidebar with access from sticky header
Also, more generally:
- How severe do you consider the issues raised (and which are specifically issues)?
- Should any of this be considered a blocker for initial deployment as a non-default skin?
- Do we have conventions regarding what the hard requirements are surrounding what is acceptable, versus the guidelines as to what would be considered ideal (the must-haves, compared to the nice-to-haves)?
Lacking any response I'm just going to close this. The new tasks were all filed, so thanks for the input!
Duplicate site branding is redundant
Note, this was handled perfectly by one aspect in the Winter prototype framework - It used the normal logo, and as we scrolled down the page and the wordmark part of the logo scrolled into the fixed-header, the wordmark part stopped scrolling and became part of the fixed-header.
Go to 47 seconds in this video, to see it in action.
Sadly the prototype isn't online anymore, but perhaps you can fire up a test instance using the code? (it looks like style/winter.css is involved (the #logo & #logo.stuck classes) but I don't know what else.)
I guess I could help a little here. BTW, everything I state here are just my guesses and opinions. Just to avoid any possible mis-interpretation, I'm not kicking in on behalf of @Nirzar
@Nirzar's trying to tell that he's not sure of the end-users of this design.
Sidebar is a critical space. Value of the real estate could be evaluated more seriously
- Are you recommending some other sidebar usage besides the site navigation (such as for the ToC or page tools), or is the issue here more that the sidebar is making the content too narrow, especially at mid-lower resolutions? (T165945)
It seems to be the latter (sidebar is making the content too narrow). I guess he expects something like the mock found in the 13th page of the review (It looks better to me too)
The horizontal bars create an effect called visual banding.
- What is 'visual banding' in this context?
I guess it's something related to http://greatshroudofturinfaq.com/Science/Cloth/banding.html for webpages
Single column reading to focus on content
- This is the case at lower resolutions, but at high resolutions the extra space should be put to use. There is a difficult trade-off, here, however, as to how. The point of MediaWiki is editing and becoming involved in the community, as much as it is reading, and to de-emphasise one for the sake of the other harms both. We need a balance, essentially - make the content easily read without distraction, but make important tools and spaces easily discoverable, to all classes of users.
That seems to be a valid point.
Use WMF color palette for accessibility, brand, and consistency
- Agreed, but where is the current one documented? Timeless was loosely based on the WMF colours of the time, with adjustments made for improved contrast and usability, but there has been a fair amount of change in the interim.
I guess it's the one found at https://wikimedia.github.io/WikimediaUI-Style-Guide/
- Do we have conventions regarding what the hard requirements are surrounding what is acceptable, versus the guidelines as to what would be considered ideal (the must-haves, compared to the nice-to-haves)?
I guess the style guide covers this too.
@Nirzar's trying to tell that he's not sure of the end-users of this design.
Should have been a little clear here, the following should be added to it.
i.e., he's not sure if the design is targets readers, editors (or) any other audience.
Reopening because there's a bunch of new stuff on this and I don't have time to deal with it all right now.
Hello
I am a French contributor who is at the origin of the consensus on the integration of Timeless within Wikipédia Fr. The community is rather favorable to its integration but several problems remain, in particular on the graphic elements of Skin.
Indeed, we wonder if the side bar to the right she is really useful with all the place which she takes? To delete this side bar to the right and to merge its contents with that of the left would not allow to win in ergonomics? Furthermore, the space at present assigned to the center for an article is not it not too low for an article Wikipedia?
I hope that you can take the measures of graphic modifications in consequences!
An idea to better use the right side band : https://lut.im/nqAcrtQDB0/0k9u687OmaedDiPy.png
We would gain in ergonomics and usefulness. What do you think ?
This bug is directly mentioned in this Community Wishlist Survey proposal; see also this similar proposal which does not mention Timeless.
@Menthe I fully agree; the right sidebar isn't going anywhere at high-resolution because there's just no good reason not to use that space (and it's already collapsed into the left at lower ones so the content doesn't get too squished). And moving the infobox into it is an excellent idea currently blocked by the fact that infoboxes are just content and it's hard to make a skin handle specific content, BUT that is definitely a very important use case for actually making that into an extension so we can do that. Apparently there's an RfC and stuff already, but I don't remember where.
Also note that it may be possible to move the infobox with a gadget or something regardless. We should totally look into that.
One quick design question where I'm unsure if it's worth it opening up a seperate task for: Is there a specific reason why the main content window stops getting wider at 100 em? It creates useless whitespace that could be used more effectively.
Readability. The optimum line width is somewhere in the range of 50-80 characters (source goes to 75 but I've seen 80 in the context of programming). 100em probably allows for pictures and infoboxes and other side-content.
For ultra-wide resolutions, it might be interesting to see if we can do a 4 or 5 column skin where all of the columns with our working tools travel with you as you scroll down the article. But I suspect that Isarra has enough grief trying to get our current 1-3 column layout to work. :D
I feel like either demon or TheDJ put together a prototype, but that may just have been fiddling with a different skin and Capiunto.
Yes, https://en.wikipedia.org/wiki/User:TheDJ/responsiveContent - I really like this gadget (except for the 1900+ breakpoint, which I've overridden with a browser-script using Stylish).
Sidenote: I had similar concerns with maximum-width restrictions, until I got a widescreen monitor when suddenly it all made sense. (I.e. when a browser window gets over 1500px wide, the very long text lines become very awkward to read.) I do agree the resulting whitespace could be used more effectively; personally I dream of possibly putting our footnotes there (in Wikipedias) to make them more visible and useful, but that's a complicated and probably long-term set of possibilities.
Should this be still opened? Skin is deployed (probably) but design review is not completed? Really?