My comments inline and purple. Thanks for the feedback!

On Mon, May 20, 2013 at 11:17 AM, Jared Zimmerman <jared.zimmerman@wikimedia.org> wrote:
 
I think this design direction is good, still not 100% sold on the multi-column, but need to investigate more. 

Yay! If we don't go multicolumn, we need *some* kind of tablet layout; I'm not sure if keeping everything fullscreen on a tablet makes sense in the upload list view. :)
 
* Is this generally good? Should we continue to pursue this design?
Jared — 
 
yes, a few notes, right now there is a gap between images which is medium grey, would like to see this in black, and gone all together as options

Hmm, you should see no gap at present (except during initial loading before the layout is complete)... sometimes I see a 1px black gap. (Note that a couple of the images here actually have tiny borders of their own, such as the maps, but there's not much we can do about that.) Looks like there's also a slight glitch that shows through gray background instead of black if you view on an iPhone or other small-screen device (it also doesn't handle the rotation properly when viewed on an actual device, I'll try and fix that.)

* This mosaic layout attempts to put chronologically adjacent items near each other across the columns, but things don't always scan in order because there aren't even rows that cut across the columns. If this is too confusing, we could switch to a Google Image Search style mosaic for tablet view, where we have even rows instead of columns. This would be inconsistent with the phone view, then.
Jared — 
 
Gotta play with this more on tablet to have an informed view
 

Excellent, let me know if it's worth pursuing; the column algo needs some work before being used. :)
 

* Any feedback on the detail page? Should everything be overlaid or should there be a drawer, or a swipe, or?
 
Jared — 
 I
actually like the overlay more than i thought i would, however the blue links are nearly impossible to read, couple design notes here

Naturally yes, links will need a legible color!

I've got a couple general issues with the overlay though:
* When we run out of room on the screen, how should we deal with scrolling? Keep the image still, scroll it evenly with the foreground, or have it scroll more slowly than the FG (parallax effect)?
* How can people view the image fullscreen or zoomed in? Do we need another button to get to that? Or some way to dismiss/hide the overlay? (I like the idea of a drawer that can be opened/closed to show all the details, but I'm not sure on it.)
* How will this scale up to tablet view? (Possibly on tablet view we could have the overlay be a separate pane from a zoomable image view?)

  • is the image being blended to (overlaid on) a black background or a dark grey one? black my be better


Black.


  • Perhaps try an additional black to transparent gradient overlay from the top of the screen to further increase the readability of the text at the top 
  • For the text, at a 1px black hard drop shadow for further contrast and 
    read
    ability

*nod* That'll help!

  • Can we set the background image height to the screen height of the device, and anchor left, so the image overflow goes to the right? then set the background to fixed so it does not scroll with the page?
What to do on images taller than the screen aspect ratio? Show black, or crop to top? Or crop to center?


  • lack of left margin on text makes me uncomfortable, perhaps equal too or half the top margin

*nod*

Also some other ideas on info/controls to show:

* multilingual options for description -- descriptions can be stored in multiple languages; currently the mockup just fetches English. Giving people a chance to translate a description on the detail page would be a great microtask.
* article usage list with links to the pages... be warned, potentially long! (optional: filter to just articles, or include full list of meta and user pages?)
* (potential for the future) image editing tools
* (for the future) how to trigger audio/video playback for media items?
* we need to work out what the "use this photo in an article" feature does; if we don't want to build a full thing that actually inserts things into pages, we need to at least have a documentation page to link to.
* should we expose file metadata? (basic things like type/size, complex things like EXIF contents table)
* how should we expose GPS data? an inline map, or a trigger to bring up the info? How do we make the same interface work for editing/adding coordinates?

-- brion