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/
>