Gallery

Below is the thread with background logic for Gallery.

FROM ALICE ON JUL 12

The term Gallery is used loosely on the web to speak of 2 types of content (often related to images) -- one is an interactive component (javascript driven galleries) while the other references data collections (simple image thumbnail sets).

It's being filed on its own page here for further discussion on where this pattern fits within WebBlocks:

Here is a general and broad definition (one that's commonly understood on the web): http://ui-patterns.com/patterns/Gallery

A. Pattern: Player. One option is to think of galleries as an interactive component as in javascript driven galleries -- and thus having more in common with sliders and slideshows etc. From an interactive perspective, it's primary function is to display and transition between a series of images. The primary organizing principal is in its interaction design: to allow users play and transition. As such it would have many elements in common with other forms of interactive media players. http://www.bbc.co.uk/gel/web/web-patterns/interaction/slideshow http://www.queness.com/post/633/30-javascript-image-and-photo-galleriesmootool-prototype-jquery-and-tutorials http://coding.smashingmagazine.com/2007/05/18/30-best-solutions-for-image-galleries-slideshows-lightboxes/

B. Pattern: Display Collection/Thumbnails. Another option is to think of galleries as a variant of listing a collection from a data set. In this second pattern, the content type is less important (media vs. link vs. image) -- what matters is the fact that there is a curated list or collection of data that is seen as one related chunk. Interactivity is often not the focal point in this pattern as transitioning is less important than the fact that the user can associate the grouping as a set.

See pattern #15: http://www.onextrapixel.com/2010/11/03/15-ui-design-patterns-web-designers-should-keep-handy/ http://developer.yahoo.com/ypatterns/social/objects/collecting/displaying.html Twitter Bootstrap has something they call Thumbnails: http://twitter.github.com/bootstrap/components.html

In the mobile space the term is a popular form of navigation pattern referencing the dataset type of gallery: http://mobiledesignpatterngallery.com/mobile-patterns-details.php?colid=65438029-72157627607680275&setid=72157627762105824&s=4

For semantics, the type of gallery it is will matter. If the item is of the player type than the argument for figure/caption could be made. Otherwise, if it is of the data set type, then a list type would be more appropriate. See overuse of figure: http://html5doctor.com/avoiding-common-html5-mistakes/

It may help for us to disambiguate the term "gallery" and use instead "player" to refer to slideshows, sliders, video players and "sets" to refer to image, links, etc. Or not, and live with the fact that "gallery" is the popular and understood term to mean "anything with a bunch of images" and deal with an overlap in 2 categories ("interactive" and "collection (a.k.a. data sets)").

One Approach: interactive/player/gallery entity/list/collection/gallery

Another Approach: ui/gallery/interactive ui/gallery/static

Or simply adopt the Thumbnails pattern from Twitter.

FROM ERIC ON JUL 12

I think that ui/gallery/interactive and ui/gallery/static make sense if they share a significant chunk of markup and then just differ in behavioral properties (like player controls). However, you make a good point that the player should have figure/caption and the collection would be a list. That said, I agree that we should actually NOT use ui/gallery as a base for both but instead come up with another way to do it.

I agree then with the idea of interactivity/player/gallery and some other class. However, I'm not sure the right breakdown is entity/list/collection/gallery. Maybe we should go with entity/list/gallery. Any reason we want to add a subcategory of collection there? I think a list is a collection.

In a way, this sort of entity/list/gallery can be an extension of Bootstrap's .thumbnails class and its subclasses. However, we should design our UX as we think it will be and then go from there.

FROM ALICE ON JUL 12 Hi so ... upon further reading it does look like figure can be used to encapsulate a grouping of related images -- so perhaps it is better to have them be one gallery ui element, afterall? I'm still not sure. On one hand it does make sense as a type of list, on the other hand it actually doesn't seem to be a problem to have the figure element act as a wrapper for a list; and the other element that lends weight to using figure is that it can contain any type of content (not just images) -- that are related and directly referenced by the primary content from its context. The important point about figure is that it should be something that relates primarily to the content (that if removed, the page will lose meaning, but it's placement in the flow is maliable) -- otherwise the content would be considered an aside. http://html5doctor.com/the-figure-figcaption-elements/

What do you think about the following? entity/figure/gallery

See this example: (taken from here) http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element

<figure>
 <figcaption>The top 10 movies of all time</figcaption>
 <ol>
  <li value="10"><cite>Josie and the Pussycats</cite>, 2001</li>
  <li value="9"><cite lang="sh">Црна мачка, бели мачор</cite>, 1998</li>
  <li value="8"><cite>A Bug's Life</cite>, 1998</li>
  <li value="7"><cite>Toy Story</cite>, 1995</li>
  <li value="6"><cite>Monsters, Inc</cite>, 2001</li>
  <li value="5"><cite>Cars</cite>, 2006</li>
  <li value="4"><cite>Toy Story 2</cite>, 1999</li>
  <li value="3"><cite>Finding Nemo</cite>, 2003</li>
  <li value="2"><cite>The Incredibles</cite>, 2004</li>
  <li value="1"><cite>Ratatouille</cite>, 2007</li>
 </ol>
</figure>

FROM ERIC ON JUL 16

Let's go with entity/figure/gallery then for the markup.

FROM LOGAN ON JULY 25

In thinking through the possible use cases, I think the proposed markup easily handles two main scenarios (which you have already explained above):

1. An image carousel/player/slider that transitions through a set of images
2. An image gallery of image thumbnails

My only concern was the combined scenario, in which you have a carousel-type display of the current image and a gallery of thumbnails (that acts as another control for the carousel), as you would need a separate place from the list in the markup to slot the focal image (example: http://nivo.dev7studios.com/demos/4/). Or maybe we just don't tackle this scenario as to not overcomplicate the base framework? (It could always be implemented later as a plug-in/add-on to the framework)

Also, one more thing: are we adding the optional "player" controls to the prototype?

(Let me know where I can help, Alice; just didn't want to step on your toes)

[Alice 7/26]

@loganfranken - jump in anywhere you see fit - no worries. I already added the prototype.html example you posted for gallery in the standards doc. I think it's good to think through these design issues and log the research here. I know we've agreed to put only ideal clean entity prototypes and decided to deal with implementation issues later -- but it'll be great to have that information brought up and logged.

[Alice 8/06 Update] Group decided in meeting that Gallery should accomodate both the div and figure use-case; when the content's position is critical div should be used; when the position is not critical figure would be appropriate.

FROM ALICE ON 8/22

Coming back to finish this off. Gallery and Billboard both have optional "interactive" scenarios -- I believe that these should be handled in their own interactive class prototypes (as well as the rendered player controls). I have updated both prototypes to include the optional interactive classes for interactive features.

This follows the conventions seen in other frameworks: twitter bootstrap, YUI and BBC GEL. All the above frameworks break out complex interactive features as "interactive" or "javascript" components, plugins or widgets sperate from the base content component.

http://twitter.github.com/bootstrap/components.html#typography vs. http://twitter.github.com/bootstrap/javascript.html#carousel http://www.bbc.co.uk/gel/web/web-patterns/interaction/slideshow http://www.yuiblog.com/blog/2009/11/04/yui-3-gallery-accordion-widget/

Further writing about this technique is explored in this article: http://www.onderhond.com/blog/work/carousel-2012-update

I'm also adding a nested figure option for cases when the billboard needs to accomodate having a unique caption per image. The current recommended approach that is deemed more accessible is using nested figures with their own figcaptions. See these sources: http://www.paciellogroup.com/blog/2011/11/html5-accessibility-chops-using-nested-figure-elements/

http://dev.w3.org/html5/spec/the-figure-element.html#the-figure-element