Next Product up: FC.ImageSearchResults

Right on the heels of our FC.MetadataExtractor 2.0 release shortly before Christmas we're working hard on getting a fun product out the door: FC.ImageSearchResults. It'll probably be another couple of weeks before we hit beta 1, but I thought I should already mention it here.
 
All the metadata that can be unleashed by the FC.MetadataExtractor product will be available to search on if the FC.ImageSearchResults solution is installed. And what's best, the solution comes with a custom searchresult page that displays those images nicely with thumbnails and metadata that makes sense for images. I'll blog more about this as we get closer to the public beta release.
 
As always with our product efforts we're aiming to support both MOSS (the commercial product) as well as WSS 3. This time I am especially happy to tell that there will also be support for a free version of SharePoint: while search in WSS 3 simply sucks, the Search Server Express 2008 (SSX) product (that simply can be installed "over" an existing WSS 3 installation) has all the bells and whistles to serve as the basis for our search solution.
 
If you run WSS 3 and haven't looked at SSX yet ...I highly recommend you do so ASAP!
 
The object model of the libraries that get installed with the SSX "upgrade" for WSS 3 have everything we need for our solution. Even the Search user interface that is added to the Central Administration is quite nice. However, there was one thing that was missing: a link to the page to manage the so-called "Shared Scopes". Our solution installs a Share Scope called "All Images" that allows to search across the entire farm and while we do that programmatically we of course prefer it to be visible to the administrator, so what is installed is transparent.
 
Well, the respective admin page for managing the scopes is actually installed. Just the link is missing. So you can get to that page simply using this link:
 
http://<server name>:<central admin port>/ssp/admin/_layouts/viewscopesssp.aspx?mode=ssp
 
View Scopes

Published: Jan-16-10 | 0 Comments | Link to this post

SharePoint DAM: Versioning Metadata

As we've just released the 2.0 version of our FC.MetadataExtractor product I thought I should catch up with some blog postings on DAM functionality in SharePoint.
 
One of the great things that come with SharePoint 2007 and WSS 3 is that you can keep track not only of the different versions of an image but also of its metadata. This is extremely helpful as entering metadata in a corporate environment is usually done over multiple rounds and maybe even involves several contributors.
 
All you need to do to activate versioning of metadata is to enable Versioning in the Site Settings:
 
Versioning Metadata
 
Once that is enabled you can either create a new version by uploading a new version of the image which includes new metadata, or by editing the metadata directly in SharePoint.
 
The Version history is now available via the item's context menu and the metadata trail can be seen in the screenshot below:
 
Versioned Metadata
 
This is just one example of the great base-level functionality SharePoint 2007 / WSS 3 include that can be applied in many scenarios, but is especially useful for metadata-heavy applications like DAM.

Published: Dec-23-09 | 0 Comments | Link to this post

FC.MetadataExtractor 2.0 Launch

It's been quite a busy time lately, as we were zeroing in on the 2.0 release of our FC.MetadataExtractor solution, and I have to say that the good old 80/20 rule certainly still applies (the last 20% of the work takes 80% of the time).
 
Just to give a quick overview: The FC. MetadataExtractor reads metadata from images - either on upload, or triggered manually - and stores it in the Sharepoint columns.
 
As the SharePoint custom document parser interface turned out to not be available for the main image formats we had to use Event Receivers. However, those also turned out to be quite inadequate, e.g. as the ItemUpdated receiver is asynchronous and interferes with the EditForm that comes up when someone uploads a single image. Hristo Pavlov had a good suggestion on how to solve that one problem, but it still leaves a lot of questions on how to wrap all this customization into a single feature, which is to be installed.
 
And beyond that there were many more individual problems attached to the different ways to upload or move images to a SharePoint library. Some of them are related to IIS and SharePoint settings in general, like for uploading large image files. I'll do a separate post on this once we're through with the release.
 
At this point I also want to thank our beta testers. They are still the best source of inspiration and guidance!!

Published: Dec-11-09 | 0 Comments | Link to this post

ChangedProperties Property - Documentation Error

We're getting ready to ship the 2.0 version of our "Metadata Extractor" product that extracts metadata out of images and copies it into the list columns. One of the cool new features is that it also extracts the metadata when a new version of a file is uploaded (previously it only did that on the initial upload, which was hard enough, given the problems around the asynchronous ItemAdded eventhandler ...but that's another story ;-).
 
The best way to check what exactly has been changed on an item is to use the ItemUpdating and ItemUpdated events. However when we looked into storing information that was available in the ItemUpdating event that occurs first, so that we could access it in the ItemUpdated afterwards we were a bit confused about the documentation, especially the meaning and usage of the ChangedProperties property. MSDN states that it "gets properties that have changed". Well, not only is that as minimalistic as can be, but also simply wrong:
 
The ChangedProperties property can actually be used to store values from the ItemUpdating event to access them in the following ItemUpdated eventhandler.
 
Example:
If you add the following statement in your ItemUpdating eventhandler:
properties.AfterProperties.ChangedProperties.Add("FILEVERSION", item.File.Versions.Count.ToString());
...then you can access this value in the ItemUpdated eventhandler via:
string previousVersionNumber = properties.AfterProperties["FILEVERSION"].ToString();
Btw, if you step through your code you'll see that the key/value pair is actually being added to the ChangedProperties property. SharePoint then copies it over to the AfterProperties collection before the ItemUpdated eventhandler is invoked.
 

Published: Nov-15-09 | 0 Comments | Link to this post

Custom List Forms with Code-behind

There are a lot of articles on the web about manually modifying the list forms and the ListFormWebPart in particular, but there isn't that much information about modifying these forms programmatically, and the problems that come with that.
 
To start with, there's a great article on SharePoint List Forms by Hristo Pavlov that I highly recommend.
 
Customizing the ListFormWebPart is a chapter by itself, but what we needed was to customize the EditForm.aspx. Actually, we needed to inject a control that would prevent the form to come up while the asynchronous "ItemAdded" event, triggered by a file upload to the library, was still busy retrieving metadata (also an adventure in itself, as I consider that clearly a conceptual bug in SharePoint), which would result in an exception and a failure of the upload and/or the metadata extraction.
 
Now, there are actually two levels of forms one could utilize: each list/library has a set of these forms (New, Display, Edit) and the content types that are associated with the list/library also have these forms.
 
We chose to replace the EditForm.aspx of the document-type content types with a custom aspx form with code-behind. Why code-behind? Well, there are actually a couple of things one needs to adjust on the fly to make this work. One example would be that a custom application page should reside in the "_layouts/" space and the default.master masterpage that is used by the list forms is not directly accessible from there. But the most important reason was that the ListFormWebPart requires the "ListName" (it's actually the Guid ID of the list) and the "ListItemId" (which is what it sounds like :-) to be set properly when the OnInit event fires.
 
ListName&ListItemId
 
So, where's the problem? The ListFormWebPart is an incredibly flexible piece of programming art that can render itself on the fly automatically, depending on what list, content type and columns are to be displayed, BUT it does not retrieve the ListName and ListItemId from the Page.REQUEST automatically. Alright, we can do that with the code-behind, but that's NOT the problem ;-) The problem is that the control isn't available during the OnPreInit event to set these properties, and before the OnInit event handler gets fired SharePoint already throws an exception stating that no item could be found for the list and itemId specified ...Duhh!
 
Well, the solution is actually (as most things in life) trivial: the OnInit event fires on the controls before it fires for the page. Therefore it is important to add a code-behind event handler not only at the page level but also for the Web Part itself:
 
WebPart OnInit event handler registration
 
And the rather simple code-behind for this looks like this:
 
        protected void Lfwp_OnInit(object sender, EventArgs e)
        {
            string listId = Page.Request.QueryString["List"];
            string itemId = Page.Request.QueryString["ID"];

            ListFormWebPart lfwp = (ListFormWebPart)sender;
            lfwp.ListName = listId;
            lfwp.ListItemId = Convert.ToInt32(itemId);
        }

 
The beauty of this solution is that the same custom EditForm.aspx can then be used not only for all Picture Libraries, but also for Document Libraries.

Published: Oct-12-09 | 8 Comments | Link to this post

Joe Bachana on the latest DAM Trends

Joe Bachana shares his viewpoint on the latest trends of the DAM market. It's a great presentation with concise details. Absolutely worth reading.
 
Joe has been in the DAM industry pretty much since its inception and he has a wealth of hands-on experience with many DAM products.
 
Here's the link to his blog also, which is focused on Publishing in general.

Published: Jun-03-09 | 0 Comments | Link to this post

Guidelines for Handling Image Metadata

Determining the right taxonomy and picking the right standards to store metadata has long been a challenge for DAM users.
 
But there's hope! The Metadata Working Group - consisting of heavyweights like Adobe, Apple, Microsoft, Canon and Sony - recently wrapped up a first major draft of their Guidelines for Handling Image Metadata.
 
So, if you're still bedazzled about what to do about tagging and categorizing your images, there's a document for you to read!
 
If you're in the L.A. area on November 10-11, you might also want to attend the annual Henry Stewart DAM event. Andrew Salop, a world expert on XMP metadata, will be discussing these guidelines.

Published: Nov-05-08 | 0 Comments | Link to this post

The DAM Vendor List

Not sure what DAM vendors are out there, and what they really offer?
 
Capterra.com offers a comprehensive list of DAM vendors. Many of the entries provide bullet points on what they offer (click on "more").

Published: Nov-05-08 | 0 Comments | Link to this post

The State of Digital Asset Management

Over the last days I've thought about my first post on Digital Asset Management (DAM) - and then along comes Theresa Regli from CMS Watch and states it for me ;-)
 
Let me quote a couple of important points she made:
 
"Lack of real asset workflow solutions. Compared to the other technologies we cover at CMS Watch, DAM systems have comparably weak workflow capabilities. Many DAM processes are complex, and many asset managers have required third-party tools to create truly automated workflows."
 
Well, it's actually quite embarrassing for many DAM vendors, because it's been obvious for a couple of years now that the DAM customers need end-to-end workflows that deliver the end-product, be it a catalog or a video commercial.
 
"Increased need for enterprise system integration, DAM to Web content management systems in particular. Many asset managers wish to distribute products via the Web, and thus have a business need to merge those two technologies, making an easier bridge to cross. Therefore, many asset managers and industry veterans see the concept of the DAM system as the "single source of truth" as a bit antiquated because the repository needs to serve multiple platforms."
 
This too isn't really anything new. About 2 years ago, I wrote an article addressing the need for ECM and Portal integration in order for DAM to sustain its play. Since then, only a few vendors have been able to embrace the opportunity.
 
As an example on the positive side: take a look at the SharePoint integration ADAM recently delivered. They also have a strong BPM solution they've integrated with their product. Absolutely worth checking out!

Picture 

Published: Nov-05-08 | 0 Comments | Link to this post