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

Web is 25: word processors missed chance, static web content authoring with templates. 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.

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

OpenID Connect would have been superb without the annoying notion of html redirect. I despised OAuth2 for that, I jumped on the specifications of OpenID Connect thinking it would have a good answer, and I wasn’t pleased to see that it’s still there. So either vendors have an interest in keeping things that way, or there was an oversight. The latter is implausible, so it’s got to be the former.

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.