Community Concerns

Regarding ExtJS I remember in a thread years back reading a fairly straight forward explanation; it was a matter of resources at the time; ExtJS was a means to an end. Which is fine, but we have reached that end. Some of these "shortcuts" have caused the 2.x project some technical debt and the community feels the pain.

We've seen it with accessibility and the learning curve or general dissatisfaction of working with ExtJS. compress_css and compress_js seem like clever optimizations. Less HTTP requests right? They arguably do more harm than good from a performance perspective, white screen many MODX installs, and go against future HTTP2/web components best practices. Not only does ExtJS but things like these settings need to be removed before extra developers can start feasibly using things like web components.

I still haven't figured out how to explain to clients MODX is the best CMS ever when they can't log into it on their smartphone. Have you? Responsive Design recently celebrated it's *5th Birthday* but still really hasn't gotten a visit from Uncle MODX because well, ExtJS. Yes Handyman exists but just like Mark points out in his "Why modmore is not donating to the MODX accessibility campaign" it side-steps the issue with a theme an entirely different /manager.

So when can we expect breaking changes and where do we discuss what to break? Jason's posts have been enlightening but from a front-end perspective I still find myself crossing my fingers for things on a 3.x roadmap.

Quote from: dinocorn at Apr 26, 2015, 02:16 PM

I still haven't figured out how to explain to clients MODX is the best CMS ever when they can't log into it on their smartphone. Have you? Responsive Design recently celebrated it's *5th Birthday* but still really hasn't gotten a visit from Uncle MODX because well, ExtJS. Yes Handyman exists but just like Mark points out in his "Why modmore is not donating to the MODX accessibility campaign" it side-steps the issue with a theme an entirely different /manager.

I show them the backstage and how easy it is for me to manage all the code powering the site. Coding on a smart phone is not a hit and is the main reason
why I need my computer and big screen.

That being said I wish the a11y "theme" could lead us to a responsive manager "theme". But it seems it's hard to make that happen with ExtJS.

But we don't need the whole manager to be responsive, just the content publishing part!

Just to chime in here, I've been developing with MODx since c. 2006 (v1.6 thru 2.3) and though the flaws of Revo have been well documented, I still think it's the best CMF out there - with one caveat: It is the best only for Designers and Developers. However, when it comes to end users (content managers) and 3rd party add-on developers, it falls woefully short for many reasons - not the least of which is the difficulty of developing for and working with the Manager.

For instance, if a client who knows nothing about HTML or CSS has the requirement of heavily editing their own content, I tend to get a little nervous about recommending MODx and usually want to steer them to WP at that point. Mainly because their is no build-in preview mechanism, but also because of the extra, sometimes painstaking steps of setting up a permissions schema and customized forms for them. The same applies when they want extended functionality to their site like a full-featured Event Calendar or A/B testing. There's only a tiny repository of maintained, high quality and FREE specialized plugins. And I'm sorry, I don't want to hear, "But you can develop whatever you want with the core plugins available, i.e. MIGx". Budgets are a real thing in the real world.

Which is why I want to bring up what Susan said about developing Manager pages with the Manager. To expand on what she is saying, I think most developers have gotten too caught up with the "mgr" context and the difficulties of developing therein. MODx got too stuck on the "All things for All people" mentality. They figured secretaries would be just as comfortable using the same tools as the Rocket Scientists. Let's call a Spade a Spade, the system was designed by geniuses for really smart, experienced developers to take advantage of all the power under the hood. I consider myself one of those aforementioned developers, and truth be told, I've only begun to scratch the surface of what I can accomplish with MODx.

The easiest way to solve a lot of these issues going forward (for instance the problem with responsiveness), one that doesn't require a "start from scratch", is to move beyond the "mgr" context and start thinking about developing extras in the "web" context where you have total freedom to do it your way. Yes, this might break out of the "feel" of MODx, but in some ways, that may be a good thing. As for content managers who might or might not have any real technical skills, this is a perfect way to split off the rocket science from the clerical duties.

What I'm saying is, we can keep the laboratory in the basement where all us mad scientist can lurk and geek out, but keep a nice clean office space for the people that will actually be using all the tools we create in every day situations. I guess the succinct way to say it is, keep the "web" and "mgr" context, and create a totally new "admin" context where the end-user tools are housed.

Quote from: dan971 at Apr 27, 2015, 11:03 AM

MODx got too stuck on the "All things for All people" mentality.

This is a really good point. I discovered MODX while I was freelancing in Portland and at the time gave several demonstrations to local agencies to try and sell them on MODX. I knew it was the only thing I wanted to build websites so I gave several demos at places like Wieden + Kennedy (the largest independently owned ad agency in the world) and the general responsive I got was "This looks really nice to build websites with; Let us know when the manager interface is something we can show to our clients."

When you are dealing with people that art direct sites like nike.com it is really difficult to sell them on an interface that didn't consider user experience much at all. It's like trying to get them to take a seat in a car with square wheels.

Over 4 years later the project is in the same boat square-wheeled car. 2.3 looks a lot nicer, we have things like ContentBlocks now; but we are still in the same vessel.

It seems like if 3.x consisted of an even less opinionated backend, a REST API to talk to it, and supported creative freedom and custom theming within the /manager we could be freed from such technical debt. Theme Developers could create themes powered by jQuery, vanillajs or .no-js at all. This would be just like how we can can freely create front end websites using MODX today if the API allowed for it. Instead of there being "a framework" the project uses (like replacing ExtJS with Angular) there could be a REST API and a new theme is a blank slate. Maybe the default theme uses Angular but point being design agency could role their own managers more practically than create a custom mgr is today. In this future world of MODX 3.x development, I can see myself able to build websites *and custom manager themes* for clients in less time than it would take to assemble the site alone using other systems.

All of these things seem feasible but require more leadership and communication from the LLC. Currently, we are being asked to donate to a project that attempts to enhance technology that pre-dates HTML5 (ExtJS) in the name of accessibility, something that very technology mocks. What modern browser needs something like ExtJS in the first place? Is it even possible to make an ExtJS interface fully accessible without an HTML layer underneath it? None and no.

If you need to support IE 8 or below things like ExtJS (or even Flash) save the day but browsers can do *so much more* now. Within a few months Microsoft will release free updates to Windows 10 and with the all-new Spartan browser legacy IE support will become irrelevant. Microsoft gave up on Internet Explorer because of technical debt that held the web back. Why can't MODX give up on ExtJS?

What specifically is holding up breaking ground on a 3.x front end manager interface? Should the community start showing and sharing their own concepts and ideas for a roadmap or just "hold tight"?

Good points. Personally, I'd like to see a pure HTML/CSS Manager for starters with sensible classes and very little styling. Themes could then be created with an overlay of CSS, JQuery, Angular, Ember, or whatever. Almost everything in the Manager, except maybe the file/image browser and datepickers, could be done without JS.

I've looked at the code with the idea of trying this but soon got lost in the current maze of extJS, modExt, and Smarty. I thought I would be able to just create new Manager pages and use the current processors, but it looks to me like the extJS and Smarty are fairly well baked into the request handling process in a way that's difficult to bypass. I'd be happy to be proved wrong.

In case anyone's interested and hasn't seen it yet, @bezumkin has done some pretty incredible things, connecting a native iOS app with the current version of Revo.

https://github.com/bezumkin/mxManager

Quote from: BobRay at Apr 27, 2015, 10:50 PM

Personally, I'd like to see a pure HTML/CSS Manager for starters with sensible classes and very little styling. Themes could then be created with an overlay of CSS, JQuery, Angular, Ember, or whatever. Almost everything in the Manager, except maybe the file/image browser and datepickers, could be done without JS.

I agree. I've been working on some HTML-first components and have actually had a crack at both an HTML-first media browser as well as a file browser. The media browser is still in rapid development over at:
https://github.com/jpdevries/eureka#eureka

There are working examples of both an HTML-first implementation (supports .no-js):
http://devries.jp/static/eureka/examples/index.php

as well as an example that populates the DOM using JS (for use in systems like 2.x):
http://devries.jp/static/eureka/examples/muck.php

Screenshots
eureka.js with JavaScript disabled:
http://j4p.us/image/2p3J1I0h3v0c

eureka.js within 2.3 on a mobile viewport:
http://j4p.us/image/3w2z3x2V2p0O

more:
https://github.com/jpdevries/eureka/wiki/Screenshots

Without js or even a mouse you can browse media sources, upload multiple files, and of course select an image. The layout requires no JavaScript, resize listeners, or inline styling. Other than drag n drop files, change views, and asynchronously filter media items you can basically do everything a js-enabled user could. HTML FTW.

The component currently weights less than 84kb in total (CSS and JS). Being authored in VanillaJS, it has no dependencies (not even jQuery) and does not rely on any other frameworks. React and Angular drivers are on the roadmap so it can more efficiently be integrated into projects that utilize those frameworks:
https://github.com/jpdevries/eureka/wiki/Roadmap#030

So, I can't help but wonder what couldn't we do with HTML and MODX given breaking changes?

That's fantastic. I wish I had time to integrate it into NewsPublisher and TinyMCE.

If only there were an HTML datepicker.

http://www.cssflow.com/snippets/dark-datepicker

You could convert that table into a form and do stuff with it.

Their demo doesn't seem to work in Firefox. I can't advance the month and selecting a date doesn't do anything.