[Qgis-community-team] Re: Planning for QGIS 1.0.0 '????'

[Tara Athan]

Time pressure leads to panic, panic leads to mistakes.
I think we will be much better off having a looser schedule for the user
guide and not expect a simultaneous release.

If we were following a stricter development process (GUI design which is
specified early, strong communication channels concerning any changes to
that design) then it might be possible to develop the user guide in
parallel to the implementation.
But my feeling is that is not the way this (or any opensource?) project
works, yes?

Tara

Tim Sutton wrote:
> Tara and others concerned with the manual
>
> The more I think about it, the more I think its maybe not a good idea
> to try to do simultaneous release of QGIS 1.0 and the manual. I've
> been going through the bug queue and many of the tickets would require
> (usually small) changes to the user interface to resolve. This along
> with Toms work on menus and the GRASS work I am doing and the merge of
> composer and labelling stuff - and possibly Godofredo's work is going
> to make a moving target. Trying to restrict UI changes is going to
> hamper developers, not restricting UI changes is going to hamper doc
> writers. For this reason I would like to suggest pushing back the
> manual schedule by a period that will comfortably allow you to update
> it after the GUI is frozen. What do you and community team think about
> this?
>
> Regards
>
> Tim
>
> 2008/7/26 Tom Elwertowski <telwertowski at comcast.net>:
>   
>> Tara Athan wrote:
>>     
>>> Tim & Tom - Let me see if I have this straight
>>> 1. items currently in the dropdown menus will probably not be moved to
>>> different menus, although the order in which they appear might change
>>>       
>> Lots of items will be added. A Mac standard is to have every command in a
>> menu so that an app is fully usable with no visible toolbars. I'd like to
>> minimize movement so as not to confuse existing users however meaningful
>> groupings will take precedence over existing position.
>>
>>     
>>> 2. tools currently in the toolbars may be moved to different toolbars, and
>>> the order may change
>>>       
>> There will probably be less change here because most or all commands are
>> already in toolbars. A few items may be reordered so that the order is the
>> same for both the menu and toolbar.
>>
>>     
>>> 3. new items may appear in the dropdown menus that currently are only
>>> tools or context menu items
>>>       
>> As mentioned, this is the primary goal of the reorganization. There are
>> probably enough of these to result in general rearrangement. For example, a
>> Tools menu will probably be added and Settings will not be a menu though the
>> items will appear somewhere.
>>
>>     
>>> 4. a new menu, the Window menu will be added
>>> 5. another new menu, the Edit menu will be added
>>>       
>> File and Edit will be the first two items; Window and Help will be the last
>> two. Again this is a Mac standard thing.
>>
>>     
>>> We are trying to be more explicit in the user guide,  by giving the
>>> precise sequence of user actions, and all options for doing it (such as
>>> menu, tool icon, context menu, shortcut). Also I think it is best if we
>>> specify in the guide which toolbar a tool is on, so that if someone has
>>> docked their toolbars in various places or turned some off, they know where
>>> to look (there are a lot of icons!). So this seems like a very significant
>>> shake-up to me, in terms of the effort required to update from a v0.11
>>> compatible user guide to a v1.0 compatible user guide.
>>>       
>> It is a significant shake-up. However, I think anything called 1.0 should
>> have a somewhat more organized UI. I'm pushing for compliance with Apple
>> menu guidelines so that a new user will find items in expected locations.
>>
>>     
>>> I am searching for a way for us to move forward on some of the user guide
>>> updates without having to redo work after the GUI freeze- we just don't have
>>> the man/womanpower to do it.
>>>
>>> Here's a thought - if Tom can give us a GUI design, we can write the user
>>> guide to the design rather than the implementation. Then there is less
>>> pressure on implementers to get things done quickly and less pressure on
>>> document writers to do all the writing at the last minute. If there are
>>> changes in the GUI design, we will know exactly where to go to modify the
>>> user guide, rather than having to make a full sweep through the guide.
>>>       
>> I would like to make a menu proposal available for discussion next week. I
>> don't know how long the discussion will last. Hopefully, half of it will be
>> non-controversial and you can document that part first. After that, you can
>> from time to time tell us we need to finalize one more piece.
>>
>> Tom
>>
>>     
>
>
>
>   


-- 
My e-mail delivery has been unreliable lately, so I am asking for
return receipts from all my email messages.
OK'ing the return receipt lets me know that my message was delivered.
Thank you.

Tara Athan
Principal, Alternatives to Invasive Species
tara_athan [AT] alt2is.com
707-485-1198
PO Box 415
Redwood Valley, CA 95470