 |
 |
Hi Tom, It's nice to see Suma discussed on this thread, and I do think that it is a pretty nice tool for collecting, managing, and analyzing a variety of transactional and observational use data. We're using it at NCSU to collect a fairly wide range of data, including head counts, service desk transactions, roaming service, technology lending issues, and detailed space usage for new or experimental spaces. I wanted to respond specifically to two of the requirements you listed with a brief explanation of our design decisions. 1) Chair-level data A central goal of Suma from a very early point in the project has been to support frequent, long-running, and (optionally) mobile data collection initiatives with stable, simple, and reusable tools for collection, management, and analysis of this data. In our conversations about highly granular data like chair usage, several conflicts with Suma's priorities of simplicity and flexibility were identified. First, this kind of data can be very brittle. Even minor changes to furniture layouts can introduce a serious disruption to long-term data. For example, if you decide to change out the chairs at a table with a new style, are those the same chairs that were counted earlier, or are these new chairs? Or if you add a chair to a table, or push two tables together, which chairs are new and which are old? How do you encode that information? How often do you need to update the collection interface? Second, we felt it would be much more difficult to design simple but sophisticated reusable data visualization and analysis tools with geographic data (say, the specific location coordinate of a chair) and, in order to provide more than a floor plan heat map, we would need to map these coordinates to regions, and those regions to larger regions, etc., which would quickly obscure the chair-level data. Finally, when we collected examples of questions that people would like to ask of the data, the tools to answer them rarely required chair-level usage information. We decided to represent locations as a hierarchy where a data collector just drills down to the most relevant location label. This isn't to say that Suma couldn't support very specific regions. In a couple of cases where we have particularly specific questions about space use, we do break down spaces into detailed regions such as "lockers" or "soft seating." It would be pretty difficult to collect chair-level data in Suma, though. I do also recognize that there are cases where chair-level data is critical. There are proprietary tools used by interior design and architecture firms to support these activities, and our Building Services department uses PlanGrid for tracking issues on a floor plan using an iOS device, but we have focused more on regional data in Suma so far. There are probably some other options out there that I've missed. 2) Floor plan interface This was a big part of our early design discussions. Like many libraries, our earlier usage data collection methods were quite varied, and included a variety of paper forms (to later be entered into spreadsheets) and sometimes paper floor plans with seat-level pencil marks. While we felt that seat-level or coordinate data generally could not justify its cost for the reasons described above, the ability to select a regional location using a floor plan would definitely be convenient and may improve data consistency in ambiguous connective spaces. In this case, our decision was really driven by technical expediency and open-source community support. Providing a floor plan interface would require the development of a system for managing and coding floor plan images (we could probably use OpenLayers for part of this), which would have slowed our initial development and created hurdles for deployments to new locations. We have always maintained, though, that this kind of interface could be developed for Suma if it were compatible with our location hierarchies (and, of course, pull requests are always welcome). In two years of heavy internal use, though, we have found that the text-based location hierarchies require only a small amount of training in order to ensure consistent use. If you do think that you might want to try out Suma, just drop me a line and I can show you around a live demo. Also, I can't resist joining in on the seat usage spitballing. I saw a presentation once that described an NFC-based seat reservation system at a Korean library. Something like this might help answer questions about furniture preferences based on academic affiliation:-) Thanks, Jason On Thu, Aug 15, 2013 at 7:49 PM, Thomas Misilo <[log in to unmask]> wrote: > Thank you all for the suggestions. I guess I should be a little more > specific. I am looking for something that can be loaded up on a tablet > (ipad and/or nexus 7), and have the laylout of the floor + chairs and > tables. > > We are wanting to track usage of specific carrels and tables in different > locations on the floor. To determine if they are in a good place or if they > need to be repositioned or repurposed. > > Thanks again! > s > Tom > > > > -----Original Message----- > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > > stuart yeates > > Sent: Thursday, August 15, 2013 6:43 PM > > To: [log in to unmask] > > Subject: Re: [CODE4LIB] Way to record usage of tables/rooms/chairs in > > Library > > > > Many buildings have IR sensors already installed for burglar alarms / > fire > > detection. If you can get a read-only feed from that system you may be > able > > to piggyback. > > > > Of course, these kinds of sensors are tripped by staff making regular > rounds > > of all spaces and similar non-patron activity. > > > > cheers > > stuart > > > > On 16/08/13 06:33, Brian Feifarek wrote: > > > Motion sensors might be the ticket. For example, > > > https://www.sparkfun.com/products/8630 > > > > > > Brian > > > ----- Original Message ----- > > > From: "Andreas Orphanides" <[log in to unmask]> > > > To: [log in to unmask] > > > Sent: Thursday, August 15, 2013 11:12:02 AM > > > Subject: Re: [CODE4LIB] Way to record usage of tables/rooms/chairs in > > > Library > > > > > > Oh, that's a much better idea than light sensors. One challenge with > > > that might be difficulty in determining what "vacant" looks like > > > authoritatively, especially if people move chairs, walk through room, > etc. > > > But much more accessible than actually bolting stuff to the table, I > > > would think. > > > > > > On Thu, Aug 15, 2013 at 1:03 PM, Schwartz, Raymond > > <[log in to unmask]>wrote: > > > > > >> Hey Dre, Perhaps a video camera with some OpenCV? > > >> > > >> -----Original Message----- > > >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf > > >> Of Andreas Orphanides > > >> Sent: Thursday, August 15, 2013 8:55 AM > > >> To: [log in to unmask] > > >> Subject: Re: [CODE4LIB] Way to record usage of tables/rooms/chairs in > > >> Library > > >> > > >> If I were feeling really ambitious -- and fair warning, I'm a big > > >> believer that any solution worth engineering is worth > > >> over-engineering -- I'd come up with something involving light > > >> sensors (a la a gate counter) mounted on the table legs, just above > > >> seat height. Throw in some something something Arduino or Raspberry > > Pi, and Bob's your uncle. > > >> > > >> I find myself more intimidated by the practicality of maintaining > > >> such a system (batteries, cord management etc) than about the > > >> practicality of this implementation, actually. > > >> > > >> -dre. > > >> > > >> On Wed, Aug 14, 2013 at 7:59 PM, Thomas Misilo <[log in to unmask]> > > wrote: > > >> > > >>> Hi, > > >>> > > >>> I was wondering if anyone has been asked before to come up with a > > >>> way to record usage of tables. > > >>> > > >>> The ideal solution would be a web app, that we can create floor > > >>> plans with where all the tables/chairs are and select the "reporting > > >>> time", say 9PM at night. Go around the library and select all the > > >>> seats/tables/rooms that are currently being used/occupied for > > >> statistical data. > > >>> > > >>> We would be wanting to go around probably multiple times a day. > > >>> > > >>> The current solution I have seen is a pen and paper task, and then > > >>> someone will have to manually put the data into a spreadsheet for > > >> analysis. > > >>> > > >>> Thanks! > > >>> > > >>> Tom > > >>> > > >> > > > > > > > > > -- > > Stuart Yeates > > Library Technology Services http://www.victoria.ac.nz/library/ >