-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Anatomy of a report #3
Comments
I plan on adding a draft to this repo (probably in (all imho)
The original reporter will/should be highlighted in some way. When the list of collaborators starts to grow I imagine the significance lended to any single author to diminish -- i.e. to not be such a large part of the UI.
I imagine any information about the diffusion of the report itself will be in a separate interface/section of the report. The actual location of the event should be primary.
Yes, some events will have a planned end-time. Others will be open-ended.
Do you mean for sub-events? I've played with the idea of having an event within an event. This is mentioned briefly in the Glastonbury case study [not yet finishied]. So, as part of a developing emergent event, there may be something else that happens as a result of or within the scope of that initial event. For this we could take advantage of three different types of relationships that events can share:
I imagine some events may be more complex than what is accommodated by these relationships though. We'll need to keep developing the case studies to expose such things...
Honestly I'm not sold on such UI sugar. I think there will need to be a way to define relationships between events though. |
Some reflections in no particular order:
|
So, the question(s) that Yip will be answering is "What's happening?", "What happened?" but the most basic atom of "happening" - the single report, sub-event, event - can be read as incidental to his surroundings, on the various different plans:
I think that the "relationships" you describe might be a very important focus in guiding the architecture and the UI - in fact, this is the very core of the project imho. |
Adding to the laundry list:
|
RE: Tagging / Classification / Categories
It's an interesting point you raise. I think it needs to be solved, but I don't think categories would serve it well. We can have other classification means though. Maybe user-curated lists (like you have on Twitter)? Tagging can be very powerful too. Enough tags and the search mechanism will be very powerful. I could do a search like:
The TextSearch would look through tags (weighted highly), description text, title text (also weighted highly) etc. I imagine if the events are well titled, well described, and have ample tags, then we won't need to worry. IMHO straight-up exclusive categories seem very limiting. |
The purpose of an application might be planned by its author, but at the end, I believe, the users will run away with it (ideally) and it will be the "feel" of the application, its UI, how it positions itself relatively to the user (i.e. virtuous and with a high entry barrier like wikipedia, or playful and accessible like Foursquare) than will determine its diffusion and the way it's lived day by day.
I think it might add to the discussion to explore some of the choices that Yip will unavoidably have to make in order to achieve a brick and mortar (in the internet sense!) existence. There are many but for the moment being I'd like to focus on the anatomy of a report. It might be useful for everyone involved to get an idea of what it will all be about.
Prescriptive vs freeform:
Which elements will form a report?
I am posting this laundry list only to spark a debate. I am willing to contribute my own opinions to the discussion - I favour immediateness over completeness, broadly speaking. But others might disagree and even if they agree, the way in which such principle applies to the various choices I've listed it's certainly widely arguable.
The text was updated successfully, but these errors were encountered: