A 5-yr Insight to Sitecore Partnership

Yes, it’s been 5 years.  I still remember the day when I first looked at Sitecore in our previous office.  It was for a prospect that wanted a CMS.  During that time, the CMS market was dominated by Interwoven, Stellent, MS CMS, Documentum, Sharepoint and Vignette.  None of those fit my criteria:

• .NET-based
• Less than $20k
• Open-architecture
• Strict separation of content from presentation
• Visual Studio-friendly

So, I started looking deeper in the market and found Sitecore.  At that time, Sitecore USA just opened its doors in California.  We didn’t get the prospect but I saw such potential in the technology that I decided to go for training and become a partner.  Needless to say, we became one and I couldn’t be happier with my decision.  Here is our 5-yr timeline with respect to Sitecore:

Year One (2005)

becomes a Sitecore Certified Partner with 1 developer using Sitecore v4 trained internal developers on Sitecore v4 signed our first Sitecore customer ended up with 4 Sitecore customers integrated Sitecore with AS/400 and JD Edwards thru a SOA middle-tier

Year Two (2006)

developed a mySQL data provider before it became available developed a Sitecore-generated site scraper to LAMP-friendly site full AD integration complete with biographies and documents more than 12 implementations by this time (including v5.1 and v5.2) real-time integration for up-to-date scoring

Year Three (2007)

iMIS integration Community Server integration TIMSS (Personify) integration multi-language with fallback implementation Omniture analytics integration multiple v5.3 implementations and upgrades embraced the “partner for partners” philosophy

Year Four (2008)

more v5.3 implementations integration with iMIS for more detailed information on events, members, and others migrated several sites to Sitecore single-sign on with membership system, Sitecore, and Community Server several Sitecore architectural consulting

Year Five (2009)

SaaS integrations such as Google Maps, calendars and events, and others several v6 implementations and upgrades one of the first OMS certified partners multiple Sitecore Foundry v2 and v3 implementations 2 case studies performed by Sitecore for the government and faith-based markets

It’s already the 2nd quarter of 2010 and yes we’ve already done some special things this year such as hosting Sitecore training, more OMS certifications, additional Foundry implementations, and recognized as one of the Outstanding CMS Projects.  After attending Dreamcore, we have a renewed excitement towards what Sitecore is doing.  I’d like to be able to update this blog post and let you know what we’ve done again.  With the upcoming release Sitecore and OMS, Intranet Portal, and Foundry, we’re sure to make more history.

Porting Legacy Web Apps to Sitecore Quickly

Have you ever had a client request where they’d like to have any of their Web apps to be ported over to Sitecore?  And, why not, it looks like Windows and it’s .NET, it can’t be that hard.  Well it can be easy and it can be hard depending on what level you want to port the application.  For this post, we just want to see the legacy app in the Sitecore Shell.  Sometimes, that’s all is needed since the Web app already works pretty well.  Plus, it just looks cooler when your app is within Sitecore.

So, to show the app within Sitecore, we just need to create a Start menu item that invokes the remote Web app.  Let’s start.

Power up Sitecore and login.  Click on the Sitecore “start” button > All Applications > Sitecore on the Net > Sitecore Homepage.  That’s just the Sitecore corporate site.  I’m guessing you’re following what I’m getting at.  You can easily encapsulate (frame) any Web apps that you have created. This is really important because Sitecore let’s you incorporate legacy Web applications especially when it takes a while to port a complex application.  This gives your CMS users a way to access the legacy app through the Sitecore shell provided that the app doesn’t interfere with Sitecore’s windowing mechanism.  There might even be a way to pass data from Sitecore to the app through the URL because that’s essentially how the Web app is invoked.

You can quickly do this by going to the Core DB.  Open the Content Editor and go under Documents and Settings. Traverse the nested folders until you get to Programs.  Inside Programs, you can create a Start menu folder, or the “shortcut” that invokes your legacy Web application.  To create the “shortcut”, which is really a Start menu action, select it from the Insert ribbon.  The most important piece of data you need to assign is under the Message field.  Enter:

RunExternal(\"<URL>", \"\", \"Software/32x32/application.png\", \"<WINDOW TITLE>\")

where <URL> is the Web address to your Web application, <WINDOW TITLE> is the title that is shown on the Sitecore window that appears.  You can also change the icon that appears on the window if you’d like.  Just make it the same icon that you specify in the Icon field of the menu item.

To see the new menu item, refresh the Shell or switch to the Master DB (which refreshes the Shell), and notice that you’ll find your new menu item in the Start menu.  Clicking this item should invoke your remote legacy Web application.

This is the quickest way. Obviously, you can’t do much with this since the Sitecore and the app are not really integrated.  There is only one way communication, if even any from the URL.  But, you can actually use Sitecore’s security to restrict access to the Start menu item, thus making it seemingly secured  Of course, you still have to keep the app secured somehow but at least there’s another level of security that can be used on top of the Web app itself.

There are other two ways to port apps into Sitecore.  With moderate complexity, you can use Sitecore as the app’s data storage.  This means that you’ll have to figure out how to port DB tables to templates (which is pretty simple since that’s how they initially taught us during Sitecore training to explain the concepts).  You can still just use straight ASP.NET controls to do your UI and just use Sitecore APIs to update those related Sitecore items.  I actually created one like this that essentially converted the ASP.NET generated site into PHP files and published the site to Linux with Apache complete with uploaded images, etc.

The most complex way is basically creating a XAML app.  That’s essentially how the native Sitecore apps you see now are developed such as Content Editor, Workbox, etc.  This has been the case since v5 so I’m not sure now how compatible Sitecore’s XAML with the Windows Presentation Foundation (WPF) (Anyone from Sitecore???).  This way of porting the legacy Web apps benefit from the separation of UI from logic, which is what XAML was supposed to achieve.  XAML is intended to be device-independent.  This method is the most lightweight and you can use all the readily available Sitecore-specific XAML controls already created by Sitecore.  You also benefit from the UI’s performance techniques such as AJAX and others without thinking about them.

Anyway, I’ve given you 3 ways to port your legacy apps.  Sometimes it just as easy to port an app than to only integrate them especially when it requires administrative UI.  One of the main reasons that Sitecore is so powerful is its UI, so leverage that with your legacy apps and future ones.

Sitecore OMS vs. Sharepoint….hmmmm

I had an initial reaction from my VP of Marketing, Aaron Branson, regarding my take on Sharepoint as being great on audience-profiling, targeting, personalization, and workflow in my previous post.  Aaron says, “What about OMS?”, who, by the way, is one of the first OMS Certified Professionals.  I just want to quickly clear things up that I have not misspoke since I think that Sharepoint is good for these.  I never mentioned OMS because I wasn’t trying to make that connection.  Note: For the workflow feature, it’s more between Sitecore and Sharepoint.

Well, now I would like to make that connection.  The Online Marketing Suite (OMS) is an evolutionary product that changes how a CMS can display marketing-appropriate content to particular users.  Its foundation is its behavioral engine that allows it to analyze how to best show particular content and target the correct audience.  OMS is marketed as an analytics tool, which compared to Sharepoint’s audience targeting, personalization, and targeting is totally different.  How so, you ask?

Although both products may be using similar words/phrases to market their products, they actually have different purposes and basis on how they do it.  There’s a reason why the OMS product name has “Marketing” on it.

Audience Profiling
OMS Sitecore OMS profiles its users based on the visitor’s site behaviors.  The keyword is “behavior”.  I’m sure there’s a way to incorporate additional user information to fine-tune the profile but that’s when you know who the users are.  This means, OMS profiles anonymous users  to be able to deliver better contextual content.	Sharepoint Sharepoint profiles is based on “known” information about the user.  As I said before, it’s initial intent is for internal sites where users are in some database.  For Sharepoint, it’s the Active Directory (AD).  The AD contains organizational, demographic, departmental, and others that help content authors deliver appropriate content that pertains to them.
Targeting
OMS OMS targets based on its behavioral analysis of the user.  It does its analysis using tests such as classic multivariate and A/B splits.  Whichever combinations perform better, the marketer can fine-tune particular pages or areas of the page.  Targeting in OMS sense is meant more to improve conversion rates.	Sharepoint As mentioned before, Sharepoint uses stored known information about its visitor because they are logged in.  With this information, Sharepoint can target content appropriately.  For instance, a St. Louis picnic outing announcement will not likely show up for someone who lives in New York.
Personalization
OMS OMS’s personalization is a “push” from marketing.  It makes the site seemingly personalized to the user because of his/her site behavior.  For instance, if I visited a particular camera, I might see tile ads pertaining to that camera in the future (similar to the Nicam demo).  So, OMS personalizes the content for me instead of the other way around.	Sharepoint As a portal software, one of it’s strengths is giving the user control over what content he/she sees.  This is the basis for Sharepoint personalization.  Unlike OMS, it’s personalization is dictated by the user’s preferences and not necessarily by behavior.    Thus, the user “pulls” the content instead of marketing or whomever is “pushing” content.
Workflow
Sitecore Notice I changed this to Sitecore and not OMS.  The main thing to consider is the type of date stored in each of these systems.  For Sitecore, it’s primarily Web content.  The content goes through various department staff and reviews, approve, denies, or publishes them.  The primary “work” involved is reviewing the content.  Sitecore’s workflow mechanism is great for this.  It’s highly customizable and flexible to a point to where it’s possible to have Sharepoint-like workflow (not necessarily better, but has more out-of-the-box features).  We’ve done workflow where content actually goes out of the CMS into a preview server for outside approval.	Sharepoint Workflow in Sharepoint is a totally different monster.  It’s not just for reviews although in the end, that’s essentially what people do.  But, it’s more on the type of data that goes through workflow.  Basically, anything goes through its workflow such as (of course) simple Web content.  But, Web content is only one type of data it supports.  An organization can create workflow that adheres to its business processes and allows business users to collaborate on documents, although Sitecore can certainly be extended to do this. By the way, Sharepoint is essentially a host for Windows Workflow Foundation (WWF), thus making it pretty customizable and very powerful.

I’ve cited differences between OMS and Sharepoint (and with Sitecore as well) and the main concept to consider is that OMS is behavioral while Sharepoint fact-based (at least on these features).  I know each one can be retrofitted somehow, but out-of-the box this is what you have.  I hope this clears up any misnomers that I may have mentioned before in my previous post.

Sharepoint vs. Sitecore

This should really be: “When not to use a portal-centric solution.”  I’ve been asked before by a client/prospect why not use their internal Sharepoint implementation for their corporate site.  The simple answer is because it’s not meant to be.
I think that Sharepoint is a great product.  We even use it internally and it makes our internal processes go a lot smoother.  It helps us manage our documents.  It makes collaboration in our projects possible.  We are able to connect various business models into one system.  And, we can integrate it with other nifty Microsoft products we have access to as a Gold Certified Partner.  In brief, we love Sharepoint and I don’t know how we can manage our information without it.
With that said, it’s not always the best solution.  It can, however, be retrofitted to be a solution but that’s when more work is involved and thus not leveraging features that the product has.  When it comes to Sharepoint vs. Sitecore debate for external sites, there’s no sure winner…except when you know what the site is for. 
To me, Sharepoint is great for portal-based sites especially those that requires audience profiling and targeting, personalization, document management, and workflow.  But most sites don’t need this especially corporate sites.  So, why pay the licenses and the services to get it done?
On the other hand, Sitecore is great for content-based (instead of data) sites where the presentation is also a big deal.  Because of its “true” separation of content from presentation (where Sharepoint can’t really attest to), it allows for more control on the presentation.  Although Sharepoint can certainly be skinned, it’s not that straight-forward…remember using FrontPage at one point…and now Sharepoint Designer.
Here are my top reasons why Sharepoint is not the best solution for most external-facing Web sites:

• Licensing
  Sharepoint costs about $50k minimum to be used for external facing sites and that’s not including the Enterprise Search Server.  Compared to Sitecore’s entry point of $15k, Sharepoint is way too expensive. The main reason is because of MOSS for Internet Server (MOSSFIS) license which allows external anonymous users to access the site.  Hmmm…what if you want an extranet?  What would the licensing look like?  It’s just too complicated for this scenario.  Here’s a Sharepoint calculator if you’d like to see: http://community.bamboosolutions.com/blogs/sharepoint-price-calculator/default.aspx. UPDATE: See comments below for some discussion on this criteria.
  
• Developer vs. IT
  I think we can say that Sharepoint is enterprise-ready, but that' doesn’t mean Sitecore isn’t.  It’s just that the tools and how it’s deployed differs.  A lot of IT shops like Sharepoint because they can easily install it and maintain it.  Essentially, they have more “control”.  Sometimes, it’s a matter of politics.  But with politics aside, Sitecore CMS is geared more towards developers.  Sitecore really focused on making the software easy to customize and more open for complex functionalities…thus, more developer-friendly. I’m not sure what’s in store for Twin Peaks release, but I hope corporate can market it being more “IT-friendly”.  I think IT would like to to have inherent monitoring capabilities, backup tools, automatic updates, etc. 
  
• Development Environment
  We have several experience on developing on both platforms. As I said earlier, Sitecore is more developer-friendly and it starts with the development environment.  Essentially, Sitecore is just an ASP.NET application.  So if you know ASP.NET, you can develop using Sitecore.  I can’t easily say that for Sharepoint.  It’ll require more work.  Here’s a great blog on how to setup a Sharepoint environment (http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx).  Of course, this is just one of them but it should give you an idea.
  
• Deployment
  I guess this depends on perspective.  IT may say Sharepoint is easier to deploy than Sitecore because it has a set of instructions it needs to follow.  Remember, IT folks are not necessarily programmers, so they don’t like “exploratory” trial-and-error types of deployment.  To me, having deployed both, I say Sitecore is much easier to deploy the first time and follow-up updates to the production server(s).  The main thing is that you just need to have a very specific deployment process.  The only difference between Sitecore and Sharepoint is that Sharepoint created tools and written instructions, while Sitecore needs to have their partners define what’s appropriate for the client.  I think that you’ll agree that not every client has the same infrastructure, so allowing Sitecore partners to define it is a big plus.
  
• Content Separation
  Sharepoint markets itself having Content Management.  I can’t say that they are lying.  But, the only thing I can say is that they have a level of content management that can’t match up with Sitecore.  Sitecore has a true separation of content from presentation allowing for better content sharing and re-usability.  You can do that with Sharepoint but you actually have to really plan for it and if you don’t, you’re screwed.  Sharepoint’s CMS basically has the same concept as it did with MS CMS 2002…and where is that now?  Try creating a mobile or print-version of you Sharepoint-based pages…and let me know how easy that is…I can do that quickly in Sitecore.

What’s your take on Sharepoint compared to Sitecore?  Let us know. 

Upgrade to What?

We have a client who wants to upgrade their Sitecore site to the latest version.  Well, normally that’s a simple “Sure, we can do it” but it’s not.

The reason is that Sitecore sometimes releases a version that's not tagged “recommended”.  Sitecore will release a new version, even a totally new sub-version (6.1 or 6.2) but not call it recommended.  Then, they have the release notes of what changed, improved, and fixed. 

If I’m reading the release notes, I automatically gravitate to why not recommended those.  The changes seems to be great such as a much improved Content Editor.  I don’t know what Sitecore goes through to “recommend” a release.  But, it’s hard for me to recommend a non-recommended version. 

We try to get clients up to date with the releases but if it’s not recommended, we don’t recommend that version.  So, we upgrade to the recommended version only.  But, if the client finds out that there’s an issue with the recommended version that is resolved in later version, then we’re stuck hearing about it and eventually tell ‘em that we can upgrade them with the fix under warranty. 

As you can see, it becomes bad business since we have to do the extra work without getting paid. Maybe it’s just the way I need to form the contract.  Regardless of that, it’s still bad that additional work is needed later.

My main issue is that the non-recommended version number uses a mini-version number instead of the “revision” number.  If it’s a patch, then it’s a patch and just send out a patch package not a whole Sitecore instance.  I know that it may have warranted a new mini-version number because of the improvements, but I suggest that Sitecore separate fixes from improvements.  Fixes can have revisions, while improvements (with the fixes of course) as a mini-version number.

What’s your take?

I’m Back

Okay, it’s been a while (specifically almost a year) that I’ve written something on Sitecore.  Since the economy wasn’t too good last year (even now), I had to focus my efforts on ensuring my company is not affected much.  I needed to redirect my attention to growth and to do that is to have the right people in place.  I think I have that now.  I’m still going to be busy doing that, but I’ll put more time into my Sitecore blog.

This may be a year later but Sitecore’s Security UIs have remained the same, so I thought I pick it back up from where I last left off. 

There are five (5) security-related UI's in Sitecore (not counting the security tab/section on the Content Manager):

• Access Viewer
• User Manager
• Security Manager
• Role Manager
• Domain Manager

Sitecore’s Access Viewer is certainly much improved from previous versions.  It used to be somewhat confusing but with the context help/explanation on the right, it makes it easier to understand.  Notice also that you can now also see how workflow affects security.  It’s brilliant. 

FUTURE FEATURE: To make it better, it’d be nice to see how the security is inherited such as if this is from the template, or from a hierarchy, or combination.  This way, we can easily diagnose potential security issues.

Undocumented dtSearch Synopsis Trick

I've worked with dtSearch before on other projects and have used other ones since then. I'm currently working on a project that uses dtSearch as the primary search engine. There's always a synopsis for a search result and the dtSearch module actually provides a XSLT helper.

If you just want to know how to do it, then follow this quick steps:

1. Create an index in dtSearch using the Create Index(advanced) option.
2. In the Create Index(advanced) window, make sure to check "Cache document text in index" and/or "Cache documents in index". This tells the dtSearch indexer to keep a copy of the content that's being index.
3. Add a Sitecore setting in web.config named "dtSearchSynopsis" with the value "true".
4. Update your XSLT Rendering to get the content in the search result set that comes back from the Search function.

Now, if you want a more detailed explanation, read on.

The dtSearch XSLT Helper's GetSynopsisNavigator() method requires:

• pageUrl
• search term
• css highlighter style name
• length of the sysnopsis

The method uses the page Url so that it can access it able to extract the page's content. Then it truncates the content while making sure that the search term is in the synopsis. Finally, it looks for the search term and re-formats it between a tag with the specified css class name. And it returns the string. Of course, it does some other things also such as remove scripts, tags, etc. to give you a nice clean synopsis.

Well, sometimes it's clean. The problem with this approach is that the synopsis will always return almost the same set of synopsis when the search term is something that's found on the top part of the page such as your navigations, etc. For instance, if you have a site that has a ubiquitous utility bar with "Contact Us". So, this text phrase exists on every page. Now, if you search for the word "Contact", dtSearch will return basically all pages as the set of results and the synopsis for each will be very odd using GetSynopsisNavigator() and will always include the utility bar content even though those parts of the site are really skeletal pieces that should not be searched.

So, you might think that it's an issue with the indexer. Well, that's partly true. To let dtSearch index only particular parts of the page, you need to use the that is documented in SDN5 and at dtSearch's site. So, you basically put the comment markers appropriately and it will only index, say, the main body content of the page and not the footer text, headers, callouts, and other supporting/related content.

At this point, we've only solved that dtSearch should only index appropriate content so that it doesn't return "ALL" the pages. The next part is to get the synopsis corrected. Well, I accidentally found this out by going through the intermediate language for the dtSearch module. I read it through to figure out how it works. Then, I noticed that it's actually possible to generate synopsis as part of the result set as returned by the module's XSLT Helper Search() function.

To do so, you'll need to add an undocumented Sitecore setting for dtSearch named "dtSearchSynopsis" with the value "true". This tells the dtSearch module's XSLT Helper to add a tag in the result set that comes back from the Search() function. The synopsis automatically adds "<b>" around the search term. The synopsis looks pretty good and there are no truncated words because of the # of characters limit.

Sometimes you might get some odd results, so you just need to fine-tune where you place your comments. Make sure that the indexer is able to see the scID and scPath meta tags since the dtSearch module uses them to find items.

Well, that's it. I hope that helps.

Technical DeepDive: Sitecore v6 Security

First off, I want to announce that we just moved our offices to a much larger and spacious office space. I'm excited for our future and our potential. So, expect greater things from Roundedcube. If curious, you can find out more about our move.

So back to our main topic here. As I said from my welcome post, I'm going to have a technical perspective of Sitecore as well. For these types of posts, I'm going to envelop them into what I call a Technical DeepDive. During technical sales presentations, these types of presentations become very important for technical audiences who tend to evaluate a product based on technical details without the marketing wrapping. We're going to start with one of Sitecore v6's important changes, the use of .NET 2.0 security framework.

To read further, I need to tell you that this is not about ASP.NET 2.0 security mechanism but on how Sitecore leverages it and how it is applied. So, you'll need to know about ASP.NET security mechanism before you read on. There's a great introduction from MSDN with related articles for your reading.

In the past, Sitecore maintained its own version of a security context. As a developer, you need to remember that the ASP.NET security context is different from Sitecore's. So, there were three ways to work with Sitecore's security:

• use Sitecore's security context exclusively and integrating into Sitecore's extranet domain


• use ASP.NET security exclusively


• use both but making sure they are in synch

In Sitecore v6, both ASP.NET and Sitecore security context are the same...or I should say that Sitecore taps into ASP.NET's context instead of managing its own. However, this doesn't mean that Sitecore essentially is just ASP.NET. Sitecore only uses the provider model and uses the same context but Sitecore's context is much more powerful and what Sitecore does with it. Here's a list of things we'll discuss:

• New UI
• New Access Rights
• Inheritance
• Roles within Roles
• Enhanced Domain Management

On my next Technical DeepDive, we'll talk about the new security UI's.