[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Synaptic-devel] New term for "No changes" is needed
From: |
Gustavo Niemeyer |
Subject: |
Re: [Synaptic-devel] New term for "No changes" is needed |
Date: |
Tue, 10 Feb 2004 11:45:07 -0200 |
User-agent: |
Mutt/1.5.5.1i |
> > > - Dequeue
> > >
> > > This term would also reflect the "queuing" concept in synaptic.
> >
> > I confess I'm not in favor of the "queue" concept, after all, there
> > are no visible nor abstract "queues" in Synaptic. I think "scheduling"
> > would fit better our purposes.
>
> This might be right from a perspective which also takes the internals in
> consideration [which I don't even know exactly :) ], but on the ui level
> the things look different.
As you've noticed, I've explained that in the paragraph above. There are
no *visible* nor *abstract* queues in Synaptic. I wasn't talking just
about the implementation.
> The queue with changes is visible in the "programmed/queued changes"
> filter and the summary dialog to the user.
This is not a *queue*.
> Furthermore the queue terminology is commonly used to describe the way
> of selecting something, putting it on hold, collecting more and then
> finally applying them at once. This is the way the interface works.
I have never seen this terminology been used the way you describe. A
queue is used to represent when things have a sequence, like a queue
of jobs which will be executed one after another. This is not the way
the interface works, and should be changed.
> IMHO I was not the only new user who asked what "programmed changes"
> are.
If we had the welcome dialog we have now, you wouldn't have asked. It's
not about the exact term we use, but about explaining to the user the
general idea: things are not applied immediately.
> The idea behind the introduction of queue was to unify the former used
> terms "mark", "selceted" and "programmed".
I like the idea of unifying them, but I don't like the queue term, for
the explained reasons.
> I don't think that the user should be bothered with code internals. The
> ui should use clear, familiar and consistent terms.
I'm not talking about code internals, as I've said since the first
paragraph I've written about this matter.
--
Gustavo Niemeyer
http://niemeyer.net