Content Management

Content Management is one the most important categories of software. Two years ago, Microsoft Office was the inevitable choice, with various hosting applications like Sharepoint for the enterprise. But there's been a huge amount of change in the last two years - from OpenOffice to Google Spreadsheets to Youtube.

It's now (just) possible to see what Content Management will be like in future - and it's already clear that no one is near yet.

About Content Management

The first question is, what is content?

• text (e.g. HTML, doc or xls)
• raster images (e.g. JPG, PNG)
• vector images (e.g. SVG)
• audio (e.g. mp3)
• video (e.g. mpeg)
• structured data (e.g. various XML)

The last category is really a miscellaneous bucket, which I don't expect to contain much except for niche applications. Raw XML is great for data crunching and back-end configurations, but I don't see it being used much for content - we have more specific languages (like HTML and SVG) for that.

The second question is, what is management?

• CRUD (create, read, update, delete)
• publishing
• collaboration (CRUD permissions, discussion tools)
• versioning & audit trail
• syndication (subscribing to feed)
• search
• storage (includes records management)

Web Office Suites

If you look through this list, Microsoft Office only really handles the first option. Sharepoint handles most of the rest, but that's only used in the enterprise - what about other people?

That's why you can't rule out web office suites like Google Apps - they may be very basic at CRUD, but they can be excellent at management functions 2 through 7 - and how many people really want complicated document formatting options anyway?

The most interesting content management technology is, of course, the Wiki. Wikis naturally cater for all seven management functions above. The only problem is, traditionally Wikis have been restricted to plain text and totally open permissions, but there's no reason why that couldn't change.

For example, JotSpot was (until being acquired by Google) selling a Wiki for corporate use that included HTML calendars and spreadsheets as editable pages. And I don't see why you couldn't edit other media collaboratively using a Wiki - especially vector graphics.

Ideas for a Web Office

Google has been suprisingly quiet about the future of JotSpot since acquiring it. If I'm right, their strategy will be to convert Google Apps into a Wiki suite that covers all types of content (1-6 above), and all types of management (1-7 above).

For example, Youtube could become a Wiki, including video editing capability (with permissions settings). Picasa will become a Wiki-based competitor to Photoshop. They could be packaged up with general Wiki website editing functionality, and sold to corporates (or made available to consumers, supported by ads).

To compete, Microsoft will have to cannibalize their existing Office suite, including Sharepoint. I'm still not sure they're ready for this yet.

In summary

The future of content management is Wikis, allowing management of all types of content: web pages, photos, vector diagrams and videos. It'll be based in the browser, using standard web technology like HTML, CSS, javascript and SVG. There'll be a lot more emphasis on collaboration, syndication, and search. And now the future is clear, there will be a race to achieve it - and Google has the head start.

SonyEricsson W960 versus Apple iPhone

All the recent iPhone hype has removed focus from other manufacturors plans. In most cases, it doesn't matter, because most phones are just thinner versions of the previous model.

But I'm really surprised there hasn't been more buzz about the Sony Ericsson W960, which will be released in Q4 - before the iPhone in its target markets (Europe and Asia).

Check the table below to compare features.

Feature	iPhone	W960
Touch Screen	Y	Y
Browser	Safari 3	Opera 9
Music Player	Y	Y
Video Player	Y	Y
Memory	8Gb	8Gb
Wifi	Y	Y
Connection	2.5G	3G
Camera	2 MPx	3.2 MPx
Keyboard	Virtual	Physical + handwriting recognition
Operator	AT&T	Any
Development	Ajax	Ajax + client

Note that the W960 phone will be available to all operators, developers have full access, it has a better camera, just as good a web browser, and it's 3G. Unfortunately, pricing information is not available, but it'll be interesting to see how it compares with the iPhone.

I'd also be very surprised if the W960 didn't come with MusicStation installed - which means you can subscribe to a massive library of songs, and download them directly for free - without even touching a PC!

At the very least it seems Steve Jobs was wrong about the iPhone being five years ahead of the industry ... it'll have a fight on its hands outside the US.

Ajax and the iPhone: great, but what about RSS?

So, Apple announced that the iPhone will be programmable, but only using HTML, CSS and Javascript.

Most people were pretty underwhelmed by this news - it sounds like Apple's quick fix to build a development community, and it probably is.

But this is a massive story. We will finally have a popular device whose developers will have to rely entirely on internet standards. The internet will receive another boost, as developers realise how much they can achieve - even Google Spreadsheets - and, after the kicking and screaming has subsided, I don't believe they'll want to look back to proprietary client technology.

After all, the desktop world is moving away from client applications towards the internet - and it's going to be the same on the smart phone.

Internet Apps, not Client Apps

Steve Jobs mentioned making a call and sending an email via Safari - I assume this means they'll support <a href="mailto:x@y.com">Email me</a> and <a href="callto:+112345">Call me</a> via HTML. At once, seamless integration with CRM and corporate directories will be straightforward.

Of course, this makes the decision to stick with GPRS, rather than 3G, even more strange. Download speeds will be pitiful once you're outside a Wifi connection. Surely they'll produce a 3G model soon, especially for Europe?

Offline RSS

I'd love to see offline RSS in the iPhone. If it synched your RSS feeds every time you hit a Wifi zone, and stored them locally for offline access, that would be a tremendous win.

After all, what is iTunes.com but a personalized RSS feed of music and video files? If your phone wirelessly synched up with iTunes.com, you wouldn't need to touch your PC!

And offline RSS would also allow me to synchronize with corporate files, Google's Picasa, news, and much more.

If that's not a good programming API, I don't know what is!

The internet applications gold rush

The golden age for internet applications is now - surpassing even the dot-com era of the late 90s. The technology, infrastructure and understanding of the power of the internet has reached critical mass.

I believe that for any industry, a couple of experts could put together - in a single day - a revolutionary business plan for automating its key processes, using the internet. It's that easy!

All you have to do is map out existing tools against the end to end processes, spot the gaps, apply standard internet advantages (collaboration, accessibility, open standards) and keep an open mind, and inspiration will quickly strike.

For example, retail banking: one of their critical business processes is fulfilling transactions. Why shouldn't I be able to

• subscribe to a secure RSS / Atom feed of my statement
• tag, star, annotate, and search for each statement entry
• click on hyperlinks from each statement entry to the relevant retailor's receipt and product description
• use customized graphs, charts and tables to analyze my statement
• use the same chip + pin security to log into my online statement as for when I make purchases
• accept secure payments from anyone else, using chip + pin
• make customized standing orders; for example, automatically transferring 70% of my balance every day, so long I have more than £1000
• Be part of an online community for sharing financial advice, information, and transactions.
• arrange private loans online with community members, facilitated with credit checks, legal agreements, online community-based reputation, loan insurance, and various interest rate options and calculations
• allow community collaboration, so I can list other users that have view (filtered or full), add (make transactions), edit (annotate, tag, star my statement entries), or delete (cancel transactions) permissions to my statement.

You might have thought financial services was pretty automated already. But based on a 10-minute brainstorm, it's clearly missing the internet touch!

In this blog, I've already applied the same techniques to the media, telecommunications, and content management industries. That's just the start.

But if I can do it, then other people can, too. Expect an avalanche of internet start-ups across a huge range of industries. This will revolutionize our world!

Replacing F1 through F12 with browser keys

Traditionally, keyboards come with function keys - F1 through F12.

These keys are all wrong. It's not clear what they do, in any given application or OS. They take up valuable space and in my experience merely add confusion - they're way too abstract.

I would advocate the following four keyboard buttons instead:

• Home
• Back
• Forward
• Refresh

These actions have proved their worth on the web. They're simple, easily understood, and very powerful. They exert pressure on the software developer to program the right way.

Putting them clearly on the keyboard would make web browsing a much better experience, by reducing unnecessary use of the mouse.

It would also increase consistency with smaller devices, such as the iPhone or Blackberry - even if you don't have a QWERTY keyboard, you still need to navigate around.

And other applications - such as email on Blackberry - could easily use them too, bringing a standard user interface framework to computers.

Vector Graphics should belong to the web

There have always been two competing SVG visions.

One camp sees SVG as a stand-alone XML format for graphical applications, such as graphical design tools or mobile phone user interfaces.

The other camp sees SVG as belonging to the web - an extension to HTML, and a way for web designers to add exciting new features to their pages. Sitting in this camp are the browser makers (and probably most of Silicon Valley, when they think about it).

Of course, there is a spectrum of viewpoints between the two - but the W3C seems dominated by the stand-alone camp, who have seemingly neglected interoperability with HTML, CSS and current browsers.

This is betting against the internet. The browser is the new platform, and HTML, CSS and javascript are the basic formats of choice. SVG must fit into that picture.

Silverlight and Flash are not the answer

Microsoft and Adobe have proprietary vector graphics packages, using plug-ins (in fact, both also handle streaming video and audio). Adobe's Flash has a huge installed base, and both come with great design tools for creating compelling content.

But they also have weaknesses. They follow proprietary standards, they are inaccessible (especially in their binary formats), they overlap with HTML functionality, they're not propertly part of the DOM, and they don't have CSS support.

Therefore both Silverlight and Flash firmly belong to the stand-alone camp, not the "part of the web" camp.

SVG should be an extension to HTML, CSS and the DOM

Another way of saying "part of the web" is to say "an extension to HTML, CSS and the DOM".

That is, SVG should start with the existing web - our current browsers and websites - and provide additional elements, attributes, styles, and scripting power, to support vector graphics.

In this spirit, I've listed ten principles that I think SVG should follow. Browser makers can follow these principles while maintaining compliance with SVG 1.1.

For the examples, I've set XHTML as the default namespace, and I've linked "svg:" to the SVG namespace

1. No foreignobject required for HTML

SVG has a <foreignobject> element, which you're meant to use for inline XHTML. Surely this isn't necessary - so long as elements have the right namespace, you should be able to mix them any way you want. Browsers should allow XHTML inside SVG, without <foreignobject>, e.g.
<svg:svg>
<svg:rect x="0" y="0" width="100px" height="100px"/>
<p>Hello</p>
</svg:svg>

The HTML is positioned according to its parent, i.e. the <svg> element - see point 5 below.

2. Apply SVG layout to HTML

HTML uses the box model for layout - everything is aligned to, and contained within, vertical and horizontal boxes.

SVG allows transformations for scaling, rotating and shearing coordinates. This is much more powerful than the box model, and might seem to be inconsistent - but actually, it's not! You can construct twisted HTML boxes, following the coordinate axes.

So, browsers should allow things like:
<p svg:transform="rotate(45)">Hello World</p>

3. Apply SVG fills, strokes, gradients, filters, patterns, and painting to HTML

You should be able to apply all the great SVG effects to plain old HTML. See the example below for an HTML paragraph that has been filled with a red to yellow gradient!

<svg:defs>
<svg:linearGradient id="MyGradient">
<svg:stop offset="5%" stop-color="#F60" />
<svg:stop offset="95%" stop-color="#FF6" />
</svg:linearGradient>
</svg:defs>
<p svg:fill="url(#MyGradient)">Hello World</p>

4. Apply SVG CSS to HTML

If you look at the example above, the svg "fill" attribute carries out a similar role to the HTML "background-color" style. I don't see this as an issue - whenever present, it would take priority over CSS 2.1 styles. Similarly, SVG "strokes" would take priority over HTML "border" styles.

This would also apply to external CSS files, as the example below shows:
p {stroke-width: 2px; fill-opacity: 0.5;}

Not only do SVG styles overlap somewhat with HTML ones, but they use different conventions for units, too. In HTML, CSS values must have a unit; in SVG, they don't have to. Fortunately, the SVG "px" unit works the same as having no units, so browsers could define "px" as the default unit.

5. Apply HTML CSS to SVG

The SVG <svg> element could follow the box model, allowing floating and automatic re-flow on page re-sizing. For example,

<svg:svg>
<svg:circle cx="100" cy="100" r="50"/>
</svg:svg>
<svg:svg style="float:left">
<svg:circle cx="100" cy="100" r="50"/>
</svg:svg>
represents two circles that float next to each other, just as jpgs would on the page. Any HTML CSS style, including layout styles, can apply to the <svg> elements.

6. Allow HTML inside SVG shapes

A common complaint with HTML is that everything appears boxed - you can't, for example, put a paragraph inside a circle. Well, with SVG you can - see below!
<svg:circle cx="100" cy="100" r="50">
<p>Hello World</p>
</svg:circle>

The browser should wrap the text inside the circle element. Standard CSS styles like margin and text should still be valid - for example, left-aligned text.

What this means is that instead of plain old <div>, you can use <rect>, <circle>, <ellipse>, and <polygon> too. So long as the contents are pure HTML - no SVG, that would break the spec - this would help enormously.

7. Use HTML for text, not SVG

Unlike SVG, HTML was specifically designed for text. SVG 1.1 doesn't have semantic text elements, like <p> for paragraph or <h1> for header or <ul> for bullet points. It doesn't even allow text wrapping!

Once you've allowed SVG effects to be applied to HTML (points 2, 3 and 4 above), the only advantage to using SVG text is the <textpath> element - so let's allow that one too, as below!

<svg:defs>
<svg:path id="MyPath"
d="M 100 200 C 200 100 300 0 400 100 C 500 200 600 300 700 200 C 800 100 900 100 900 100" />
</svg:defs>
<svg:textPath xlink:href="#MyPath">
<p>We go up, then we go down, then up again</p> </svg:textPath>

Imagine the power of this - you could have whole paragraphs, even <div> elements, following bendy paths! Again, this isn't inconsistent with the HTML box model - see point 2 above.

The SVG <text> element is then totally redundant. You can still keep it in browsers, for backwards compatibility, but no one need use it.

8. Allow HTML animation

SVG 1.1 includes elements from SMIL, allowing animation. This always struck me as slightly bizarre - why not just keep them in the SMIL spec, and reference them?

Anyway, in a combined SVG / HTML document you should be able to apply animation to HTML elements too:
<svg:circle cx="100" cy="100" r="50">
<p id="p1" fill-opacity="1">Hello World</p>
</svg:circle>
<svg:animate xlink:href="#p1" attributeName="fill-opacity" attributeType="XML"
begin="0s" dur="9s" fill="freeze" from="1.0" to="0.0" />
You could also animate the paragraph's position, by moving the containing circle around.

9. Browser-based SVG design tools

There's a real lack of proper SVG design tools. Inkscape hasn't even reached version 1.0 yet, and it's holding back designers from using SVG.

Rather than creating a client SVG design tool, why not just use the browser? Anyone could log on using Opera, Firefox, or WebKit, and create, edit, save, search, collaborate, and publish their designs. You can imagine it as part of the Google Apps suite. All the sophisticated rendering would be done by the browser - the editing is just javascript!

10. Keep the dream going

The SVG community are not in good spirits. There is discontent at the W3C, who maintain the standard, especially from Mozilla and Apple who feel left out in favour of mobile phone vendors more interested in closed garden solutions. Adobe have dropped support for their plug-in, which was the best way to get SVG support in Internet Explorer. Mozilla have dropped several SVG elements from their forthcoming Firefox 3 browser, stating competing priorities. And Microsoft have announced their own proprietary, competing solution - Silverlight - to great fanfare.

And yet, the dream remains tantalisingly close - in 9 months time, probably 20% of all desktop browsers, most smart phones, and many other devices (e.g. the Wii) will have pretty good SVG support. Can the slow, steady, and scattered progress of SVG overcome the might of Microsoft and Adobe?

You bet it can. We just have to ditch stand-alone SVG, and ride the internet.

HTML audio and video

HTML 5 will introduce new <audio> and <video> elements, for including these objects on a web page in a simple, standard way. Just as Netscape originally became successful due in part to the new <img> element, you can expect browser makers to quickly implement and take advantage of sound and video.

Currently, sound and video is only available using the general purpose <object> element and various non-standard techniques for each plug-in (QuickTime, Silverlight, Flash, etc).

The new elements have several benefits:

• accessible - to search crawlers, the visually impaired, etc
• standard API - consistent DOM, javascript, and HTML elements & attributes
• standard user interface - for play, pause, etc
• integrated with the web page - part of the DOM, controllable by javascript for play, pause, volume, etcclear scope - just for video and audio, not for e.g. vector graphics

Possible uses of them include:

• Web page control of play, pause, fast forward, etc
• Web training videos with multiple choice tests on completion
• Video SVG filters (e.g. guassian blurs)
• Synchronized subtitles and sign language

Revealingly, both Flash and Silverlight don't neatly fit into this picture. They don't only enable video - they also handle vector graphics and html-like text. I suppose you could use the <video> element for Flash videos, and the <object> element for Flash graphics and text. But ideally you'd instead use html for text, and an element like <svg> or <vml> for vector graphics, in order to maintain the benefits above.

Once you've got normal html, <video>, <audio>, and <svg>, is every type of multimedia covered? No - there's still a need for interactive gaming user interfaces and 3D, for a start. But you're much further, and there's always the <object> element for missing pieces.

Voice Browsing

There's a famous story about the Microsoft developers perfecting voice recognition for Windows - it worked great until one of them visited a friend's video website of someone shouting "Start - Run - Format C - OK".

It's a great tale, but it's also a fundamental security issue that could derail most attempts at voice control of the client. The microphone should only be available to the application with focus (and not available for OS commands), and for privacy reasons, applications should always make it clear when they're listening and what they're likely to do with the data.

These rules are pretty restrictive - but they fit very neatly onto the web!

The vocal web

The web was designed with accessibility in mind - so that people with visual impairment could still access the web, by using voice browsers that read pages out load. There are even rarely used CSS styles for controlling vocal pitch, volume and tone.

But the web isn't just for people to read data. What's missing is a standard way to write data using speech - especially filling out the standard HTML <input> and <textarea> elements.

If this were possible, developers could create the following:

• Mobile phone search engines - just talk to Google!
• Dictated web email, blogs, or private notes
• Full use of most applications - e.g. Amazon or eBay - for the visually impaired

Vocal HTML

Following the security rules above, any website could be speech-enabled in three steps:

• Users adjust their browser settings to allow speech input (this could be a default on mobile phones)
• Developers prompt speech by styling input boxes with CSS 2.1 "cue-before" and "cue-after" styles
• Browsers vocally prompt form submission when they reach a submit element.

That's it!

There are two methods to do speech recognition:

• Client-side: A browser plug-in converts speech to text, places the text in the relevant HTML element, then submits the form on request.
• Server-side: For POSTed forms, browsers simply attach an mp3 or audio file for translation by the server

Despite the history, still lots of opportunity

Voice recognition has been talked about for ages, but it's still a niche - many people probably still think it's a distant dream.

But that will change, especially with the rise of the internet and mobile phones. And when it does, it won't only be the visually impaired that gains; it will be anyone accessing the internet without a good keyboard.