David Scotson

Hi James,

You asked:

Registering under pseudonyms is one method I have considered (and noted in other posts). But won't it have the same problem Timothy Takemoto noted in his 27Apr05 post?

Given the following quote from the Moodle Admin Configuration screen (underneath the NoReply email box) then if the email is visible in forum emails after setting it to be hidden in the user profile then there's a bug somewhere (or possibly just an unwanted interaction with Timothy's modifications).

Emails are sometimes sent out on behalf of a user (eg forum posts). The email address you specify here will be used as the "From" address in those cases when the recipients should not be able to reply directly to the user (eg when a user chooses to keep their address private).

I will test this and report back.

edit: our own 1.5 test Moodle does this correctly, and I've just hidden my email in my Moodle.org profile so if you are reading this as an email you should be able to see my name, but not my email address, if I changed my name to something anonymous then a fair degree of anonymity (at least between participants) seems achievable.

You could probably fake this by adding the number of the book before the name. It would probably get ugly though as you'd need to use leading zero's to ensure correct sort order in the chapter and verse numbers too.

It's probably a general feature request, after all if you're using the Glossary to hold people's names you'd want all the Smiths together rather than sort on the first letter of their first name. If you are sorting book, album or film titles you probably want to ignore 'The' (and possibly 'A') to make things easier to find. So perhaps there should be an optional sort order field for Glossary entries?

The maker of your tools has the means to facilitate things, or make them harder. It all depends on having the right incentives and intentions. You are probably familiar with the vendor lock-in that you fear.

There's a nice economic analysis of vendor lock-in by Bryan Cantrill of Sun Microsystems.

Joel Spolky's Camels and Rubber Duckies is also a readable romp through the economics of software pricing. It starts off desktop app focused but it gets onto institutional purchases of Moodle type software later on e.g.:

The joke of it is, big companies protect themselves so well against the risk of buying something expensive that they actually drive up the cost of the expensive stuff, from $1000 to $75000, which mostly goes towards the cost of jumping all the hurdles that they set up to insure that no purchase can possibly go wrong.

and the potential pitfalls of selling Free Software:

There are just too many examples where you actually do get what you pay for, and the uninformed consumer is generally going to infer that the more expensive product is better. Buying a coffee maker? Want a really good coffee maker? You have two choices. Find the right issue of Consumer Reports in the library, or go to Williams-Sonoma and get the most expensive coffee maker they have there.

Hi Urs,

the section you quote from my previous post was the least strong of my objections. It really applies mostly to online shops (or newspapers and similar resources) where a customer may be hunting for a specific item, or browsing for something that catches their eye The collapsable hierarchical menus hide a lot of information, and according to the usability studies in the linked articles can be quite harmful when looking for things. Moodle content is usually a bit more focussed.

My main issue with submenus (single drop down menus are much less of a problem) is that they a) require precise mouse control, and b) act crucially differently from the menus in Windows and Mac OS that they are imitating without being different enough for a casual user to work out what's going on.

In your example try selecting Direkt zu... -> Gruppenraum -> Chatraum or Direkt zu... -> Themenraum -> Chatraum Thema. Every time I do it I fail because the menu has closed or changed by the time my mouse gets to the place where my desired link was. (If it works for you try it again with your mouse in your left hand). To correctly select those targets you have to move horizontally to the right while staying within a 20 pixel vertical distance until you are over the submenu and then move vertically down towards your chosen target. This L-shaped movement is different from the straight line diagonal that works on most operating systems.

I'm not sure if it's impossible, but I've never seen a web-based menu that works the same way that native menus do. I'm fairly certain that it would need javascript (i.e. a lot more javascript than is used in the mainly CSS-based Suckerfish menus that you are using) so any visual browser with javascript turned off would need an entirely different menu as well to be considered accessible. It might be a better idea to get that menu system sorted first and then work on the advanced version.

About the menu not disappearing completely: this is almost certainly a problem with the browser that needs to be worked around. Most fancy tricks that involve things appearing and disappearing need to be tweaked for every browser you wish to target, with Safari on the Mac often being one of the last to be catered for.

I think the hierarchical sub-menus are a bad idea for reasons outlined in a post somewhere above. From a technical point of view, the menu currently leaves its right border visible after it disappears (for me on Safari at least).

I generally think that when you imitate an existing UI element (like menus) then it's better to be obviously different as being subtly and unpredictably different from an established interface metaphor is more disturbing than something completely alien to the user (this is similar to the Uncanny Valley effect where humanoid robots are acceptable up until they become too similar to humans when the small differences begin to creep you out).