The narrative paradigm and linear stories

[barbaracassani]

I just found this:

http://en.wikipedia.org/wiki/Narrative_paradigm

It's related only to some extent, but it made me think that the narrative paradigm might be the underlying reason why news on both traditional and digital media are usually presented in a linear plot fashion (e.g. this is how we eventually process them anyway). The point of view of the narrator is therefore "built-in" the report itself, closing effectively the door to any kind of deep ontological objectivity.

As builders who try to challenge the "guidedness" of information, we might still want to keep in mind that a linear narrative is probably more accessible.

Do you think it would make sense to group independent reports under a collaborative, wiki-style digest of the event? A pity that natural language analysis is still so challenged - it would be super cool to be able to create automatically such digest from the various reports.

[padolsey]

Nice topic for discussion!

Do you think it would make sense to group independent reports under a collaborative, wiki-style digest of the event?

Yes, absolutely. This is the intent of the "conglomerations" - http://concept.yip.io/static/Conglomeration.html

I definitely agree that we should provide something akin to a narrative of a single event. I guess the main questions are around how we collate similar reports into this singular digest/overview -- only including notable updates -- and ensuring that the reports are indeed related. It's mostly a technical challenge I think.

Fundamentally, I see the 'Conglomeration view' as being quite similar to the 'Report view' except that its updates are populated from multiple reports. In addition there is the possibility of the Conglomeration view containing various wiki-able fields, like title, summary etc. There could also be wiki/democratic processes for deciding what reports are included. Without this I imagine that reports would simply be included on a popularity/accuracy basis (as established by other means).

For this real-time collation of reports what would be the best name? 'Digest' suggests it's just a summary or abstract. Other options are 'Narrative', 'Overview', 'Collation', 'Conglomeration' ... thoughts?

[barbaracassani]

[barbaracassani]

This is how I see it - sometimes it's easier with a drawing. It's not (completely) a suggestion for the ux but more of a representation how what I think should be wikified / collaborative (we can call it the "story", maybe?).
It seems to be pretty identical, on the other hand, to the Conglomeration?

[padolsey]

Really love that sketch!

I think we're agreed -- we need some type of story/narrative/conglomeration for a single event. For now the core indicators of similarity include:

• Proximity in location
• Proximity in Time
• Title similarity (soft-matching + mild NLP?)
• Content similarity (soft-matching + mild NLP?)

Even with these there will probably be quite a few false positives, which is something we'd ideally avoid. I guess the Reports that make up a single Story/Conglomeration are wiki'able -- so a user with enough cred can 'vote out' a single report from a story if it's unrelated (or for other reasons potentially).

[barbaracassani]

Having accidentally deleted a long-winded comment I was about to post :-/, I'll retype only the gist of it.

Ideally we'd have two types of reports: the "pin" in the sketch above (linear narrative, supposedly objective, editable by anyone who is above a determined threshold of cred, one per event) and the "dot" (nonlinear narrative, intentionally subjective, non editable or editable only by the author, many per event). This would be ideal for consultation as it forms a nice user journey (I have a quick glance at the pin, decide that the topic interests me, I read the individual reports). The focus should be, I think, on the individual reports in order to avoid trivialising them by reproducing a blog-like post/comments structure.

But I cannot easily imagine the user journey for the reports themselves. Let's suppose I see something I want to report (I am going to use the usual exploding pavement, now nearly a Yip staff trope - apologies to everyone who was shocked or injured by an exploding pavement):

• I see the explosion. I open my mobile Yip App - I enter "sidewalk explosion" as title, leave location and time on autofill, go on to enter a description, I add some tags

Let's suppose I am the first to have done so for this particular event. What my report will be? A pin? A dot? Shall I be given the option to choose between the two?

And now someone else comes and reports about the same event. Shall the interface, after the second report has submitted, suggest something like "we have already report titled "sidewalk explosion", is it a report about the same event you have reported about?". Or will it aggregate them silently on the basis of similitude, giving the successive user(s) the possibility to mark a preexisting report as "non related to the topic"?

It all seems to me a bit... cumbersome. Maybe we should let the users create only the dots, and when sufficient dots have accumulated in one space/time area, create automagically a stub of the pin by just grabbing one title/description among the existing reports, and make that wiki-editable. Not sure. Any thought? Am I off the mark with this pin / dot distinction?

[padolsey]

Or will it aggregate them silently on the basis of similitude, giving the successive user(s) the possibility to mark a preexisting report as "non related to the topic"?

Yes, this makes sense. Although I imagine any manual work that user has to do to establish "is X report and Y report of the same event?" should be minimal -- we should seek to do as much as we can automatically.

It all seems to me a bit... cumbersome. Maybe we should let the users create only the dots, and when sufficient dots have accumulated in one space/time area, create automagically a stub of the pin by just grabbing one title/description among the existing reports, and make that wiki-editable. Not sure. Any thought? Am I off the mark with this pin / dot distinction?

I am not sure the concept of dots & pins helps to simplify much here. But the idea of a 'stub' automagically being created is/was the original idea of the conglomeration and IMHO makes good sense.

[barbaracassani]

Ok, I think I get it. I have now a clearer idea on how it should work. I am going to produce later an uml diagram (or, more likely, a simple sketch) to ensure everything is clear.