The convoluted user interfaces of most desktop GIS software is something I revisit from time to time. James’ most recent issue of his SpatialTau newsletter got me thinking about it again. A while back, I got caught up in a Twitter discussion about it. Tools like and TileMill have fantastic interfaces, but they also perform narrow functions (data editing and map composition, respectively).

For a while, I’ve been thinking that this might be an approach worth investigating: rather than one piece of software with everything in it, a suite of tools dedicated to different aspects of the typical GIS workflow. This would not be a panacea as some tasks are just more complex than others. (Think of all of the editing options available in any piece of CAD software, and this is devoid of any analytical tools.) As attractive as this approach seems to me in concept, I suspect it would break down in execution. I think it could end up multiplying the problem with many overly-complex applications instead of just one.

Over the last year or so, I’ve become somewhat enamored of another approach: the search tool. This requires a little back story.

Sometime in early 2013, it became necessary to repave my wife’s old desktop PC. We had purchased it in the waning days of Windows XP and had never upgraded it to Vista or Windows 7. Due to years of installing and uninstalling various forms of games, educational software, and the like, it was clogged up and needed to be rebuilt.

Given the time frame, I decided to install Windows 8. I immediately hated it. The UI was clearly meant for tablets and phones and was just cumbersome for a standard desktop PC. Or so I thought. The upgrade to Windows 8.1 didn’t do much to lessen my hatred.

I was talking about this with our company’s IT support contractor and he said to me “You’re kidding, right? Windows 8 is the easiest operating system Microsoft has ever released.” I was incredulous. He said “Just slide your mouse over to the right and type whatever you want to do into the search tool.” I started doing that and I became hooked. User management? Type “users” and it will most likely be in the top of the results. The same for any applications I installed, or printer management, or whatever. I have long since stopped caring about where these things reside in the live tiles. I use the desktop and the search bar. The desktop has icons of my most commonly used applications only.

This approach bled over into my use of Ubuntu. I used to hate the Unity desktop and would always put Cinnamon or some version of Gnome on my machine. Now I live in the Ubuntu search interface and no longer care about Unity. So, yes, Windows 8 made me more productive on Linux. Go figure.

So, back to GIS. As James pointed out, desktop GIS typically has user interfaces that only a mother could love. Perhaps it’s time to hide all of that complexity behind a search tool that surfaces the tools you need when you need them. After all, no software can or should obviate the user’s understanding of workflow, so it is reasonable to expect users to be able to search for the tools they need for a given task. Perhaps each tool could have pointers to “related tools” that are commonly grouped together, or even suggestions for tools that a particular user has commonly used together. The software could even allow users to build their own task-specific toolbars to be save in a project.

I’m thinking it can’t be worse than this:

7 thoughts on “Toolbars

  1. I read James’ piece as well. I agreed for the most part with what he was railing against, but I couldn’t see a concrete example of something he would approve. Thanks for taking it a step further.

    These different UI’s have different challenges. Do you give the user a “Choose your own adventure storybook” a la ribbon bar? You’ll have to deal with users complaining their favorite feature is broken because they forgot to select the feature that brings it up.
    Or, like you suggest, you bring up a search bar. Then your tools have to be properly documented with related key words, and possibly make it user friendly enough that someone who doesn’t know inverse distance weighting from kriging can do their job.
    With the state of the current toolbar menu that James shows, it’s hard enough to make sure the buttons, tools, addons, and plugins you expose in the toolbar do their job. To also modify their visibility or content based on current workspace content adds to the complexity. If the platform doesn’t let your tools subscribe to content events, You can’t pull it off. But if the platform supports it, there could be a lot of tools listening for changes, and potentially a lot of memory used to hide 2/3 of those buttons when a feature is or isn’t active.
    Not saying it’s impossible. But it’s going to require some significant architecture/UI/testing disciplines working together.

    1. Agreed that it wouldn’t be easy. Anything that presents simplicity to a user usually isn’t easy to implement on the back end. I think the current state is much easier on the developer than the user, but that’s just my opinion.

      Devising and enforcing an indexing scheme would be a challenge for search. I’m less concerned about users that don’t actually understand their jobs. The responsibility to know which tools they need is theirs. My responsibility would be to make sure they can find them.

  2. I know you dislike the Ribbon, Nathan, although I’m not really sure why. I think it’s strength lies in it being dynamic. Just think how useful just about any toolbar or menu in QGIS would be if they dynamically changed in response to whether a vector layer or raster layer is currently active. This could also apply to a number of functions. Instead of having an editing toolbar, just have a editing button that changes the landscape of the existing interface. I think dynamic behaviors could go a long way toward wrestling menus and toolbars into usefulness.

  3. There are two things with having a (tool) search function (something I have considering adding to QGIS for a while now):

    1) It has to be fast
    2) It has to give the correct results when the user might not exactly not know what they are looking for

    2) is more important then 1) and this is where I find the Windows 8 search sucks a little. Searching for stuff I have installed tends to yield web results first which means my Win Key + Search + Enter normally opens a web browser. You wouldn’t have web results in a GIS search but it’s more to the point that the first result should normally give you what you need so you can be quick.

    Search can be a good compliment but I don’t think hiding everything from the user and just having a search bar would work.

    I’m also of the opinion that we can improve this situation without restoring to a ribbon interface which really just moves the cheese…

    1. I agree that hiding everything would be a bit extreme in practice. I think you could hide most things and use search to get at the ones you need when you need them. I agree that search would get annoying if used every single time. I’m thinking more like you could use it to find the tools you need and then drag them onto the canvas for repeated use. I think the indexing behind the scenes would need to be fairly robust. It bears more thought.

  4. I have to disagree with you on this one. Accessing a search tool and then typing into it does nothing for productivity. I find toolbars to be useful enough if they can be fully customized. I am also a big fan of Microsoft’s Ribbon interface. The idea of a single toolbar that changes dynamically according to the task at hand seriously appeals to me. I expect it will only get better as time goes on.

    1. I get that and I’m also a fan of the ribbon. I don’t think any one approach will will make everyone happy. I don’t think using a search tool every time would go far, but it might be a good way to initially access tools for a task, which you could then persist onto the UI in some fashion. I also think the really common tools should just be there by default. I may play with this more in my copious free time.

Comments are closed.