Quote from: stephenrs at Oct 21, 2009, 09:41 PM
I’m sorry to see insert_nick come back here apologizing with his tail between his legs. Nothing that he said should be construed as insult, nor was he saying anything even close to the notion that the Revo manager was not "up to par". He was simply confirming what the title of this thread asks, by noting that the Revo manager is slower than the Evo one. Good info for anyone reading this, devs included; and constructive by its very nature.
And I apologized for it, my response was a bit harsh. However, to be fair, saying he’ll wait until "revolution gets the manager it deserves" directly implies the manager is not up to par. Again, I don’t think my reaction post was appropriate nor the right way to respond, though.
The fact that Revo is slower has now been confirmed by other, and respected members of this community.
Well, wait now. "Slower" implies a lot. It’s a bit slower in initial response times in the manager, but vastly faster in the front-end. It’s also faster when you start using Quick Update/Create, saving documents, and other features. The "workflow" in Revo is vastly faster - I can create an entire minisite without reloading the page once.
So "slower" is a bit debated - I find Revo quite a bit faster to develop sites in. However, I would agree that the AJAX calls could be optimized. I would also agree that the JS could be slimmed - that will be addressed through JS compression in RC1.
Adding new features to an application, no matter how good they are, is a sound explanation, but does not excuse a slower application - just try that one with a client. I know mine wouldn’t go for it.
Agreed, but we have to define what you mean by "slower" first. Taking an extra second to load the mgr page at the benefit of the workflow improvements that make it so you can create a site in an hour less is a "good" tradeoff.
A more "constructive" answer might have been: We know that the Revo manager is slower, we’re working on it, please have patience - we do this in our spare time. To not even acknowledge the decrease in speed doesn’t help anyone, including the project itself - and certainly doesn’t give the impression that the devs are planning to do anything about the slowness.
I’ve acknowledged in other threads that it’s a bit slower in initial response times in the manager, and that we are working on it - I also acknowledged I was open to constructive suggestions on how to improve it. I understand your concern, but I’m not sure these lines are fair to me. That said, my reply was a bit forward and harsh, and I apologize for it.
We all already know how hard the devs are working on MODx, and that we haven’t paid a cent for it. We are all grateful, and don’t need to be reminded. We incidentally also know that the devs aren’t doing this out of the pure goodness of their hearts - that there is a larger long term objective here that involves some kind of payoff for the devs - and that ALL of us are helping that process move along by our very involvement.
Just trying to inject some honesty, objectivity, balance, and perspective back into this conversation. No hard feelings.
None taken; and to be honest and transparent, Jason and I work full-time on MODx (excepting client work to pay bills). We do hope to be paid, in some level, for this product and services - we don’t expect 7 figure salaries, but more of a baseline income for our positions and work. And you’re right - we’d like to make MODx profitable someday - but not just for us: for the 3rd Party developers, client design/dev shops that use MODx, and independent contractors that rely on MODx for small gigs. We’ll be rolling out some new services to help that soon.
But I’m also reminded of many OS experts, from Google to MySQL to others, who have iterated one thing over and over again - criticism without specifity and constructive points should never be welcome in Open Source communities. OS groups that allow that kind of armchair-quarterback crits without any level of commitment and involvement to improving the problems often degrade into he-said-she-said battles, where nothing gets done and people’s feelings get hurt, with no real progress happening. But how to enforce that without blockading newcomers is difficult - most so for those most involved in the community, as they’ve put the most effort in and (rightfully so) have the most input into the development process.
Expanding on that, one thing I love about MODx is the community. We love how people here are actively engaged in helping others, and making the community one of the best parts about MODx. And the tenor here is usually positive - a rarity, I feel, for OS groups. We’re not perfect at that (as I have shown), but we’d like to be. And one of the best things about MODx is how people dont just comment on the project: they contribute to it.
So, how to get people to have helpful contributions to a project without blockading them out of making criticisms? Well, we simply ask that for every criticism, one should offer a suggestion on how to improve it. And to be honest, criticisms paired with suggestions are far more likely to be listened to and respected. I’m sure you can empathize with that - you’ve worked a long time on a project and someone comes along and says, "It’s slow. That stinks. I’ll go back to this other version." without any details or specifics or suggestions for improvements - that’s bound to irritate you, and rightfully so, I believe. Now, if that criticism had been paired with, "well, I see here that the AJAX calls for loading the data are loading twice; and what about optimizing the JS via compression?", then you’d be a lot more open to listening.
It’s a two way street, I think. I don’t feel that agile communities should allow their developers to get stomped on by anyone who decides to register for a forum account. Nor do I believe that developers should be able to be uppity and dismiss every criticism or request made their way. Both must respect and honor the other - the users by providing constructive critiques and suggestions; the devs by admitting flaws and accepting new ideas.
All that said, none of us are perfect at it. We apologize ahead of time for when we fail. But do help us out - give us some ideas, too! Thanks stephen for your thoughtful reply.
As someone trying to get up to speed with the system (and sometimes clicking all over the place to see what’s what), slow page load times are a serious deterrent to my acceptance of the product. From where you sit it may be an acceptable tradeoff, because you know the tool intimately, but for me who uses other similar tools all day long (and writes some of them), it’s hard to justify the comparatively slow speed based on the fact that "somebody" can build a site in an hour. Since you’re working on it, this is likely not an issue for the longer term - even in a less than ideal world it should be possible to have a powerful workflow that is also crisp.
☆ A M B ☆