Added platform Share-Button

[tclaus]

Solves #26 with platform-dependent Share Buttons:

On iOS:

On Android

(on real device it looks much nicer)

[tclaus]

It looks strange if someone needs to login, but the url still is valid.

The body is used to build. Subject line - if sharing to a mail this is there used, when sharing elsewhere the body (first 60 chars) is used as kind of a headline. The platform pics what is needed for the different targets.

What is a "secondary" post action?

[jhass]

The actions you get when sliding a post to the side in the stream view, or in the single post view those actions are on top of the post.

Sharing limited content just leads to very broken UX, yes, the URL is not valid at all for the recipient, what's the likelihood of the receiver having an account on the same pod! But that's not even my main point. We simply shouldn't encourage to share content that wasn't intended for public consumption by the author. That's why in Diaspora you also cannot reshare non-public posts.

Can't we just not provide the body/subject line?

[tclaus]

Did not see this full comment. Will add limit sharing to public content only.

Did I understand you right- just to share content? This might be formatted content, embedded media and no clue if it's origin. A share should always lead to the source. Like sharing a tweet, a public Facebook post (which means always to login) or a post from a blog. Do you know the Og Tags? Diaspora uses tags to help receivers to extract preview images, headlines etc. What only works when sharing the source url

[jhass]

Sorry, no, you got me exactly backwards there :D I'm skeptical about sharing the first 60 (random value much?) characters of the post is necessary and actually improves UX. I think I would prefer sharing just the URL.

[tclaus]

Mostly it makes no difference - but I found out when sharing in an email this looks like this: With subject in share function:

Without subject in share function:

On all other share types I tested (WhatsApp, Notes, Airport to desktop) - the extra subject is ignored and extracted from url.

[jhass]

Yes, I would argue that most of the time the post content doesn't give a good subject line, so the user has to replace it anyhow. Think when the post is just the link to a youtube video, or an image upload with a couple of tags for example. So actually not setting the subject saves the user the step of replacing/deleting it :)

Even in your example the # from the title are just noise and the next sentence gets broken in the middle and leaves you pretty clueless. Imagine receiving an email like this, you would consider it spam.

[tclaus]

Hm - in case the post is just another link, User may need to change this - in all other cases user must enter something (Not to send a mail with an empty subject) IMHO its better to give a kind of suggestion than keep this empty and urge user to enter something. "Share and go" For me its an UI improvement not a distraction. Whats about to start with this and let get a feeling for this?

You have the last word. ;-)

[jhass]

Well, that's exactly my point, we cannot give a nice "share and go" experience for the majority of cases. Just try it with the latest 20 public posts in your stream, I bet most of them will be just tags (many of them broken in half due to the 60 characters limit), a noisy markdown header and a broken sentence, or just an URL quite likely broken due to the 60 characters limit again.

So let's not pretend like we can provide this nice "share and go" experience.

[jhass]

🍪