October 6, 2010

Light at the End of the Tunnel

Last week’s Business Catalyst “Town Hall Meeting” from Adobe was encouraging. After a year of near silence since the Business Catalyst merger with Adobe we at last had a chance to see the faces and hear the voices of the team behind BC.

Their explanations of why progress with BC has been so slow were credible and frankly, not surprising.

This is the typical growth path of a new system. A point is reached when limitations of the initial version of software become a liability and large scale changes are required. The mooted BC V3 is the large scale change which BC has sorely needed for some time. So, there is hope.

How long will it take? Bardia said middle of next year (2011). Realistically I expect that means end of 2011 or sometime in 2012.

Unfortunately improvements to the CMS did not rate highly on the V3 roadmap. So many innovative and useful things could be done in that department.

Posted by Paul Howson at 12:01 AM 1 comments

September 9, 2010

Limitations of Templates and Content Holders

One of the puzzling things about Business Catalyst is why tried and tested software designs successfully used in open source content management systems (and hence readily available to mimic) have been completely ignored.

This approach has led to a lot of pain for Business Catalyst developers.

Take the example of templates. Anyone who has built other than trivial websites will know that templates often have common elements. There is an overall page design with specific customisations for different sections of a website.

Following the programmer’s axiom of DRY — “Don’t Repeat Yourself” — it makes sense to factor out these common elements.

Because websites usually have a hierarchical structure, templates which nest inside other templates (or “subtemplates”) are a common solution which meets this need for DRY. Many CMSs offer nested templates.

But not Business Catalyst. Why not? I’ve yet to hear a good reason from Business Catalyst.

Is there a work around? Well, Business Catalyst offers “Content Holders” as a way to factor out repeated content. Can we use Content Holders to factor out repeated parts of a template? For example, could we use one Content Holder for first part of the template before the page content and another for the second part? Different templates could then just include these Content Holders and we could write most of the template code just once.

Alas, if we try this we find that Content Holders can only be created and edited via the WYSIWYG editor and this silly device thinks it knows better than you what you want. It closes any unbalanced html tags. Hence splitting a template between two Content Holders doesn’t work. Sigh…

(BTW, why are pages, templates and layouts accessible to edit via FTP while content holders are not? Another arbitrary limitation.)

Oh well, maybe we can still factor out common code providing it is self contained and doesn’t contain unbalanced tags? Let’s try taking repeated material that should go the <head> section of each template (e.g. css and javascript includes) and putting that in a Content Holder.

This solution works if we use the FTP interface to templates. But if we subsequently try to edit that template using the WYSIWYG editor, this ridiculous contraption, which is too smart for its own good, silently moves our included content out of the <head> and into the <body> of the template. Imagine the possibilities for disaster caused by an innocent attempt at editing the template!

I wonder if any of the Business Catalyst engineers have ever built a website using Business Catalyst? It seems very doubtful. Because if they had, they would have come across these problems and fixed them. There are obvious solutions which would not be difficult to implement. Technical difficulty cannot be a plausible explanation for why these things are not fixed. It has to come down to lack of awareness of these design deficiencies — a lack of awareness which comes from a lack of practical experience using the tool.

Posted by Paul Howson at 5:07 PM 1 comments

August 10, 2010

Blog Templates Not Quite Right Yet

The recent addition of separate templates for blog posts in list and detail views is a small but useful improvement. At last we have a way to distinguish the context in which a blog post is being presented.

Prior to this change, exactly the same overall page template, overall blog template and individual blog post template were applied in both the list and detail views. This meant it was impossible to customise the appearance of blog posts in either context. If you wanted to have a social networking widgets appended to each post when viewing the detail of an individual post, then you had to have the same widgets visible on the page listing all posts. There was simply no way of detecting the different context (amazing but true).

Now at least there is some respite. We now have separate blog post templates for list and detail views. So you can, via contextual CSS, change the appearance of a blog post in list and detail views, including adding of such things as social networking widgets.

When this was announced, I thought “Great, now all those problems with blog presentation will be solved”. Not so. Because the system still limits you to using the same overall page template and the same overall blog template in list and detail views. The overall blog template is a wrapper that goes around the entire page content in either list or detail views.

Consider this problem: You want to include an introductory explanation about your blog on the list view (i.e. the “home page” of the blog), but you don’t want that introduction to appear on the detail view for individual posts.

Under the current system this can’t be done, because content which should appear once at the top of a page must occur in the overall blog template or the overall page template, and these are the same in both list and detail views. Another BC brick wall. In the ended I resorted to some JQuery to hide these introductory elements on the detailed post view. But that should not be necessary.

What’s needed?

Separate overall blog templates for list and detailed views. Surely this should not be difficult to add? How about it BC?

Posted by Paul Howson at 5:07 PM 0 comments

August 2, 2010

Some Explanations At Last

Well, today we at last have an admission from Business Catalyst that progress has been slow, together with an explanation of why. To quote the BC blog post:

  1. We’ve had to invest a large amount of effort into system stability and reliability, e.g. we’ve already launched new data centers in New Jersey, USA and Dublin, Ireland, which of course were prioritized over wishlist requests.
  2. We acquired a new engineering team to work on the platform shortly after the acquisition. While we had high hopes in the beginning that we could be releasing new features immediately, the reality is that it’s taken the team a significant amount of time to familiarize themselves with BC’s codebase and architecture. It’s only now and moving forward into the future that we’ll start reaping the benefits of this investment the engineers have made in understanding BC.
  3. As a consequence of switching engineering teams, we underestimated how difficult it was to implement some of your customer requests and so we over-promised in the beginning.
  4. Moving forward we need to put a greater emphasis on quality and testing to make sure that new features and bugfixes are stable which means we will be sacrificing some speed in delivering features

Of course it is not surprising that a new engineering team will take time to get up to speed with an existing system. In fact it is inevitable. And that’s what’s surprising — that BC management (and especially Adobe management) didn’t see this coming. It suggests a lack of experience and wisdom in the organisation.

This admission is not encouraging, because as is explained further down in the BC blog post, very little progress has been made with the wishlist. Goodness knows how long the wishlist must be by now! The design limitations of BC are disappointing to say the least and BC users, many of whom are smart, clever people, have discovered the myriad problems with the system and documented these in the wishlist. I’ve added some myself, and they’re not just cosmetic issues, but significant deficiencies in design and function. Looks like we will be waiting some time yet to see our wishes granted.

Posted by Paul Howson at 11:28 AM 0 comments

June 29, 2010

So Many People, So Little Result?

Today’s announcement from Business Catalyst of SEO Friendly URLs for Products and Catalogs is a welcome step forward.

What puzzles me though is why progress on the Business Catalyst platform is still so excruciatingly slow. We were told late last year, after the acquisition by Adobe, that the engineering team was to be expanded five-fold. Assuming there were at least three on the engineering staff prior to the Adobe deal, that means there would have to be at least fifteen now.

I was hoping that with a larger team of (presumably) experienced and talented programmers that we would see real progress and a steady pace of new or improved features.

Yet the changes have been sparse and often quite minor. The significant reform that we have been awaiting has not materialised. What can be the reason?

One likely cause is that expanding the design/engineering/programming team has actually slowed progress due to the “Mythical Man Month” factor. All these new people are taking time to learn how Business Catalyst works and how it is put together. As the new team members dig into the existing code, they will find things they want to change. No doubt some of them are questioning earlier design decisions or perhaps finding that the codebase isn’t quite as perfect as it could be. People will want to change things, perhaps radically. You know the story.

We, the users of the system, can only wait and hope that real progress eventually does happen.

Posted by Paul Howson at 7:43 PM 0 comments

April 2, 2010

Hierarchical Attributes in Website Structure — Part 1

This is Part 1 of a proposal for adding hierarchical attributes to Business Catalyst website structures. The website structure is considered as a tree of nodes onto which attributes can be attached. Nodes inherit attributes from ancestor nodes. A pre-existing example of such a system (the Frontier Website Framework) and its benefits is presented.

The Legacy of Frontier

Long before Business Catalyst was even an embryo, more than ten years ago in fact, one of the first practical content management systems (CMS) was hatched from the fertile mind of Dave Winer, a software entrepreneur from California. This CMS was built with Userland Frontier.

Frontier was a remarkable piece of work. A persistent hierarchical object database with a browsable interface and scripting language all rolled into one.

The Frontier Web Site Framework used a branch of the object database (comprising a hierarchy of nodes) to represent the web site structure. Text nodes within the object database represented individual pages. Sophisticated scripts (also stored in the Frontier object database) wove everything together and rendered a complete website to disk. There were templates, glossaries, image storage and tag generation. Frontier as an automated publishing tool for static websites gradually developed a devoted following and a vigorous online community of users and hackers who continually added to the functionality. It was ahead of its time.

Dave Winer used Frontier to publish “Scripting News” which many people consider the first ever blog — it has been running continuously since 1997. Concepts for blog publishing developed within Frontier went on to become standard practice in many blogging tools. Dave Winer subsequently added a web server to Frontier and created Manila, one of the first dynamic content management systems.

(Note: The current author created and published in 1998 a Frontier “plugin” for rule-based translation of xml into other systems of markup (such as html). This was at least a year ahead of the first practical xsl translators. Frontier encouraged innovation.)

Frontier’s Innovations are Still Relevant in 2010

There were many ground-breaking ideas within the Frontier Web Site Framework. One of them was the concept of a web site as a tree of nodes in a hierarchical object database, to which arbitrary objects could be attached. The effect of these objects would ripple down the hierarchy to individual directory and page nodes. Any particular page in a website would inherit attributes from all its parent nodes in the hierarchy all the way up to the site root.

Attributes attached to nodes could be used to control almost any aspect of the page rendering process. For example, specifying that a particular template should be used for all pages within a particular subdirectory of the website could be done simply by attaching an attribute naming the template to the node corresponding to that directory. All pages in that directory and all subdirectories would inherit that template attribute. It was that easy.

“Metadata” could be attached to nodes also. For example, the name of a section within a website could be attached to a node. All subordinate pages would inherit that attribute. Code within a template or page could then reference that attribute to create, for example, a section banner across the top of a page. One common template could thus be customised in almost unlimited ways.

Present day programmers are familiar with including PHP or other language code within web pages. In the Frontier CMS, templates and pages could include arbitrary code in the Usertalk scripting language, including references to code stored in the object database which could call into action a vast array of sophisticated scripted processing during the page rendering process.

Even today I still maintain a couple of websites using the Web Site Framework in Frontier because of the power and flexibility it offers.

Applying These Ideas to Business Catalyst

In Part 2 I will look at how this concept of a website as a hierarchy of nodes with attached data could be incorporated into Business Catalyst. How could it work? What kind of user interface would be required? Are there any interesting possibilities? Would doing this break the existing functionality? Stay tuned.

Posted by Paul Howson at 3:37 AM 0 comments

March 21, 2010

Using Textmate to Edit BC Pages and Templates

Using a code editor to edit the content of pages, templates and layouts is simpler and quicker than using the Business Catalyst web interface.

To do this I’m using the Interarchy FTP client to view the website hierarchy. Recent additions to BC have provided access to templates and layouts as virtual folders in the site hierarchy. Previously these could be accessed only through the “Admin” menu and then clicking through a series of links. The new access method is much faster.

Interarchy (and no doubt other FTP clients also) gives you a contextual menu for any site item whereby you can edit the item in an external editor—in this case TextMate, my favourite coding editor. Behind the scenes Interarchy downloads the file via FTP into a temporary location and opens it in TextMate. Now you might think this series of steps would be time consuming. Surprisingly it usually happens in a fraction of a second.

Once you’ve finished editing the file in TextMate, saving it notifies Interarchy that the file should be re-copied back to the server. Once again, this happens remarkably quickly—in about a second or so. If you have Growl installed, then Interarchy will popup a brief notification that the file has been uploaded. Then you can test your changes by refreshing the page in a web browser.

As I said, this all happens so quickly that you would think you were editing a local file rather than a file on a remote server. It is much more straightforward than clicking around the online interface, scrolling to find the correct button, searching through multiple menus and submenus, and so on. You also work purely in HTML, whereas the browser interface defaults to non-HTML and you have to manually switch to HTML view each time you want to edit something.

The other big plus is that once your page content or template or layout is in an editor like TextMate, you get all the syntax highlighting goodness and powerful editing tools—such as grep, automatic indenting, code folding, and so on. In fact all the things you don’t get in a browser-based editing area.

This technique has made working with content in BC much easier and faster.

Posted by Paul Howson at 12:45 AM 0 comments
Subscribe to: Posts (Atom)