7 ms·

Build a CMS, no forms allowed

109 points by bergie 16y ago

Udo 16y ago
While it's a very cool app (also, kudos on reducing the huge framework stack), I still believe an in-page text editor is actually a form.
- jasonkester 16y ago
  Ah, but remember, it's the letter of the law, not the spirit, that matters. So in this case the author has tackled that abomination that is ContentEditable and likely aged himself ten years in the process so that you can edit text on a page with no <textarea> tags in sight. As anybody who's had the misfortune of being sucked into the ContentEditable TimeSink Vortex will tell you, that's probably not a very good idea when all you're trying to do is edit text. But from a purely technical standpoint, he has indeed done what the title describes.
  - jasonlotito 16y ago
    I think it's also fair to say that even the spirit was met. The idea, I gathered, was to not having your typical form page where you do your creation like most typical applications have. Their is a big difference in inline editable functionality and your typical forms for add/edit/delete functionality.
  - bergie 16y ago
    The pain of contentEditable is quite nicely removed by using http://aloha-editor.org/ http://aloha-editor.org/
    - jasonkester 16y ago
      Have you actually used that editor in a project? I ask, because I tried to once. After a bunch of unsuccessful shoehorning, and marveling at how they could write an entire megabyte of javascript and still not end up with a working editor, I gave up and rolled my own. It actually made diving into ContentEditable seem like the less painful choice.
      - bergie 16y ago
        Yes, we use Aloha. It is a bit big now, mostly because it depends on ExtJS. But that is bound to change: http://aloha-editor.org/wiki/Migration_to_jQuery_UI http://aloha-editor.org/wiki/Migration_to_jQuery_UI
      - balupton 16y ago
        Hi Jason, Benjamin here from the Aloha Editor Team. You are completely right that Aloha Editor is pretty big right now; as Bergie as mentioned this is due it's ExtJS dependency. The Aloha Team has now partnered with the jQuery UI team and development is underway to shed this dependency and use the much lighter jQuery UI framework as the default. You can follow the status here http://aloha-editor.org/wiki/Roadmap http://aloha-editor.org/wiki/Roadmap and we're totally open to as much feedback you'd like to throw at us :-) We're here to help! Cheers, - Benjamin (Aloha Editor Team Member)
  - Semiapies 16y ago
    Sorry, meant to upvote, not down.
  - masklinn 16y ago
    Hasn't the WhatWG done a lot of work trying to formalize the workings of ContentEditable in order to include it in the HTML5 spec?
    - jasonkester 16y ago
      Possibly. In the current crop of browsers, it's a complete mess. IE surprisingly has the best implementation, measured by how often you have to write specific code to insert/remove/re-insert/manually move the caret, etc. just to make a simple command work on a piece of selected text. Actually, it might not be such a surprise since they had it working back in IE5. Webkit is quirky, but at least you can generally hack things into working. Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. It's completely unusable, and many trivial things simply throw non-catchable exceptions at you and refuse to work. Bugzilla is full of open bugs on the most basic things, with comments from, for instance, the Google Docs team about how they simply can't support certain features until Firefox finishes implementing ContentEditable.
      - jessedhillon 16y ago
        > In the current crop of browsers, it's a complete mess. I don't think this accurate. The Facebook status update box, and other inputs, have been implemented content editable for years now. A good example of this is the field you see when composing a message, where you enter recipients' names. When you add a recipient, their name becomes a badge in the field and you can continue typing as if it were an input. Some pretty mature JS frameworks have relied on content editable for a while too, including Ext JS. > Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. Which functions don't work?
        jasonkester 16y ago
        Do a quick View Source on that facebook box, or better still download the source of any of the wysiwig dhtml editors on the market. Note that it's half a megabyte. All hacks to make ContentEditable work at all. So yes, it's technically possible to do. That's not at issue. The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways. The goal of the standard is to have a single easy way to flip a switch on a piece of content and have it editable in a way that you can quickly hook up your "bold" button, etc. It's a long way away from that today. Try implementing a simple WYSIWYG editor for yourself, then note the large bald patches on your head and corresponding clumps of hair in your white-knuckled fists. That's not something that you get with other areas of the HTML5 spec.
  - warrenwilkinson 16y ago
    I've been wrestling with the idea of using contentEditable in my project for a while now. On one hand it's a great way to let users edit text, very friendly. On the other hand, you'll need a javascript toolbar, and you're limited to things that are expressible as HTML.
edtechdev 16y ago
It's nice, as long as no one is trying to use your site from an ipad or other tablet or phone that doesn't support contenteditable well (i.e., all of them). Others are starting to find workarounds by using a hidden textfield that captures input. I haven't tested them on a tablet or mobile phone yet, though. See the Ace editor and Codemirror 2: http://codemirror.net/2/internals.html http://codemirror.net/2/internals.html http://ace.ajax.org/ http://ace.ajax.org/ (yes I know those are code editors, not wywsiwyg rich text editors, but I'm just pointing to solutions that might possibly work better on mobile platforms) Another, perhaps kludgier workaround is to use a floating css keyboard for mobile users to enter text.
- bergie 16y ago
  Lack of proper contentEditable support on typical mobile devices is indeed an issue. iOS somewhat supports it, for example you can make formatting changes but don't get a keyboard. There are some ways to go around this: * Wait for Apple to fix this issue (there is a bug open) * Implement a form-based workaround or do a on-screen keyboard in JavaScript * Do something completely different. We've had quite good experiences in publishing from mobile devices via email
  - wladimir 16y ago
    Interesting... Does Google Docs address this problem on iOS? I believe I read that Google Docs does not use contentEditable, but emulates it by catching keyboard events directly.
    - alanh 16y ago
      Wait, Google Docs supports editing on iOS at all?
modernerd 16y ago
Why don't all Content Management Systems work this way? The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend. I've found that new WordPress users are confused as to why, for example, the text they type in the post editor is set in a serif typeface when their site is displayed in sans-serif, or when their H2 tags are larger in the post editor than on the site itself. And those are only tiny examples -- I'd guess that a large proportion of new user (dis)orientation is related to the enforced disconnected backend that the majority of content management systems adopt. I think WordPress et al could hugely benefit from a pure edit-in-place model, with overlays or sidebars for any non-visible configuration like permalinks, draft posts, and email settings. WordPress 3.1 moved the admin bar onto the front page; perhaps this is a sign that more of the backend is to follow?
- phsr 16y ago
  Sitecore (proprietary, .Net CMS) has had Page Editor, a in page editor, for years now. They've been adding to and improving it. http://www.sitecore.net/en/Products/Sitecore-CMS/Editorial-Tools.aspx http://www.sitecore.net/en/Products/Sitecore-CMS/Editorial-T...
- bergie 16y ago
  We're trying to implement this "decoupled content management" idea to other systems as well via http://wiki.iks-project.eu/index.php/VIE http://wiki.iks-project.eu/index.php/VIE There is already a WordPress plugin in works... https://github.com/Jotschi/Aloha-Editor-Wordpress-Plugin https://github.com/Jotschi/Aloha-Editor-Wordpress-Plugin
- bobfunk 16y ago
  We do something similar for http://www.webpop.com http://www.webpop.com (video of it here: http://www.webpop.com/blog/videos/on-site-editing-the-easiest-way-to-update-a-website http://www.webpop.com/blog/videos/on-site-editing-the-easies...), but with the difference that we always do open up a form. In our first prototypes we were experimenting with inline editing, but we actually decided against it. The really good thing with allowing editing right on the site is that it matches non-technical end-users conceptual model of a website far, far better than some abstract admin backend for their content. This is a big deal, since for many users even something as seemingly simple as Wordpress can be really hard to explain. They just don't intuitively understand that there's a database somewhere with content that are then sucked into their website and displayed. And when they want to edit something on their site, they don't want to go somewhere else to look for it. The bad thing, in my opinion, with actually doing inline editing, is that the end users conceptual model is actually wrong. There really is a difference between content and design. The same content can often be displayed in many different places and used in different ways. Sometimes you have an article with a long text and big photo, but choose to only show the first paragraph of the text as an excerpt on the front page together with a thumbnail version of the photo. Or you truncate the title to a short version to show a teaser for the article in a small box in the sidebar, etc, etc. If the user clicks on the excerpt of his long text to edit it, inline editing starts getting problematic. Do you allow him to edit only the first paragraph inline, leaving the user unaware that he might make the next paragraph in the article sound really weird if he change it? Or do you expand it to the full text with the risk that the design will get completely mangled? Some of these problems are solvable if you limit how the designer can use the content and what HTML/CSS he can write (CSS can really mess with inline editing as well - just think about overflow: hidden or white-space:nowrap). That's why we went for a small miniform triggered by clicking directly on the content you want to edit, but with a link to the full form for that content. We want to gently guide the user towards the right mental model of how their website works, without forcing them to go search for the right content in a backend interface whenever they want to edit something.
bergie 16y ago
The relevant GitHub repositories are: https://github.com/bergie/midgardmvc_ui_create https://github.com/bergie/midgardmvc_ui_create - the reference UI implementation for Midgard Create https://github.com/bergie/VIE https://github.com/bergie/VIE - JavaScript library used for making RDFa-annotated content editable https://github.com/alohaeditor/Aloha-Editor https://github.com/alohaeditor/Aloha-Editor - usable HTML5 contentEditable implementation https://github.com/midgardproject/midgardmvc_core https://github.com/midgardproject/midgardmvc_core - the PHP framework used with the UI reference implementation If you want to implement this UI, or something similar to your web system, just let me know. I'm usually on Freenode #midgard and #iks channels.
edambauskas 16y ago
1. Is there a demo of the CMS somewhere? 2.Is the API for the JSON/REST backend documented anywhere? It is awesome to see someone implement this architecture. I have been working on a similar concept for quite a while, but didn't have time to build anything more that prototypes and proof-of-concepts.
- bergie 16y ago
  1. Not really, but you can download and run it yourself. Online demo will come at some point later 2. We're passing JSON-LD (http://json-ld.org/ http://json-ld.org/) over the standard Backbone.sync API (http://documentcloud.github.com/backbone/#Sync http://documentcloud.github.com/backbone/#Sync). But for other systems that can be replaced with a different JS implementation to the fit the API conventions of the back-end you talk with. Just override Backbone.sync If you're working on something similar, then our JS libs will probably be handy: https://github.com/bergie/VIE https://github.com/bergie/VIE
- makethetick 16y ago
  I might try and build this into my upcoming hosted CMS, CMSey (http://cmsey.com http://cmsey.com). I was planning on using TinyMCE but we'll see..
leejoramo 16y ago
Maybe I am missing the point of this. It seems like they are talking about having no "backend" to manage site content. Plone has been doing this for years. Or maybe this article is about doing these things with a lighter weight framework. Plone has always let you edit content via the web in the context of the normal web pages, not a separate admin mode. Additionally for at least 4 years, Plone has also had a feature where you can click on various page parts (title, description, body text, image, etc) and edit inline without entering the full page edit mode. This is not enabled by default, but it is available. The Plone 5 is scheduled to allow full control of page layout and creation of content types on the fly and in the context of the page. Take a look at http://blip.tv/file/4310018 It starts getting interesting about 11 minutes in.
- nowarninglabel 16y ago
  I came here to say the same thing about Drupal. Any CMS worth its salt has the same features, but I guess maybe the difference is that by leaving all the other features out, this CMS is supposed to be better. Which could be possible in theory, though I doubt it in practice.
thesunny 16y ago
We've built our own inline editor for Orbs, a website builder project which we posted to Hacker News last year. You can see it at http://www.orbs.com/ http://www.orbs.com/. Basically, you just click on the content and the editor starts working in place. This version actually uses an iFrame but copies the CSS styles in so it works exactly like inline editing. When we asked for feedback, there was a comment that was particularly interesting where the user said he'd pay for something like that if he could edit his regular website with it. Basically a CMS. It was such a good idea that we built it and it's available at http://www.designhamster.com/ http://www.designhamster.com/. Basically, you just add a class="EDIT" attribute to any div you want to make editable. We plan on making a real post to Hacker News about it later. This version is actually making the DIV editable instead of an iFrame. There is a live demo on that page where you can click on a box with some text in it and try it out on the DH home page; however, to get a real feel for it, I'd suggest using the free signup so you get an idea how it works in a page. Note: DesignHamster is live and accepting customers but we aren't going to promote until we improve the interface. This will be done in 2 weeks. It is completely usable now though for projects. So, you are using Aloha editor. It's kind of cool but still buggy (I'm sure this will be cleaned up) and I understand it's quite heavy. I think we did ours in 66KB + mootools. If you are wondering, making an editor from scratch is HUGE work. To get bold, italic, headings, bullets, and everything else that is built into the browser's execCommand list for working with contenteditable gets you a lot of cool stuff for almost zero pain. It's fun, enjoyable and fast to build. This gives you the false impression that the rest will be just as easy. Unfortunately, not even close. Every browser is different is just the beginning. There are bugs galore in each browser. Some of the worst offenders are from our favorite browsers like Chrome and Safari too. Try and backspace from a paragraph into a heading and you'll get these weird inline SPAN that fake the formatting of the H1/P tag without actually being one. In many instances, IE has the sanest behavior. To fix this, we override the handling of delete, backspace and enter depending on the browser. If the browser handles it correctly, we don't touch it. But if it doesn't, we modify the DOM directly. In other areas like selecting an image, IE uses a completely different selection object type for images than text. This has to be handled specially too. Many commands not built in require manipulation of the DOM. But unfortunately that kills your UNDO. So if you want to keep undo working, you have to build your own UNDO stack. Then there are just plain weird bugs. I think there was one where if you have an image in a P tag with nothing else, in one of the browsers, your cursor can't move passed it. So to fix it, we had to insert an invisible space. For us, the editor is one of the most valuable assets of the company which is why we have spend, probably over a man-year working and improving our editor. We are getting better at it but it's still not perfect. We want the editor to be a prime differentiator of our product so we are willing to put in the work; however, be warned that working directly on creating an editor is a lot of work.

109 points by bergie 16y ago

Udo 16y ago

While it's a very cool app (also, kudos on reducing the huge framework stack), I still believe an in-page text editor is actually a form.

jasonkester 16y ago
Ah, but remember, it's the letter of the law, not the spirit, that matters. So in this case the author has tackled that abomination that is ContentEditable and likely aged himself ten years in the process so that you can edit text on a page with no <textarea> tags in sight. As anybody who's had the misfortune of being sucked into the ContentEditable TimeSink Vortex will tell you, that's probably not a very good idea when all you're trying to do is edit text. But from a purely technical standpoint, he has indeed done what the title describes.
- jasonlotito 16y ago
  I think it's also fair to say that even the spirit was met. The idea, I gathered, was to not having your typical form page where you do your creation like most typical applications have. Their is a big difference in inline editable functionality and your typical forms for add/edit/delete functionality.
- bergie 16y ago
  The pain of contentEditable is quite nicely removed by using http://aloha-editor.org/ http://aloha-editor.org/
  - jasonkester 16y ago
    Have you actually used that editor in a project? I ask, because I tried to once. After a bunch of unsuccessful shoehorning, and marveling at how they could write an entire megabyte of javascript and still not end up with a working editor, I gave up and rolled my own. It actually made diving into ContentEditable seem like the less painful choice.
    - bergie 16y ago
      Yes, we use Aloha. It is a bit big now, mostly because it depends on ExtJS. But that is bound to change: http://aloha-editor.org/wiki/Migration_to_jQuery_UI http://aloha-editor.org/wiki/Migration_to_jQuery_UI
    - balupton 16y ago
      Hi Jason, Benjamin here from the Aloha Editor Team. You are completely right that Aloha Editor is pretty big right now; as Bergie as mentioned this is due it's ExtJS dependency. The Aloha Team has now partnered with the jQuery UI team and development is underway to shed this dependency and use the much lighter jQuery UI framework as the default. You can follow the status here http://aloha-editor.org/wiki/Roadmap http://aloha-editor.org/wiki/Roadmap and we're totally open to as much feedback you'd like to throw at us :-) We're here to help! Cheers, - Benjamin (Aloha Editor Team Member)
- Semiapies 16y ago
  Sorry, meant to upvote, not down.
- masklinn 16y ago
  Hasn't the WhatWG done a lot of work trying to formalize the workings of ContentEditable in order to include it in the HTML5 spec?
  - jasonkester 16y ago
    Possibly. In the current crop of browsers, it's a complete mess. IE surprisingly has the best implementation, measured by how often you have to write specific code to insert/remove/re-insert/manually move the caret, etc. just to make a simple command work on a piece of selected text. Actually, it might not be such a surprise since they had it working back in IE5. Webkit is quirky, but at least you can generally hack things into working. Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. It's completely unusable, and many trivial things simply throw non-catchable exceptions at you and refuse to work. Bugzilla is full of open bugs on the most basic things, with comments from, for instance, the Google Docs team about how they simply can't support certain features until Firefox finishes implementing ContentEditable.
    - jessedhillon 16y ago
      > In the current crop of browsers, it's a complete mess. I don't think this accurate. The Facebook status update box, and other inputs, have been implemented content editable for years now. A good example of this is the field you see when composing a message, where you enter recipients' names. When you add a recipient, their name becomes a badge in the field and you can continue typing as if it were an input. Some pretty mature JS frameworks have relied on content editable for a while too, including Ext JS. > Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. Which functions don't work?
      - jasonkester 16y ago
        Do a quick View Source on that facebook box, or better still download the source of any of the wysiwig dhtml editors on the market. Note that it's half a megabyte. All hacks to make ContentEditable work at all. So yes, it's technically possible to do. That's not at issue. The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways. The goal of the standard is to have a single easy way to flip a switch on a piece of content and have it editable in a way that you can quickly hook up your "bold" button, etc. It's a long way away from that today. Try implementing a simple WYSIWYG editor for yourself, then note the large bald patches on your head and corresponding clumps of hair in your white-knuckled fists. That's not something that you get with other areas of the HTML5 spec.
- warrenwilkinson 16y ago
  I've been wrestling with the idea of using contentEditable in my project for a while now. On one hand it's a great way to let users edit text, very friendly. On the other hand, you'll need a javascript toolbar, and you're limited to things that are expressible as HTML.

edtechdev 16y ago

It's nice, as long as no one is trying to use your site from an ipad or other tablet or phone that doesn't support contenteditable well (i.e., all of them). Others are starting to find workarounds by using a hidden textfield that captures input. I haven't tested them on a tablet or mobile phone yet, though. See the Ace editor and Codemirror 2: http://codemirror.net/2/internals.html http://codemirror.net/2/internals.html http://ace.ajax.org/ http://ace.ajax.org/ (yes I know those are code editors, not wywsiwyg rich text editors, but I'm just pointing to solutions that might possibly work better on mobile platforms) Another, perhaps kludgier workaround is to use a floating css keyboard for mobile users to enter text.

bergie 16y ago
Lack of proper contentEditable support on typical mobile devices is indeed an issue. iOS somewhat supports it, for example you can make formatting changes but don't get a keyboard. There are some ways to go around this: * Wait for Apple to fix this issue (there is a bug open) * Implement a form-based workaround or do a on-screen keyboard in JavaScript * Do something completely different. We've had quite good experiences in publishing from mobile devices via email
- wladimir 16y ago
  Interesting... Does Google Docs address this problem on iOS? I believe I read that Google Docs does not use contentEditable, but emulates it by catching keyboard events directly.
  - alanh 16y ago
    Wait, Google Docs supports editing on iOS at all?

modernerd 16y ago

Why don't all Content Management Systems work this way? The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend. I've found that new WordPress users are confused as to why, for example, the text they type in the post editor is set in a serif typeface when their site is displayed in sans-serif, or when their H2 tags are larger in the post editor than on the site itself. And those are only tiny examples -- I'd guess that a large proportion of new user (dis)orientation is related to the enforced disconnected backend that the majority of content management systems adopt. I think WordPress et al could hugely benefit from a pure edit-in-place model, with overlays or sidebars for any non-visible configuration like permalinks, draft posts, and email settings. WordPress 3.1 moved the admin bar onto the front page; perhaps this is a sign that more of the backend is to follow?

phsr 16y ago
Sitecore (proprietary, .Net CMS) has had Page Editor, a in page editor, for years now. They've been adding to and improving it. http://www.sitecore.net/en/Products/Sitecore-CMS/Editorial-Tools.aspx http://www.sitecore.net/en/Products/Sitecore-CMS/Editorial-T...
bergie 16y ago
We're trying to implement this "decoupled content management" idea to other systems as well via http://wiki.iks-project.eu/index.php/VIE http://wiki.iks-project.eu/index.php/VIE There is already a WordPress plugin in works... https://github.com/Jotschi/Aloha-Editor-Wordpress-Plugin https://github.com/Jotschi/Aloha-Editor-Wordpress-Plugin
bobfunk 16y ago
We do something similar for http://www.webpop.com http://www.webpop.com (video of it here: http://www.webpop.com/blog/videos/on-site-editing-the-easiest-way-to-update-a-website http://www.webpop.com/blog/videos/on-site-editing-the-easies...), but with the difference that we always do open up a form. In our first prototypes we were experimenting with inline editing, but we actually decided against it. The really good thing with allowing editing right on the site is that it matches non-technical end-users conceptual model of a website far, far better than some abstract admin backend for their content. This is a big deal, since for many users even something as seemingly simple as Wordpress can be really hard to explain. They just don't intuitively understand that there's a database somewhere with content that are then sucked into their website and displayed. And when they want to edit something on their site, they don't want to go somewhere else to look for it. The bad thing, in my opinion, with actually doing inline editing, is that the end users conceptual model is actually wrong. There really is a difference between content and design. The same content can often be displayed in many different places and used in different ways. Sometimes you have an article with a long text and big photo, but choose to only show the first paragraph of the text as an excerpt on the front page together with a thumbnail version of the photo. Or you truncate the title to a short version to show a teaser for the article in a small box in the sidebar, etc, etc. If the user clicks on the excerpt of his long text to edit it, inline editing starts getting problematic. Do you allow him to edit only the first paragraph inline, leaving the user unaware that he might make the next paragraph in the article sound really weird if he change it? Or do you expand it to the full text with the risk that the design will get completely mangled? Some of these problems are solvable if you limit how the designer can use the content and what HTML/CSS he can write (CSS can really mess with inline editing as well - just think about overflow: hidden or white-space:nowrap). That's why we went for a small miniform triggered by clicking directly on the content you want to edit, but with a link to the full form for that content. We want to gently guide the user towards the right mental model of how their website works, without forcing them to go search for the right content in a backend interface whenever they want to edit something.

bergie 16y ago

The relevant GitHub repositories are: https://github.com/bergie/midgardmvc_ui_create https://github.com/bergie/midgardmvc_ui_create - the reference UI implementation for Midgard Create https://github.com/bergie/VIE https://github.com/bergie/VIE - JavaScript library used for making RDFa-annotated content editable https://github.com/alohaeditor/Aloha-Editor https://github.com/alohaeditor/Aloha-Editor - usable HTML5 contentEditable implementation https://github.com/midgardproject/midgardmvc_core https://github.com/midgardproject/midgardmvc_core - the PHP framework used with the UI reference implementation If you want to implement this UI, or something similar to your web system, just let me know. I'm usually on Freenode #midgard and #iks channels.

edambauskas 16y ago

1. Is there a demo of the CMS somewhere? 2.Is the API for the JSON/REST backend documented anywhere? It is awesome to see someone implement this architecture. I have been working on a similar concept for quite a while, but didn't have time to build anything more that prototypes and proof-of-concepts.

bergie 16y ago
1. Not really, but you can download and run it yourself. Online demo will come at some point later 2. We're passing JSON-LD (http://json-ld.org/ http://json-ld.org/) over the standard Backbone.sync API (http://documentcloud.github.com/backbone/#Sync http://documentcloud.github.com/backbone/#Sync). But for other systems that can be replaced with a different JS implementation to the fit the API conventions of the back-end you talk with. Just override Backbone.sync If you're working on something similar, then our JS libs will probably be handy: https://github.com/bergie/VIE https://github.com/bergie/VIE
makethetick 16y ago
I might try and build this into my upcoming hosted CMS, CMSey (http://cmsey.com http://cmsey.com). I was planning on using TinyMCE but we'll see..

leejoramo 16y ago

Maybe I am missing the point of this. It seems like they are talking about having no "backend" to manage site content. Plone has been doing this for years. Or maybe this article is about doing these things with a lighter weight framework. Plone has always let you edit content via the web in the context of the normal web pages, not a separate admin mode. Additionally for at least 4 years, Plone has also had a feature where you can click on various page parts (title, description, body text, image, etc) and edit inline without entering the full page edit mode. This is not enabled by default, but it is available. The Plone 5 is scheduled to allow full control of page layout and creation of content types on the fly and in the context of the page. Take a look at http://blip.tv/file/4310018 It starts getting interesting about 11 minutes in.

nowarninglabel 16y ago
I came here to say the same thing about Drupal. Any CMS worth its salt has the same features, but I guess maybe the difference is that by leaving all the other features out, this CMS is supposed to be better. Which could be possible in theory, though I doubt it in practice.

thesunny 16y ago

We've built our own inline editor for Orbs, a website builder project which we posted to Hacker News last year. You can see it at http://www.orbs.com/ http://www.orbs.com/. Basically, you just click on the content and the editor starts working in place. This version actually uses an iFrame but copies the CSS styles in so it works exactly like inline editing. When we asked for feedback, there was a comment that was particularly interesting where the user said he'd pay for something like that if he could edit his regular website with it. Basically a CMS. It was such a good idea that we built it and it's available at http://www.designhamster.com/ http://www.designhamster.com/. Basically, you just add a class="EDIT" attribute to any div you want to make editable. We plan on making a real post to Hacker News about it later. This version is actually making the DIV editable instead of an iFrame. There is a live demo on that page where you can click on a box with some text in it and try it out on the DH home page; however, to get a real feel for it, I'd suggest using the free signup so you get an idea how it works in a page. Note: DesignHamster is live and accepting customers but we aren't going to promote until we improve the interface. This will be done in 2 weeks. It is completely usable now though for projects. So, you are using Aloha editor. It's kind of cool but still buggy (I'm sure this will be cleaned up) and I understand it's quite heavy. I think we did ours in 66KB + mootools. If you are wondering, making an editor from scratch is HUGE work. To get bold, italic, headings, bullets, and everything else that is built into the browser's execCommand list for working with contenteditable gets you a lot of cool stuff for almost zero pain. It's fun, enjoyable and fast to build. This gives you the false impression that the rest will be just as easy. Unfortunately, not even close. Every browser is different is just the beginning. There are bugs galore in each browser. Some of the worst offenders are from our favorite browsers like Chrome and Safari too. Try and backspace from a paragraph into a heading and you'll get these weird inline SPAN that fake the formatting of the H1/P tag without actually being one. In many instances, IE has the sanest behavior. To fix this, we override the handling of delete, backspace and enter depending on the browser. If the browser handles it correctly, we don't touch it. But if it doesn't, we modify the DOM directly. In other areas like selecting an image, IE uses a completely different selection object type for images than text. This has to be handled specially too. Many commands not built in require manipulation of the DOM. But unfortunately that kills your UNDO. So if you want to keep undo working, you have to build your own UNDO stack. Then there are just plain weird bugs. I think there was one where if you have an image in a P tag with nothing else, in one of the browsers, your cursor can't move passed it. So to fix it, we had to insert an invisible space. For us, the editor is one of the most valuable assets of the company which is why we have spend, probably over a man-year working and improving our editor. We are getting better at it but it's still not perfect. We want the editor to be a prime differentiator of our product so we are willing to put in the work; however, be warned that working directly on creating an editor is a lot of work.