Thanks for this very good account of a real life scenario - and your thoughts on the larger issues surrounding 'simplicity' for library staff. It was hearing rumblings of similar stories that got me interested in the library context.
As you mentioned, it's a classic case of an evidently simpler, target-specific tool (LibGuides) weighed against an essentially more complex, general tool (Drupal). In general simpler means less flexible. I never use the word 'simple' in design discussions. It's not useful as a requirement. I use the word 'target' to refer to the specific usage context and the scenario you described does indeed suggest some clearly definable usability requirements. (I have a blog post about the 'simple' question here.)
I share your perspective about wanting Drupal to be both flexible and 'simple' for end users and I can see how it must be difficult to 'sell' Drupal to your clients because of its, shall we say, 'problematic' interface. Yes, it would be great to have a module (or several) to help address the library related target contexts. The really good thing about Drupal is the collective intelligence behind it as an Open Source product with modules being produced and shared all the time.
So if library specific modules were to be created then it should be based on taking in scenarios such as the one you've presented as a source of real usability and functional requirements. That's the fun stuff.
I'm very interested in finding out more specific details about this scenario. For example, I'm intrigued by the desire for a 'tabbed interface'. Do you know what it as was about tabs that would make tasks easier for these users? Actually, that question is premature. I really would want to know more about what the tasks were in general. If you or others are interested, perhaps we can work out a way to capture these details.
Once the usability requirements are established, then we could look at what it would take to produce some modules that would help people in your position 'sell' Drupal and in fact produce a powerful tool for your clients.
This work is licensed under a Creative Commons Attribution- NonCommercial- ShareAlike 2.5 License.
Thanks for this scenario
Mark,
Thanks for this very good account of a real life scenario - and your thoughts on the larger issues surrounding 'simplicity' for library staff. It was hearing rumblings of similar stories that got me interested in the library context.
As you mentioned, it's a classic case of an evidently simpler, target-specific tool (LibGuides) weighed against an essentially more complex, general tool (Drupal). In general simpler means less flexible. I never use the word 'simple' in design discussions. It's not useful as a requirement. I use the word 'target' to refer to the specific usage context and the scenario you described does indeed suggest some clearly definable usability requirements. (I have a blog post about the 'simple' question here.)
I share your perspective about wanting Drupal to be both flexible and 'simple' for end users and I can see how it must be difficult to 'sell' Drupal to your clients because of its, shall we say, 'problematic' interface. Yes, it would be great to have a module (or several) to help address the library related target contexts. The really good thing about Drupal is the collective intelligence behind it as an Open Source product with modules being produced and shared all the time.
So if library specific modules were to be created then it should be based on taking in scenarios such as the one you've presented as a source of real usability and functional requirements. That's the fun stuff.
I'm very interested in finding out more specific details about this scenario. For example, I'm intrigued by the desire for a 'tabbed interface'. Do you know what it as was about tabs that would make tasks easier for these users? Actually, that question is premature. I really would want to know more about what the tasks were in general. If you or others are interested, perhaps we can work out a way to capture these details.
Once the usability requirements are established, then we could look at what it would take to produce some modules that would help people in your position 'sell' Drupal and in fact produce a powerful tool for your clients.
Michael
Michael Baynger www.TheUserAdvocateGroup.com