Hi all,
I wanted to share a short video that illustrates some ideas for the user
experience improvement of the Translate extension.
The video is available at http://youtu.be/xKfaLyJE4ow?hd=1 (links to
different language-specific versions of the prototypes are available at the
video description)
Arun and I are organizing usability testing sessions these weeks. Anybody
can volunteer for participation in the usability tests at
http://goo.gl/E5dvO
The only requirement is to speak more than one language, but no previous
experience with translation is required.
Feel free to provide any comment on the prototype, or join the testing
sessions.
Pau
--
Pau Giner
Interaction Designer
Wikimedia Foundation
Hi,
I'm new to the list, and the mediawiki world. If this would be
better directed elsewhere, let me know.
I recently came across a skin for Mediawiki called Erudite[1], which
is based on a Wordpress theme of the same name[2].
I updated it to the work well with the current Mediawiki version,
fix bugs, and try and ensure everything was general enough that it
should work on any wiki with any extensions. As I say, I'm new to
mediawiki, so my ideas on the best ways of doing things come largely
from a blog post[3], the mediawiki wiki, and delving into
mediawiki's code for things I wasn't sure about. It's possible I
didn't follow best practises in some places, but I certainly tried
to.
I set up a new wiki demoing the skin (editing and creating accounts
is enabled; try it out,) here:
https://www.dur.ac.uk/nick.white/erudite-demo/mediawiki-current/
And the code is all here:
https://www.dur.ac.uk/nick.white/eruditeskin-0.9.4-r1.tar.bz2
If anybody interested could take a look, and give me feedback, that
would be wonderful.
I'd also ideally love the skin to be taken as one of the standard
skins that is distributed with mediawiki. I think it's very
attractive, and quite different to the other mediawiki themes I
found, so could be a good fit. Might that be possible? How would I
go about pushing that forward?
Thanks, and I look forward to hearing back from folks.
Nick White
1: http://www.unifiedrepublicofstars.com/reference/The_Unified_Republic_of_Sta…
2: http://wordpress.org/extend/themes/the-erudite
3: http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/
Pretty nice user script for the pre-Visual Editor era (and a problem
we'll have to solve in VE land as well), developed by a Hebrew
Wikipedia contributor:
https://en.wikipedia.org/wiki/Wikipedia:VPT#Template_Parameter_Wizard
It gives you an autocomplete search box for templates to add in the
edit window, renders the template key/value parameters as a form, and
apparently has a feature for parameter help/documentation as well. JS
code here.
https://en.wikipedia.org/wiki/User:%D7%A7%D7%99%D7%A4%D7%95%D7%93%D7%A0%D7%…
Something similar has been around in de.wp for a while as well, but at
least for plain vanilla template insertion, this one looks a bit
cleaner and simpler.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hey,
Heads up that it is a possibility that Trevor's Drafts extension may be
enabled after it is reviewed. I wanted to bring this to the attention of
the design team just in case it hasn't been mentioned, because it currently
adds a button to the editing interface. If anyone wants to have input on
this, now is the time to speak up.
As I understand it, this is different than the drafts idea that has been
discussed for article creation. Rather than a namespace where pages could
be moved in and out, this is instead drafts at the more granular level of
individual edits. Drafts are put in to a log, but are individually owned.
Docs:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=37992
* https://www.mediawiki.org/wiki/Extension:Drafts
*
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…
--
Steven Walling
https://wikimediafoundation.org/
Inspired by the discussions of the design team meetings, I have been
playing around with a few ideas for a simple navigation model for the
mobile that can extend the feature set of tools and options available to
users. It struck me that the article lead, some images and infobox data can
give a very good idea of a topic that is alien to the reader and such a
compact view on the mobile screen has a lot of value.
It got me thinking of the possibility of decomposing any wiki page into
multiple 'views' or layer that can alter the way one views the same page by
selectively rearranging and hiding the content. Possible page layers could
be:
A) Overview: Condensed view of the article optimized for the small touch
screen. It can also contain an index of topics covered that can act as
navigation aid to jump to a section in the Article layer
B) Article: The whole article, just like what you see in the current mobile
site
C) Gallery: Thumbnails of pictures, videos from the article. Could also
fetch related content from other wikimedia projects
D) Category: Allows you to jump to related topics if you are interested in
the subject.
E) Discussion: The talk page to discuss
The search and other page functions including language selections go into a
menubar that floats above the article. It would work like the menubar in
Google Now which Pau had demoed. When you scroll down its hidden, as you
scroll up, the menu pops up again, which means that all the functions
including search can be accessed from any part of the page. This also saves
screen space when you are reading and scrolling down, giving you a full
page view of the article with no distractions.
You can see a visual overview of this here:
http://upload.wikimedia.org/wikipedia/commons/f/fe/Wikimedia_mobile_layer_n…
Just an idea, more discussion with the design team pending.
--
Arun Ganesh
(planemad) <http://en.wikipedia.org/wiki/User:Planemad>
<http://j.mp/ArunGanesh>
I'm interested in getting a few interested people together to talk about
possible solutions for viewing diffs (including previewing changes) and
handling edit conflicts for VisualEditor.
We don't need to do anything formal really - if you are particularly
interested in getting involved let me know. If there are a few of us I will
throw a short brainstorming session together and we can go from there.
Just to throw something out there to give you a feel for what little we
have considered in this area: it is possible to utilize the granular
history data we capture for undo/redo purposes to support playback. This
would give the user a time-slider that takes the document from one state to
another, and a play button to animate between these states. This is usually
considered to be a "cool" idea, but we don't know that it's practical or
respectful enough of people's privacy.
I think this is an exciting area of VisualEditor with few restrictions and
almost no existing ideas or plans, which makes it possible for us to come
up with radical solutions and make them a reality.
- Trevor
Hi,
Continuing yesterday's theme of deciding about fonts for projects in
many languages, I wrote a page about the desired first step in that
direction:
https://www.mediawiki.org/wiki/Internationalization/Styling_and_typography
The rest of the Localization team supports me on that.
TL;DR: Before writing a big new movement-wide style guide we must
understand and document the different content and UI elements that
need styling in different languages and communities and only after
that start to bikeshed about particular fonts, weights etc.
Comments about that page are welcome.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Oliver Keyes said:
> Like, if I save a draft, cool. Except it doesn't reappear when I open the
> same page's editing window again.
When I open a page for which I made a draft of a new version,
it shows the list of existing drafts on top of the edit window.
If I click in the link provided, the page is reloaded with my draft inside the
edit box and I can continue updating it before publishing it.
Maybe it was just a bug when you tested?
Best regards,
Helder
On Thu, Sep 13, 2012 at 8:31 AM, Dario Taraborelli <
dtaraborelli(a)wikimedia.org> wrote:
> that's fantastic, is there any plan to support some basic markup/HTML
> parsing in the message - or is it not within the scope of this type of
> notifications?
I asked about this on wikitech. Daniel Friesen's answer:
mw.notify accepts DOM nodes and jQuery objects. So you can add in whatever
> html you want by parsing it into dom. mw.notify also accepts mw.Message
> objects so you can use `mw.notify(mw.message( 'foo' ) );` and it'll be
> parsed.
http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063189.html
--
Steven Walling
https://wikimediafoundation.org/
