Written by: 
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
This and some other features, can happen easily within version 3, so let’s not postpone everything in this list for 4.0.
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)
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.
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.
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...
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.
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
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
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.
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.
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