[Qgis-developer] Polishing QGIS

[Alister Hood]

Hi Tim,
As a user who opens a lot of tickets which could be described as about
"polishing", this is great to hear.
I do have a comment below - I hope it isn't too long.

> Date: Sat, 24 Sep 2011 13:39:57 +0200
> From: Tim Sutton <lists at linfiniti.com>
> Subject: Re: [Qgis-developer] Polishing QGIS
> To: Paolo Cavallini <cavallini at faunalia.it>
> Cc: qgis-developer <qgis-developer at lists.osgeo.org>
> Message-ID:
>
<CALCNqkYpv87-OmG27ngK2fM_QwBp4oNhciP_g0FEJyzRgWJ88Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Paolo
> 
> On Sat, Sep 24, 2011 at 10:41 AM, Paolo Cavallini
<cavallini at faunalia.it>
> wrote:
> > Hi all.
> > Just finished (yet another) course, this time in Spain. Went well,
> > people looked very positive about it. Crashes are less and less
frequent
> > over the course of the years, even using the dev packages.
> > Now that many core issues are solved, cosmetic issues are more
apparent:
> > we suffer from duplications and inconsistencies. I have opened
several
> > tickets. I know it is a boring and unexciting job, but sooner or
later
> > we have to do it.
> > Anyone has plans to work on this?
> 
> In my mind this will be very much the mission of 2.0 - as well as
> making all the internals clutter free and consistent, we must work to
> make the ui the same. I hope to spend the upcoming hackfest working to
> build more re-usable widgets (as we have discussed and planned in
> Lisbon). Building a good widget library I believe will be a key step
> towards achieving this consistency and will have the benefit on
> centralising fixes that then propogate themselves to all parts of the
> UI that use that widget, The projection selector widget is a really
> good example of the mileage we can get from this approach - it is used
> in various parts of the ui and in many plugins.
> 
> There are some key things I think need to be done:
> 
> - adopt an activity based interface: e.g. the print composer,
> georeferencing tool and other parts of the app that also implement a
> main window ui are all kinds of wrong. There should only be one main
> window and set of menus in any application, so we need to implement
> the appropriate changes such that the menus etc update according to
> the context of the work (activity) you are doing. In the courses I
> give, people generally lose the composer window and it is not uncommon
> to see them with ten instances of composers as they lose it and create
> new ones in succession.

I'm sure you will do anyway, but I might as well say it: Please think
carefully about this sort of major change, as the current system works
very well as soon as you understand about working with multiple windows.

It can be very useful to have a number of windows open at the same time,
especially attribute tables and composer windows.
1) it is good to be able to look at several windows side by side
2) it provides a way to quickly switch between a few that you are
actually working with, so you don't need to keep searching for them in a
very large list.

What will an "activity based interface" look like, and will it provide
for these situations?  Will it work with multiple screens (and virtual
desktops), e.g. so you can have an attribute table on one screen and the
main window on another?

Will it really be better?  It seems you could end up removing powerful
functionality, essentially using a sledgehammer to break an egg, and not
really improving much.

Maybe you could achieve the same benefits by minor improvements to the
existing gui, e.g.

- add one or more widgets which allow the user to switch which layout or
attribute table is shown in the current window (Menu?  List?  Spinbox).

- change how features are accessed, to make them more (or less?) easy to
find and use.  Currently the "New print composer" menu item stands out
more than the items in the "Print composers" submenu.  It might be good
to rename the "Print composers" submenu to "Open print composer" or
"Show print composer", and give it an icon.  An alternative might be to
move "New print composer" and "Composer manager" to the top of the
"Print composers" submenu, with a separator between them and the list of
composers.  Similarly, on the toolbar there is a button for "New print
composer", but to access an existing composer from the toolbar you need
to click the "composer manager" button, select a composer, click show,
and then close the manager.  It shouldn't be this much harder to open an
existing print composer, which is a much more common task than creating
a new one.  But this could be fixed by a small change to how you open
the print composer, without redesigning the way the whole thing actually
works.
 
> - Implementing the symbology ui better. We need some kind of tree
> interface (we discussed this at the hackfest in Lisbon in some
> detail). New symbology is very confusing when you have symbols
> composed of symbols that are themselves composed of symbols. Managing
> that causes many levels of windows to be spawned and novice users
> (advanced users too I guess) can quickly lose track of where they are.
> 
> - We need to look at how simple interactions work and streamline them.
> For example, label rotation is a nice new feature but its almost
> impossible to get the alignment you want interactively.
> 
> - We need to identify parts of the user interface that are 'advanced'
> and hide them away from casual users.
> 
> - We need to apply sensible defaults and work towards the element of
> least surprise.
> 
> - We should start thinking about implementing a telemetry layer in
> QGIS - with ~200 000 possible users out there, if even just 10% of
> users allow us to collect telemetry data it will be a goldmine of
> information (it will make a nice GSOC project). Know where users
> click, how often, which dialogs they spend most time in, etc etc can
> prove invaluable in targeting places that need improvement most.
> 
> I could keep on going all day about all the other things we need to
> do. This hackfest I was thinking it would be nice to try to do the
> planning and meeting stuff before the time as much as possible (via
> wiki / mailing list) so we can come prepared in small teams ready to
> reaaly focus on working. I enjoyed Lisbon very much but I felt we
> spent too much time meeting and discussing stuff and not enough hands
> on time so it would be great to address that. Anybody coming who is
> interested in forming part of a GUI overhaul team lets get the ball
> rolling and put our plans in place here
> 
> http://www.qgis.org/wiki/Version2GuiRevision  (just a place holder
> page for now  - we can flesh it out in the run up to Zurich).
> 
> 
> Regards
> 
> Tim

Thanks,
Alister