Re: [Synaptic-devel] interface changes in 0.51

[Sebastian Heinlein]

On Mi, 2004-07-21 at 20:25 +0200, Frank Van Damme wrote:

> > 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.

Perhaps we should label the filters "Custom" or "Custom filters" to make
the sense of the filters more palpable. We don't want to delete any user
created filter during update. So the old filters still exist. If you
remove the file "/root/.synaptic/filters" synaptic won't recreate the
redundant filters at start up.


> > > - 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?

Sorry, this a technical term: if the sub window of an application is
always on top of the main window and if you can only return to the main
window by closing the sub window it is called modal. An example would be
the find or upgrade dialog.


> > > - 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... :)

You are OK with the new way?


> 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.

Without user interface test studies you don't know it for sure (low on
resources). But we haven't received any complains yet and this is a big
indicator. 


> > > - 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.

I want to push the search functions since I think that browsing is not
very effective if you have 14000 packages plus.


> > > ... 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.

Could you be more detailed on this? Because this is the interesting
point to improve the user interface. What did you want to do? And at
which step were you confused or would you expect another method?

Regards,

Sebastian