Archive for March, 2011

WCM project Lifecycle : Sign-off’s?

Thursday, March 24th, 2011

Each and every project has milestones and one of the important milestone is the sign-off of various artifacts including site designs, wireframes, functional specification, HTML mock-ups, content etc. With the WCM projects, my exeprience of sign-off is just a formality but in reality it doesn’t hold any vlaue. And the reason: changes and more changes after sign-off.

Normally when the design and wireframes are laid down, there is just specific group comprises of few individuals from IT and business teams that will look at them and sign-off. Based on the designs and wireframes the HTML mock-up originates and again in most of the cases the same approval authority sign off without getting into much details.The mock-up are presented to the development team who start to churn out templates and components and setting up website to deliver content. Once the development has passed a reasonable phase, someone in the approval team suddenly come up with a novel idea of presenting this new webiste within the higher authorities. And this very novel idea presents highter authorities with their first view of the site. This is the very first time they start inputting their feedback and the whole ball game of sign-off, CRs start. This sometimes is so drastic that teams go back to the drawing boards and start implementing new designs.

Content sign-off is a very different story with CMS projects where customers always take a view that the whole idea of implementing a CMS is that they can make changes nth minute before the launch of the website.

Also, when the mock-ups are signed off, there is a need for technical review of the code. It is pretty easy for the creative agencies to place lots of images and make them as part of CSS which are non editable by authors. I think it is important to have certain more activities on the plan to cover some of the above issues including:

  • Technical Verification of HTML mock-up to make sure that editable/ dynamic area’s/ extensible area’s are not goverend through CSS/JS hardcoding
  • Presentation of HTML mock-up to all the stake holders to identify gaps earlier than later
  • Involvement of high level management in each stages of the project, including design sign-off, HTML mock-up sign-off etc.
  • etc.

If the issues are raised during development or in UAT, it involves lot more effort than getting it right in the initial stages.

Anyone experienced such situations in their WCM project lifecycle?

Discussion:Adobe’s Day CQ : Separation of content from components

Sunday, March 20th, 2011

Few days back I posted some information around Day’s CQ Separation of Content from Components. There was some good discussion around the topic in one of the CQ group. Here is information from group discussion:

From Paul McMahon, Acquity Group

I think this is a common mis-perception – that because a component defines both content and presentation that the content and presentation are somehow linked.

Yes the component does have presentation logic associated to it, but the content is stored without the presentation, as raw content. This means that that content can be reused in many places without calling on the presentation of the component that was used to create the content.

So let’s take you restaurant example. You might define a restaurant component, which would include all the attributes of a restaurant in it’s dialog, and provide the presentation for a restaurant detail page.

Now lets say you want to have a restaurant listing component. This components content would be limited to say title and column headings for example. In the code of you component you execute a search on the repository looking for all nodes where sling:resourceType = yourrestuarantComponent. This search returns all the nodes where restaurant details were entered. You iterate over this nodes, grab the content you want to display and you display it in the presentation layer you need for the listing page. No duplication of content and you retain the ability to edit the content in it’s natural home within the site.

Now that said I often create the sort of plain jane content entry components and templates you are describing when dealing with content that has no natural home, but that is more about content organization and business process than it is about separation of content and presentation layer.

You can also use the scaffolding mechanism to achieve similar results, but in a different manner.

(more…)

Adobe’s Day CQ : Separation of content from components

Tuesday, March 15th, 2011

I am almost two impelementation’s old with Day’s CQ WEM. When I started with CQ product, one thing which kept me guessing within CQ was the separation of content from presentation.

As per my understanding of CQ, a component is the one which holds data, dialogs to capture information and presenting the information. One of the ground rule for a CMS system is separation of content from presentation but its initial usage looks to voilate this rule. If the same content is presented in three different formats, it is pretty common in CQ to end up adding the same content three times through different components usage. And if the site is pretty huge, I can easily image the content getting out of sync soon within the same site, not even accounting for any external interfaces.

No doubt, CQ is pretty powerful and its underlying architecture can allow you to do almost everything, along with its paragraph system. For our implementations, we followed an approach as described below. I am sure this is nothing new but I never saw such information on sites, so I thought of putting togather this post. In order to achieve separation of content from presentation, we defined three different categories of components:

Data Components: These are data buckets which holds data without any presentation logic built into them. It presents user with a dialog box along with various tabs to capture information.

Presentation Components: These are components which extract information from data components and display the content in the desired format.

Common components: There are common set of properties defined to capture common assets information either as part of data component or presentation component.

Let me try to explain with an example:

Requirement:
Suppose there is a need to build a website for hospitality group which has number of restaurants scattered across the globe. These restaurants are logically grouped into regions, for example, Asian, European, American etc. As part of restaurant, there is a need to capture information including: Name of the restaurant, Location, Region, image of the restaurant, Description of the place, Opening hours, facilities etc. The information for restaurants are displayed on various pages, on the restaurants home page, maps pages, regional pages etc.

(more…)

Hiding sites from Seach Result

Sunday, March 13th, 2011

Recently, google released another way to help you personalize the results, by blocking the sites you don’t want to see. This is another angle Google introduced around CEM (Customer Experience Management) giving more control on the hands of end user.

Here is an extract from Google’s blog:

You’ve probably had the experience where you’ve clicked a result and it wasn’t quite what you were looking for. Many times you’ll head right back to Google. Perhaps the result just wasn’t quite right, but sometimes you may dislike the site in general, whether it’s offensive, pornographic or of generally low quality. For times like these, you’ll start seeing a new option to block particular domains from your future search results. Now when you click a result and then return to Google, you’ll find a new link next to “Cached” that reads “Block all example.com results.”

Hide sites to find more of what you want

Hide sites to find more of what you want

This feature makes your quality of content all the more important because once the user has blocked site in search results it will be tough to get the users back. On the face of it the feature sounds pretty exciting but it will limit the users of quailty content and management of block sites will later, if not sooner, will become a burden and tools around managing the same.

HTML Mock-up guidelines from CMS Vendors?

Thursday, March 10th, 2011

With the develpment in CMS area, there is all the more push in the market for websites to move to a CMS system, large or small, to manage their content. As a result there are lots of new initiatives for grounds-up CMS implementation.

Usually, a CMS product starts with HTML a set of HTML mock-ups which defines how the site will look like along with specifying the static and dynamic regions on the page. By static, I mean area’s which are not editable by authors/editors and usually controlled by CSS. By Dynamic, I mean, authors/editors can go in CMS system and change content for these areas. Dynamic area could be anything, plan text, images, links etc.

The CMS developers take HTML mock-up as input, define content types based on defined dynamic area’s (and obvously functional specifications) and convert the HTML into CMS templates and content holes. The above approach sounds all straight forward but still there are soo many projects which fails/get delayed. And one of the reasons is HTML mock-ups.

Usually in an enterprise environment, multiple vendors are involved in building a website, from creative agencies, to implmentation partners to hosting partners. In most of the cases the creative agencies which develop HTML mock-ups who has no clue around how the HTML mock-up is going to be fitted in a WCM in terms of templates/ components/ elements etc. They try to make website flashy, attractive without really worrying around its maintenance. Some of the examples are:

  • Using images everywhere in the site goverened by CSS than HMTL
  • Same block of content using different HTML structure on different pages though the look and feel is the same
  • Hard coded height width dimensions for image tags
  • Too many variations in layout, which in reality could fit in just a few
  • etc.

Even if the HTML mock-up is developed to the best of practices, its usage varies with each CMS. An example, there is a style defined globally which is applicable to all the divs in centre portion of a page. Some CMS systems add their own divs when elements/components are dragged on the centre part. This leads to style issues for the centre portion and we spend lot of time negating those effects.

I think its time for CMS vendors to move forward and lay down best practices, guidelines that needs to be followed when developing HTML mock-up for their product. This could definitely makes easy for creative agencies and implementors to get it right the first time than really spending time on HTML structures just because the choosen CMS doesn’t like the way HTML mock-up is designed. It will really going to reduce overall project cost and project failures.

IE6 Countdown: Right time for Browser Standards

Sunday, March 6th, 2011

Its good to see world is ready to move on from Internet Explorer 6. Here is a snippet from IE6 count down site:

10 years ago a browser was born. Its name was Internet Explorer 6.
Now that we’re in 2011, in an era of modern web standards, it’s time to say goodbye.

This website is dedicated to watching Internet Explorer 6 usage drop to less than 1% worldwide, so more websites can choose to drop support for Internet Explorer 6, saving hours of work for web

Internet Explorer 6 usage around the world

Internet Explorer 6 usage around the world

As per my previous post Write Once, use everywhere? Content Vs Code, I think it’s perfect timing to get some standards defined around web browsers.

For corporates, its time to move on and this move is definitely going to give great boost on Intranet front, presenting more opportunities and opening new doors.

Write Once, use everywhere? Content Vs Code

Saturday, March 5th, 2011

One of the thumb rule for any CMS system is:

Have just one instance of the content and define templates/components/modules/elements to render it differently

So, Why the same rule doesn’t apply for code written to define styles, javascript functionality across browsers?

Let me take an example from one of my recent project: As per requirements, we need to support IE (6,7,8), Forefox (3.x), Safari (3.x), Opera (9.x). The HTML mock-ups are generated by one of the creative agency who are in the market for good number of years and know their stuff. SO, just analysing the HTML mock-up, total HTML/CSS/JS size is around 1.9 MB (exclding images). Out of which the CSS/JS specifically for handling cross borwser issues is 0.06 MB which roughly forms 3.5% of the total code set. And such
percentage of cross browser hacking code is present on most of the website.

Below are some of the issues from different perspectives:

Development Perspective

  • Analyse browsers which the site needs to support for previous web analytics or such tools
  • Define graphics which could work across browsers
  • Develop mock-ups with this extra code to hack site working across browsers
  • Testing effort across browsers. Most of the times the UAT error log will have such issues in good percentages
  • More development effort, hence more cost to the project

(more…)