I have run two sets of user tests with Winter to determine the usability of in-header page action icons and whether or not users can easily recognize their personal tools menu and the search box, especially after scrolling in the page. The results are not encouraging for the in-header icons.
Two tests were run because the first test had some possible errors and confusions. The second test (Winter Harness Two Electric Boogaloo) had some modifications to the flow to avoid people getting lost on user talk pages (this was the result of the first version of Harness Two telling them to click on the Speech Bubble icon in the top right if they were lost - but they had scrolled to the top already). H2:EB corrected this by directing them to the context action ribbon.
* https://www.mediawiki.org/wiki/Winter#Harness_Two:_Winter
* https://www.mediawiki.org/wiki/Winter#Harness_Two:_Electric_Boogaloo
* Only *one* user out of ten correctly used the in-header page action icons. Further, his language indicated that he had some icon confusion: he thought that only a few icons were added, and that existing ones were moved (e.g., history and edit were new, but the watch list icon was still the same).
* Most users were unable to recognize the personal tools section as being "my stuff" unless their username was ''also'' included. Once the username was gone, it was invisible to them (with rare exceptions, and mostly by accident then).
* No users had trouble with the search box. At all.
* Most users ended up using the context action ribbon and ignored other navigation hints.
* The in-header TOC might as well be invisible.
* At this point, with 10 testers and a 10% success rate, I'd say that the benefits of putting page icons in the header are outweighed by the negatives of losing the username for discoverability.
Discussion here: https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rr0ke21yl3…
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi Everyone,
I would like to invite your feedback on [1] prototype of
Project-'UploadWizard:OSM embedding' [ user/password is mediawiki/mw ].
This project is about enhancing the image upload process for Wikimedia
Commons.The main goal of the OSM embedding project is to provide map
interface to the UploadWizard. We can not expect each and every uploader to
know exact location where image being uploaded was taken, or to use
location enabled camera/phone to take the image. With introduction of map
interface, uploader can easily choose location coordinates for uploaded
images.
Detailed project description can be found at [2].
Functioning of embedded map :
- On valid coordinates/location inputs widget first loads a static map
which on 'click' will initialize leaflet powered dynamic map
- Address search
- ' type' or 'importance' specific zoom for various kinds of locations
on address search
- .Dynamic updation of coordinate fields and location field on leaflet
map interaction and vice versa
Kindly give your suggestions for map widget- design as it needs to be
improved, also propose features and/or improvements in current features.
Please share your insights at [3].
[1]http://uploadwizard-osm.bitnamiapp.com/mediawiki/Special:UploadWizard
[2] https://www.mediawiki.org/wiki/UploadWizard_OSM_map_embedding
[3] https://www.mediawiki.org/wiki/Talk:UploadWizard_OSM_map_embedding
Best regards
Anu G Enchackal
Dear all,
I have noticed a page called Wikipedia:2014 main page redesign proposal in
Wikipedia, I want to confirm that the community really wants to have the
main page design changed. If the community really wants to change, I
suggest to use User:Gabrielchihonglee/Main_Page as the new design. How do
you guys think about that?
_______________________________________________
Gabriel Lee
Admin at beta and wy/zh
#PRAYFORMH370
The first battery of user tests have completed against the Winter prototype. I have included links to all of them at the main Winter page:
https://www.mediawiki.org/wiki/Winter#Harness_One:_Winter
All tests are annotated, but highlights are included in-line.
The primary take-aways are:
* No tester had difficulty recognizing the search bar.
* All testers quickly grasped the in-page context action ribbon.
* Several testers expressed surprise that Wikipedia had discussions, which lends even more credence to the idea that Vector tabs are effectively invisible.
* The "Cancel" button from the editor may need work.
* All testers found their way to the contributions page, even when faced with bugs/difficulties. They just did it in other routes.
I am very pleased with the results.
I’ve created a Flow discussion about this here:
https://www.mediawiki.org/w/index.php?title=Talk:Winter&topic_postId=rqjdm7…
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Glad to hear you were aware of the earlier work. I agree it is often easier
to reimplement something from scratch than finishing someone else work.
Regarding the static maps on initial load, I found this feature to be
unintuitive when I tried it. IMO, it would be better to just show a spinner
while the map is loading, rather than requiring an extra click to get to
the actual map.
The rest of the functionality seemed quite smooth and intuitive. Nice work!
Ryan Kaldari
On Wed, Mar 12, 2014 at 3:50 PM, Gergo Tisza <gtisza(a)wikimedia.org> wrote:
> On Wed, Mar 12, 2014 at 2:42 PM, Ryan Kaldari <rkaldari(a)wikimedia.org
> >wrote:
>
> > Ack, I wish I had known about this earlier. Most of these features had
> > already been implemented for UploadWizard, but the patches were never
> > polished enough to be merged:
> > https://gerrit.wikimedia.org/r/#/c/12352/
> > https://gerrit.wikimedia.org/r/#/c/12353/
> >
> > I would be good to at least compare against your implementation and see
> if
> > there are any ideas that would be useful to incorporate.
> >
>
> I looked at those some time ago, but reusing them didn't seem much less
> effort than reimplementing (also the OPW project had more ambitious goals
> like Nominatim integration and using static maps initially to speed up page
> load).
> I didn't compare visually (you used CloudMade tiles, Anu uses MapQuest),
> that would be worth doing.
>
> There is also a third OSM integration attempt,
> https://github.com/lukaszkostrzewa/wiki which has some additional
> server-side features which look interesting although probably overlap with
> MobileFrontend's Nearby.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Has it ever been specified why mw needs a font stack in the first place?
Sure, when specifying only the generic type of font, the fonts different
systems chose do look a bit different, but why is this a bad thing? From
what I understand, these fonts are usually the most readable ones for
the systems in question, hence why they are the defaults.
So why do we want to override this?
-I
Mobile is experimenting with showing a small banner at the top of the main
page that prompts logged in editors to help a page in need of new links:
https://en.m.wikipedia.org/wiki/Main_Page?mobileaction=beta
I think this is _great_ and started playing with it on the train with
nothing to do.
Two improvements need to be made though:
1) It's difficult to know what to link to. I wrap words which I feel should
be existing wiki pages but I pretty much have to guess or open a new window
to check those. Some kind of search interface or link validation
tool/corrector would be useful.
2) Since red links are turned off in the editor preview it can be tricky to
know whether I caused a typo or linked correctly if new to wiki text. This
is a bad first time user experience. Some kind of validation step or
feedback when I create red links in the editor itself would be useful. We
should at very least enable red links in the editor preview.
On a side note:
I really think we should give more priority to enabling new page creation
on enwiki to help those sort of experiences before continuing down this
path of encouraging new editors. People could start drafts, start pages
with photos. This seems like a really useful focus of time.
I had a chat with paper scrunching Moiz in person. To reiterate what I said
there - as stated in my first email "I wanted to discuss whether this is a
good idea?" To be clear I was never saying it was a bad idea. My original
mail was just curious to the motivating factors to why we are doing it and
what we are achieving and most specifically for me whether mobile web
should be experimenting with it too. We should definitely try this out and
see what happens.
Max has identified that this happens already on Russian Wikipedia and Amir
that this happens on Hebrew and Polish and I didn't know that. There is
also a widely used gadget. Those are interesting data points.
Steven has identified a problem you have with what summaries get canned.
This is now a shared problem.
This is why we discuss these things to understand them and end up building
the right and the best thing.
Please keep us up to date with designs. Maybe a volunteer might be
interested in knocking this up for mobile web..?
I'd love to see any other findings you've made.
To wrap this conversation up can you share the link to the relevant trello
card (I couldnt find it) or wherever is the best place to find your most up
to date designs for this so if a volunteer/future me wants to work on this
they can do so?
On 11 Mar 2014 06:43, "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il>
wrote:
2014-03-11 1:00 GMT+02:00 Max Semenik <maxsem.wiki(a)gmail.com>:
> On 11.03.2014, 1:32 Jon wrote:
> > 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?
> Russian Wikipedia was doing that for ages to everyone's satisfaction.
> The only problem is where to cram them in, but that's solvable.
Hebrew and Polish Wikipedias are doing it for ages, too, and probably some
other languages.
In fact, numerous people complained that VisualEditor breaks this feature.
Editors don't care whether it's a local custom gadget or something else -
for all they care, it's a feature and VE breaks it.
Anyway, it would be a lovely feature to productize and make available for
all languages, for both mobile and desktop interfaces. The code is
basically there - just take the gadget from one of the Wikipedias that
currently use it and package it as an extension.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
2014-03-11 1:00 GMT+02:00 Max Semenik <maxsem.wiki(a)gmail.com>:
> On 11.03.2014, 1:32 Jon wrote:
> > 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?
> Russian Wikipedia was doing that for ages to everyone's satisfaction.
> The only problem is where to cram them in, but that's solvable.
Hebrew and Polish Wikipedias are doing it for ages, too, and probably some
other languages.
In fact, numerous people complained that VisualEditor breaks this feature.
Editors don't care whether it's a local custom gadget or something else -
for all they care, it's a feature and VE breaks it.
Anyway, it would be a lovely feature to productize and make available for
all languages, for both mobile and desktop interfaces. The code is
basically there - just take the gadget from one of the Wikipedias that
currently use it and package it as an extension.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
http://designatwikipedia.tumblr.com/post/62048718932/thoughts-on-humanizing…
"With humanizing articles, we have two objectives:
-Creating awareness about the editors and their interests on Wikipedia.
-Promoting connections within the community using shared interests."
The post shares some ideas and mockups and notes, "While the details are
being refined, comments on the general direction towards contributions
or alternate ideas would be super appreciated."
(By the way, after this email, I'm unsubscribing from the design list as
I prep for my sabbatical - more info at
http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071542.html
. If you need to talk about Wikimedia technical community stuff or
communication before January, please consult Quim Gil, qgil at wikimedia
dot org, or Guillaume Paumier, gpaumier at wikimedia dot org. Thanks!
Looking forward to coming back in January.)
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation