#quantumgis

Related to my yesterday rant about QGIS and usability: I've been reading an article called "Usability and Open Source Software" article and it has a lot of interesting points. It's a little bit dated (year 2002), but I think most issues remain the same even now after 10 years.

Here are some highlights I find interesting (but you should read the whole article):

If this [desktop and application design] were primarily a technical problem, the outcome would hardly be in doubt. But it isn't; it's a problem in ergonomic design and interface psychology, and hackers have historically been poor at it. That is, while hackers can be very good at designing interfaces for other hackers, they tend to be poor at modeling the thought processes of the other 95% of the population well enough to write interfaces that J. Random End-User and his Aunt Tillie will pay to buy. (Raymond, 1999)

...

The ‘personal itch’ motivation creates a significant difference between open source and commercial software development. Commercial systems development is usually about solving the needs of another group of users. The incentive is to make money by selling software to customers, often customers who are prepared to pay precisely because they do not have the development skills themselves. Capturing the requirements of software for such customers is acknowledged as a difficult problem in software engineering and consequently techniques have been developed to attempt to address it. By contrast, many OSS projects lack formal requirements capture processes and even formal specifications (Scacchi, 2002). Instead they rely on understood requirements of initially individuals or tight-knit communities.

The relation to usability is that this implies that OSS is in certain ironic ways more egotistical than closed source software (CSS). A personal itch implies designing software for one’s own needs. Explicit requirements are consequently less necessary. Within OSS this is then shared with a like-minded community and the individual tool is refined and improved for the benefit of all – within that community. By contrast, a CSS project may be designing for use by a community with different characteristics.

....

Many kinds of commercial software have been criticised for its bloated code, consuming ever greater amounts of memory and processor cycles with successive software version releases. There is a commercial pressure to increase functionality and so to entice existing owners to purchase the latest upgrade. ... There are similar pressures in open source development, but due to different causes. Given the interests and incentives of developers, there is a strong incentive to add functionality and almost no incentive to delete functionality, especially as this can irritate the person who developed the functionality in question.

....

The process of ‘release early and release often’ can lead to an acceptance of certain clumsy features. People invest time and effort in learning them and create their own workarounds to cope with them. When a new, improved version is released with a better interface, there is a temptation for those early adopters of the application to refuse to adapt to the new interface. Even if it is easier to learn and use than the old one, their learning of the old version is now a sunk investment and understandably they may be unwilling to relearn and modify their workarounds.

...

Intro

Looks like my morning rant tweet "QGIS needs a usability expert. Or a whole team of them." has caused a little storm in the GIS community. I haven't really expected any feedback on this, so i guess I can say that Twitter is the King. I've already e-mailed some of my views to the first QGIS person that contacted me (Nathan Woodrow), but for the sake of open discussion, I'll expand on these thoughts in this post.

First of all, some disclaimers: I'm an occasional QGIS user. I only use a very limited subset of its functionality (mainly viewing shapefiles, since I think it's the best shapefile viewer out there). I'm not really a GIS professional, at least not in the traditional sense. Half of my work time evolves around developing Maperitive, a cartography software mostly based on OpenStreetMap. The other half is doing work as a professional programmer in an IT company. And I'm not a usability expert, so what I'm writing here is based on my personal experience.

Usability Issues

OK, so let's open QGIS. The first thing users will probably notice is a fair number of toolbar icons displayed at the top:

Don't get me wrong: I'm not against toolbars. In fact, QGIS doesn't even have a lot of icons, compared to some other apps (I use VisualStudio a lot, and it has a lot more toolbar icons). But there are some usability issues with toolbars:

Image-only toolbars

Image-only toolbars are difficult for users to comprehend. It is difficult for most users to remember all those images and associate them with functions. This is contrary to what most designers/developers think when they use toolbars in their apps. Yes, there are some classic icons that get reused all the time (diskette icon, undo/redo, cut, copy, paste), but these are exceptions to the rule. Most of the toolbar icons are application-specific, they tend to be small and look similar to each other. Icons are great enhancers of the information, but they are not the main information.

Possible solutions:

Instead of putting all of the icon groups to the top, separate them physically. Move map-oriented icons (like zooming) closer to the map, possibly arranging them vertically instead of horizontally. I know users can move them by themselves, but that's not the point.

For more important icons, add the text description. Yes, this takes more space, but usability takes precedence over screen real estate.

Alternatively, think about using ribbons. I hate what Microsoft did to Office, BTW, but that's because they chose to use ribbons as a replacement of menus, instead of just an additional way to access commands.

Microsoft introduced ribbons because the number of commands in Word menus grew and grew and it became more and more difficult for users to find things.

Some references:

UX Myths: Myth #13: Icons enhance usability

UX StackExchange: When to use icons vs. icons with text vs. just text links?

Is Microsoft's Ribbon UI really that great, from a usability perspective?

Mouse Bias

One of the greatest productivity enhancements an application can offer is to provide users with the ability to accomplish their tasks using the keyboard instead of forcing them to use the mouse even for repetitive and frequent commands. That's why it is very annoying to find that QGIS doesn't have keyboard shortcuts for the most basic stuff like "Pan Map" and "Select * Features" commands. As I explained to Nathan, I find JOSM's user experience on this much more satisfying.

Also, the toolbar tooltips must display the keyboard shortcuts together with the command description. This is about discoverability.

One other thing (this is a response to Nathan): I would avoid assigning important functionality (like map panning) to the middle mouse button. Maybe it's just me, but I can't remember when was the last time I owned a mouse with a proper middle button. Most mouses these days seem to have abandoned those for mouse wheels, which may be pressable, but that experience is lousy - the wheel itself is usually not ergonomically designed for pressing and it also tends to cause the wheel to move a notch or two.

Mouse-Pointed Zoom

Come on, people. We're in 2012. All respectable graphics editors/GIS programs should zoom to the point indicated by the mouse and not the current map center. Don't make me zoom and pan and zoom and pan and zoom and .... It's 2 lines of code. The fact that QGIS actually has a user setting to switch mouse-pointed zoom makes it even worse. Why doesn't it do that by default? If people can do it in JavaScript (Google Maps, OpenLayers, etc etc), Android, iOS, how come it's not there in QGIS? Heck, even Garmin's MapSource can do it (just tested it)!

"User Can Configure That By Herself" Mantra

Having a user setting for everything and anything is not a good alibi for not making the right design choices from the start. Someone once wrote (I can't find the source now) something to the effect that each user setting represents a decision the developer didn't want or couldn't make, so she left it to the poor user.

So I cannot accept argument that users can assign missing keyboard shortcuts or extend the functionality via scripting. You're assuming two things:

All of the people who want to use the program have the level of technical experience comparable to you (as a designer of the application).

All of the people will be willing to study the complete functionality of the program before actually using it for the purposes they came here in the first place. Most of them won't and will instead put up with having no keyboard shortcuts or will go somewhere else.

Yes, having the ability to assign shortcuts or write extension scripts is great. But this will be used by a tiny percentage of your users. As I mentioned before, I use VisualStudio a lot and so do my colleagues. But I can tell you that I'm having problems trying to find somebody that assigns their own shortcuts in VisualStudio or uses other advanced customization functions. And they are all bright and technically savvy people (heck, they can even write some code). That's not to say they wouldn't benefit greatly from such customization, but most users seem to accept things as they are (even if they are unhappy with them). Call them lazy, but that's the way it is.

On Open Source

I realize QuantumGIS is an open-source project. I understand realities of working in an open source project - I've done some OS work myself. But I don't see that as an excuse for not taking user experience seriously. After all, the purpose of these projects is to make life easier for its users. And you don't really need big investments to improve the usability - my talk of "usability experts" should not be taken too literally. There are a lot of things that can be done without too much time & money:

Take a look at some UX guidance documents. Here's a good one from Microsoft. There are a lot of other good ones.

Visit some good UX Web sites, like designinginterfaces.com or even read some user interface books.

Participate in ux.stackexchange.com. Ask questions and advice. Ask people who never used QGIS before to evaluate your design.

Instead of implementing a new shiny XY functionality for the next release, invest that time to fix some usability issues.

Drawing map is so lovely if we do in python.

This is the mapnik xml that I generated from QuantumGIS

<?xml version="1.0" ?> <Map bgcolor="rgb(255,255,255)" srs="+proj=utm +zone=48 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs">     <Style name="Bangunan_style">         <Rule>             <PolygonSymbolizer>                 <CssParameter name="fill">rgb(144,52,45)</CssParameter>                 <CssParameter name="gamma">0.7</CssParameter>             </PolygonSymbolizer>             <LineSymbolizer>                 <CssParameter name="stroke-width">0.96</CssParameter>             </LineSymbolizer>         </Rule>     </Style>     <Style name="Jalan_style">         <Rule>             <LineSymbolizer>                 <CssParameter name="stroke">rgb(255,0,0)</CssParameter>                 <CssParameter name="stroke-width">0.96</CssParameter>                 <CssParameter name="stroke-linejoin">bevel</CssParameter>                 <CssParameter name="stroke-linecap">square</CssParameter>             </LineSymbolizer>         </Rule>     </Style>     <Style name="Sungai_style">         <Rule>             <LineSymbolizer>                 <CssParameter name="stroke">rgb(70,130,180)</CssParameter>                 <CssParameter name="stroke-width">0.96</CssParameter>                 <CssParameter name="stroke-linejoin">bevel</CssParameter>                 <CssParameter name="stroke-linecap">square</CssParameter>             </LineSymbolizer>         </Rule>     </Style>     <Style name="kelurahan_style">         <Rule>             <PolygonSymbolizer>                 <CssParameter name="fill">rgb(157,245,92)</CssParameter>                 <CssParameter name="gamma">0.7</CssParameter>             </PolygonSymbolizer>             <LineSymbolizer>                 <CssParameter name="stroke-width">0.96</CssParameter>             </LineSymbolizer>         </Rule>     </Style>     <Layer name="kelurahan" srs="+proj=utm +zone=48 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs">         <StyleName>kelurahan_style</StyleName>         <Datasource>             <Parameter name="file">bdg_barat/kelurahan.TAB</Parameter>             <Parameter name="layer">kelurahan</Parameter>             <Parameter name="multiple_geometries">0</Parameter>             <Parameter name="type">ogr</Parameter>         </Datasource>     </Layer>     <Layer name="Sungai" srs="+proj=utm +zone=48 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs">         <StyleName>Sungai_style</StyleName>         <Datasource>             <Parameter name="file">bdg_barat/Sungai.TAB</Parameter>             <Parameter name="layer">Sungai</Parameter>             <Parameter name="multiple_geometries">0</Parameter>             <Parameter name="type">ogr</Parameter>         </Datasource>     </Layer>     <Layer name="Jalan" srs="+proj=utm +zone=48 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs">         <StyleName>Jalan_style</StyleName>         <Datasource>             <Parameter name="file">bdg_barat/Jalan.TAB</Parameter>             <Parameter name="layer">Jalan</Parameter>             <Parameter name="multiple_geometries">0</Parameter>             <Parameter name="type">ogr</Parameter>         </Datasource>     </Layer>     <Layer name="Bangunan" srs="+proj=utm +zone=48 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs">         <StyleName>Bangunan_style</StyleName>         <Datasource>             <Parameter name="file">bdg_barat/Bangunan.TAB</Parameter>             <Parameter name="layer">Bangunan</Parameter>             <Parameter name="multiple_geometries">0</Parameter>             <Parameter name="type">ogr</Parameter>         </Datasource>     </Layer> </Map>

the hardest thing to get the map is find the right coordinate so it could rendered properly so it's better if we generated it from the background layer coordinate. I change

map.zoom_to_box(mapnik.Envelope(778614, 9240464, 790014, 9230968))

to

map.zoom_to_box(layer0.envelope())

now we can get the map automatically without confused with the number

import mapnik map = mapnik.Map(800, 400) mapnik.load_map(map, "bandungbarat.xml") layer0 = map.layers[0] map.zoom_to_box(layer0.envelope())

mapnik.render_to_file(map, "bandungbarat.png")

and this is the result.