Improve inline documentation of admin interface

This one deserves to be opened again I guess: #496446: Administration interface tough love

I completely disagree with you in this: "the module would be useable out of the box without the README." . There's no reason for this. IMO reading the readme is mandatory to know what can be done (and what should not be done) with the settings, and this clearly doesn't fit in the admin interface. Once you KNOW (not guess) the module options and their purpose, there's no need to put more load in this really overloaded page, but I agree that the interface is not fancy, neither sexy enough.

I mean, this module is not a gaming module to be playing with, or should not be, therefore I'll try to avoid any idea that may lead to this kind of situation.

I said "would", not "should": my point is this is a simple module, from the user perspective: enable it, fiddle with settings in the admin section, get extra security. Why document the settings in the README instead of the admin section?

I'm not saying the README should be dropped, but at this point, there clearly is a discrepancy between the documentation available in the admin interface and the README.

A good use case is this: I install the module, read the README (like the good boy i am ;), fiddle with the settings, login and out, be happy. A few months later, come back to my site to change the settings because of user complaints. I log into drupal, head for the login security settings (because I know where they are now!), but.. hum... what's this setting for again? Rah, need to pull out my FTP/SSH credentials just to read that silly README...

I understand the README can be useful and often consulted when installing the module (it's common practice) but for those details, it could simply point to the documentation in the settings page.

Update: Oh, and I wouldn't reopen #496446: Administration interface tough love... this is a new issue. :)

Also keep in mind some users will have login_security bundled with their system at some point (through install profiles and such) and having the README is not sufficient in that case.

Maybe (I don't know) you just bumped into the module queue and had several ideas.. good point. I guess (just a guess) if you didn't realize to read the README file, why should you look at the issue queue.. I'll point you back to this one: #496448: Review/Create module documentation, even if incomplete, you will have a handbook page with the documentation and specific use cases (as included in the README, I'm planning to rename PLEASE-DONT-README.txt).

If you need to access the file again, you can even search using "login_security readme.txt cvs" that will point you to: http://drupal.org/cvs?file=/modules/login_security/README.txt where you could read any of the versions without an SSH or FTP client. There's no way to put all the information in the admin interface.. but it's possible to change it to be more clear..

But I agree that this part needs some work, as you said. Now, I leave the issue open, please, provide suggestions to the admin interface, I don't know what do you mean with being consistent between the readme.txt and the interface itself. A mockup or some texts will be helpfull, and of course, I'm waiting for them to be introduced for the next version.

PD: about the use case: oh, I just install the module for the first time, and go to the readme to see what should I do to avoid blocking the site or users. then, a few months later, I will do the same to avoid bloking the site or users. This module is an evil, please read: #558624: When using feature "Increase delay for each attempt" no logins are possible anymore to see how simply a site could be stalled just changing a WELL EXPLAINED configuration option.

ok, lets move this one.. I just changed the field descriptions in the form, with README.txt descriptions, and now interface may look a little bit overloaded, but is completely re-documented IMHO. Anyway, if it helps..

All tests passed. No coder issues. Verified manually. Commited to 6.x-1.x-dev

Automatically closed -- issue fixed for 2 weeks with no activity.