Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Admin Panel Edits for 4.0.4
If “doesn’t work at all” means doesn’t “do” anything publicly visible at the moment, then yes.
OK. So the chances of it being hidden until functionality is “publically visible” is nil, I reckon?
It’s a little complicated because of old versus new behaviour (backwards compatibility). Earlier, you would insert raw PHP and it would be parsed. Later, a specific Textpattern tag was created to be used instead. Rather than completely removing the earlier behaviour, you get a warning that you should be using the tag for it instead. This new preference is a way of enforcing this – not only would you get the warning, your PHP would fail to be executed. It’s useful if you have more than one user with access to publishing articles and templates.
Wonderful. So this is an evolution of functionality then, and in later relseases we should see a complete elimination of using any raw PHP (and thus the widget option along with it)?
There’s no doubt that some of the docs need retooling (or be created…), but no assumptions are made as to what the user’s knowledge level is.
My mistake. I should not have used the word “assumed”. I should have really said that Help should be written with a little more consideration to the lowest common denominator (user understanding).
This is what the purpose of “Advanced” options is for, in part: things that are advanced, which a user may not be able to grasp. For those, usually the default is “safe” to be left alone entirely, you need not have a clue what they’re for. Those that care about such things usually do know how they work. When they don’t, or it needs clarification on certain points, that’s what the help popup is supposed to be for.
Good point. And I have already made that notion clear in the wiki docs.
And don’t forget: it’s just as easy to overdo it, and give far more words to an explanation than is helpful.
This is true, though long paragraphs is not really what I was suggesting, but rather a rethinking of the more fitting words to begin with, and if it takes an extra sentence or two, that won’t hurt anything.
the help popup docs are only accessible to the developers. I am pretty sure you need to contact Pedro to discuss adding/refining help texts.
Dean once told me that it was possible for others to help write those widget help pieces, that it was managed via a cookie or something like that? Anyway, I indicated I would be interested, but I never heard back. That was quite a while ago, and at this point I would prefer to just focus on the wiki. No offense to Pedro, he’s a fine chap, but if he’s in charge of English documentation, then maybe that’s a misallocation of skillsets. Like I said before, Reid should be the one on that job (or a new, dedicated writer altogether?)
Oh, I don’t want to keep chasing two different threads that more or less deal with the same issues (documentation) so I’m going to respond to your comments below from elsewhere, here…
Mary from there: I’d recommend just Googling and placing a couple relevant links – since this isn’t Textpattern-specific, but a commonly used technique.
Actually, I think just having external links by themselves as a substitute for internal help is a bad call (equally as bad as writing 300+ words of custom copy). Certainly links to external information a nice addition that a user can choose to use, but they should not be the primary means to the end, especially if the widget is a simple Yes/No option. If there’s going to be an widget option in the admin side, and thus help copy for that widget, then there needs to be an attempt at explaining it, whether or not it’s a wider technological issue. Again, the base of my argument there was better help copy to begin with (less vague).
Last edited by Destry (2006-08-23 10:08:37)
Offline