synaptic-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]