Any way to have different placeholder text for password in signIn and signUp fields? about core HOT 10 CLOSED

This is not possible at the moment.
Implementing it would require to change the way fields are configured, allowing to have objects for the placeholder option (instead of a simple string) with 'states' as keys.

Actually this wouldn't be difficult to implement. I'd just like to make sure it will be a useful feature for many.
...at this point, what about doing the same for othet options too?
Would it make sense to have different labels?

from core.

My preference would be to have total control over all of the displayNames and placeholder text for all the fields that can be shown, in all the various forms (signIn, signUp, etc.). One example where I'd like this is the following.

When I add the fields for name, email and password, I am able to set the displayName and placeholder text for each of these at configuration time. For the password field, they are used for signIn and signUp forms.

However, if I have both username and email defined, the displayName and placeholder text for these is used on the signUp form, but when they are collapsed together in the signIn form, the displayName for the 'username' field is 'Username or email' as is the placeholder text.

I am not fond of having the word 'user' in my app interface and would prefer to use 'name.' So, I would rather it read as 'Name or email.' But I am unable to configure the displayName and placeholder text for the combined name/email field (at least as far as I can tell).

Also, the link text on the signIn form and the button text on the signUp field is 'Register.' I would rather be able to control that text too. That goes for ALL the text on the forms, e.g. 'Don't have an account?' I think what you have as defaults would work for a lot of people, but I'd also suspect that there are others who want that level of detailed control of the language used in their designs.

Food for thought...I hope it made sense.

from core.

The bad news is that once you set up a displayName or a placeholder value for a field, these are used for that field in every form it appears in.
Which means that if you do

AccountsTemplates.removeField('password');
AccountsTemplates.addField({
    _id: 'password',
    type: 'password',
    required: true,
    displayName: "Secret",
    placeholder: "at least six characters",
    minLength: 6,
    errStr: "I told you I want at least six characters!",
});

The label above the password input will be "Secret" both for the sign in and sign up form, as well as for the placeholder which will be "at least six characters".

To let the possibility to have different labels and placeholders I should change the way a field's options can be specified (keeping it compatible with the current one, so the above should still work!).
On way could be something like this:

AccountsTemplates.removeField('password');
AccountsTemplates.addField({
    _id: 'password',
    type: 'password',
    required: true,
    displayName: "Secret",
    placeholder: {
        default: "password",
        signUp: "at least six character",
    },
    minLength: 6,
    errStr: "I told you I want at least six characters!",
});

AccountsTemplates.removeField('email');
AccountsTemplates.addField({
    _id: 'email',
    type: 'email',
    required: true,
    displayName: {
        default: "email",
        signUp: "Principal Email",
    },
    placeholder: {
        default: "email",
        signUp: "your email address ",
        forgotPwd: "email used for registration",
    },
});

Which might become a little too verbose, but at the same time will allow what you're asking.
And I agree this will increase the control you have about form customization.

At this point we could also have something like this:

AccountsTemplates.configureTitle({
    signIn: "Entrance",
    signUp: "Registration",
    forgotPwd: "We''l solve it, just tell me your Email...",
    ...
});

AccountsTemplates.configureSubmitButton({
    signIn: "Get in!",
    signUp: "Please Accept me!",
    forgotPwd: "Let me back in again, I promise I wont forget it again!",
    ...
});

...and since the aim of AccountsTemplates is provide the possibility to customize the UI as much as possible, I think this could be a good direction where to head to! ;-)
This topic could also be of interest for the more general discussion we had on #34...

The only thing to understand about the above (and actually about the current status about using provided texts), it the following.
All values passed to configuration options are supposed to be valid keys for the T9n object provided by the accounts-t9n package (you can see the currently available keys here). This allows to get instantaneous 18n capabilities, since each key look up is done inside the map for the current set language.
So, for example, "error.accounts.User not found" will be "User not found" if you set the language to 'en' while will be "Utente non trovato" if you set it to 'it'.
The same applies for button texts and links:
"usernameOrEmail" -> "Username or email" or "Nome utente o email"
"signUp" -> "Register" or "Registrati"

In case you provide a key which is not found inside accounts-t9n it will be displayed unchanged, but won't be translated in any way.
...unless you provide a mapping for it (see here):

T9n.map('en', {
    letMeIn: "Let me in!",
    signUp: "Sign Up",
    info: {
        passwordChanged: "Password Successfully Changed!"
    }
});

T9n.map('it', {
    letMeIn: "Lasciami Entrare!",
    info: {
        passwordChanged: "Password Cambiata con Successo!"
    }
});

The above does two different things at the same time:

1. provides a new key (letMeIn) which will be displayed as "Let me in!" or "Lasciami Entrare" if you set the language to 'en' or 'it', while it will be displayed as "letMeIn" for every other language...
2. overwrites the value for the key signUp for the 'en' language, and the values for info.passwordChanged for 'en' and 'it'.

This, at the moment, is the way to go to rename more or less whatever you see on the AccountsTemplates forms.
The only drawback is that if you are interested in more than one language, you'll have to provide the translations for all of them on your own. But in the end might be something affordable...

This said, supposing you need only English the following will redefine most of what you where talking about:

AccountsTemplates.addField({
    _id: "username",
    type: "text",
    displayName: "Name",
    placeholder. "name",
    required: true,
    minLength: 5,
});

AccountsTemplates.removeField('email');
AccountsTemplates.addField({
    _id: 'email',
    type: 'email',
    required: true,
    displayName: "Email Address",
    placeholder: "[email protected]"
    re: /.+@(.+){2,}\.(.+){2,}/,
    errStr: 'Invalid email',
});

AccountsTemplates.addField({
    _id: 'username_and_email',
    type: 'text',
    displayName: 'Name or Email',
    placeholder: "name or email",
});

AccountsTemplates.removeField('password');
AccountsTemplates.addField({
    _id: 'password',
    type: 'password',
    displayName: "Password",
    placeholder: "at least six characters",
    required: true,
    minLength: 6,
    errStr: "I said, at least six characters!",
});

T9n.map('en', {
    signUp: "Sign Up",
    dontHaveAnAccount: "You can always"
});

I'll try to put the above examples also inside the documentation...

Thoughts? Impressions?

from core.

Wow! What a reply! Thank you so much for such thoughtful consideration. I understand the constraints resulting from the accounts-t9n package. I think that what you described as an approach makes a lot of sense. Having said that, I can use the package as it currently exists without needing this. As I consider where I need to put my energy, I need to go forward and integrate what I've now learned about accounts-templates and make it work for me so that I can move on to other items that are needed prior to launching my site.

While the approach you describe is a bit verbose, I don't find it overwhelming. And it is just configuration that happens once.

I think that as Meteor matures and becomes more widely used, designers are going to want to be able to specify the microcopy that is presented in the user's login flow. It's such an important part of the onboarding process for users/customers and some designers obsess over details like these. Disclaimer: I am not a designer. I've just been reading a lot and that's my impression. It has made me pay more close attention to these details.

I was having some trouble yesterday when I was adding using addField to add the username_and_email field. For some reason, the app was crashing. But as you note in the documentation, if name and email are present, the username_and_email is automatically added. So I just removed it to prevent the crashing. I've just re-added it, using what you show above and it worked fine. However, I noticed that when I specify the displayName: "Name or Email" and placeholder: "name or email" the sign IN form shows the label as "Name or Email (Optional)"

Where did the (Optional) come from? The field is a required field, but the user has the option of entering either his/her name or email that they used during signup. I think that the (Optional) confuses things.

from core.

Here you go!

from core.

...noticed the (Optional) problem only now.

I've just tried it out and:

AccountsTemplates.addField({
    _id: "username_and_email",
    type: "text",
    displayName: "Name or Email",
    placeholder: "name or email",
    required: true,
});

works fine for me.
Optional is displayed only if I set optional to false or if I let it undefined...

...have you actually put required: true?
I know it's a required field but I still haven't put artificial intelligence into AccountsTemplates ;-)

P.S. hope you can find the time to test the brand new features about the above discussed customization! :-)

from core.

My error. I did not have required: true. Once I did that, the Optional disappeared.

I am very excited about the new features. You are a magician! I will be updating and testing them later this evening.

Mille Grazie!

from core.

I see that you updated the version to 0.0.24. Do you have to publish the new version to Meteor before I can see it? I ran meteor update packages, but Meteor still thinks that the latest is 0.0.23. Thanks.

from core.

Meteor now sees 0.0.24 and I have updated my test app to it. I'll do some testing in a couple of hours.

from core.

👍

from core.