Joomla! 4 and Beyond: A vision for the end user

In the first post of this series we explored the unified marketing message for Joomla! 4 and beyond. Armed with this result let’s see how we can turn this into an actionable vision, starting with the improvements that affect our end users. The common theme behind all the improvements in this vision can be summed up as “Don’t make them think”.

Simplified installer

WordPress claims that it has a “famous 5 minute install”. It’s not famous, it’s not 5′ and it’s not a complete installation. It merely sets up the database. But it looks simple. The first experience someone has with WordPress is “man, that’s so simple”.

On the other hand, Joomla!’s installation procedure looks like a border check in the USSR.

Too many forms. Too many choices. It looks extremely complicated. I know it isn’t, but the newcomer’s first impression of Joomla! is “man, this is some seriously complex stuff”. And in software, just like in dating, first impressions make all the difference.

So let’s simplify it. Only show the absolutely necessary options by default. Hide everything else behind a click on an “Expert Mode” button. You know what? We can make it a single page installer, too.

Moreover, let’s generate the .htaccess or web.config file automatically. Running tests in a subfolder of the installation directory is cheap, easy, transparent to the user and we can enable SEF URLs without asking users to touch scary stuff through scary sounding FTP.

(An illusion of) Site and admin integration

I consider the separation of site (front-end) and admin (back-end) a very positive feature of Joomla!. But it does lead to user frustration. Why do I have to manually enter a special URL to access my admin panel? And why do I have to log in with the same username and password twice? Why logging out from site doesn’t log me out of admin or vice versa? Why are there “two pages” for editing the same article and module? We take it for granted but it confuses newcomers and the real end users tasked with the upkeep of the site’s content.

Let’s give an illusion of integration with a single sign on for both applications.

When you log in to one you log in to the other automatically, as long as you have the adequate privileges. Yes, it does have the potential to adversely impact security by making it more likely for an XSS vulnerability to be exploited so we can make it an opt-out feature. Advanced users can disable it.

Integrator mode

How often did you find yourself wondering which bloody module is being displayed on this page, what are the available module positions on this template and which view template you need to override to change that area over there? If you’re building sites of average or higher complexity you know what I mean.

What if we had an Integrator Mode in the Global Configuration, right under the Site Debug switch, which gives them x-ray vision on the site’s front-end?

Such an option could:

  • Let you see the module ID along with the Edit Module button.
  • Enable the use of tp=1 to display all available module positions, Joomla! 1.5 style.
  • Overlay an info icon with every rendered view template. Hovering it reveals the path, relative to the site’s root, of the original view template rendered AND the relative path to the required template override. Mark the active one (original or override) with bold text.

Comments

We must be the only CMS in the galaxy which doesn’t have comments.

For crying out loud, it doesn’t have to be a great commenting solution, just good enough.

Have you used WordPress? If you commented here you have. You see how the default comments work? It’s brain-dead simple. The Markdown integration isn’t part of the core, it’s a plugin. The default commenting solution of the most used blogging software on the planet requires the Internet to learn how to type raw HTML markup. I kid you not.

And I say let’s up the ante. You just need a choice between WYSIWYG, plain text, bbCode or Markdown for the comment text; nested replies up to 5 levels deep (it becomes unreadable soon after); avatar support (Gravatar by default, allow plugins to define additional avatars); allow any extension to use the commenting system (like we do with com_categories); allow content plugins to provide integration with anti-spam services (perhaps integrate with Akismet by default); allow our existing CAPTCHA system to be used for guests, all or none. The development time required is less than a person-month.

Custom fields

Not necessarily a 4.0 feature. I won’t lie to you that this can replace a dedicated CCK.

It can give some serious, UNADULTERATED CONTENT CUSTOMIZATION POWER to site integrators.

Allow per-category sets of custom fields with a default rendering method in our view templates. If you play this right you can have the fields stored in a separate table (not as JSON-encoded data in #__content) to make it searchable. And you can make the system pluggable to allow 3PDs to provide custom field types. As I said, not a CCK but it will help a lot of people deliver sites faster without tying their sites’ fates to 3PDs with whatever that means for their ability to update…

Content staging

We’re already so close but we got no cigar. The ill-advertised Versioning feature allows you to have one “live” version of your content and several (default: up to 10) “non-live” versions. You can even pin some of the versions to never go away.

What if we increased the states from two to three? We could have “live”, “staged” and “other” content. Then, if the user has enough ACL privileges, we could have a module which allows the front-end user to toggle between live and staged content. We could even have a plugin which enables staged content when the site is accessed through a specific hostname, even without a logged in user โ€“ if I want to test guest content for instance. Since this is a global application flag 3PDs can make use of it to provide their own staging features are well.

This does require some changes in the way we process article IDs meaning that the staged site will be slower, but I consider this an acceptable impact.

Not to mention that what people request when they say “multisite” is actually a simple way to stage their content. So here’s that.

A Media Manager which actually manages media

The current Media Manager should be properly called “Files Browser”. A proper media manager needs to store metadata of media files and help you organise and search it. Ideally a media manager requires:

  • Support for different media types: images, video, audio, miscellaneous documents.
  • Store metadata for each item: title, description, caption, tags, file size, dimensions (image, video), length (video, audio), format, MIME type.
  • Multiple media roots. Each root can be stored locally, on S3, CloudFiles, (S)FTP, Dropbox etc. This can be pluggable, of course.
  • Let the media manager provide resized versions of images dynamically (cached, of course). Each dynamically resized version should be also made permanent upon the administrator’s request with no more than one click.

A WYSIWYG editor apt for content creation

Those who actually know how to use Joomla! have long replaced the core WYSIWYG editor with JCE. Newcomers are left wondering why the editor is such a convoluted mess. My pet peeve is having two link buttons (toolbar and below), two image buttons (toolbar and below) and so on. This is madness! Some easy improvements:

  • Override the Link button of TinyMCE. At the very least allow users to search core articles and categories. Make it pluggable and you have the same experience as JCE and WordPress.
  • Get rid of editor-xtd plugins. Developers should be able to provide their own plugins to provide linkable content through the Link button of the Editor instead of custom editor buttons.
  • If you really insist on editor-xtd plugins the buttons should be rendered in the editor’s toolbar, not under the editor.
  • Let the editor expand in height as the content grows, without growing taller than the entire window. Use WordPress to write a long post and you’ll catch my drift.
  • Likewise, give the editor an opt-out “focus” (full screen) mode.
  • Drag’n’drop media to uploads & add it to the media manager and insert it into the document.
  • Pasting a YouTube link should be instantly converted to an embed without the need for a 3PD plugin and awkward plugin code of the {youtube}abcdef123{/youtube} kind. Make this feature pluggable to allow 3PDs to support services we may have never heard of but some people swear by them.

Simplify the Options โ€“ Workflow management

Over the last 5 years we’ve been adding features to all core components at the same rate rabbits breed.

The Options pages of core components look more complicated than the cockpit controls of a modern airliner.

We need an opt-out “dummy mode”. By default only show people the most relevant options and hide the rest behind an “Expert Mode” button. Turn it off to get access to everything. If you can customize which options to show you have a good step towards workflow management.

Workflow management requires more than that. At the very least I can imagine it requires a state machine which defines which user group can do what in the back-end based on some conditions. Since this is really not my area I’d like UX experts and people familiar with workflow management to provide feedback.

Routing and menus

This is actually an architecture item for tomorrow’s post, but since it affects end users I decided to make a short mention.

Having menus define the routing (URLs) is frustrating.

People have to create hidden menus to create custom URLs. If they’re not careful with the use of aliases vs real items they will end up with duplicate content or components doing “strange” redirections that are impossible to debug. In my opinion menu items and routing has to be finally decoupled, even if it means displeasing a lot of people in the process.

Improved multilingual

Can we all agree to call this “multilingual” and not “multilanguage”? Last time I checked our default language was English (UK) not Joomla! Creole.

The major flaw of multilingual in Joomla! 3 is that it’s convoluted and almost impossible to set up in an existing site.

Move the multilingual wizard from the installer into the CMS. Let people enable multilingual anytime. Doing so copies their home menu for each additional language but does NOT publish the language just yet.

When creating menu items and you have multiple languages set up allow the users to enter the menu item name and alias in all available languages. Then handle menu creation and language relations automatically for all the additional languages. When an item is created in a menu which has the Home element for a specific language make the language option of the new item default to the language of the Home element. When copying a menu item, category, article etc from Language A to Language B automatically create the language relationship between the original and the copy. DON’T MAKE ME THINK!

Improved ACL management

I’ve been using ACL Manager on the sites I’ve been building or upgrading because it has one fundamental feature missing from the core: an ACL debugger.

We need an ACL Debugger. Given an end node (menu item, article, category, …) and a username show me the ACL privileges results. For Denied rules show me which rule caused the Deny. Also allow me to enter my own ACL permission (e.g. com_foobar.something) and perform the same analysis. Even better, let me select an ACL node and show me all the groups’ permissions. Help me understand what the heck is going on with my site.

Content export and import

How do you currently transfer content between two sites? Have a hairless monkey copy and paste it like it’s the 1950s.

We can do better than that. We must do better than that. I know this is a tricky subject for two reasons. Primarily because of ACL and the impossibility of matching User Groups and View Access Levels between two different sites. But this is not a problem. Try to do a string match and if that fails warn the user and let them import with the default ACL privileges / access levels. The other touchy point is that lengthy export / import jobs can lead to timeouts, memory outage and so on and so forth. We can’t do anything about it other than allowing partial exports, i.e. selecting a specific number of articles or categories to export. Speaking of which, if we would add support for importing from WordPress’ XML format would allow people to import from a variety of sources, not just WordPress. Easier migration leads to easier conversion.

To be continued: Joomla! 4 and Beyond: architecture and design

62 Replies to “Joomla! 4 and Beyond: A vision for the end user”

  1. Apart from integrating comments which I disagree with and missing the ability to customise the admin interface/menus which I know you disagree with me on this ticked off everything on my list.

    1. Look, I don’t like comments as a core extension either. But people do use this argument to say Joomla! sucks. It’s easy to fix, it’s NOT going to please those who want to seriously use comments but at least we won’t be the village idiot any more.

      Regarding back-end menu customisation I don’t disagree with you on principle. I would, however, only accept such a feature if there is an “Unscrew my menus” feature easily accessible. I am currently seeing a lot of people running an outdated version of JSN PowerAdmin which has a bug that doesn’t allow the Akeeba Backup and Admin Tools menus to show. These very angry people jump on my throat for something that’s not my fault. One of them even filed a chargeback because our software “didn’t work”. If it becomes too easy for people to screw their menus we at least need a way to fix that, or you’ll end up with developers forcibly creating menu items in whatever structure they please to get rid of customers angry at them for a problem that’s ultimately of the clients’ doing.

      1. Even on WordPress sites I disable default comments and then install Disqus.

        It’s nice to have there but I’ve never used core comments in WP.

        1. Yet comments are one of the top requests in ideas.joomla.org ๐Ÿ™‚ If we don’t want to provide these features in the core we can at least change Install from Web’s landing page to promote the JED categories where the extensions for the top requested features exist. Right now people go in there and they’re “um, where do I start”. Not that I should complain. My own extension is top-rated and the first thing they see in the IfW tab. They just don’t install it because backups, who needs backups (said everyone until the lost their site to something silly they did out of sheer inexperience) ๐Ÿ˜€

    2. Comments are for blogs. Joomla is a CMS. Adding comments to Joomla is like putting feathers on a fish.

      1. Interesting analogy because there are flying fish, with feathers ๐Ÿ™‚

        Joking aside, I think there’s a misconception on what the C in CMS stands for. Content means more than static articles. A news item is content. A blog post is content. A hotel listing is content. A recipe is content. A song tablature is content. Content comes in all shapes, forms and sizes and many times it requires social interaction to make it valuable. Comments are just one way to do add social interaction.

        Is it for every site? No, of course not. This is why even in WordPress contents are an optional feature. You can’t generalize and say that comments must always be enabled or that comments must never be available. Just because you need / don’t need something doesn’t mean the same for everyone else. Considering how the standard gripe of people I hear in every single JoomlaDay I’ve been is the lack of comments and considering how easy it is to add a VERY basic commenting feature I say let’s just bloody do it! We’ve already been into the path of core-supported extensions which will be able to be installed either when you install Joomla! or afterwards, so lets just provide this basic feature and stop people from complaining. Simple.

  2. I’m almost off topic but I just have to say I love the dog in the picture ๐Ÿ™‚ Lot’s of wise words in your post too!

  3. My share of brain dumping on this one:

    Installer – I think what we have now is much more friendlier than the installer of versions past, but there’s definitely a lot of room for improvement. Those first two pages (the admin user and database connection) are pretty essential stuff, that third page is a killer though. Not to mention that it’s terrible at catching errors during the install routine, which has probably chased away more people than we might care to admit to. Luckily, the installer is one of the few things in Joomla that isn’t strictly bound to B/C rules (other than making documentation obsolete), so hopefully enhancing this one doesn’t take a couple of years to figure out.

    Site/admin – Conceptually, it makes sense. Execution wise, right now I think we’ve created our own problems with it. My gripes are more code than UX here I’d say though, but I do think FOF handles the split between the applications much better than core.

    Comments – It fell off the 1.6 roadmap for Hathor, and truthfully I think that was a mild blessing in disguise. With that said, if there’s really that big of a cry for a core supported commenting platform (maybe I’m oblivious to it but I don’t know of many screaming for it), maybe it can take a “core supported add-on” approach like Install from Web or Weblinks. WordPress has been doing the plugin first approach for a while, it can’t hurt us to try something similar if it’s something that truly interests users and developers (because someone’s gotta write the feature for the users to use it).

    Custom fields – Wasn’t UCM supposed to start building toward a somewhat native CCK type platform which could have supported this? The code stalled out and what exists is barely a usable shell of code. Or am I thinking about this wrong?

    Option Happy Interface – As long as we don’t start down a path of “enable this option to disable this option that enables options F-H and J” then we’re making progress. Sometimes I think our whole options system (and how they can get overridden at different levels) is far too complex for even advanced users, it has to be cleaned up and simplified massively.

    ACL Debugger – I’m on the fence as to whether a fully featured ACL debugger should be part of the core distro or whether it could be written as a standalone debugging script (either a fully separate app like Elin did with https://github.com/elinw/AssetDiagnosis/blob/master/assetdiagnostic.php or a beefed up ACL Manager extension). Not saying that it isn’t a useful tool, but I think we’re past the days of the default route being to cram everything into one package and should be looking at things that are immediately useful a majority of the time for the main package and support tools/extensions being prominently promoted and easily accessible to all users.

    1. Installer: full ACK.

      Site/admin: FOF2 was still way off the mark. My vision on closing the gap without screwing the developer is finally complete in FOF 3. Melding the two parts would solve both UX and code issues. The latter by removing the need for duplicate code doing the same stuff as the back-end.

      Comments: Sure, it can be an extension not packaged with Joomla! as long as we adequately inform newcomers of their existence and let them install them easily. Did someone say distros?

      Custom fields: Regarding UCM… wait for tomorrow’s post 3:->

      Options: binary toggle. Something like “n00b mode: Enabled/Disabled”. We can find a more marketable term than “n00b mode” of course.

      ACL Debugger: Separate app requires people knowing what they’re doing. People screwing up ACL by definition do NOT. Core supported extension sounds better. See my comment on comments (wow, so meta!) for my only objection.

      1. Somewhere in all your madness, I hope you’ve got an idea about what to do with the disconnected infrastructure known as joomla.org. Ideas like the decoupling of weblinks or core supported extensions aren’t bad, but when you have to hardcode a message into the CMS to point users where to find things, that’s just bad user experience.

        1. Oh, you’ve got to be ducking kidding me! Are you reading my notes? Restructuring the disheveled mess of derelict properties the Joomla.org Drive is comes right at the end of the series. That would be about the same time you’ll be flying to Europe. If my timing is just right you might be reading that post at 30,000 feet.

          As for core supported extensions (can I call them COSEs? sounds cool) we don’t have to use a com_postinstall message for each one. We could use the Install from Web infrastructure and simply add a tab which force loads a specific JED category. The post-install message could simply enable IfW and open that special tab. Problem solved.

          1. I see some of the comments on Twitter and the blog posts and wonder if people have been hacking into my notes for JAB ๐Ÿ˜€

          2. We could use the Install from Web infrastructure and simply add a tab which force loads a specific JED category.

            Wasn’t that part of the original concept

          3. I am aware of that. It was never executed. Of course IfW being broken for 6 months didn’t help things either…

  4. Agreed with every points. I hope you will write something on compononet/application development in your next post. So far great series mate ๐Ÿ™‚

  5. Another great post Nick!

    My 2 cents on some of the subjects:

    Installer – What I really like with a lot of similar products is an option to install additional extensions/addons. In Joomla’s case I can imagine a bunch of currently core extensions or functionalities like weblinks (I know it’s been removed from core in J3.4), user notes, messaging, etc being an option during installation process. Thinking from this perspective, you could also add commenting system as an optional install. Although I know there was a lot of debate about adding new extensions to the core.

    Custom fields – First big step in this direction could be API (or something) for developers to use (create, display, query, etc) Custom fields. Average user centered solution with admin GUI could be implemented subsequently. It would be great if Custom fields could be easily integrated with core Form fields. Michael mentioned UCM – could it be used as a basis for something like custom fields?

    Media Manager – one of Joomla’s weaknesses compared to similar products, I really hope to see new Media Manager GSOC project merged soon

    Multilingual – I talked to a lot of average users during multilingual site management instructions and every single one of them said, that it would be easier for them to create/edit multilingual content in one place/single window, so they don’t have to search/open new article for every content language installed. But it’s true that they were using not more than 3 or languages.

    1. Installer – Yes on allowing people to install core supported extensions easily. No on loading our overloaded web installer. Note: I am NOT talking about com_installer, I was talking about installation/index.php when you first install Joomla!. I suppose you mean a tab in the com_installer so yeah, agreed.

      Custom fields – UCM is about as suitable for the task as a ripe banana is for playing baseball. UCM should just be mothballed and put in a dark corner. Custom Fields can be easily implemented without going through UCM.

      Media Manager โ€“ย Yeah. I’ve heard about the rewrite of MM so many times that for me it’s like the Yeti. People claim to have seen it but there’s no hard evidence it even exists. I hope for the best.

      Multilingual – What they have in mind is translation, not multilingual. This is a different approach. There are solutions like Falang and others which do that. The main difference is that multilingual allows you to have entirely different content/structure per language while translation forces you to have exactly the same content and structure in all languages. Both are valid use cases. Translation can be a (suboptimal) subset of multilingual, that’s why multilingual was chosen for the core.

  6. hello i am not a dev but like CCK user.
    I think (for user vision), the most important think is :
    -add submenu drag and drop in menu manager and add a auto mode to construct menu easier (ex an option in article, like on joomla 1)
    -rebuild module assignation system, he is realy powerfull but not user friendly
    -update editor => i am agree its the most imortant thing for user … wordpress is realy good
    -update media manager => i think the new manager on road is good but we need a perfect integration with editor
    -a draft mode will be good if we mix with versionning

    But i think some other feature aren’t needed (we have apps for it)

    1. Hello Yannick!

      Drag’n’drop is already implemented in Menu Manager. There’s a good user experience reason why you can’t d’n’d from one submenu to the other. Ideally we could allow that if the user held, let’s say, CTRL while dragging but I’m not sure if that’s feasible with Javascript. I’m not a Javascript developer. I mean, yeah, I can write JS code but it’s not my area and I’m pretty sure my JS code is crappy as heck.

      Module assignment: I agree, it’s a pain to use. Any concrete suggestions? Something like NoNumber’s Advanced Module Manager perchance?

      Editor and Media Manager: yes, I agree. They have to be integrated. That’s what I said ๐Ÿ™‚ When you drag a media to the editor it should be auto added. Moreover the image button should open the media manager, not the basic TinyMCE dialog. Hint: in Joomla! 3 there’s such a button, UNDER the editor area. Yeah, I missed that too for a few months until I noticed its existence…

      Draft mode: That’s they idea behind staging. Content preview doesn’t work well unless you see the content on the actual page it will be displayed. That’s what a staging feature does.

      1. hello thanks for reply
        for menu => drag and drop for subemenu was necessary (like menu manager CK)

        for module => maybe in two step => drag and drop in position for all page and disable it with checkbox in menu and specific option of module

        for editor : it was a most important think, it realy the first interaction between user and CMS. Adding multimedia content need to be simple and out of box. I think inline editing will be an impressive adding. Editing article and custom module without reload page will be the most impressive feature for all personns how thinks joomla is too complicated.

        Draft mode : the hability to work on v2 of my article and lets publish v1 will be perfect !

        Thanks for your work and your vision

  7. Fully support the idea for the one page installer. Ridiculously simplified as default, but with an option for advanced users that will reveal all the hidden/unused fields of the former. We can easily use something like this http://tympanus.net/Development/FullscreenForm/ as a template (other colors, etc).
    This and some other features, can happen easily within version 3, so letโ€™s not postpone everything in this list for 4.0.

    1. Some (most) of the features I am proposing would break backwards compatibility or would require extensive code duplication under the current component paradigm. But yes, work on some features CAN start now, namely Media Manager, Comments (IF we want a core solution), WYSIWYG Editor. I personally find Media Manager and WYSIWYG Editor to be the most urgently needed features. Even better, any work made of them can be ported to Joomla! 4 very easily.

  8. Nic, thanks so much for putting these ideas out there. My JAB talk is going to focus exclusively on the topic of complete front-end content management (and how it’s already achievable by using the help of a CCK) for site admins. This is probably my number 1 selling point when selling a site to a customer. They love the idea of a really simplified interface that makes updating their content simple.

    I don’t know what I think about the custom fields idea. For me, there are some good and mature CCKs out there with so many useful features. I think adding custom fields will then give people a small taste of a CCK and lead to frustration that more functionality is not included in the core.

    Can’t wait to read the next one. Thank you.
    James (Twitter @_jrmo)

    1. The core can definitely not provide everything for everyone. If you think about it the content management is very basic. It does give a small taste of what a content management system can do for you and it’s perfectly fine for most simple to medium complexity uses. When you want to go into really complex, feature rich sites you do need specialised solutions… which is why Joomla! has 10,000 extensions.

      Giving custom fields in the core will allow the people who do not need the complexity of a CCK but do need a degree of content customisation to use Joomla!. Right now these people need to use a CCK (e.g. K2) which makes them perceive Joomla! as deficient and hard to use.

      I have an example in mind. A few years ago my friend who started using Joomla! when we were working together had to build a site listing concerts. Each concert required some fixed, searchable data such as date, time, venue, ticket price range, booking URL. He lost 3 weeks with K2 only to discover the custom fields were not searchable. Then another 2 weeks with JCal. I don’t know what he finally decided to use. The site was late to launch anyway and he was NOT a happy camper.

      I’m thinking just how many similar cases exist which only ever need a simple custom fields system, not a full blown CCK. The feature is easy to implement (been there, done that, twice) and while it’s not extremely powerful it covers a simple need without having to go the third party route.

  9. I agree to almost all suggestions. I belive that Joomla is a diamond that people is not aware of it.

  10. I agree to almost all of the suggestions. I believe that Joomla is a diamond that people is not aware of it.

  11. New administrator template please!

    I think one of the major problems in Joomla is the administrator template. I think that is needed a revamp of the administrator interface, with a cleaner design, with a more user friendly admin menu, as it can be difficult to newcomers to understand it. For example, the module manager nested inside “Extensions”, I think it should be included in “Content”, or a new “Site” group, article manager, menus and modules.

    I don’t like the use of “chosen” in every select, a customized version of Bootstrap 2, etc. I think that for Joomla 4 we should pick a new modern FW and stick to it trying to reduce to the minimum the custom front-end code needed in terms of CSS and JS.

    Also the structure of the administrator pages should be updated. The ordering of the elements in the page is not correct, for example, in articles view, it should be 1) subnav 2) filters 3) buttons 4) list. I think that the current anarchic structure of the elements and patches like the sidebar and search tools, not consistent between core extensions, really hurts Joomla more than anything else.

    Router problems: com_content is the guilty

    I think that any problems with the Joomla router are not caused by the current module-menu system. I think that the problem is the extreme complexity of core components like com_content and it’s modules. I think Joomla should stop adding more complexity to core extensions, and take a different approach.

    Would be much more easier to have a simpler components, instead of a behemoth like com_content and all it’s modules and plugins. For example com_articles, com_pages (article + menu item), com_blog, etc.

    It will be more user friendly and BAM! much router problems could be easily solved with different routers in every extension.

    This would also reduce the thousands of options needed to configure a view or an item in com_content. Also some extensions could be optional like com_weblinks, for example com_blog.

    Doing this is a no-brainer, the same table could be shared for all components, and with RAD and JLayouts the code needed could be minimal.

    1. Admin template menu: Yes, I think it should be customizable as long as there is an easy way to restore it to factory defaults. The latter is very important because it’s more than likely that people WILL end up removing more than they should and they WILL blame developers for that. I’ve been on the receiving end of unjustified accusations by people who’ve screwed up their sites’ ACL or were using a buggy version of a third party back-end template which hid the menu items to our components. It’s not fun trying to explain that you’re not an elephant.

      Admin template CSS framework: I see it holistically, not just on the back-end. We have to either invent our own CSS framework or have the balls to say that we’ll stick with the latest version of Bootstrap, at most 6 months after it’s released. I’m writing part 3 of this blog series where I touch that point.

      Admin template page structure: I agree to half of what you say. I would leave the top of the page (logo, main menu, component name, toolbar buttons) intact. I do agree that the rest of the filters makes no sense. I disagree with the way sidebar and the search tools are implemented. Either all filters should be hidden behind a panel (and listed at the same place) or we should just put them between header and list. I prefer the latter but I do understand its limitations and why it may not be the correct solution for Joomla!.

      Regarding routing: no, you’re way off the mark. What you think as separate core components are just different layouts. Following your approach would result in severe duplication of code, adding to the complexity (and number of inevitable bugs). In fact, com_content is a fairly simple component. We CAN and SHOULD trim down its code, not make 5 copies of it!

      The routing issues in Joomla! stem from the Itemid. Right now you have components (option) which have views and tasks. Adding a record ID gives you a page. But not so fast! You may have the same combination of option, view, task and ID in different menu items, i.e. different Itemid’s, leading to different SEF URLs. It gets even more complicated when you have drill-down content views. For example, consider the structure Category 1 (cat1) > Category 2 (cat2) > Article 1 (article1). The parentheses are the item aliases. And consider these menu items:
      * Menu 1 (menu1): Show all categories
      * Menu 2 (menu2): Show Category A
      * Menu 3 (menu3): Show Category B
      * Menu 4 (menu4): Show Article 1
      The URL to my one and only item can be:
      * http://www.example.com/menu1/cat1/cat2/article1
      * http://www.example.com/menu2/cat2/article1
      * http://www.example.com/menu3/article1
      * http://www.example.com/menu4
      Which one should I choose? I have no idea. Each menu item can be assigned different modules. If I choose any one of these 4 URLs I have a 75% chance of showing the WRONG modules than the ones the user expected. On top of that we also have languages for the “multi-language” sites which add yet another level of of routing.

      This problem is not specific to com_content or the core components. This is what 3PDs like me have to deal with. I have three front-end components (Ticket System, Release System, DocImport) and in all three the router is a mixture of voodoo, code I can’t quite explain and wishful thinking. It usually works IF AND ONLY IF you follow my instructions on the sequence and method of building menu items down to the letter. Try anything else and the whole house of cards falls apart.

      As long as our routing is tied to the Itemid we’re screwed. I think that we should be probably looking at how Drupal has separated routing from module-to-page assignment. The problem is that both solutions have their challenges. It’s the one thing that fixing it for some will break it for others…

  12. I thank you for your well written atticle and the good discussion points underneath.

    To add my thoughts I would like something a little different though some end results might be similar.

    The changes that are suggested are ones that iterate on now. They are changes for a half version jump and though some would require reachitecting and break backwards compatibility. I would suggest for a v4 you should have a theme or goal or audience to address and tie things too.

    The thought of simple nice clean UI and ticket boxes against WordPress is not a market I would aim for as though more downloads might come very little profit would. I use Joomla to build sites beyond WordPress. Professional built sites not simple to install for one person blogs. Though ease of use to me helps, I want it easy for the users in categories to be better.
    So at this larger scale I don’t mind the effort or cost to set it up, while keeping to a budget. I want the admin to have a different feel or template for the staff that come and use it next.
    So workflow of content, seeing content (more than one article) live before I make it live to customer. That Cck or more complex content types and layouts can be made by the user without having to learn little hacks.
    These things are possible now but could be smoother and not work in different ways or with little issues.

    Also to leap forward not just improve. To work with API and PHP components of other frameworks. To work in a stack with other languages. To look to where a CMS is next just a little with some innovation that pulls in new people.

    I want to impress the business managers to make them pay for the sites and the content and sales people using the site.

    If Joomla knows where it’s target market is pulling features along with a direction makes sense.

    1. I think that what you’re saying is exactly what I covered in the previous two posts in this series?

  13. Thanks Nicholas for these series of articles to make a better Joomla.

    In 2009 at an CMS event here in Brazil I asked to Anthony Ferrara why the functionality to make direct link to the menu in the articles was deleted (Joomla 1.0). It was a very productive shortcut for those who knew functionality. He said “We had forgotten to implement this in Joomla 1.5” and in the same day I sent a suggestion to return this functionality. The core team was not remembered and not implemented and we are already in version 3.5.

    And never i receive the follow-up about this.

    congratulations again for your message. a hug from Joomleiros in Brazil

    julianoaugusto.com

    1. I hear you! It sounds like an easy feature to add. I’ll try getting in touch with the PLT about it. I can’t promise immediate action (flying out to JaB15 on Thursday) but I’m adding this to my to-do list.

  14. Hi Nicholas ,

    thanks for sharing your visions. In most points I totally agree.

    Comments – Should be available only as extension, but not a native part of Joomla. I think it plays in the same league as Weblinks, Banners, Newsfeeds. Not necessary as a core feature.

    Native Content Construction – Hell yeah, this is needed! This is one of the missing features most other CMS already have. Joomla definitely needs something manage simple custom fields in article creation, something to give template creators/designers more possibilities for different page-types/layouts without the usage of a bulky 3rd party extension. Another advantage: Endusers doesn’t need to layout within one and only editorfield.

    ACL – Joomla needs something like Sander Potjers ACL Manager to have a better overview of the permisson hierarchy/tree. Your ACL Debugger vision is a good one. But the ACL itself has also to be finer granulated.
    Missing: Editing an item (article, menu, module, whatever) -> permissions -> now we are able to set access-levels and usergroup-permission. We are not able to include/exclude a single (or more) User. Everything has to be done over access levels and usergroups, just when you want to give one user a special permisson to work on one article. I like the JCE Profile Manager. You can assign a JCE profile to a usergroup as well as directly to a specific user.
    Missing: A better permission mangement for User Manager. At the moment it’s impossible to create “GroupAdmin” who only has permissions to create/edit/delete users within his specific group. Everyone who has got permissions to create/edit/delete users can do this for all other exisiting groups / is able to create users with more permissions than himself. This is still a big deficiency in Joomla.

    Just my additional thoughts ๐Ÿ™‚
    Cheers,
    Bjรถrn

    1. Comments Well, yeah, I mean that’s the already agreed upon plan: lean core with core-supported extensions. As I also said in the comments it doesn’t have to be a core solution as long as we agree to start promoting entire JED categories of often-requested functionality.

      Content Construction Yes, the custom fields will be good enough for most users who don’t want to use a full blown CCK. One point I forgot to make is that each category would now be able to define its own preferred layout. This allows different styling of different categories with different custom fields. If it sounds like deja vu, yes, it’s pretty much what K2 has been doing.

      ACL I disagree. If anything, the current ACL system has TOO MUCH complexity. Moreover, the per-user permissions in your scenario wouldn’t work. Explicit Deny trumps Explicit Allow.

      As for the user manager, no, you can’t escalate privileges (create a Super User if you don’t have that permissions yourself). It may be possible to create users assigned to non Super User groups with “higher” permissions, but this is subjective. You can’t explain to the computer what you mean with “higher” permissions without having to define the relation between every single ACL privilege and combination of parameters. To put it in perspective, a site with core + 2 custom user groups, two categories and ten articles would require several hundred manually defined relations. Not gonna happen. As with all access controlled systems exercise common sense.

  15. Great post, great ideas & great comments. I thought I’d add my 2 cents on the idea of comments: this might be related to the idea of an easier installer.

    What do I mean by this?

    What makes Joomla both great and insanely complicated at times is that it really tries to have the flexibility to be everything to everyone. In fact, I believe this is where Joomla truly shines. But with power and flexibility comes the fighter jet cockpit you mentioned before and many many unused plugins, components, modules, templates and other rubbish and code slowing things down.

    For example: for those who say we don’t need comments as a core component, how about banners as a core component? Just as useless to many users, no?

    So here’s a thought: As part of a simplified installer, maybe we ask the end user what kind of site they’re creating. If they choose “Blog” we add comments, if they say “Publisher” we add comments & banners, if they say “Brand” we remove both options, etc. This might even inform how we setup ACL, Advanced options and everything else, and of course all of these options can be enabled/disabled at any time. Maybe we even ask what their “Power Level” is (e.g. Power User, Intermediate, Beginner, etc).

    I know it might sound a little crazy, but I’ve personally always thought that Joomla needs a little help learning how to talk to humans, if you know what I mean.

    Sorry for the long comment, 2 cents spent.

    1. For example: for those who say we don’t need comments as a core component, how about banners as a core component? Just as useless to many users, no?

      Banners, along with a series of core components, are scheduled to have the same fate as com_weblinks: they will be removed from the core and made available through JED as core supported extensions.

      So here’s a thought: As part of a simplified installer, maybe we ask the end user what kind of site they’re creating.

      That’s part of what I had in mind with Workflow Management. Once you select a site profile the workflow you experience is best suited for this kind of site. It’s not too easy to accomplish but I think it’s plausible.

  16. There is no need to make job last simpler just to attract bloggers
    Joomla must be an easy Drupal solution

    and the editor even JCE are crap when you try to explain ton your customers to write a simple article

    1. JCE has profiles which can be activated globally, per user group or per component. You can create a new profile, customise the toolbar to make sense and enable it for your clients. How do you think I keep my sanity? I sure as heck don’t use the built-in Joomla! WYSIWYG editor or the full blown JCE with the impossible number of buttons. Learn to use your tools ๐Ÿ™‚

  17. I think the most important thing Joomla to have is a dedicated UI/UX team. WP has this, and they know how to make new users believe WP is modern, easy and fast.

  18. The years I dream in the day that the core of Joomla will implement the option of extra fields and I no longer need to be fighting with CCK’s …
    Another important thing is to unify frontend and backend … I already have an idea of how to do this in a simple way …

    I SAY ONE THING, while developers think like developers, the tools will never be just right for customers. He was thinking of the customers who came the most successful PRODUCTS!

    1. I fully agree. IMHO the developers are here to serve the users, not themselves.

      Regarding unifying the frontend and backend we’ve already discussed this. On the technical side it requires using a DI Container which allows us to perform a concurrent front-end and back-end login at the same time. George Willson is already working on this. On the user interface side of things I think the simplest way to implement it how WordPress does it: a top bar in the front-end integrating the back-end menu in the front-end. You see, even WordPress has discrete front-end and back-end parts, it just tricks you into thinking they are one.

      Regarding custom fields, they will probably be implemented as an extensible system. Joomla! will provide some basics and 3PDs can extend them. The idea we sketched out on Saturday is something which empowers both users and developers. CCKs should ideally be implemented on top of core content (think FlexiContent), not with ad-hoc tables. It all boils down to how much time and manpower we’ll have to get Joomla! 4 ready ๐Ÿ™‚

      1. Fantastic, I work many years with Joomla and always waited for the time of a shift in thinking about these things. We have come far, but we need more and I am very happy and hopeful to see that we are really starting.

        What Joomla team has to keep in mind is that for many developers, Joomla is not optional, it is years of dedication and we want to stop looking for the “worpress” as an option. It is working to have a community that has no doubt made a great choice!

        But, I think the fear of many, including me, is that the Joomla team! responsibly take decisions, because one thing that concerns me is having to start over when a new version of Joomla appears. The main change is without the community suffers major impacts. My only concern is this !!

        I’m looking forward!

        1. Joomla! 4 will be a major shift BUT this doesn’t mean that you will have to suffer the way you suffered going from 1.0 to 1.5 or 1.5 to 1.6+. The consensus was that a migration path will be provided on the day of the release, supported by the Joomla! development team and it will be a proper solution. This of course requires some stuff to be added to Joomla! 3, like minimum version support, but these are already known and being worked on.

          On top of that we had an informal discussion last weekend which touched subjects like a backwards compatibility layer for third party developers (3PDs) to easily port their code to Joomla! 4.

          In short: starting over is NOT an option. As long as all 3PDs do the right thing and plan their code’s transition to J! 4 the transition should be fairly smooth. Yes, you’ll have to upgrade your templates and your other extensions but that should be just about it.

          1. THIS is GOOD NEWS – [quote]this doesn’t mean that you will have to suffer the way you suffered going from 1.0 to 1.5 or 1.5 to 1.6+[/quote] – Hopefully as the move from 1.5 to newer versions plus the abandon of support of the most popular Joomla version to date (1.5) simply put this CMS to is knees. I donโ€™t think Joomla can afford a repeat.

  19. A lot of good points here – just one more quick drop from me, although if I sit down and think I might have more to say:

    As a power user I want to use my mouse the less possible. There are so many times I would wish to have keyboard shortcuts to navigate and perform actions in Joomla.

    Also many times I would wish if I could just navigate from article to article (or other item objects like menu items), while in editing mode, instead of have to save & close and wait for the list to open and select to open the next item. Something like the Save & New but for items I am already editing.
    This could go a step further, so the editing could be switching from a found set of items in the list – or there could be the possibility to call a “frame” of other items in the list (still while on editing page of an item) and clicking on them could save (or temp save) current item and open immediately that next item for edit.
    I guess these might sound too much or an extreme feature…

    1. Keyboard shortcuts: there used to be an extension for that by Twentronix (now he quit extension development for personal reasons). It was really cool but not as much used while managing your site as you’d think it is.

      Regarding the navigation, this feature has existed since at least 1995. You can open a new browser tab or window. I don’t see the reason of adding 5000+ lines of hard to test and maintain Javascript code when you can simply hit CTRL-T and get a new tab on your browser. Duh!

  20. Also think for the end user – some more built in template options or templates available to install from the web installer with a few easy to customize settings would help.

    Giving the option to the end/simple user to adjust the layout/look of a website should not require much effort and knowledge but only a few clicks.

    1. templates available to install from the web installer with a few easy to customize settings would help.

      The Joomla! Templates Directory is planned as far as I know.

      Giving the option to the end/simple user to adjust the layout/look of a website should not require much effort and knowledge but only a few clicks.

      I disagree not on principle but in practice. A template framework which allows the end user to customise everything is by definition bloated as hell and slower than creeping death. Look at major template providers who use this kind of ginormous frameworks and then look at templates like JooStrap. I shed 2s of page load time (out of 3s โ€“ 67% speed increase!) just by switching my business site’s template from a framework-based one to a JooStrap-based one.

      So, do you really want the user to have a nice, fully customisable template and at the same time perceive Joomla! to be this abysmal, slow as molasses CMS? In the end of the day people want a fast loading site (unless it’s a site they will ever visit once in their lifetime).

      1. I didn’t speak about adding any heavy template frameworks nor making a fully customizable template. – I also don’t like them for the same reasons you described.

        But templates can be really easy and light based on pure simple Joomla code. So why not giving a few more options to the new users? In order to make them feel more in control? Simple things, they could make them feel familiar with Joomla.

        Just saying…

      2. To not mention, that I have found many WP vs Joomla comparison posts saying about the Joomla templates and such – plus the fact that they say you have to pay in order to get a template for Joomla.

        Little simple additions changes, could change this myth.

  21. Heading 1

    <

    h1> for articles.

    Currently articles can display a heading 1 title only if assigned on a menu item and have the setting to display page heading. Otherwise the article title is displayed as heading 2.

    That extra work shouldn’t be required and generally it doesn’t help with SEO (another thing that Joomla is getting negative feedbacks compared to WP).

    Article Title should become a heading 2 only if indeed the article is assigned on Menu item and the menu item is set to display page heading, otherwise it should default to heading 1.

    To achieve this now, you need to create a template override. But how to explain this to a new user that is just trying to setup a site? And why at the end we need to do all this extra work?

    I know sounds like a minor thing – but sometimes a few small details can make a big difference…

  22. There are free templates for both Joomla! and WordPress alike. The common theme in both CMS is that free templates are low (visual) quality, badly coded and generally a bad idea. If you pay peanuts you get monkeys. There are exceptions, of course, e.g. JoomlaShine. The only MAJOR difference is that WordPress has a theme directory integrated into wp-admin whereas Joomla! still doesn’t have a Template Directory. As I said, this is something that’s going to happen. Even better, the directory will list both free and paid templates (like Joomla! Extensions Directory) making it easy for everyone to find anything they want. So really, we are saying the same thing after all.

    As for what a core template should do, let’s take a look at WordPress and I’ll prove to you that Joomla! already does the same and much more.

    All core WordPress themes from Twenty Ten onwards allow very minimal changes (through the Customize menu item), namely: colors and header image. That’s the beginning, middle and end of it. Lo and behold, Joomla! 3.0 (released in 2011) onwards already support this. Go to Extensions, Template Manager, Protostar and click on it. Colors? Check. Logo? Check. Wanna change the header image? Extensions, Module Manager, edit the Image Module, done.

    Granted, WordPress also has a background image option. According to every single designer I’ve talked to the background image option is really bad. I can understand why: it’s distracting and makes the site look too “busy”, therefore making it hard for visitors to focus on the content. I’ve seen several abominations of WordPress sites abusing this feature so I consider it a positive thing that we do not offer this possibility.

    The other WordPress customization options are:
    * Site title and tagline. In Joomla! this is in Global Configuration.
    * Widgets. We call them modules. They are more powerful but a bit harder to set up. There’s a balance there. I’m quite happy with our module system, it’s not too hard to use and very powerful. Can it be more powerful? Yes. Should it be easier to set up from the front-end? No, it would lose a hell of a lot of its power. Choices, choices…
    * Static frontpage. Eh, well, we have a much more potent menu system. You can simply change the Home menu item. I have seen 3PD templates having a similar feature but, frankly, it’s caused more problems than it solved. If you really want to construct a super powerful customised front-end create an article and put {loadposition} tags to create a stunning front-end assembled from custom templates. Beats the power of what WordPress can do by a couple orders of magnitude.
    * Featured content. Unsurprisingly it’s called Featured Articles in Joomla!.

    To sum it up, everything you say you need you already have in Joomla! 3 but nobody told you. Maybe you should take a good look at what Joomla! 3 already offers out of the box? ๐Ÿ™‚

  23. As for h1, h2 etc the way Joomla! 3 produces its output is actually better for SEO than slapping h1 on every single article title out there. There’s a lot of work also going into microdata which is even more important.

    Finally, one thing that I’ve found is that the h1 etc are not as important as you might think for SEO. They’re in the same category as SEF URLs: nice to have, but really unimportant for SEO. The major factor for getting a good ranking is having good, fresh content with organic traffic and links. In other words, create a site which people want to read and make sure its content doesn’t get stale. Everything else tries to work around this basic deficiency and yields varying results, usually faring pretty bad.

  24. Part-way down, you mention [b]Workflows[/b], IMO the highest priority suggestion. [b]Workflows[/b] actually drive your other ideas, allowing the site worker(s) to display which features get pushed to the top when they’re logged in, working on the site.
    [b]For example: [i]Content mode, developer mode, site admin mode, troubleshooting mode, testing mode, marketing mode,[/i] etc. Each mode is an admin-toggled workflow, bringing up the relevant mode that’s focused on helping the site worker accomplish her/his task easier and faster.[/b]
    I’m a sitebuilder who writes, designs, front-end develops, markets and troubleshoots, so I’d switch between modes, depending upon what I was attempting to get done. Depending upon assigned Access Controls, site workers with specific roles could be limited to certain modes, so they don’t end up wandering off the reservation. ๐Ÿ˜‰

    Workflows would be a key way to make Joomla very different and better than other Big 3 CMSs, and most (but not all) proprietary ECMs too.

    PS: [i]This all assumes accessibility is tackled first. Accessibility must be done.[/i]

    1. [i](realizing I’m replying to my own comment here). I should clarify a bit, I re-read my comment, and noticed I got ahead of myself with articulating [i]workflows[/i], as if [i]work modes[/i] are one in the same. They’re not. The workflow could help simplify, automate and speed up processes in each respective work mode one chooses. [/i]

  25. Nick your a genius! If only I could pronounce your last name I would shout it from the roof tops. I mean that. Thank you for all of your work and contributions. Hey here is a novel Idea. How about the ability to filter modules by what menu item/page they are assigned to. Do you know how many seconds add up to hours of me scanning through looking for and trying to better organize modules. I know there are extensions that use color codes etc. But really how hard can it be. Just another drop down filter with the list of menu items…No?
    Thanks

    1. Hello, Rob and thank you for your kind words! I’ll tell you a Joomla! hidden secret: what you are looking for already exists since Joomla! 3.3 (maybe 3.2, I’m not sure). Go to the Menus menu item, click the item of your menu, click the menu item (page) and then click on the Module Assignment tab which is the last tab on the right. By default it shows all modules published on that page [i]and[/i] the modules without assignment. Under “Unassigned Modules” click on Hide to only show the actual modules currently assigned to the menu item.

      Since a module can be shown or hidden based on menu item, all items or no item that’s the only reasonable way to organize your modules. Color coding would end up using ten times the colors of the rainbow on most sites and would frankly look a bit ridiculous ๐Ÿ™‚

      Also, if you want to quickly edit a module: just log into the front-end of your site as a Super User. Hover over the module and you’ll see an edit button appear โ€“ as long as your template is updated the last couple of years. Clicking on that button will allow you to edit the module and return back to the same page after saving to see what your changes look like.

      I’ve found myself using these two features quite a lot. They are very convenient!

    1. Don’t ask me. What was decided to be implemented in the two meetings in Odense and Athens has NOTHING to do with my blog posts and the discussion we had in J and Beyond 2015, therefore I quit the Joomla! 4 Working Group. In my opinion, the Joomla! 4 development effort is going towards an entirely wrong direction. If you want information about Joomla! 4 please contact Marco Dings of the Joomla! Production Leadership Team.

      1. Iโ€™m really sad and really worry that you decide to retire from Joomla 4 working group. I follow you, now for a long time, by your Akeeba extensions that add great value to Joomla itself and I also see your involvement in the Joomla project and always find your voice to be one of wisdom. This move make me doubt that you are right and Joomla is actually moving in the wrong direction. Iโ€™m long time aficionado of Joomla and building web sites only with this platform. I saw in Joomla history some very bad decisions that almost kill the platform, like at the 1.5-2.5 passage (I will not discuss on that here) that bring Joomla to his knew and shy away the exact people, like me, that are the most important to the platform, the people that believe and distribute Joomla. A few other mistake like that and Joomla will simply not recover and join the betamax of this world. Nicholas, as I value your opinion greatly, will it be possible to see a simplified overview of the main reasons that make you take this decision?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.