Where Did It All Go Wrong?

I’ve watched MODx grow from the TV modification it started as in the original Etomite to what it is today. I remember the internal discussions about the direction when we all started with the fork, and how there seemed to be a strong commitment to mainstreaming the project and making it an accessible CMS to everyone who wanted to run a website.

The concept was supposed to be like those old Othello commercials from the 80’s: A minute to learn, a lifetime to master.

I come back every few months to check on the latest releases and see what direction the system continues to mature into. Personally, I’ve been saddened by the missed opportunities the project has had to grab the CMS world by its proverbial cajones in an effort to cater towards a more byzantine development platform.

We all started with Etomite because it was stupid simple. Making templates? Easy. Adding snippets? Easy. Customizing content? Easy. But Template Variables was different...a concept of easily adding additional variables to your templates without having to resort to programming.

With each iteration, TVs became more and more complex. You could do gazillions of things with them...practically anything you wanted. The problem grew from that time because there wasn’t any effort made to provide only the complexity the user needed or asked for.

Today, the Manager looks great. In many ways, the stock usability of MODx is more simple now than it was when it was a blue and orange interface. The problem is that terminalogy, extensibility, and most importantly the focus of the development efforts seem to assume a level of development skill that isn’t on par with what people looking for a CMS generally want or need. At least from the outset, the comprehension surface of MODx is more cumbersome than I think its original intent was meant to be.

MODx was proclaimed to be the first true AJAX CMS. People were paying close attention to the moves and accolades of the system. Instead of embracing the trends of making things easier, the team sought to aggressively build out the back end and make it more of a framework than an actual front end for content management.

With Revo and Evo on the perpetual horizon, I have even more concern for how this will all play out. Evangelists on the forums speak in a language that assumes everyone knows what everyone else is talking about, and there isn’t a lot of accessibility for the common user. The person who wants to download MODx, install it on a website, build a template, and host content has been lost in the shuffle.

Perhaps this was the intent, but I seem to remember differently. It was supposed to be about making things easier for Joe Q Webuser, not Jane P Softwaredeveloper. Any developer who uses a framework is leaning towards RoR, Zend, Cake, Symfony, etc. Isn’t MODx supposed to be the bridge between these script languages and the common user?

I write this as an open letter to the MODx team: Focus on the simplicity. Focus on the things the marketing team asked of the project in the beginning when we were trying to "Make our Mark" by looking to what makes things like the iPhone so wonderful. If Wordpress is the tool people use to blog, realize that MODx can fill the defacto niche of creating solid websites that don’t require months of learning to code to create or manage.

My love affair with MODx started because I could take a site to live quickly, and turn it over to non-coders who could use it for content management. I fear that as time continues to progress, those who eat their own dog food will continue to focus on what’s important to them, and forget about those that came here for the simple joys of the CMS, not a software development platform that caters to a whole different sector.

I could be completely wrong, and I’m sure that if the team responds it will be to explain in all the ways I am incorrect, but I wanted to offer my feedback from a distance. Either you can take it into consideration or blatantly ignore it because its easier to shoot down my concerns.

In the end, its up to everyone to determine what they put in and what they get out of an open source project. I know that those who started Etomite and those who continued it with MODx are unbelievably talented and if the direction has changed, then maybe they know something I don’t.

Thanks for the ear.

Hello SpeedStreet, nice to hear from you.

Let me start with a quote from one of my favorite musicians...

Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.
- Charles Mingus

I can’t speak for everyone here, but I can say that my vision for MODx, from the beginning is absolutely to make things as simple as possible for not just the CMS consumer, but also for the developers. MODx developers are the only ones who can produce components and libraries that make using MODx as simple as possible, so in my perspective, our primary goal at this point in the growth of MODx is to make it a more solid and attractive development platform for these folks.

MODx Evolution is just as simple as it was from the beginning; perhaps simpler. There will be some changes in Revolution that will make some uncomfortable at first, in order to further simplify and unify the concepts that make up the foundation of MODx. Once this new foundation is in place, you will be able to see exactly how much this will benefit MODx developers, and as a result, the non-developer CMS consumers.

I think there is a misconception that MODx is becoming more complex simply because of the increasing complexity of the "core" components that are included with the current releases of MODx. Combined with the terminology changes coming in Revolution, and I can certainly see where you can get the impression that it is becoming more complex. But that is precisely what we have been working extremely hard over the last 3+ years that Revolution has been in development trying to address. Are we taking the right direction? Are we creatively making the complicated simple or are we just producing another commonplace solution? I like the believe the former, but only time and our community will reveal the truth.

The problem is that no two end users want the same thing. Let’s look at a comparable ecommerce application, CubeCart. It’s dead simple to set up - except that every shopping site wants something different. So you have patches on patches and it quickly becomes a nightmare trying to figure out which patch is breaking what earlier patch. Just try upgrading a heavily modified CubeCart installation.

Neither MODx nor any other CMS can possibly be all things to all people. So what the MODx team is trying to do is make the basic site dead simple to set up, and the inevitable multiplicity of modifications and customizations as painless as possible, all the while maintaining a clear upgrade path.

Consider Ditto and Wayfinder. Both collect, sort and display lists of documents, albeit for different purposes. Originally both were relatively simple, and quite easy to use. But people wanted this, then more this, then that, and more that, until both grew and grew and still people weren’t satisfied. Now there’s PHx, and still every now and then somebody has to hack them to get just the layout or just the selection they want. If a simple menu listing snippet has to get a whole book written about how to use it, and still people want more, how can the CMS as a whole withstand the demand for variations on the theme?

Having developed a few nice mini-applications for MODx, then getting bombarded with demands for more and different functions and features, I can understand the need for making inherent complexity as simple and logical as possible.

Where did it all go wrong? As usual, with some clueless user. Well, that’s an oversimplification; usually it’s more like somewhere in a meeting room and involves a Photoshopped concept that looks real pretty, has no relationship whatsoever to reality, and is a nightmare to implement.

Very good to hear from you indeed John! I like your post a lot. I think you’ll find that MODx can be both simple for end users, and robust for developers.

We’re definitely more focused on the developers as Jason mentioned. Why? Because honestly that’s what we’ve needed as the core team to pay the bills with MODx. Supporting this project and continuing to develop requires a tremendous amount of resources (as in time and money), so we have to pursue what keeps us eating and puts clothes on the kiddos.

You can still spin up a site in no time with Evo/0963. It should get better in fact with Evo release as we’re still purging some legacy baggage and cleaning things up, making more consistent, and making it better for multi-language users. That said, I don’t think MODx in and of itself will ever be a website tool for instant awesomeness, no training required. However, it’s a great framework for folks to build those solutions and offer them as content packs and Add-ons. For sites that we set up it takes less than an hour to train end users to manage day to day. They find it incredibly liberating and empowering, and they’re fully custom sites that look EXACTLY the way they want them to look. And in that regard, I don’t think you’ll find many solutions in the same ballpark.

So, I don’t think we "went wrong" at all. Our original vision may have been noble indeed, and likely a bit naive, but over time it changed to reflect the reality of the world in which we’re (making a) living. If you need uber-simplicity grab iWeb and a Mobile Me account. We can’t compete with Apple in that regard. I’m sure there’s an analog on the Windows side of the world, too. But if your website needs stray outside of what those types of solutions offer, I’d argue that MODx makes it incredibly easy for Joe Q Webuser given a properly set up site. It might just take someone who’s a bit more savvy in the ways of the web development arts to set it up initially, which makes for a good MODx ecosystem I think.

Would love to hear your thoughts.

I decided on MODx back at 0.9.5 and was very glad I did. It was a closely knit thing back then between MODx and Typo3 (which is very big in Germany). I decided on MODx as it meant I wouldn’t have such a steep learning curve with TypoScript, and I was turning out websites at a rapid rate of knots...even though my PHP skills were only average.

I downloaded the MODx beta after hearing all the good things that people are saying about it, and have found it very daunting indeed from a "bit of everything" developer’s point of view. I was on the lookout for a solid framework with a CMS "built-in", and thought it could have been the solution, but aren’t quite so sure anymore...I hope it will be. I’m going to spend a couple of days trying to get my head around it all towards the end of the week,and hope it will all "come to me", otherwise I’ll have to fall back onto CodeIgniter, which has been innovative to date for me to get to grips with but lacks a sound (Open Source) CMS. I can totally understand that you are tailoring MODx to your needs, and am questioning that in no way whatsoever. I also agree with

I don’t think you’ll find many solutions in the same ballpark

I sincerely hope that things will improve as documentation is worked on, as I have come to deeply admire the community and core developers behind MODx, and thanks to SpeedStreet...as I thought I was the only one having trouble getting to grips with the new way of doing things.

All the best,
Taff

Taff, by all means ask for help and how to approach things on the framework front. Real world usage scenarios are what’s going to help flesh this out and identify where the documentation needs to be enhanced.

Interesting discussion. I agree that Evo (096x) is as simple as ever...not really seen any operational changes since I started using it. There are a few naming changes but that is no big deal (even if I don’t agree with a few)...and under the hood it has gotten leaner.

A system like MODx which has an incredible level of flexibility is bound to become more complicated as the environmental demands increase. It seems that every day a new feature is needed (be it by some clueless user) that require adding a new level of complexity to cater to the needs. I am very surprised at how many users will hack/tweak wayfinder to accommodate an off-the-shelf dhtml menu rather than modifying the menu code to fit wayfinder which is much easier. It seems that as the level of complexity in the layout elements increase that the level of user ability to understand what they are doing decreases...and they want/expect MODx to fill in the gaps. MODx could be much simpler if the user base was much more experienced...but this is a CMS for everyone so it has to accommodate all levels of users (although I have always considered it a developers CMS).

I am happy with the direction of the project, and the core team is doing a great job with it (pretty much with only a small handful of dedicated devs). Is this what I would have done...maybe not...I would have preferred to see a polished new 096x before Revo...however, if I was developing large scale sites I would much rather have a more efficient cache and contexts before any UI enhancements for sure. It is impossible to make everyone happy all of the time.

Quote from: OpenGeek at Jun 21, 2009, 08:17 PM

I think there is a misconception that MODx is becoming more complex simply because of the increasing complexity of the "core" components that are included with the current releases of MODx. Combined with the terminology changes coming in Revolution, and I can certainly see where you can get the impression that it is becoming more complex.

IMO this misconception is simply because the initial buzz around Revo is on features like contexts and modComponents which are complicated for everyday users to understand, but these are under the hood features that only developers really need to know...the basics are still very much the same. I know I am somewhat intimidated by Revo, but not because it is complicated...more because it is different and the differences have been discussed much more than the similarities (which is normal since it is new). Also I am a user who falls well within the limitations of 096x and this makes the new stuff in Revo less ’urgent’ for me, and since I have a hard enough time keeping up with other technologies I have simply not had the time to embrace Revo as I would like to...but I recognize that it is a great step forward and hope to be able to embrace it fully some time soon. However, i do find myself occasionally questioning the personal marketing value of re-learning MODx as a development framework compared to devoting effort towards a mainstream framework (like CI).

Quote from: OpenGeek at Jun 21, 2009, 08:17 PM

But that is precisely what we have been working extremely hard over the last 3+ years that Revolution has been in development trying to address.

I understand that everything that is great takes time to build...but I have to ask myself if the promise of 097 (which became Revo) and the time it has taken to develop has hindered the progressive evolution of MODx (as in community development) over time. The reason i have this impression is that in forum posts dating back a few years the solutions for more challenging endeavors were promised with the release 097 (which seemed always just around the corner). As a result 3rd party development has more or less stalled while waiting for this next step. There have been many projects that have been stopped or dropped while waiting for Revo (Jot, FDM, Content_History...) and other projects that never realized themselves because "in Revo this will be easy". I hope that these projects will pick up again once Revo is released and that they don’t take years to catch up...and with the ’new core’ features I hope that many more projects will materialize as a result.

How much MODx has evolved from the Etomite days is beyond me...but I find that it is the only setup that offers the level of flexibility to tackle almost any project while at the same time being simple enough for non-tech users. I don’t think that MODx has gone wrong at all (I admit that I do not know the initial objectives). It is a very great existing platform (Evo) and has a tremendous promise for the future (Revo).

Revo will compete for the attention of developers who are drawn to Silverstripe (Sapphire) and EE2 (CI) (should it ever see the light of day), i.e. a framework with a wizzy pre-built admin that can be adapted to a custom data model. Having played with Silverstripe and used CI extensively I believe the modx paradigm is inherently more flexible and potentially superior, but it lacks articulation. Modx doesn’t sell itself like it should partly because the terminology, documentation and lack of tutorials gets in the way.

To compete with these systems it’s going to need:
1. A nicely designed and user friendly admin. Beta 1 Revo has come a long way from the earlier releases but it’s still seems... unintuitive, and slightly intimidating. Is it just me?
2. Good documentation/tutorials like this and this
3. Community support. We all need to get behind this effort.

Wow! What an awesome thread. Some great points and insight into the observations and wants of some of our users and the visions of its founders.

I came MODx at 0.9.2 as a web designer who was building his HTML pages using a little bit of PHP includes (for headers and footers) and who was painfully sick of hacking his way through wordpress’ insanely complex templating scheme. Over the years I’ve tried CI, RoR, Joomla, Mambo, Xoops, Drupal and a couple of eCommerce apps. MODx did it better and more simply than I’d ever imagine possible in other CMS apps.

To this day I can rely on the Evo branch (MODx Classic) to be there for me for quick sites, conversions and WP theme ports.

I was seriously intimidated by Revolution’s terminology, contexts and what seemed to be too much MODx, until... I saw how it can be used. It shares the original MODx paradigm of templates, tags and the tree yet moves into the modern era of OOP/MVC and addressing the lack of flexibility of our good ol’ MODx Evo.

So here’s what you get: all the good stuff of MODx Classic on a cruft free, platform that will work for both the designer and developer on your team.

Again I want to reiterate that I am hardly a programmer—more a cut and paste, hack and slash php implementor but I get it.

Despite my own hesitation with revolution, I find it increasingly elegant and does things I only dream Evo/096- could do.

I’d love to see more people help contribute code, components and assistance in improving documentation.

I think all depends on the customers that MODx wants to attract.

I see the customers groups as:

1) Super-developers ( like the MODx core developers)
2) Developers
3) Semi-developers (designers/developers, medium PHP knowledge, medium JSP/AJAX, like most of us here)
4) Designers
5) General Public

I always have thought that the MODx customers are #1 to #4 but lately I think it is moving to #1 and #2.
I read what Shane and Jay are saying and maybe it is my misconception of not having tried using Revo, but
being one that wants to understand how things work, I would have to start with xPDO and then Revo and
that, am afraid, will take a long time.

I think that the original ideals of the OP can still be accomplished by MODx but maybe there is a "layer" of
developers to have Revo still cater completely to all #1-#4 customers.

The core developers, as Ryan, has explained play with the core and write their stuff. Then there are the
developers of complex snippets like Ditto, MaxiG, etc that bring amazing functionality to more of us
but still need a customer to know what it is going on and even maybe need to fiddle with PHP to obtain
the expected result.

The missing layer is, I dont know how to call it, the automatization or wizard-ization of MODx snippets,
where a designer can choose the Wayfinder wizard or the Ditto wizard and design a menu or page still
based on the parameters of each snippet but in a much more friendly way. I think that today’s drag&drop
demo goes in the right direction. But I also think that the core developers and developers won’t necessarily
will be interested on writing this wizards since they can do their job without them.

The integration of templates, template variables and "template wizards" will help, in my humble opinion, MODx
reach and satisfy the main four group of customers, that and documentation will make MODx THE powerhouse
it deserves to be...

my dos centavos...