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

[felix]

Hi Everyone,

the last days i read a lot about the ongoing process of "modernizing" the admin theme, adding some features and getting some marketing buzz from people who aren't currently aware of processwires awesomeness due to the fact they didn't like the current admin theme.

I must admit that at first was one of those "design oriented" guys and didn't dig deeper into the system because i didn't liked it's look & feel (or at least i thought it doesn't look "professional" enough to present it to our customers).
Fortunately a colleague of mine finally managed to convice me giving pw a second try. After digging deeper i started to really like the concepts behind it. I tried different admin themes and git stuck with "ergo" which we currently are using on several pw instances. Although i weren't completely happy with it's look and feel on several details (but that's just me: i never heard one of our customers complaining ). The Idea of doing a theme by myself started to grow in my mind.

After doing several layouts that "just beautified processwire to my taste" (i can post a "design evolution summary" if anyone is interested) i took a step back and started doing some more conceptual work and research. Specifically i thought about which "personas" are using processwire and for what reasons they are using it.
Also i tried or looked at screenshots of some more "hyped" systems (ghost, anchor, craft...), asked out some (dev) co-workers and others who are content editors (which are the two main "groups" of personas imo) what parts of processwire could be done better or used in a more efficient way. The good (but not surprising) news is: There were almost no complaints about the current features. 

Long story short: With the "benchmark" in mind and some feedback i again started layouting. I rearranged some buttons, menus and tried to give processwire a more modern, clean and "up to date" look. But before i'm going to code all of this i wanted feedback from a broader audience so i can propably fix or correct things that you as everyday users aren't happy with.

Here we go:

• I used the "w" of the processwire logo as a "picture mark" as it is pretty unique and can easily be recognized and remembered (You could also use this as a favicon).
• I kept using "processwire colors" for brand/product recognition (i know ryan stated people are complaing about them) but also tried to use them in a very minimalistic way so there is nothing that distracts editors from the content.
• I chose the menu to be positioned right for two reasons:
  • 1) Content first! The most part of work in processwire is editing and creating content. So why shouldn't content "rule" and be the first and most important thing (at least for LTR Readers)?
  • 2) With the buttons and the menu both at the right side there is a "cluster of functionality" which makes it more efficient: Shorter ways for eye- and mouse movement, less things to "overlook" when actually editing content.
• The pages options within the tree are hidden (again: reduce visual complexity) into a dropdown with only the most commonly used one (edit) beeing shown (this should be configurable).
• The Font is the beautiful Fira from Mozilla <3

• The messages are displayed "growl style" and can easily be closed by the user (or close themselves after a certain amount of time)

• I chose to use the content of ryans "new theme" example screenshots to make it easier comparing them in terms of visual hierachy.
• As you scroll, the buttons on the top will pin and scroll with you. This way it's always possible to save or view the page at any scroll position (the save/publish buttons are part of a module that's currently in devlopment here). 
• The bar at the bottom will contain some shortcuts as well as less frequently used / system related stuff (i.e: user profile and logout).

• "Zen Mode" with closed menu. Just you and your content

• For those who like it bright: An example of an alternate version which is even more minimalistic.

From my point of view there are some things still missing. I thought a lot about including a possibility to open the page tree from everywhere (as in Nico Knolls Dark Business and the ongoing Discussion in the Two column admin theme concept). I think this might be more effective to just test it from a ux perspective when actually coding the theme.

My Idea is to build a static clickdummy and put it on github before actually releasing a "real" theme (with all the logic / js work to be done) to do some usability testing.

Thanks for reading and i hope there will be some feedback!

Best regards,

Felix

[apeisa]

This looks super clean! Also I think this builds upon PW strengths without trying to "re-invent" everything.

If you pull this with same quality code than these UI screens are, I think this would be definitely great candidate as a next default theme. As Ryan has mentioned the current improvements are some "first aid" for the theme challenge, all doors are open to take this to next level.

[felix]

Hey apeisa,

thanks a lot for your feedback which leaves me sitting here with a big smile

Quality frontend code is in fact something i'm really passionate about. In my mind i'm already doing some nice ux stuff as well as optimizations concerning a11y to existing markup and scripts while introducing some "up to date frontend stack" (grunt, sass, bower).... But for now let's wait for some more Feedback to come.

[ryan]

Beautiful work! I'm currently over my head on client work, but just wanted to quickly drop in and thank you for your great work and thinking here. I'll come back with a better reply (and catch up with the rest of the forums) once I get through this marathon work week.

I've been working on admin theme stuff a lot lately (before this week at least), so it's very fresh on the mind and I'd be happy to collaborate on the back-end side too. 

[BUCKHORN]

Can you make it responsive? 

[owzim]

Wow, looks great. Looking forward to the implementation.

[felix]

Beautiful work! I'm currently over my head on client work, but just wanted to quickly drop in and thank you for your great work and thinking here. I'll come back with a better reply (and catch up with the rest of the forums) once I get through this marathon work week.

I've been working on admin theme stuff a lot lately (before this week at least), so it's very fresh on the mind and I'd be happy to collaborate on the back-end side too. 

Thanks a lot ryan! I can't wait to hear more details.

Can you make it responsive? 

It's 2013. What do you think? Sure it will be responsive!

For a "normal" (consumer) website i most certanly would have done a "mobile first" design. But for me processwire is a software that is used by "professionals" as part of their work (either developing or creating content). So i created it with "desktop first" usage in mind as most people are using some sort of desktop computer for their daily work. "Mobile optimization" will be done while actually coding the theme (though i did think of several things performance wise while designing... if you're interested in some really cool videos and links i'll open up a topic in "Dev Talk" as this is a little bit off topic).

 

Wow, looks great. Looking forward to the implementation.

Thanks!

[felix]

Since there were no further replies I thought i might share my Ideas concerning "what would be a perfect frontend for the backend" from a technical point of view. Again: I started to code some stuff, took a step back and thought it would be interesting to get some input on my considerations first. This list is not meant to be complete but only a preliminary result of my current thoughts:

 

What could be improved on the current technical setup of the backend?

 

Modularity

Not only PHP but CSS as well as Javascript should be modular. To do this "right" there should be some considerations about how things are structured and the way modules inject their assets into the system:

• Modular Javascript: My proposal is to use a module based javascript loading technique. Until EcmaScript 6 modules will finally have a broad support in the majority of browsers the way to go here would be UMD (or namely require.js). There would be several benefits from using this kind of loading technique: The Global Namespace would be much less polluted, Scripts would only be loaded when they are needed and multiple files can be loaded in parrallel. Furthermore there this technique ist "non blocking". This means: While loading scripts the browser continues rendering the frontend without having to wait for all assets to be completed. The core modules could be combined into a single file to minimize requests and speed up the application even more.
• Modular CSS:  From my point of view an OOCSS Architecture (BEM, SMACSS to name a few) would also give us several benefits. Current modules often have to fight a "!impoprtant war on specifity" with core components due to the fact that there are several pretty specific selectors. This could be eliminated by using a flat, object oriented, reusable set of classes that can be extended.
  To give an Example of this here is some CSS from the default theme:

  .PageList .PageListItemOpen > a.PageListPage {
  color: #000;
  background-color: #ffffdd;
  }
  

  in BEM Syntax this would be: 
   

  .pagelist__item--open .pagelist__page {
  color: #000;
  background-color: #ffffdd;
  }
  

  To alter this and avoid more descandant selectors you just add another class of .pagelist__page--myfunkyalternation and thus can see by the name it's a changing the page element.

• Modular "External Frontend Components": I personally like using bower to manage external frontend ressources. It really simplifies the way of downloading and updating them. There are some things to consider when it comes to structuring them, though.

Performance

Not only the "frontend" part of the Website / App you're about to build should be fast. There is a huge demand for responsive backends not only when it comes to displaying and using them on mobile devices. Most people that left the ModX community (and i'm sure there are others facing the same problem) did this because of it's sloppy and slow backend. While the processwire is stunningly fast now, there are always some things to tweak and optimize

On a sidenote: There has been quite a buzz about this in the last couple of months (as mentioned in this thread) which could also help market PW and "ride this wave".

Btw: My co-worker just sent me the link to a standalone PHP asset optimisation & manipulation library. This fits in here quite well: http://mun.ee/

 

Accessibility 

This is also a huge one. Modern Applications should be as accessible as possible. Consequent usage of WAI-ARIA, meaningfull / semantic Markup and a bunch of related a11y techniques would make the backend more accessible for people with disabilitys. This is also a "Killer Marketing Criteria" as most western governments and their organisations have to put a special focus on choosing software that is accessible for anyone who works with it. Currently there aren't many (Open Source) CMS which match these criterias well.

 

Testing  

There should be (frontend) tests for all crucial core components. This is also something which can be used for marketing when it comes to CTOs making decisions about whether to use a system or not  

 

 

As stated above this list isn't meant to be complete (i didn't mention grunt which is awsome for simplifying some of the above tasks for example!) and subject to be changed and updated with great Ideas from the community which are missing until now.

Having said that: Your Feedback is greatly appreciated!

[diogo]

Felix, great write up and many great points. This takes the admin theme discussion to a new level. I agree with all your concerns (not necessarily the proposed solutions as I would have to study them better). Of course, addressing all these is not a task for someone that has all the CMS to think of (Ryan), so it would make all the sense to form an admin theme task force.

You seem a bit impatient with the lack of answers to your posts, which is good. I'm sure it's not lack of interest but mainly lack of time. The questions you are raising are interesting and certainly people will jump into the discussion.

[felix]

Hi Diogo, thanks for your kind answer. I'm "not really" impacient as i understand that this is quiet a complex topic to deal with (at least if you're not coming from a frontend-dev background like me). I can't expect to just "throw my thoughts in" and have people think about and engage with them it as if they had nothing else to do. But yes: I wanted to push this a bit further and give some more input to discuss about.

IMO it's always good to have some (maybe controversial) foundation to discuss about as a starting point. Just looking at a "nice design" and literally asking people to start a discussion about a "good frontend" was propably not enough as design (for some) is somewhat subjective. People tend to focus on details instead of the topic as a whole. So if there is a big list of consumptions maybe someone will engange for some specific thought or technology quicker.

[SteveB]

Felix, thanks for taking the time. Tools, devices and standards are such a moving target that it's easy to fall into analysis paralysis. One of my favorite things about PW is that it doesn't assume you will use a particular frontend solution so I'd say the "perfect frontend for the backend" is one which can be replaced. For being able to work at a wide range of scale and withstand changes in the web environment simplicity often wins out. If we throw enough problem solving tools at a problem don't we create a new problem? Will Bower, for example, be your favorite front-end package manager six months or a year from now? Will it be a pain to change it out?

I think Ryan's been smart to leave frontend up to the developer and to strive for admin pages that support anything you can come up with in PW, even if that means less then optimal user friendliness. Yes, I'd love to have slicker admin tools. That would make my work more pleasant and with some tuning and configuring could be great for clients to use. If we're going in that direction perhaps the goal should be to have PW core stick to having a spartan (I mean that in a good way) but robust and scalable admin interface, which supports but does not require the modernized, design-oriented, slick, next-generation, fun to use thing we all seem to want.

Contributed modules and themes extend the present PW admin and I think we should retain that option but perhaps what Felix and others are getting at is a third thing. Not the public face of a site and not the nuts-and-bolts technician's access panel, but something with aspects of both. A third thing, which depends heavily on frontend which in PW is an application specific developer decision, not something baked into the framework. That's a strength of PW. The admin pages are an exception but let's not drag too much decor into that toolbox. How about doing this third thing as regular pages hidden and protected by roles and permissions?

Sealed with a K_eepI_tS_impleS_tupid.

[diogo]

SteveB, lett's not forget that PW already uses jQuery and jQuery UI on the backend, and now even SASS, so it's already making some —also probably questionable— choices there, and I don't think Felix's choices are necessarily heavier. I completely agree with Felix that a tool for web developers should give the example of excellence in web developing by applying all possible developing and design good practices (let's not fall in the same mistake as Textpattern that used tables on the backend layout until very recently, or is it still like that?).

[felix]

Hey SteveB

Actually what I'm aiming for is exactly what you've mentioned: A modular backend that can easily be themed and extended. Apart from bower (which i personally like but i'm not surprised others don't) nothing of this is actually something that ties you into a specific Framework (in fact the processwire backend does already tie you to use specific frontend components - namely: jQuery and jQuery UI and there is nothing wrong with that as they are widely known and used). What i'm promoting is more of a "keep the backend fast and modular" approach which provides theme developers even better tools to achieve their very own personal setup.

Maybe the design and the "improvement of technical setup" threads should be separate discussions. What do you think? 

//Edit: If I read your post a second time: Maybe there has been a misunderstanding. I didn't talk about making any changes to the way processwire assumes what you will do with it in the frontend. That's the thing i actually like the most about it and i'm totally with you it shouldn't be changed (if i were thinking about how to change the way processwire works I'd be better off searching for another CMS.)! Again: I'm only talking about the "frontend of the backend" here.

//Edit2: I just realized that this actually might be the kind of productive discussion that i was aiming for. I get your point that complicating things too much is very valid. If processwire would only be customizable with a higher computer science degree (which i don't have either) that would be very contra productive. Thanks a lot for your input!

[SteveB]

Diogo's right of course, there's already front end stuff in the admin but it's fairly conservative. Separation of duties between the core admin and a more frontend focused fancy tool could allow the core admin to be even less dependent on third party tools, the ebb and flow of UI trends, etc.

I'm not taking a Luddite stance, I'm just thinking that anything so cutting edge as to be like Felix said, "applying all possible developing and design good practices" will forever be in Beta but we'll always need a stable, solid, easy to support and troubleshoot admin tool. These are two different requirement sets.

Felix, it sounds great and I don't have anything against the tools. I brought up the observation about PW leaving frontend out of the framework (which we both like) to support my reasoning which goes something like...

Admin pages with state of the art bells and whistles have lots of frontend.

Frontend is not baked into PW, for good reason.

Therefore this new cutting edge admin thing should not replace the standard PW admin system we depend on.

Having it separate would take some feature creep pressure off of Ryan. Standard admin could be as "pure" and failure proof as possible.

By separating these two admin interfaces they are each freed from having to meet criteria which pull in opposite directions.

(fixed a typo)

[felix]

Diogo's right of course, there's already front end stuff in the admin but it's fairly conservative. Separation of duties between the core admin and a more frontend focused fancy tool could allow the core admin to be even less dependent on third party tools, the ebb and flow of UI trends, etc.

Ok: Let's just leave out the fancy design for now. If we do that there is exactly one tool apart from bower which I've mentioned: require.js. If you don't like using this: I'm OK with that from a "don't use too many fancy libraries" point of view (but IMO there are - as i mentioned - several good reasons to think about it). Other than that I only talked about making things more modular and fast which isn't dependant on any library or framework.

When you remove the "prose part" i was basically saying:

• Modularity
  Use OOCSS and make Javascript less dependant on Markup and other Javascript
• Performance
  Keep an eye on performance issues and make things as fast as possible
• Accessibility 
  Add some markup that helps disabled people to use processwire
• Testing  
  Good software (which processwire is) should be tested

 

I'm not taking a Luddite stance, I'm just thinking that anything so cutting edge as to be like Felix said, "applying all possible developing and design good practices" will forever be in Beta but we'll always need a stable, solid, easy to support and troubleshoot admin tool. These are two different requirement sets.

I'm with you here. Let's take OOCSS as an Example: For a long time I didn't like the concept of OOCSS and kept using descandant selectors for "all the things". While this is a conservative and valid way to write CSS there are certain pitfalls and problems which make it hard to maintain and extend. When it comes to complex frontends that are beeing maintained and extended by multiple developers it's good to have some structure and guidelines to assure everyone is running in the same direction. I recommend reading these articles to dive more into this concepts. Implementing - for example - BEM syntax and methodology would be pretty simple: It's only thinking about structure in another way and adding / removing some classes. As diogo mentioned SASS is already used in the new admin theme and i'm pretty happy with that as it adds another layer of easier theming and DRY.

 

Admin pages with state of the art bells and whistles have lots of frontend.

If I were about to introduce a lot of "state of the art bells and whistles" i would have mentioned doing the backend with angular, ember, polymer [more namedropping and fancy frontend frameworks here] or even building a processwire api framework which acts as a facade and abstratcs dom manipulation and common tasks out so you could even drop jquery and use zepto, prototype or yui instead. But I didn't do that for a reason. I'm fine with keeping it simple (stupid) and not overenigneering things (I've done quite a lot frontends for magento which imo is an overengineered nightmare and a perfect example how to complicate things while maximizing modularity to a level no one will ever need).

 

Frontend is not baked into PW, for good reason.

Therefore this new cutting edge admin thing should not replace the standard PW admin system we depend on.

Sorry: I can't follow your argumentation at this point. I'm still not getting what the fact that processwire doesn't bake in anything at the frontend has to do with the style the backend is implemented. The frontend part is "your project": This is the what you are going to produce the way YOU like and processwire is a very efficient tool which helps you to achieve this without getting in your way. So if we make processwire even more efficient and customizable (if you're interested in customizing things) what makes that a bad thing?

 

Having it separate would take some feature creep pressure off of Ryan. Standard admin could be as "pure" and failure proof as possible.

By separating these two admin interfaces they are each freed from having to meet criteria which pull in opposite directions.

Why would one need two interfaces? I think it's OK for both editors and developers to have a decent, up to date, simple, good looking, efficient tool to work with. For me there is no need to seperate things here.

[felix]

Concerning "fancyness" and the Design part:

Maybe it's easier to understand where I am heading if I share some more general perspective of engagement with you:

•  I adore the system and want to give something back
  
•  I'd like to make processwire more known as we would all profit from this in several ways
  
•  I like the way the processwire community acts and communicates: You're all kind and lovely people around here in the forums
  

Having said that here is "my plan" to discuss and think about

I'm a CTO and developer at a Communication Agency and (as i already stated) and have a strong design & UI background as I completed vocational training as a media designer. I'm also very interested in marketing. To be kind: What I'm trying to do here could be summed up as "Content Marketing". 

To Explain this further: Me and all my co-workers were in search of a "perfect" CMS that fits our needs because we were tired of all those typo3s, drupals and wordpresses out there. We discovered processwire and all loved it. I even managed to convince my boss that we should start using processwire as our first choice CMS because it seems promising in the long term. He agreed because he trusts me with this kind of decisions. That was mostly because I told him that I know there are plenty of other developers feeling the same. That's a good starting point: When a lot of people are searching something there is a business case for it.

But there was one thing we didn't like and in my opinion is a reason processwire doesn't get the credits it deserves: The design of it's backend which until now (sorry: no offense ryan) looked kind of "oldish" (i love where the new dev-branch theme goes though).

If you're looking at choosing processwire from a bussiness perspective it is nothing (at least our) customers already know, so there are some things to consider apart from how efficient and fun it is to build websites with:

• How do i convince my customers this is the CMS he needs?
  
• Will my customers have "fun" using it and be satisfied (as in "WOW, this is SO SIMPLE and BEAUTIFUL" i'll recommend it to all of my partners and drop my MS-Word for it!!11)?
  
• Will there be more attention (and thus more potential jobs) in the future?
  
  • If not: How can we manage to draw more attention to it (again: for us and the community because we do believe it should have)?
    
  • Most people like "nice looking and simple" things (take the iPhone for example). Processwire is (imo) just simple yet. That's good from a developer point of view but won't sell you anything. So let's work on that.
    
  • If we made it more "nice looking" we can start the "marketing machine" saying: Customers love it's look AND developers it's simplicity. It's so super-duper awesome that a really big bunch of hip "early adopters" (that's us!) is using and has written some articles in about it (which is something we're about to do, too).        
    
  
  
• The people you should try to reach here aren't just developers but designers and marketing guys who are really good at sharing and promoting things once you've conviced them that this is an awesome system to use.
  
• Once PW is more known: How can we position ourselfs as experts when someone is looking up people who implement things with PW for him?
  
  • Engange
    
  • Be visible
    
  • Help making things better
    
  • Promote where you can
    
  
  
• Last but not least: World domination! ;D
  

Ghosts marketing did a pretty decent job on that (except for the world domination): No one knew how the system would work but it looked simple and beautiful so it got a big buzz, is widely recognized and people are starting to build stuff with it. I know Ghost reaches out for a different kind of users (more End-users and Bloggers) and I didn't dig too deep into Ghost but as far as I can tell it's pretty "basic" compared to what processwire can do. 

[Beluga]

Hmm.. if I may try to correct a possible misunderstanding on Steve's part: Felix was saying the word "frontend" a lot, but it was in the context of "frontend development" - NOT about the Processwire frontend vs. backend! So he was talking about best frontend development practices for strictly the PW admin interface.

(Sorry, if this is superfluous at this point, just not sure if we are all on the same page)

[adamspruijt]

I have to say I agree a lot with what Felix is saying here, though I sure our methods would differ in some ways the overall message is the same, the admin interface is holding PW back. While the new design is an improvement (for the most part) it really doesn't hold a candle to Ghost, Craft, Statamic or even WordPress, and I feel like this is at an extreme odds with how the API its self functions which is clean, modern, easy, concise and beautifully self apparent.

Some of the other things mentioned here I have mention before as well, a more modular approach, fixing the massive overuse of !important, migrating away from jquery ui (its antiquated, bloated and generally looks like shit, sorry), adding font icons (in the new default! yay!) so on. I believe PW can dominate if its gets the "sex appeal" it sorely needs and frankly the new theme still isn't going to get us there, not yet at least. 

[slkwrm]

Hi Felix, hi everybody. Long time no see!

I have mixed feelings about this idea of pimpin' up PW's backend. Currently PW doesn't make many assumptions about previous expertise of the developer who uses it and requires very traditional skillset apart from jQuery which knowledge is de-facto standard for any front-end developer. And this fact is the key concept that makes PW open and friendly for everyone. The thing is, people still can use BEM OSCSS or whatever they want if they build with PW as it's a framework as much as it's a CMS.  You can use existing backend and build on it or even start from scratch if needed. You can use any framework but you're not forced to do it.

I don't think current default back-end needs loading optimization at the moment. PW has one of the fastest backends I've ever seen. IMO, optimization at this point would be premature and profit would not be worth the effort.

BEM and OSCSS (don't know about SMACSS) are templating ideologies aimed mostly at large projects with big dev teams. Yandex, the largest Russian search engine company (kind of little-scale Russian Google) who invented BEM, use it in their projects because they need it for their very complex and unique projects. They wanted to shorten render time of their interfaces in (mostly) older browsers and to standardize the way their teams worked. These problems are very rare for most projects. So modular CSS, IMO, is a marginal demand.

MODX made a big mistake putting their chips on ExtJS in the back-end of Revo branch. They lost many loyal devs since then. Partly because this framework was marginal at the market and its learning curve was steep. Let's not step on the same rake.

Not sure but I guess modular JavaScript could be added optionally via a module.

The strength of PW is its openness to any developer and, I dare to say, any user. It was a relief for me to see PW's interface. I'm not sure PW has to compete with these systems as (for me) it already has a better interface. Less noise, less distraction, less confusion = more focus, more flow, more get done.

Accessability is a good point. I think this kind of interface extension could be implemented as a module. Btw, I believe BEM and semantic markup ideologies are not compatible

As far as I know there is a project for core testing in PW, but not sure if it's active. Ryan can tell for sure.

I'm inclined to think that PW's default backend should stay as slim as possible in terms of dependancy on third party frameworks and concepts but be as extensible and hookable as possible. Every new "hard-coded" concept or framework will bring new element of complexity to a system, make it more closed, and make learning it more difficult. All these features proposed here are really great and PW will definitely win more developers and users if it implements at least some of them.  But, IMO, they have to extend or override PW's defaults not substitute them. Another way is to start an alternative backend project that would embody the latest tendencies of front(back)end development and help make some hype in more visually-oriented and framework-aware crowd.

[felix]

Hey, thanks for your answers. I'll write something tomorrow. Had no time today

[Macrura]

it really doesn't hold a candle to Ghost, Craft, Statamic or even WordPress

did wordprass change something? I really don't like WP backend, default PW is vastly superior IMHO... i can get so much more done and much faster..

[adamspruijt]

did wordprass change something? I really don't like WP backend, default PW is vastly superior IMHO... i can get so much more done and much faster..

I'm talking about form/style not function. ProcessWire arguably functions better and more logically than any of those CMSs by a long shot. WordPress might be a bit bland but it is consistent, though not the best example I believe it is still better than PW 2.3 admin (aesthetically).

[diogo]

If I'm not mistaken the design of the WP admin is from Jason Santa Maria. Couldn't be ugly for sure...

[felix]

I have to say I agree a lot with what Felix is saying here, though I sure our methods would differ in some ways the overall message is the same, the admin interface is holding PW back. While the new design is an improvement (for the most part) it really doesn't hold a candle to Ghost, Craft, Statamic or even WordPress, and I feel like this is at an extreme odds with how the API its self functions which is clean, modern, easy, concise and beautifully self apparent.

I'd love to hear the methodology you would have chosen!

 

 

Some of the other things mentioned here I have mention before as well, a more modular approach, fixing the massive overuse of !important, migrating away from jquery ui (its antiquated, bloated and generally looks like shit, sorry), adding font icons (in the new default! yay!) so on. I believe PW can dominate if its gets the "sex appeal" it sorely needs and frankly the new theme still isn't going to get us there, not yet at least. 

I also not a big fan of jQueryUI for the same reasons you've already mentioned. Removing it would mean to rewrite most of the core JS though. That'd be a pretty substanical decision to make.

 

 

--

 

 

I have mixed feelings about this idea of pimpin' up PW's backend. Currently PW doesn't make many assumptions about previous expertise of the developer who uses it and requires very traditional skillset apart from jQuery which knowledge is de-facto standard for any front-end developer. And this fact is the key concept that makes PW open and friendly for everyone. The thing is, people still can use BEM OSCSS or whatever they want if they build with PW as it's a framework as much as it's a CMS.  You can use existing backend and build on it or even start from scratch if needed. You can use any framework but you're not forced to do it.

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).

 

I don't think current default back-end needs loading optimization at the moment. PW has one of the fastest backends I've ever seen. IMO, optimization at this point would be premature and profit would not be worth the effort.

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

 

BEM and OSCSS (don't know about SMACSS) are templating ideologies aimed mostly at large projects with big dev teams. Yandex, the largest Russian search engine company (kind of little-scale Russian Google) who invented BEM, use it in their projects because they need it for their very complex and unique projects. They wanted to shorten render time of their interfaces in (mostly) older browsers and to standardize the way their teams worked. These problems are very rare for most projects. So modular CSS, IMO, is a marginal demand.

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.

 

MODX made a big mistake putting their chips on ExtJS in the back-end of Revo branch. They lost many loyal devs since then. Partly because this framework was marginal at the market and its learning curve was steep. Let's not step on the same rake.

Once again: I never mentioned replacing jQuery with something else (especially not ExtJS which is a nightmare). I'm fine with using it although the way it is used could be more modular and less dependant on certain dom structures (proper event delegation, micro-templating or even directives like in angular would be fine).

 

 

Not sure but I guess modular JavaScript could be added optionally via a module.

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.

 

 

The strength of PW is its openness to any developer and, I dare to say, any user. It was a relief for me to see PW's interface. I'm not sure PW has to compete with these systems as (for me) it already has a better interface. Less noise, less distraction, less confusion = more focus, more flow, more get done.

This - for some people - is quite a subjective one. But from a "professional" point of view there are quite a lot of things that could be done better (in terms of UI/UX). PLUS: If you want to sell/market something it better looks "sexy"

 

Accessability is a good point. I think this kind of interface extension could be implemented as a module. Btw, I believe BEM and semantic markup ideologies are not compatible

Accessability is more like a way of thinking about and architecturing things. Many of the core modules which either produce DOM-Elements or modify them (js) would need some tweaking.

 

As far as I know there is a project for core testing in PW, but not sure if it's active. Ryan can tell for sure.

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).

 

I'm inclined to think that PW's default backend should stay as slim as possible in terms of dependancy on third party frameworks and concepts but be as extensible and hookable as possible. Every new "hard-coded" concept or framework will bring new element of complexity to a system, make it more closed, and make learning it more difficult. All these features proposed here are really great and PW will definitely win more developers and users if it implements at least some of them.  But, IMO, they have to extend or override PW's defaults not substitute them. Another way is to start an alternative backend project that would embody the latest tendencies of front(back)end development and help make some hype in more visually-oriented and framework-aware crowd.

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.

[apeisa]

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!