[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?
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.
2) Indicating to the user what needs to be done
As a user, I've found the indicators where my help is needed not entirely obvious.
* 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.
* 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.
4) Analytics
Do we have any tracking at all for actions/errors within the app? It would be nice to rig up at least basic tracking for API errors and other issues during upload, so we know if lots of users are trying and failing for some reason (e.g. aborting at the login step, experiencing connection issues). Ori from the E3 team might be able to help rig something up.
- - -
I think issue 2) could be a potential major factor that could frustrate users. But this is just my feedback, so do with it what you will.
That's it. I've encountered a couple bugs but want to spend a bit more time in BZ to ensure I'm not reporting known stuff. The app overall is coming together nicely and it's very slick (I especially like the aggregation of monument counts at the lower zoom levels, the "Use my current location" feature, and the integration of links to Wikipedia).
Congrats on the work so far and looking forward to launch.
Cheers, Erik
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.
- 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?
- 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.
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.
- 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?
- 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
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_M... )
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:
- 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.
- 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.
A story exists for this and will likely be fixed.
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.
- 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?
- 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
On Mon, Aug 20, 2012 at 5:53 PM, Philip Chang pchang@wikimedia.org wrote:
Erik, thanks for the great feedback. Further to Jon's comments:
- Brion, any idea if and why Cordova uses .jpeg instead of .jpg?
The final filename should be whatever we provide to MediaWiki's upload API; I can't think how it would come from Cordova. It looks like it's being added by MediaWiki, actually -- we're sending a filename without an extension.
08-21 10:56:30.784: D/FileTransfer(9443): fileName: Second and Howard Streets District (taken on 21Aug2012 10hrs56mins22secs)
Perhaps adding a '.jpg' extension would eliminate the auto-added one?
-- brion
Lets add a card so that one of us can fix it.
--tomasz
On Tue, Aug 21, 2012 at 10:58 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Mon, Aug 20, 2012 at 5:53 PM, Philip Chang pchang@wikimedia.org wrote:
Erik, thanks for the great feedback. Further to Jon's comments:
- Brion, any idea if and why Cordova uses .jpeg instead of .jpg?
The final filename should be whatever we provide to MediaWiki's upload API; I can't think how it would come from Cordova. It looks like it's being added by MediaWiki, actually -- we're sending a filename without an extension.
08-21 10:56:30.784: D/FileTransfer(9443): fileName: Second and Howard Streets District (taken on 21Aug2012 10hrs56mins22secs)
Perhaps adding a '.jpg' extension would eliminate the auto-added one?
-- brion
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Tue, Aug 21, 2012 at 11:00 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Lets add a card so that one of us can fix it.
This seems to work: https://github.com/wikimedia/WLMMobile/pull/149
-- brion
woot!
--tomasz
On Tue, Aug 21, 2012 at 11:04 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Tue, Aug 21, 2012 at 11:00 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Lets add a card so that one of us can fix it.
This seems to work: https://github.com/wikimedia/WLMMobile/pull/149
-- brion
To focus on the filename
Op 21-8-2012 19:58, Brion Vibber schreef:
On Mon, Aug 20, 2012 at 5:53 PM, Philip Chang <pchang@wikimedia.org mailto:pchang@wikimedia.org> wrote:
Erik, thanks for the great feedback. Further to Jon's comments: 1) Brion, any idea if and why Cordova uses .jpeg instead of .jpg?The final filename should be whatever we provide to MediaWiki's upload API; I can't think how it would come from Cordova. It looks like it's being added by MediaWiki, actually -- we're sending a filename without an extension.
08-21 10:56:30.784: D/FileTransfer(9443): fileName: Second and Howard Streets District (taken on 21Aug2012 10hrs56mins22secs)
Perhaps adding a '.jpg' extension would eliminate the auto-added one?
The filename should be clear and unique. Some things you can hash into the filename: * Name * Username * Date * Monument id * Timestamp taken
You want to trim name if it exceeds a certain length. Inluding the id and the username makes sure that you'll only collide with yourself. Timestamp in iso format is probably a bit cleaner (YYYY-MM-DD HH:mm).
Maarten
El 21/08/12 21:00, Maarten Dammers escribió:
To focus on the filename
Op 21-8-2012 19:58, Brion Vibber schreef:
The final filename should be whatever we provide to MediaWiki's upload API; I can't think how it would come from Cordova. It looks like it's being added by MediaWiki, actually -- we're sending a filename without an extension.
08-21 10:56:30.784: D/FileTransfer(9443): fileName: Second and Howard Streets District (taken on 21Aug2012 10hrs56mins22secs)
Perhaps adding a '.jpg' extension would eliminate the auto-added one?
The filename should be clear and unique. Some things you can hash into the filename:
- Name
- Username
- Date
- Monument id
- Timestamp taken
You want to trim name if it exceeds a certain length. Inluding the id and the username makes sure that you'll only collide with yourself. Timestamp in iso format is probably a bit cleaner (YYYY-MM-DD HH:mm).
Maarten
ISO format does seem clear. Date gives much uniqueness, but pollutes the filename. I'd prefer if when uploading the filename, we could suggest a pattern and mediawiki gave us a unique alternative filename if needed.
For instance sending: action=upload&filename=St._Andrew's_Church.jpg&filenamepattern=St. %20Andrew's%20Church_-_%25d.jpg&comment=...
and receiving: {"upload":{"result":"Warning","warnings":{"exists":"St._Andrew's_Church.jpg"},"available": "St._Andrew's_Church-5.jpg, "filekey":...}
Yes, it would be great if Mediawiki gave us a unique alternative filename - but we are out of time. Let's keep these thoughts for future enhancements.
Perhaps the timestamp down to minutes is sufficient to ensure uniqueness for now, though one Commons admin pointed out that a timestamp is quite unusual in a filename.
Phil
On Tue, Aug 21, 2012 at 1:03 PM, Platonides platonides@gmail.com wrote:
El 21/08/12 21:00, Maarten Dammers escribió:
To focus on the filename
Op 21-8-2012 19:58, Brion Vibber schreef:
The final filename should be whatever we provide to MediaWiki's upload API; I can't think how it would come from Cordova. It looks like it's being added by MediaWiki, actually -- we're sending a filename without an extension.
08-21 10:56:30.784: D/FileTransfer(9443): fileName: Second and Howard Streets District (taken on 21Aug2012 10hrs56mins22secs)
Perhaps adding a '.jpg' extension would eliminate the auto-added one?
The filename should be clear and unique. Some things you can hash into the filename:
- Name
- Username
- Date
- Monument id
- Timestamp taken
You want to trim name if it exceeds a certain length. Inluding the id and the username makes sure that you'll only collide with yourself. Timestamp in iso format is probably a bit cleaner (YYYY-MM-DD HH:mm).
Maarten
ISO format does seem clear. Date gives much uniqueness, but pollutes the filename. I'd prefer if when uploading the filename, we could suggest a pattern and mediawiki gave us a unique alternative filename if needed.
For instance sending: action=upload&filename=St._Andrew's_Church.jpg&filenamepattern=St. %20Andrew's%20Church_-_%25d.jpg&comment=...
and receiving:
{"upload":{"result":"Warning","warnings":{"exists":"St._Andrew's_Church.jpg"},"available": "St._Andrew's_Church-5.jpg, "filekey":...}
Wiki Loves Monuments mailing list WikiLovesMonuments@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikilovesmonuments http://www.wikilovesmonuments.org