A GUI, or rather a CMS interface for DocPad is the big next step. It was also one of the first proof of concepts I used to ensure DocPad would be able to scale into the web development platform of the future.
Back in the first early months of DocPad, I created three plugins:
- Authenticate: To authenticate you against the project's maintainers to ensure that you have read and write access
- REST: Provided authenticated users the ability to update documents via HTTP POST requests using JSON
- Admin: Provided authenticate users the ability to edit documents using content editable (inline and client-side editing), and on changes send them back to the server (via the REST plugin) to be saved
And to my astonishment, it worked very well. The proof of concept was a success, and that was one of the final ticks needed for me to pursue my full-time commitment to DocPad.
Now, DocPad is starting to mature; version 6 is on the way, a series of large firms are now using it (among dozens of passionate individuals), and theme markers are starting to make the move. The future is amazingly bright.
So what next? A few things, but this post will focus on the development of an official GUI.
So, setting out for a GUI is pretty ambitious. We had plenty of ideas:
- Be like WordPress and facilitate everything
- Be like SquareSpace and facilitate everything
- Be like Tumblr and be really simple
- Be like Cloud9 and only be for coders
All of which, were all in options, with significant development time, and huge lock in. Something completely against the DocPad Principles/Spirit of clean/lean, agile and powerful. So we thought, we thought, and we thought.
And just like that, it all came together. The future of a CMS is not with lock-in, but with plug and play.
From pretty much the birth of the internet, Content Management Systems have always had one thing in common - be the biggest and be the best, or rather have the most features and the most users.
That precise reasoning is why we have thousands of expensive content management systems, all of which lock you in, and yet no one is completely satisfied. As as soon as you stray for the use cases that that CMS is built for, everything comes crashing down.
So what does this boil down to? That while there are many great ways of accomplishing an individual thing, there are no great ways of accomplishing everything.
What this means for content management is precisely what we've seen with the success of platforms like Tumblr, Twitter, Shopify, Flickr, Vimeo, YouTube. Choose one thing, do it incredibly well.
Tumblr chose blogging. Twitter chose micro-blogging. Shopify chose online stores. Flickr chose photo sharing. Vimeo and Youtube chose video sharing (professional vs. personal).
Whereas WordPress chose to do blogging, but it is used for everything, hence why it disappoints everyone who doesn't use it for that.
This is also the reason for DocPad's success, it chooses one thing writing websites, and does it incredibly well.
And as website is a very large superset of many other things (e.g. static sites, blogging, e-commerce, web applications), DocPad is very well positioned to be the foundation of a lot of amazing things.
So, how can DocPad scale from its superset of writing websites, into more specific subsets like blogging or e-commerce? Well that's easy, write a GUI. However, if we were to accept that, fast forward 5 years and we'll be in the same spot as wordpress is now. Let's try again, how can we ensure we provide the best experience possible for creating more specific subsets like blogging or e-commerce? By creating specific solutions for each of them (each use-case), and ensuring they can be mixed and matched (plugin and play).
So naturally, who is already doing this? Well, for starters. Vimeo, YouTube, Flickr, Tumblr, Twitter, are all actually plug and play content management systems. They provide a simple service, for a specific use case, that can be embedded into different services. Lets get more specific.
Lets say I want to upload a video, I would upload that to Vimeo, then it would automatically publish to my website, Facebook and twitter automatically. Lets get more specific.
We upload a video through Vimeo's interface, which is then stored inside Vimeo's content repository - it then notifies other services such as Facebook and Twitter automatically, which then make an entry into their own content repositories. Lets find the pattern.
A video is uploaded to a content repository, and then referenced in several other content repositories.
But what does this mean for us, the website creator. It means that if we want to get our video onto our website, we would have to implement a content repository integration for vimeo into our website. Which is exactly we do with the Feedr plugin for DocPad, we pull in the vimeo atom feed, and display its contents on our website.
However, this isn't really an interface for managing our content though… but it does fit the bill for a plug and play content management system, so what's up? Well our wants are off. So what is that we really want?
To find out what we want, we should ask, what is it that appealed to us about Vimeo? What is it that we would like for our own project? Take a guess.
Its the interface. Its the interface of Vimeo that we like, its the interface of Tumblr that we like, its the interface of GitHub that we like.
This appeal of the interfaces is crucial, and GitHub knows this. For instance, that is why there is (my speculation) GitHub Enterprise - the GitHub interface locally. People don't care for using an alternative like a spring loops virtual machine locally, they care for the github interface, which is why they pay big money for it. As it is the interface that provides the experience, it is the experience that produces results. Therefore a good interface, leads to goods results.
So what we are really after, is in fact, a plug and play interface. However remember one interface to do everything fails miserably, so what we are really after, is plug and play interfaces. One interface to nail each use case.
So surely there are some nifty plug and play interfaces already out there, it can't be a new concept. Correct, intact it is a very very old concept. Very old, as old as the concept of clothing I bet.
Clothing you could say is a plug and play interface. Once piece of clothing and be plugged and played on multiple people. And clothing is a interface, it is how people see us, it helps to form peoples opinions about us, and it helps to craft experiences about us, and it also helps us get stuff done. Clothing really is synonymous to user interface.
Give that, lets apply this to a more techie world. Lets look at projects like people, and their interfaces like clothing.
So what interfaces are there? Or rather, what interfaces/clothing aren't sewed/dependent on their person/project/content-repository?
Well, for instance, pretty much every single content browser or editor on the computer is. Lets look at this in a list, in the format of: "person/project/content-repository: interface/clothing"
- Internet: Google Chrome, Firefox, Internet Explorer
- .txt files: TextEdit, Notepad, Sublime Text 2
- .doc files: Microsoft Word, Apple Pages, IBM Symphony
- .mov files: VLC, QuickTime, Windows Media Player
All of these pieces of content, all have multiple interfaces that can be plugged and played on that particular piece of content, right where it is.
However, this isn't how the vast majority of the web is built. Instead most web applications are built on the principle that content, or rather information is power, the more information you possess, the more power you have, the more value you as a company have.
Honestly, I feel that principle is shit. I feel the principle of power is shit. A government is not a good government because it is powerful, a government is a good government if it empowers its people. Importantly, these two forces completely repel each other!!!
This is the precise movement towards open-source and collaboration. They are all about giving up power, for collaboration. Which to rephrase, makes perfect sense. They are all about distribution of power. Keeping power for yourself, means keeping it from others. Giving up power yourself, means giving it to others.
Woah woah, that is crazy?!?! But it is true. Lets look at government. A strong government is one that asserts its power over its people. A weak government is one where the people assert their power over the government. However, there is another option, and that is the option of collaboration, the option of open-source. A powerful country, is one where the people and the government share their power uniformly.
This is beautiful. Because, by sharing power, you have less power yourself, but as a unit, you have more power! Crazy omg goodness. This is precisely a requirement for working in teams, if you work in a team as a dictator, your team will rebel. If you work in a team as a wimp, your team will walk all over you. However, if you and your team work together, you accomplish truly amazing things, things more amazing than yourself as an individual ever could accomplish.
Why is this? Its because everyone, has their own unique insights to things, insights formed by their unique wiring, insights formed by their unique experiences. This applies to you too, you have unique experiences, insights and wiring, that only you have, no one else does, these unique things help you to excel and see things differently than other people. However, you may think that you don't need other people to realise your dream, however, is that to say that the person who has the insight that you do is wrong? Well, no and yes, both to their own extents, and to the extents of their experiences. Which is why listening and working with others is so important, we can't experience every single thing possible, which is why learning from others experiences, and their learnings is so important. Why giving them a say, why giving them power, is so important. For instance, if someone says "trust me", and you say "I'm not sure", go with the "trust me" as their experiences and insights are screaming that they know a better way - whereas "not sure" just means you have not yet experienced that better way yet. If for instance, you have "trust me" vs "that is a terrible idea" then argue, and extrapolate the good idea from the bad idea, as your experiences may be similar but they are not the same, find the differences, find the similarities, and you will then have the key to the success and failure of your experiences. That is growth, that is sharing, that is collaboration.
Now that we've established sharing/collaboration is empowerment, what does the future look like?
In my opinion it means that open collaborative and empowering platforms are the key to success and growth of humankind. For instance, the open-government movement takes power away from the government and gives it back to the people, allowing them together to accomplish amazing things.
It means that for user interfaces, we'll start to see the emergence of the semantic web even more. That people will start running their own content repositories, which can then plug into specific interfaces.
It means that for collaboration, we'll start to see even more services like GitHub emerge.
What was does this mean for DocPad? It means that for us to grow forward, we will need to focus on our key strength "writing websites" the best we can, and be the foundation of a new platform of collaborative website development.
This is possible through DocPad's commitment of being simple yet empowering. As DocPad doesn't enforce and restraints on you, you have the world to conquer. However, if you want to hop on the fast lane for any common use case, DocPad should cater for that terrifically - e.g. using pre-processors to write faster, using layouts and partials to improve abstraction and re-usability, using meta data to improve manoeuvrability, etc.
Tying this back to the rest of this post, it means having specific interfaces for each specific subset of websites, to provide the best experience for accomplish that subset that anyone can possibly create.
It means having an interface like tumblr that you can install to plug and play instantly with your DocPad website to write your blog content better than ever before, directly on your DocPad website.
It means having an interface like vimeo that you can install to plug and play instantly with your Docpad website to upload your videos and manage them better than ever before, directly on your DocPad website.
To accomplish this, these interfaces must be MIT licensed, to foster empowerment, remix-ability/forking, with strong community involvement and leadership. Something the DocPad community is blessed with.
But there is one more key thing that is vital, and the most important. If we couple these interfaces to DocPad, we then are exactly the same as wordpress. So how do we win? This is the kicker, and it is so ridiculously obvious.
We don't couple them.
De-coupling content management was first introduced to me by Henri Burgius at the Aloha Editor Dev Con 2010. Henri is a big promotor of this philosophy, and job involves being sponsored by the IKS to ride around a motorbike through europe all year round promoting and hacking on projects to accomplish this vision.
In fact, DocPad is directly a result of my conversations with him and a night of beer and swiss chocolate with security researcher Sven Fuchs. DocPad was designed to the premise of the foundation, or rather a vehicle for the semantic web.
So what is the semantic web?
It is easy, it is simply a web represented by documents.
Huh, but isn't that the web already? Well no, right now the web is a bunch of content, and hardly represented by anything.
Lets elaborate on that earlier definition. It is a web, filled with semantically/meta-data rich documents, that are able be easily extrapolated from their existing content repository.
Right… so what does this mean to me? Well it means that it is very very easy to make your website, semantically rich. You just add a series of HTML tags to your website markup to explain the type of documents your website contains, and their relationship to your content repository, and other content on the web.
What does this mean for others? The big picture idea for the semantic web, is that it allows applications that you never have intended for, to utilise your website data in rich new ways, that otherwise would never have been possible. In other words, it empowers your website content standardised API that others can hook into. In more or less the same way how Twitter and Facebook provide APIs to use their services (post and read tweets) to provide new services that otherwise would never have been possible.
The big picture practical example that I personally love, is that it allows for a peer-to-peer crowd-sourced google to come into existence rather easily.
Essentially what it all boils down to, is that we're about to start developing a series of interfaces like tumblr, vimeo, etc. that are decoupled from their content-repositories, allowing them to hook into any semantic content-repository (such as DocPad, or whatever) allowing us to move the web forward.
A decoupled web, means increased collaborations, means increased empowerment. Which achieves Bevry's purpose.
The future is incredibly bright.
Care to join us? Join in on the discussion below.
The latest on development is: