Reply to Stephen Lead's post on Count-dependent rendering
Moderator – I cannot figure out how to post a reply using the web interface (using both Chrome and IE9) ... any instructions?
From a colleague of mine at esri (Charlie Frye):
The User interface portion of the user experience is actually pretty decent. The only thing I would adjust regarding the website design is to make the titles of the maps more prominent (having the Atlas EXPLORER and logo being the most prominent thing on the page) is not helpful to users of the map. The map title should be most prominent, and then the most important task widgets.
Another thing that would be good is to have a button for map use tips, where users could be shown how to use the Shift-key and drag the cursor to zoom in, etc.
The maps, need some fine tuning in regard to how they are used by the app. Draw the text on top of the thematic data—the #1 rule about any web map or web graphic is that it must be legible. Drawing the thematic polygons on top of the text makes the map useless and frankly, the resulting aesthetic looks dumb--because it the information is clearly out of order (something even CEOs can understand). I know you can’t do anything about the road map unless you want to make your own top and bottom layers. So, I like that you used imagery as your default view—it’s hands down the most popular kind of map anyway.
I LOVE! The population pyramid. Sweet!
In terms of multiscale/traditional, traditional is old and useless. If this map feels like it will work, then it works. My guidance is not to listen to traditional cartographers who will tell you the geography shown on each screen must make sense relative to the next screens. No—the overall picture must make sense, and the fact is: geography works at different densities at a given scale. Always do what’s right to communicate well when it comes to mapping—rules are for neophytes who lack confidence, direction, and insight. Whoa!—how’d that soapbox get under my feet?
On the technical side of cartography, the legends need a little work:
1. Nil? Is that Australian for zero?
2. Truth in Mapping—always disclose your minimum and maximum values. “fewer than 250” and “more than 1,000” are not informative and frankly set up an attitude of skepticism on the part of who will be your most educated users (which are the people you ultimately want to market your map by word of mouth). You are a trustworthy source for information, and by using conventions like this, you undermine that trust.
3. The legend title is the field name? Use Aliases—make this information human-friendly. Programmers and computers are not human (think about it). Then don’t repeat the actual title in your qualification about the map being smart enough to show you the best stuff.
4. I would move the enumeration unit type below the legend elements.
5. Your first legend class value should be 251, 501, 751, etc. (the value 500 cannot be in both classes, and that confuses people when it comes time for them use the map for something specific).
Thanks for sharing it.
Charlie, a huge THANK YOU for taking the time to write such a thorough review. It's very much appreciated.
> In terms of multiscale/traditional, traditional is old and useless. If this map feels like it will work, then it works
I was most concerned with the count-dependent rendering aspect, so you comment above is perfect and gives me confidence that this will work.
Great points on the other aspects too:
> The map title should be most prominent, and then the most important task widgets.
Good point, I'll see if we can tweak those settings.
> have a button for map use tips
Great idea. We wanted to avoid having a "user manual" but some tips and tricks would be useful.
> Draw the text on top of the thematic data
I'd love to be able to do this, but we need to use the Bing basemaps, which contain the labels, then we draw the polygons on top. Options could be reducing the transparency of the polygons, but then you lose the location context. (Some of the more traditional cartographers involved in the project didn't want any basemap at all - I think the current implementation is better than a blank screen)
> “fewer than 250” and “more than 1,000” are not informative, and " Your first legend class value should be 251, 501, 751"
I was applying a dose of the "traditional is old and useless" approach here. The difference between 250 and 251 isn't of paramount importance, in the context of an aggregated population statistic collected 5 years ago - the key point is that this suburb has more people than that suburb, and I wanted to avoid clutter on the legend. If people really care, the population pyramid allows them to see the exact values of total population and each population slice.
> The legend title is the field name? Use Aliases
That's a bug - an alias should be read from the JSON. I'll look into it - thanks
> I would move the enumeration unit type below the legend elements.
Good idea - thanks.
Thanks again for such a detailed review - stay tuned for the changes.
Cheers,
Steve





