Derk-Jan (DJ) is a prolific contributor to our front-end stack -- a
veritable Tzadik Nistar[0] who goes around quietly fixing and improving
things. You may have met him at the architecture summit. He is currently
working on improvements to the CodeEditor extension, which provides an
alternative text editor for editing source code (like Lua modules, for
example), and has requested some help in creating icons for the toolbar.
See his post to wikitech-l for details:
http://www.gossamer-threads.com/lists/wiki/wikitech/444398
I'm writing to endorse his request and to encourage designers with a cycle
or two to spare to help out! :)
[0] https://en.wikipedia.org/wiki/Tzadikim_Nistarim
---
Ori Livneh
ori(a)wikimedia.org
hey everyone,
I just came across this cute little thing the folks on mozilla developer
network are doing: They include links to their history and edit pages in
the browser's context menu.
https://www.dropbox.com/s/7xctszwdjvtui79/Screenshot%202014-03-22%2015.35.3…
Thought I'd share this.
best, max
@awesomephant
fyi
---------- Forwarded message ----------
From: *Quim Gil* <qgil(a)wikimedia.org>
Date: Saturday, March 22, 2014
Subject: Three GSoC proposals about skins
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Let me draw your attention to three GSoC proposals trying to improve the
current situation with MediaWiki skins. They didn't come from our list of
featured projects,but they point to problems the community has
acknowledged, and so far they are responding well to feedback. Your
attention and help is welcome.
Sorted by date:
A modern, scalable and attractive skin for MediaWiki, by Jack Phoenix
https://www.mediawiki.org/wiki/User:Jack_Phoenix/A_modern,_scalable_and_att…
Isarra and Emufarmers are volunteering as mentors. All the basics seem to
be in place, more scrutiny is welcomed.
Separating skins from core MediaWiki, by Bartosz Dziewoński
https://www.mediawiki.org/wiki/User:Matma_Rex/Separating_skins_from_core_Me…
No mentors assigned yet, Jon Robson is volunteering. More than classical
mentors, this proposal needs explicit community consensus, and a clear
backing from MatmaRex's fellow Vector maintaners: Trevor Parscal, Roan
Kattouw, Timo Tijhof. In fact, one of these (or someone else with +2 amb
familiarity with skins) should be a co-mentor to offer a third pair of eyes
to the plans and the code reviews.
Frontend for Vector skin CSS customizations, by Ioannis Protonotarios
https://www.mediawiki.org/wiki/User:Protnet/Frontend_for_Vector_skin_CSS_cu…
No mentors assigned, and nobody is volunteering so far. The proposal is
receiving good feedback from known experts in that area. While the previous
two candidates are already maintainers in the areas they are proposing to
work, and while Ioannis provides details about his experience, he needs
mentors happy to evaluate him with microtasks and tough questions.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hey all,
I'd like some wider opinions, particularly from UX designers, on the
following issue: in MediaWiki's login form on desktop, there is a link to a
login help page. By default it links to "Help:Logging in", which exists on
most Wikimedia wikis but which is likely not existing in a brand new
MediaWiki installation.
I was comfortable including this link by default because I think it's
reasonable to ask wiki administrators to either create a login help page or
link to one they like. However, some people find this unacceptable, and
would prefer to link by default to the help page on MediaWiki.org.
I think this is not so bad, and there are drawbacks to both. However, I
think it's better to not link to a help page on a completely different
site. Users, especially casual non-technical users, won't understand what
"MediaWiki" is or why they were sent there instead of to a help page on
their wiki. This seems likely to confuse, and we should put more of the
burden on site admins to deal with the link as they see fit.
The relevant patch is https://gerrit.wikimedia.org/r/#/c/83220/ and the bug
to comment on is https://bugzilla.wikimedia.org/show_bug.cgi?id=53888 if
anyone can chime in.
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
Hello all,
I'm Tina Johnson. I'm planning to work on GSoC project: MassMessage page
input list improvements. My proposal is :MassMessage page input list
improvements<https://www.mediawiki.org/wiki/Extension:MassMessage/Input_List_Improvements>.
Kunal Mehta ( Legoktm ) has agreed to mentor me ( mostly the coding part ).
But I'm in need of a mentor who could help me with the UI design of the
improved extension.
Can anyone help me with this as I need two mentors to get started with my
project.
Regards,
Tina.
I have published the results of two additional tests on Winter. These were competing tests and I expected one to fail fairly strongly (and was not disappointed).
The first test was identical to the "Electric Boogaloo" test. However, the Winter interface had been modified thus:
* No page-context actions are loaded into the fixed header.
* The user tools section does not shrink/collapse (thus always showing the username).
This test was a fairly significant success. All testers completed all tasks.
Most users quickly pointed out that they knew they were "logged in" because of their username appearing in the corner and noted that they have a set of personal or profile tools there. More than one tester referred to this area as "their profile". No users had difficulty finding their contributions because of this.
With one exception, all users found the context action ribbon quickly. The one who did not later was observed using it with proficiency.
Many users unconsciously navigated with the context action ribbon afterwards.
The search box remains mostly discoverable. Several testers unconsciously used it in the sticky format without scrolling to the top.
No one used the table of contents in the header.
The second test was the polar opposite. For this test, the in page context actions (the ones below the article title) were removed. The page actions in the header were visible at all times, and the user tools menu did not collapse.
Most users encountered signficant icon confusion. In some cases, the confusion was enough to prevent them from accomplishing a task. In other cases, the confusion will obviously be problematic as cental editing themes are confused.
The discoverability of the user tools section, when the username is present, is very high and remains so.
The discoverability of the page action icons is almost non-existent. Several users expressed a desire for action labels. Many users failed to accomplish tasks that required these icons, or assumed they had achieved success when they did not. It is my belief that at least two testers assumed that the page action icons were just parts of their personal tools, and never looked there for page actions.
Over all tests, no one has ever used the in-header Table of Contents.
Test videos and more highlights available here:
https://www.mediawiki.org/wiki/Winter#Harness_Three:_Winter:_No_Header_Iconshttps://www.mediawiki.org/wiki/Winter#Harness_Four:_Winter:_Only_Header_Act…
Barring additional test desires, I'm going to collate all findings across all tests.
My current recommendations are:
* The in-header actions are confusing and should be removed.
* The user tools menu should not collapse as its discoverability significantly degrades when the user name is not present.
* The in-header table of contents has very low discoverability. No one has ever used it, and more than one tester has expressed confusion about it when it was found. We should remove it or explore alternatives.
* The search box remains highly discoverable, but it is my belief (backed by some tester statements) that the icon is a large part of this. Changing the text in the box reduces discoverability some but not enough that I would eliminate the behavior.
* A link to an article's talk page should be included in the in-page table of contents. Several users seem to want to go there.
Please discuss here: https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rr9fa8q2bb…
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
The app team showed a demo to the mobile web team today of the latest
editing experience for the new Wikipedia app that is being worked on.
The mobile app editing experience was very consistent with mobile web
which is a great thing, that said it had one significant difference -
canned edit summaries.
The interface showed various buttons that when clicked would populate
the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we
should be doing that at the start of the workflow in my opinion - tell
a new user what they can, give them a better idea using the article
issues templates.
If the goal is to make the users editing experience easier (which it
should be), personally I think it would be more useful to have an
autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people
can see what I'm talking about?
Hi!
According to the Deployments page on Wikitech, Typography Refresh is
scheduled to be enabled for all users of the Vector skin sometime next
week <https://wikitech.wikimedia.org/w/index.php?oldid=105227#Next_month>.
As I like my skin the way it is, I have two questions: (1) Can someone
from the Design team confirm that the deployment will actually happen
next week, and (2) if so, how can I opt-out of the change without having
to edit my own common.css (or vector.css) stylesheets?
I have very strong negative feelings towards Typography Refresh because
of the shade of grey it uses for article text and the way it changes
link color from blue to grey, which makes it very hard for me to read
the text due to my poor eyesight, and would therefore prefer not to have
to use it.
Tomasz
Dear all,
I plan to redesign it, I will tell you guys the plan and give you the
scratch a few days later. But I don't know how to apply the changes, so
hope some one may teach me.
_________________________________
Gabriel Lee
Admin on wy/zh and beta
17/3/2014
#PRAYFORMH370
