Joomlatools

Although this sounds great from a user’s point of view, where/when would these checks take place? Should they be done for each and every request? In that case, wouldn’t performance become an issue? Should they be done only for some requests, caching the results of the check in between? Theoretically, these circumstances would be stable enough to do the checks upon installation, and never look back, but what happens if the installation is moved to a different environment?

The advantage of a setting is, a user can go and check it, and decide if it needs changing or not. At runtime, it’s just there, telling the software what to do, without it having to go and find out.

An important part of my experience of “software that knows best” is with Microsoft Office products that often get it almost right, but not quite, and leave me frustrated because it won’t do what *I* want it to.

Having sensible default values, maybe even figure out those values (at install time) on the fly from environment characteristics, great. Hiding them from view in some “Advanced settings panel”? Wonderful. Getting rid of them entirely and having the software handle them completely? Not convinced…

Hi Eelke,

You make a few very valid points. It doesn’t make sense to make these checks for every request indeed I don’t think this is what Mathias is suggesting, at least not in the way I read his post.

Mathias is also not suggesting to remove the settings just change the wording and their use to make it more clear to the user.

I agree that you will still need some settings to be able to configure the SEF behavior. I think Mathias his main message is that it It would make more sense too to turn SEF and the URL suffix on by default, since this is an action you need to do anyway when setting up a Joomla! 1.5 site.

The second question Mathias asks is if Joomla can determine if it can rely on url rewriting without index.php or not. For that it needs to know if the htaccess file with the rewrite rules is available or not. The check for this could happen when you are changing the configuration settings or when you install Joomla!.

Like you, I’m also not a 100% convinced that you need to jump through all these extra hoops to automate a simple setting which is only accessible by super administrators in the first place. The risk for issues and bugs with the failsafes in this is case is probably higher then the benefits.

I do though agree with the fact that extension developer should try to limit the amount of settings to a bare minimum and think very well about what they make the user think about and why. Better to make him to less then more.

Hi Eelke,

You make a few very valid points. It doesn’t make sense to make these checks for every request indeed I don’t think this is what Mathias is suggesting, at least not in the way I read his post.

Mathias is also not suggesting to remove the settings just change the wording and their use to make it more clear to the user.

I agree that you will still need some settings to be able to configure the SEF behavior. I think Mathias his main message is that it It would make more sense too to turn SEF and the URL suffix on by default, since this is an action you need to do anyway when setting up a Joomla! 1.5 site.

The second question Mathias asks is if Joomla can determine if it can rely on url rewriting without index.php or not. For that it needs to know if the htaccess file with the rewrite rules is available or not. The check for this could happen when you are changing the configuration settings or when you install Joomla!.

Like you, I’m also not a 100% convinced that you need to jump through all these extra hoops to automate a simple setting which is only accessible by super administrators in the first place. The risk for issues and bugs with the failsafes in this is case is probably higher then the benefits.

I do though agree with the fact that extension developer should try to limit the amount of settings to a bare minimum and think very well about what they make the user think about and why. Better to make him to less then more.

Hi,
Perhaps I didn’t make myself clear. The goal was not to present a ready made solution, but to illustrate how the process of simplifying Joomla could work. As I wrote:

>> This automatic handling of htaccess might be a bit too risky, (…). Further testing and brainstorming is required. (…) By keeping an open mind and coming up with creative ways, I’m sure it’s possible to remove half the options in Joomla, (…) So what do you think? Which options or buttons would you drop from J!1.6?

All of this is meant as an invitation for the developer community to think more actively about their UI’s, about avoiding _developer_ concepts to slip in to _user_ interfaces.

>> “software that knows best”

The truth is, the developer knows best. The developer can’t go to each user’s site and pick option A or B. So the developer writes documentation. The user doesn’t read it, and bugs the developer for support/complaints/… instead.

The M$ way:
Set to option B for everyone.

My suggestion:
The developer knows when to pick option A or option B. The developer models this decision-making process into code logic. The code now knows whether to pick A or B. There’s still a decision-making process, but it’s automated.

Hi,
Perhaps I didn’t make myself clear. The goal was not to present a ready made solution, but to illustrate how the process of simplifying Joomla could work. As I wrote:

>> This automatic handling of htaccess might be a bit too risky, (…). Further testing and brainstorming is required. (…) By keeping an open mind and coming up with creative ways, I’m sure it’s possible to remove half the options in Joomla, (…) So what do you think? Which options or buttons would you drop from J!1.6?

All of this is meant as an invitation for the developer community to think more actively about their UI’s, about avoiding _developer_ concepts to slip in to _user_ interfaces.

>> “software that knows best”

The truth is, the developer knows best. The developer can’t go to each user’s site and pick option A or B. So the developer writes documentation. The user doesn’t read it, and bugs the developer for support/complaints/… instead.

The M$ way:
Set to option B for everyone.

My suggestion:
The developer knows when to pick option A or option B. The developer models this decision-making process into code logic. The code now knows whether to pick A or B. There’s still a decision-making process, but it’s automated.

Nice input! Alot of times it is better to use convention over configuration. J 1.6 is an excellent opportunity to clean things up a bit!

I posted a “complaint” about the aboundance of config options in JCE on the JCE forums, but I can’t find the link now (site is down). Anyways.. It has default settings, plugin settings, default group settings, group settings… it takes a while to figure out which setting is the valid and working one. JCE is great, don’t get me wrong, but there is room for improvements.

An option I would like to add to J1.6: I wish the core files could be moved outside the web root.

Sensible defaults and moving many “options” to some sort of “hidden” panel is definitely the way forward. (To be fair Joomla 1.5 definitely made a great start at this. Just look at content parameters.)

Simple and understandable terminology is still the biggest problem facing most users. The requirement to be Search Engine Friendly is completely irrelevant for the majority of sites that I am involved with as they are corporate intranets. However what they want is for the urls to be HEF (Human Ear Friendly).

Many of us understand that when Joomla says SEF urls it also means HEF urls or perhaps Pretty urls but definitely not the majority of users.

For me the days of the long, unpronouncable url are over, lets have HEF/Pretty urls on by default (subject to a simple test) and leave the advanced Search Engine tweaks and customisations to 3pd SEF tools.

Sensible defaults and moving many “options” to some sort of “hidden” panel is definitely the way forward. (To be fair Joomla 1.5 definitely made a great start at this. Just look at content parameters.)

Simple and understandable terminology is still the biggest problem facing most users. The requirement to be Search Engine Friendly is completely irrelevant for the majority of sites that I am involved with as they are corporate intranets. However what they want is for the urls to be HEF (Human Ear Friendly).

Many of us understand that when Joomla says SEF urls it also means HEF urls or perhaps Pretty urls but definitely not the majority of users.

For me the days of the long, unpronouncable url are over, lets have HEF/Pretty urls on by default (subject to a simple test) and leave the advanced Search Engine tweaks and customisations to 3pd SEF tools.

I think Brians on the money in regards to terminology.

Every cms uses same terminology for differnt effect, Modules for example exist in many CMS’s but are to varingly different degrees different from one to the next.. The result being the punters have no idea what they are looking for.

Yeah – sometimes I wish we still had mambots and not plugins. At least with mambots no-one knew what they were and they would find out. with plugins there can be an assumption that they are the same as a plugin in another app when they are very different.

Hello Mathias,

great article! You are one of less programmer that think about usability and the normal user.
This is the right way a software has to go.

Keep it simple!!! (thats also our motto)

I think the first 2 option should definitely be re-written to be more clear. Even perhaps include a javascript demo of what a URL will look like underneath. Have it changed based on URL rewriting ON/OFF.

As for adding logic to determine if index.php is necessary – that could be done when the SEF urls are toggled ON/OFF.

I disagree with your recommendations with 1 and 2:

1) While not opposed to defaulting on, I don’t think the option should be altogether removed. There are still extensions that don’t always play nice with SEF, and I would want the option of turning it off. Further, there are 3rd party SEF extensions that may require native SEF off in order to function properly.

2) The addition of the suffix is a preference issue, with no dominant direction. Personally, I never turn the suffix on, because I prefer very simple SEF links: http://www.mysite.com/blog — rather than tack on a suffix.

3) This is the stumbling block for most non-techy/beginner users. I’d love to see a way to automate the process, but am not sure it would be wise to default it turned on. For example, what if the option was presented as a button to turn htaccess on/of, and triggering the button changed the file name, ran an HTTP request, and yielded a success/failure message.

>> There are still extensions that don’t always play nice with SEF,

The fewer settings, the fewer possible configuration developers have to provide for. If sef is always on, all components will be tested against that configuration only.

Let me put it this way: if the option would never have been there to turn it on or off, but instead it was always on, no one would miss it to begin with.