Skip to content
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

Differ Presentation by Post Type #228

Closed
dshanske opened this issue Jul 19, 2014 · 11 comments
Closed

Differ Presentation by Post Type #228

dshanske opened this issue Jul 19, 2014 · 11 comments
Assignees
Labels

Comments

@dshanske
Copy link

Develop some method of adapting the presentation based on the markup of the site.

For example, identifying an article, and publishing just title and link, differentiating between this and a note, where the fulltext should be posted. Option for this is the class h-as-article(http://indiewebcamp.com/ActivityStreams)

@snarfed
Copy link
Owner

snarfed commented Jul 19, 2014

definitely! @dshanske, would these orders of precedence work for you?

  • article: summary, then name, then content
  • note: summary, then content , then name

@snarfed
Copy link
Owner

snarfed commented Jul 19, 2014

(right now, twitter uses summary, then content, then name, for both articles and notes. facebook always uses content.)

@dshanske
Copy link
Author

Well, a summary might not fit in a Tweet, but it would on Facebook, for example. Would that be...

  • article: summary(if exists), then name(if exists), then content
  • note: summary, then content , then name

Related to this is the ongoing photo discussion.

@snarfed
Copy link
Owner

snarfed commented Jul 19, 2014

yeah, I meant those as fallbacks, not combinations. good point, I can also check if each one would fit on Twitter, and fallback if either it doesn't exist or it's too long. sound good?

@dshanske
Copy link
Author

Makes perfect sense to me. The biggest problem for me is the ... that many POSSE publishing services do in truncating content on Twitter.

@snarfed
Copy link
Owner

snarfed commented Jul 19, 2014

yeah, ellipsizing is no fun. out of curiosity, though, if the only options available are longer than 140 chars, do you know what you'd want to do instead of ellipsizing?

@dshanske
Copy link
Author

Suggest the user fix it? Not sure.

On Sat, Jul 19, 2014 at 1:37 PM, Ryan Barrett [email protected]
wrote:

yeah, ellipsizing is no fun. out of curiosity, though, if the only options
available are longer than 140 chars, do you know what you'd want to do
instead of ellipsizing?


Reply to this email directly or view it on GitHub
#228 (comment).

@kylewm
Copy link
Contributor

kylewm commented Jul 19, 2014

Unfortunately I'd guess most users would want/expect Bridgy to do the truncation, rather than give an error.

@snarfed
Copy link
Owner

snarfed commented Jul 22, 2014

fixed by snarfed/granary@2a9ce83

@snarfed snarfed closed this as completed Jul 22, 2014
@jasonkgreen
Copy link

With Twitter, there's the challenge of two distinct use cases

  1. You are publishing a link to a longer article
  2. You are publishing a single tweet

Case 2 is tricky. I'm guessing that (I use IndieWeb Press This to publish from WP)

WP Post title = name
WP post content = content
WP ??? = summary

When it was pushing content from the post content to the tweet, I was at a loss as to what to title the posts in WP. It's fine to tweet the post title as long as everyone is clear that's how it works. I need to read up on passing h-as-* to IndieWeb Press This.

@snarfed
Copy link
Owner

snarfed commented Jul 23, 2014

thanks for the info @jasonkgreen! that name/content mapping is right. i haven't seen a summary object from a wordpress blog before, so you may be able to ignore that.

as i mentioned on twitter, you can make wordpress use h-as-note by using the Aside post type. if you add this line to the window.onload section of your press_this.js, it should use Aside automatically:

document.getElementById("post-format-aside").checked = true

snarfed added a commit to snarfed/granary that referenced this issue Jan 4, 2016
...specifically, when summary and content are the same, so we know we're not losing anything.

for snarfed/bridgy#219, snarfed/bridgy#228
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants