In an effort to get to know better the needs of developers are from the Human Interface Guidelines, I solicited several groups of developers to participate in a survey which ran for two weeks in May. The outcome was very good with 52 participants providing their comments and suggestions.
After reviewing the results and compiling them in to a report I think several things are safe to assume about developer's relationship with the HIG:
- They don't trust it.
- They don't trust us.
- They expect more from it.
- They didn't know it existed.
- They might actually use it.
They don't trust it. The old guidelines are just that -- old. Being out of date and inaccurate are strong reasons why developers might not use them. Being incomplete also raised some questions in their validity.
They don't trust us. Some of them flat out said they didn't trust them (and those who write them) and won't until they see some theory behind the claims. Trust in the usability community has always an issue. Theory is fine and dandy, but misunderstood or out of context its useless. Just because you don't like it or don't understand it shouldn't be grounds for creating inconsistent interfaces. If you really feel that strongly against that particular guideline, there are better ways to change them than ignoring them.
They expect more from it. The quality and quantity of the guidelines are an issue. There isn't enough there and what is there is dated and old. If the HIG is to be a definitive guide then it needs to be current and updated frequently. Important issues need to be added in order for them to be referenced, there were many comments of fruitless searches because content was missing.
They didn't know it existed. Apparently it isn't very easy to find the guidelines because many of the participants didn't know they existed, or had looked for them and never found them. Along with a community-wide effort to promot the guidelines, it has to be more easily accessible.
They might actually use it. No one was really against having guidelines, infact many were optimistic they would use it if it met their explicit demands. If we can solve the Q&Q (quality and quantity) problem which is present in the existing guidelines, I'm optimistic the new guidelines will be happily adopted.
What you've been waiting for: KDE4 HIG Developers Survey Results (PDF 601KB)
Syndicate Blogs
Excellent work
This is very interesting reading. Great job on doing this work. I have to say I am somewhat surprised by some of the results -- I thought that the existing style guide was well known amongst all KDE developers. I'd love to know how this could be better advertised to new developers.
"Don't Repeat Yourself"
Perhaps on the minds of many developers is the DRY principle. They see a HIG (at least in part) as another, redundant definition of a user interface that is already defined in some programming language. (A similar impediment to proper usage and maintenance of other types of project documentation.) A big leap forward in the adoption of such guidelines is for them to become authoritative components of the development process. The HIG should not only be human-friendly, it should be machine-translatable into the final product. Of course, this may all be a pipe dream; there is little adoption of technologies which turn functional specifications into an end-product. Fortunately, more languages are supporting code annotations, and advances in natural language development will help move us in this direction.