I went ahead and did a quick mockup for some modified JavaScript and CSS for image pages. Here's a live demo:
http://toolserver.org/~brion/mockups/mobile-imagepage/
This is using the current existing File: page markup and modifying it with CSS and JavaScript: * the extra data sections are hidden by default except for the image, so they don't get in the way * link bar at top is reformatted and links are used to show/hide each section instead of jumping around * the image itself is sized down to fit the screen, but using the same medium-resolution version that we started with
I also changed the viewport settings to allow zooming in, which we've been thinking about doing anyway.
Result is: * by default there's less clutter on screen * by default the image fits * auto-scales to fit when changing orientation * on high-resolution screens (iOS with Retina display, Android with 240dpi or 320dpi display) the picture appears much sharper * can zoom in for more detail with standard pinch-to-zoom
Confirmed that it works in at least iOS 5 Safari and Android 2.3.6 Browser, haven't tested all other things.
Checked in with Phil & Patrick -- we think this is a good direction to start with and should be easy to include in MobileFrontend extension (it's a conservative change that doesn't alter any HTML of the page itself, and just adds some CSS/JS that will be easy to keep and port in future).
Any comments, ideas? For instance the initial view could be made more 'image viewer'-y by centering things, removing some extra links or reformatting them, etc
-- brion
On Thu, Dec 8, 2011 at 4:57 PM, Brion Vibber bvibber@wikimedia.org wrote:
I went ahead and did a quick mockup for some modified JavaScript and CSS for image pages. Here's a live demo:
Awesome. Live demos are the best.
This is using the current existing File: page markup and modifying it with CSS and JavaScript:
- the extra data sections are hidden by default except for the image, so
they don't get in the way
Much nicer on a small screen.
- link bar at top is reformatted and links are used to show/hide each
section instead of jumping around
- the image itself is sized down to fit the screen, but using the same
medium-resolution version that we started with
Nice
I also changed the viewport settings to allow zooming in, which we've been thinking about doing anyway.
About time we did this.
Any comments, ideas? For instance the initial view could be made more 'image viewer'-y by centering things, removing some extra links or reformatting them, etc
Great start!
I'm going to take the long term view here. When a user taps an Image on Wikipedia I'm going bet that they want to see the image in whatever size is right for their phone. Scalable of course. Without much else. Were showing them way too much by default.
But we want to make the extra data available if a user asks for it. So why don't we surface it when a user taps on the image as a set of icons/text that floats at the top and the image description at the bottom. And a black background behind everything to make the image pop.
We could also get rid of the following but not limited to as they don't serve the needs of someone browsing an image description page on a mobile
* Different resolutions * IW links * Home, Random * Search * Full resolution link on every page
--tomasz
Great mock up! The only real annoyance I had looking at it was that at least on the iPhone the upload history table took up about 2 screens worth of horizontal space so you had to scroll over to read it.
More comments in line
On Dec 8, 2011, at 5:50 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Great start!
I'm going to take the long term view here. When a user taps an Image on Wikipedia I'm going bet that they want to see the image in whatever size is right for their phone. Scalable of course. Without much else. Were showing them way too much by default.
Agree!
But we want to make the extra data available if a user asks for it. So why don't we surface it when a user taps on the image as a set of icons/text that floats at the top and the image description at the bottom. And a black background behind everything to make the image pop.
I like the idea of the black background (almost lightbox style even if we don't use one) though I worry about it with dark images. Dark background/Dark images can be hard for me to see even on my lap or desktop but on my phone can be almost impossible. It would be awesome to have something detect how light/dark the image is but possibly too much?
I have my concerns about both icons and a 'click to surface' interface. I like icons from a clean layout point of view but they need to be almost completely universal or it becomes a problem quickly. Even on an American English page I can get confused about why a certain icon was used but on an international site it can become impossible to know what's what. This seems like it will be even harder in our environment (file history may work as a clock, description possibly as paper/pencil though that may look like edit too, no clue how we would do meta data).
Clicking to get the menu scares me mostly because I think it would be so hard to "randomly find" that it wouldn't get used when it should. I think we want to not only make sure they can get at the info but also make sure, without hurting their experience, that they know it's there. I think adjusting the background, eliminating a lot of the interface (like below) and keeping a nice bar like Brion's mockup could leave those choices easily accessible but lose the clutter that distracts from the file.
We could also get rid of the following but not limited to as they don't serve the needs of someone browsing an image description page on a mobile
- Different resolutions
- IW links
- Home, Random
- Search
- Full resolution link on every page
--tomasz
Agree with almost all of these. I could make an argument for home/random/search at top but I'm not sure it' a good. We just have an easy to find back button or X (especially if it's only an image) and they can tell how to return back. The clutter removal also gives us the ability to highlight the file and to the actual info attached to the file instead.
I like having full resolutions available but I think they are relatively low yield. Where they are now they're destructing without adding too much (though I did keep trying to click them... I knew it wouldn't work but for some reason they were addictive 'to make sure Brion didn't hide something here'). They are probably better served on the description page (under) or an other info page. I feel most people wanting them will probably look in those places to find it.
Also might I add: this working mockup rocks. Makes it so much easier to think about and visualize adaptions.
James
Sent from my iPhone... Sorry if it formats horrible.
Wow, awesome comments. It's good to see so much concern about UX.
Just wanted to clarify that I believe Brion included the current W menu elements just to make the mock-up complete. In most cases the menu would not be revealed in this image view.
Personally I like the different image resolutions because of these two use cases:
- the user wants to see details in the image that are not visible in the current resolution - the full resolution guarantees that you can see everything there is to see
- the user wants to send the image to someone else and the choices of resolution are handy (though if I am not mistaken this is not possible on iPhone)
But these are somewhat edge cases and putting them somewhere else may not be a bad idea.
Phil
On Fri, Dec 9, 2011 at 12:23 AM, James Alexander jalexander@wikimedia.orgwrote:
Great mock up! The only real annoyance I had looking at it was that at least on the iPhone the upload history table took up about 2 screens worth of horizontal space so you had to scroll over to read it.
More comments in line
On Dec 8, 2011, at 5:50 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Great start!
I'm going to take the long term view here. When a user taps an Image on Wikipedia I'm going bet that they want to see the image in whatever size is right for their phone. Scalable of course. Without much else. Were showing them way too much by default.
Agree!
But we want to make the extra data available if a user asks for it. So why don't we surface it when a user taps on the image as a set of icons/text that floats at the top and the image description at the bottom. And a black background behind everything to make the image pop.
I like the idea of the black background (almost lightbox style even if we don't use one) though I worry about it with dark images. Dark background/Dark images can be hard for me to see even on my lap or desktop but on my phone can be almost impossible. It would be awesome to have something detect how light/dark the image is but possibly too much?
I have my concerns about both icons and a 'click to surface' interface. I like icons from a clean layout point of view but they need to be almost completely universal or it becomes a problem quickly. Even on an American English page I can get confused about why a certain icon was used but on an international site it can become impossible to know what's what. This seems like it will be even harder in our environment (file history may work as a clock, description possibly as paper/pencil though that may look like edit too, no clue how we would do meta data).
Clicking to get the menu scares me mostly because I think it would be so hard to "randomly find" that it wouldn't get used when it should. I think we want to not only make sure they can get at the info but also make sure, without hurting their experience, that they know it's there. I think adjusting the background, eliminating a lot of the interface (like below) and keeping a nice bar like Brion's mockup could leave those choices easily accessible but lose the clutter that distracts from the file.
We could also get rid of the following but not limited to as they don't serve the needs of someone browsing an image description page on a mobile
- Different resolutions
- IW links
- Home, Random
- Search
- Full resolution link on every page
--tomasz
Agree with almost all of these. I could make an argument for home/random/search at top but I'm not sure it' a good. We just have an easy to find back button or X (especially if it's only an image) and they can tell how to return back. The clutter removal also gives us the ability to highlight the file and to the actual info attached to the file instead.
I like having full resolutions available but I think they are relatively low yield. Where they are now they're destructing without adding too much (though I did keep trying to click them... I knew it wouldn't work but for some reason they were addictive 'to make sure Brion didn't hide something here'). They are probably better served on the description page (under) or an other info page. I feel most people wanting them will probably look in those places to find it.
Also might I add: this working mockup rocks. Makes it so much easier to think about and visualize adaptions.
James
Sent from my iPhone... Sorry if it formats horrible.
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Dec 9, 2011 at 10:43 AM, Philip Chang pchang@wikimedia.org wrote:
Wow, awesome comments. It's good to see so much concern about UX.
Just wanted to clarify that I believe Brion included the current W menu elements just to make the mock-up complete. In most cases the menu would not be revealed in this image view.
Personally I like the different image resolutions because of these two use cases:
- the user wants to see details in the image that are not visible in the
current resolution - the full resolution guarantees that you can see everything there is to see
- the user wants to send the image to someone else and the choices of
resolution are handy (though if I am not mistaken this is not possible on iPhone)
But these are somewhat edge cases and putting them somewhere else may not be a bad idea.
I've gone ahead and committed this version with a couple additional tweaks:
* clickthrough on the image is disabled, so a tap on the image doesn't accidentally send you through to the full-res download. (There's still a link if you want that) * fix for when don't have reupload priv ;) * full-resolution link and description are shown with the image, but no longer on the other subpages
I'd probably recommend a bigger redesign of the file/image display page for desktop which will make improvements for mobile easier too, but we can do that in a bit. :)
This'll need testing on devices other than high-end smartphones; the JS is pretty straightforward but you never know about lower-end phones.
-- brion