GUI Roadmap for Version 2.0¶
This is a draft document
Goals for 2.0 GUI¶
Clean up and fix portions of the interface that are not working, not consistent or not HIG compliant.
TODO: Further overall goals for the 2.0 interface.
Assess Current GUI¶
Gather info for possible adjustments to the HIG, to produce accurate checklists for the audit, and to catalog examples of what currently works well. Often GUI audits focus on what's wrong or broken. Establishing a baseline catalog of examples of what does work offers a good reference for comparison during an audit, and potentially a source of examples to be used in the HIG. Good checklists help ensure GUI elements aren't 'fixed' multiple times. Results will be compiled on the wiki under GUI assessment and audit for version 2.0
Discussion on Any HIG Changes¶
Opportunity for the dev community to provide input before any HIG changes occur, and before any GUI changes are cataloged or made. This gives other devs a say in what constitutes the 'best way' of representing some data or widget. HIG shouldn't be frozen after this stage, but a baseline needs to be established, relative to what is expected to be fixed in the current GUI, and how, before a catalog of changes is produced.
Audit Current GUI¶
Analysis of every core GUI component, using the HIG, checklists, and comparing against known good examples. A listing of things that need addressed or changed will be compiled on the wiki under GUI assessment and audit for version 2.0. No actual changes are made, just cataloging the changes in an outline form based upon general application components and file structure in the source. Any active GUI issues in the tracker are added and linked to.
Prioritize and Apply Fixes¶
Most actual work gets done, starting with fixing any GUI glitches that affect functionality or repetitive workflows. The GUI team (i.e. anyone willing to help, via commit or pull request) may mock-up the changes in QtDesigner or source, show the developer who made the GUI component, and ask them to implement the changes. If the developer doesn't have the time, or doesn't mind, the GUI team makes the changes. Asking devs to fix their own work first has several advantages: the dev understands the underlying code and current GUI decisions, the dev gains a better understanding of the HIG and goals for 2.0 GUI.
Changes made will have their text set to strikeout in the list and a commit hash noted and linked to, so the commit can be referenced when other GUI components of similar type are worked on.
The general user community will be asked to add to the list, or submit issues, for anything GUI-related.
(Up to this point in the process work will have been focused on fixing what's not working, not consistent or not HIG compliant.)
Move to a More Maintainable GUI¶
Work towards changes that update the way the GUI is maintained, examples to explore would be Qt stylesheets, user-preference integration, or working with the documentation team to increase overall ease of documentation and contextual help. A more maintainable GUI will also lend itself to a more theme-able interface for users. Separation of GUI design and maintenance from program logic, where possible, is a goal.
Make GUI Improvements¶
Start discussion and/or work towards changes to the GUI that make it distinctively version 2.0, though some of those changes may occur when applying the audit fixes. Feature requests and functional improvements are considered, and if a dev is interested in doing the work, the feature is implemented.
GUI improvement ideas for version 2.0
Usability Analysis and Update¶
Invite the general user community to test the 'new and improved' GUI, providing devs with important feedback on how QGIS is used in workflows. QGIS is used by many different people in many diverse fields. Devs aren't always knowledgeable on aspects of users' workflows. While QGIS can't be everything to everyone, discovering patterns for known workflows and integrating them into QGIS will help smooth the user-friendly wrinkles out of the the interface, hopefully increasing and easing its adoption amongst new users, institutional entities, and possibly entire fields of discipline.
Enterprise and Government Specific¶
An optional further audit of how QGIS's GUI can be adjusted to help acceptance of the program in enterprise or government environments. (This can happen at any time during the process.) Consultation with outside help may be needed here. Many of these environments have restrictions placed upon them. The QGIS project may benefit greatly if it met those restrictions. One such restriction in the U.S. is Americans with Disabilities Act compliance, for example having an interface that works with visually impaired users (colorblindness, etc.). Data security and access is another. There are no doubt many restrictions across the different countries where QGIS might be considered for use.
(Release version 2.0 here)
Larry Shaffer