Jim Meyer wrote:
Perhaps the more proper solution is to improve the documentation?
Improving the documentation assumes that people actually read it
first.
This is where it reduces to philosophy: you don’t want new users to
have to read the instructions before you start setting RT up for
production. I think that reading those instructions is the measure of
a responsible technologist.
I agree with both of you! I reckon it’s responsible to read through the
instructions before deploying a new system for real.
But also before making a decision to deploy new software, it’s
responsible to evaluate it. Given how awful most software is, it seems
responsible, at least initially, to minimise the time spent testing a
particular program. Often just by playing around with some software
it’s possible to get a feel for it (or at least enough to know it isn’t
worth bothering with!).
I’d expect a competent techie to have enough background, experience,
nouse, and curiosity to be able to make a stab at an initial evaluation
without spending lots of time ploughing through all the available docs.
And it does nothing to address the fact that the user interface
uses ‘/’ as a separator between nested levels of keywords in it’s
display, […]
I don’t see that using a / separator is a problem which needs to be
addressed. Again, I think it’s a matter of philosophy.
For what it’s worth, I also initially tried creating hierarchies by
typing slashes in keyword names, but I worked out the ‘correct’ way
within half an hour or so. I did look at the documentation – it was
the ‘RT/FM Installation Guide’ that caused me to try typing slashes in
the first place. (I hadn’t read the Keywords-Howto by that stage.)
So an explicit warning in the installation guide would seem a good idea.
(Many beginners appear to have fallen for this, and that won’t irritate
experienced users since the latter won’t be reading the installation
guide.)
To be precise, your solution means that any new user is protected
against this one flaw (and lulled into thinking he understands the
system, a side issue to this discussion); any programmer can remove
the limitation once s/he has hunted it down; and any other user (e.g.
experienced non-programmers) is stuck with it. That is unacceptably
and artificially dumbing-down the system to no worthy purpose.
I agree with that; removing this functionality would be bad.
However, as a compromise, what about not refusing to add keywords with
slashes but still displaying a warning message? That way any beginner
who’s got this wrong gets told about it, but on the odd occasions
experienced users want slashes they still can.
The warning could even be restricted to only being displayed when
generating a keyword called “Left/Right” when there already is a keyword
simply called “Left”; that would catch all the beginners making this
mistake and affect hardly anybody genuinely wanting slashes.
Note that the above is merely by conjecture: there is almost no chance
of me being bothered to write code to do this – yes I did make the
mistake, but having made it once I’m not going to make it again, and
there’s many more things I want in ‘RT’ for my own use that I’m much
more likely to code.
Cheers.
Smylers
GBdirect
