Hi guys,
I have been a happy user of evolution for a couple of years. To be honest I was kind of surprised when I saw revolution went into beta already. However, I gave it an honest shot and this is what I found. . .
Let me first say that from a technical point of view, the improvements are very obvious and I think the dev team did a great job. I really appreciate all the hard work. However, that said..
I’ll be pretty amazed if you find another CMS that solves this problem for you or comes closer than MODx does. Lexicons might be a tiny part of the answer but, at first glance, it looks like a job for Template Variables with a snippet to set their values based on the "culture" of the visitor.
i18n:
The revolution docs state that te lexicons are the answer to internationalization. I am managing 4 websites in at most 8 languages, and in evolution I have been missing good internationalization for a while. I was happy to hear that revolution addresses it. However, I think the dev team misunderstood the real problem with internationalization. The real problem is _not_ that you simply want a duplicate of the same site in a different language. The problem is that in different languages:
- often you need a different site for the same language simply because its a different country and therefore the site structure needs to be slightly different, pages need to go or be added, etc etc. However 90% of the site is still the same, so I don’t just want to duplicate the branch. I want a ’shadow’ version of the site, which I can adapt wherever I want. This happens for example with US/UK/CA sites, NL/BE sites, FR/CA-FR/BE-Fr sites.
- translating a website does not involve only text, but also images, flash movies, structure changes, different news items and contact info etc etc.
- for a lot of languages we do not have time to translate it wholly, so we only do the first page for now, and want the rest to be in english. ergo, 90% of the site is the english website. Of course, a lot of other things change too, because we don’t recruit in that language and there are no customer events either.
It’s definitely scary at first, but to make MODx do what it does, those objects have to exist and you have to call them *something.* I was on the losing side of a number of arguments about terminology where I was on your side. On reflection, though, I was generally wrong. We can’t call them "pages," for example, because it would be misleading. Pages are what you see in the front end and they can be created in a wide variety of ways, some of which involve multiple chunks, resources, plugins, snippets, and TVs. If you have only one content section, you won’t have any TVs. If you have more, the extra ones will need a collective name and they’ll each need individual names. I guess they could be called "Extra Content Fields" but that wouldn’t help anyone understand the relationship between TVs and templates, which is critical if you’re going to create any. You can change the name on that tab easily enough (or have them below the content field in an accordion menu).
A programmer’s view - or: a steepened learning curve
When I’m browsing through the manager, I am overwhelmed by all the technical terms I encounter. Namespaces, connectors, content elements, controllers, actions, etc. Now I’m ok with this because I know what it means from my technical background. However I think the manager should be written from the users’ point of view, not from the programmers.
The people that most often use the manager here are our copywriters, who have limited technical knowledge. They want to see a list of "pages", not "web resources". They don’t want to click "template variables" to see the rest of the content because to them content equals content. The page-tree is the center of all activity, so why is it not always visible anymore? ’static resource’? You mean a file?
You probably know the answer to the first one: "Any where you like."
Even for me as a programmer some things are really not intuitive. Where do I put my template files, css and js? Do I first have to create a namespace and a directory or something? The point is that things everyone does a lot, should be extremely obvious.
Additionally, give me as an admin the option to hide stuff that my copywriters will never use.
user interface
docs
Ok, I know docs are not the most fun for a developer but please dont underestimate their importance. For example, take this page:
http://svn.modxcms.com/docs/display/revolution/Templates
quote: "Simply create a new Template, then assign it to a Resource."
Umm yea I know that part because I know what templates are but the reason I came here was to figure out HOW I create a new template. It was only after 15 minutes or so that I thought of clicking ’content elements’ Also terms are used in the docs that are not introduced yet. It’s probably better to have a couple of getting starteds/tutorials than a lot of incoherent docs.
Custom TVs
Ok this wasn’t possible in evolution either. I always loved the concept of TV’s. However sometimes I want to present the copywriters with a choice that is not part of the default input type options. For example, the result of an advanced Database Query, or the possibility to add a list of images for a slideshow. It would be *totally awesome* if there was a way to define my own TV input types
Yes i realize that, to my knowledge only modx gives me the option to at least make something myself that fits the requirements.
I’ll be pretty amazed if you find another CMS that solves this problem for you or comes closer than MODx does. Lexicons might be a tiny part of the answer but, at first glance, it looks like a job for Template Variables with a snippet to set their values based on the "culture" of the visitor.
i18n:
I understand what you’re saying, one needs names that fit the purpose. However, it’s not just names its also what you see first when you try to find something. I hardly ever use the files manager in evolution, and content elements can be considered less important (or more advanced if you want) than web resources. Right now they are given the same ’weight’ in the manager interface. I probably would’ve only shown the web resources (and don’t name it maybe) much like in evolution.
It’s definitely scary at first, but to make MODx do what it does, those objects have to exist and you have to call them *something.* I was on the losing side of a number of arguments about terminology where I was on your side. On reflection, though, I was generally wrong. We can’t call them "pages," for example, because it would be misleading. (..)
A programmer’s view - or: a steepened learning curve
MODx is, at heart, a developer’s CMS/CMF. If the terminology were less precise, developers would have a much harder time accomplishing things in MODx than they do now. The Manager in Revolution is quite customizable and, as time passes, I think there will be customized versions of the Manager that will be tuned to naive users.
You probably know the answer to the first one: "Any where you like."
Where do I put my template files, css and js?
You could say like "we don’t care where you put it, but this directory would be a great place". But anyway I understand the point.and I’m sure you know that, for the most part, the docs can’t be written until the UI is finalized.
Have you looked at the @ bindings and TV-based chunks? You should be able to do everything you’ve described with them.
Sure no problem! Keep up the good work, I’m a big fan of modx.
Thanks again for the very clear and insightful analysis.
☆ A M B ☆
For the sake of the argument, how hard would it be to create a ’customized’ manager interface, just for the copywriters?
And allowing users with enough rights to switch between "normal" and "advanced" manager layouts via the top menu.
I think Contexts would be most appropriate here for you - they’ll allow you to redo the structure for the different language formats. You can link back to the main Context when you don’t have a part of the site translated into the new language.
i18n:
The revolution docs state that te lexicons are the answer to internationalization. I am managing 4 websites in at most 8 languages, and in evolution I have been missing good internationalization for a while. I was happy to hear that revolution addresses it. However, I think the dev team misunderstood the real problem with internationalization. The real problem is _not_ that you simply want a duplicate of the same site in a different language. The problem is that in different languages:
- often you need a different site for the same language simply because its a different country and therefore the site structure needs to be slightly different, pages need to go or be added, etc etc. However 90% of the site is still the same, so I don’t just want to duplicate the branch. I want a ’shadow’ version of the site, which I can adapt wherever I want. This happens for example with US/UK/CA sites, NL/BE sites, FR/CA-FR/BE-Fr sites.
- translating a website does not involve only text, but also images, flash movies, structure changes, different news items and contact info etc etc.
- for a lot of languages we do not have time to translate it wholly, so we only do the first page for now, and want the rest to be in english. ergo, 90% of the site is the english website. Of course, a lot of other things change too, because we don’t recruit in that language and there are no customer events either.
I hope one can see that lexicons cannot help me with this. I looked into Contexts, but they don’t solve the former problem either.I’m not sure how Contexts don’t help you - you just need to set up Revolution properly to get them to help you. You have quite a lot of options on how to do this - you can setup subdomains and use a plugin to switch between them, or setup different subfolders and run index.php files that instantiate modx (similar to modx/index.php) in the proper context, or many other ways.
They’re pretty ’hard’ to set up too. Can’t it be made that a context can be inherited, and that contexts are linked to the domain automatically?Right; we realize this is a problem. I think it mostly has to do with documentation, rather than the UI, although I can see a case for improving the UI here. The problem is mainly in that Contexts are almost *too* flexible - they can be used for a multitude of different scenarios, from subdomain management, to sublanguage sites, to subsections of a main site, to staging to production sites, to most anything else you can think of. So we’ve been trying to create a UI that doesn’t *restrict* those possibilities while also enabling and streamlining existing and common methods. It hasn’t been easy, and we’re definitely in need of improvement there. Suggestions are very welcome.
When I’m browsing through the manager, I am overwhelmed by all the technical terms I encounter. Namespaces, connectors, content elements, controllers, actions, etc. Now I’m ok with this because I know what it means from my technical background. However I think the manager should be written from the users’ point of view, not from the programmers.Right; well, most of these terms we’ve really debated and delved into - for example, what else *do* you call a connector, or a namespace? And, we’re still in beta - things are still open to tweaking a bit.
The people that most often use the manager here are our copywriters, who have limited technical knowledge. They want to see a list of "pages", not "web resources". They don’t want to click "template variables" to see the rest of the content because to them content equals content. The page-tree is the center of all activity, so why is it not always visible anymore? ’static resource’? You mean a file?Well, lets delve into that - Pages wont work, simply because not every Resource type is a Page. Weblinks aren’t pages, nor are Symlinks. And we’ll be showing and improving the process on how to create custom Resource Types here in the next couple beta releases, so that a developer could create ’Blog Post’, ’Atom Feed’ or whatever. So Pages would be a misnomer.
Even for me as a programmer some things are really not intuitive. Where do I put my template files, css and js? Do I first have to create a namespace and a directory or something? The point is that things everyone does a lot, should be extremely obvious.Well if you’ve been using Evo, do the same as you do in Evo. You put it wherever you want. On the filesystem, or in a Resource. Or even serve it up via a Snippet. It’s up to you. We don’t want to restrict people’s usability.
Additionally, give me as an admin the option to hide stuff that my copywriters will never use.ManagerManager provides this for Evo - eventually we’d like to see something like this in the core of Revolution. Jason and I talked at length on how to do this the other day. The main problem isn’t that we don’t want to do something like this - it’s that we don’t have the time or manpower. Right now there are 2 active committers for Revolution; Jason and I. We want to get this much higher, but so far, developer adoption has been slow. We’ve been trying to encourage that by concentrating on the documentation, but again, community development and adoption has been slow. We are very open to ideas on how to get this to improve.
To be honest I think the user interface could use some love.. I like ExtJS, but the top menu and the grey boxes on the left appear kinda clunky. Love the website by the way.I agree. If anyone would like to help with this, we’d really appreciate that.
Ok I know I can change this myself but things should be perfect immediately, right?What do you mean? Symlinks are different Resource types than Weblinks entirely.
- duplicate sym/weblink-button in the site-menu. The difference should be an option, not 2 menu-items
- manager-logout in the site menu?We actually had that removed at one point, but our users requested it back. Did you have a suggestion for another place for it?
- search-resources in site menu should be somewhere near the content-elements box because that’s where you manage content elementsWait a minute - I’m not sure I understand you here. Search searches resources...not elements, why should it be near content elements? I’m confused.
- security: Didn’t really look into it but it looks very very complicated.Simplifying the UI for the Security sections is a main priority of beta-4. It is also a much more complex and flexible security system than Evo’s - it’s actually a business-model ABAC approach with full ACLs and more. This allows for much, much more fine-grained security options. We’ve addressed this quite a bit in SVN so far.
Ok, I know docs are not the most fun for a developer but please dont underestimate their importance. For example, take this page:Agreed; now if only some documentation writers for Revolution would appear. So far we’ve had no one step up, and it’s left pretty much myself to write them (along with all the xPDO docs as well), while also trying to do the UI and more. I would really, really, really, really appreciate help from people in doing this.
Umm yea I know that part because I know what templates are but the reason I came here was to figure out HOW I create a new template. It was only after 15 minutes or so that I thought of clicking ’content elements’ Also terms are used in the docs that are not introduced yet. It’s probably better to have a couple of getting starteds/tutorials than a lot of incoherent docs.
Ok this wasn’t possible in evolution either. I always loved the concept of TV’s. However sometimes I want to present the copywriters with a choice that is not part of the default input type options. For example, the result of an advanced Database Query, or the possibility to add a list of images for a slideshow. It would be *totally awesome* if there was a way to define my own TV input typesThere actually *is* - we’ve done it in a couple client work projects. We definitely need to document and create some helper pages on how to do this. It’s in the queue of things to do.
Please let me know if I misunderstood something, but if not I think I would stick with evolution for now.That’s fair; we understand there’s still roadblocks to Revolution. We’re trying to deal with them, and any help either in suggestions or actual development would be greatly appreciated, and we are hoping the MODx community will start stepping up to the challenge here soon.
MODX Staff
Right now there are 2 active committers for Revolution; Jason and I. We want to get this much higher, but so far, developer adoption has been slow. We’ve been trying to encourage that by concentrating on the documentation, but again, community development and adoption has been slow. We are very open to ideas on how to get this to improve.
I completely understand; we knew that during development. Since we were changing the foundation of MODx with Revolution, it definitely would have been hard for devs to pick up during alpha stages. However, most everything is pretty finalized structure-wise, xPDO’s pretty much as it will be come 1.0 GA, and the UI may pretty up a bit, but will be very similar. So the basics and foundations of Revolution are pretty set for the first release. We just need 3PC developers and bug fixers to help with the slack.
You’re definitely on the right track with concentrating on documentation, splittingred. I’ve been in and out of Revo over the past year and a bit, with only a handful of commits, compared to the thousands of commits from you and opengeek. From my experience, I would argue that it would only have been possible for a developer to contribute meaningfully during the pre-beta period if they were able to dedicate a fairly large chunk of time to the cause. A few sporadic hours here and there just wasn’t enough time (for me) to learn the system and keep up with the rapid and extensive ongoing changes at the same time without the benefit of things like system or architecture diagrams, documentation etc. But now that most or all of the deeper stuff has been realized by you guys during that intense period, Revo is beta, and most importantly, the documentation is there as a starting point for me to re-learn the system from scratch, now I can see a point-of-entry back into the project with minimal "risk" of the landscape changing on me as I learn. This is an exciting time!
Please don’t take any of that as a criticism of how things have been. I don’t see any other way that Revo could have evolved to this point. Adoption may still continue to feel slow while devs soak it up, but the documentation is the key. Then, devs blogging and tweeting about stuff they’re doing.. and it will grow from there. That’s my $0.02.
I believe that when you first log in, the Web resources section is shown and the others are closed. So a user that only works on docs, should, in theory, never see the other sections. The problem with making the other sections less accessible is that, as a developer, I have to constantly go back and forth between resources, snippets, and chunks. Once you start using Quick Create and Quick Update, I think you’ll see how much more productive you can be with the current Manager than theold one.
I understand what you’re saying, one needs names that fit the purpose. However, it’s not just names its also what you see first when you try to find something. I hardly ever use the files manager in evolution, and content elements can be considered less important (or more advanced if you want) than web resources. Right now they are given the same ’weight’ in the manager interface. I probably would’ve only shown the web resources (and don’t name it maybe) much like in evolution.
For the sake of the argument, how hard would it be to create a ’customized’ manager interface, just for the copywriters?
I’ve argued exactly that point a few times and I still wouldn’t mind MODx coming with an empty assets/css folder, for example. The problem is that half the people want to put CSS files in a central location and the other half want to keep them with their respective components. A good case can be made either way so what do we recommend?
Where do I put my template files, css and js?
hmm yes, great philosophy, but restriction is something different than recommendation
You probably know the answer to the first one: "Any where you like."
It definitely would have been nice in some ways to have the GUI completed ahead of time, but I’m not sure it would have been feasible and it’s water under the bridge at this point.
edit: I must say that it’s a little worrying that you guys postpone GUI design until the beta phase. It’s not uncommon that the user interface design can be harder than the actual code framework design. Anyway, I’ll have patience