The NewUserTemplate currently has 18 MAKETEXT. This can be discouraging for new users and gives a geekish impression, something I would like to avoid if we want to move TWiki into the mainstream. It is all about a smooth user experience for new users.

Simply removing MAKETEXT is not a solution since users - say in China - do not see the help text in their language.

A simple solution is to remove the help text but ask the TWiki administrator to translate NewUserTemplate into their language. This does not address the needs of a multi-lingual community, but for those communities, what is less confusing, a home page littered with MAKETEXT or helptext in the common language of the community?

Hmm, there is no "Urgent Enhancement", so set to "Urgent" for now.

-- PTh

Good point.

IMHO the TWiki web should be read only. The Main.WebPreferences thing was a great idea, and I thi maybe everything that could be customized by admins should go on the Main web. Maybe a long term solution for this issue?

Another aspect: personal roadmap includes figuring implementing full topic translations (in contrast with user interface elements) for EdinburghRelease. Maybe we could think in a way it could be used for this kind of stuff, e.g., TWiki would pick a suitable NewUserTemplate based on the user's language. I don't know, dropped a note on TWiki:Codev/TranslationSupport .

AT

Added a comment to the topic to explain the MAKETEXT for new users.

SVN 8311

CC

SVN 8319 solves the geek factor and scare tactics factor:

• Added English text in NewUserTemplate and a note for administrator to customize template topic
• Added line in TWikiInstallationGuide to customize NewUserTemplate

-- PTh

If the admin chooses to do nothing, the created user topics looks broken now - on purpose?

As seen on Main.NewUserTemplateTest there are parts like

• write: ---++ My Own Setup -->
• }%

Else I like the way of fixing this; we are getting close to a (second :-)) string freeze now.

-- SP

IMHO making the admin the change topics in the TWiki web is an invitation to lost data on upgrades, but ...

AT

My last comment is unclear, I think what happens is that the %NOP{" terminates at first "}, which belongs to a %MAKETEXT%.

Still needs to be escaped / rearranged / %OUTCLUDE'd in some way.

-- SP

I created new Item1422: NOP{} cannot contain variables with parameters.

For Dakar release, either that bug needs to be fixed or a workaround done for the issue described here.

-- PTh

I found that users typically get confused by any default text in their home page if it is not directly understandable. Maybe its just my users but they don't get the idea of settings in free text.

Presumably there is no way to provide the explanations to the left-side or right-side of the the edit window whilst editing? i.e.

<-   Edit pane             -------> <-Read-only text, shows like the explanations during form editing->
------------------------------- 
|* Set BLAHBLAH = User's value |   To the left are a some settings that control how you want 
                              | TWiki to behave. Options are defined one per line, start with 
|* Set FUBAR = User's FU value  | * Set OPTIONNAME = value
                              | Commonly defined settings are: BLAHBLAH FUBAR and GROK.
                              | BLAHBLAH controls ... ; it should be set to 1, 2, or 3.
| * Set GROK = User's GROK      | FUBAR controls ...; most people leave this unset - see SomeTopic
                              | GROK controls ...
                              |
                              | This is part of a more powerful system ...
                              | A fuller, more technical explanation is available on AnotherTopic

Alternatively, is the TWiki:Plugins.PreferencesPlugin trouble-free enough that it can be installed alongside by default into the Main web? I'm guessing no as it pushes preferences into the form - and I'm assuming that make it incompatible with the topic already having a form?

Prefs plugin could be very useful for end users - the wikiwebmaster can reasonably be assumed to be technical but users should be assumed to not be.

MC

MC, on the TWiki:Plugins.PreferencesPlugin idea, an issue is that the settings need to be "already there" to use that functionality - and as we'd like to the settings disabled until willful enabling in this case, that won't do any good here (of course, the plugin could be expanded with en-/disable functionality, but ..).

-- SP

Registered Main.DeleteMeItem1395Test user, everything looks great - except topic is locked down to TWikiGuest. Reported as Item1426.

-- SP

Re: settings needing to be "already there" - I'd have thought that it was a case of just bringing in the right preference hash keys.

-- MC

It is - but if they are there explicitly, they override global preference set in TWikiPreferences, making global defaults meaningless. See Item1364.

-- SP

Ok, this is also affected by Item1800 following conv today on irc.

-- MC