Hi,
I wondered where to raise this and decided to do it here.
The message that asks for to write the edit summary in VisualEditor is
"Describe what you changed".
In the source editor it's just "Summary" in the core. In the English
Wikipedia, however, it's modified to "[[Help:Edit summary|Edit summary]]
(Briefly describe the changes you have made)".
The VisualEditor is used a lot by new editors (it's an impression, but I'm
pretty sure that the data will say the same). The idea of the edit summary
is to help the people who patrol recent changes or read the article
history. When new editors, who aren't so familiar with Wikipedia's edit
summary culture, are asked to "Describe what you changed", they may answer:
"the year when he was born". This is a correct answer as far as the editor
is concerned, but it's not so helpful in the context of recent changes.
I don't know about other languages, but this actually happens quite a lot
in the Hebrew Wikipedia, and some patrollers are complaining about it. (In
grammatical terms, the summary is written as a direct object: "Describe
what you changed" -> (I changed) "the year".)
Now I could change this to something clearer in the translation to this
particular language, but I like to be thorough when it comes to UI
messages, so I'd like to ask the pros here: How would you design the edit
summary box? The requirements I can think of are:
1. Encourage the user to actually write the edit summary. People not
writing summaries at all is a bigger problem than writing them not clearly
as I wrote above.
2. Encourage to write it in a way that would be useful to the people who
will read them in Recent Changes and in reviewing previous article versions.
3. Possibly give the users tips about how to write them well, but without
too much additional text.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
In the alpha mode of mobile we show a number inside the talk icon that
shows how many open talk topics there are on a page.
For example here:
On the San Francisco [1] page you see a 7. If you click it there are 7
topics / sections.
The code has been stagnating for some time, which is a real shame in
my opinion as it surfaces the talk page and discussions more. It works
by generating a number of sections on each save and storing them in a
page property to avoid performance implications.
I personally find it very intriguing when I see a high discussion
count on what seems like a non-controversial topic. e.g. Tofu has 37
open topics and makes me curious to click on it and read what people
have been discussing around it [2]
It's hard to measure the impact of the talk bubble when it is
displayed like this. I'd be interested to do some sort of A/B test
around it to see whether more people visit the talk page when the
number is shown - I'm not sure if Growth has any plans to do this.
Also I wonder if this is something Flow is thinking about.
Either way can we make a decision and either kill this code, or bring
it into beta mode?
[1] https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=alpha
[2] https://en.m.wikipedia.org/wiki/Tofu?mobileaction=alpha
getting a conversation count via flow's API will be much easier, but a
conversion of all talk pages to flow is still some time off, it would be
good to have a working way to do this on non-flow enabled talk pages as
well.
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
On Fri, May 23, 2014 at 10:33 AM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
> I have a storng conviction that if a feature had been bitrotting in alpha
> for a year without anyone even remebering about it yet alone caring about
> promoting it - it should be put to death. It resurfaced for me yesterday
> when I discovered that it's taking about a half of page_props table on
> enwiki which is an atrocitous amount of rows. I vote for promoting or
> removing it, keeping it in alpha is counter-productive. Considering that we
> have the Flow team to work on alk pages, I think that making this hack in
> MobileFrontend makes no sense so it shoud be removed.
>
>
> On Fri, May 23, 2014 at 9:07 AM, Jared Zimmerman <jzimmerman(a)wikimedia.org
> > wrote:
>
>> Displaying the discussion count in a design were investigating with
>> winter as well.
>>
>> Sent while mobile
>>
>> > On May 23, 2014, at 7:37 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
>> >
>>
>> > Then people would avoid starting a talk page when the number is 0. This
>> is, in my view, a bad thing.
>> This is a valid assumption and one we could test. A zero might even
>> prompt new discussions. We'll never know unless we explore it. I'm
>> just curious if there are any plans to test this and other similar
>> hypotheses.
>>
>> > This number would have to be generated by MediaWiki or Flow, but surely
>> not by MobileFrontEnd. As I said, MobileFrontEnd is only a skin.
>>
>> Not true. MobileFrontend has a few more bits of code that make it a
>> little more than a skin - e.g. special pages like Special:Nearby. It
>> currently records this number via a hook and is agnostic to Flow and
>> MediaWiki (although this code could easily be added to MediaWiki core
>> to be standardised)
>>
>> _______________________________________________
>> Design mailing list
>> Design(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/design
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
>
Hi Gilles,
I'll add some details about Agora: Some of the Agora classes are already
available as part of mediawiki.ui (such as buttons and button groups we
discussed for Media Viewer), and progress details for upcoming UI
components are available in this Trello board:
https://trello.com/b/EXtVTJxJ/mediawiki-ui
I don't know the technical details on why OOUI components such as buttons
are not using those classes, or which are the plans for doing so, but I
would love the current duplication to be solved for the benefit of
consistency and time.
Pau
On Thu, May 8, 2014 at 5:19 PM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
> Towards the end of developing features in Media Viewer, Pau asked us to
> correct a lot of the layout that was provided by the OOUI defaults. In fact
> I know there are still some elements that aren't styled the way Pau wants
> them to be, that we couldn't improve due to lack of time.
>
> I think I recall that this happened because OOUI doesn't implement Agora
> styles yet, which I understand to be the standard look as defined by the
> Design team. Is that correct? Or were the styling issues specific to Pau's
> design for Media Viewer?
>
> Since we're embarking on Upload Wizard work, the fact that we will use
> OOUI for it or not will soon be debated, and I'd like to clarify if we're
> likely to have to do that sort of patching on top of existing CSS again in
> order to comply to unified styling.
>
> If there is a plan to make OOUI CSS comply to the unified styling, what's
> the status of that? Is anyone actively working on it?
> https://www.mediawiki.org/wiki/UX_standardization seems to list it as a
> TODO, but there's no timeline nor references about who's taking on that
> task.
>
> _______________________________________________
> Multimedia mailing list
> Multimedia(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/multimedia
>
>
--
Pau Giner
Interaction Designer
Wikimedia Foundation
Hi everyone,
For curious, I wanted to share a quick update on the typography refresh.
The following four recent pieces of news that should be of interest...
1). The French Wikipedia community closed their vote on most aspects of the
new design (color, size, new headers, etc.) and it was very much in favor
of keeping the new design in all aspects.[a]
2). Spanish Wikipedians also closed their vote, which was more of a simple
yes/no on whether to revert. This was also in favor of keeping the new
design.[b]
3). Jon Robson has put up a patch to allow LESS styles to be set
per-language.[c] This means that many local site hacks, like Japanese
Wikipedia removing the serif headers or Farsi Wikipedia having to set
completely different Farsi-friendly fonts, will potentially no longer be
necessary. Review and testing is needed!
4). For some time now MediaWiki.org and the test replica of English
Wikipedia (en.wikipedia.beta.wmflabs.org) have been using a new proposed
body font stack by Erwin Dokter. This puts Nimbus Sans L first, and
restores the other body font settings like Helvetica Neue for Mac users,
Arial for all Windows users etc. Please try it out, especially if you're on
Windows or Linux. We'd like to put this in Vector/core at some point, if we
can make sure it works.
Thanks!
a.
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Prise_de_d%C3%A9cision/Afficha…
b.
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_la_actualizac…
c. https://gerrit.wikimedia.org/r/#/c/125760/
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
On Apr 29, 2014 3:43 AM, "Steven Walling" <swalling(a)wikimedia.org> wrote:
>
> FYI, if you're interested in continuing to talk about this and related
> issues, I strongly encourage Wikitech subscribers to join the Design list.
>
> ---------- Forwarded message ----------
> From: Steven Walling <swalling(a)wikimedia.org>
> Date: Mon, Apr 28, 2014 at 6:42 PM
> Subject: Typography refresh, now that dust has settled
> To: "A list for the design team." <design(a)lists.wikimedia.org>
>
>
> Hi everyone,
>
> For curious, I wanted to share a quick update on the typography refresh.
> The following four recent pieces of news that should be of interest...
>
> 1). The French Wikipedia community closed their vote on most aspects of
the
> new design (color, size, new headers, etc.) and it was very much in favor
> of keeping the new design in all aspects.[a]
>
> 2). Spanish Wikipedians also closed their vote, which was more of a
simple
> yes/no on whether to revert. This was also in favor of keeping the new
> design.[b]
>
> 3). Jon Robson has put up a patch to allow LESS styles to be set
> per-language.[c] This means that many local site hacks, like Japanese
> Wikipedia removing the serif headers or Farsi Wikipedia having to set
> completely different Farsi-friendly fonts, will potentially no longer be
> necessary. Review and testing is needed!
>
> 4). For some time now MediaWiki.org and the test replica of English
> Wikipedia (en.wikipedia.beta.wmflabs.org) have been using a new proposed
> body font stack by Erwin Dokter. This puts Nimbus Sans L first, and
> restores the other body font settings like Helvetica Neue for Mac users,
> Arial for all Windows users etc. Please try it out, especially if you're
on
> Windows or Linux. We'd like to put this in Vector/core at some point, if
we
> can make sure it works.
>
> Thanks!
>
> a.
>
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Prise_de_d%C3%A9cision/Afficha…
> b.
>
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_la_actualizac…
> c. https://gerrit.wikimedia.org/r/#/c/125760/
>
> --
> Steven Walling,
> Product Manager
> https://wikimediafoundation.org/
Is there at this time any interest for a test tool for fonts where users
can rate the qualities if a font we are looking for? I posed the same
question on wikitech before the dust settled, but that might have been too
soon.
--Martijn
>
>
>
> --
> Steven Walling,
> Product Manager
> https://wikimediafoundation.org/
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have uploaded a new version of the Winter prototype, version 0.5.
You may play with it here: http://unicorn.wmflabs.org/winter/
And give feedback here: https://www.mediawiki.org/wiki/Talk:Winter
After a significant battery of tests, several changes have been made (and will be going into test this coming week).
Most notable:
* Personal tools section no longer modifies itself upon scroll and remains fully expanded.
* In-header table of contents now appears to the left of the search box. It has been further expanded to include page-context links. The visual design of the menu requires work.
* Moved Language links into the page context ribbon area.
- Hovering over the affordance will show some languages to better enable discovery
- Clicking will open the language list. This could be the ULS; could be something else. But a pulldown list isn't working.
-This is for testing discoverability.
* Moved the watchlist star out of the context ribbon and right next to the article title.
* Some context-ribbon button labels are now automatically updating
- Discussions counts the sections in the talk page and changes accordingling (e.g., "35 Discussions") (We're aware that there are possible caching issues with live implementation)
- The history link now shows the last updated time in human-readable format.
A new experimental thing:
* Added new toggle, "Hidden Sidebar". This hides all sidebar links until hover over the logo.
- Toggle off or on from the sidebar.
- It needs a ''lot'' of work, especially around the "non-scrolled" visual state. This is possibly a throw-away experiment.
There are various other minor changes; full changelist can be found here: https://www.mediawiki.org/wiki/Winter#Version_0.5.2C_April_20.2C_2014
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate