This is somewhat long post regarding suggestion on a new and enhanced media library functionality for Sitefinity 4. I've split them up into a general category and 2 sub posts with specific content suggestions on images and the new html5 audio/video.
This is in no way a complete feature suggestion list, merely a kick-off to get a discussion started instead of being surprised by an implementation and complaining after alot of work has been put into it (although I'm betting they've got something internal already)
Media library [general]
Unified media library:
Currently images and videos are split content items and libraries refer to a group of either images or video's. My suggestion would be to create a unified (combined/not seperate) media library in which a user can define 'albums'.
Inside those 'albums' a user could place a diverse range of content (img/video/audio) depending on what settings were set/allowed for that album. These settings would be backed by Admin>Advanced settings which would define valid content mime-types for the entire website.
For instance 'AlbumA' would be allowed to have '.jpg' and '.png' while 'AlbumB' would be allowed to hold '.png', '.ogv' and '.webm'
From an end-user perspective it makes much more sense to have all the 'slider' content in one album instead of half in an image library and half in a video library. This will also make it easier for security permission to be set because certain users would be restricted to uploading only to a certain 'album'.
Media items should be restricted to albums.
Images/audio/video should be hidden behind albums like blog entries are hidden inside a blog. Currently when browsing Content>images, one immediately sees image thumbnails regardless of their library. And even when selecting a library it it completely unclear to the end user as to where one is. Also when uploading from within a certain library it still asks to upload to any library and even allows to upload outside a library.
Uploads should be completely restricted to inside albums to ensure correct permissions and restrictions.
Currently things are set on a per item basis, which is fine if you only have a select few items, when managing hundreds of media items it allows for far greater security and easier alternations if things can be set on an 'album' basis.
Overlay icons & descriptions.
Whether a user is browsing an 'album' or looking at some images/videos, the items should show a small thumbnail icon in a corner making it instantly recognizable what someone is looking at (an album/an image etc).
When hovering over with the mouse, one should get some additional information. For instance with an 'album' how many files inside, what content types and for an image it's alt tag and its size.
On each album one would be able to restrict settings for each content type allowed as mentioned before. But next to file-type restrictions, we should also have the ability for file-size restrictions on a per cotent type. For instance 'AlbumA' images automatically will be resized to 640x480 while 'AlbumB' images can be uploaded in full format.
This can be achieved by adding a global albumconfig.config with inside for each album the allowed type and it's allowed sizes. This doesn't only apply for image sizes but complies to video sources aswell.
Album items should be 'pointers'.
When in BackEnd clicking on Media Library, one should get an grid overview of the albums and the playlists. Clicking on an album should take one to an grid overview of the items. When clicking on an item, one should go to a detail page.
On that detailpage one should have the general item settings on top (alt tag/description/figure caption/placeholder image) and beneath that a grid of the actual physical items.
For instance with images you'd have alt/text/description which applies to all the different physical items but one could have a thumbnail/small and large size images as physical files. Or for html5 video, you'd have 1 pointer item with an alt/description/placeholder image but with different physical formats (one in .ogv and one for .webm
An extra addition to the media library would be playlists. Playlists would be an xml generator from a certain album by which an enduser could quickly select the 'album' to create the playlist from and select from a few minor options (same as with navigation, all or selected subset of items).
Playlists can be extended with custom fields, allowing for easy attribution of some text or an uri.
This way it will be easy for novice end users to change content sliders and/or audio/video players without jumping through html hoops or being forced to create an entire new album and duplicate content.
The playlist widget.
Instead of having a mere image gallery, the playlist widget could be used as an exposed XMLDataSource to allow further jQuery fun-stuff, to not only allow lightbox things but all kinds of jQuery sliders/enhancements. By having a Telerik developed 'playlist' we're assured that it's not only implemented correctly but also exposed through the API.
Media library [images]
As mentioned before, albums should have upload restrictions both in file-type and in image size. This will allow for easier use of content and a more flexible approach towards responsive design/adaptive images.
For a 'generic album' you could set for instance 4 image sizes. Thumb, 1 column, 2 column and fullsize. In the album settings one would define whether images should be stored physically or scaled dynamically. But on the front-end these image-sizes are the only ones choosable.
Most webdesigns are designed/looking best when using only 1 or 2,3 predefined sizes, wether the design is grid based or not. By making sure that on upload images are automatically set to the right dimensions and 'scaled' alternatives are present, one no longer has to worry about 1900px wide images popping up inside 960px websites.
Media Queries & Filetype restrictions.
By having fixed imagesizes one could combine these with Mediaqueries aswell. By utilizing a standard naming scheme imagename.size.ext and a few lines of code one could make sure that when browsing on a mobile phone funpicture.small.png is loaded instead of funpicture.normal.png and that way ensuring that a 2Mb 2600px isn't html scaled down to 300px simple because an end user isn't a html expert.
When an 'album' is set to not store the different image-sizes in seperate physical files, image scaling should be done server side and not client-side by adding a ?size= attribute to the image. There are .NET libraries and opensource-code available to do this on the server. Although this will add some overhead on the server, the download benefits outweigh this tremendously.
If a designer/editor still wishes to override the predefined image-sizes, he can still force it through hardcoding the width/height inside the html but 700px scaled to 610px is always better than having to download 2600px and html-scaling that to 610px.
Image pointers vs physical files.
As said before, when browsing from an 'album' to an item, one should arrive at a detailpage where the pointer is displayed with below the several physical items. All the semantic information is stored with the pointer image like alt text, description, figure caption etc, while the physical files are mere size alternatives of that pointer image.
When using the image widget or RadEditor image, one always selects (through the album) an image and a size. Through the fluent API all the necessary image information can be retrieved independent of the filesize alternative displayed.
Media library [html5 audio/video]
As mentioned before, since we tie all the related data to the pointer, we would only have to set description/alt/fallback text and placeholder image once.
And since an 'album' can store multiple content items, we can easily include the placeholder image for the video in the same album as the video.
Since we're trying to be complete the pointer should also have a link to a caption item. Currently .srt is widely used although WebVTT has been proposed, but that's more of a player issue than storing a link problem.
Combined upload restriction.
Since media items are 'pointers' we're able to be more flexible with them and instead of having a singular restriction (as with images) regarding filetype/filesize we should have a combined restriction for html5 video. Meaning: for every filetype of contenttype 'video' one should be able to have a different file-size.
Some browsers are capable of displaying .ogv, others .mp4 and others require .webm, but as with images, when viewing in a mobile browser we should have the option to load a 'low bandwith' source instead of the full 720dp version.
Possible implementation: Actually the other way around as mentioned above.
For each 'filesize' restriction a user should be able to upload a file of the allowed 'file-type'. So if there were 2 filesizes defined 'Mobile' and 'HD' and 3 file formats were allowed (webm, ogv & mp4) we'd have the combination of Filename.Mobile.webm, Filename.Mobile.ogv, Filename.Mobile.mp4 and the Filename.HD.webm, Filename.HD.ogv Filename.HD.mp4.
When the uploading a image-file you simply 'hide' the alternative filetype versions from the user and leave the references to the pointer empty.
The player widget.
I'm sure somewhere inside Telerik's RadTools Team someone's already working on a Telerik version of jPlayer to allow for a skinnable html5 enabled player. As a widget, one simply would select the desired playlist or direct file and be done... There should be a fallback option to Silverlight but the main player widget should be fully HTML5.
I can't imagine Telerik sticking to the Silverlight player, but just in case I'd like to point out that Windows 8's integrated IE10 (the cool one integrated in the Metro style) won't accept plugins, not even Silverlight.