Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
talked about the future of skins. Hopefully this mail summarises what
we talked about and what we agreed on. Feel free to add anything, or
ask any questions in the likely event that I've misinterpreted
something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it
currently is for developers to create a skin. The skin class involves
too many functions and does more than a skin should do e.g. manage
classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list
generator to generate things like a list of links to user tools. The
widgets will be agnostic to how they are rendered - some may use
templates, some may not.
We identified the new skin system will have two long term goals:
1) We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css
file.
2) Should be possible for us in future to re-render an entire page via
JavaScript and using the modern history push state re-render any page
via the API. (Whether we'd want to do this is another consideration
but we would like to have an architecture that is powerful enough to
support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and
has resulted in MobileFrontend rewriting it. We decided to target this
as it is a simple enough example that it doesn't need a template. It's
small and contained enough that we hope this will allow us to share
ideas and codify a lot of those. Trevor is hoping to begin working on
this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the
templating RFC [1] can get resolved however we are getting to a point
that we need one as soon as possible and do not want to be blocked by
the outcome of this RFC, especially given a mustache based templating
language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Just an update on VE editing since we pushed it to stable for tablet users
(as an opt-in secondary editor on all projects) yesterday:
Since yesterday, we're getting about 0.2% of total mobile edits across all
projects coming from VE, and about 2% of unique mobile editors having made
at least 1 successful VE edit. So the volume is, as expected, pretty low –
which is good because it gives us lots of breathing room to fix bugs and
improve features before we make VE any more prominent of an editing
experience :)
For fun, here's a breakdown of which projects those unique editors were on:
Project # of unique editors making at least one successful VE edit
enwiki 42
eswiki 5
frwiki 4
itwiki 3
svwiki 2
cswiki 2
nlwiki 2
cawiki 1
jawiki 1
thwiki 1
dewiki 1
ukwiki 1 <-- this was me :)
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Hi Designers,
Is there any reason we shouldn't put a search icon next to the "search"
text box in the app? (see image)
The reason I ask is:
- We've received more than one complaint on OTRS saying that the Search
field is not discoverable (because it doesn't look like a normal text box).
- Every other app that implements any kind of "search" functionality has an
icon, so it's universally recognizable.
-Dmitry
device-2014-08-29-123320.png
<https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1V0pLNjh0VGI5cjA…>
Hi everyone,
Yesterday, Katherine, Tomasz and I met with Joe Castorena from Google’s
Android Play Partnerships team. I’ve split up the most relevant information
into a few separate emails, to keep the discussion on each separate point
focussed.
Tomasz put forward the idea of using the Wikipedia app as a code tutorial.
Have you ever been on the Android help pages online and seen code snippets?
Tomasz suggested that since our app is totally open source, they could
actually use living examples from the Wikipedia app on those pages if they
wanted. It’d be good PR and branding for them to use the Wikipedia app as
an example, and it would expose our code base to a much larger group of
people, and specifically those people would be developers!
This idea is obviously in its infancy, but I think we should definitely try
to push forward on this. Many thanks to Tomasz for suggesting this.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
*tl;dr: *
The Mobile Web team has decided to hide the uploads features (upload & add
to article + upload from left nav) on the mobile site until we have the
time/resources to rebuild them into a more productive contribution stream.
*Background:*
Before wikitext or VE editing, the mobile web team built an
upload-to-Commons pipeline as the first proof-of-concept of mobile
contribution. When we first launched the two upload features (upload and
add to article + upload to Commons via the left nav) ~2 years ago, we saw a
high ratio of these images being deleted (because they were copyright
violations, test images, selfies, etc.). Since then, we've continued to
make incremental improvements to address these issues: we added interactive
tutorials and instruction screens, and also gradually increased the
permission levels required to see these features (from everyone –>
logged-in-only –> autoconfirmed only –> 10+ edits).
However, despite all these changes, the ratio of kept to deleted uploads
has not changed significantly; though the absolute number of uploads per
month has gone down,[1] 70-80% of these files still get deleted.[2]
This is both a crappy experience for the end-user and a major headache for
the team – in addition to the pure engineering effort of continuing to
adjust the parameters of the feature, every incremental change to the
workflow requires a browser test rewrite, analysis time to figure out if
the improvements have actually made a difference, and lengthy
back-and-forth communication with a very unhappy set of Commons admins on
Bugzilla. And none of the changes to date seemed to have made much of a
difference.
In trying to address these issues, we've shifted from focusing on the new
user persona to the power user... but we're not explicitly revisiting the
interactions, messaging, or feature set, because we don't have the
bandwidth to make larger changes. I.e., despite the fact that the feature
is now not even being shown to brand-new users, we still show a tutorial
targeted at people who've never contributed before. I think we've reached
diminishing marginal returns on incremental improvements at this point. If
we want uploads to succeed, we need to start from scratch: decide who the
persona we want to target is and then build the set of features that this
user is going to need.
But rethinking how to instruct newbies (since tutorials don't seem to work)
or coming up with a whole new workflow aimed at experienced users isn't
something the team can take on at this point. It requires dedicated product
and design attention and quite a bit of engineering work, none of which we
have the resources for.
Since our focus for the year is new active editors and uploads are not part
of our annual targets, I recommended to the team that we hide the mobile
web uploading features for now and revisit them either later this year or
next fiscal year. The team agreed to this at today's planning meeting, and
we'll be making this change in the coming days.
I know it's not a great feeling when the software we create isn't a rousing
success, but I think it's really important to be upfront (with ourselves as
much as with the community) when we see that a feature just isn't doing
what we want it to do. Lila has been talking a lot lately about how it
seems like we've been trying to do! all! the things! in WMF engineering –
which comes at the cost of fragmenting our attention and making it hard to
really excel at any one of those things. I think she's totally right, and
I'd like to see our team lead by example and strive for more focus and
rigor in terms of what we work on and how :)
As always, if you have questions/concerns, feel free to voice them here.
I'll probably communicate this more broadly sometime early next week.
1. http://mobile-reportcard.wmflabs.org/graphs/unique-uploaders
2. http://mobile-reportcard.wmflabs.org/graphs/deleted-uploads
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Hi everyone,
Dmitry, Monte, James, Vibha and I just met to discuss where to go with
syntax highlighting in the apps.
For a variety of technical reasons, implementing VisualEditor in the apps
is a gigantic undertaking. The Mobile Apps team left wondering whether
there are lower-hanging fruit that we can run with in the meantime. So
we're looking at syntax highlighting for wikitext to make it easier for
users to understand.
Dmitry has a working prototype (example screenshot
<https://trello-attachments.s3.amazonaws.com/52607de6737250777a000201/538f52…>).
On discussing this prototype, we were wary that while multi-coloured
highlighting makes a lot of sense for programmers it may not make sense for
newer users who aren't programmers, and may actually have the opposite of
intended effect of making wikitext *more *scary. Oops!
The way we're going to proceed is by changing the colour of all the
highlighting to grey. That way, the actual content in the wikitext is
brought to the foreground. The exception will be wikilinks; the text will
be black, but the brackets will be grey. Hopefully this will help users
make the association between the wikitext and the reader experience more
apparent. We need to choose the right colour such that the text doesn't
look disabled and disincline people from touching it if they want to, but
we can do that!
Since this is a side-project and potentially could make the experience a
lot worse if we do it wrong, this is just going to be pushed to the
Wikipedia Beta app on Android, and we'll analyse the data. We are *only*
going to push this to production if the data strongly supports our
hypothesis (i.e. the bounce rate on the edit screen is significantly
reduced). If the data does not support this, or is inconclusive, we'll look
at other ways to test this hypothesis.
Special thanks to James for offering his editing domain knowledge to us for
this meeting. :-)
Let me know if there any questions!
Thanks,
Dan
*tl;dr: EVERYTHING GREY*
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
On 28 August 2014 11:22, Max <max(a)koehler-kn.de> wrote:
> You're welcome. Do you guys have a grunt workflow set up? I'd love to help
> out.
>
Yes, here for OOjs UI
<http://git.wikimedia.org/blob/oojs%2Fui.git/HEAD/Gruntfile.js> – we'd
definitely welcome suggestions and patches. :-)
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
On 27 August 2014 12:14, Max <max(a)koehler-kn.de> wrote:
> There's a grunt task called grunticon that does #2.
> https://github.com/filamentgroup/grunticon
Max,
That's a pretty awesome find; thank you!
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hi everyone,
On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s
Android Play Partnerships team. I’ve split up the most relevant information
into a few separate emails, to keep the discussion on each separate point
focussed.
Joe mentioned something that Google offers its partners, called a UX
review. He said that he could get the build passed to the Android
engineering team at Google, and in short they’d critique every aspect of
the user experience. The result would be a long document (on the order of
20 pages) where the Android team at Google would make recommendations about
how we could improve the UX of the app. He said that this process is
entirely voluntary, so we could take or leave the feedback as we see fit.
He did suggest, however, that doing something like this is going to
massively increase the way that we’re perceived by Google, and would
increase the possibility of getting featured as a “Best App 2014” or “Best
Designed App”. Basically, we’d be seen as a shining example of what Android
could do.
Given that we can take and leave the feedback as we see fit, I think we
should definitely do this. Once we have the feedback, we can figure out
where the individual items of feedback sit in our priorities. I'm really
excited to get some feedback from the people who literally wrote the book
on Android design.
Thoughts?
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Now that the left-hand navigation menu has expanded to six links, I'm
having a little trouble quickly scanning it to find the item I need.
Previously it was no issue, since there were only three or four links. Have
we considered adding icons?
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
