Thanks for your thoughts!
yep yep yep yep yep
I agree that these are pretty much a sine qua non. Also, we need to be handled content in these data types in a way that isn’t just “plain text”, but can handle structured representations of linguistic units, alignment, etc. Otherwise we may as well just be using existing tools like Zoom, Facebook chat, Dropbox, etc. (Not that those aren’t useful tools in many cases.)
I came up with the list below as a sort of “umbrella list” of … well, “aspects” of what we’d need to think about?
(Silly emoji symbols for fun, alternative suggestions welcome ):
Media types (in increasing order of difficulty)
Offline (actually I think this is worth thinking about, even just as a foil to the fully collaborative, networked, blue-sky scenario)
Linguistic data types
Texts (in the sense of a narrative, a conversation, whatever other genre)
“Sentences” (interlinearized “segments”… IGTs… whatever you want to call them!)
Paradigms (paradigm… pair o’ socks… HAHA. Ehem.)
The last category, linguistic data types, is pretty much in line with what I’m trying to implement in the software library I’m writing about in my dissertation (it’s called
Let’s think interface
These are all worthy areas to keep in mind. Each has its own technical expertise requirements: actually implementing these (connectivity, versioning, etc) in turn requires skill development, testing, etc.
But let’s just imagine that these things magically work. What does the actual user interface look like? What are the buttons? What are the boxes? Where do the video player and the record button and so forth live on the screen?
I think this kind of “participatory design” is a great way to start, actually.
It reminds me of an issue that came up in @ldg’s paper on “Developing without developers” (PDF): the exercise there was to reimplement ELAN on the web by cloning the interface quite precisely. The fidelity is quite amazing:
Here’s the quote about why cloning ELAN was chosen as the task:
Choosing an ex-isting app obviated the design process, saving timeand eliminating a potential confound. ELAN waschosen in particular because of its widespread usein many areas of linguistics, including LD, and because its user interface and underlying data structures are complicated. We reasoned that if our approach were to succeed in this relatively hard case,we could be fairly certain it could succeed in easier ones, as well.
ELAN is certainly a complicated interface, and the web port is an amazing achievement. But ELAN has evolved to do what it does over a very long process of development. The key fact to my mind is that process had a starting point — an initial idea — that only included some of the tasks that documentary linguists & colleagues are concerned with (namely, media/transcription alignment). Other things have been added incrementally, but I think that if ELAN were redesigned from scratch it would have not just different capabilities, it would have a very different interface.
That’s where I’d like to gently nudge this conversation… we have know what the ingredients are, but what does the cake look like, even if we don’t have a recipe?
(I just appended the title of this topic to include user interface to emphasize this… might be a record for longest title! )