-
-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Admin GUI #123
Admin GUI #123
Comments
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 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 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. |
I guess the big question after version 1, is how should the GUI develop.... Seems we have these options (they are not mutually exclusive):
I guess now is to think about what type of use cases for the GUI we have, and which options address them:
Possible combinations:
|
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 :
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 :
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: 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 |
Here's my thoughts on the whole thing: https://gist.github.com/2906284 |
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:
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 On Mon, Jun 11, 2012 at 3:52 PM, Jamin <
|
Here are my current thoughts on how we can break this down into steps:
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 |
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. |
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: to be feasible |
nide doesn't seem maintained anymore, however adobe has created their own thing here: https://github.com/adobe/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 <
|
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 2013/6/27 Benjamin Arthur Lupton notifications@github.com
|
also this one seems really sexy! francisco arenas 2013/6/27 francisco arenas francisco.arenas@dospuntocero.cl
|
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? |
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 [image: dospuntocero] Francisco Javier Arenas Ulloa 2014-06-10 8:39 GMT-04:00 Goran Aleksic notifications@github.com:
|
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' But i prefer docpad. |
i think i can mix baked.js with a project of mine called gulp+jade+sass i will try to do that in the next days. [image: dospuntocero] Francisco Javier Arenas Ulloa 2014-06-12 4:36 GMT-04:00 Goran Aleksic notifications@github.com:
|
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, [image: dospuntocero] Francisco Javier Arenas Ulloa 2014-06-12 10:48 GMT-04:00 Goran Aleksic notifications@github.com:
|
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. |
As a User, I want a GUI, so that I can better interact, discover and use docpad
Implementation
Steps
docpad/gui
docpad/bin/docpad-gui
docpad/bin/docpad-cli
docpad/bin/docpad
spawn both of those bin filesCaution
Notes
Relatives
Depends on
Enables
The text was updated successfully, but these errors were encountered: