
Widgy: Open Source Python/Django CMS Framework - rahimnathwani
http://wid.gy/
======
etchalon
Holy god, this is awful.

I'm not sure why developers continue to believe that "tree of widgets!" is a
good design for a CMS. It's horrendous.

First, most CMS users are end-clients who will have absolutely no clue to
handle a drag-and-drop dependent UI, let alone a nested tree of UIs.

Second, it encourages a site structure where the content is stored
hierarchically according to display requirements, instead of the actual
semantic relationship between elements.

While I'm sure this is very well coded, it continues the long tradition of
content management systems built by developers for developers and in such a
way only other developers will like or understand.

~~~
Pitarou
You make two very good points, but I think this tool still has some important
use cases.

I agree that this is a poor way to structure a whole site, but there's still a
need for a way to produce _ad hoc_ pages.

I also take your point about the tree of widgets thing, but there is always a
trade off between conceptual-ease-of-use and power. There are plenty of users
who will do just fine with this interface.

~~~
rockymeza
I work on widgy, so I admit that I'm very biased, but I'd like to expand on
this a little bit.

I think there are some use cases where the tree structure really shines, where
I haven't really seen anything that could really match the power that we give
the user. For example, the Form Widget -- users can create their own forms
just by dragging and dropping the form input widgets. Now this would be
possible without the tree structure, but since we have it in widgy, users are
able to intersperse non-form related widgets like text or images and also they
can add structure widgets like the Tabs or Accordion widget.

> I also take your point about the tree of widgets thing, but there is always
> a trade off between conceptual-ease-of-use and power.

We do find that our clients are willing to take a little time to learn the
interface in exchange for the ability to have more power.

------
legutierr
This seems to be built on top of Mezzanine--in fact, the word "Mezzanine"
appears in the upper left-hand corner in the admin in the demo.

Is this some kind of fork of Mezzanine, or is there something else going on
here? Is this meant to run on top of Mezzanine? In spite of similarity in the
admin, reading through the code quickly doesn't seem to reveal any clues (or
much of any similarity at all with the other project).

~~~
rockymeza
If you were curious as to how it is integrated with Mezzanine, here are some
links:

* [https://github.com/fusionbox/django-widgy/blob/master/widgy/...](https://github.com/fusionbox/django-widgy/blob/master/widgy/contrib/widgy_mezzanine) \- the widgy_mezzanine "contrib" app. It provides a Page subclass that has a WidgyField on it.

* [http://docs.wid.gy/en/latest/tutorials/widgy-mezzanine-tutor...](http://docs.wid.gy/en/latest/tutorials/widgy-mezzanine-tutorial.html) \- a tutorial for getting started with Mezzanine and widgy.

[edit -- formatting]

------
WimLeers
This is a PMS (Page Management System), not a CMS. With this, you can only
build _pages_ , not _reusable content_.

A CMS must be able to display the same content in different ways, display
content filtered according to relationships, and so on. Not to mention render
in other content types than just HTML.

I'm sure this is fine and fun to build pages with though!

Also: the demo is broken… so this is based on what seems to be their main
selling points.

~~~
insky
> A CMS must be able to display the same content in different ways, display
> content filtered according to relationships, and so on. Not to mention
> render in other content types than just HTML.

That's quite rigid. Good to ask the question: what is a CMS? It's pretty
ambiguous.

------
insky
+1 for having a usable demo to play with off the bat.

I tried to publish a simple page from the demo. But I did have problems:

I created a callout, and then created a page. I then tried to add the callout
to the page. And save as published. But I was hit with a message: need to
commit first? I didn't get that.

I then saved as a draft, and then hit commit. Not sure what was happening.

I then tried to view the page, but got a 'No content' message.

I then added something to the main content of the page. And saved. No change.

I then commited again. But still had the 'no content' message.

I then tried the commit and approve, which seemed to finally publish the page.

Confusion lies in the commit part, or in the publishing process, order of
process. Some buttons looked deactivated, but actually you can click on them,
like the 'Commit and approve' button. I was a little perplexed.

The demo then reset itself before I could test a form!

All feels slow to me. But then again most online CMSs feel a little like that
to me.

It was also quite difficult dumping widgets into areas. A little practice got
there, but it wasn't the easiest of things for me to do.

~~~
rockymeza
Thanks for the great feedback, I'm so sorry that you got hit by the cron job.

> +1 for having a usable demo to play with off the bat.

Thanks.

The idea behind the versioning system is that for a lot of our clients, the
people who are editing the pages are not actually allowed to publish them.
Those users will not see a Commit and Approve button, they only have the
Commit button. Later, somebody who has full privileges will review the commits
(either in the History or in the Review Queue) and decide whether or not to
approve those pages.

If you wanted to see the version that you were editing (we call it the working
copy), you can click on the preview button located next to the Commit and
History buttons. You can even test the form from the preview page and it will
still work.

> Confusion lies in the commit part, or in the publishing process, order of
> process.

I think you are absolutely right that this flow is confusing. We will talk
about how to make this flow better and more obvious.

> Some buttons looked deactivated

I opened an issue for that <[https://github.com/fusionbox/django-
widgy/issues/205>](https://github.com/fusionbox/django-widgy/issues/205>).

~~~
insky
I totally get 'workflow': draft, unpublished, approved, published etc, and
'roles': creators, editors, moderators, publishers etc. I also appreciate the
idea of having some version control.

With the demo it wasn't intuitive how the above applied to the post, or the
creation process. Order mattered, but it wasn't straight forward figuring out
the required process. Resulting in frustration.

You speak of a staging area, or some such. But how is the user to know about
your version control system, or how it works?

Surely hitting save should be as good a commit? Or the save implies or
triggers a commit? If the commit is that important to the publishing process,
emblazen it across the bottom with the Save button.

I really just wanted to see how my page looked as early as possible. And be
able to see the page before it was published. You should be able to preview
content, but make it clear that the status/workflow of the page you are
viewing: You could add a banner across an unpublished page with the page
status displayed.

------
healthenclave
Very well done! The best part of Widgy is the ability to create custom pages
and forms with drag and drop widgets.

I had been working on figuring out a solution such as this. The ability to use
this and extend the widgets is really powerful.

------
Pitarou
_[deleted]_

Forget what I said earlier. I thought Widgy was a CMS, but it isn't. It's a
page editor for a CMS.

In combination with Django CMS 3, this could be awesome. The Django CMS team
have put a lot of effort into moving as much of the administration as possible
into the front end. Widgy complements this with a slick drag-and-drop
interface for adding and rearranging page content.

~~~
ojii
django CMS 3 has drag-and-drop for re-arranging pages and the contents on the
pages themselves. Could you expand on what Widgy does better here?

~~~
Pitarou
Django CMS has a content view and a structural view, and they clearly want you
to spend most of your time in the content view. The structural drag-and-drop
interface is barebones and, to the naive user, it's far from obvious how the
nested lists of grey blobs relates to the actual content on the website.

In contrast, Widgy's interface attempts to be more like a WYSIWYM structural
editor. New widgets are created by dragging them from a widget palette.
Draggable objects represent their content in some way, and the physical layout
of the widgets and dropzones matches the layout of the webpage being designed.

------
rxdazn
My main problem with Django CMS frameworks is that they all use the django
admin which quickly becomes a PITA when you want to modify it. I'm really
starting to prefer rolling my own easy to use admin interfaces to trying to
override the django admin.

~~~
andybak
I strongly feel the exact opposite. I've worked with the Django Admin
extensively since 0.98 and it gets more flexible and easier to customize with
every release.

There's an astonishingly large ecosystem of widgets, extensions and additions
and having a single point of integration that (mostly) everyone agrees on
allows them all to work fairly well together.

There are things that I wish could be improved about the admin - mainly to do
with the slightly old-school HTML and CSS behind it - but there are so many
points where you can override, replace and extend that the good outweights the
bad.

~~~
crdoconnor
>There are things that I wish could be improved about the admin - mainly to do
with the slightly old-school HTML and CSS behind it - but there are so many
points where you can override, replace and extend that the good outweights the
bad.

I use this: [https://github.com/django-admin-bootstrapped/django-admin-
bo...](https://github.com/django-admin-bootstrapped/django-admin-bootstrapped)

It seems to work pretty well.

~~~
andybak
Except all the HTML is now different to the standard admin and lots of 3rd
party apps break.

Unfortunately - there is a limit to how much you can alter the admin HTML
without this problem. My own admin skins have been CSS only precisely to avoid
this.

------
syncopated
Their tagline reads like the "future proof" or "never obsolete" stickers on
90s mid-tower PCs.

~~~
glomph
But is obviously tongue in cheek.

------
programminggeek
My first expectation was to be able to click and edit content, Instead I got
pushed into a horrible tree structure of pages that got me to a tree structure
of editable widgets. Yuck.

------
kevcampb
Seems the admin interface is publicly accessible, which I assume is
intentional for demonstration. This can only end badly.

~~~
Pitarou
But the _Commit change_ button is deactivated.

------
solotraveller
nicely done! But the drag and drop editor feels slow and unresponsive,maybe
something like ckeditor would have been better.

------
JacobSingh
I'm a serious Drupal expert, but Python was my first love, I know Django and
I'm all for a usurper that can do it.

That being said, with an arrogant shitty attitude like this page shows, it
will never actually get there.

The most important facet of a CMS's success (or most software) isn't clean
dependency injection and scaffolding, it is a strong community and humility.

~~~
collyw
Was that written by a script? The words make sense individually but not as a
whole.

------
daenney
Just about everything is 404'ing right now (2014-05-13T09:23:00+02:00)

