A few thoughts on the LibLab planning process
2 views
Skip to first unread message
Nate Hill
Jul 31, 2011, 1:32:23 PM7/31/11
to lib...@googlegroups.com
Just a few notes on this LibLab planning process, largely of interest to the new folks who just got on the list.
note 1: we need a better name! help!
other notes:
To be clear, the point of this LibLab project is to create a set of design patterns, not a finished architecture of any sort. I know that I operate best in the tangible, visual world, so this is something I struggle with as I contribute to our collective vision. We’ve broken the LibLab down into activities and use cases that support the production of collaborative knowledge, so that they can repurposed and rebuilt in different ways for different user needs and with different partners. So an activity might be as simple as ‘scanning station’, but the pod or module that is built around this activity would vary depending on the use case. One scanning use case might be bulk scanning and OCR of books, uploading the results to wikisource via bot as described on our wiki. Another use case for a scan station could be entirely different. Sam said quite eloquently in an email, “design patterns include physical specs, patterns of use over time, and visualizations patterns are associated with an activity or capacity. use cases are past, current, or future projects.”
I’m pointing this out (and reiterating it for some), because we want to be careful not to design the components for collaborative knowledge production into a box too soon. It’s a natural tendency to think, “OK, we’ve got this space, let’s do some very specific things in that space”. Instead, what we are assembling at DCPL is more of an exhibition of design patterns. Some will feature interactive elements and deliberate partnerships that bring these stations to life, but largely our goal is to create a framework for replicating these activities in very different ways for the many different communities that might see LibLabs (or whatever we choose to call them) across the country. This keeps us out of the awkward position of trying to tell any library or other space how they ought to assemble a LibLab, instead, we are building a conceptual framework and a set of design patterns that they can use to support and inform their decision making.
On Wednesday I’ll join the folks up at Noll & Tam for a design charrette and we’ll end up with some more complete explanations for everyone to react to. Stay tuned, and again thanks to all of the new folks who just joined this list, your input and collective experience is going to be key to doing this well.
Cheers!
Nate
note 1: we need a better name! help!
other notes:
To be clear, the point of this LibLab project is to create a set of design patterns, not a finished architecture of any sort. I know that I operate best in the tangible, visual world, so this is something I struggle with as I contribute to our collective vision. We’ve broken the LibLab down into activities and use cases that support the production of collaborative knowledge, so that they can repurposed and rebuilt in different ways for different user needs and with different partners. So an activity might be as simple as ‘scanning station’, but the pod or module that is built around this activity would vary depending on the use case. One scanning use case might be bulk scanning and OCR of books, uploading the results to wikisource via bot as described on our wiki. Another use case for a scan station could be entirely different. Sam said quite eloquently in an email, “design patterns include physical specs, patterns of use over time, and visualizations patterns are associated with an activity or capacity. use cases are past, current, or future projects.”
I’m pointing this out (and reiterating it for some), because we want to be careful not to design the components for collaborative knowledge production into a box too soon. It’s a natural tendency to think, “OK, we’ve got this space, let’s do some very specific things in that space”. Instead, what we are assembling at DCPL is more of an exhibition of design patterns. Some will feature interactive elements and deliberate partnerships that bring these stations to life, but largely our goal is to create a framework for replicating these activities in very different ways for the many different communities that might see LibLabs (or whatever we choose to call them) across the country. This keeps us out of the awkward position of trying to tell any library or other space how they ought to assemble a LibLab, instead, we are building a conceptual framework and a set of design patterns that they can use to support and inform their decision making.
On Wednesday I’ll join the folks up at Noll & Tam for a design charrette and we’ll end up with some more complete explanations for everyone to react to. Stay tuned, and again thanks to all of the new folks who just joined this list, your input and collective experience is going to be key to doing this well.
Cheers!
Nate
--
Nate Hill
nathan...@gmail.com
http://www.natehill.net
Reply all
Reply to author
Forward
0 new messages