Mediagrif Interactive Technologies Inc. (TSX: MDF) has delivered innovative e-commerce solutions to businesses since 1996. Its web platforms enable clients to find, purchase and sell products, exchange information, gain access to business opportunities and manage supply chain collaboration with greater speed and efficiency. They provide e-commerce solutions in the fields of electronic components, computer equipment and telecommunications, medical equipment, automotive aftermarket, wine and spirits, diamonds and jewelry, classified ads, supply chain collaboration and government opportunities.
Mediagrif has been using Cascade CMS for over 5 years to provide both static and dynamic sites for their clients. We recently sat down with Ken Calder, Director of Software Development, to ask him about some of the interesting projects they’ve achieved using a combination of Cascade CMS features and custom technology that they’ve developed.
Read on to learn about how they’ve used Cascade CMS to
- Provide personalized web content based on visitor behavior,
- Display dynamic content from external databases alongside Cascade CMS managed content,
- Allow non-technical users to manage elements of configuration sets without actually touching the configuration sets themselves, and
- Manage multi-lingual sites.
We believe that Mediagrif has done some very innovative things with Cascade CMS, and we’re excited to share them with you here.
Static and Dynamic Implementation Q&A
Q: Tell us about the sites you manage for your clients in Cascade CMS.
Here’s a quick description of the two main categories of sites we manage in Cascade CMS:
- Static Sites: We publish complete JSP files onto a standard tomcat server with an apache web server in front (www.mediagrif.com)
- Dynamic Sites: In the case of dynamic sites, we use our application servers as the content delivery application, which gives us lots of flexibility.
When we publish from Cascade CMS, we are actually pushing our files onto one of our background application servers. Those files are then loaded into our application server’s database (we call that the “upload”). Then, each of the front-end servers (once per hour or else on demand) downloads the file from the database and puts it into its webapp folder (we call that the “sync”). This means we can have as many front-end servers as we want. For example, Hach.com has four, Brokerforum.com has eight, and all front-end servers sync at the same time, so we know that all our front-ends are in sync with each other.
Q: You mentioned that you use a combination of Cascade CMS content and includes to serve up chunks of text or html ads based on searches performed by your site visitors. How exactly do you personalize web content based on visitor's behavior?
We basically have two scenarios here:
In the first scenario, a page is managed in Cascade CMS, and then we use AJAX calls to get information from the server. For example, on the sign up page the whole of the page is in the CMS, but the form comes from the server.
In the second scenario the page is managed on the server and then we use JSP includes for sections of the page that are managed in Cascade CMS. For example, on https://www.hach.com/dr3900, the product detail information is all dynamic and managed on the server, but the links on the left-hand side as well as the verisign logo are managed in Cascade CMS.
These are two simple examples of how we use includes to personalize information on our clients’ sites.
Q: How do you pull in dynamic content from external databases alongside Cascade CMS managed content?
One example of pulling in dynamic content from external databases is on www.hach.com. We manage some product information inside Cascade CMS, while other information is maintained in an external database. We use the product ID tags (“SKU’s”) as the link between the CMS and the database when we need to call for information in the database.
To inject information about products into the CMS, we put these product tags into the WYSIWYG. Then at upload time, we translate them into JSP so they get interpreted at runtime by the application server.
Product Name: [product:2946003:name/]
Product Image: <img src="[product:2946003:primaryImage.largeURL/]" alt="[product:2946003:name/]" height="200" width="200"/>
As for the preview in the CMS, the XSL stylesheet takes these tags and replaces them with generic placeholders for each attribute type, so that we can see what the layout will look like, though we can’t see the actual product itself until it’s live on the site.
Q: How do you manage different configurations of your site with Cascade CMS?
There are certain things that we want our non-technical Cascade CMS users to be able to control. In these cases, we give them simple text files in the CMS that they can edit themselves to configure what is shown in the site to different visitors.
For example, we support a live chat function that appears for the users if they are in a country for which the client is paying for live chat support. In this case, we have a simple text file in the CMS that the user can edit with the list of “live chat supported” countries. Our application server then reads that file from the database to get the list of countries and determines whether or not to show the live chat link on the site. This allows them to manage the list of countries “just in time” without having to ask the development team for the change and without having to go through our whole software release process.
We only do this for things that are not likely to change too often and have little impact if the Cascade CMS end user were to make a mistake. We also take care on the server side to make sure there are no ill effects if the end user does make a mistake. In this case, if the file was corrupted, the link would simply not appear at all, which would not be the end of the world for a short period of time.
Q: What are you doing to manage multi-lingual sites? How has this changed from when you first started managing multiple languages?
Let me start with a bit of background. Our servers work with suffixes on the url. For example in the case of Brokerforum.com, we use the following URL suffixes:
- http://www.brokerforum.com/tbf/privacy-policy-en.jsp = English
- http://www.brokerforum.com/tbf/privacy-policy-zh.jsp = Chinese
- http://www.brokerforum.com/tbf/privacy-policy-ko.jsp = Korean
In Cascade CMS, we started out using one asset with three outputs to manage multi-language pages. For our needs, we found this to be cumbersome because we were basically managing the XSL stylesheets in triplicate with some minor differences; usually just replacing “en” with “ko” and “zh”. We also learned that it was typically a different person who was editing the asset for each language. So we decided to go with the “one XSL stylesheet; multiple assets” approach. This works much better for us because in most cases, the pages and layouts are exactly the same and it’s just the content that is different.
As for language-aware images, we use the same concept. At upload time, the server parses the page and determines for each image or css file if there is a language-specific version of an image. If there is, it rewrites the path to the image; if not, it will default to the English version of the image.
Q: Are there any other ways you are using Cascade CMS to provide a personalized experience to web visitors using dynamic content?
One way we do this is that we let Cascade CMS users use specific styles in pages that are interpreted by the server at upload time. For example:
- <div class=”showForCA”>…</div>
At upload the time the server will wrap this div in some JSP so that it will only be shown if the web visitor is from Canada.
- <div class=”hideForUS”>…</div>
At upload time the server will wrap this div in some JSP so that it will only be shown if the web visitor is not from the US.
We are now stepping into the next level of our integration and we are starting to use the Cascade web services to attain some of our objectives. A real challenge we face is the flexibility of Cascade CMS. I know that sounds strange, but because there are so many different ways to achieve the same goals (for example multi-language sites), we have had to put a team in place to try to maintain standards and best practices for how to do the development inside Cascade CMS.
Q. What are some of the biggest ways Cascade CMS has helped Mediagrif and its clients?
Cascade CMS has helped us save so much time and put the control of site content into the right hands. Our clients appreciate as much control as we can give them, and they have told me it does make a difference in their effectiveness in terms of lead conversion and marketing. My main objective now when implementing CMS pages is always to give the client the ability to manage as much of the site themselves with as little development intervention as possible. This greatly improves their ability to manage the SEO, page views, bounce rates, time spent on pages, and conversion on their sites. They can also react much more quickly to changes in Google crawling algorithms or important market keywords. It allows them to have content creation and management without having to sacrifice development time and new technology projects.
Q. Thank you so much for sharing your experiences with our Cascade CMS community. Is there anything else you would like to share?
We've been really happy with the product but supremely happy with the support. We push the limits and sometimes hit a few bumps, and your support team has been amazing—prioritizing our help tickets so we could make a release deadline. Internally, people ask me, “What can I do with the CMS?” and I say, “Well, what can’t you do with the CMS?”