New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we move the Manager to HTML5? #11339

Closed
atmmarketing opened this Issue May 1, 2014 · 24 comments

Comments

Projects
None yet
9 participants
@ghost

ghost commented May 1, 2014

And away from XHTML, CDATA et al?

@rthrash

This comment has been minimized.

Member

rthrash commented May 1, 2014

I hear ya! Unfortunately, not very likely in the 2.x series as it is built on top of ExtJS. It's almost an absolute certainty that 3.0 will have a full HTML5 mobile responsive Manager, though.

Are you aware of a way to bridge the gap with ExtJS 3.x, which is what we are built on top of (and is actually more performant than 4.x and I suspect 5.x)?

@Carw

This comment has been minimized.

Carw commented May 1, 2014

Mb we should use AngularJS?

@ghost

This comment has been minimized.

ghost commented May 1, 2014

I'm not looking to start a religious war about Ext, I was just wondering if the roadmap featured a Manager interface in HTML5. Seeing all that XHTML is like peering into the distant past...

@rthrash

This comment has been minimized.

Member

rthrash commented May 1, 2014

The Roadmap absolutely includes a new, modern, mobile-responsive, lightweight, HTML5 Manager.

While there are actually more than a few people that love ExtJS—it makes incredibly complex things almost sane and the simple things incredibly painful—I'd be surprised to see it make the final cut.

Angular is absolutely in the running; it has tons of momentum, a great license and a growing community (and bright future).

@rthrash

This comment has been minimized.

Member

rthrash commented May 1, 2014

Going to close this one down but rest assured this topic has come up time and time again! :) Keep the suggestions and questions coming!

@rthrash rthrash closed this May 1, 2014

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Dec 1, 2015

It's almost an absolute certainty that 3.0 will have a full HTML5 mobile responsive Manager, though.

The Roadmap absolutely includes a new, modern, mobile-responsive, lightweight, HTML5 Manager.

@rthrash at MODXpo you said that 3.x would still be powered by ExtJS. Is there a 4.x roadmap? Can we please get some clarification on this?

@dannevang

This comment has been minimized.

Contributor

dannevang commented Dec 1, 2015

I think that when @rthrash wrote 3.0 in 2014 he probably meant what @opengeek call Modx Next today, not what is becomming revo 3.0 due to semver.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Dec 1, 2015

What I'm confused about is if there are contributors willing to invest efforts into an HTML-first manager should they direct their efforts at a Revolution 4.x or MODX Next? My understanding is that MODX Next is a full re-write.

If there was a roadmap back in 2014 that included a mobile friendly manager has that roadmap been published or adjusted to accommodate the recent changes?
https://rtfm.modx.com/revolution/2.x/getting-started/an-overview-of-modx/roadmap

Major semver bumps mean breaking changes, so ExtJS could walk the plank in 3.x. It just isn't. This is understandable if the 'php side' of things need breaking changes before a newer manager interface can be put together, I just hope a 4.x or MODX Next is visible enough on the horizon for contributors to start breaking ground on.

@StevenMorgan

This comment has been minimized.

Contributor

StevenMorgan commented Dec 1, 2015

Roadmap? Are you having a laugh?

That doesn't exist, and certainly isn't for community contribution.

On 1 Dec 2015, at 21:13, JP DeVries notifications@github.com wrote:

What I'm confused about is if there are contributors willing to invest
efforts into an HTML-first manager should they direct their efforts at a
Revolution 4.x or MODX Next? My understanding is that MODX Next is a full
re-write.

If there was a roadmap back in 2014 that included a mobile friendly manager
has that roadmap been published or adjusted to accommodate the recent
changes?
https://rtfm.modx.com/revolution/2.x/getting-started/an-overview-of-modx/roadmap

Major semver bumps mean breaking changes, so ExtJS could walk the plank in
3.x. It just isn't. This is understandable if the 'php side' of things need
breaking changes before a newer manager interface can be put together, I
just hope a 4.x or MODX Next is visible enough on the horizon for
contributors to start breaking ground on.


Reply to this email directly or view it on GitHub
#11339 (comment).

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Dec 1, 2015

It's kinda sad that I have to agree that there isn't a roadmap for the community to work on - there could be so much more if we found a way to activate the community to work on the right issues for the future. Time to make our own? ;)

@rthrash

This comment has been minimized.

Member

rthrash commented Dec 1, 2015

I'd love to see a non-ExtJS Manager in Revo. That would certainly qualify as a 4.0 (or 5 or …).

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Dec 1, 2015

I've updated the roadmap in the RTFM re 2.5 and 3.0, though obviously nothing too exciting beyond what's already in the code or a pull request. Don't want to misinform people with fancy promises without anything to back it up.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Dec 3, 2015

On the topic of roadmap, I'd hope we can think bigger about a new Manager beyond a non-Ext Manager like perhaps rethinking all of the task flows and what the Manager can do. It feels like small thinking (probably out of pained frustration at the glacial pace of change in the UI) to just want to redo the same (6 year old) Manager but with better markup, css and JS.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Dec 3, 2015

Further to the topic of the new Manager, before we start committing or submitting PRs, it feels like defining what the next Manager should be. This is my core problem with relying on Github as the primary tool for product development (which it's not really meant for, though can be used for it) is that it forces decisions to be made at the PR level—after the decisions and work has been done. Product development should include goals declarations, defining scope, audience, possibly include research and problem statements long before we get down to the work of markup.

IMO we should not be contributing work to a long future version of the software before deciding what's being built and for whom.

If I were doing this for MODX Cloud's Dashboard (since it's not an open source project), we'd talk about all the issues, task flows and users, what works what doesn't and then build out a scope of work that clearly defines what problems we're going to solve and new features we think it should have before we start any work on a rebuild.

Doesn't it make sense that that's the kind of discussion we should be having?

@dannevang

This comment has been minimized.

Contributor

dannevang commented Dec 3, 2015

It most certainly does, and that discussion should lead to a roadmap including technology choises that pr's could be made from.

But that quickly leads back to the recurring debate about leadership of the project. Should the form and process of the debate be lead by the community or the LLC? Who will decide which of the directions that a debate will produce should be the official one that at roadmap should be formed from?

I think there is a lot of people willing to participate in the process, both with the code and the strategy - but it is hard to know how to do that.

All I know about MODX Next is from @opengeek 's articles on medium and from the slack channel. It all sounds really great - but I hasn't been an invitation to participate.

So how do we get the discussions going?

@StevenMorgan

This comment has been minimized.

Contributor

StevenMorgan commented Dec 3, 2015

Sounds great.

Who is responsible for coordinating this?

Steve

Sent from my iPhone

On 3 Dec 2015, at 19:29, Jay Gilmore notifications@github.com wrote:

Further to the topic of the new Manager, before we start committing or
submitting PRs, it feels like defining what the next Manager should be.
This is my core problem with relying on Github as the primary tool for
product development (which it's not really meant for, though can be used
for it) is that it forces decisions to be made at the PR level—after the
decisions and work has been done. Product development should include goals
declarations, defining scope, audience, possibly include research and
problem statements long before we get down to the work of markup.

IMO we should not be contributing work to a long future version of the
software before deciding what's being built and for whom.

If I were doing this for MODX Cloud's Dashboard (since it's not an open
source project), we'd talk about all the issues, task flows and users, what
works what doesn't and then build out a scope of work that clearly defines
what problems we're going to solve and new features we think it should have
before we start any work on a rebuild.

Doesn't it make sense that that's the kind of discussion we should be
having?


Reply to this email directly or view it on GitHub
#11339 (comment).

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Dec 3, 2015

Further to the topic of the new Manager, before we start committing or submitting PRs, it feels like defining what the next Manager should be.

I agree, though in absence of a definition or a process to reach that, I think the next best thing will be PRs.

This is my core problem with relying on Github as the primary tool for product development (which it's not really meant for, though can be used for it) is that it forces decisions to be made at the PR level—after the decisions and work has been done. Product development should include goals declarations, defining scope, audience, possibly include research and problem statements long before we get down to the work of markup.

That depends on the git project it is based on. Talking about what we have today, yes that is a very limited and "after the fact" way of discussing, however it doesn't have to be. There could be a separate repository which contains markdown documents that outline those aspects you mention (goals, scope, etc). If anyone beliefs something should be corrected or added, they can send a pull request which is then immediately a place for discussion. If the discussion is positive, it can immediately be merged and it's then "official".

Git(Hub) makes the process public and transparent, something I believe to be important. Anyone can contribute to the process if they desire, making it accessible too.

Who is responsible for coordinating this?

For historical reasons, I believe @opengeek needs to be at the forefront of this - at least initially. It's not his sole responsibility, but he has been speaking about some of the concepts for MODX Next, so I think those should be formulated as a starting point. From there it should be a community process.

@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Dec 3, 2015

Just came across this on my twitter feed: https://github.com/apple/swift-evolution

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Dec 4, 2015

Git(Hub) makes the process public and transparent, something I believe to be important. Anyone can contribute to the process if they desire, making it accessible too.

I agree with this. This is why I couched my comment. MODX's historical product discussions were cloistered in the forums and then, to some degree, in private conversations. Git(Hub) does seem like a fine place to manage the project on a higher level to set the goals and managing principals and the chief problems we're solving.

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Dec 4, 2015

Further to the topic of the new Manager, before we start committing or submitting PRs, it feels like defining what the next Manager should be.

What if we use a channel on the MODX.org to post and discuss different ideas and PoCs? We could even Slack Reactions for a simple method of polling.

I like the idea of a separate repo with Markdown documents too. That would allow people to submit "specifications" for how certain things should be approached. I think that could really improve whatever MODX Next becomes.

It may be true that the project has had a difficult time putting together a roadmap (and so on and so on) but I've also come to realize that shouldn't stop people from stepping back and attempting to make progress in more abstract ways. The MODX Community collectively has a lot of experience in the tasks at hand so let's make a space for it to formerly contribute to early stages of the project.

IMO a lot of what we are talking about boils down to "how do we make a MODX Manager the MODX way?". Something that is abstract and not bound to a particular JavaScript library. Something that is future proof. Something that Extra developers can progressively enhance with creative freedom over the components their users will use. A manager experience with the same type of creative freedom we celebrate when powering sites brought to how we manage sites.

This might seem like a daunting task but I agree with @jaygilmore that if we start by looking at user tasks flows and focus more on things from the users perspective than reverse engineering a UX from how things were developed we could create something truly amazing but more impressively truly MODX.

@jaygilmore

This comment has been minimized.

Member

jaygilmore commented Dec 4, 2015

It may be true that the project has had a difficult time putting together a roadmap (and so on and so on) but I've also come to realize that shouldn't stop people from stepping back and attempting to make progress in more abstract ways. The MODX Community collectively has a lot of experience in the tasks at hand so let's make a space for it to formally contribute to early stages of the project.

Absolutely, yes.

@OptimusCrime

This comment has been minimized.

Contributor

OptimusCrime commented Dec 4, 2015

I really like what @Mark-H linked to. That is like php-fig is suggested too

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Sep 24, 2016

I took a swing at a PR to add Service Workers to 2.6 manager assets which would cache manager assets offline and increase snappiness.
The worker installs and activates but doesn't intercept fetch events. I can't say definitively but I'm assuming this has to due with the doctype not being HTML5.

So I wonder if it would be worth testing if ExtJS still works with the new doctype...

@jpdevries

This comment has been minimized.

Contributor

jpdevries commented Nov 22, 2016

I just noticed that the Manager uses the HTML5 doctype now. I'm not sure when that changed. But it is still using xhtml xmlns...

Can we remove the xhtml xmlns?

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="nl" xml:lang="nl" manifest="/manager/cache.manifest.php">
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment