Update: I'm going to try using a mix of strike through, small caps, and condense and see what the users think. Let me know if there are better options. Thanks.
You are hitting a real problem.
In many cases the standard FileMaker login is strongly confusing to the end users and while we will always stick to FileMakers security model we have to make a modal window with a simple-not-so-messy dialog.
This is OK in some cases, but is offering a lot of ways out that in many cases are utterly irrelevant in the specific solution. And turning of the right to change password does not solve the problem but ads insult to injury by telling the user that the they are not permitted to do what we just offered them to do.
Another issue is that we are showing them the guest access elements, even when guest access is turned of (greyd out).
Terrible information owerflow, confusing and flabbergasting the customers/users.
Especially not at their very first moment using your solution.
Some, if not most, of our users should be recieved as beloved and dear guests and should see nothing but this:
And here Mikes request for a way to display a peacefull, simple and friendly dialog with obscured password is important.
FileMaker 12, with its new Window modes is a gift to us. Only few details still need to get solve.d
1 of 1 people found this helpful
IWP is a killer!!!! when we are talking login. I can only find the same solution as yours (strange/obscure characters).
My suggestion is to divide the login in two versions:
- one not-so-good-version for IWP users (consider giving them FileMakers dialog ... sorry).
- another one for FMP users.
The real solution - which will not work in IWP:
Add an extra field - the password field shown to the end user, where he/she enters the values is a dummy field (pw2). Every time the user enters a value a dot is added to this field while the value is added to the real, invisible, field (pw).
a field scripttrigger of course.
Both pw fields (and the user name) should of course be global fields. Instead of this you could consider not having the real pw field, but just add the real password to a global variable while writing the dots to the visible field.
Btw: This approach also adds the opportunity to check the new password against a much more comprehensive model and set of rules than FileMakers model. And gives the chance to do it in a much more friendly way with suggestions and explanations.
Thanks, Carsten. It seems there's not a good way around this.
I agree; using the option of script triggers or other means would work just fine, but the IWP barrier just creates a no-win situation.
Thanks for the input.
Thanks, and when creating your scripttrigger script: Remember that the user can also use the "delete" button. This should of course delete the last bullit AND the last value from the pw global field/the global variable.
Just one extra thought ... IWP is supporting the webviewer very well. We could probably do something with html/php?
Hmm ... that might be worth a look. Except I'm having issues with the web viewer as well - it's misbehaving with Internet Explorer.
I've walked up to the edge of using IWP and turned away for the reason being discussed here.
Reading this thread has me wondering, how crazy would it be to use an off-the shelf product like Zen-Cart, etc. just as an opening page to handle the credentials ?
Som of our competitors are using IWP a lot, and some of the solutions we have seen are rather well done. We are using PHP, and 3 of our developers are competent php developers. But IWO is not bad, not at all. And since FileMaker 7 it has improved and is now pretty fast as well.