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(a)wikimedia.org>wrote;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(a)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 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
>
>
>
> On Sun, Jul 7, 2013 at 10:09 PM, bawolff <bawolff+wn(a)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/…
>> 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(a)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 | :
@JaredZimmerman<https://twitter.com/JaredZimmerman>
>>>
>>>
>>>
>>> On Thu, Jun 13, 2013 at 9:02 PM, bawolff <bawolff+wn(a)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(a)lists.wikimedia.org
>>>>
https://lists.wikimedia.org/mailman/listinfo/design
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Design mailing list
>> Design(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/design
>>
>>
>
> _______________________________________________
> Design mailing list
> Design(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/design
>
>
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design