Apr 09, 2012
On May 8th, I will be hosting a panel at CMS Expo called "CMS Review - Compare CMSs For Web Design Studios & Development Firms." The panel is designed to help web design and development shops build their CMS portfolios. Selecting the right platforms to take to market is extremely important because building competency with these technologies takes time and your projects are risky until you do.
In the panel, we will be focusing on the topics most relevant to studios and integrators:
-
The types of sites that the platform is best suited for.
-
Market awareness in industry verticals.
-
Availability and quality of training and support.
This session would also be useful for an internal services group that does web design and development projects for departments within the organization.
I will be around pretty much the whole conference. Look for me if you want to chat about CMS selection, localization, or marketing operations. If you haven't registered yet, use the code Seth2012 for a 10% off discount.
Apr 04, 2012
Warning: Geeky Coding Post
I have worked on a number of Django projects and settings.py is always a problem. This is the configuration file with information like how to connect to the database and what Django apps to install. Some of this information is sensitive (like your database password or an API key) and you don't necessarily want it in your source code control system. Other information is instance-specific like the host that your database is sitting on.
In the past, I have managed the production settings in the core settings.py file and then imported an override file at the bottom that overwrites certain settings with my local settings. The code looks something like this:
try:
from settings_local import *
except ImportError:
pass
Then all you have to do is ignore your settings_local.py from your source code management system and exclude the file when bundling up a deployment package. This works pretty well except when you don't want to store a password in your SCMS or if you have lots of different settings for different environments that you are deploying to.
What you want to do is have those settings living permanently as part of your target environment(s) and just deploy a neutrally configured application. Last week I stumbled on a good technique for this that I thought I would share. The strategy comes from an article on Tim Sawyer's Drumcoder blog: Apache Environment Variables and mod_wsgi. The article shows how you can access environment variables from settings.py.
After following these directions, I was able to do things like:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'APP_DBNAME' in os.environ and os.environ['APP_DBNAME'] or 'dbname',
'USER': 'APP_DBUSER' in os.environ and os.environ['APP_DBUSER'] or 'dbuser',
'PASSWORD': 'APP_DBPASS' in os.environ and os.environ['APP_DBPASS'] or 'password',
'HOST': 'APP_DBHOST' in os.environ and os.environ['APP_DBHOST'] or 'localhost'
}
}
I am surprised that I limped along so long before using this technique. An alternative method would be to install a python package on the server (in the python libraries) that just contains these constants. But this just seemed easier to me.
Apr 03, 2012
Localization can be an elusive requirement for a website. During the platform selection process, internationalization is often listed as a "strong" requirement. Why wouldn't you want the ability to reach new markets? Then, during the implementation process, localizing gets downgraded as a "nice to have" or "future" requirement as time and resources dwindle and compromises need to be made to launch the primary language site. Eventually, localization becomes an "oh crap" requirement when someone expects to have a "Spanish version of the site up ASAP". After all, localization was part of the business case and a key selling point of the platform. Yes, localizing the site would have been as easy as hiring translators if only some accommodations had been made during initial implementation. But they were not. Hence the "oh crap."
While you may not have budget to localize your website during your initial CMS implementation, following these steps will make adding a new language easier down the road.
-
Learn how internationalization works on your platform.
Different platforms have different approaches and best practices for internationalization. If you make the modest investment to fully understand these techniques, you will at least make educated decisions about how to defer localization and not rule it out. If you are working with a systems integrator, which I highly recommend, make sure they have experience building (and maintaining) localized websites on the platform.
-
Use the translation framework provided from the templating system.
Any given web page will have a lot of static text that lives in templates (as opposed to in the content). For example, there might be a label on the upper right that says "search" or a copyright statement on the bottom of the page. It is not practical to manage these little "content crumbs" through your usual editorial workflow — they are small, numerous, easy to lose track of, and rarely change. But if you are planning on localizing your site, you don't want those strings in your templates either. It is much better manage these strings separately in "resource" or "message" files that can be shipped off to translators. Most templating languages come with a system for invoking externally managed strings. For example, in JSP Standard Tag Library, translated strings are invoked like this:
<fmt:message key="some.text"/>
In eZ Publish they look like this:
{"Some text you are going to translate"|i18n('design/standard/node')}
Setting this up is easy enough to do when you are building out your templates for the first time. However, it is very tedious to retrofit old mono-lingual templates with this system. You wind up doing it for templates that are no longer used "just in case." Worse of all, you have to visually re-inspect every pixel of the site because you are touching nearly every line of view code.
-
Keep text out of images.
Having text in images adds a lot of friction to the localization process. First, you must remember to keep the image source files on-hand so you can produce the translated versions. Second, the translation process goes through additional steps of extracting and then re-imported the localized text. Managing all of those image files can be a real pain too. It is much better to float text over image backgrounds for buttons, navigation, and slides. Incidentally, applying this practice will also help with SEO and accessibility.
-
Make room for other languages.
Think as your primary language as the first of several languages when you are designing your content repository and defining roles and workflows. These localized content collections need a place to live. They will need access control so that a local team can safely work in their content without risking the overall content repository. Pay special attention to how "global" reusable content components are managed and retrieved.
-
Buy your top level domains NOW.
If you will be publishing your sites to different markets, start working on acquiring those top level domains (like .fr or .es). It will be really embarrassing to enter into a new market only to find someone else squatting on your domain.
-
Set the appropriate character encoding
Most of the time this is a non-issue because most modern technologies default to UTF-8. Just make sure that you set up your databases with UTF-8 encoding and collation. Some older versions of programming languages require adjustments when dealing with Unicode too.
If you think localization may be in your future, plan for it now. Take the additional steps to reduce rework and risk when you are under the gun to get that new language published. If you didn't follow this advice, I would look into translation proxies.
Feb 29, 2012
Edit: Please disregard this post. I tried to add a product to the list and it was rejected. Looks like I am going with a Google Doc. Anyone want to re-invent the wheel with me?
At Lionbridge, when we scope and propose a Global Marketing Operations solution, we need to learn about the publishing infrastructure. I have been training our sales engineers to do some initial CMS analysis including what platform is being used and how. One very important data point is the software version the customer is running - in particular, how current it is. Running outdated software may indicate that the infrastructure has been neglected and may require some optimization in order to achieve efficiency goals - or it could just mean that the newest version features did not justify an upgrade. That is OK too.
Anyway, I started to put together a public Google spreadsheet that lists the most common CMSs and the current version (why not share it with everyone?). Then I decided to do one better and see if there was something already out there that I could help maintain. Sure enough, there is a Wikipedia page dedicated to listing CMS products and versions. The data is pretty current and I made a couple updates.
If you specialize in a particular CMS (as a vendor, systems integrator, or customer), please update the Wikipedia page with what you know. I know editing wiki tables is painful but I think that everyone would benefit from having access to current and accurate information. If there is a critical mass of people who prefer to manage this in a Google spreadsheet, I would be happy to participate in that effort as well.
Feb 17, 2012
I just received an email update that NGDATA has bought Outerthought, developers of Lily CMS, Kauri web application framework, and Daisy CMS. Here is the announcement. I do not know much about NGDATA other than it is a bigger company with a focus on big data. But just from that information, the acquisition could be a great opportunity for both sides.
I have been following Outerthought for a long time (starting in 2007 when I wrote about them in Open Source Content Management in Java) and got to know the team when I presented at one of their Fireside Conversations. The Outerthought team has always impressed me with their architectural vision and ambition. One day, I sat down with their architects and developers and was blown away by their insight and creativity. At times I was doubtful that a team so small (with so little external funding) could execute on such lofty plans: developing a new web application framework and building the first "big data" CMS. But they seem to continually defy my doubts.
I hope that NGDATA fully understands what it got out of this deal and gives the Outerthought team autonomy and resources to continue its successful track record and further accelerate the pace. Most of all, I wish the Outerthought team a great future as part of NGDATA.
Feb 16, 2012
Recently, I have been doing a lot of work with translation proxies. A translation proxy is a service that sits in front of your website and applies translations so that different audience segments can see your content in their local languages. You point various DNS entries to the proxy so that request goes through the proxy service to your native language website. On the return trip, the proxy applies translation rules to the HTML in the response. It’s a little like when Google Chrome asks you to run Google Translate on the foreign language page you are looking at. However, unlike Google Translate, these translations are done by professional translators and there is a multi-step workflow to ensure that the translations express correct information and tone. Of the three ways that Global Marketing Operations can localize websites, translation proxy is the fastest growing option.
This approach has several benefits. Among them:
There is no need for the core publishing platform to have multi-lingual capabilities
The publishing platform behind the primary language site may not support localization features such as storing different localized versions of a piece of content or being able to easily localize display templates. Many CMS implementations start with a localization-capable product but then cut corners, which prohibits adding alternate languages down the road. Building a site for localization takes planning, skill, and investment that cannot be justified if localization is less than a drop-dead requirement at the time of the initial implementation. Retrofitting is a lot of work.
You can translate both content and template text in one place
In a typical translation scenario, we need to translate both the content (which the content contributors manage) and the presentation templates (code that the developers manage). See this screenshot for an annotated view (sorry for the color palette choice. I understand if you have a sudden craving for a Big Mac).
With other localization approaches, you need to localize these aspects separately: the content through an editorial workflow and the template text through a software development life-cycle. In the translation proxy approach, all of this text can be localized together.
You can leverage your main site’s interactive functionality.
Because requests are proxied back to your primary language site, all interactive features (including search, contact forms, and even commerce transactions) will continue to be supported.
Your content stays secure.
Because the translation proxy only sees what regular visitors see, there is no risk to the security of the main site. The one thing you want to watch out for is transactional functionality. You want to make sure that the proxy service does not collect sensitive information that visitors submit to the website and also can create rules to ignore sensitive information coming back to the visitor.
Like with any technology, translation proxies are not ideal for every case. Here are some reasons why a translation proxy may not be right for you.
-
Local markets cannot create original content in the proxy.
A translation proxy only translates (or, in some cases filters) content from the main site. There is no clean way to add original content to a localized site managed by a translation proxy. This is perhaps the biggest show-stopper for some companies. If you have a local marketing team that wants the autonomy to develop original content for their local markets, a translation proxy is not going to help. They need to publish their content somewhere before it can be served through the proxy. Perhaps they could create areas on the main site for their specific regions but then they wouldn't be leveraging the proxy.
-
A translation proxy will not allow you to neglect your localized sites.
If you want to save money by putting up simple, (crappy,) static sites for local markets, a translation proxy is not a great solution. The translation proxy model is intended for managing localized versions of the primary site. Any new or changed content will display in the primary language until it is translated. You can contain translation costs by excluding certain sections from your localized websites (for example, you may not want to translate your blog or press releases). Still, with the proxy model, you need to consider the translation costs when you add new content to your website. One work-around could be to create a trimmed down, rarely-updated "international site" on your CMS and use the translation proxy to localize it for all your foreign markets.
-
Translation volumes are difficult to predict.
Unlike traditional translation projects, a translation proxy service is monitoring a constantly changing website so scope is going to be fluid. This is not an “invest and then rest” type of service. It requires a level of attention and planning commensurate with the level of work that is done on the main site. If you are serious about reaching into new markets, this investment should seem reasonable to you. It’s still cheaper than hiring in-country marketers to produce original content. Look for suppliers that offer a capacity model where you pay a fixed fee based on expected usage. This will protect you against a large per-word translation bill after your primary language authors have been particularly prolific.
While the translation proxy approach is not optimal for every business or website, its benefits are very compelling for many. A translation proxy may be worth considering if you learn that your sophisticated interactive website was not built with localization in mind and you want to serve new markets with the same level of experience that you serve your home market.
Feb 02, 2012
I just published my first blog post on the Lionbridge blogs site. It's all about managing URLs for global websites and discusses when to use TLDs, sub-domains, and paths. Here is the link: URL Management for a Global Business.
Feb 01, 2012
CMSWire's recent article The Seven Hats Content Managers Will Wear in 2012 drives home a point that I have been making a lot recently. It's the point that inspired me to take a full-time job with Lionbridge to scale the Global Marketing Operations offering. Engaging audiences with content is hard work and it doesn't matter that your CMS makes it easy to edit web pages. As the article describes, a modern content manager is a content collector, a context controller, an eavesdropper, a concierge, a right-brain thinker, a number cruncher, and a bodyguard. And that is just to manage a site in one language. For a global site, you might as well add "international (wo)man of mystery" to that list.
One thing you realize after years of content management consulting is that the tools play a relatively small role in a company's ability to maintain an excellent digital presence. Skills, process, and commitment play a much larger role. If you don't have those, no technology is going to help you.
Recently I appeared on a CMS-Connected and we talked a lot about web engagement. I mentioned that the market, as a whole, failed to get sufficient value from the content production functionality of upper tier WCM platforms. Most customers didn't have the process, skills, and commitment to fully leverage workflow and other content management functionality. As a result, many found themselves owning 6 million dollar wysiwyg editors. CMS vendors has responded by shifting the value over to the delivery side with functionality like personalization, multivariate testing, and analytics.
One thing that I wished I said on the show was that, unless customers increase their people commitment (time, skills, and process) to managing their websites, the upper tier CMS vendors won't achieve value on the delivery side either. So far, I am finding that most customers are under-utilizing these advanced marketing features that were so important in their platform buying decision. If only they had more hats...
If your company runs a website (and what company doesn't?), I want you to take the web manager out to lunch. You will probably learn that he is overworked and would love to be doing so much more but limitations of time and skills prevent it. You may hear will hear that the CMS didn't really remove the webmaster bottleneck and all of his time is spent chasing down and posting content. He might confess his embarrassment from how bad the site looks on mobile devices. In short, the web manager has his hands full just getting content on the site and can't even think about maximizing the reach and effectiveness of the website.
If you hear these signals, your organization probably has a lot of growth to do before it can fully realize the benefits that web engagement functionality promises. You need to acquire some more hats before you go software shopping.
Jan 26, 2012
Last week I had the privilege of joining Scott Liewehr on CMS Connected, a web television show about content management. The topic was "2011 WCM Year in Review" and we covered a lot of ground: mobile, engagement, and the cloud. Tom Wentworth, from Ektron dropped in on Skype for a cameo appearance too.
I had a great time and folks on Twitter seemed to enjoy the conversation as well. You can watch it here. I also got to meet Butch Stearns who I know from listening to WEEI.
Big thanks to Tyler Pyburn and The Pulse Network for hosting and Falcon-Software for their generous sponsorship.
Jan 17, 2012
In the old days, static publishing (or baking, where the CMS generates static HTML files at publish time), was pretty much the standard. Most of the WCM products on the market did static publishing: Interwoven, Tridion, RedDot, Percussion .... Even the frying systems like Vignette and FatWire (FutureTense/OpenMarket back then) relied so heavily on caching that they were practically baking style systems. Computing power was so expensive back then that you didn't dare to do much processing at request time.
Then frying-style systems became the norm. WCM vendors needed to have an answer to market demand for personalization and other dynamic behavior and the only way to do that was through dynamic (request-time) publishing. But static publishing isn't dead. There are many baking style systems on the market and lots of customers swear by static publishing. Good strategies have emerged to overcome its limitations. The primary benefits of static publishing are still very real: cost-savings, security, and stability. You can cheaply stand-up web servers that have the easy job of just serving up static HTML files.
And this brings me to my little obsession with static publishing. I am hosting a few sites on Amazon S3. The cost is ridiculously low and the speed is crazy-fast. Publishing them is fun too. For example, I publish my little personal site (www.sethgottlieb.com) using a site generator called Hyde, which is a Python port of a Ruby-based system called Jekyll. The way these generators work is that you enter your content in HTML, Markdown, or some other syntax and then run a script that renders static HTML pages with your presentation templates. Presentation templates can also do useful things like create listing pages. The Hyde sample site has a blog and there is a script to migrate from Wordpress. Versioning? Git, of course. In fact, using a source code control system will also allow multiple authors to collaborate too. Site generators also do useful things like minifying your CSS and JS files for maximum performance. Want interactive features like search or commenting? For search you could use Google Custom Search. Commenting can be supported through a service like Disqus. You can configure secure areas with your web servers. For little bits of interactivity, you could embed some client side Javascript or server side PHP in your static HTML files.
I also used static publishing to create an archive of a site that I no longer update. I created a Drupal website for my wife's birthday a few years ago. I didn't want to pay for LAMP hosting indefinitely but I didn't want to lose the site either. My solution was to pull the whole site down using wget and then upload it to S3. The site has lots of pages and I wouldn't want to manage them as static HTML but since I have no plans to change the site, I don't have to worry about it.
I am not saying that static publishing is a good idea all or even most of the time. Dynamic publishing opens up a whole new word of interactivity and personalization. Just don't write off static publishing too quickly — especially if your site doesn't change much and doesn't need to be very interactive.