I seem to use the word “drupalism” in a pejorative way. Usually, to to describe anything that follows one of these drupaly anti-patterns:
- The belief that one should hide settings at least 4 clicks away from wherever those settings matter. "That's where settings go.", so the argument runs.
- A purpose-agnostic interface element that receives “whatever” from other modules (think hook_links,, and the barf it spits out….)
- The belief that verbose help text fixes a poorly thought out interface, or form item heading.
- The belief that one needs to have a usability study -- as opposed to good taste, or common sense -- to backup decisions related to usability.
- Having form help text for the sake of having form help text (see the helptext on ./user/login.... if you don't chuckle, you lose help text writing privileges.
- A drupal hook that gets passed all of the following: a) a giant object, or array (by reference), b) an $op variable that has more than 5 possible values, c) usually several other arbitrary variables that change depending on the value of $op. hook_nodeapi, hook_user, hook_comment are the most obvious examples.
I've never seen the word “drupalism” used to describe a good thing. But, as I've argued time and again, I'm an idiot, and a fool -- perhaps even stoopid.
Comments
Ahh, that is what I was looking for
In your post you didn't mention the fact that putting in a little thought into the design of a UI goes a far way. Which I think is a very important point that should have been made, as that's really the issue. That people don't put enough thought in the design process. I totally agree design goes a far way and will avoid a lot of usability study work.
I am not sure why your ghetto testing strategy is any different from what I perceive as a usability test. The idea that a formal study is the only way to go, has long past. That's where the whole idea of discount usability testing originated from, of testing a lot and cheaply in a informal way. If you need $5000+ to do simple testing which requires a lot of your resources, it should make sense that the people you are approaching can't work within your context. The whole lab, is only a necessary if your looking for specific information that can be addressed by eye-tracking equipment, but for most of the information you're looking for it is useless. (To mention that stakeholders and developers love flying balls)
The last years the whole usability profession has moved from quantitative studies, towards doing a lot of small qualitative studies and getting those to be quantitative (It just takes some time for everyone to forget about 1 way mirrors and expensive equipment). I think formal studies still have their place, but in Drupal we need a more suited type of testing. Usability testing should save you resources/time as you wont have to argue endlessly(Drupal?) and you wont have to redo things at the end.
4. Usability Tests
There seems to be an attitude in the community that these tests are 'scientific' and conducted by 'experts' so they shouldn't be criticised by mere developers, and if you do you're against usability - we critique everything else that affects core, and we should take the same approach with usability tests.
Usability tests and surveys can be extremely useful in discovering problems we may not have considered, but we need to be aware that they are inherently flawed - testing behaviour or opinion affects what is being tested. The question is not if the tests are flawed, they always are, what's important is to what degree they are flawed and how much of the data is invalidated/relevant. This is where debate and common sense needs to be applied.
drupalism
Haven't encountered this term, but it sounds like an excellent candidate for the quirks you've listed. All are true, and funny, I find #4 especially funny.
Is this really Drupal specific?
3. Since the existence of documentation, they have always been used to explain poorly designed interfaces.
4. I disagree with this, of course you can use good taste and common sense but that always comes from something. And this past experience differs a lot from person to person, so in order to agree on something you need something viable to support your decision. We are not the culture Apple has, that is mostly based on really good taste (Apple is actually closing down some of it's usability facilities and had quite some usability issues in new products such as Ilife). Programmers still make most of the calls on design.
I think its completely unrealistic to expect issue ques to evolve around common sense and good taste, as much as we understand this is just as much part of usability as the testing itself -- you know opinion wars can only be decided by one thing.
Not sure if you have attended many usability studies, but no matter how good your taste is some behaviours really don't make sense. Even the best designers use usability studies, not to convince their peers but because they are still surprised a lot when they see someone actually use the interface
5. Please, go work in the user interface text issue ques, I think most of us know there is way to much text. But no one cares enough to acctually work on it, since its hard. Everyone loves to rant about it, but it's really not as simple as you expect. There is always a tendency to add more text, which is something deeply embedded in a programmers mind I guess.
I am surprised I took the effort to register, enable anonymous comments please :)
Not trying to discourage
Not trying to discourage usability studies. I'm just pointing out that you can make something quite usable by putting a little thought into it.
I've only once had the pleasure of spending several hours sitting behind a mirror watching a usability test. To be honest, I wasn't thrilled with the results, given the time and resources it took... Within about 4 tests, the "hotspots" that really needed to be fixed became obvious. This experience didn't convince me tests were worthless, but that cost vs return of formal testing discourages it from occurring frequently enough. Now if I had tons of money and time, I'd go the formal route in a hardbeat. However, I've had to suffice for a more ghetto testing strategy:
1. I buy a few acquaintances at a coffee shop a beer, in exchange for about 5 to 10 minutes.
2. I ask them some basic questions about a page, and ask them to complete a couple tasks.
3. Make notes on when their face indicates any sort of confusion, or frustration. Where they get hung up, etc...
Its not perfect, but its a lot better than not testing it all... and its low cost enough that I could easily do it for work that I'm not getting paid for...
The recent blog post by a
The recent blog post by a Google designer reminded me of this Drupal discussion and Drupal's design conundrum - http://stopdesign.com/archive/2009/03/20/goodbye-google.html:
"Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions.
Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle."
Post new comment