wiki:MediumPicture

The "medium" picture

We already have some pages about the Big Picture, describing our ideas. We also have a detailed plan of the feature set of our first release. This document tries to be more specific than the first one, it tries to give you an idea what the first release should look like, how it is planned to be used. It is more general than the second one though, as it doesn't enumerate technical implementation details, rather it describes why and how things will look like.

What?

We are trying to create the "content management system of the world". Now the problem is that it is a bit competitive market, so we not only need to tell how, but also why? (Also, about anything "ultimate", see the regularly appearing articles on  http://worsethanfailure.com :) )

What google is good at: organizing the information available in the world. It is pretty good at it. What wikipedia is good at: use the energy of those who'd like to write. This is the same thing that blogger.com does, using the free or cheap workforce. What the New York Times is good at: editing information to present a nice frontpage. What latex is good at: organizing a document using a boxing model.

What thiblo should be good at: using the energy or those who are not only want to write content, but be editors themselves. Plus all of the above.

Wikipedia is a content management system by definition. People can go there, and create pages. It has many flaws:

  • it doesn't allow "original content", just mainstream with references
  • hence it wants to decide what God is, which is not only impossible, but silly

Blogger is also a content management system, but very different. It helps people write about something in a linear fashion, but doesn't help people to create permanent content which evolves with each article. I mean: OK that somebody writes about dancing regularly, but it won't ever be distilled to be a page about dancing.

The two should be composed. Thiblo is planned to be a content management system that helps people create pages of varying styles.

If one wants to do just a blog, he can get it, and create content that way. If somebody wants to be an editor about a certain topic, he should be able to build a page about that topic. The style should be freely adjustable from a wikipedia-style manually fixed page to a semi-automatic or automatic page, where some or all of the boxes get content automatically from other pages, using avalanche tagging information channeling.

How?

I usually say that Thiblo is going to be somewhere in the middle of the Wikipedia-New York Times section. It should be community driven, but, in contrast to wikipedia, emphasis should be put on 'edited frontpages'.

Now I'm saying it is in the center of the Wikipedia-NYT-Blogger triangle.

Implementing the "Ultimate CMS" (again, this expression alone is a wtf candidate in itself, but let's move on for a sec) is to be done in steps. One could start from any direction. Take a classic journal engine, implement blogging, avalanche tagging, etc into it. Take a classic blog engine, implement frontpages. Or take wikipedia, implement blogs and frontpages.

With the current specification of MM1, we are starting from somewhere close to the blogger vertex of the above mentioned Wikipedia-NYT-Blogger triangle. We are heading to the center of the triangle with MM2, etc.

Although almost all our ideas we are incorporating are more than 2-3 years old, we weren't too fast with the implementation. Now just as it was with special relativity a hundred years ago, these things are "in the air" now. Every week appears a brand new system that implements more and more of our ideas, so we'd better start to participate in the race. Which doesn't mean that we can do much with a release system that

  • either doesn't contain any innovations, compared to existing web-cms systems like blogger.com
  • or the innovations we incorporate (webmore, avalanche tagging) are paired with a bad quality or totally incomplete implementation of the existing well-known-systems, so the world doesn't use ours, just takes our inventions and builds it into better quality systems.

So from the moment we release, we are on the rush, moving towards the center of the above mentioned triangle, before the world finds out that our inventions are worth using.

Why?

Because it is the  only way to change the world. (See the part at "Two: there is no two."). I have nothing against the US government, it is just trivial that information is not organized these days as it could be. Though it is customary to shoot for world domination these days (in every sense of the word), my goals were much more modest when designing thiblo. I wanted to collect knowledge.

That's why. I planned to collect knowledge. For that, I want input from many other people. So it is a good idea to write some thought provoking articles on some topic I am interested in. So I need a journal.

Also, I want to organize the information about a certain topic, so I also need wikipedia. But these should be connected. Also, information comes into the system in the form of comments. I want to be able to see where an interesting comment comes in, maybe to edit my article/text at that point to incorporate the input. So we arrive to the idea of webmore.

And, even if I don't necessarily want to defeat the US government, I find the power of mainstream press way too big. So doing anything that promotes the Brand New World of Internet community-media is the Good Thing in general.

Some details

MM1

The goal for MM1 is that we come out with a system that works for me (us) as a journal-frontpage-system, maybe with using the command line client for some operations, and works as a webmore-enabled blogger system for everybody else.

So we should be able to create complex frontpages with the command line, tweak them as we wish, also we should be able to tag articles (from the command line, emulate avalanche tagging using cron+scripts, whatever).

Others should be able to register, log in, comment, open a blog (choose from some few pre-defined designs), create articles, and that's all

The boxes system

There is an interesting new competitor,  http://www.squidoo.com . It lets the user create "lens"-es, which is a very similar technology as I have in my head in general for "hboxes/vboxes/..." frontpage. It is just way more simple.

I think that being general will pay off in the long run. We should think about latex, which became wildly successful in the scientific world. Other than the math formulae, the main advantage of it was that it took the boxes analogy from legacy printing technology.

Squidoo created its boxes system to be gui friendly from day one. I'd like to prioritize it differently: I'd like a boxing system that is able to describe arbitrary content (hboxes/vboxes/content boxes), even if at MM1 we are not going to let users to build their own layouts.

We are starting MM1 from the blogger vertex: we are going to offer our users simple linear layouts, for example, only one content box that is able to show a number of articles linearly.

It the meantime, we should have the boxes system designed and partly implemented, I'd probably like to create some journal frontpages by manual coding right when MM1 comes out.

Blog creation

At first I thought that we won't even offer blog creation with MM1. But then we discussed that not offering webmored blogs for others means that even if webmore is successful, we won't get any influx of writers as people will implement webmore for other blog engines.

So letting the users create blogs is a must. It means more effort on the implementation side that we can be happy with, but whatever. See the last section of MM1, that's a pretty new one.

MM2 and later

Avalanche tagging and complex pages

This is what the second major milestone should be about. This is actually two major developments. First the automatic tagging code, second some gui for the hbox/vbox/content box system.

The gui development will be a series of extremely nontrivial decisions. If we shoot for easy-to-understand, we will need to trade in generality of the possibly achievable pages.

I believe that we can either be the 1000th content management system of the web, or we can't compromise generality of the achievable pages. I'd like to choose the second, even if slower startup is guaranteed.

We need to define use-cases to see how a frontpage actually lives. Since the whole thing has been started because I was planning to maintain a frontpage (a journal), I have some preferences here. I'd like to have a journal which has a classic web-journal structure, of which the boxes get some articles automatically through avalanche tagging, some articles get tags manually because I select them to be tagged. I might want to delete tags from some articles which got tagged automatically but I find the article offensive or bad.

I also want to be able to somehow sort the appearing articles within a box, manually.

So: I plan to do some reasonable amount of manual editing. A system of my dreams is able to degrade gracefully: for example, I set some priorities for the articles that got selected to my frontpage through some gui. Those priorities converge in time to some default with some reasonable half-life, for example, a day later the new articles automatically get to the top. So if I have time to manage my frontpage a day, I can set which article goes to where, but they start to get automatically rearranged if a certain time has passed and new articles came in through avalanche tagging.

Naturally, there is nothing that would say the system shouldn't support conservative newspapers where the editor changes the frontpage manually every time. Just for that mode of operation, the user interface should be *very* user-friendly, which might not be our goal before MMmany.

On the other end, there might be users who keep a google-reader-like frontpage with 2 or 3 automatic boxes of different topics, now for them, the GUI for creating that frontpage should be very easy to use.