Sumanah poked me in IRC today to ask when we are scheduling time to
give KnockOff / TAssembly a spin in MobileFrontend.
Gabriel Wicke is looking for feedback...
I ran an audit of the existing browser tests for MobileFrontend as
part of a mobile team spike [1]. You can see the results here:
https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014
Our coverage is actually not too bad, but there is definitely room
from improvement. That said I have a big concern is around the
organisation of the tests and how they are written and what is written
- many of the tests could do with being reworded and a lot of them
should probably actually be deleted. There is a lot of code
duplication.
When auditing I found tests scattered all over the place. This
suggests that we could benefit from reorganising the file structure to
be more logical, in particular features that relate to special pages
should have their own folder (this is particularly useful for
clarifying what tests the watch star and what tests the actual
watchlist page - Zeljko / Chris is it possible to have subfolders in
the features directory that contain features?).
I would also suggest the following actions for improving our test coverage:
* Add tests for error handling on login / account creation
* Add tests for this page has issues
* Improve tests for key editing and upload workflows
* Add tests for Language variant support
* Add tests for full text search support
* Improve the existing watch star tests so they actually check the end result
* Add test to check the user can close the left navigation menu
* Add tests for logout
* Add tests for reference overlay
* Add tests for toggling
* Add tests for Nearby in skins other than Minerva (mobile skin)
* Address hygiene issues on
https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014
[1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1687
Actually cc'ing mobile-l this time instead of just saying it ...
On Wed, Jun 11, 2014 at 11:56 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote:
> CC'ing mobile-l to get this archived and for others to know that its coming.
>
> Dan, given that we can't easily ship a beta within the iTunes store
> what will the mechanics of the release look like?
>
> --tomasz
>
> On Wed, Jun 11, 2014 at 11:48 AM, Dan Garry <dgarry(a)wikimedia.org> wrote:
>> Hey guys,
>>
>> Vibha, Moiz, Monte, Brion and I just met to get a date together for the
>> release of the iOS app. We arrived at 7th July (3.5 weeks from now, the end
>> of the next sprint). Here's how.
>>
>> I asked the engineers and designers what they felt the dependencies were. We
>> identified:
>>
>> Edit workflow refinements (current sprint)
>> Onboarding (first time UX) (current sprint)
>> TOC refinement (next sprint)
>> Styling refinement (next sprint)
>> General bug fixes and cleanup (next sprint)
>>
>> The first three are hard requirements; if they're not in, then we will delay
>> the release. The last two are softer requirements, particularly since we can
>> update the app CSS without pushing out a new release.
>>
>> It was a careful negotiation! Monte originally wanted an extra sprint of
>> slack, but I managed to arrive at the two sprint number by assuring him that
>> if something game-breaking came up then we'd delay the release. I think the
>> user feedback is really important, so I think it's worth setting the goal to
>> be sooner rather than later.
>>
>> The cool thing is, this means the iOS release will only be two weeks after
>> the Android one. Woohoo!
>>
>> We're all happy with this date. I'm meeting with Katherine tomorrow to
>> discuss what the best communications strategy for this is.
>>
>> Thanks,
>> Dan
>>
>> --
>> Dan Garry
>> Associate Product Manager for Platform and Mobile Apps
>> Wikimedia Foundation
This is essentially an app that gives you a mobile-friendly interface for
tracking Recent Changes, Watchlist Changes, and Contributions on Wikipedia
projects.
See https://meta.wikimedia.org/wiki/Grants:IEG/WikiTrack for more
information.
Ryan Kaldari
I tried VE on the two working Android tablets that we have: Samsung Galaxy
Tab 10.1 (Android 4.0.4) and Nexus 7 (Android 4.4.2). Samsung uses Android
Browser and VE performs slowly and buggy there. Link inspector works better
than on iOS but there are other small bugs like problems with some icons
not being scaled properly or occasional rendering issues. Nexus 7 with
Kitkat has Chrome as its default browser and everything works fine there, I
would even say it works better than iPads.
Kaldari is doing more research regarding which tablets should be redirected
to mobile.
--
Juliusz
Hi everyone,
This edit concerns discussions that Vibha, Yuvi and I have had about the
abuse filter today. As it is part of the edit workflow, these discussions
took place to unblock the card. The abuse filter works just fine on both
platforms, but the design leaves a bit to be desired. For those of us who
are unfamiliar with the abuse filter, I've prepared a short write-up in
this Google Doc
<https://docs.google.com/a/wikimedia.org/document/d/1VIIQhkribQuJa-6ugm3XM5d…>
that
explains what the abuse filter is.
Here's the outcome of the discussions:
1) The abuse filter stuff has been broken off of the edit workflow cards
and placed onto its own card here. This unblocks the iOS card, and then the
Android card is only blocked by waiting for the relevant design.
2) The interaction of the designs on iOS is good. The design restyling
that's in the edit workflow changes card can take place, but the
functionality can remain the same. This goes for Android too.
Let me know if you've got any questions!
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
Hi everyone,
Our final sprint before the Android release has come! Woohoo!
There are a few blocked cards in Trello:
1. Edit workflow changes: This card is awaiting the Android design. I've
followed up with Vibha and Moiz and the design should be available by the
end of the day today.
2. Re-do buttons for progressive styling: I think Monte and Moiz had
some discussions about this last week but I'm not sure what came of it.
Monte, can you update the card?
3. TOC bar: Blocked on us making a decision about whether the TOC button
should have a spinner or not. Did we reach a decision about this?
4. More menu: Blocked on me making a decision about what should go in
the menu. I will do that today and note on the card.
Thanks everyone!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
Hi all,
Monte, Yuvi, Vibha, Moiz, Jared, Howie and I met today to talk about
refining the edit workflow on the apps.
The statement of the problem is that user testing has shown that in the
current workflow the preview step is not useful; people are not recognising
that it is a preview, not recognising the edit summary box is there, and
accidentally abandoning their edits because they think they've saved
already. This is related to the fact that there are too many steps in the
edit workflow. In particular, the call to action to "sign in and save" or
"save anonymously" was basically ignored by everyone who tested the app.
Our macro-level goal for the app is to get people to edit. Whether that's
by signing in and saving or by saving anonymously isn't as important to us
as *actually getting them to edit.*
Our course of action is therefore multi-faceted:
1. For the MVP we're removing the call to action to sign in and save.
Since people are ignoring it, it's not really serving any purpose in the
current workflow except to bloat it. This drastically reduces the number of
steps in the process.
2. We're flipping the edit summary box and preview around, so that when
you make a change and click next you see the edit summary on top. This
makes it clearer that your edit hasn't saved, it emphasises the canned edit
summaries that users responded positively to in the testing, and makes the
preview step feel more optional. We're also going to restyle this page
slightly to make it clearer.
The workflow for editing is now press edit > make change > press next >
enter edit summary (and optionally view preview) > save. This makes the
workflow much easier to use, and a lot clearer.
I realise that my description above isn't great; Vibha and Moiz are going
to create a mockup for it, and I'll share that on this list once we've got
it.
Thanks everyone!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
This afternoon Dan and I reviewed how tags from the android app are captured in the change_tag and tag_summary tables.
(1) We noticed that the “mobile app edit” tag is applied to recentchanges events that are not edits, but new account registrations:
SELECT * FROM enwiki.change_tag WHERE ct_rev_id IS NULL AND ct_tag = "mobile app edit";
ct_rc_id ct_log_id ct_rev_id ct_tag ct_params
661123291 56899294 NULL mobile app edit NULL
661123407 56899301 NULL mobile app edit NULL
661124928 56899375 NULL mobile app edit NULL
661127933 56899610 NULL mobile app edit NULL
661128644 56899685 NULL mobile app edit NULL
661131626 56899908 NULL mobile app edit NULL
661133278 56899998 NULL mobile app edit NULL
661134572 56900072 NULL mobile app edit NULL
661140653 56900620 NULL mobile app edit NULL
661155198 56901558 NULL mobile app edit NULL
661155799 56901593 NULL mobile app edit NULL
661156983 56901659 NULL mobile app edit NULL
AFAIK this is unusual behavior for tags and will create artifacts in tagged revisions unless people are aware that all these registration-related events always need to be excluded (it’s also confusing because the name of the tag explicitly refers to an edit). As suggested earlier [1], we should not track the source of account registrations via MediaWiki tags but via the ServerSideAccountCreation log.
(2) edits made on apps should be stored with two separate tags: “mobile edit” and “mobile app edit”. The tags are correctly stored in the change_tag table with 2 records for each revisions, e.g.
SELECT * FROM enwiki.change_tag WHERE ct_rc_id = 661110028;
ct_rc_id ct_log_id ct_rev_id ct_tag ct_params
661110028 NULL 611585155 mobile app edit NULL
661110028 NULL 611585155 mobile edit NULL
but when the tags are combined in the tag_summary table, the “mobile app edit” tag is lost:
SELECT * FROM enwiki.tag_summary WHERE ts_rc_id = 661110028;
ts_rc_id ts_log_id ts_rev_id ts_tags
661110028 NULL 611585155 mobile edit
This should not be the case, the 2 tags should be concatenated in the ts_tags field, see for example this desktop revision with 2 tags:
SELECT * FROM enwiki.change_tag WHERE ct_rc_id = 578489188;
ct_rc_id ct_log_id ct_rev_id ct_tag ct_params
578489188 NULL 555564321 gettingstarted edit NULL
578489188 NULL 555564321 visualeditor NULL
SELECT * FROM enwiki.tag_summary WHERE ts_rc_id = 578489188;
ts_rc_id ts_log_id ts_rev_id ts_tags
578489188 NULL 555564321 gettingstarted edit,visualeditor
I believe that neither (1) nor (2) is intended behavior for apps. Can you guys confirm and if so, can we fix this?
Dario
[1] http://lists.wikimedia.org/pipermail/mobile-l/2014-May/007150.html