EPiServer Falcon (CMS 7?) Seminar Feedback

I was lucky enough to get a seat at the EPiServer Falcon event in Stockholm and I thought I’d share my feedback directly here at EPiServer World.

Built in “Page Type Builder”

The biggest news for me is the ability to have an EPiServer standard way to define page types in code. Up until now Page Type Builder has been a de facto standard, but there are other alternatives as well. For example in Making Waves we have our own system called Making.Common (partly released as Open Waves in Codeplex)

It is definitely the right way forward for EPiServer and it is clear that this is a feature still under development. During and after the seminar there was many poignant questions that I think EPiServer need to address:

-How do I sync page types between development, staging and production?

-If the editors can edit the page types in the admin mode, how do I prevent it conflicting with future code updates?

-Is there an upgrade path from PTB? (I think EPiServer said they where thinking of this already)

Blocks aka Property Groups

I was very relieved when I saw that EPiServer have thought about the ability to group properties together. This has implications way beyond just grouping first name and last name properties together: it can be used for storing the data for custom properties (e.g. for storing the image url, description text and url for an EPiImage property) as well as for dynamic content.

But as a developer I often run in the following use case: The customer has a contact page and want to add a number of people. Each person has a name, email, phone number and picture. There are two common approaches to this:

1. Create the 4 properties directly on the contact page times the max number of people they can have on the page. So for 5 people we need to add 20 properties. Quite messy and inflexible.

2. The second approach is to create a page type called person where you have the 4 properties and then create a page for each person. You would then link the person pages with the contact page using a link collection.

Both of them has draw backs, and both feels like hacks even though this is something that is very basic.

So in the solution that EPiServer has proposed you could group the 4 properties into a single property. That makes it a little simpler, but you still would need to add 5 blocks to the contact page to handle 5 people. This is better, but not perfect.

My suggestion is to introduce a block list property that can take several items of a certain block type. That way I can add a single block list property to my contact page and it would show up in the edit UI as a list that can be drag and drop sorted, and where the editor can add/edit/delete people.

MVC Support

I think EPiServer has made the right decision to add MVC 3.0 support to Falcon, but also have full support for good ol’ WebForms. The way the handle routing looks very well thought out and I am glad my old friend FURL is still in there somewhere

New way to handle Add-Ons

I think the idea of having an “app store” for editors to add functionality to their site is at a first glance a good idea. A perfect example is Frederik Vig’s oEmbed plugin. It gives you an DynamicContent plugin that easily lets editors add YouTube videos, Flickr images, SlideShare slides etc. to their pages by simply copying and pasting the url to original item (the embed code is automatically created using oEmbed).

But you don’t have too look far before things start to break down (no pun intended). First of all the biggest danger is that the editor installs something that breaks the whole site! Secondly it has limits to what you can actually do with your plugin.

I do however like the idea of easy install and uninstall with dependency checks. Also a single resource for add-ons is nice. So all in all: I am a bit undecided about this new feature.

Please note that the EPiServer NuGet feed still will the main way for developers to get hold of their add-ons.

Localization support 

EPiServer is moving the lang files into resources and I think this is an excellent solution for all kinds of reasons:

-Clearer separation between EPiServer files and project files
-No overwriting of modified lang files when upgrading EPiServer
-Lang folder still available for your overriding EPiServer language settings and your own stuff
-Faster boot up after build (I hope)
-One system for all EPiServer products
-Provide based: I am itching to build a better language manager that editors can use. Stored in DDS maybe?

It is however harder to find where to override EPiServer language settings, so access to the source XML files is a must!

MAYBE: Query API

EPiServer also teased us with a few features that might or might not be added. One of them was Query API and the answer is: YES WE WANT THIS!

In fact I think that this should be a high priority for EPiServer. As of now I feel that we are to bound to the tree structure, and a simple LINQ query capability can help us build more advanced navigation structures.

Better File manager

OK, so EPiServer didn’t actually say anything about a better file manager, but they should have. I 100% agree with Karoline Klever that: “…EPiServer isn’t giving the File Manager any love.”

On top of my wishes for a new file manager is:
-Better search for finding files
-Better preview of images and videos
-Better meta data support
-Automatic image scaling (the service is already there!)
-More user friendly

Drag and drop upload of multiple files in ALL browsers

Ok, so they didn't mention that either. But it is embarrassing to tell clients that they need IE to upload multiple files. I mean: Even Microsoft has abandoned ActiveX

My suggestion is using Plupload from the same company who made TinyMCE to add this functionality to Falcon. It shouldn’t be to hard as Pluload handles all the hard stuff (Flash/HTML5/Silverlight).

Rumors

After the event there was also some lose rumors about the new edit mode. All I can say is that I am very excited to hear more about this, as this is one of the weak points of EPiServer when we look at some of the competition.

Thank you for listening!

Finally I must say that I impressed with how open EPiServer has been with this Falcon seminar and how they actively search for feedback. Smart move!

Looking forward to building my first customer project with the final version of Falcon!