A new media library

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.

Album restrictions.
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

Playlists.
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]
---

Upload restrictions.
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.

Image scaling.
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]
---

Audio/Video Pointers.
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.

Hi Jochem,

Thank you very much for all the suggestions. We need some more time to discuss them and share our comments with you. I will get back to you tomorrow.

Greetings,
Antoaneta
the Telerik team

Hi Jochem,

Thank you once again for the detailed post. Please, find my comments in green below.

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'.

This is currently supported - you can use the Documents & Files section where all types of files can be added.

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'.

We will discuss this internally and will consider adding such options in the future.

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.

What we can do is to add another view and to allow users to decide how they want Images, Videos etc to be displayed. I absolutely agree that in some cases is more important to see items organized by libraries.

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.

This is planned but I cannot tell when we will be ready with this improvement.

Album restrictions.
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.

Very interesting suggestion, I will forward it to our UX team.

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.

The type of view can be selected by the user - you can choose to see items in grid or by thumbnails.

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

This will be really hard to achieve with the current interface and will be also inconsistent to the other parts of the system. I will forward this request to our UX team to think in more details about this feature.

Playlists.
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.

This is added in PITS as a feature request with ID 8080

All other comments and suggestions for Media library [images] and Media library [html5 audio/video]
will be forwarded for internal discussion with more people involved.

2000 Telerik points are added to your account.

Greetings,
Antoaneta
the Telerik team

Hi Antoaneta,

Thanks for taking the time to plough through it and I'm grateful for the many points. When I'm bug hunting I'll gladly accept them but suggestions, to me at least, are to make my life as a SF dev/var easier. So I guess we benefit both from them no? 

Album restrictions.
Well that's one thing I really miss from eMagiC, having the restrictions on the library to ensure proper image width/height is set and to be ensured that we've got a thumbnail and a large image automatically present. Filestorage is cheap so would love to see this feature in Sitefinity also, even if it were just a thumb and a normal version. 

With just those two (taking a 960px/16col design) you could set normal to 8col and thumb to 2col and scale 50% for the 4col and 1col version which is way more efficient than the current scaling.


Playlist widget.
Great! Thanks! Hope to see it get voted up alot and somehow the community will embrace xml-datasource as a 'defacto' jQuery widget standard.


Album items should be 'pointers'.
I understand I was talking about a complete overhaul, but it is not an inconsitency with regards to the current Sitefinity system. Its a lot of work but I believe it is necessary to offer an easy end user experience and a yet still offer a flexible but consistent and standardized system. 

Not to be negative but the functionality the current image/video library offers is a little behind. The uprising of mobile and the new HTML5 standard and its capabilities calls for flexibility. 'Content' no longer constitutes a single physical file. And although progression is good, it doesn't necessarily makes my life (as a developer) any easier. So we're both in a tough spot...

Whether we call it 'pointers' or 'facade' or something else, it doesn't really matter but its the best solution there is, let me give you 1 example with 3 alternative approaches. 

Imagine a HTML5 video widget (in the form of rendered HTML5):

Ima jump in here and say the video library in general needs the most work...seems "tacked on" with as few features as possible.

1) More supported formats
2) Scheduled task system should be able to kick off in the background and convert the videos to other formats for us to be consumed by the video tag...this should be configurable on a library by library basis.  Alfresco does something like this where you create rules on content spaces to do things when something new is added...uses a java workflow engine like WF4.

Hello Jochem, Steve,

@Jochem: We are always looking for feedback and comments from our customers. We hardly rely on this feedback because we want to make you happy, to make your life easier. That is why we are constantly listening what you guys are saying and what your needs are. I realize sometimes we are not reacting quickly and we do our best to improve this.
Your two posts related to media library suggestions are priceless for which I am thanking you once again. We will use your feedback when we discuss, plan and design the improvements so your comments will be definitely taken in mind.

@ Steve: Thanks for the additions. I will add them in my list with desired features and improvements and when we start working on this they will be discussed and most probably included.

Kind regards,
Antoaneta
the Telerik team

Beep beep: http://www.iis.net/download/TransformManager

Integrate with this please :)

Library security still seems to be a pain in the (well you know where)

To me it seems that the library security works like page security in old days.
Create a group A and user A
Create a library and grant this library access for group A

In order for group A to see the libraries you have to grant them access to libraries. Now they will see ALL Libraries and not only the once they have been granted acces for.

So in order to restirct them from other libraries you have to break inheritance on all existing libraries and remove group A.

If you create a new Library you have to remember to remove Group A

Hope you understand
Hope I am correct

markus

Hi Markus,

Yes, this is how it works for now. We realize how complex this is and we are working internally on improvements. Anyway, nothing is scheduled or planned to be released soon.

Greetings,
Antoaneta
the Telerik team