Skip to content
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

Closed
balupton opened this Issue Dec 29, 2011 · 72 comments

Comments

@balupton
Copy link
Member

balupton commented Dec 29, 2011

As a User, I want a GUI, so that I can better interact, discover and use docpad

Implementation

Steps

  1. Make docpad event driven #60
  2. Create a gui.docpad project that will prototype the interface
  3. Prototype the interface
  4. Bring interface into docpad repository to docpad/gui
  5. Start docpad gui with docpad/bin/docpad-gui
  6. Move docpad cli to docpad/bin/docpad-cli
  7. Make docpad/bin/docpad spawn both of those bin files

Caution

  1. Will eventually support deployment (future task)
  2. Will eventually support selecting plugins from a crowd-sourced plugin repository (future task)
  3. Will support turning watching on and off
  4. Will support a setup guide #62

Notes

  1. Interface must co-incide and work simultaneously with the CLI
  2. DocPad API should still be accessible
  3. Will support on-demand generation

Relatives

Depends on

  • #60 - event system
  • #125 - docpad gui

Enables

  • #62 - guided installation
  • #124 - happiness stats

This was referenced Dec 29, 2011

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jan 2, 2012

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.

@bobobo1618

This comment has been minimized.

Copy link

bobobo1618 commented Apr 7, 2012

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...

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Apr 7, 2012

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.

@bobobo1618

This comment has been minimized.

Copy link

bobobo1618 commented Apr 8, 2012

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

@DjebbZ

This comment has been minimized.

Copy link

DjebbZ commented May 15, 2012

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 ?

@sfrdmn

This comment has been minimized.

Copy link

sfrdmn commented May 16, 2012

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!

@DjebbZ

This comment has been minimized.

Copy link

DjebbZ commented May 16, 2012

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.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 1, 2012

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.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 1, 2012

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)
@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 1, 2012

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.

@bobobo1618

This comment has been minimized.

Copy link

bobobo1618 commented Jun 1, 2012

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.

@DjebbZ

This comment has been minimized.

Copy link

DjebbZ commented Jun 1, 2012

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.

@eric-brechemier

This comment has been minimized.

Copy link

eric-brechemier commented Jun 1, 2012

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).

@DjebbZ

This comment has been minimized.

Copy link

DjebbZ commented Jun 1, 2012

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.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 10, 2012

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

/cc @bergie @DjebbZ

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 10, 2012

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.

@jamon8888

This comment has been minimized.

Copy link

jamon8888 commented Jun 11, 2012

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.

@jamon8888

This comment has been minimized.

Copy link

jamon8888 commented Jun 11, 2012

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.

@bobobo1618

This comment has been minimized.

Copy link

bobobo1618 commented Jun 11, 2012

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)

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 11, 2012

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...

@DjebbZ

This comment has been minimized.

Copy link

DjebbZ commented Jun 11, 2012

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.

@jamon8888

This comment has been minimized.

Copy link

jamon8888 commented Jun 11, 2012

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 ?

@bergie

This comment has been minimized.

Copy link

bergie commented Jun 12, 2012

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.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 21, 2012

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 22, 2012

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

@jeremyfa

This comment has been minimized.

Copy link

jeremyfa commented Apr 30, 2013

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.

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 21, 2013

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.

@jtremback

This comment has been minimized.

Copy link

jtremback commented Jun 21, 2013

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
.

@mikeumus

This comment has been minimized.

Copy link
Member

mikeumus commented Jun 21, 2013

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

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 21, 2013

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.

@jtremback

This comment has been minimized.

Copy link

jtremback commented Jun 21, 2013

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
.

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 21, 2013

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.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 27, 2013

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!

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 27, 2013

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
.

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 27, 2013

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
.

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Aug 5, 2013

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

@balupton balupton closed this Aug 5, 2013

@searli

This comment has been minimized.

Copy link

searli commented Oct 15, 2013

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

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Oct 15, 2013

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

@dashed

This comment has been minimized.

Copy link

dashed commented Oct 15, 2013

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

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 10, 2014

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

Maybe it would be good to make a plugin?

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 10, 2014

@hivearts so cool!

@dashed also so cool!

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 10, 2014

Is it possible to integrate prismic fast with docpad ?

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 11, 2014

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).

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 11, 2014

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

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

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 12, 2014

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.

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 12, 2014

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).

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 12, 2014

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

i think docpad is best match :)

@dospuntocero

This comment has been minimized.

Copy link

dospuntocero commented Jun 12, 2014

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).

@hivearts

This comment has been minimized.

Copy link

hivearts commented Jun 16, 2014

Anybody want to help with prismic.io integration?

@balupton

This comment has been minimized.

Copy link
Member Author

balupton commented Jun 18, 2016

@balupton balupton modified the milestones: Admin Interfaces, Premium Offerings Jun 18, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.