The revolution will not be televised ... but it will certainly be ajaxified

I have just installed my first revo install on a production site, and have been tinkering all afternoon with it.

My thought about the manager and ajax - you guys have really gone overboard - even drop-down menus (select a template, content type, etc.) load via AJAX. Isn’t that somewhat of an overkill?

Every thing in this UI seems to load content via AJAX, in some sort of post-web 2.0 nightmare

Well, I am exaggerating, but I think you get the idea. It wouldn’t be so bad IMO if I felt the UI was snappy and fast because it initially loads less - but I am afraid this doesn’t seem to be the case either.

Are there any plans to improve the responsiveness of the manager between beta 4 and the RCs?

Yes, there is.

Unfortunately, loading straight without using AJAX for dropdowns such as Template fields prevents us from dynamically adjusting the content of those dropdowns at any given time without reloading the page, and putting that Template combo widget anywhere - including in windows such as the Quick Create Document window.

That said, we do plan to optimize some things. The JS will all be compressed, along with the CSS. We’re also going to look at the AJAX request and see if we can cut down on them.

Feel free to suggest fixes or optimizations.

Quote from: splittingred at Nov 01, 2009, 08:41 PM

Yes, there is.

Unfortunately, loading straight without using AJAX for dropdowns such as Template fields prevents us from dynamically adjusting the content of those dropdowns at any given time without reloading the page, and putting that Template combo widget anywhere - including in windows such as the Quick Create Document window.

That said, we do plan to optimize some things. The JS will all be compressed, along with the CSS. We’re also going to look at the AJAX request and see if we can cut down on them.

Feel free to suggest fixes or optimizations.

I am not a programmer, so I can’t really suggest fixes in any meaningful way ...

But in general, the manager is really heavy, and especially compared to evo. I really prefer the new interface in many ways, though.

Something has to be done, IMO, because while editing and adding content, I really feel like there is a lot of waiting time - it kind of kills the experience. Perhaps I notice it more, being in israel and having a server in the states there is a noticeable latency with all server requests. Although again, it is not a problem for me with any other web apps I use, including evo.

Quote from: towerofbabel at Nov 03, 2009, 05:30 AM

Quote from: splittingred at Nov 01, 2009, 08:41 PM

Yes, there is.

Unfortunately, loading straight without using AJAX for dropdowns such as Template fields prevents us from dynamically adjusting the content of those dropdowns at any given time without reloading the page, and putting that Template combo widget anywhere - including in windows such as the Quick Create Document window.

That said, we do plan to optimize some things. The JS will all be compressed, along with the CSS. We’re also going to look at the AJAX request and see if we can cut down on them.

Feel free to suggest fixes or optimizations.

I am not a programmer, so I can’t really suggest fixes in any meaningful way ...

But in general, the manager is really heavy, and especially compared to evo. I really prefer the new interface in many ways, though.

Something has to be done, IMO, because while editing and adding content, I really feel like there is a lot of waiting time - it kind of kills the experience. Perhaps I notice it more, being in israel and having a server in the states there is a noticeable latency with all server requests. Although again, it is not a problem for me with any other web apps I use, including evo.

this is worth a read:
http://www.useit.com/papers/responsetime.html

Your link addresses site visitor attention span, etc. These are typically NOT a consideration for developers.

But the point is valid.

Maybe, the devs should cache the menus and only use the ajax to load if there has been a change since the last cached load. Essentially use ajax to change the cache on the server and update the browser IF there have been updates or additions to the menus since last load.

Just a suggestion. I’m still working on getting content to users.

Quote from: wshawn at Nov 10, 2009, 07:02 PM

Your link addresses site visitor attention span, etc. These are typically NOT a consideration for developers.

But the point is valid.

Maybe, the devs should cache the menus and only use the ajax to load if there has been a change since the last cached load. Essentially use ajax to change the cache on the server and update the browser IF there have been updates or additions to the menus since last load.

Just a suggestion. I’m still working on getting content to users.

I think they are considerations - the MODx Manager is a web application that will not only be used by developers, but also content editors, etc.

Anyway, I would think that developers would be less forgiving of waiting time than the "average user" - but it is just an assumption.

No one else seems to have complained about this until now, so perhaps it truly is a non-issue for MODx developers.

Still, from my experience - in the last 2 weeks I have been building two different sites - layout and also entering content, etc. One site in Evolution (1.0.1 and now I upgraded it to 1.0.2) and one in Revolution. The differences in workflow are quite significant due to this dynamic loading of just about everything in the Revolution manager.

No one else seems to have complained about this until now, so perhaps it truly is a non-issue for MODx developers.

Some people have been complaining since the early alpha stage, but Revolution is still in bêta stage and i’m pretty sure that the manager speed will improve in future release.

Still, from my experience - in the last 2 weeks I have been building two different sites - layout and also entering content, etc. One site in Evolution (1.0.1 and now I upgraded it to 1.0.2) and one in Revolution. The differences in workflow are quite significant due to this dynamic loading of just about everything in the Revolution manager.

It may be because of what you expected of Revolution when you were playing with it.

I too have been making a website with both Evolution and Revolution, and even if i don’t understand all the magics yet, i have gained quite some time with Revolution, especially with application deployment via the package system.

The development itself stay in my editor, and most of the time out of the manager for both Evo and Revo. So, in my case, it doesn’t change anything on the dev speed aspect.

Quote from: lossendae at Nov 12, 2009, 02:52 AM

I too have been making a website with both Evolution and Revolution, and even if i don’t understand all the magics yet, i have gained quite some time with Revolution, especially with application deployment via the package system.

The development itself stay in my editor, and most of the time out of the manager for both Evo and Revo. So, in my case, it doesn’t change anything on the dev speed aspect.

There is no doubt that people use the manager differently, and just having includes in the manager and working on files with an IDE, as I think you are doing from what you say, obviously won’t run into load time lags in the manager interface.

I am not talking about development speed generally, which I think is what you are getting at. I am talking about lag when performing actions in the manager, evo vs. revo.

But yep, maybe I should also just start using includes and build outside of MODx itself.

I tend to use include statement for my custom snippets, allowing me to use my editor and avoiding copy pasting things for each modification.

But now, even if i want to use directly my snippets without include, it’s easier by using package. I can update everything in 2 clicks.

For exemple, if i have a theme for which i want to create a new page layout, with new images, updated CSS and a new TV parameter and updated backend custom page.

I’ll just have to modify my package builder.

Then all files, snippets, tv’s and template structure are updated, without needing to go copy paste the updated template, then copy paste the updated snippets, edit the TV manually, then get out of the manager and copy paste the new pictures and css files, and more depending of the complexity of the template.

However, i do agree that actions in Revo’s manager feels slower than in Evo. And even more since Evo 1.0