[Cross posting to commons-l and design list]
Hi all,
Over the last couple days, I've been looking at making our <gallery> tag a lot more slick. Compared to other websites, our galleries look very "boxy" imo. This isn't that bad when it comes to icon/clip art type media, but for photos I feel we could really do better. So I've tried to make the galleries be more compact, with rows of images all the same height but different width, and the caption visible on hover. The only downside to this is the borders of the gallery become a little ragged, which mostly looks fine to me (Possibly could be dealt with with js. Would involve a bit of double loading the images though).
A demo speaks louder than words, hence:
* http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... with http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...) * http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A... with http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish ) * http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page
Additionally the wiki is open to editor (You need to register an account first), so please don't hesitate to experiment.
Anyhow, this is all still a work in progress, and I would really appreciate your feedback/criticism/hate mail/love letters/etc. -- Thanks, Bawolff
This is very pretty; thank you for your work. :-)
I won't touch on design issues (others are more qualified), but might we want to bring into MW core some of the extended gallery tag syntax that Wikia have developed for their wikis?[0] In particular, letting galleries become click-through slideshows, or page-width image reviewing slideshows ("sliders", in Wikia terminology) would be nice to add for some wikis.
[0] - http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wiki...
On 10 June 2013 17:36, bawolff bawolff+wn@gmail.com wrote:
[Cross posting to commons-l and design list]
Hi all,
Over the last couple days, I've been looking at making our <gallery> tag a lot more slick. Compared to other websites, our galleries look very "boxy" imo. This isn't that bad when it comes to icon/clip art type media, but for photos I feel we could really do better. So I've tried to make the galleries be more compact, with rows of images all the same height but different width, and the caption visible on hover. The only downside to this is the borders of the gallery become a little ragged, which mostly looks fine to me (Possibly could be dealt with with js. Would involve a bit of double loading the images though).
A demo speaks louder than words, hence:
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... with http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...)
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A... with http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish )
Additionally the wiki is open to editor (You need to register an account first), so please don't hesitate to experiment.
Anyhow, this is all still a work in progress, and I would really appreciate your feedback/criticism/hate mail/love letters/etc. -- Thanks, Bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Jun 10, 2013 at 5:36 PM, bawolff bawolff+wn@gmail.com wrote:
Over the last couple days, I've been looking at making our <gallery> tag a lot more slick. Compared to other websites, our galleries look very "boxy" imo. This isn't that bad when it comes to icon/clip art type media, but for photos I feel we could really do better. So I've tried to make the galleries be more compact, with rows of images all the same height but different width, and the caption visible on hover. The only downside to this is the borders of the gallery become a little ragged, which mostly looks fine to me (Possibly could be dealt with with js. Would involve a bit of double loading the images though).
I like the overall look, couple notes: * Think about tablet and mobile views -- galleries are even awfuller on mobile right now than on desktop. This means a) consider touchscreens and b) consider small screens. * I'm not sold on "show title on hover". Touchscreens don't do hover... * Ragged edges can be fixed by adjusting spacing or aspect ratio a little, like justifying text. This would look awesome. :) * We need to fix what happens when clicking the items -- should get a nice zoomed lightbox or something. This should be shared with non-gallery media however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy, but how can we show subcategories nicely? What about non-visual media? Can we display them better than we do now?
-- brion
Brian,
All and all I think this is a great improvement, I think the things that Brion points out are valid and would improve the design, with the gaps in spacing now it can look a little haphazard depending on the mix of images.
Being aware of mobile/touch UI and users is at the forefront of our minds in all of our design work and we'll need an answer for this case as well. Great work, and I look forward to seeing how it evolves.
Jared
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jun 12, 2013 at 7:22 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Mon, Jun 10, 2013 at 5:36 PM, bawolff bawolff+wn@gmail.com wrote:
Over the last couple days, I've been looking at making our <gallery> tag a lot more slick. Compared to other websites, our galleries look very "boxy" imo. This isn't that bad when it comes to icon/clip art type media, but for photos I feel we could really do better. So I've tried to make the galleries be more compact, with rows of images all the same height but different width, and the caption visible on hover. The only downside to this is the borders of the gallery become a little ragged, which mostly looks fine to me (Possibly could be dealt with with js. Would involve a bit of double loading the images though).
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller on
mobile right now than on desktop. This means a) consider touchscreens and b) consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a nice
zoomed lightbox or something. This should be shared with non-gallery media however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy, but how can we show subcategories nicely? What about non-visual media? Can we display them better than we do now?
-- brion
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller on
mobile right now than on desktop. This means a) consider touchscreens and b) consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a nice
zoomed lightbox or something. This should be shared with non-gallery media however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy, but how can we show subcategories nicely? What about non-visual media? Can we display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy, but how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it - May our Visual Designer is working on an information overlay for use in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days - Animation! I think this is a perfect opportunity to use some animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller on
mobile right now than on desktop. This means a) consider touchscreens
and b)
consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a
little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a
nice
zoomed lightbox or something. This should be shared with non-gallery
media
however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely? What about non-visual media? Can we display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
-- - Brian Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for use in
the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some animation,
we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller on
mobile right now than on desktop. This means a) consider touchscreens
and b)
consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a
little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a
nice
zoomed lightbox or something. This should be shared with non-gallery
media
however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely? What about non-visual media? Can
we
display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sun, Jul 7, 2013 at 10:09 PM, bawolff bawolff+wn@gmail.com wrote:
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for use in
the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some animation,
we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller on
mobile right now than on desktop. This means a) consider touchscreens
and b)
consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a
little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a
nice
zoomed lightbox or something. This should be shared with non-gallery
media
however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely? What about non-visual media? Can
we
display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively easy,
but
how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
Look and feel consistency is great; but I feel that the motivation for the dark overlay on mobile is driven by a lack of space. This lack of space does not exist on the desktop. We are an information provider; why are we advocating for hiding pertinent information about something if we have space to display it? Am I missing another constraint we've identified somewhere?
There's another problem with relying on mouseover... touch devices (which are a present and growing percentage of 'desktop' web devices) do not have a mouse to hover. What is our solution there if we go the hover route?
What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway?
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Mon, Jul 8, 2013 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sun, Jul 7, 2013 at 10:09 PM, bawolff bawolff+wn@gmail.com wrote:
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for use
in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some
animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller
on
mobile right now than on desktop. This means a) consider touchscreens
and b)
consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do
hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a
little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get a
nice
zoomed lightbox or something. This should be shared with non-gallery
media
however, so can be outside this present scope.
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively
easy, but
how can we show subcategories nicely? What about non-visual media?
Can we
display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery displays... having a gallery-style display for contained media is relatively
easy, but
how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I'd love to see this redesigned with mobile in mind as well... galleries are currently very broken on mobile!
On Mon, Jul 8, 2013 at 2:02 PM, Matthew Walker mwalker@wikimedia.orgwrote:
I was actually quite drawn to the images that were clean with no overlays
until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
Look and feel consistency is great; but I feel that the motivation for the dark overlay on mobile is driven by a lack of space. This lack of space does not exist on the desktop. We are an information provider; why are we advocating for hiding pertinent information about something if we have space to display it? Am I missing another constraint we've identified somewhere?
There's another problem with relying on mouseover... touch devices (which are a present and growing percentage of 'desktop' web devices) do not have a mouse to hover. What is our solution there if we go the hover route?
What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway?
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Mon, Jul 8, 2013 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sun, Jul 7, 2013 at 10:09 PM, bawolff bawolff+wn@gmail.com wrote:
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for use
in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some
animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
I like the overall look, couple notes:
- Think about tablet and mobile views -- galleries are even awfuller
on
mobile right now than on desktop. This means a) consider
touchscreens and b)
consider small screens.
- I'm not sold on "show title on hover". Touchscreens don't do
hover...
- Ragged edges can be fixed by adjusting spacing or aspect ratio a
little,
like justifying text. This would look awesome. :)
- We need to fix what happens when clicking the items -- should get
a nice
zoomed lightbox or something. This should be shared with non-gallery
media
however, so can be outside this present scope.
Another related thing to consider is Category page gallery
displays...
having a gallery-style display for contained media is relatively
easy, but
how can we show subcategories nicely? What about non-visual media?
Can we
display them better than we do now?
-- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
Another related thing to consider is Category page gallery
displays...
having a gallery-style display for contained media is relatively
easy, but
how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I'm not afraid of a completely different structure on mobile that is more appropriate to touch devices, but on the desktop I think we can rely on hover as a means of interacting with the content.
While space isn't as much of a concern the point of a gallery does feel more like it is about appreciating the imagery, by itself without extraneous elements clutter the visuals. When images appear in context they'll continue to have a byline with the title and author but in the gallery context this seems less desirable. Having the row of text breaking up the images feels distracting.
As with anything else we do we want the non-js version to be a graceful degradation of the experience. perhaps for non-js users we can set the text in white, on a black field, connected to the bottom of each image to make it seem like a cohesive object, and use similar typesetting, as the JS version, e.g. multiple font weights and opacity, left aligned, etc to echo the look and information hierarchy of the JS version, just not overlayed onto the images and having no rollover effect.
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jul 8, 2013 at 2:06 PM, Jon Robson jrobson@wikimedia.org wrote:
I'd love to see this redesigned with mobile in mind as well... galleries are currently very broken on mobile!
On Mon, Jul 8, 2013 at 2:02 PM, Matthew Walker mwalker@wikimedia.orgwrote:
I was actually quite drawn to the images that were clean with no overlays
until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
Look and feel consistency is great; but I feel that the motivation for the dark overlay on mobile is driven by a lack of space. This lack of space does not exist on the desktop. We are an information provider; why are we advocating for hiding pertinent information about something if we have space to display it? Am I missing another constraint we've identified somewhere?
There's another problem with relying on mouseover... touch devices (which are a present and growing percentage of 'desktop' web devices) do not have a mouse to hover. What is our solution there if we go the hover route?
What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway?
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Mon, Jul 8, 2013 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sun, Jul 7, 2013 at 10:09 PM, bawolff bawolff+wn@gmail.com wrote:
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for use
in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some
animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.com wrote:
> I like the overall look, couple notes: > * Think about tablet and mobile views -- galleries are even awfuller on > mobile right now than on desktop. This means a) consider touchscreens and b) > consider small screens. > * I'm not sold on "show title on hover". Touchscreens don't do hover... > * Ragged edges can be fixed by adjusting spacing or aspect ratio a little, > like justifying text. This would look awesome. :) > * We need to fix what happens when clicking the items -- should get a nice > zoomed lightbox or something. This should be shared with non-gallery media > however, so can be outside this present scope. > > Another related thing to consider is Category page gallery displays... > having a gallery-style display for contained media is relatively easy, but > how can we show subcategories nicely? What about non-visual media? Can we > display them better than we do now? > > -- brion
So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex
> Another related thing to consider is Category page gallery displays... > having a gallery-style display for contained media is relatively easy, but > how can we show subcategories nicely?
There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory.
Thanks everyone for the feedback :D
--bawolff
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-1
Our "Desktop" site is not a mouse-only desktop site. It's served to all non-tiny devices. Including desktops with mixed Touch and Pointer support and large tablets that don't have a pointer at all and rely entirely on touch.
I do not find mouseover to be an acceptable thing to rely on.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2013-07-08 2:19 PM, Jared Zimmerman wrote:
I'm not afraid of a completely different structure on mobile that is more appropriate to touch devices, but on the desktop I think we can rely on hover as a means of interacting with the content.
While space isn't as much of a concern the point of a gallery does feel more like it is about appreciating the imagery, by itself without extraneous elements clutter the visuals. When images appear in context they'll continue to have a byline with the title and author but in the gallery context this seems less desirable. Having the row of text breaking up the images feels distracting.
As with anything else we do we want the non-js version to be a graceful degradation of the experience. perhaps for non-js users we can set the text in white, on a black field, connected to the bottom of each image to make it seem like a cohesive object, and use similar typesetting, as the JS version, e.g. multiple font weights and opacity, left aligned, etc to echo the look and information hierarchy of the JS version, just not overlayed onto the images and having no rollover effect.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman https://twitter.com/JaredZimmerman
On Mon, Jul 8, 2013 at 2:06 PM, Jon Robson <jrobson@wikimedia.org mailto:jrobson@wikimedia.org> wrote:
I'd love to see this redesigned with mobile in mind as well... galleries are currently very broken on mobile! On Mon, Jul 8, 2013 at 2:02 PM, Matthew Walker <mwalker@wikimedia.org <mailto:mwalker@wikimedia.org>> wrote: I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal. Look and feel consistency is great; but I feel that the motivation for the dark overlay on mobile is driven by a lack of space. This lack of space does not exist on the desktop. We are an information provider; why are we advocating for hiding pertinent information about something if we have space to display it? Am I missing another constraint we've identified somewhere? There's another problem with relying on mouseover... touch devices (which are a present and growing percentage of 'desktop' web devices) do not have a mouse to hover. What is our solution there if we go the hover route? What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway? ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Mon, Jul 8, 2013 at 1:50 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org <mailto:jared.zimmerman@wikimedia.org>> wrote: I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal. I'd urge you to continue to explore a dark overlay on hover style for the desktop. May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery * * * * *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Sun, Jul 7, 2013 at 10:09 PM, bawolff <bawolff+wn@gmail.com <mailto:bawolff+wn@gmail.com>> wrote: Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected). As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/Non-photographic_media Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select. Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc). The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/ Thanks, Bawolff -- - Brian Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight. On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org <mailto:jared.zimmerman@wikimedia.org>> wrote: I tried this new version on my phone first and my desktop browser just now, a little feedback - I like it - May our Visual Designer is working on an information overlay for use in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days - Animation! I think this is a perfect opportunity to use some animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal. * * * * *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Thu, Jun 13, 2013 at 9:02 PM, bawolff <bawolff+wn@gmail.com <mailto:bawolff+wn@gmail.com>> wrote: > I like the overall look, couple notes: > * Think about tablet and mobile views -- galleries are even awfuller on > mobile right now than on desktop. This means a) consider touchscreens and b) > consider small screens. > * I'm not sold on "show title on hover". Touchscreens don't do hover... > * Ragged edges can be fixed by adjusting spacing or aspect ratio a little, > like justifying text. This would look awesome. :) > * We need to fix what happens when clicking the items -- should get a nice > zoomed lightbox or something. This should be shared with non-gallery media > however, so can be outside this present scope. > > Another related thing to consider is Category page gallery displays... > having a gallery-style display for contained media is relatively easy, but > how can we show subcategories nicely? What about non-visual media? Can we > display them better than we do now? > > -- brion So I've tweaked the demo a little bit in response to feedback: *If you're on a touchscreen, it will always show the caption instead of hover. Screen readers should also always see the caption, and if an image receives focus, its caption becomes visible. **Nonetheless, hover seems to be a sticking point, so I have a bunch of non-hover variations at http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page (May have to scroll) *Javascript now justifies the images. (The page is loaded with 1.5x the normal resolution images, and the <img> tag is manipulated to try and fill everything up, up to a maximum of 1.5x the original size. The last row is left as is, since its often a single image [Although as I write this, I think it should be manipulated too, might as well make it 1.5x]). As an aside, I found out that if I do text-align: justify, the browser will adjust the whitespace between images to justify it. However I think it looks better with the last row centred and typically adjusting the image size is enough; the whitespace doesn't have to be touched. **If you resize the browser window, js doesn't re-adjust stuff currently, so ragged edges re-appear. I suppose it could. Would make things a bit more complex > Another related thing to consider is Category page gallery displays... > having a gallery-style display for contained media is relatively easy, but > how can we show subcategories nicely? There was a thread a while back on the commons village pump which I thought was an interesting idea, where some users wanted a magic word that would enable a gallery view for subcategories, where each subcategory has a representative image specified via some means (I imagine parser func on subcategory page), or if unspecified defaults to the first entry in the subcategory. Thanks everyone for the feedback :D --bawolff _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
The patch I currently have actually does both methods, and can be triggered by a parameter. The implementation plan I'm hoping for is that patch gets enabled, and users can set which mode. After a month or so of gathering which mode users like, we could enable that one.
The reason why I went not to the overlay version in the demo was because many users I talked to thought it was very undesirable for the caption to be hidden, as they give context . Although in cases like categories where the caption is not very important (essentially the file size and name), I think the hover version may be the best choice.
What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway?
Note, the hover is pure css. (the fallback for if it detects you have a touch screen is js though)
--bawolff
-- - Brian Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Mon, Jul 8, 2013 at 6:19 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I'm not afraid of a completely different structure on mobile that is more appropriate to touch devices, but on the desktop I think we can rely on hover as a means of interacting with the content.
While space isn't as much of a concern the point of a gallery does feel more like it is about appreciating the imagery, by itself without extraneous elements clutter the visuals. When images appear in context they'll continue to have a byline with the title and author but in the gallery context this seems less desirable. Having the row of text breaking up the images feels distracting.
As with anything else we do we want the non-js version to be a graceful degradation of the experience. perhaps for non-js users we can set the text in white, on a black field, connected to the bottom of each image to make it seem like a cohesive object, and use similar typesetting, as the JS version, e.g. multiple font weights and opacity, left aligned, etc to echo the look and information hierarchy of the JS version, just not overlayed onto the images and having no rollover effect.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jul 8, 2013 at 2:06 PM, Jon Robson jrobson@wikimedia.org wrote:
I'd love to see this redesigned with mobile in mind as well... galleries are currently very broken on mobile!
On Mon, Jul 8, 2013 at 2:02 PM, Matthew Walker mwalker@wikimedia.orgwrote:
I was actually quite drawn to the images that were clean with no
overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
Look and feel consistency is great; but I feel that the motivation for the dark overlay on mobile is driven by a lack of space. This lack of space does not exist on the desktop. We are an information provider; why are we advocating for hiding pertinent information about something if we have space to display it? Am I missing another constraint we've identified somewhere?
There's another problem with relying on mouseover... touch devices (which are a present and growing percentage of 'desktop' web devices) do not have a mouse to hover. What is our solution there if we go the hover route?
What about the case where the user does not have javascript enabled -- what is our progressive enhancement pathway?
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Mon, Jul 8, 2013 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
May created the mockup here http://www.mediawiki.org/wiki/Commons_Web_Gallery
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sun, Jul 7, 2013 at 10:09 PM, bawolff bawolff+wn@gmail.com wrote:
Just as an update on my attempt to redesign the gallery tag. I now completed the code (Making it work well with TMH was more challenging than I expected).
As before, there is a demo at: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... Based on feedback, it seems like hiding of caption is not wanted, so I changed the default mode on the demo. In my patchset it add a "mode" parameter to the gallery tag that users can select.
Ideally what I would like to see happen with this is that it gets CR and is merged (but the default is still the old gallery), let the users play with it for a little while. If feedback is positive, switch it to be the default (for both the <gallery> parser tag, and things like categories, Special:newimages, etc).
The code is at: https://gerrit.wikimedia.org/r/#/c/67885/ (Sorry for a somewhat big patch). Any code review (or other types of review/feedback) would be appreciated. There's also a patch for TMH at https://gerrit.wikimedia.org/r/#/c/69455/
Thanks, Bawolff
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85 million tons of TNT per net ounce of weight.
On Fri, Jun 14, 2013 at 2:53 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I tried this new version on my phone first and my desktop browser just now, a little feedback
- I like it
- May our Visual Designer is working on an information overlay for
use in the commons mobile apps, I'd like for the visual design to sync up with that work, which should be done in a few days
- Animation! I think this is a perfect opportunity to use some
animation, we still want this to be quick, but having the overlays animate in(very fast), and out(less fast) would be ideal.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Jun 13, 2013 at 9:02 PM, bawolff bawolff+wn@gmail.comwrote:
> > I like the overall look, couple notes: > > * Think about tablet and mobile views -- galleries are even > awfuller on > > mobile right now than on desktop. This means a) consider > touchscreens and b) > > consider small screens. > > * I'm not sold on "show title on hover". Touchscreens don't do > hover... > > * Ragged edges can be fixed by adjusting spacing or aspect ratio a > little, > > like justifying text. This would look awesome. :) > > * We need to fix what happens when clicking the items -- should > get a nice > > zoomed lightbox or something. This should be shared with > non-gallery media > > however, so can be outside this present scope. > > > > Another related thing to consider is Category page gallery > displays... > > having a gallery-style display for contained media is relatively > easy, but > > how can we show subcategories nicely? What about non-visual media? > Can we > > display them better than we do now? > > > > -- brion > > > So I've tweaked the demo a little bit in response to feedback: > *If you're on a touchscreen, it will always show the caption instead > of hover. Screen readers should also always see the caption, and if > an > image receives focus, its caption becomes visible. > **Nonetheless, hover seems to be a sticking point, so I have a bunch > of non-hover variations at > http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page > (May have to scroll) > *Javascript now justifies the images. (The page is loaded with 1.5x > the normal resolution images, and the <img> tag is manipulated to try > and fill everything up, up to a maximum of 1.5x the original size. > The > last row is left as is, since its often a single image [Although as I > write this, I think it should be manipulated too, might as well make > it 1.5x]). As an aside, I found out that if I do text-align: justify, > the browser will adjust the whitespace between images to justify it. > However I think it looks better with the last row centred and > typically adjusting the image size is enough; the whitespace doesn't > have to be touched. > **If you resize the browser window, js doesn't re-adjust stuff > currently, so ragged edges re-appear. I suppose it could. Would make > things a bit more complex > > > Another related thing to consider is Category page gallery > displays... > > having a gallery-style display for contained media is relatively > easy, but > > how can we show subcategories nicely? > > There was a thread a while back on the commons village pump which I > thought was an interesting idea, where some users wanted a magic word > that would enable a gallery view for subcategories, where each > subcategory has a representative image specified via some means (I > imagine parser func on subcategory page), or if unspecified defaults > to the first entry in the subcategory. > > Thanks everyone for the feedback :D > > --bawolff > > _______________________________________________ > Design mailing list > Design@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design >
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, 08 Jul 2013 22:50:09 +0200, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
I was actually quite drawn to the images that were clean with no overlays until mouseover, it was also more closely tied to the look of the commons uploader mobile app. We feel strongly that consistency between these would be ideal.
I'd urge you to continue to explore a dark overlay on hover style for the desktop.
Please no. Let's not create another incarnation of mystery meat[1]. Captions are content and they should be immediately visible if they're present.
[1] https://en.wikipedia.org/wiki/Mystery_meat_navigation
2013/6/11 bawolff bawolff+wn@gmail.com
Over the last couple days, I've been looking at making our <gallery> tag a lot more slick.
This got deployed yesterday - see Brian post on Wikimedia Commons village pump https://commons.wikimedia.org/wiki/COM:VP#.3CGallery.3E_tag
Many thanks to Brian for his work!
Cheers,