Hey everyone,
Monte, Yuvi, Danny (PM for Flow) and I met today to discuss our way
forwards with discussions on apps.
The statement of the problem is that the apps currently don't surface
discussions at all; both article talk and user talk are not made apparent
to the user. This creates problems for power users and new users alike;
power users workflows are built around discussions so we serve them poorly,
and new users can't interact with anyone, which includes things like new
users being unable to read vandalism warnings.
Our solution needs to let people participate meaningfully in discussions,
both on article talk pages and also meta-discussions (user talk pages, etc.)
So the question is, do we do a styling pass on talk pages to make them
easier to use on the apps and surface those talk pages, or do we just wait
for Flow (for some definition of "wait")? We were leaning towards the
former, but wanted to make sure we'd considered all the variables before
proclaiming we had a solution.
We discussed. We felt that waiting for Flow introduces too many unknowns;
Flow will not be deployed to user talk pages for at least six months, which
is a long time to wait to get discussions implemented. Even then, it may be
even longer before we can reliably say "all discussions are on Flow". We
can't afford to wait that long to serve the need for discussions in the app.
*This email in a nutshell: Waiting for Flow is insufficient. We want to do
a styling pass on talk pages to make them usable on apps.*
Let me know if you have any questions!
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
---------- Forwarded message ----------
From: Deepak Gupta <deepak343(a)gmail.com>
Date: Thu, Jun 5, 2014 at 11:38 AM
Subject: I have an issue on Mediawiki with MobileFrontend installed
To: maxsem.wiki(a)gmail.com
Hi Maxsem,
I have an issue on Mediawiki with MobileFrontend installed.
I have set wgMFAnonymousEditing= true;
But when I edit any article on the wiki page with mobile version of the
skin, I am not able to save it. It says - "Error, edit not saved." However
if I am logged in, there are no errors.
But on the desktop version of the site, there are no errors.
Can you please help me?
Thanks,
Deepak
--
Best regards,
Max Semenik ([[User:MaxSem]])
Here's a quick link to a page Vibha and I started as a scratchpad for a
list of page styling issues we've identified in particular articles.
https://etherpad.wikimedia.org/p/App_Page_Styling
Wanted to share this as an initial touchpoint for surfacing some small
styling tweaks that may need to be made to MobileApp css files.
Hi all,
This is something I've been tinkering with for a bit:
https://www.dropbox.com/s/g9svwrlvf839z9f/device-2014-06-04-085320.png
IMHO, the Wiki markup syntax can be quite daunting for new editors, and
when editing articles with a lot of markup, the edit window can look like a
cacophony of symbols.
In lieu of a full-blown VE interface, I propose implementing a minimal form
of "syntax highlighting" that will at least guide new editors on the usage
of Wiki markup, and might even help experienced editors double-check what
they're adding without requiring a preview.
What does everyone think of this?
-Dmitry
There is a consistent failure on 2 tests in the Chrome build. Firefox
build not effected.
These tests both depend on the window size being >= 768px
1) Table of contents.Show table of contents on tablet
2) Toggling sections.Section open by default on tablet
When run locally against beta labs they pass for me. Is there any
known issues with cloudbees around browser window size manipulation?
It's the only thing I can think that might be causing this issue.
The step that might not be working as expected is:
Given(/^I am viewing the site in tablet mode$/) do
@browser.window.resize_to(768, 1024)
end
https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…
CC'ing the mailing list so that we can have this archived.
On Tue, Jun 3, 2014 at 12:50 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org>
wrote:
> Hi Vibha and Moiz,
>
> I think we should look at the icons a bit more for the full release. The
> icon we have for editSave is from the Android Icon Pack
> <https://developer.android.com/design/downloads/index.html>, which is
> great but the other icons we have are much thicker, like the one for ToC.
> So, for beta having consistency within the app is good enough, but
> eventually we should get closer to the platform icon style. The Iconography
> Guide for Android
> <http://developer.android.com/design/style/iconography.html> also calls
> for less opacity in the action bar icons.
>
> (1) Table of Contents icon: [seems very thick and fuzzy compared to the
> editSave from Android Icon Pack below. I think it has too much padding and
> by our code scaling it up to 48dp it becomes fuzzy. We should scale our
> fake action bar icons to just 32dp BTW.]
>
> [image: Inline image 1]
>
> (2) editSave from Android Icon Pack:
>
> [image: Inline image 4]
>
> (3) our editSave icon: [too much padding --> seems too small]
>
> [image: Inline image 3]
>
> Here is the latter with the rest of the screen:
>
>
>
>
> I also think that the *launcher icon* should either not have any rounded
> border at all. At least, we should use a different icon for the action bar,
> like shown here (using the same icon as in the search fragment: search_w):
>
>
>
> The Iconography Guide for Android
> <http://developer.android.com/design/style/iconography.html> states that
> the launcher icon should be a distinct silhouette. See also Android
> Design in Action: Football Apps + Launcher Icons
> <https://developers.google.com/live/shows/97567912>, you can skip to
> minute 22, when launcher icons are covered.
> Thank you,
> Bernd
>
Sounds great. Standing by.
Any changes for the action bar home icon? Right now the real action bar's
home icon (the W on the left) could look much better if it didn't have the
border around it. Do you mind if I'd switch to the search_w icon for the
real action bar home icon as well? (See the last image in my original
message.)
Thanks,
Bernd
On Tue, Jun 3, 2014 at 1:05 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote:
> Hi Bernd!
> Excellent points. All the inconsistencies will ironed out once we use all
> icons from Wikifont.
> While we reuse all the native interaction patterns on android, the
> iconongraphy will be wikifont.
> So this means we will not use default android icons. Where needed we can
> replicate the shapes in a heavier weight which is consistent with Wikifont.
>
> Currently,
> Previous/Back
> Next
> Share
> Save
> More
> are in the wikifont.
>
> I'm talking to yuvi right now to export these into the appropriate size
> folders for android
> I'll ping you as soon as that is done.
>
> Thanks
> Vibha
>
> ----
> Vibha Bamba
> Senior Designer | WMF Design
>
>
>
>
>
>
>
>
> On Tue, Jun 3, 2014 at 12:50 PM, Bernd Sitzmann <bsitzmann(a)wikimedia.org>
> wrote:
>
>> Hi Vibha and Moiz,
>>
>> I think we should look at the icons a bit more for the full release. The
>> icon we have for editSave is from the Android Icon Pack
>> <https://developer.android.com/design/downloads/index.html>, which is
>> great but the other icons we have are much thicker, like the one for ToC.
>> So, for beta having consistency within the app is good enough, but
>> eventually we should get closer to the platform icon style. The Iconography
>> Guide for Android
>> <http://developer.android.com/design/style/iconography.html> also calls
>> for less opacity in the action bar icons.
>>
>> (1) Table of Contents icon: [seems very thick and fuzzy compared to the
>> editSave from Android Icon Pack below. I think it has too much padding and
>> by our code scaling it up to 48dp it becomes fuzzy. We should scale our
>> fake action bar icons to just 32dp BTW.]
>>
>> [image: Inline image 1]
>>
>> (2) editSave from Android Icon Pack:
>>
>> [image: Inline image 4]
>>
>> (3) our editSave icon: [too much padding --> seems too small]
>>
>> [image: Inline image 3]
>>
>> Here is the latter with the rest of the screen:
>>
>>
>>
>>
>> I also think that the *launcher icon* should either not have any rounded
>> border at all. At least, we should use a different icon for the action bar,
>> like shown here (using the same icon as in the search fragment: search_w):
>>
>>
>>
>> The Iconography Guide for Android
>> <http://developer.android.com/design/style/iconography.html> states
>> that the launcher icon should be a distinct silhouette. See also Android
>> Design in Action: Football Apps + Launcher Icons
>> <https://developers.google.com/live/shows/97567912>, you can skip to
>> minute 22, when launcher icons are covered.
>> Thank you,
>> Bernd
>>
>
>
Hello all together!
Maybe someone can help me? :)
I have reinstalled my development system and so reinstalled MediaWiki and
MobileFrontend Development Environment. After i installed git, gerrit and so
on, i started to install tests. qunit and phpunit runs perfectly without
errors and works fine. But now comes a little problem. After the first test
commit, the script would install phpcodesniffer via composer, and there i
had two warnings/errors:
Skipped installation of bin dev-scripts/phpcs for package
squizlabs/php_codesniffer: file not found in package
Skipped installation of bin dev-scripts/phpcbf for package
squizlabs/php_codesniffer: file not found in package
Correctly the script except with message, that phpcodesniffer has to
installed (make phpcheck says all ok).
Now my question is: Am i to silly or somtehing else?
After i changed the line phplint.sh to the new location of phpcs
(vendor/squizlabs/php_codesniffer/scripts) the test works. But im unsure,
if im right to only change the line of the localtion of phpcs and all is
good. Can you ad hoc say anything to that? That would be extremly helpful
for me :)
You can contact me via this E-Mailadress, mobile-l and irc
(#wikimedia-mobile FlorianSW). Big thanks!
Kind regards
Florian
Freundliche Grüße
Florian
Hi everyone,
So as you know I did some user testing a few weeks ago. Here's the messages
I took home from it, and how I think we can address those. Most of these
have been covered in meetings and in our planning for the next sprint, but
I think it's still worth making explicit.
*1) The preview step, as it stands, is not useful. *A lot of new users
don't understand that they're being presented with a preview and think
instead that their edit is already saved. Meanwhile, experienced editors
are annoyed at not having the ability to choose when they preview like they
do on desktop. For our MVP we're moving towards taking preview out as a
discrete step, and also using text on buttons to make it clearer what
actions are happening.
*2) Searching and starting the edit workflow is really clear to people.* People
know exactly how to search, what was happening, and that hitting the pencil
let them edit the article. That's great.
*3) People don't notice the edit summary box.* This is probably a
sub-problem of finding the preview step confusing. When I pointed it out to
people, they happily started using it, so it's not that they can't be
bothered using the feature, it's just that they're not discovering it.
We're going to look into ways of making the edit summary box more
noticeable in combination with the work to resolve point 1.
*4) When people are pointed to the canned edit summaries dialogue on iOS,
they use it fluidly.* It was a big hit with people and they understood it
instantly. This was such a success that I think we should look at getting
it onto Android further down the line.
Like I said, we're working on most of this stuff already. This is mostly
just for posterity.
Thanks!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
