• Ryan MackRyan Mack, 8 years ago

    Wonderful work Anthony. I was struggling to understand where this would be making the saves to a database/file until I found the "Saving strategies" tutorial. I love the flexibility you're giving, but for the audience that I presume will be attracted to a dead-simple CMS like this won't have a clue what to do here.

    Also, would you be able to tell me your main differentiators to http://simpla.io?

    2 points
    • Anthony Blackshaw, 8 years ago (edited 8 years ago )

      I hadn't seen simpla.io before - the demo seems very nice though and the concept pretty cool, their mechanism for managing the logic behind editable regions seems really clean.

      To clarify - ContentTools is not a CMS - it's a front-end tool that provides a more natural editing environment for HTML pages than traditional rich text boxes. You still need a CMS behind it. What I've presented in the Saving Strategies tutorial is really intended to help those looking to integrate ContentTools into their CMS understand how the output of the editor can be stored. The example code in the tutorial could I suppose serve as a basis for someone looking to build there own CMS but I suspect in most cases it's far too simplistic for that purpose.

      So coming back to your original question I guess the main difference is that simpla.io provides both the editing environment as well as an API for storage to different platforms (such as dropbox which they mention on the demo page). ContentTools only provides the editing environment - the storage of content and other CMS responsibilities are out of it's scope.

      For storage simpla.io provides a remote API which you either need to sign up to use, or which you need to host yourself (you can host there API locally). The simpla.io front-end library sends updates to this API which is then responsible for storing the content somewhere.

      Reading the questions at the end of the simpla.io KickStarter page it appears you still potentially need a CMS, e.g to manage the creation of new pages, access control, etc.

      So really only the two editing environments are comparable and the best way to establish the difference between them is to try the demo pages on both sites (which I'm sure you have).

      Thanks for your question, I hope my answer helps better define ContentTools' role.

      1 point
      • Ryan MackRyan Mack, 8 years ago

        That certainly does. Thank you for the thorough explanation. Keep up the great work!

        0 points
  • Peter McDonaghPeter McDonagh, 8 years ago

    This is really elegant and smart. Squarespace offer pretty advanced inline editing but this feels even slicker. The strength is in the simplicty. Looking forward to seeing the screencasts to integrate it.

    1 point
  • Ashley CyborskiAshley Cyborski, 8 years ago

    This is pretty interesting, and has a really nice, inuitive UI. What are some of your use cases for this? Seems like it would be good for mostly static, brochure-style sites that are short-lived.

    Is there any functionality or planned functionality to allow users to add pages and nav items solely through this interface? That would be quite challenging, but w/ some pre-baked templates could likely be done and would increase the number of use cases I could foresee this being applicable to. (Maybe it already exists, I didn't dig too deep)

    1 point
    • Anthony Blackshaw, 8 years ago

      I'm actually in the process of writing a short guide on the subject of integrating ContentTools into your CMS because this question has come up a number of times since the library was released last week.

      We currently use the library on a number of client sites (including the getcontenttools website which promotes the library itself). The role the editor plays is determined by the balance of content. On the getcontenttools website new pages are added by creating a new template file in a relevant directory (e.g /tutorials/adding-content-tools-to-your-cms.html) at which point I can navigate to the page and use the editor to populate it with content (IMO it's preferable to writing markup or HTML) - so in this instance ContentTools is pretty much the entire CMS interface (there's a fairly detailed description of how this is done in the Saving strategies tutorial).

      However clearly in many cases content is better edited through traditional forms (no one wants to try to build/parse a product discount matrix written using a WYSIWYG editor). So typically in these scenarios ContentTools is used to enhance the functionality of an existing CMS not replace it. For example on an eCommerce site users might add a blog/page/product using a traditional form but when they wish to edit the item's content the CMS would switch to a front-end preview of the item and allow the user only to update the relevant content (e.g the content of a blog article or page, the description for a product).

      ContentTools does not attempt to replace the CRUD facilities of a CMS (it's beyond the libraries scope) but rather to provide users with a more natural editing environment.

      Hopefully that helps answer your question, if you keep an eye out next week for the tutorial on integrating the library into a CMS I'm hoping top provide some screencasts showing how we've achieved this on different sites.

      0 points
      • Ashley CyborskiAshley Cyborski, 8 years ago

        Ah I see, yes that makes perfect sense. I think the question arises out of a need to satisfy the non-technical clients who want a simple-to-manage site but don't want to pay for or deal with a backend CMS of any sort (the mythical unicorn). Your explanation makes perfect sense and, again, I really like the overall design and intuitive UI. I may put this into use in the future :)

        1 point