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 thoughts on “Joomla! 4 and Beyond: A vision for the end user”

  1. Thursday, 21 May 2015 21:37
    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. Thursday, 21 May 2015 21:49
      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. Friday, 22 May 2015 10:29
        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. Friday, 22 May 2015 11:32
          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) :D
    2. Monday, 08 June 2015 16:38
      Comments are for blogs. Joomla is a CMS. Adding comments to Joomla is like putting feathers on a fish.
      1. Monday, 08 June 2015 23:52
        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</em> 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 <em>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. Thursday, 21 May 2015 21:58
    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. Thursday, 21 May 2015 22:10
    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. Friday, 22 May 2015 00:24
      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. Friday, 22 May 2015 00:31
        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. Friday, 22 May 2015 00:52
          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. Friday, 22 May 2015 00:54
            I see some of the comments on Twitter and the blog posts and wonder if people have been hacking into my notes for JAB :-D
          2. Friday, 22 May 2015 00:54
            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
            1. Friday, 22 May 2015 00:55
              I am aware of that. It was never executed. Of course IfW being broken for 6 months didn't help things either...
  4. Thursday, 21 May 2015 22:18
    Agreed with every points. I hope you will write something on compononet/application development in your next post. So far great series mate :)
  5. Friday, 22 May 2015 00:18
    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. Friday, 22 May 2015 00:31
      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. Friday, 22 May 2015 11:38
    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 =&gt; i am agree its the most imortant thing for user ... wordpress is realy good
    -update media manager =&gt; 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. Friday, 22 May 2015 11:44
      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. Tuesday, 26 May 2015 14:46
        hello thanks for reply
        for menu =&gt; drag and drop for subemenu was necessary (like menu manager CK)

        for module =&gt; maybe in two step =&gt; 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