Django CMS is the simplest and most elegant Web CMS I’ve seen lately

Recently I have evaluated a lot of web content management solutions, all of them open source, almost exclusively on Unix like systems, I haven’t seen anything as simple and elegant as Django CMS. I took it for a spin, it’s polished, really designed to solve fast turn-around web publishing needs. It does that brilliantly, no question about that. I particularly like the way they make all the authoring tools and widgets disappear when not in use, so that you are always looking at your content exactly as it will appear when  published.

There is one thing, in a lot of cases, to truly appreciate any piece of work, one must have a practical understanding of the challenges involved in making it. This is also true for software. Content management, web content management isn’t a sexy topic. However, without such systems it would be tedious to maintain an online  presence, difficult to consume a lot of the content produced daily by legions of people.

I was just going to use one of the web CMS products I’ve known for a long time, to power one of my web sites. In the process, I realised that I have not done any proper re-evaluation of the products available for a while. I wanted to try that first before settling on something. I thought perhaps I should go open minded about it, include a broad selection of products. As time is precious, I decided to focus on Unix/Linux based solutions for now, because that is also my target deployment platform.

For my purpose I went back to implementing a few other web CMS products, namely: Zotonic (Erlang based), Liferay Portal (JCR), Magnolia (JCR), dotCMS (JCR), several static publishing systems such as Pelican (Python), Jekyll and Octopress (Ruby), and of course WordPress (PHP, which powers this blog). Django CMS best all these in terms of simplicity and its focus on making semantic HTML content authoring a bliss. To be fair, it’s hard to compare these products I just mentioned since each actually aim to cover a breadth of needs that might be going well beyond web CMS (portal for example). But I had narrowed my scope down to the authoring and publishing processes only, web CMS functionality alone, that makes it possible to come up with a fairly reasonable comparison.

I am not yet done evaluating web content management systems, I still have on my to-do list Prismic.io (an innovative Content Repository As A Service) and a couple of .NET based web CMS.

More to come on this topic sometime later. I probably have enough material to publish a small document on this subject. We’ll see if/when I get to that. But for now, I definitely maintain that Django CMS is the most polished solution for folks looking for a simple and attractive web CMS software.

With 8, Java is distancing itself from the ‘new Cobol’

It is time to amend a post I made a while back, where I supported the idea that Java was the new Cobol. At that time I had given up any hope to see a decent modernisation of the language in a foreseeable future. That future is here and Java has been modernised.

If you look at Oracle’s site, a few points stick out:

  1. Lambda Expressions: this improves some of the building blocks considerably.
  2. Nashorn and Javascript: this is a nod to the success of NodeJS

To me, those two points justify a new blog post to adjust my earlier statement. I still see opportunities for improvement in the syntax itself, take the following example (from the same Oracle article linked above):

Set<artists> artists =
        albums.stream()
            .filter(album -> album.getTracks().size() < 8)
            .map(album -> album.getArtist())
            .collect(toSet());</artists>

Wouldn’t this read better in the following way?

Set artists =
        albums ->
            stream
                filter tracks.size < 8 
                map artist Set

Notice a lot of the unnecessary characters removed, because the compiler would be able to infer them. This isn’t far off from the language’s current standard, yet it could have dramatically improved the code readability. I know, there’s a huge legacy to cater for and language design requires serious work. This type of simplification wasn’t out of reach, it is what you typically see in the attractive programming languages like Haskell, OCaml and others.

So, Java 8 has introduced a lot of welcome improvements, justifying that I take back my earlier statement that it was ‘the new Cobol’, but I see there is room for improvement.

Web is 25: word processors missed chance, static web content authoring with templates

The web’s just celebrated its 25th anniversary. With that you’d think we’d be far along with the tools and techniques for authoring web content. You’d be right and wrong at the same time. One area is the ability to author web content based on templates.

The issue

By static web content authoring with templates, I mean: the ability to define content elements and their styling with only HTML, CSS and perhaps JavaScript, and be able to author the content elements and expect the tool to manage everything as a unit. This is what you can achieve using web content management (WCM) products. But WCM products are born just for the web,  they might sport rudimentary word processing functionality but that’s not their real purpose.

Yes, web content authoring has been possible for a long time via various means, in various degrees of coherence and complexity. However, the leading word processing software packages just never managed to provide a good way to author web content. What is the state of affairs there?

Vendor Attempts

There were attempts to do this in Microsoft Office. It would produce html formatted content for direct publishing on the web. Did you ever look at the source code that it generated? Possibly one of the most complex and opaque there ever were. It had so many dependencies and proprietary tidbits that you couldn’t consume it on non-Windows machines.

Another approach I saw was for example a product like EMC Documentum, which would embed Microsoft VBA code in Microsoft Office document templates and use ActiveX controls to communicate with the back-end system. This looked clever on the surface but it had numerous problems.  The first one was, it only worked on Windows. The second issue, the local versions of a document would quickly and frequently go out of sync with the server versions, and resolving such issue was tedious. The last but biggest drawback was that it treated Microsoft Office documents like opaque files with some metadata, so the web templates and the office templates had nothing to do with one another. This wasn’t an optimal solution, it just allowed people to somehow share and version Office documents.

Microsoft eventually came up with SharePoint, that is such a different beast that it is a category of its own. I have also experienced situations where SharePoint local views of a document piece would go out of sync with the server version, a nightmare to fix as I experienced – though, I must add that I stopped at SharePoint 2010, I haven’t used the recent ones which could have solved such issues. Again, my point here is that, SharePoint isn’t a word processing tool, it’s something else altogether.

Let’s consider LibreOffice and Open Office powered approaches, these sibling products provide a way of programmatically manipulating documents without requiring visible User Interface (UI) elements. This made them great for mail merging and versatile document outputting combined with web technologies. Even so, they don’t help much with decent template based web authoring.

Then there’s Apple Pages software. It’s hopeless with web authoring, it doesn’t support it as far as I known. However, Apple has recently come up with iCloud offering it’s office productivity functionality as a pure web browser based solution. It looks promising, it may make Apple’s products more pervasive. But this still falls short of what I am looking for, what I thought would be a genuine user need, the ability to author web content based on a template built on HTML, CSS and JavaScript standards only.

Market dynamics

There came a point where the market was split, one one side you had the traditional office document management system packages (DMS), on the other side, the pure web content management (WCM) packages. Each side of this rift was very good at what it was built for, and did poorly at the other part of the equation. So as is often the case, vendors started expanding their products, DMS products started adding more and more web authoring capabilities, and WCM products started to provide DMS functionality too. The result is a mixed blessing where not many have done as well as could. Eventually Social Media (SM) entered the scene, everybody scrambled to redraw their blueprints and product marketing.

Status Quo

I am tempted to think that the word processing software vendors were caught napping, they never truly understood how to serve the web needs. It’s as though word processing product managers never spent a single day contemplating web authoring. You’d have thought the web to be the most important market phenomena in the IT industry, wouldn’t you? If you’d have millions of people using word processors daily, a large number of those have a need to publish content on the web, making lives easier could surely add value. Nope, the vendors missed that. It might have been a case of the old pony with new tricks.

Summary

I didn’t intend to talk about content management, or web content managent or web content distribution as a main subject. That would take an entire and long blog post of its own. I just wanted to look at how the word processing vendors fared as the world wide web dawned upon us. What I have seen and experienced tells me that the vendors missed the boat. And, if we consider who the dominant players are in the word processing market, it becomes glaring that Microsoft might have let this opportunity slip up. I’ve not seen any analyst mention this so far, they all seem to be focused on mobile and tablet as the only significant disrupting.

OpenID Connect and browser redirect, the web should get over its HTML hangover

When I saw the OpenID Connect announcement my hope just went up that, finally, OAuth2 would be getting a decent replacement and it’s annoying web browser logic would go away. Nope, it seems that’s not the case at all, so I came quickly back down to earth and needed to get this out of my system.

I started reading up OpendID Connect specifications. It looked promising until I got to the point where it mentions redirect URI (section “3.1.2.1. Authentication Request” ), there I froze, shock and horror! I don’t get it, why would a 2014 web single sign-on standard specification have such a narrow focus.

When writing a modern web application, if architected properly, one certainly would have completely separate notions of visual and non-visual elements. A web solution that isn’t composable isn’t future-proof and is doomed to quick obsolescence. Yes, sure, the web picked up thanks to HTML and HTTP. But the Internet was there long before all that and, we’re surely heading towards an Internet where a lot of chatty stuff isn’t going to surface to a user until at the very last moment, at a final consumption point. Issues such as identification and data access are to be resolved well before anything is ready to be made visual. Authentication and authorisation are not visualisation problems, they are data access concerns. Data can and should be manipulated in a composable manner, until it’s finally rendered. There should never be any assumption about visualisation in the guts of non-visual elements. Visual elements should be calling on the non-visual elements, not the other way around. That’s how, most probably, the Internet Of Things and any great stuff looming in the horizon would be architected. In this context, I don’t get the reasoning behind tying OpenID Connect to things like browser redirects.

So, OpenID Connect rings quite a few good tones, but it didn’t seem ambitious enough for me to fully empower the next generation Internet solutions. In many ways, it looks like a vendor toy that would be great for tool vendors but developers would need to figure out ways to make it even more usable. That’s a shame, a missed opportunity.

The very employable leave their mark well beyond their own office

As a follow-up to my posting on people who rant as they quit a job, I stumbled upon a perfect example of how to do it right. And this is the case for Tim Bray’s post on his leaving Google.

If the name doesn’t ring a bell, check out Wikipedia (Note: do read Wikipedia disclaimers, I only know Tim through his great work that large swathes of the IT industry depend upon daily).

Musings on Technology and the society