vision
vision copied to clipboard
hypothesis
Groups Mockups
Allow annotations to be made privately on a page between a group of people that have access to a shared link.
User stories
- As a user, I would like to be able to quickly, privately annotate a page with people I know, just by sharing a link to it-- in the same way I’d use an etherpad for spontaneous collaboration.
- As a writer, I would like to invite an editor to provide feedback on a post, without that feedback being visible to everyone else.
- As a blogger and political activist, I would like to be able to link to my annotations, and to be able to share that link in my posts or on social media; so that people can click on the link and see my (and only my) commentary on the page.
URLs: h/issue 495 Current documentation Mockups
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.
- [x] As a user I want to be able to annotate a web page with others privately.
- [x] As a user I want to be able to invite others to the page via a link.
- [ ] As a user I want to be able to name the link I'm creating.
- [ ] As a user I want to be able to view a list of all groups I'm subscribed to.
- [x] As a user I want to be able to author an annotation under the page group i'm at, or privately or publicly. Annotations authored under a group should reflect that somewhere on the annotation card.
- [ ] As a user when I click a link I should be taken to the page, with H. injected. From there I can create an account if I don't already have one.
I would love to suggest the following modifications:
- Clarify "name my group". Mostly, what does "my" mean.
- Clarify "leave a group".
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.
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
- a collection is an Atom Feed--you can both publish to it and subscribe to it
- entry documents can have all the
atom:linkreference 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}") - semantics exist for categories, authors, contributors (feed & entry level), and (via the threading extension) further conversation threads
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
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.