Widgy: Open Source Python/Django CMS Framework | Hacker News Reader

Widgy: Open Source Python/Django CMS Framework

wid.gy

71 pointsrahimnathwani43 comments

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.

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.

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.

Because they've only dealt with the most simple of use cases, and have no idea that the world is bigger than their little circle.

The classic signs are usually upfront, presenting the product as the holy grail, in this case "The very last CMS framework you will ever need". Anybody with any experience knows that this cannot possibly be anywhere near true, not even if technology stops evolving altogether.

You see this pattern nearly every day on HN. A language, a framework, a design pattern, a database, a methodology.

Our industry is like playground for juvenile fundamentalists who all believe in the One True Tool.

The classic signs are usually upfront, presenting the product as the holy grail, in this case "The very last CMS framework you will ever need". Anybody with any experience knows that this cannot possibly be anywhere near true, not even if technology stops evolving altogether.

I think the ", like ever" indicates that their tongue was in their cheek when they wrote that.

Could you given an example for a CMS that you consider good in this regard? Hierarchies are a very powerful information-organization tool, so although I agree that not everything should be hierarchical, I am wondering whether the alternatives are much better, or would they lead to a disorganized mess.

This is exactly how I feel. I really thought that this kind of backoffice design was a pattern that was universally hated and killed off. Making users drill down through menus (which already makes the mistake that end users understand a developers idea of a taxonomy and naming conventions) to get to content completely out of any context of the site is a horrible strategy. Joomla and typo3 have always been particularly bad examples of this but they are so "mature" that it's understandable why they have that stance. I don't feel like there is any reason for that model here.

That's the one thing I liked about Typo3, that it insisted on heirarchical placement of a page in the nav.

I think to understand the reason for the above is that those systems appeared before 'tagging' and loose content relationships.

Working with Drupal, I know it can become confusing when you mix the two. Menus,tags or both? What if content should appear in more than one place? It's an area that is can be confusing for site admins and users.

Drag and drop is popular. We are just less and less used to the paradigm, and don't expect it to work in the browser. I don't think there is much wrong with the approach, but there is a blur between app/OS interfaces and web ones. For example if that widget kit was a separate window like say the old Gimp toolset, it would feel okay to me.

The placement on the RHS is a little awkward, especially if there is scrolling required.

The commit process was confusing for me in trying to publish a page, but I found the CMS more intuitive than something like Joomla, that I feel out the box is a train wreck (it takes a good while to fit the pieces together/learn how to use).

There's scope for better CMSs that's for sure.

Native drag and drop is popular, but I'd hazard to guess that most people are more comfortable selecting individual files or groups of files via a file dialog than they are dragging them onto a web page.

I can't think of any file dialogue that lets you select groups of files (at least native ones), so you are entering non-standard territority to do so, which is further afield than the drag and drop.

Holy god, this comment is awful.

Instead of encouraging an open source project, it punches the developers in the stomach.

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

It's not a fork. It's using Mezzanine to structure the tree of pages, but Widgy is used to edit content on the pages themselves.

Basically, we made a really good content editor and wanted to get running quickly, so put our content editor in a Mezzanine page type. However, Widgy is a generic tree editor so potentially could be used for the page tree too.

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/... - 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... - a tutorial for getting started with Mezzanine and widgy.

[edit -- formatting]

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.

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

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

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

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.

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.

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

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?

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.

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.

Wagtail (https://github.com/torchbox/wagtail/) does not use the Django admin. It leaves it completely alone. It really is just another Django app. Highly recommended.

Widgy doesn't require the Djange admin. You can attach a widgy content editor to any model.

So widgy could by used with Pyramid via sqlalchemy?

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.

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

It seems to work pretty well.

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.

I love the Djqngo admin, and use it a lot at my day job, but it does seem to be a PITA to try and do non standard things with it (say add an extra button). And it always looks like the Django admin - its a great set of sensible defaults, but often you don't want that.

I am currently trying to learn the ins and outs of generic views with djang-extra-views, so that I can hopefully do as much, but without the restrictions of the admin.

django CMS 3 [1] still uses the underlying admin system (for it's CRUD views etc), but moved all editing into the frontend, thus making it more friendly to content editors.

[1] https://www.django-cms.org/en/

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

But is obviously tongue in cheek.

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.

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

But the _Commit change_ button is deactivated.

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

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.

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

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

Reply on news.ycombinator.com