synaptic-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Synaptic-devel] interface changes in 0.51


From: Frank Van Damme
Subject: Re: [Synaptic-devel] interface changes in 0.51
Date: Wed, 21 Jul 2004 20:25:42 +0200
User-agent: KMail/1.6.2

On Wednesday 21 July 2004 09:01, Sebastian Heinlein wrote:
> On Di, 2004-07-20 at 13:15 +0200, Frank Van Damme wrote:
>
> Hello Frank,
>
> > However, I am not entirely happy with the changes in the user interface
> > in the latest version.
>
> There is always space for improving and we are happy to hear where we
> can improve. So thanks for sharing your detailed thoughts and comments
> about synaptic.
> 
> > - in previous versions the filters where more accessible. Now the user
> > has to choose between selecting a filter and viewing a specific section.
>
> We are trying to orientate more on cases of use instead of pure
> providing of functionality. Could you give some or one use case where
> you really missed this?

Not actually since everything is still available if you keep on using just 
filters (like defining a filter that shows upgradeable packages in the 
Editors section). It's just that the same functionality is available in two 
places (showing a section can be done by selecting "section" as well as by 
defining a filter eg) which I, personally, find more confusing than using 
filters for everything.

> > - the tab sheets at the bottom have disappeared, and are only accessible
> > by the entry "properties" in the context menu. Imho the long description,
> > dependencies and other package info are basic stuff that should not be
> > hidden away in a popup window.
>
> At first the dialog "properties" is now non modal in version 0.52 - this
> should make it more usable (it was modal because of technical reasons).

Excuse me... what do you mean with modal <-> non modal?

> The long description is always shown in the main window.
>
> It is not about hiding basic stuff, but about removing not often used
> stuff from the main window to avoid cluttering. Also many users were
> confused by the technical stuff presented in the main window.
> Furthermore I don't know why the dependency tab should be so important:
> the dependency handling should be done by apt/synaptic and not by the
> user.

You got a point there. 

> > - I can not find back the ability to install a particular version of a
> > given package, which - for me - is a good reason to use Synaptic instead
> > of command-line apt.
>
> We dropped this feature, since it was not implemented in a clear way.
> But it is now back in version 0.52. The corresponding menu item "Force
> version..." is located in the menu "Package"

I see (after upgrading Synaptic). I'm one of those people with the bad habit 
of mixing packages from different releases... :)

> > - In previous versions the Keep, Install and Remove (which are the basic
> > functions of Synaptic) were clearly visible, which isn't the case
> > anymore.
>
> Have you had any problems finding this functionality? At first I also
> wanted to implement buttons for this common functions, but Gustavo came
> up with the great status icon menu, which I think is sufficient, since
> the checkbox like status icon seems to attract users in a magical way:
> before that we had have received some complains, that the checkbox would
> not work properly.

Really? Well you know probably better then me what users expect. I would 
rather expect that users who are used to having the 4 most important  
functions smacked up their nose would be missing those.

> > - I find the way of choosing between sections/status/alphabetic, find
> > history, or filter confusing. Imho it would be better to:
> >   * remove the "filter" entry from that menu and restore the filter
> > dropdown at the top of the window like it was before.
>
> Which filters do you miss? How should the find results be handled? The
> "search filter" was quite ugly.

That's not it. I just felt that particular do-it-all dropdown is a weird thing 
from a useability standpoint.

> >   * Add a dropdown to the "find" text field showing the history.
>
> Are you talking about the find dialog or the removed "quick" search?
> There is already a combobox in the find dialog. The old quick search was
> a dead end for many users since it didn't provide enough visual
> feedback. I would favor adding key shortcuts (pressing "b" would jump to
> the first package that starts with the initial letter "b") and a instant
> search field, that you can find e.g. in rhythmbox, muine or epiphany-
> webbookmarks. But we haven't yet found any way to get an acceptable
> speed of the instant search.

Ok, might have overlooked that one. That form of a search function sounds like 
a good idea.

> >   * the sort function is useful bout could be implemented even more
> > powerful :) what about this:
>
> I don't know if this is also the case in 0.51, but you can sort the
> package list by clicking on the header of the column.

Right... 

> >     + Remove the dropdown.
> >     + instead, split the current list in two. The top half can be used to
> > put any of (status, section, alphabetic) in order. Based on this the
> > bottom part can show a tree:
> >
> > ... maybe a simpler solution is preferable but I wouldn't keep using the
> > dropdown for 2 functions, and instead using it only for sorting packages.
>
> What would be the benefits of this way? In which cases of use would this
> be more useful? I don't want to put you off, but we need arguments to
> evaluate solutions.

Avoiding general confusion? See, this interface changes don't imply a 
diminishment of functionality as far as I can see it, but just puts things in 
a strange order. I would call the benefit a clearer user interface; it's more 
obvious what everything does. Disclaimer; this may be because I am just used 
to the pre-0.51 interface.

Greetz,

-- 
Frank Van Damme




reply via email to

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