Let's say I'd second most of what Bryan says, especially about forking, Mir, Blink and Canonical. I am a lot less enthusiastic about current trends frankly. Most of it is experiments I'd rather opt out from if I could and let the train pass. Don't get me wrong: visions are a necessity. However some of them have far too many implications while being quite off at the same time.
For many people managing changes in IT is more of a survival issue being confronted with a constant stream of changes for the better or - more often - for the worse.
We've had request by some folks that search be more "relevant". We asked them "relevant to what". The thinking is that the search results be based on "metrics" like "most visited" shown first or something like that. Is that possible? Just wondering what our options are. (source)Here's my answer.
There are two main points made by Karen:
(1) WYSIWYG sucks. Better separate content from form, or as she coins it:
Get your HTML out of my butter.
(2) Page-oriented authoring sucks.
Both issues prevent content from being future-friendly as it can only be presented in the context that it has been created for and is not reusable for other use cases or devices. Point (2) also means that inline-editing sucks as it enforces a mental model of blips of content only being valid in a specific context or situation.
Most content authoring systems present a single WYSIWYG area where authors can just go wild and do what they want (almost). People love their WYSIWYG because it reminds them so much of their beloved MS Word. So what's wrong with giving them what they want? Basically, nothing. Yet still they have a problem: their content is not reusable. Its main value is lost in piles of markup dealing with presentation. Getting the real value out of it means stripping off markup that authors better shouldn't be adding in the first place. The content management system is much better suited to take care of it. It is this markup noise that prevents content from being reusable in a different context, on multiple devices or even audio-devices.
Let's put that into the light of wikis. Wikis are build around the central notion of a Wiki Page. It serves as a container for a note or idea that people can create quickly and without any admin overhead: click - edit - save - done. In short this is called "wikiness". Wikiness is a measure for the amount of overhead people have to face creating content. Wikiness is high when there's barely any overhead. Wikiness is low when there's a lot of planning ahead creating structures to be filled out in a guided mostly form-based way. Of course there's a middle ground where you can do both on different grades by increaseing the amount of form-based input while decreaseing the importance of blob content. Still, the basic storage unit in a wiki is one page where content is located. This location corellates directly with the URI that the system uses to present the wiki content. So wikis tightly couple the location where the content is authored with the location of its presentation. That's actually different in other content management systems such as Drupal, which come with a dedicated admin interface, a second layer behind the curtain where content is created. These admin shells are totally separated from the way the content is perceived on the front.
And here's the problem: separating content authoring too much from the way content is perceived requires additional mental efforts. It is far more challenging to build up a mental model for content chunks being used in distant locations rather than seeing hands-on what your content is going to be for the reader.The important point here is that every writer is his own reader while producing it. I am a bit concerned about separating content production in an admin shell from the way it is perceived. This is disturbing the process of creating the content significantly. In the end creating content as an author requires him to be productive. Productivity is highest when he is in a so called flow state, similar to musicians improvising while listening to themselves, or a martial artist being in a body dialog with an opponent (uke-nage). In that sense, separating writing too much from reading will hurt productivity. Not the less does carrying the burden of fancy content styling interrupt the writer in capturing his thoughts in fluent language. After having written a few chunks of content a writer will regularly test the text by putting himself into the reader-role to see whether the text makes any sense. The process of writing thus follows loops of continual typing, re-reading, simplifying, rephrasing and reordering paragraphs. The outcome of it is best when the means for the writer support his thinking and doesn't get into his way too much in terms of (1) forcing him to deal with presentation issues as well as (2) forcing him into chunks that don't match his mental model of the concepts he is thinking about. Both will inevitably cause the writer to drop out of flow state. So he ends up more playing CMS or WYSIWYG rather than producing valuable content. To be fair, we are actually talking about different things here. Karen did not talk about the authoring process as such but more as seen from the other end of the chain of content management. She ends noting that it is not so much the systems that need to change but more our mental models about content. Agreed, but even more do we have to support creativity and productivity of its authors. Chunking content for the sake of reusability puts that into danger, even more when those chunk don't match the mental model of the concepts being transported. Studies show that for similar reasons current mobile devices are counter-productive. They are the highway to snarf in content snippets in real-time. They don't lend towards a flow-state in content production by far, nor do current CMSes like Drupal actually. That's where wikis still have an advantage.