[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
If this should find its way into core, it should be made optional (using an attribute of <gallery>)! Please be aware that this would instantly destroy gallery applications like COM:QIC. Also from a usability standpoint hiding the captions is probably not always a good thing. Especially in the context of an encyclopedia rather than a "pretty picture" site (like flickr). Daniel
On Mon, Jun 10, 2013 at 6:36 PM, 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... (contrast with http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic... )
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A... (contrast 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
That's how its currently implemented (with an attribute named mode). How it all works (Or even if it gets adopted), will depend on the sort of feedback I get.
You're 100% right, that this would not work well with the COM:QIC workflow, and there are many places where the captions are important. But I would argue there are many places where people just have captions as a place holder text since there is a spot for a caption (Many [not all] galleries on commons fit this description). In particular, the captions on the auto-generated galleries in category listings are pretty useless, and could easily be replaced with something triggered on hover.
Even in encyclopedic contexts, a gallery is used as a collection of pretty pictures, and the caption is a sort of "see also" text to provide further context for if one of the images catches the reader's eye.
--bawolff
On Mon, Jun 10, 2013 at 10:53 PM, Daniel Schwen lists@schwen.de wrote:
If this should find its way into core, it should be made optional (using an attribute of <gallery>)! Please be aware that this would instantly destroy gallery applications like COM:QIC. Also from a usability standpoint hiding the captions is probably not always a good thing. Especially in the context of an encyclopedia rather than a "pretty picture" site (like flickr). Daniel
On Mon, Jun 10, 2013 at 6:36 PM, 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...
(contrast with
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...
)
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A...
(contrast 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers. This format is used on sites like Flickr, Pininterest, Google+ etc.. while many user spend there time just scraping these sites do we really need to look them How does an editor decide what image sizes are,
IMHO rather than doing this to <gallery> tag something thats frowned upon in GA, A class and FA processes on en.WP anyway this would be better utilised within the category structure where the more important elements of image size, and name could be displayed with the hover giving you linking options.
On 11 June 2013 10:20, bawolff bawolff+wn@gmail.com wrote:
That's how its currently implemented (with an attribute named mode). How it all works (Or even if it gets adopted), will depend on the sort of feedback I get.
You're 100% right, that this would not work well with the COM:QIC workflow, and there are many places where the captions are important. But I would argue there are many places where people just have captions as a place holder text since there is a spot for a caption (Many [not all] galleries on commons fit this description). In particular, the captions on the auto-generated galleries in category listings are pretty useless, and could easily be replaced with something triggered on hover.
Even in encyclopedic contexts, a gallery is used as a collection of pretty pictures, and the caption is a sort of "see also" text to provide further context for if one of the images catches the reader's eye.
--bawolff
On Mon, Jun 10, 2013 at 10:53 PM, Daniel Schwen lists@schwen.de wrote:
If this should find its way into core, it should be made optional (using an attribute of <gallery>)! Please be aware that this would instantly destroy gallery applications like COM:QIC. Also from a usability standpoint hiding the captions is probably not always a good thing. Especially in the context of an encyclopedia rather than a "pretty picture" site (like flickr). Daniel
On Mon, Jun 10, 2013 at 6:36 PM, 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...
(contrast with
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...
)
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A...
(contrast 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Bawolff, as a simple user I find your gallery very pretty and usable. I think also that it's a good idea to look at sites that work (Flickr, Pininterest, Google+, Tumblr), especially if we want to be read, used and acctract contributors.
Aubrey
On Tue, Jun 11, 2013 at 4:31 AM, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers. This format is used on sites like Flickr, Pininterest, Google+ etc.. while many user spend there time just scraping these sites do we really need to look them How does an editor decide what image sizes are,
IMHO rather than doing this to <gallery> tag something thats frowned upon in GA, A class and FA processes on en.WP anyway this would be better utilised within the category structure where the more important elements of image size, and name could be displayed with the hover giving you linking options.
On 11 June 2013 10:20, bawolff bawolff+wn@gmail.com wrote:
That's how its currently implemented (with an attribute named mode). How it all works (Or even if it gets adopted), will depend on the sort of feedback I get.
You're 100% right, that this would not work well with the COM:QIC workflow, and there are many places where the captions are important. But I would argue there are many places where people just have captions as a place holder text since there is a spot for a caption (Many [not all] galleries on commons fit this description). In particular, the captions on the auto-generated galleries in category listings are pretty useless, and could easily be replaced with something triggered on hover.
Even in encyclopedic contexts, a gallery is used as a collection of pretty pictures, and the caption is a sort of "see also" text to provide further context for if one of the images catches the reader's eye.
--bawolff
On Mon, Jun 10, 2013 at 10:53 PM, Daniel Schwen lists@schwen.de wrote:
If this should find its way into core, it should be made optional (using an attribute of <gallery>)! Please be aware that this would instantly destroy gallery applications like COM:QIC. Also from a usability standpoint hiding the captions is probably not always a good thing. Especially in the context of an encyclopedia rather than a "pretty picture" site (like flickr). Daniel
On Mon, Jun 10, 2013 at 6:36 PM, 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...
(contrast with
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...
)
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A...
(contrast 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
These look fantastic! I think with hover over captions as optional it could be a big hit.
On 11 June 2013 03:31, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers.
Not if implemented properly. e.g. utilising the <img> tag's title/alt attributes - in which case it's actually better than the current implementation!
Tom
Implementation in JavaScript:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit...
Good: * Works.
Bad: * Needs to load thumbnails twice (for hi-res versions). * Excessive API usage for getting hi-res thumbnails, but could be grouped for multiple files per query (I'm just too lazy to implement now). * Also too lazy to implement changing img title, but possible.
Feel free to improve!
On Tue, Jun 11, 2013 at 10:27 AM, Thomas Morton < morton.thomas@googlemail.com> wrote:
These look fantastic! I think with hover over captions as optional it could be a big hit.
On 11 June 2013 03:31, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers.
Not if implemented properly. e.g. utilising the <img> tag's title/alt attributes - in which case it's actually better than the current implementation!
Tom
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hi magnus, in this page: http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit... this image has a strange behaviour:
[image: POTY ribbon 2007.svg]http://commons.wikimedia.org/wiki/File:POTY_ribbon_2007.svg
(second row of the Bony fishes, first image)
Aubrey
On Tue, Jun 11, 2013 at 12:26 PM, Magnus Manske <magnusmanske@googlemail.com
wrote:
Implementation in JavaScript:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit...
Good:
- Works.
Bad:
- Needs to load thumbnails twice (for hi-res versions).
- Excessive API usage for getting hi-res thumbnails, but could be grouped
for multiple files per query (I'm just too lazy to implement now).
- Also too lazy to implement changing img title, but possible.
Feel free to improve!
On Tue, Jun 11, 2013 at 10:27 AM, Thomas Morton < morton.thomas@googlemail.com> wrote:
These look fantastic! I think with hover over captions as optional it could be a big hit.
On 11 June 2013 03:31, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers.
Not if implemented properly. e.g. utilising the <img> tag's title/alt attributes - in which case it's actually better than the current implementation!
Tom
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Not quite sure what you mean. I don't see a POTY ribbon, either with or without the JS.
On Tue, Jun 11, 2013 at 11:36 AM, Andrea Zanni zanni.andrea84@gmail.comwrote:
Hi magnus, in this page:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit... this image has a strange behaviour:
[image: POTY ribbon 2007.svg]http://commons.wikimedia.org/wiki/File:POTY_ribbon_2007.svg
(second row of the Bony fishes, first image)
Aubrey
On Tue, Jun 11, 2013 at 12:26 PM, Magnus Manske < magnusmanske@googlemail.com> wrote:
Implementation in JavaScript:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit...
Good:
- Works.
Bad:
- Needs to load thumbnails twice (for hi-res versions).
- Excessive API usage for getting hi-res thumbnails, but could be grouped
for multiple files per query (I'm just too lazy to implement now).
- Also too lazy to implement changing img title, but possible.
Feel free to improve!
On Tue, Jun 11, 2013 at 10:27 AM, Thomas Morton < morton.thomas@googlemail.com> wrote:
These look fantastic! I think with hover over captions as optional it could be a big hit.
On 11 June 2013 03:31, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers.
Not if implemented properly. e.g. utilising the <img> tag's title/alt attributes - in which case it's actually better than the current implementation!
Tom
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
In this page: http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit... there is an image called *Dactylopterus volitanshttp://commons.wikimedia.org/wiki/Dactylopterus_volitans * (Flying gurnard)
It sort of "doubles" if you put the cursor on it. All other images on the other hand just show their caption.
Aubrey
OK, should be fixed now.
On Tue, Jun 11, 2013 at 12:03 PM, Andrea Zanni zanni.andrea84@gmail.comwrote:
In this page:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit... there is an image called *Dactylopterus volitanshttp://commons.wikimedia.org/wiki/Dactylopterus_volitans
- (Flying gurnard)
It sort of "doubles" if you put the cursor on it. All other images on the other hand just show their caption.
Aubrey
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
My quibble with galleries as they are now is that, for audio and video files, they make it hard to get to the respective file pages on Commons. If hovering could help with that, I would welcome it.
I am doing a lot of demos of Commons functionalities to GLAMs, who are very concerned about their materials being attributed properly (which have been doing well so far) and about making it easy to get from the page containing a particular file to the file description page on Commons (the latter part works fine for images but currently is too complicated for audio and video files).
Is anyone working on that?
A sample gallery containing only audio and video files is at http://outreach.wikimedia.org/wiki/GLAM/Newsletter/May_2013/Contents/Open_Ac... .
Cheers,
Daniel
On Tue, Jun 11, 2013 at 1:36 PM, Magnus Manske magnusmanske@googlemail.com wrote:
OK, should be fixed now.
On Tue, Jun 11, 2013 at 12:03 PM, Andrea Zanni zanni.andrea84@gmail.com wrote:
In this page:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit... there is an image called Dactylopterus volitans (Flying gurnard)
It sort of "doubles" if you put the cursor on it. All other images on the other hand just show their caption.
Aubrey
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 6/11/13 4:53 AM, Daniel Mietchen wrote:
My quibble with galleries as they are now is that, for audio and video files, they make it hard to get to the respective file pages on Commons. If hovering could help with that, I would welcome it.
Personally, I would like to see an improved modular viewer for all types of media files. Right now we have a modular viewer for videos, but it would be a lot cooler if it included the attribution information (and possibly the licensing information) within the viewer itself (rather than only showing it after the video has played). If we had this sort of functionality for all types of media there would be less need to send people to Commons to see the file page (which is often confusing to people).
Ryan Kaldari
On 6/10/13, Gnangarra gnangarra@gmail.com wrote:
Requiring a hoover to see a caption becomes an impediment to non sight readers who rely on various readers. This format is used on sites like Flickr, Pininterest, Google+ etc.. while many user spend there time just scraping these sites do we really need to look them
I've re-done the demo in a way hopefully more accessible to screen readers (The caption text should be picked up by screen readers, even if not visible.) Additionally the caption text should be visible when tabbing through the page.
Not if implemented properly. e.g. utilising the <img> tag's title/alt attributes - in which case it's actually better than the current implementation!
Yeah, I'm not sure which is better, to stuff the caption in an alt attribute (where we'd have to strip out the complex formatting a caption could have, and where the caption could potentially not even describe the image), or making the caption part visible to the screen reader but invisible to the user [Galleries support adding an alt attribute, but almost nobody does]. So far I've opted for the latter, but I'm certainly not an accessibility expert. (I had a little fun though today playing with the orca screen reader and testing. All I can say is that it must be an extremely frustrating experience to be visually impaired)
One remaining issue is that the hover on captions thing is not very effective with a touch screen...
How does an editor decide what image sizes are,
Not sure what you mean? Same way they currently do with a parameter to the gallery tag.
this would be better utilised within the category structure where the more important elements of image size, and name could be displayed with the hover giving you linking options.
That's (part of) the intent.
Thomas said:
I think with hover over captions as optional it could
be a big hit.
I've experimented with various methods of non-hovering. See http://tools.wmflabs.org/bawolff/gallery/index.php?title=Main_Page for different options I've tried (You may have to scroll a little bit).
Implementation in JavaScript:
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Animals/Fish?wit...
Cool. I thought it was interesting to view Special:newfiles with this script.
Thank you everyone for your feedback. I appreciate it (If you have any more thoughts, keep it coming).
--bawolff
On 11 June 2013 10:20, bawolff bawolff+wn@gmail.com wrote:
That's how its currently implemented (with an attribute named mode). How it all works (Or even if it gets adopted), will depend on the sort of feedback I get.
You're 100% right, that this would not work well with the COM:QIC workflow, and there are many places where the captions are important. But I would argue there are many places where people just have captions as a place holder text since there is a spot for a caption (Many [not all] galleries on commons fit this description). In particular, the captions on the auto-generated galleries in category listings are pretty useless, and could easily be replaced with something triggered on hover.
Even in encyclopedic contexts, a gallery is used as a collection of pretty pictures, and the caption is a sort of "see also" text to provide further context for if one of the images catches the reader's eye.
--bawolff
On Mon, Jun 10, 2013 at 10:53 PM, Daniel Schwen lists@schwen.de wrote:
If this should find its way into core, it should be made optional (using an attribute of <gallery>)! Please be aware that this would instantly destroy gallery applications like COM:QIC. Also from a usability standpoint hiding the captions is probably not always a good thing. Especially in the context of an encyclopedia rather than a "pretty picture" site (like flickr). Daniel
On Mon, Jun 10, 2013 at 6:36 PM, 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...
(contrast with
http://commons.wikimedia.org/wiki/Commons:Featured_pictures/Non-photographic...
)
http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/A...
(contrast 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com
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
- I'm not sold on "show title on hover". Touchscreens don't do hover...
Except the new galaxy.. ;-)
- Ragged edges can be fixed by adjusting spacing or aspect ratio a little,
like justifying text. This would look awesome. :)
I'd keep aspect ratio constant, but play with the height a bit. This would make the gallery height setting a rough target value, rather than an absolute.
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 just tested the new environment with multimedia files - not a good match: http://tools.wmflabs.org/bawolff/gallery/index.php?title=Featured_pictures/N... .
Daniel
On Fri, Jun 14, 2013 at 6:02 AM, 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
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
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,
2013/8/20 Jean-Frédéric jeanfrederic.wiki@gmail.com
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!
Echoing Jean-Frédéric's message, that's amazing as a big fan of galleries vs categories this features made my day.
\o/ \o/