Maybe a very dumm follow up question from my side: would it be possible to include the app download (at least, maybe also use?) in the piwik stats? (it's explained here:  https://commons.wikimedia.org/wiki/File:Piwik_documentation_for_Wiki_Loves_Monuments.pdf  )

Not that I don't trust your tracking, but it would be really neat to have all tracking for WLM sites in one place :) Makes processing easier afterwards. 

Best,
Lodewijk

2012/8/21 Philip Chang <pchang@wikimedia.org>
Erik, thanks for the great feedback. Further to Jon's comments:

1) Brion, any idea if and why Cordova uses .jpeg instead of .jpg?

Unique name - originally we were going to include username and date/hr/min (no seconds) - would that be acceptable? Derrick Coatzee commented in the bug Jon referenced and roughly he is saying similar things to you. 

I believe it is more work to assign a unique number and we are rapidly running out of time, with plenty of work still to do.

2) The first point about including the icon in the monument detail screen is a great one and possibly could be considered. The second point is something we should do, and a similar existing story for the map view may not make it, but I will create a story for this particular enhancement.

3) A story exists for this and will likely be fixed.

4) Ori is more than welcome to help! This is a good thought and we are trying to get just basic tracking, but if something can be done easily we should go for it.

Phil


On Mon, Aug 20, 2012 at 5:10 PM, Jon Robson <jdlrobson@gmail.com> wrote:
Thanks Erik - my comments are inline!

On Mon, Aug 20, 2012 at 4:47 PM, Erik Moeller <erik@wikimedia.org> wrote:
[Cross-posting to WLM mailing list]


Hi Phil & mobile team,

a few questions/comments from playing with the WLM app.

1) Filenames of uploaded files

Right now files appear to follow the following pattern:

[Name of monument] (taken on [timestamp in DDMMMYYYY HHhrsMMminsSSsecs]).jpeg

First question: Is there a reason we're using ".jpeg" instead of the
more common ".jpg" extension?

This is a good question and I'm not sure why this is happening. It's potentially a default of the Cordova library we use. Someone more informed might be able to shed light on this.
 
Second question: What are the motivations for the full timestamp in
the pattern? Is it primarily uniqueness? If so I would suggest
(re-)considering other approaches to achieve uniqueness (e.g.
obtaining a unique suffix like 001, 002). This pattern seems pretty
verbose; I do see some files with date-stamps in the name on Commons
(and it's encouraged per
https://commons.wikimedia.org/wiki/Commons:File_naming ), but very few
that have the full timestamp.
 
This is primarily about trying to get a good balance between uniqueness and being human readable.  There was a confusing ticket about this - https://bugzilla.wikimedia.org/show_bug.cgi?id=38285 which I closed today due to the fact it wasn't actionable - I welcome (https://bugzilla.wikimedia.org/show_bug.cgi?id=38285#c8) suggestions on how we could improve the names.


* The red place-marks vs. gray place-marks iconography - are we
explaining this anywhere in the UI? I was ultimately able to infer it,
but it might be nice to have this explained e.g. by having the icon
repeated in the detail view with a "Existing image" or "Photograph
needed" label.


Yes I agree we could reinforce this better... 
 
* In list view, the gray boxes are gradually replaced with photographs
where they exist. Ultimately I end up with some remaining gray boxes,
which I can infer are cases where a photo is missing. But it seems
like we want to have a different icon in list view for "We don't have
a photo at all" vs. "We're still checking whether we have a photo".
Perhaps a spinner while it's checking?


 
3) Small UX confusion

* I have been repeatedly confused by the proximity of the "Back" arrow
to the "Map view / List view" selector. They look like they're a
single widget. I would suggest moving the "Map view" vs. "List view"
indicator to the right, detaching it from the "Back" arrow.


We've had similar comments from Matthew Roth  so agree this should be thought about.


_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l




--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810


_______________________________________________
Wiki Loves Monuments mailing list
WikiLovesMonuments@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments
http://www.wikilovesmonuments.org