enjalot / tributary

rapid prototyping with d3.js
http://tributary.io
Other
598 stars 70 forks source link

Getting notified of forks via twitter #115

Open georules opened 10 years ago

georules commented 10 years ago

I thought I'd toy with the twitter notification idea we chatted about in the hangout yesterday. This is a branch extending from the v1 branch: https://github.com/georules/tributary/tree/twitter

I mocked up a little code to send a tweet https://github.com/georules/tributary/blob/twitter/server.js#L99 in after_fork. https://github.com/georules/tributary/blob/twitter/server.js#L398

The twitter account that has an application associated with it will tweet something like this:

screen shot 2013-12-21 at 5 47 06 pm

This currently uses the github user.login.

I really wanted to use https://dev.twitter.com/docs/api/1.1/post/statuses/update_with_media to put the thumbnail (if exists) inline with the tweet on twitter. Which is why I started to setup some code to perform different actions depending on what data I have after_fork. However, the API for this requires that you upload the image data to twitter. You cannot just provide a URL afaik, but this makes me wonder how youtube links showing the "show media" link works. https://dev.twitter.com/discussions/5735 I thought about downloading the image from imgur and then posting it over to twitter. I decided it would be better to just bring it up and see what you all think.

I assume that "anon" will work if you are not logged in, but "Save" never completes for me on my localhost (it does work on tributary.io) when I am not logged in. I might just be derping here though.

This current rendition requires a package and some settings: https://github.com/ttezel/twit https://github.com/georules/tributary/blob/twitter/package.json#L41 https://github.com/georules/tributary/blob/twitter/example-settings.js#L17

Throwing this out there for ideas, thoughts, improvements.

enjalot commented 10 years ago

Nice! we could send the image data to twitter, we are just sending it to imgur now cuz that was easiest at the time. We will probably still want to send both, but I think the fork hanging on dev is because imgur doesn't return properly. I think that code needs to be refactored so that the flow for forking doesn't interupt your code being shared and link being made. perhaps doing stuff async and not forcing a new page load on fork would be best.

we could also add a button for sharing which we've talked about before, or some way to expose the share link for a particular tributary (right now people have to think to use the url bar, but we can make it more convenient.

georules commented 10 years ago

Images are uploaded from the client to /imgur/upload/thumbnail at a different time than /tributary/fork (when we want to make the tweet for a fork), and the image data is forgotten, since we pass it to imgur and later just reference the URL saved in the gist's config.json. I don't think the image is uploaded from the client again on a fork.

Maybe a share button makes more sense though, and could upload the image at that time as well. Someone might not want a fork to be announced publically.

I'll look into the imgur return for dev. I agree with figuring out a better way for forks to be handled without page reloads would be good.

enjalot commented 10 years ago

Yeah, thanks for looking into it. I hope you see a more straightforward way to decouple screenshots from saving/forking/sharing but still allow us to give the options to do any of those.

Perhaps explicitly calling out sharing is the best ux, perhaps it isn't :) On Dec 21, 2013 9:15 PM, "Geoffery Miller" notifications@github.com wrote:

Images are uploaded from the client to /imgur/upload/thumbnail at a different time than /tributary/fork (when we want to make the tweet for a fork), and the image data is forgotten, since we pass it to imgur and later just reference the URL saved in the gist's config.json. I don't think the image is uploaded from the client again on a fork.

Maybe a share button makes more sense though, and could upload the image at that time as well. Someone might not want a fork to be announced publically.

I'll look into the imgur return for dev. I agree with figuring out a better way for forks to be handled without page reloads would be good.

— Reply to this email directly or view it on GitHubhttps://github.com/enjalot/tributary/issues/115#issuecomment-31079228 .

georules commented 10 years ago

I'm liking the share button idea. I'll mock some stuff up with it for more discussion. I'll also think a bit about how we might refactor forking and also decoupling the screenshots from any particular activity.

ejfox commented 10 years ago

Maybe we could do without sending Twitter any data and using meta tags in Tributary to give Twitter the thumbnail. https://dev.twitter.com/docs/cards

Not sure if that is easier or not.

Maybe a share button makes more sense though, and could upload the image at that time as well. Someone might not want a fork to be announced publically.

I can't imagine any situation where someone wouldn't want a fork to be private. Tributary is very sharing-biased, we do not make much effort to help users be private, or to create private tributaries, or any other functionality like that. (And I personally really like the GitHub model of pay-to-be-private, if we were to go down that road).