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