Hacker News Reader

Comment by etchalon | Hacker News Reader

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.

View on HN

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.

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.

Holy god, this comment is awful.

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

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.

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.

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.

Reply on news.ycombinator.com