In NodeStream, I would like there to be a gallery. I've discussed this with Fabsor, and as with the other content providers, the gallery will be developed as it's own project. Sandbox here.
In this post, I intend to outline what a NodeStream gallery would consist of, and what the challenges are.
What will the gallery do?
The gallery will first and foremost provide a content type called gallery. A gallery will be created with a few standard fields for tags, description, and most importantly, media.
One important feature that I think we should offer out of the box, but that doesn't belong under the gallery project namespace, is bulk upload with a drag and drop interface. Plupload can provide this functionality, but perhaps primarily we want to look at more modern options, comments welcome.
There will definitely be a make file to help put the module together with it's external dependencies, and possibly there will be hard-dependencies on modules such as plupload and multiform, making it obvious what's required to get a nice out of the box experience.
We will provide a few default configurations that the gallery can be viewed with, but also make sure that we build as much as possible on Views/Panels and enable users to customize the experience as they see fit.
Technical challenges
User experiece
Currently, combining media, plupload and multiform, will give a very nice user experience for bulk uploading images to the library, at /file/add. While this is nice, I don't think it's enough. We should make it possible to use drag and drop directly on top of the file-field in any gallery edit page. This functionality should probably go into the file-entity, or media, or another project though, not the gallery.
References and display
When we discussed the rendering solution for a gallery in Sthlm, we concluded that it would be a nice "feature" not to have a hard dependency on Views. Instead we refer to media from the gallery by entity references, and use Panels ref formatter to render the thumbnails at the bottom. This will give us both nice performance and a lot of flexibility, but comes with a price. Since we don't use a file-field anymore, the implementation of the multiupload functionality will become much more comlicated. The question is if we should try to implement bulk upload on ERs, or use media references.
The way forward
Currently I'm thinking that I will just ignore the issues above, use ERs and Views, so that we can "deliver working software", and then prioritize from there.
Comments
Some UX questions
In the research I did around this, 'bulk upload' quickly surfaced as a must-have indeed.
Gallery UX
As you can perhaps tell from my post, I'm a technical person, and think first in terms of "what would a nice technical solution look like", and only later "who would be able to use this?". ;)
That only means I appreciate the UX feedback more. :) I attempt to answer your questions below.
The end user of a gallery is obviously the person browsing the site, but for me, the main target user is the site-builder/editor.
What the site-builder want to achieve, is building a media gallery with little effort, that is still configurable enough that one feels empowered by the module, not locked in to a specific configuration. The editor, wants a convenient way of creating new galleries, the main feature here is the bulk upload.
The two main scenarios, for which I would like to ship default configurations:
A high-res photo gallery. Images displayed in a large size/fullscreen overlay so that high resolution photos can be displayed appropriately, for when the images themselves are the main attraction. (Assuming your monitor is large, how we handle this on a smaller device I don't know)
Promotion slideshow for a certain piece of site content. I'm thinking about something very similar to how steam has a slideshow for promotion of individual games. (Example: http://store.steampowered.com/app/65300/
With "How do they picture, think about how that would work?" I can only answer for myself, but I'm annoyed by needing to upload each image individually. There bulk upload is an important function. :)
Good!
These kinds of questions help scoping things.
I agree with the site builder as the primary persona for this tool
The larger context/scenario questions tries to frame when people will be using this:
Not saying you should be able to answer these now, but something to look into.
Nice feature!
Great. I agree that multi-upload is separate from the gallery, it would be nice-to-have in core nodestream, e.g. when adding media to an article. As I understand the current situation the pupload module is now abondoned by the media project? Are there other obvious choices for multi-upload functionality if you don't go for HTML5?
I can see several several primary use cases:
- Slideshows in promos (is not really a gallery, could probably be realized with current functionality as multiple media assets are linked to the article).
- Ability to link a slideshow to an article, similar to how factboxes work. Visitors can click a link or image in the "factbox" to open up a gallery viewer/slideshow (overlay) with related images. Alternatively open up a proper gallery page.
- Media repository, bascially a landing page for all galleries. Can galleries be nested?
Functionality I'd love to see for the site admin/editor:
- Organizing which media go into which gallery. One image can go into several slideshows? Can the Media Browser Plus project be of any help?
- Configurable settings for each gallery of for example presentation type: overlay/lightbox or in-situ image swaps or mediaplayer Mediafront(?) etc.
I've been off Drupal for a couple of years and it seems to have happened a lot around media. I'm currently discovering and learning Nodestream - this would be a great addition for all kinds of sites!
Bulk Uploading is key!
Galleries should allow for bulk uploading.
Also, galleries should be embeddable in articles
404?
Sandbox link gives me a 404. Could you update your post please?
That's annoying. The link
That's annoying. The link didn't include the domain, so it linked to g.d.o instead of d.o. Fixed now.