[Qgis-developer] Polishing QGIS

Tim Sutton lists at linfiniti.com
Mon Sep 26 05:12:23 EDT 2011 

Hi

On Mon, Sep 26, 2011 at 10:56 AM, Tim Sutton <lists at linfiniti.com> wrote:
> Hi All
>
> On Mon, Sep 26, 2011 at 10:39 AM, Ramon Andiñach <custard at westnet.com.au> wrote:
>> I also would be concerned about a purely 1 window approach.
>> Taking an example from my routine work, it is extremely useful to be able to
>> retain the georeferencer window open as it allows me to visually confirm my
>> control points are where I'm expecting them to be.
>> -ramon.
>
> Just to clarify, I was *not* suggesting a purely one window approach,
> I was suggesting that should only be one *Main Window*.  That is only
> one menu should exist in the application. Try this as an experiement:
> open the georeferencer, enable dock mode in its settings and then dock
> it into the main window. Now you get a dock with menus and the main
> window with more windows.

Sorry I meant more *menus* :-)


Regards

Tim

> This is just plain wierd UI wise. My
> suggestion was rather than we adopt an activity based view where the
> main window menus update according to the context of what you are
> doing. Just try opening openoffice and switching between normal view
> and print preview to see what I had in mind - the toolbars adjust
> themselves and menu items grey out based on your context. I would
> expect that we will adopt a tabbed interface to QGIS (with possiblity
> to tear of tabs as floating windows) and that based on the kind of tab
> you have open, we would adjust the menus and toolbars and other
> contextual information accordingly.
>
> @Nathan and @Alister thanks for your comments - I'll formulate a more
> detailed reply to your points tonight!
>
> Regards
>
> Tim
>
>
>> ______
>> The rest of this is some examples from a closed source program[1] that
>> reflects some of what I think Nathan is suggesting. I'm not remotely saying
>> it should look like or work like this - it's just an example.
>> On the left of a set of dialogue boxes that can be nested. As default the
>> top half has three nested dialogues that show forms (approx saved styles),
>> Properties (what the info tools creates), and Sections (approx map
>> bookmarks).
>> Below that is a Display dialogue that shows windows that are open. These can
>> also be reached and reordered by tabs across the top, just below the menus.
>> I can't pull the main windows out onto a different screen, but I can pull
>> the dialogue boxes out around the place, so top right shows the properties
>> box being pulled around. If I drag onto one of the little arrow-like things,
>> it docks against the edge of the window, e.g. Bottom right. Otherwise you
>> can let it go somewhere, including a different screen and it stays there.
>>
>>
>> 1. I *think* this is the last piece of propietary software I have to use. If
>> anyone can think of an OSS/FOSS equivalent, I'm curious to know.
>> On 26/09/2011, at 12:33, Nathan Woodrow <madmanwoo at gmail.com> wrote:
>>
>> I have to echo Alisters concerns with moving to a single window system.
>>  MapInfo (and Arc as far as I know)  currently use a single window system
>> and it's a pain if you do have multiple monitors and want to use them.
>> In my ideal QGIS world we could have a single window system (using tabs
>> to separate the windows) but have the ability to tear each tab off into it's
>> own main window for a different monitor.  This model could then
>> be adopted for 1+N map windows and 1+N composers.   I don't think this would
>> be overly hard to achieve but would just require some thinking with how the
>> UI behaviors in each situation.
>> Here is a idea using Visual Studio 2010 as
>> an example http://blogs.msdn.com/blogfiles/zainnab/windowslivewriter/thebestofvisualstudio2010freeyourdocumen_761d/image_thumb.png
>> The window that is highlighted is normally docked in the main VS window
>> however you can break it out into its own window if you need in order to
>> use multiple monitors (very handy!).
>> This is a concept that I can up with the other day for handling the composer
>> list thing and tab interface http://imgur.com/8aA1W The idea is we just have
>> one list with the tabs (or windows) to handle the map canvas/es and
>> composers.  In the case of the tree view when clicking on a item header (eg
>> Map Window or Composer 1 etc) the tab would switch focus to that window/tab
>> and set up the controls for the tab/window.  Using this model would allow
>> you to also drag layers from a map window into a composer map frame as
>> technically the composer map frame and map window are not 1:1 always with
>> layers sets. Being able to see what layers are in what frame would also be
>> handy IMO.
>> Just my thoughts for this at the current time.
>> - Nathan
>> On Mon, Sep 26, 2011 at 1:26 PM, Alister Hood <alister.hood at synergine.com>
>> wrote:
>>>
>>> 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
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==============================================
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Visit http://linfiniti.com to find out about:
>  * QGIS programming and support services
>  * Mapserver and PostGIS based hosting plans
>  * FOSS Consulting Services
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
> ==============================================
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================

More information about the Qgis-developer mailing list