[UI/Concept/Drafts] - a modern admin theme

[slkwrm]

How would using modular patterns change this? As stated before: the only thing "new" would be require.js. Apart from this BEM would even make it easier to change things (and you don't have to use it yourself if you are developing a module).

RequreJS looks good, no doubt. But does PW really need it at the moment? Will modular loading open new possibilities for backend development? I haven't encounter complains here about issues with using scripts when loading them traditionally. Please, correct me if I'm wrong.

Well if you count in the various module developers which also tend to inject customisations into the backend (new fields, admin pages...) you actually HAVE a huge amount of people working on the backend and NEED some sort of standardization. Just look at all this !importants in every module.

Yes, potentially there can be a lot of developers but even then even then, I'm sure, BEM is overkill for PW's backend. Yandex use set of tools to automate BEM project's deploying (can be found here http://bem.info/tools/bem/). Or do you mean using this methodology as guidelines and just hand-crafting css the BEM way?

If anyone's interested there's a good article about BEM to wrap one's head around this concept (and don't forget the comments section as there's an interesting discussion going on there):

http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/

this one is also good:

http://bem.info/articles/yandex-frontend-dev/

and this can help to  understand the evolution of the method:

http://bem.info/method/history/

Please note, Yandex has more than 150 frontend-developers and they create super-complex projects that are sometimes interconnected and so the context where the "block" can potentially be used is often unknown so this methodology suits their projects well. I think that more concise "backend's frontend" development guidelines would be more suitable. Or maybe limit BEM's usage to certain rules of its simplified version.

IMO the real reason of the backend "outdated" feel at the moment is primarily jQueryUI, which I guess was chosen by Ryan as it provides quick and dirty way to have a very decent UI though not extremely sexy. Sex appeal is a good thing if there's a substance behind it or you are risking to end up with one night stand)

Also wanted to mention that to me it's not totally fair to compare PW to Craft and Anchor as they are blogging platforms that have more rigid structure and definite purpose so they can afford to have beautiful interface without thinking about flexibility and adaptability. Craft looks good and can be a role model for PW but what's interesting it doesn't use any progressive frontend paradigms. It seems they have their own homegrown "Garnish UI toolkit" and parts of jQuery UI. Don't know much about this CMS so can't really say anything about its flexibility compared to PW.

You're right. Processwire is blazing fast. I'm only drawing a picture of a "better" (from my point of view) architecture.

The best is the enemy of the good. Just a Russian saying) I have a parallel with PHP here: it seems like everybody hate it, but at the same time it's the most used web-development language out there. It works just everywhere and it's possible to start making sh*tty websites in minutes! But then there's a depth and space to grow.

Yes and no. The "cleanest" way would to wrap all (core) modules into a define(...); closure. You could go and "shim them" all instead. But that's a nasty thing to do.

So what changes would be required to PW core to make it work the proper way? Can it be injected as an option via PW module? As far as I understand, jQuery is AMD compatible but not all its plug-ins so then one have to shim them. Is it correct?

This only covers the PHP Part. No JS-Testing until now (there are again some requirements for this - scripts need to be written a certain way to make testing efficient and reasonable).

Oh, sorry. I see what you mean now. Does it have to be a js-testing framework of some kind?

Maybe you're right. I'll explain this a bit further in an upcoming post as i don't have time to write down all my thoughts on this now. This has a lot to do with how different personalitys and the way they handle changes to things they are already used to. Maybe it's the best way to start off with a theme, get some feedback and then as development continues some ideas and code might find their way back into pw. I don't like the idea of starting a fork of PWs backend as i think this would be pointless and do more harm to PW than it would help. Nevertheless it'd be great to keep this conversation up and going.

Yeah, agree. Alternative totlal rewrite of backend is too much. It can be reasonable only if there's a plan to migrate to such new backend in future. I think your idea about a new theme is great. It would definitely help understand what is needed for a better backend.

Thank you for your thorough answers and interesting ideas!

[apeisa]

I understand that there is lots of discussion about admin themes currently - since the default is getting lots of improvements. As always when things change it will get mixed reactions: some people doesn't want any change at all, others are very happy and some are thinking that much more should be changed. What Felix is saying is pretty much total revamp of how ProcessWire admin theme is build regarding it's front end development. That kind of change is huge amount of work - and not something that most PW users are excepting. Soma is already feeling pain since one core css class name has changed Also admin theme revamp is not on roadmap: http://processwire.com/about/roadmap/ and that is the place where we look on "what's coming next".

That is also risky business in the regard, that front end is moving so fast currently. I agree with slkwrm, that many of the buzzwords floating around currently might not be around in next 2-5 years. So committing for something like SASS should be proven to last (there is lots of users, software, tutorials etc to support it).

I don't think I have had any serious problems with html,css or javascript clashes when building PW modules - and I have build quite a many already. So in my opinion there is no real need for total revamp at all. At least not yet.

The reasons why I really enjoy this discussion and think this is very important: it helps everyone to see what could be possible and what it would require to things like that. I also feel that I am learning a lot just by following the discussion. This discussion also helps to get better picture for coming years - especially when we start actually feeling more pain points in current architecture regarding admin theme.

PW api and architecture is so modular. that there is nothing - and I really mean nothing - that would prevent building totally custom admin theme that shows off these techniques. I would be thrilled to see something like that. Revamping the current default admin would mean tons of work for most of us (who have lots of sites and/or modules to maintain) without really taking PW forward to direction that really helps us (see the roadmap).

I hope that discussion continues in same tone and also would be superb to see some working drafts how those would function. People are rarely excited to learn new ahnd change their current tools. methologies or techonogies on their core business (it is just too time consuming and risky), but when benefits are great enough and shown in action - people will take a leap in quite a speed.

[Beluga]

That is also risky business in the regard, that front end is moving so fast currently. I agree with slkwrm, that many of the buzzwords floating around currently might not be around in next 2-5 years. So committing for something like SASS should be proven to last (there is lots of users, software, tutorials etc to support it).

I think SASS might be the least risky here. What's interesting is that the CSS Variables standard is already being worked into browsers (FF, Chrome):

http://dev.w3.org/csswg/css-variables/

https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables

https://code.google.com/p/chromium/issues/detail?id=164139

https://bugzilla.mozilla.org/show_bug.cgi?id=773296

http://vimeo.com/69531455

The writer of the Variables spec, Tab Atkins, seems to take inspiration from SASS a lot: http://www.xanthir.com/b4N80 (find sass on page). So I guess you can take that as a good indication of future-proofness

Btw. lots of tools popping up to make using SASS easier on any platform: http://sword.mu/ (no Ruby installation required on Windows).

[apeisa]

Beluga: yes, that is what I tried to say (my argumentation was little weak). SASS is strong player already and has clear benefits. Also not showstopper for anyone who doesn't use or know it.

[felix]

This is good discussion in my opinion. I agree with both, Felix and slkwrm. It is very important to keep things up to date and use best practices. As Ryan has many times stated, he is more "in home" with PHP than front end stack. But in the other hand using too many "cutting edge" methods/libraries/etc is dangerous too: it always makes steeper curve to learn and start using.

 

Anyways: I am really enjoying this discussion and the constructive tone that Felix is leading here!

Thanks a lot! I'm not always sure if the way i'm writing sounds like intended as my school english got kind of rusty over the years. But I enjoy writing in english and the discussion itself for sure.

On topic: 

Introducing new "cutting edge" stuff always includes a certain risk of the tools beeing discontinued and therefore betting on the wrong horse. Thats why all of the stuff I mentioned already has a strong foundation and is established among many users/projects.  

 

 

RequreJS looks good, no doubt. But does PW really need it at the moment? Will modular loading open new possibilities for backend development? I haven't encounter complains here about issues with using scripts when loading them traditionally. Please, correct me if I'm wrong.

You're propably right: PW doesn't actually NEED it but it would have certain benefits that i've already mentioned performance wise.

 

 

Yes, potentially there can be a lot of developers but even then even then, I'm sure, BEM is overkill for PW's backend. Yandex use set of tools to automate BEM project's deploying (can be found here http://bem.info/tools/bem/). Or do you mean using this methodology as guidelines and just hand-crafting css the BEM way?

I actually just meant the methodology. Sorry about not making this clear. I'm with you here that introducing the stack of tools as a whole that'd for sure be overkill.

 

Also wanted to mention that to me it's not totally fair to compare PW to Craft and Anchor as they are blogging platforms that have more rigid structure and definite purpose so they can afford to have beautiful interface without thinking about flexibility and adaptability. Craft looks good and can be a role model for PW but what's interesting it doesn't use any progressive frontend paradigms. It seems they have their own homegrown "Garnish UI toolkit" and parts of jQuery UI. Don't know much about this CMS so can't really say anything about its flexibility compared to PW.

Thanks for mentioning - i didn't look up the sourcecode of any of them. I was just talking about the general look & feel (and also mentioned they're not as complex as PW). If you look at them they seem "light" and easy to use due to their lack of clutter. That's what makes them a role model for me.

 

The best is the enemy of the good. Just a Russian saying) I have a parallel with PHP here: it seems like everybody hate it, but at the same time it's the most used web-development language out there. It works just everywhere and it's possible to start making sh*tty websites in minutes! But then there's a depth and space to grow.

There's a pretty similar saying in germany: "Das Gegenteil von Gut ist gut gemeint" (translated: "The opposite of good is something done with a good intention") which basically means that worst thing that can happen is people doing something wrong thinking it helps you and then rely on that.

 

So what changes would be required to PW core to make it work the proper way? Can it be injected as an option via PW module? As far as I understand, jQuery is AMD compatible but not all its plug-ins so then one have to shim them. Is it correct?

Correct. That's the complicated part about it. Either you'd wrap them all into a define() closure or shim them. But if you'd shim them you'll have to register all of those plugins and build a list which has to be dynaically generated into the require.js config (see: https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-shim ). 

 

Oh, sorry. I see what you mean now. Does it have to be a js-testing framework of some kind?

Yup. There are tons of testing frameworks out there (mocha, qunit, and jasmine to name a few). Then there are testrunners which run those tests not only on an (i.e. node) js-interpreter but in a real browser enviroment (like jsTestDriver or karma).

 

 

Yeah, agree. Alternative totlal rewrite of backend is too much. It can be reasonable only if there's a plan to migrate to such new backend in future. I think your idea about a new theme is great. It would definitely help understand what is needed for a better backend.

Yup. I've already started to code some stuff. But I don't have that much time currently as my family and some paid projects we're doing have more priority currently. But I'll try to release some code as soon as possible.

 

Thank you for your thorough answers and interesting ideas!

You're welcome! Thanks for your feedback!

 

--

 

I understand that there is lots of discussion about admin themes currently - since the default is getting lots of improvements. As always when things change it will get mixed reactions: some people doesn't want any change at all, others are very happy and some are thinking that much more should be changed. What Felix is saying is pretty much total revamp of how ProcessWire admin theme is build regarding it's front end development. That kind of change is huge amount of work - and not something that most PW users are excepting. Soma is already feeling pain since one core css class name has changed Also admin theme revamp is not on roadmap: http://processwire.com/about/roadmap/ and that is the place where we look on "what's coming next".

As already mentioned I'm only drawing a picture here. I'm aware of the fact that this is not something that could be done easily. My intention is more to "get this on the roadmap" for some future release or to have people at least think about it as well as getting a feeling if there are even people thinking the same.

That is also risky business in the regard, that front end is moving so fast currently. I agree with slkwrm, that many of the buzzwords floating around currently might not be around in next 2-5 years. So committing for something like SASS should be proven to last (there is lots of users, software, tutorials etc to support it).

 

The reasons why I really enjoy this discussion and think this is very important: it helps everyone to see what could be possible and what it would require to things like that. I also feel that I am learning a lot just by following the discussion. This discussion also helps to get better picture for coming years - especially when we start actually feeling more pain points in current architecture regarding admin theme.

I'd also like to keep discussion up and running. If there are people learning from it and getting inspired that's great and makes this discussion even more valuable for all of us.

 

PW api and architecture is so modular. that there is nothing - and I really mean nothing - that would prevent building totally custom admin theme that shows off these techniques. I would be thrilled to see something like that. Revamping the current default admin would mean tons of work for most of us (who have lots of sites and/or modules to maintain) without really taking PW forward to direction that really helps us (see the roadmap).

I'm currently investigating in how much work it would be for me to rewrite certain scripts but keep their functionality and don't break things. As you said: It's a lot of work and not something that can be done until tomorrow.

 

I hope that discussion continues in same tone and also would be superb to see some working drafts how those would function. People are rarely excited to learn new ahnd change their current tools. methologies or techonogies on their core business (it is just too time consuming and risky), but when benefits are great enough and shown in action - people will take a leap in quite a speed.

In my company constant change and adapting new technologys is one of our "core values" as we help our customers in changing their communication and methodologys a lot. So I'm pretty sure there will be more to come as this discussion continues

[totoff]

This thread has become quiet unfortunately. I wonder if you (Felix) have any plans do continue with your admin theme? It's definitely outstanding ...

[Manfred62]

independent from the work of Felix (I also hope he will continue with his theme), I think in the moment its better to wait with creating themes.

There's a more or less great change with admin themes in the PW dev version (2.4).

Admin Themes as modules, and also the translation part of admin theme is directly affected by this change. I'm sure Ryan will change some parts here.

[kongondo]

This thread has become quiet unfortunately. I wonder if you (Felix) have any plans do continue with your admin theme? It's definitely outstanding ...

See this post by Ryan - http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=49703 with respect to future PW Admin Theme...

When it comes to the bigger design project (PW 3.0), we'll hand this off to Felix and Phillip (and perhaps others), who have already nailed the concept. That's my opinion, but we'll seek the input of the community to decide. My experience has been that small team design=good results, community/committee design=bad results. But that's another conversation. We'll move onto talking more about that once we've got 2.4 final.

[felix]

This thread has become quiet unfortunately. I wonder if you (Felix) have any plans do continue with your admin theme? It's definitely outstanding ...

Thank you very much!

Yes I do. Please see my answers below. I'd love to further discuss the topics I brought up though.

independent from the work of Felix (I also hope he will continue with his theme), I think in the moment its better to wait with creating themes.

There's a more or less great change with admin themes in the PW dev version (2.4).

Admin Themes as modules, and also the translation part of admin theme is directly affected by this change. I'm sure Ryan will change some parts here.

Yup. That's the reason I'm currently waiting for 2.4 to be finished (I said that in another thread about writing blog articles, too). Otherwise I'd propably have to refactor all of the stuff on a daily basis. There currently is too much (very positive!) change going on. Apart from that there is a lot of other work to do. We're currently building about 6 websites in parrallel (all driven by processwire - yay!) which is good for our business but bad for doing sideprojects like this theme.

See this post by Ryan - http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=49703 with respect to future PW Admin Theme...

WOW. I didn't read that until now. Thanks for the hint