Postponed to the February milestone, as #125 (interactive cli) would have to be done first, and enables most of the same important functionality as this gui would offer.

What's going on here? I actually started making my own system since Docpad didn't have a GUI... Got bored so came crawling back. Now I use Docpad with Cloud9 running on my server to edit documents.

So what's the idea of the GUI? Are you talking about a native (e.g. Qt) application or a web interface? I'm just curious...

The plan has evolved over a lot over the first thought. Initially our thought was cloud9 integration for editing with an admin backend on a different port.

However, now, and thankfully the plan is to create a frontend "sidebar" which expands over your website and provides realtime inline editing abilities as well as well as site configuration and everything else you'd expect from a backend admin - however through an incredibly intuitive and ground breaking ui.

Think of it as the interface and architecture of BugHerd clashed with the content and site editing abilities of SquareSpace.

It may sound crazy to traditional backend admin people, however I have absolutely no doubt in me, that this direction will be amazing in every way.

It sounds... Interesting... As long as I've got my backend I'm happy ^.^

Hi guys, hi @balupton

We (@jamon888 and me) thought a lot about how the UI should be. We both come from the CMS world with a background of several years on Drupal, Wordpress etc. Frankly : all the CMSes are a pain. Really. So we would love too a GUI for DocPad. Here are our thoughts on the direction the UI should take IOHO.

DocPad is a tool for web developers like us. Not necessarily incredibly skilled developers, but web developers/hackers/designers. As it is now, it's already very good for us using it. @bobobo1618's comment prove it : "As long as I've got my backend I'm happy ^.^". This is the crucial point for the UI development. DocPad is used by people who don't fear a few commands in the Terminal/Console, who are fine with templating languages, who understand the web from a technical point of view, who know how to segment the various parts of a webpage into documents, layouts or partials. We really don't need a UI for this, and we won't use it even if it exist I think, partly because we prefer a text editor and a console (geek inside), partly because no UI can give the flexibility and speed these tools (editors+console) give us.

So we think the UI should target the end user of the site, aka the "client". This client is not a techie like us, but is someone who want to update the site's content : add a blog entry, edit an existing page, hide/delete another. He may need to change the navigation links (if any). But we won't do anything related to the site's structure, to the design, or to DocPad's configuration. This really is what our experience with CMSes tell us. For instance, with a tool like Drupal, one could create a minimalist backoffice focused on site's content. And this is what we always do : hide admin's options and expose content editors ones.

In this regards, the UI should focus on content edition, nothing else. This keeps DocPad lightweight and focused on what it is already : a document generator. Our experience also teaches us that trying to create a product that targets at the same time the devs and the content curators ends up with a messy software, hard to use, hard to maintain, hard to evolve. Drupal is a very good example, and believe me, after 3 years of doing Drupal I still have problems saying I'm an expert. Which is a shame after such a long time using solely this technology. A reason why mixing developer experience and content creator experience is a bad idea is because both people have very different needs, that are hard to mix in one solution. You risk to end up with something that satisfy none.

The developer experience of DocPad is good. It's all about using a few npm and docpad commands and structure properly a set of files in various directories. Almost nothing more, apart for the one who wants to use collections or write plugins. Then it's all good. We also have experience with online tools that provides an interface to edit HTML/CSS files (Tumblr, CargoCollective). In one word : horrible. Windows notepad is even better. And you don't see the results of what you do. This is where trying to mix various experiences sucks. Editing such files should be done in a editor by a developer, nothing else.

After looking at various editing interfaces for online website management, we came to a similar conclusion than @balupton. No editor like cloud9, but a sidebar directly usable from the front-end, a bit like what Tumblr do. The difference between @balupton's vision and ours is regarding what tools are available to the end user. We deeply think that nothing about the design (read : the appearance) of the website should be available. Here's why : the design is generally done beforehand by the developer (with or without the help of a real designer) and signed off by the client. So the client is already happy about the design, because the client is not a designer at all. If he were, he would have either created the design himself, or he would be in the capacity to edit markup and CSS files, which almost make it a good candidate for being a "DocPad developer". What the client wants at the end of the dev process is a mean to curate his content. This is where the focus of DocPad GUI should go in our opinion.

To validate this model, we would like to create this GUI, test it in the real world on client's projects, and use clients feedback to shape it. We are a team of 4 people, one designer and 3 devs (2 are very skilled Javascript guys, I'm the beginner in the group :). @balupton just created a repo for it : https://github.com/bevry/docpad-gui, so we're going to use it for our tests.

But before dwelling in any kind of code, we really want feedback from you all. We don't pretend to have the holy science, and absolutely don't want to work alone, without any community discussion before.

What do you think ?

I've also been toying around with the idea of creating a system like this. Checked out a million other static site generators and ended up here finally. Wanna give a huge +1 to @DjebbZ's post. Not sure what @balupton's vision is exactly, but I don't see much need to provide an interface which allows for anything more than creating, updating, and deleting content / data. That is, providing an interface allowing changes to be made to a website's "model", and leaving it to the developer to create a "view" setup which reflects said "model".

However, it seems to me that this feature request is aimed at the "User" of DocPad? I.e. the developer? If that's the case, @balupton's issue of implementing a developer interface and @DjebbZ's issue of implementing a client interface should be separated. And of course, their implementations should be separated. I don't mind a developer GUI as long as I have the option to turn it off ;) Naw jk, it'd be great to have a GUI, but personally, I feel a client interface is much more useful and should be prioritized. As @DjebbZ said, the developer experience with DocPad is already good.

And I'd love to help realize the client interface, btw!

Thanks for the comment, @seanfridman. After several discussions and reflexions, I wrote a potential roadmap for the gui : https://github.com/bevry/docpad-gui/wiki/Roadmap. It will be a separate project, use a few DocPad's plugin and allow content edition. Head over to read some details, and read also the other wiki page.

Let's use Twitter Bootstrap and jQuery UI Bootstrap for the first UI iterations (version 2 and on). Later on (or now) we can do a competition for designers to retheme it. That way we can get started with the practical stuff right away, with something that looks decent, and get hopefully world-class designers to improve it later.

Version 1 of the GUI has been scheduled for this month.

I guess the big question after version 1, is how should the GUI develop.... Seems we have these options (they are not mutually exclusive):

• Use Cloud9 to edit source code for complete control
• Be like SquareSpace and be able to control everything from the GUI
• ContentEditable clientside editing (a bit retarded as we can only edit text, so may not be that consistent)
• Modal clientside editing (though this could become like the SquareSpace option if not kept directly for pages)
• Outsourced CMS like CushyCMS or PageLime to edit pages and properties
• Backend CMS - Developer a CMS like the WordPress admin

I guess now is to think about what type of use cases for the GUI we have, and which options address them:

• Use Cloud9 - edit source code - developers, designers
• Be like SquareSpace - edit everything via a GUI - website owners, implementors, designers
• ContentEditable clientside editing - quick and easy edits - everyone
• Modal clientside editing - edit content and select properties - website owners, implementors
• Outsourced CMS - edit content and select properties - website owners
• Backend CMS - edit content and plugins - website owners, implementors

Possible combinations:

• Cloud9 and Outsourced CMS would satisfy everyone, but with Outsourced CMS you wouldn't get to edit themes and no preview?
• Cloud9 and Backend CMS would satisfy everyone, but the editing experience could be better (preview, but no live preview)
• Cloud9 and ContentEditable and Modal/SquareSpace would be pretty nifty (though a lot of work... unless we can find something like cushycms for clientside editing)

Looking at the CushyCMS documentation its quite a pitty that it's editing abilities are so poor...

We could easily make something like it, that uses the contenteditable semantic tags to do the editing in the right places. This combined, with contenteditable, and modals would offer a pretty good all round solution.

The question then becomes, should we use the same UI components for the client-side and backend? E.g. a modal on the client-side is a page in the backend admin.

And should the backend be able to overlay your frontend website? E.g. I'm editing on the client-side, and I click "backend", and it opens the backend above my current website instead of opening a new window.

Just thought I'd recommend against using Cloud9 as an editor. The code won't run with modern versions of node and hasn't for months. The devs seem to be quite content to leave it that way too.

After the talk I just gave about DocPad, I thought and discussed a lot about what could be the GUI. Still following the idea of a end-user GUI as opposed to a developer GUI, I realized that the contenteditable + RDFa semantics tags is a great idea.

After my talk, a guy pointed me to the Mercury editor which looks ok but based on css selectors and not RDFa, so linking it back to DocPad would be hard. Then I found the project (IMHO) : Create. The Create project is aimed at creating a front-end only web editing interface, focused on content edition capabilities, completely independent of any backend. The good news is that it's based on Backbone, and in order to work only needs 2 things :

1. RDFa semantics in the markup
2. Overriding of the Backbone.sync method

Given a proper backend, DocPad would be easily pluggable with Create, because we already agreed on producing RDFa tags and we already use Backbone models so we may be able to reuse them in the front-end.

It happens that Create offers enough content manipulation capabilites :

• it integrates a WYSIWYG editor, Hallo, that can be replaced by Aloha editor if preferred
• it edition of various content properties (title, content, etc.)
• this rocks : it's smart enough to recognize content within a list of content and don't mess with it
• this rocks too : you can give him different content types, so adding a blog post and a page can be different
• the toolbar of the Hallo editor can adapt to the content being edited and can easily be extended
• it already support image upload et resizing, as well as inserting video (YouTube and Vimeo)
• it saves a temporary version in localStorage so that if the end user forgot to hit "Save", his work is not lost
• and surely others features I'm not aware of... (I think it natively supports Github Flavored Markdown)

From a technical point of view, Create is based on VIE, a Javascript library for modeling content based on RDFa semantics that gives models, workflow and persistence.

See this blog post on the IKS blog and this slideshow on Google+ (a series of photo) to view Create in action. It has already been implement in Midgard2 CMS (where it came then was decoupled from) and in OpenCMS (here is a nice video showing it in action)

It happens that Create doesn't stem from nowhere, but follows the (good) trend of Decoupling Content Management. The author of this blog post has several other interesting posts and is deeply engaged in this movement. Don't hesitate to read it, as well as the (half a year old) discussion on Hackers news about Create and other similar tools and decoupled editing interfaces. It's not a "one-man" project and looks well supported. To quote the main page: Create.js is free software developed by Henri Bergius and the Midgard Project in collaboration with IKS and co-funded by the European Union

TL;DR : I'm all for the ContentEditable road. Let's implement Create on top of DocPad, using the default capabilities and see how it goes. It should be a very good starting point.

So far, I was thinking that a plain text editor would be sufficient to edit the contents of a post using markup.

After testing the demo of Create, I have to admit that the usability of in-place editing is greater than editing in a side panel while refreshing a preview in the main panel.

As for creating new pages, it could be as simple as cloning an existing page or an empty prototype page (not published).

I also thought about the idea of an empty prototype page

I don't know how it works in the Create demo, but entering the Edit mode (clicking "Edit") a new "Add" button appears at the bottom that lets you add a new paragraph with 2 "fields" : [title] and [content]. Maybe Create is capable of understanding the structure of a content-type based on existing content (using RDFa and mapping to a Backbone model), or it has to defined before.

If the former hypothesis is true, great ! If not, it would require a new DocPad feature to specify a "content-type" prototype. Maybe a new "prototype" or "content-type" folder, with default values for a content of certain type, that would give a new contentType metadata available to documents to enforce those default values. It's just an hypothesis though.

Here's my thoughts on the whole thing: https://gist.github.com/2906284

/cc @bergie @DjebbZ

Essentially, as far as DocPad is concerned, all we care about is authentication and rest.

Anything involving a editing interface should be an entirely separate and independent project (albiet with a docpad plugin, or self-hosted solution with docpad integration). For instance:

• contenteditable interface, accomplished via a CreateJS plugin
• end-user admin interface, accomplished by writing something like CushyCMS that handles semantic data (this is an interesting business opportunity, could be a free docpad plugin, but for hosting, docpad and SemanticCushyCMS could be paid services)
• code editing interface, accomplished via local text editor, or cloud 9

Etc. So @bergie any ideas on the best way to go about this? While we should do a skype chat, lets use this topic to spurt out all our ideas on docpad integration of such things. I'd also like to start doing weekly 15 minute google+ hangouts to facilitate and lead development of this and other docpad/bevry stuff.

I think that saying docpad is for "writing website" is not a bad idea but i would rather say "writing responsive website".The mobile and tablet side of the docpad platform should be precised in com materials.

As an editor i think this one : http://xing.github.com/wysihtml5/, actively watched in github and forked, should be the foundation of editing in docpad.

Why not have a choice of editors?

I personally would prefer something that allows me to edit the markup
directly while seeing the output HTML live.

On Mon, Jun 11, 2012 at 3:52 PM, Jamin <
reply@reply.github.com

wrote:

As an editor i think this one : http://xing.github.com/wysihtml5/,
actively watched in github and forked, should be the foundation of editing
in docpad.

---

Reply to this email directly or view it on GitHub:
#123 (comment)

Here are my current thoughts on how we can break this down into steps:

1. Get the authentication and rest plugins going with DocPad v6
2. Create a new admin plugin that will create a server on a different port, and display a login screen, once authenticated, it will load in the website inside an iframe with the admin scripts injected

We can then write plugins to hook into this injection step, for instance we could have a sidebar that can be hooked into (to provide such things as file listings and source code editing), as well as inject createjs into the iframe for contenteditable.

This seems to be the biggest impact, least work approach.

The biggest hurdle that I can see if figuring out a way to commit changes, and push them back to the source git repository. Whether or not we do this automatically behind the scenes, or via a save interface, I'm undecided.

The other major hurdle will be allowing DocPad to "preview" changes without affecting our current live website... until the changes are committed. Perhaps for this, we will need to copy or clone the website to a temporary directory and run it from there. Alternatively, we create a new docpad instance and inject the database and configuration from the previous one...

Those are the big hurdles...

About your thoughts @balupton : great ! Having a RESTful Docpad, capable of serving semantically enriched documents is a way to go. Plug-and-play UI is definitely a good idea, as the whole movement towards decoupled UI is. +1 !

I don't know if it makes sense but I was thinking more about having a true REST API built into DocPad itself, handling GET/POST/PUT/DELETE requests to URLs like /documents, /documents/:id etc. (URLs to be defined). As I'm just starting this work (I just created a local rest branch and added an empty rest action), I'm wondering if I'm doing this for nothing or if this is a good idea.

As a good technology preview i will suggest you to take a look at salon.io who is built on backbone (chaplin), live editing and adding content are done the good way for me ( i'm a huge cargollective.com site builder), also injecting custom css et html. decoupling the 'live' editing view with a 'production clone' is a good direction , sync changes when done to the live website.
Does it make sense ?

Create.js allows using different content editors based on the configuration you give it. Right now we support Hallo and Aloha editors, but there are people working on other widgets.

The editor being used should certainly allow writing plain Markdown, but as you can see in http://hallojs.org/markdown.html, you can also turn the HTML from a WYSIWYG editor into Markdown. The domchristie/to-markdown isn't perfect, but can be improved.

http://coreh.github.com/nide/ is sweet, will need:
coreh-deprecated/nide#57
and coreh-deprecated/nide#26

to be feasible

nide doesn't seem maintained anymore, however adobe has created their own thing here: https://github.com/adobe/brackets

screenshots:
https://github.com/adobe/brackets/wiki/Brackets-Screenshots

lol I thought that was a joke at first, like http://vanilla-js.com/

On Fri, Jun 21, 2013 at 11:35 AM, Michael Duane Mooring <
notifications@github.com> wrote:

@jtremback https://github.com/jtremback and/or Purecss! XP
http://purecss.io/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-19833045
.

purecss is awesome, and it has lots of years of development behind. actually its like the same as yui grids, they just changed the name of it and put some flat styling on top of it. i have experience working with yui like forever. i did some really powerful sites using yui in the past.

Just found http://vitalets.github.io/x-editable/ seems like we could use this to edit content (including markdown content) inline. Better than contenteditable as contenteditable you must have a two-way transform (markdown to html, then back to markdown from html) - with this, you still edit the source content - but inline!

i like it

francisco arenas
dospuntocero.cl
fb.me/dospuntocero.cl

2013/6/27 Benjamin Arthur Lupton notifications@github.com

Just found http://vitalets.github.io/x-editable/ seems like we could use
this to edit content (including markdown content) inline. Better than
contenteditable as contenteditable you must have a two-way transform
(markdown to html, then back to markdown from html) - with this, you still
edit the source content - but inline!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-20097198
.

also this one seems really sexy!
http://alecgorge.github.io/MarkdownEditor/

francisco arenas
dospuntocero.cl
fb.me/dospuntocero.cl

2013/6/27 francisco arenas francisco.arenas@dospuntocero.cl

i like it

francisco arenas
dospuntocero.cl
fb.me/dospuntocero.cl

2013/6/27 Benjamin Arthur Lupton notifications@github.com

Just found http://vitalets.github.io/x-editable/ seems like we could use
this to edit content (including markdown content) inline. Better than
contenteditable as contenteditable you must have a two-way transform
(markdown to html, then back to markdown from html) - with this, you still
edit the source content - but inline!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-20097198
.

I've setup the repo https://github.com/docpad/gui/issues to serve as a location for discussing and collaborating on everything related to GUIs for DocPad - with each issue being something that a GUI should implement, and providing a place for discussion for all GUI maintainers to participate on

It is not to replace any existing or upcoming GUI implementation, but more a place to facilitate their development and evolution along-side DocPad and other GUI implementations. Will be a great alternative than this one single long-winded thread.

Will close this in favour of that repo, especially as we already have several amazing GUI implementations thanks to the amazing effort by the community, which huge thanks to @cauld and @jeremyfa for their amazing contributions with dce and minicms

Hi there did you have a look at the Ghost Blogging platform ... it specializes on Blogging only, however it has some great ideas, particularly their markdown editor with live preview, worth a look and maybe able to integrate into DocPad?

http://ghost.org/ and https://github.com/TryGhost/Ghost

Yeah doing an importer for Ghost content into DocPad for rendering would be a great step.

For markdown live preview, check out: https://github.com/benweet/stackedit

I think https://prismic.io can be great content management for docpad.

Maybe it would be good to make a plugin?

@hivearts so cool!

@dashed also so cool!

Is it possible to integrate prismic fast with docpad ?

maybe a good place so start is here:

https://github.com/prismicio/javascript-nodejs-starter
https://github.com/prismicio/javascript-nodejs-starter

[image: dospuntocero]

Francisco Javier Arenas Ulloa
Front-end Developer, dospuntocero ltda.
Tel: (56) 032 - 328 01 94 | Cel: (56) 09 - 9352 7553
Nieto 93, Viña del Mar http://g.co/maps/km5ue
www.dospuntocero.cl | visítanos en facebook
http://facebook.com/dospuntocero.cl

2014-06-10 8:39 GMT-04:00 Goran Aleksic notifications@github.com:

Is it possible to integrate prismic fast with docpad ?

Reply to this email directly or view it on GitHub
#123 (comment).

Yes, i have tried but i didn't success.

I am not so familiar with javascript and nodejs...

Does someone want to make a plugin for prismic?

I want to use prismic in next few projects, they have build static site generator also called 'baked.js'

https://blog.prismic.io/U3TAFgEAAC8AwopU/bakedjs-integrate-content-management-into-a-static-website-generator-using-javascript

But i prefer docpad.

i think i can mix baked.js with a project of mine called gulp+jade+sass
https://github.com/dospuntocero/gulp-jade-sass

i will try to do that in the next days.

[image: dospuntocero]

Francisco Javier Arenas Ulloa
Front-end Developer, dospuntocero ltda.
Tel: (56) 032 - 328 01 94 | Cel: (56) 09 - 9352 7553
Nieto 93, Viña del Mar http://g.co/maps/km5ue
www.dospuntocero.cl | visítanos en facebook
http://facebook.com/dospuntocero.cl

2014-06-12 4:36 GMT-04:00 Goran Aleksic notifications@github.com:

Does someone want to make a plugin for prismic?

I want to use prismic in next few projects, they have build static site
generator also called 'baked.js'

https://blog.prismic.io/U3TAFgEAAC8AwopU/bakedjs-integrate-content-management-into-a-static-website-generator-using-javascript

But i prefer docpad.

Reply to this email directly or view it on GitHub
#123 (comment).

Fine, but why you don't try with docpad?

i think docpad is best match :)

im not expert enough... docpad requires that i learn coffeescript, node,
and a bunch of other stufff and then understand how lots of stuff works
together, my project uses just one entry point for data in the
configuration file. you can see there is a database.json file there, i just
need to add the part that calls prismic and put the result json so be
loaded there and thats it. docpad will take me a lot more time. my project
is not as dynamic as docpad, its just meant for static sites, you can
regenerate the site really easy, but its a total different monster. meant
for frontend designers more than devs i believe

[image: dospuntocero]

Francisco Javier Arenas Ulloa
Front-end Developer, dospuntocero ltda.
Tel: (56) 032 - 328 01 94 | Cel: (56) 09 - 9352 7553
Nieto 93, Viña del Mar http://g.co/maps/km5ue
www.dospuntocero.cl | visítanos en facebook
http://facebook.com/dospuntocero.cl

2014-06-12 10:48 GMT-04:00 Goran Aleksic notifications@github.com:

Fine, but why you don't try with docpad?

i think docpad is best match :)

Reply to this email directly or view it on GitHub
#123 (comment).

Anybody want to help with prismic.io integration?

As per https://discuss.bevry.me/t/deprecating-in-memory-docpad-importers-exporters/591?u=balupton this issue is now outside the scope of DocPad.