It's a very nice idea. It can be very helpful when working with content people. It really can save a lot of time developing and configuring the content management.
In my opinion, the interface is a little confusing. It took me a long time to figure out how to create custom fields, and I was looking for it! From my experience with CMS, it's by far the most important feature. It should be very easy, especially for content editors to create by themselves...
Other than that, it can be very useful. I'll remember it for a time I'll need it...
It's a way to let content editors enter the content in a nice interface. Than the programmer can write code that uses their api to get that content the editors uploaded.
Yes, there are content management systems that you can install in your own server and manage it. But this system removes that hassle from you.
So you write your code and where you would have content you say something like {{bucketname}} and you can mess with it in the cms? What's the tempting language?
I've read the website, but I don't know what this is or what value it provides.
My understanding so far is: rather than using a CMS, I code something (not a CMS?) in whatever language I like and Osmek helps me or makes it better in some way... ?
What I understand is that you publish your content using Osmek and then use their API to pull it where you need it, be it a webapp written in JS or an iOS app.
Pretty expensive for what is essentially a replacement for phpmyadmin or Rails scaffolds...cheap content admin usable by non-programmers separate from the actual site/app.
They are a SaaS "Create Once, Publish Everywhere" (COPE) provider. NPR popularized the term a few years back, and the use it in their production environment. I have one client actively using the same architecture in production, and they love it. They use a Django site as the backend, and node.js-powered websites to publish the content.
One of the uphill battles they face is the nomenclature. Most people couple their content creation tools with the publishing tools. I.e., we think of a CMS as both the editor and the content renderer. This sort of system decouples that.
I think they are smart starting with a PHP library: that seems to target a broad install base, and publishing in PHP using an API is much easier than building a solid CMS in PHP.
Didn't programs such as Microsoft Word / Macromedia Dreamweaver / Microsoft FrontPage provide something similar a very long time ago? Maybe I'm confusing this with something else, but IIRC there were some settings in the menus that allowed you to set up remote hosts (but I'm not sure because I never used them).
It took a little while but I'm thinking the main point here is that you store your content in the Osmek system.
Then the content can be published to multiple sources such as an iOS app, website, tablet app, mobile website.
I just don't understand how this is different from having your own database with the content. What's the difference between this and say Django's auto generated admin interface (setup with proper permissions) ?
Why can't my apps just pull stuff out of the database or through my own API ?
I'm sure I'm missing something because this seems expensive so it must be worth a lot to somebody. But why ?
This seems to be a centralized content store for people without the time/money/expertise to roll their own.
The big unaddressed question is that most of the targets people care about aren't publish-only. Managing changes/submissions from many publishing targets [1] is one of those deceptively non-trivial tasks. [2]
[1] each with their own inconsistencies, permissions issues, etc.
[2] Not unlike dropbox's client software. It sounds easy. But try writing it.
I still don't quite get it. Can you provide an example?
Let's say I want to make a shared blog with Osmek. My writers use Osmek's interface to write articles, and I use the API to get the articles into blog? So it's storing the article content and it's metadata for me?
I have no idea about the value of this service, but I have to say, the website is pretty good-looking. A great advertisement for flat design - the clean typography and icons combined with bold, simple colours give the page a real confidence. The content seems to expand to "own" the entire screen, while maintaining a lightness and freshness in a way which the older style of design just doesn't seem capable.
This is a Backend as a service for Content management. Its basically Salesforce for "Content Management", which isn't a bad idea. However, for my two cents: The documentation is lacking and as a potential customer I don't quite know enough information about the product to make an informed decision to say yes/no (on spending money on it). I had this same idea a while back (except not content, mainly blogging as a hosted web service), and didn't chose to pursue it. I do believe that there may be a market, and god knows word press can use some competition. God speed and good luck! Oh and just at a final glance, the API Documentation can be cleaner.
Looks like an interesting service for managing typical application content like mail templates. A free tier would be great to try it on a project. Does anybody know similar services or open source projects that are mainly a CMS with an API combined with a good end-user editor? Git based would be a plus.
For those who are struggling to understand what this is,
It's basically a 'content store' that provides a supposedly nice interface for people to create all sorts of content and then it exposes that content back to you via an API that you can use in other places such as a CMS.
Good idea in theory, hard to execute because there is no common interface/standard.
If there was a common interface/standard you could use/build services like this to essentially decouple your content/data from the skin on top.
For example you could just pull the plug on CMS X, and 'connect' your content to CMS Y if it has a better user experience.
> It's basically a 'content store' that provides a supposedly nice interface for people to create all sorts of content and then it exposes that content back to you via an API that you can use in other places such as a CMS.
So, essentially, it's a database with a shiny frontend?
It'd be good to see more client libraries. PHP is popular but having more will help enormously with adoption. Even just stubbed out libraries on Github can be a useful starting point for the community to build on.
Is this is just a cloud provider for something similar to a de-coupled CMS, ala Symfony CMF (http://cmf.symfony.com/) ?
The idea is that the content is not locked to your CMS, like an old Joomla system where the content and meta-data are hard-coded in the schema. I would be concerned about latency, etc for hosting something like this.
There service holds and organizeds the DB storage for you. The advantage would have to come with redundnacy/latency versus rolling your own datastore. If you are doing a NoSQL or JSON type storage that allows an arbitrary format, then you are free to reuse it wherever.
28 comments
[ 2.5 ms ] story [ 72.0 ms ] threadIn my opinion, the interface is a little confusing. It took me a long time to figure out how to create custom fields, and I was looking for it! From my experience with CMS, it's by far the most important feature. It should be very easy, especially for content editors to create by themselves...
Other than that, it can be very useful. I'll remember it for a time I'll need it...
Yes, there are content management systems that you can install in your own server and manage it. But this system removes that hassle from you.
My understanding so far is: rather than using a CMS, I code something (not a CMS?) in whatever language I like and Osmek helps me or makes it better in some way... ?
They are a SaaS "Create Once, Publish Everywhere" (COPE) provider. NPR popularized the term a few years back, and the use it in their production environment. I have one client actively using the same architecture in production, and they love it. They use a Django site as the backend, and node.js-powered websites to publish the content.
Some links on the topic:
http://blog.programmableweb.com/2009/10/13/cope-create-once-...
http://www.linkedin.com/groups/Do-you-COPE-Create-Once-39120...
http://www.slideshare.net/KMcGrane/adapting-ourselves-to-ada...
http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-ada...
http://www.markboulton.co.uk/journal/adaptive_content_manage...
http://meetcontent.com/blog/structured-content-an-overview/
One of the uphill battles they face is the nomenclature. Most people couple their content creation tools with the publishing tools. I.e., we think of a CMS as both the editor and the content renderer. This sort of system decouples that.
I think they are smart starting with a PHP library: that seems to target a broad install base, and publishing in PHP using an API is much easier than building a solid CMS in PHP.
I, for example only have one name.
Thanks :)
Then the content can be published to multiple sources such as an iOS app, website, tablet app, mobile website.
I just don't understand how this is different from having your own database with the content. What's the difference between this and say Django's auto generated admin interface (setup with proper permissions) ?
Why can't my apps just pull stuff out of the database or through my own API ?
I'm sure I'm missing something because this seems expensive so it must be worth a lot to somebody. But why ?
The big unaddressed question is that most of the targets people care about aren't publish-only. Managing changes/submissions from many publishing targets [1] is one of those deceptively non-trivial tasks. [2]
[1] each with their own inconsistencies, permissions issues, etc.
[2] Not unlike dropbox's client software. It sounds easy. But try writing it.
It's basically a 'content store' that provides a supposedly nice interface for people to create all sorts of content and then it exposes that content back to you via an API that you can use in other places such as a CMS.
Good idea in theory, hard to execute because there is no common interface/standard.
If there was a common interface/standard you could use/build services like this to essentially decouple your content/data from the skin on top.
For example you could just pull the plug on CMS X, and 'connect' your content to CMS Y if it has a better user experience.
Easier said than done.
I've really like http://www.silkapp.com/ for this sort of thing. I think their API (http://developer.silkapp.com/) is great, and they have neat tools for editing structured data
So, essentially, it's a database with a shiny frontend?
The idea is that the content is not locked to your CMS, like an old Joomla system where the content and meta-data are hard-coded in the schema. I would be concerned about latency, etc for hosting something like this.
There service holds and organizeds the DB storage for you. The advantage would have to come with redundnacy/latency versus rolling your own datastore. If you are doing a NoSQL or JSON type storage that allows an arbitrary format, then you are free to reuse it wherever.