[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea for determining what users use
From: |
Luc Teirlinck |
Subject: |
Re: Idea for determining what users use |
Date: |
Mon, 2 Jun 2003 21:43:56 -0500 (CDT) |
Richard Stallman wrote:
However, we also copy the name of the feature in a file
specially dedicated for that purpose, .obsolete_features_used
or whatever.
Users are unlikely to notice that this file exists. With that name,
they won't even see it in directory listings. Unless you can design
something to call their attention to it strongly, it may as well not
exist.
I will address the above issue below, but, first of all, is the intent
to just have a head-count, nothing else, or is the intent to get
feedback? The feature I propose is designed to get feedback from the
user. It would not be that useful for a mere head-count.
I personally believe that feedback would be a lot more useful than a
mere head-count. As I mentioned before, suppose some users keep using
an obsolete alternative for a much nicer new feature because there is
one particular functionality the old feature has that is crucial to
these particular users and that was somehow inadvertently omitted from
the new feature. Should we decide to keep maintaining the old feature
or should we decide to add the functionality to the new feature? It
would seem that the latter makes clearly more sense, but with the
head-count we would never know what was really going on.
Now to the problem of making the user aware of the file. Somehow we
need to inform the user about his use of obsolete features in a way
that produces the least inconvenience possible. So let us compare the
inconvenience caused by the proposed mailing system and that caused by
the need to inform the user about the file.
With the mailing system we have to decide whether we want to ask a
yes-or-no-p question or pop up a buffer.
Let us look at yes-or-no-p. The user is busy working. All of a
sudden and not as part of a deliberately invoked command by the user,
Emacs, instead of responding to the user goes:
Beep! Beep! Beep! Fellow, I asked you a question and you better give
me an answer right now: Yes or No?
This is OK in response to a command deliberately invoked by the user
or when there is some other really good reason to do this, without
better alternatives.
Popping up a non-selected buffer with a clickable field to mail, would
in my opinion be less intrusive, because it allows the user to, say at
least finish typing his current thoughts before worrying about the
question. We could mess up the user's window-configuration, but maybe
the function could save and offer to restore that configuration.
So if we go for the mailing I clearly would prefer the latter (with
saving the window configuration). That buffer would tell the user
about the possibility of disabling the pop-up-buffer feature, using
some variable (and offer to automatically do so), while still being
kept informed about obsoleted features he is using (as well as about
other obsoleted features), using the file and commands I proposed.
One-time-inconvenience versus indefinite number of times, as features
keep getting obsoleted over time.
The Emacs manual also would have to explain some of this, so users
know what to expect and why.
There are various other possibilities, but this is one.
Sincerely,
Luc.