Admin GUI
Closed this issue · 72 comments
As a User, I want a GUI, so that I can better interact, discover and use docpad
Implementation
Steps
- Make docpad event driven #60
- Create a gui.docpad project that will prototype the interface
- Prototype the interface
- Bring interface into docpad repository to
docpad/gui - Start docpad gui with
docpad/bin/docpad-gui - Move docpad cli to
docpad/bin/docpad-cli - Make
docpad/bin/docpadspawn both of those bin files
Caution
- Will eventually support deployment (future task)
- Will eventually support selecting plugins from a crowd-sourced plugin repository (future task)
- Will support turning watching on and off
- Will support a setup guide #62
Notes
- Interface must co-incide and work simultaneously with the CLI
- DocPad API should still be accessible
- Will support on-demand generation
Relatives
Depends on
Enables
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.
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 :
- RDFa semantics in the markup
- 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
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:
- Get the authentication and rest plugins going with DocPad v6
- 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
Prose is also an interesting approach, though I think Create.js would still be a better front-end. I'll have to look at their code to see how easy the integration would be.
I looked at it briefly too, and I somehow agree with you. Prose is
"just" a text editor over github. It supports metadata (cool) though.
It lacks semantics though, which I think is the key point of decoupled
CMS.
Khalid aka DjebbZ
@Dj3bbZ
Le 26 juin 2012 à 11:53, Henri Bergius
reply@reply.github.com
a écrit :
Prose is also an interesting approach, though I think Create.js would still be a better front-end. I'll have to look at their code to see how easy the integration would be.
Reply to this email directly or view it on GitHub:
#123 (comment)
Prose implementation is dependent on prose/prose#246
Cloud9 implementation is dependent on c9/vfs#27
Brackets implementation is now possible, see task #357
All implementations are dependent on a Commit Plugin which is possible, see task #358
Created https://github.com/docpad/docpad-plugin-nativecomments to showcase how one could go about adding GUI related parts to their DocPad app.
Just a crazy idea.
Could we use source maps to solve the pre-processor contenteditable problem? Of course that wouldn't work for programming markups like eco and coffeekup. But it could work for markdown to html conversions perhaps?
I'm wondering if with the new https://github.com/docpad/docpad-plugin-ghpages plugin if the to-be editor could deploy to a github pages preview website?
The to-be commit plugin could push to a "preview" branch and maybe with the help of the ghpages, this could become the online preview page. This preview page could also work as a way to provide access to a live website in-progress and maybe have BugHerd installed to collect feedback. This is just an idea. I don't know if it's even technically correct/possible to use Github Pages for the preview page.
This is an awesome idea!
On Mar 12, 2013 11:02 AM, "Michael Duane Mooring" notifications@github.com
wrote:
I'm wondering if with the new
https://github.com/docpad/docpad-plugin-ghpages plugin if the to-be
editor could deploy to github pages preview website?The to-be commit plugin could push to a "preview" branch and maybe with
the help of the ghpages, this could become the online preview page. This
preview page could also work as a way to provide access to a live website
in-progress and maybe have BugHerd installed to collect feedback. This is
just an idea. I don't know if it's even technically correct/possible to use
Github Pages for the preview page.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-14792149
.
Nice idea ! But IMO requiring an internet access and pushing data remotely
is bad for the UX, because it makes up for a longer feedback loop.
Everything should be local, and pushing to ghpages with the plugin
mentioned would just be an action the developer would want to do, not be
required to.
On Tue, Mar 12, 2013 at 7:25 PM, Jehan notifications@github.com wrote:
This is an awesome idea!
On Mar 12, 2013 11:02 AM, "Michael Duane Mooring" <
notifications@github.com>
wrote:I'm wondering if with the new
https://github.com/docpad/docpad-plugin-ghpages plugin if the to-be
editor could deploy to github pages preview website?The to-be commit plugin could push to a "preview" branch and maybe with
the help of the ghpages, this could become the online preview page. This
preview page could also work as a way to provide access to a live
website
in-progress and maybe have BugHerd installed to collect feedback. This
is
just an idea. I don't know if it's even technically correct/possible to
use
Github Pages for the preview page.—
Reply to this email directly or view it on GitHub<
https://github.com/bevry/docpad/issues/123#issuecomment-14792149>
.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-14793759
.
Khalid Jebbari
Good call. Publishing to ghpages every time to see a preview isn't ideal. Didn't consider that.
@DjebbZ Requiring an internet connection is bad for the user experience? I don´t follow you there. Aren´t you talking about the developer instead of the user? The issue at hand here is an edit interface for the user. You´re bound to need an internet connection for that (it´s not like we expect the user to check out the sources).
If the deployment to ghpages is light & fast enough, then it may be a good approach. It is one approach and the cool thing about Docpad is there may be many different paths to the same end. I was thinking yesterday that you could have a flavor that leveraged Nodejitsu's continuous-deployment so as to when you click a preview button on the Docpad Admin UI, the commit plugin pushes to the preview branch from where Nodejitsu re-deploys from that branch into a sub-domain like preview.website.com. However deploying from Nodejitsu always takes a couple minutes to complete so maybe this is just another potential feature of the commit plugin. The same preview story may work for Azure and others as well.
Long story short, as long as it doesn't take minutes to see a preview, maybe like 10 seconds a developer may wait to see a preview. However a end-user editing their website wouldn't want to wait more than 3-4 seconds max I'd imagine.
Published this last week, but turned out to be the wrong issue (silly Ben)
To add to the brainstorming, what about the following circumstance:
- Spawning another DocPad instance that does a one-way import of the main DocPad instance's database (work has begun on a sync plugin)
- Use this secondary DocPad instance for previews
- Provide an API for performing previews and fetching the result
This way:
- previews are completely isolated from the live server
- will work offline
- can support multiple users, by spawning a secondary docpad "preview" instance for each user (imagine multiple users editing the same layout)
Actually, we could probably do this without the cross-process communication by just having multiple instances on the same process, this shouldn't be too hard to do with the docpad API.
I'm all in favour of whatever works (adds value to people) though, I'm not fussed either way in regards to technical implementation - as long as it adds value to enough people, I'm happy.
Offline editing and "multi-player" editing is something I've been dreaming of in a website for a year now so it gets my vote. Sounds like a good way to go about it. Publishing the preview to "preview.website.com" would work well in this setup as well with the synced DocPad instance acting as a staging server of sorts.
Check out this awesome work by @cauld - it's the closest we have to a CMS interface right now :) So huge preps to him for making this happen: https://github.com/cauld/docpad-collections-editor
Wow. Even if this is not what I envision for a GUI, it still looks pretty
good. Congrats, @Claud !
On Fri, Mar 29, 2013 at 2:08 PM, Benjamin Arthur Lupton <
notifications@github.com> wrote:
Check out this awesome work by @cauld https://github.com/cauld - it's
the closest we have to a CMS interface right now :) So huge preps to him
for making this happen: https://github.com/cauld/docpad-collections-editor—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-15639957
.
Khalid Jebbari
Yeah. Looks very nice, I wil definitely give this a try. Thanks a lot!
@Claud, small point of feedback: would it not be better to pull the configuration (/path/to/docpad/node_modules/docpad-collections-editor/config.js) out of the node_module directory? Most of us have node_modules in their gitignore, and I believe some command line docpad/npm options might delete this file real easy?
Hey @Claud this is awesome and I agree with the ReadMe, our client's simply can't use it without such a editor.
I also double what @Krijger is saying. node_modules/ is in all my DocPad project's .gitignores. I'd imagine that Docpad will grow into more commands as well which one might be a short cut to initializing this duel port DocPad. Another example of such commands could be a command that will run through and index files (for indexed searches or to read/embed semantics) or clear caches.
Speaking of the config file : the plugin should place its configuration the global docpad config file. Also, the password shouldn't be placed in the config, but imported from another file that is not under version control.
Also, these discussions shouldn't live here but in the project's issues, so I just created one and copied the content of this discussion starting from @balupton's PSA :)
cauld/docpad-plugin-dce#1
Thanks everyone! I'm pleased to see others find this useful. Feedback is definitely welcome. @balupton actually pointed me to this thread after I had pretty much finished the first version of DCE. I didn't realize a GUI conversation was already underway. Perhaps we can continue morphing DCE into the GUI people have been envisioning.
@DjebbZ thanks for adding this as an issue on the project page.
Just a crazy idea, but I wonder if hooks for plugin code to latch onto is a approach to avoid having to start the app from within the plugin folder for DCE here on point 3.:
https://github.com/cauld/docpad-collections-editor#setup
(posted this here as it's more a DocPad related than DCE)
I tried @cauld's DCE and it works allright. So which would be adopted on the long run? DCE or the one mentioned in this issue?
That's up to you. The DocPad core will facilitate importers - so you can use anything as GUIs. GUIs are in the scope of userland.
For anybody that could be interested, I made my own docpad GUI as a plugin: https://github.com/jeremyfa/docpad-plugin-minicms
It is quite simple, but it works. And don't get me wrong: I really like the idea of in-place editing, and rest-based editing that we are talking about on this thread, but I needed something that works right now so I made something more basic that I can use.
Some thoughts on my own. i come from the CMS world too, i have used all the bloated ones (aka Drupal, Joomla!, etc), wordpress and others. but no one seems to understand we target 2 totally different markets with a cms, as @DjebbZ said on its first comment, a CMS is for the final client, not for devs like us. so saying that, and after a couple of years playing with different CMSs, i've found Silverstripe, and i can say its the most amazing CMS i know, because:
- it's a framework for developers (a really good one, good documentation, but not flawless)
- it doesn't show anything design/coding related to the final user (which is excellent)
- their CRUD is amazing
- the admin backend is really simple for the final user and you can teach them how to use it in like 10 mins.
@jeremyfa did an impressive job with his GUI, it was an instant crush. its like silverstripe for docpad, i really love the idea, i will try to test DCE this days (i watched a video about it, but not tested yet) and i strongly believe this is the way to go. i can help to style the cms once its working, but lets focus on the important thing here now: we need to agree on whats the best way we can mix DCE with MINICMS to make this to work.
for a common site to work, we just need some GUIs for adding data, like a flexible grid (repeated objects on the same page, like for example if you are hosting an event, the ability of adding each speaker in a easy to fill form that can be repeated every time the client presses the [+] button) and some file/image uploaders. i tried to make @jeremyfa minicms image uploaders to work but i couldn't on my local environment or heroku, so i think its better to make a simple connection with the inkfilepiker which is amazing for handling files and it leaves us with lots less problems, since file handling is a pain.
regarding @balupton 's idea of think of it as the interface and architecture of BugHerd clashed with the content and site editing abilities of SquareSpace, as @DjebbZ said, the client already approved the design, so a squarespace like interface is an overkill and we will take lot of time on something that is not that important for the final user, that kind of interface is for people that wants to take an already made design and make some tweaks to make it look a little bit different... lots and lots of work for no reason actually... i strongly believe that the client must sign the design before any coding, so he can't do any changes on it on the development phase. i have 5-6 years of experience working like that and it leads to successful finished products.
you can see silverstripe mockups in this repo you will notice their design is pretty simple, but its really powerful.
so... (so much publicity on silverstripe... why dont you get out of here and use it?? - all are thinking, i know...)
because its SLOW AS HELL, the cms is amazing but you need a 4core vps with lots of ram and opcode cache running for making it work smoothly... and i believe thats an overkill for just serving content we can serve as static files.
my 5 cents.
I would caution against any of us styling GUI interfaces ourselves. If the
designer is unable to work on the project in the future, any subsequent
developers will be out of luck. Bootstrap or Foundation are more than
sufficient, and will allow future devs to move the project forward without
the original designer.
On Fri, Jun 21, 2013 at 7:20 AM, Francisco arenas
notifications@github.comwrote:
Some thoughts on my own. i come from the CMS world too, i have used all
the bloated ones (aka Drupal, Joomla!, etc), wordpress and others. but no
one seems to understand we target 2 totally different markets with a cms,
as @DjebbZ https://github.com/DjebbZ said on its first comment, a CMS
is for the final client, not for devs like us. so saying that, and after a
couple of years playing with different CMSs, i've found (Silverstripe)[
http://silverstripe.org], and i can say its the most amazing CMS i know,
because:
- it's a framework for developers (a really good one, good
documentation, but not flawless)- it doesn't show anything design/coding related to the final user
(which is excellent)- their CRUD is amazing
- the admin backend is really simple for the final user and you can
teach them how to use it in like 10 mins.@jeremyfa https://github.com/jeremyfa did an impressive job with his
GUI, it was an instant crush. its like silverstripe for docpad, i really
love the idea, i will try to test DCE this days (i watched a video about
it, but not tested yet) and i strongly believe this is the way to go. i
can help to style the cms once its working, but lets focus on the important
thing here now: we need to agree on whats the best way we can mix DCE with
MINICMS to make this to work.for a common site to work, we just need some GUIs for adding data, like a
flexible grid (repeated objects on the same page, like for example if you
are hosting an event, the ability of adding each speaker in a easy to fill
form that can be repeated every time the client presses the [+] button) and
some file/image uploaders. i tried to make @jeremyfahttps://github.com/jeremyfaminicms image uploaders to work but i couldn't on my local environment or
heroku, so i think its better to make a simple connection with the
(inkfilepiker)[http://inkfilepicker.com] which is amazing for handling
files and it leaves us with lots less problems, since file handling is a
pain.regarding @balupton https://github.com/balupton 's idea of think of it
as the interface and architecture of BugHerd clashed with the content and
site editing abilities of SquareSpace, as @DjebbZhttps://github.com/DjebbZsaid, the client already approved the design, so a squarespace like
interface is an overkill and we will take lot of time on something that is
not that important for the final user, that kind of interface is for people
that wants to take an already made design and make some tweaks to make it
look a little bit different... lots and lots of work for no reason
actually... i strongly believe that the client must sign the design before
any coding, so he can't do any changes on it on the development phase. i
have 5-6 years of experience working like that and it leads to successful
finished products.you can see (silverstripe mockups in this repo)[
https://github.com/silverstripe/silverstripe-design] you will notice
their design is pretty simple, but its really powerful.so... (so much publicity on silverstripe... why dont you get out of here
and use it?? - all are thinking, i know...)
because its SLOW AS HELL, the cms is amazing but you need a 4core vps
with lots of ram and opcode cache running for making it work smoothly...
and i believe thats an overkill for just serving content we can serve as
static files.my 5 cents.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/123#issuecomment-19818555
.
@jtremback and/or Purecss! XP
http://purecss.io/
well, you can always leave a styleguide and some good less/sass files. pure seems to be a really good alternative, but its really lame in terms of styling, meaning, there is no base theme like in bootstrap for example, but i believe its a really good choice. I personally like foundation, but as i told you before, i can use any of those and provide a styleguide for the cms. so any can work on it in the future, we can buy one too... thats the other option, like the ones on wrapbootstrap ( i like this one in particular ) but i think this must be something that we can choose in the future. first lets develop a great backend, then we can provide themes for the cms and anyone can use their preferred framework.
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.cl2013/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?
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?
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'
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'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.