kiosk split in modules

[urapadmin]

Moved here from "ideas and drafts for the recording system" in the wiki:

Do we want to split kiosk and the recording system into independently runnable modules?

It means, that one does not “buy” and use the whole enchilada, which might lead to scruples of all sorts, but instead uses single mouth-watering modules of the system (In the end one is supposed to want it all, of course). Such as the ceramic processing (something we could easily already modularize even in the filemaker frontend), a architectural phasing we don't have, yet, the publishing part, the image processing part (qr codes recognition, file import, file management) etc.

What modules would be interesting?

[urapadmin]

file repository as a first public module

Only filemaker and the synchronization system keeps us from offering a closed, working system to the public, currently. Apart from the general idea of modularizing our system, a first module could already be the file repository. New users would come to a public address, register as users and get the ability to create a file repository. They would upload photos to that file repository (and that is where it gets a bit unattractive, since that takes ages). They would be able to use QR-Code and exif-data recognition (but not recognition of patterns in filenames). They would use tags and archaeological contexts (but not table-contexts). They would be able to download, describe, delete etc. their images.
The immediate question arises: Who would pay for the server and the web-space, given that photos and photo-up- and downloading consumes considerable amounts of storage space and processing space.

A different approach could be to install our file-repository on a local machine (in which case we would need a setup at least for windows and for mac) to be used as a local solution for a single user.

[lbestock]

QR codes are repeatedly mentioned by people who encounter the system casually as the coolest part, and the file repository and my ability to find images is what makes people actually envious. But I don't really understand how QR codes would work in a module that doesn't have them generated by the recording system? Nor in fact do I understand how they would use archaeological contexts in a stand-alone file repository at all - right now the context has to exist before an image can be assigned to it, the assigning of the image can't create the context. I'm curious how you make that happen.

[urapadmin]

that was not the case at the time when I first wrote that idea into the wiki. Since then a lot happened and part of that is that the file repository relies on existing identifiers. The solution would be that there is no structured archaeological data behind the stand alone file repository. Just records with identifiers and photos attached to them. That is possible. I just don't see a real request for it so far :o) In the end what's the point in linking images to no records. Just finding them under a certain keyword is really a bit meager. Boring. Google gallery or apple gallery can do that.

[luizaogs]

Not super sure if this goes here, but I had this thought the other day and keep meaning to mention it somewhere and forgetting (let's blame my moping/raging about FedEx). Anyway, a friend of mine is leading discussions on archaeological methods this quarter in an archaeological methods class and was despairing the other day about how to lead an interesting discussion on recording contexts/survey methods, one that didn't simply rely on repeating content from Renfrew and Bahn. So: would it make any sense to have modules that can be downloaded for teaching purposes on recording methods, rather than only using the database to actually record stuff in the field? I'm sure Laurel already uses this in her methods class, but it struck me as something that might be of interest to others teaching methods, and I'm not sure if in that case downloading the entire recording system would be necessary.

[urapadmin]

that is at least a neat idea: Using our software to teach stratigraphy. I did not know that it is actually being taught :o) Right, Laurel?
How to support such a scenario is a different question. But I still think if kiosk were used in teaching it would in the end be more likely that it gets used on actual projects.

[luizaogs]

Well I don't know if it is being taught well :) But methods classes are some of the most boring things ever (though I didn't take Laurel's!) and I think using the software to actually simulate different scenarios would make them both more interesting and more useful.