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

Published by Nicholas Dionysopoulos

PHP developer, author of Akeeba Backup and Admin Tools. Father, husband, cat herder and geek. Proudly uses all major Operating Systems on desktop and mobile.

62 replies on “Joomla! 4 and Beyond: A vision for the end user”

  1. 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…

  2. 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? šŸ™‚

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

  4. 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]

  5. 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?

Comments are closed.