Blogger, Pink means Pink!: Problem Solving Google Blogger Text Colors

Awesome, Inc. template

In this post I try to change the text colors on my Google Blogger blog, and found a world of trouble and frustration.

By the time I finished this post I had uncovered several bugs. This is really long post, so I have decided to try create an itemized list of bugs up front with links to the part of the post in which I identify that bug. This doesn't work perfectly because I don't want to change the narrative flow and divide the text into sections by bug, but hopefully it helps. You can use these bug numbers later when you tell me my bug is spot on, not universal, completely wrong, or later fixed (Yay!).

Bug List

Possible bug titles for the bugs I discovered:

• Sidebar and footer background color choices not set correctly (BloggerTemplateDesigner_Bug1)
• Gadgets on sidebar don't use background color option setting (BloggerTemplateDesigner_Bug2)
• Some UI elements not visually marked on the preview when selected in the list (BloggerTemplateDesigner_Bug3)
• UI element list in "Advanced" tab order is confusing order and should be grouped by location on layout (BloggerTemplateDesigner_Bug4)
• Default template designs should have minimum text contrast requirements (BloggerTemplateDesigner_Bug5)
• Can't edit text or background of date tab on posts (BloggerTemplateDesigner_Bug6)

Feature Requests

Besides the bugs listed above, my biggest complaint is that it took so long to figure out the correspondence between UI elements on the list and UI elements in the preview. If my BloggerTemplateDesigner_Bug4 is fixed that would help. As a feature request, I would like to be able to select items in the preview and have the relevant item in the UI list be selected.

Exploring Blogger Text Colors

I just started this blog and didn't want to spend a lot of initial time worrying about the layout, so I chose one of the default layouts based on the "Awesome Inc." template and figured I'd worry about the details later.

However, there were a few details I decided couldn't wait.

Exploring, Problem Solving, and Looking for Trouble

Here I discuss briefly the kinds of testing I plan on doing for this blog and ones you could not pay me enough to do.

Exploring

A type of testing that is often ignored is what I think of as "exploring": watching what happens when the user explores an application for the first time and tries to figure out what it does and if they can do things with it that they will find useful. There are hundreds if not thousands of free apps available out there for people to wade through. Many users will download an application and try to use it and make a decision about whether to keep it in a very short period of time. In general, the more that a person knows about an application the worse they are at figuring out what will confuse or frustrate a new user. If you are creating an application you should solicit user feedback as early as possible (especially to make sure you are building the right thing in the first place) and look at a broad range of users. (And when you think your UI is pretty good, hand it over to a family member who didn't have a computer until they were an adult and tends to get annoyed rather than excited by new technology. I think most software engineers would find that a real eye-opener.)

Some companies do a reasonable job of usability testing; they want to know how easy the software is to use. However, usability testing I have seen often involves giving the user a specific set of tasks to perform and seeing where they get into trouble. At a minimum you need to have at least some beginning users and some more experienced users. (If you are lucky the customers talk out loud while they are doing this so you can learn more about what they are trying to do or expecting to see.) I have done this type of testing once for a college course and seen the results from one such study at Microsoft that was really fascinating. I wish more companies did this, especially in the early stages of the design process when the companies are capable of making significant changes based on the feedback they get from customers.

(Aside: If you have never worked in software you are probably thinking, "Why would anyone spend money to do usability testing if they weren't going to use the results to improve the UI (at least not any time soon)?" I will just say that that is a very good question. A friend once said to me something along the lines of, "Only people who don't work in software think that the things that happen in the Dilbert comic are ridiculous, and could never happen," which I think is very apt. Topic: The posting of Dilbert comics at software development companies as a form of passive-aggressive behavior: discuss!)