+1-888-365-2779
Try Now
More in this section

Forums / Suggestions / A new media library

A new media library

9 posts, 0 answered
  1. Jochem Bökkers
    Jochem Bökkers avatar
    787 posts
    Registered:
    13 Aug 2007
    26 Sep 2011
    Link to this post
    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.

    J.
  2. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    29 Sep 2011
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  3. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    07 Oct 2011
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  4. Jochem Bökkers
    Jochem Bökkers avatar
    787 posts
    Registered:
    13 Aug 2007
    07 Oct 2011
    Link to this post
    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):

    <video controls>
        <source src=video-hi-res.mp4 type=‘video/mp4;   codecs="avc1.64001E, mp4a.40.2"’    media="(min-device-width: 800px)">
        <source src=video-lo-res.mp4 type=‘video/mp4;   codecs="avc1.42E01E, mp4a.40.2"’>
        <source src=video-hi-res.ogv type=‘video/ogg;   codecs="theora, vorbis"’            media="(min-device-width: 800px)">
        <source src=video-lo-res.ogv type=‘video/ogg;   codecs="theora, vorbis"’>
    </video>

    (And this is even a fairly simple example because officially we need to/can/should support .mp4, .m4v, .ogg, .ogv and .webm)

    Approach A - Taking a shortcut.
    You could limit the Sitefinity library to just support .webM and do not off flexibility with regards to hi-res/lo-res. This means basically just replacing .wmv with .webm.

    It's easy, can be implemented fast but it would mean walking away from HTML-standards. Next to that, this would mean you offer 1 video for every user experience, the same 15Mb video will be streamed to someone on a Hi-Def widescreen, a small laptop and a mobile phone. And lastly, Windows8's integrated IE10 will not support plug-ins, so none of the video's will be playable on a Metro Desktop since webM is a plugin for Internet Explorer.

    So although it's an easy fix, it is not a desirable one to achieve or claim 'html5 video support'.


    Approach B - The kiss principle. (aka how to not hug your end-users)
    Another approach would be to just support all the different file formats and upload each video as a media library file. Also not difficult to implement because it's just a file storage system and you'd have to extend the allowed filetypes.

    And while this is the Keep It Simple Stupid principle from a developers perspective, it puts the stress on the user. There would have to be build an extensive video widget where for each desired format a user has to pick a file from the library, select it's codec and write the media rule.

    And these steps would have to be repeated for each 'version' of the video you'd like to be able to serve. And if the user screws up and forgets to put the .mp4 files first, or mixes up file types and mime types, the system breaks. I get the call and Sitefinity gets the blame...

    This also requires the 'end user' to have more than a basic understanding of how HTML5 video works. 20 clicks and a 3 page manual to post a video on your page is not the Sitefinity way and I can't imagine the joy of putting a video playlist of 5 videos together this way.


    Approach C - Paving the way instead of leading it.
    A tech-savy editor creates a video in the library. He adds the caption, a poster image and a subtitle (would be fun if you'd allow localized based on FE languages ;) ). The video 'facade' has been created and then he enters the detail page. On there he uploads the different files and sets the appropiate codecs and media queries.

    When an author (novice end-user) creates a new page, he drags the video widget onto the page and clicks on edit. He browses to the video item, hits save and is done. 

    Now that's a smooth user experience. All the technical bits are already handled and no knowledge whatsoever is required. You allow the user to upload just one format, but if he's keen on cross-browser compatibility and cares for mobile users you still allow him the flexibility to do so. Instead of making decisions and limiting the system, the choice is his.

    And even if at the start, there's only webM, the tech-editors can progressively add more filetypes to the 'facade' without breaking or having to edit the widgets on every page. An average user will never look beyond the 'facade' but if he needs to, even as a non tech-savy contentmanager (s)he'd still be able to alter the description or the poster image.

    ---
    (I fully admit, I'm totally bias to approach C)
    ---

    It seems like it's a 'break' from the current system, but it isn't really. When a user creates a page, he's on the page overview. On there he sets titles/permissions etc. Once the facade has been set, you click on page edit and start working on the details. Compare pages in the overview to video items and a page edit to a video edit. 

    Or better yet, compare it to blogs. A blog is an video library. A blog entry is a video item and editing a blog entry is same as editing a video only instead of a wysiwyg editor, you're presented with the video details and their settings.

    To any average user, who works with Sitefinity this is a natural flow of the system because it is a natural flow. 

    ---
    For peeps who totally have no clue what this is all about but are interested in learning more about HTML5 video, Nigel Parker did a great session at Mix11 on html5 video and it's complexity to serve it well.
    ---
  5. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    07 Oct 2011
    Link to this post
    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.
  6. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    11 Oct 2011
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  7. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    23 May 2012
    Link to this post
    Beep beep: http://www.iis.net/download/TransformManager

    Integrate with this please :)
  8. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    24 May 2012
    Link to this post
    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
  9. Antoaneta
    Antoaneta avatar
    258 posts
    Registered:
    02 Nov 2015
    25 May 2012
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
9 posts, 0 answered