Sorting Data Types in a Participatory Design Project

Hi all,

I spent the day gathering various types of data I have collected for a research project where I am studying the artifacts from a class that used participatory design to create restorative environments on our campus. I am charting these various items out in map view so that I’ll be able to have a single place to not forget all the sorts data I might reference/dig into. Nothing fancy to see here, but I imagine it’ll be very helpful as time goes on. I also made notes on a few of the items. For example, in the attendance cards, I have a list of all the prompts I used for each class.

6 Likes

I haven’t used images much in maps but would like to – do you have any tips regarding file sizes/resolutions to keep things manageable? Thanks in advance.

1 Like

I would also appreciate any hints here. Great work BTW. Hope the project is going well.

Hi Marc and Patrick,

The file’s big (142 MB), but it serves my purposes as a reference. It’s a little slow moving around. Because of this, I’m keeping it as its own TBX and doing analysis and other things in other TBX’s.

Beck

Marc, my experience of using images is that the TBX balloons and the performance slows in one regard specifically, saving takes much longer. It goes, in my case, using an internal SSD, from immediate/transparent to several seconds–enough that one notices. In my case, I wait to keep on going. Compressing images does not help, only downsampling, i.e. using fewer pixels. I see this behaviour beginning around 90MB file size.

Writing a Tinderbox file (or any other file) is, at best, proportional to size. Simply writing a 100MB file to a SSD is going to take about 200ms.

Encoding those images is likely to take longer, though we now do the images in parallel on different cores.

Using fewer pixels is indeed a good thing.

I’m not really sure how to interpret your remark. I’m sure you’re right that by the time the bits reach the low level drivers the file writing will vary proportionally with size.

Nonetheless, in an experience that has been repeated dozens of times a day, when I save a large file in Tinderbox, the cursor changes and shows activity in progress for several seconds, not 200ms.

From the perspective of a user speaking to a vendor/author of the software, the practical import is that I do not continue to use large Tinderbox files. I “thin” them by removing the graphics after I think they have served their purpose.

Partially I find the delay slightly bothersome. Partially I get the heebeejeebees whenever files take a long time to save because I think there is a larger window for something to go wrong. Probably this is an irrational hangover from using computers when storage was slower.

My points were

(a) the floor — the absolute minimum time to save 100MB on a fast hard disk under the most favorable conditions — is (back of the envelope) 200ms. That’s not a long time, perhaps, but it’s perceptible,

(b) for large files, the save time will scale about linearly with the size of the file.

© for files with lots of large images, the save time will be dominated by the time needed to encode the image. If (as is often the case) you have a few images, Tinderbox encodes several images at the same time and so does better than you’d expect.

(d) Big images give you relatively little advantage in Tinderbox. Agents can’t do much with them. Attribute browser can’t really do much with them. A few big images — image references for your story’s main characters, the floor plan for the event you’re planning — will do no harm.

1 Like

Thank you, I understand now.