Textshots: Rendering text selections as images when sharing.

There is a use case that I have seen all of Twitter which is that they use the service as a proxy for annotation. They do this by using a screenshot of a page + tweet (annotation). While this really shows people's want to annotate, there are a lot of downsides to that approach. Primarily, their annotation lives on only in their twitter archive - which means the conversation and feelings essentially die and are not given to the next wave of users viewing X content.

#### Here are some examples of people doing this on twitter:


They have good reasons for doing this, however. They are trying to use twitter as their delivery for annotation because they have huge investments in that service and they get immediate results and discovery of their work/annotation. This isn't unique to twitter but I think it's a great place to start - fb next.

So, the question comes up, how can we enable hypothesis to make this so streamlined that it becomes an essential tool for users who want to perform this action. Because performing this action via hypothesis keeps their work around in the hypothesis service (which has several benefits) and delivers the feature of talking with their following.

The flow they have today is:

- Highlight selection on website
- Screenshot
- Upload image to tweet
- Add tweet comment (the annotation)
- And very likely, go back to the website they were reading

When our users share an annotation today, the default value in the share message is the link directly to the annotation plus the string "#annotated". That annotation link is based on the actual uri of the current page which can mean a large portion of the tweet is taken up by that link.

So to get us closer to parity of how users seem to want to share, we can do a few things:

- Use the short link of an annotation because twitter ellipses long links anyway and we want room for annotation content. So use `https://hyp.is/Ex630O1NEeaWM_OnqRxssA/` vs `https://hyp.is/Ex630O1NEeaWM_OnqRxssA/dev.twitter.com/cards/types/summary-large-image`
- Update the bouncer service or via (whichever twitter actually hits at share-time) to have the twitter summary metadata links
- https://dev.twitter.com/cards/types/summary-large-image
- Add new service that can generate images based on text values passed in. (This is what should be referenced in the summary metadata above) How this mechanism should work is brought up below
- On share, if there is an annotation, make the first part of the share comment be the annotation. Or rather - as much of the annotation value that we can pass in (plus the link) that keeps it under the limits of the media outlet (< 140 characters for twitter).

Doing these things should allow us to get close to what users are actually doing themselves with that system. The theory is that this could bring new users into our ecosystem (because they get a twitter tool + h functionality) and encourage current users to share more because their content has richer information in the share and potentially more interactions because of the different style of tweet. That's the _hypothesis_

#### Approaches for the image service

Options for images "capture":

- Capture the screen of the selected area and store it - at annotation-time
- Complexity:
- _potentially_ could capture more than the user is expecting
- Getting the right area selected would take a good bit to get right. Like if the selection is large or spans large spaces or columns - this could be a challenge to get right.
- Would need to store in the database (either reference to image location or raw image data)
- We could only offer this service for annotations up to a week old and clear out older to keep data size low.
- It would be good to get into the data to see the age of posts shared to get this right.
- Pros:
- Works with pay-wall content
- Matches the style of the page exactly (not necessarily a critical need, however)

- Do a similar capture method as above but at share-time
- Complexity:
- Pay-walls will block
- You'd have to anchor and find selection again to get a good capture. Then you'd have to handle the same problems of getting the right content into the screen shot as mentioned above.
- Pros:
- Nothing to be stored in the database
- If you get it right, it will show the exact page content as selected

- Create a service that will generate an image.
- How this might work: We pass in the needed data like the quote. Then the service maps that to canvas or html and that is converted to an image and is returned from the endpoint.
- Complexity:
- Validation needed. Does the content in the image need to match the content exactly - or will users think this is off-putting? Something we can get user feedback on.
- Will only show the text that is ultimately passed to the service, but it does show much before or after
- Pros:
- No storing of data - Generated at share-time
- We control how the representation should be so we can mark up and prepare for edge cases more easily
- If we wanted to include the annotation in the image as well - we could and it would be the latest annotation value at share time

Given these options, I am inclined to say we go with option 3. Let's get something going that is pretty straight forward, learn from it and get user feedback. Since you don't get full context with the size of the image anyway, I think we can come up with something that emphasizes the quote and looks good. We can also try out a nice Hypothesis badge on it for branding.

Finally, for a truly superb social/Twitter experience, getting our mobile strategy up to par would also help take user engagement to the next level.