Open JakeHartnell opened 10 years ago
UI and terminology reference: https://www.facebook.com/help/211513702214269
Referencing the social views notion recently closed here: https://github.com/hypothesis/h/issues/535 which is a key component of how an effective groups representation would be implemented. Here's the google doc overview.
Some provisional acceptance criteria in the form of user stories from our design meeting yesterday.
I would love to suggest the following modifications:
I'm basically pushing for a group implementation for the moment that basically has none of its own state. I'm a member so long as I'm subscribed. I'm not a member if I stop subscribing. But "membership" isn't a real "thing" and there's no way to list the members or moderate the members once you've shared the link.
So, when you say "name my group" I want to interpret that as anyone can alias the groups they're subscribed to, not that "groups" "have a" name.
Wondering if that's acceptable to everyone.
I'm basically pushing for a group implementation for the moment that basically has none of its own state. I'm a member so long as I'm subscribed. I'm not a member if I stop subscribing.
That's basically what the approach is. Leaving a group is unsubscribing. We still need to finalize the language around this, perhaps "unsubscribing" is better than "leaving?"
With regards to the second question, correct. When a "group" is created it is given an alias for reference. This alias will be displayed when posting to a group or toggling between groups in the extension. It is important that the group is created with an initial alias so that people can more easily tell what they are joining (and so that we don't have to add an extra step of aliasing a group to the group joining workflow), but I supposed it would be easy to support people being able to re-alias their groups later if we decide that is needed.
To clarify: this version of "groups" will be like you said, basically having none of it's own state. The person who creates the group will not have special administrator privileges, it will belong to everyone who has the link. There is no "my." We should use "the" instead.
+1 for this feature
Leaving a group is unsubscribing. We still need to finalize the language around this, perhaps "unsubscribing" is better than "leaving?"
:+1:
The more I read through this the more this sounds like AtomPub: http://www.atomenabled.org/developers/protocol/#collection
atom:link
reference they want and don't have to have <content>
(though it does require <title>
, but that can be auto generated--think "{user} on {page title} at {time}")AtomPub's also very RESTful in that it comes with no prescribed URL structure, so the collection feed can live any place and the entries another (as they're just atom:link
entries).
Regardless, it's on my "to explore" list: https://trello.com/c/Ta8SeCt8/6-atompub-for-annotation-api :smile_cat:
:+1:
There's a reason our API bootstraps from a link rel=service type=application/annotatorsvc+json. I was reading and was influenced by AtomPub, which uses type=application/atomsvc+xml for discovery.
Yeah, saw that! :smile: I'm happy to dig into this AtomPub exploration. It also dovetails nicely with W3C Annotation protocol exploration--as knowing how/if annotations could be shipped over existing feed systems (Atom being the one that potentially offers both read & write semantics) could bring things into reality just that much faster. :light_rail:
Hi guys If I can join the conversation. I just sent a paper to BigBlueHat suggesting the use of self-organisng groups for H. And here you are already on to it.
The idea of ownership of a group is one that needs further discussion. In my opinion there needs to be an owner because there are a some decisions to be made such as what are the criteria for membership of the group, who should be invited to join a group and who should be excluded if they no longer meet the group's criteria.
Some groups may want to accept requests for membership. For example someone wants to join a group of like-minded people. He sends a request to join to the group; there needs to be someone who accepts or declines membership after looking at annotations that the person has already made. The ownership must be able to be passed on if the current owner loses interest or is unable to continue.
In my opinion there needs to be an owner because there are a some decisions to be made such as what are the criteria for membership of the group, who should be invited to join a group and who should be excluded if they no longer meet the group's criteria.
@bridgespotter We understand the rationale and the need for the kind of group you're describing, and I personally agree. We'll go through this interim group mode because it's useful for many situations and because it gets us 90% of the functionality while keeping administration easy. We'll address criteria like those you suggest at another time.
@dwhly Is there anywhere I can read up on the current thoughts on what the final result for H will be. I have found the road map but don't know the destination. This is the bit that interests me. As I have said I have no idea about the technicalities in between. Also a glossary would be good as there are so many concepts that are being introduced that could easily be misinterpreted.
Is there anywhere I can read up on the current thoughts on what the final result for H will be.
There are a number of docs. This is a general written overview. There's also a UI study here for Ad-hoc groups and another one here that @aron did which covers the same themes
Thanks @dwhly There is a lot of great stuff there
Hi guys, I was looking for ways to do groups-collaborative-annotation online and stumbled across this after finding the Hypothesis plugin on wordpress.org. Great stuff.. +1 to this feature. Highlighting my particular requirement : A group ought to be able to present their annotations of a document / page. With other users' annotation absent from the view.
Highlighting my particular requirement : A group ought to be able to present their annotations of a document / page. With other users' annotation absent from the view.
We hear this a lot. Sharing a social view seems useful to us too.
Allow annotations to be made privately on a page between a group of people that have access to a shared link.
User stories
URLs: h/issue 495 Current documentation Mockups