Webviews: confusion over existing behavior for viewing published posts from the post list

[rachelmcr]

Expected behavior

When users go to My Site > Blog Posts > View to view a published post on their site, they expect the post to behave the same as it does when they view the post on the front of their site or when they view the post from the same place in Calypso web.

Actual behavior

All posts (published or not) are shown in preview mode (with ?preview=true appended to the post URL). This changes the way the post behaves, e.g. doesn't show sharing buttons (see #8007) and shows comments as closed even if they aren't.

This makes sense for previewing unpublished posts, but it goes against user expectations for published posts and causes confusion. Is there a better way to manage these expectations, or should we change the behavior for viewing published posts?

Steps to reproduce the behavior

1. Go to My Sites in the app.
2. Open Blog Posts.
3. Select "View" to view a published post.
4. Try to interact with the post like a published post, e.g. share, comment.

Tested on [moto e5 play], Android [8.1.0], WPAndroid [alpha-163]

[megsfulton]

This makes sense for previewing unpublished posts, but it goes against user expectations for published posts and causes confusion. Is there a better way to manage these expectations, or should we change the behavior for viewing published posts?

I agree that this is confusing and goes against the users' expectations. My recommendation would be to change the behavior for viewing published posts.

[designsimply]

Tested with WPAndroid alpha-173 (12.6 alpha) on Pixel 3 Android 9 and found that while I can now leave a comment via Site > Blog Posts > View, the share, likes, and related posts do not show up in a webview unless I first leave a comment (because after a comment is submitted the ?preview=true query string is dropped in favor of #comment-1234).

Before leaving a comment:	After leaving a comment:

[designsimply]

Note: the update recommended in #8884 (comment) would solve the remaining problems noted in this issue.

[sophiegyo]

I'd like to add an additional ticket which is somewhat related - the user wasn't sure why they couldn't enter the password for a protected post in this preview.
Ticket: 2127352-zen

[designsimply]

Note: https://github.com/wordpress-mobile/WordPress-Android/tree/master-auto-upload contains a lot of changes to remote previews. It should be merged in the next few weeks and I have made a note to check back in here at that time.

[designsimply]

Sharing buttons not showing in previews came up in 14.1 beta testing. See #11199.

[jd-alexander]

@designsimply I am currently looking into this issue and the solution would be to exclude the preview parameter when a post is published (and has no local changes?). My question is, would the user be fine with their view count going up when they are viewing their own page? because including the preview within the URL avoids this.

[designsimply]

@jd-alexander I'm looking back to this because some similar issues have come up for the iOS app recently. Regarding the view count, if the site owner is authenticated shouldn't that also avoid their own visit from getting counted in stats?

Views by logged-in members of your site, including yourself, are only counted in your stats for sites that are set to private.

^{Source: https://wordpress.com/support/stats/}

cc @guarani as it's tangentially related to wordpress-mobile/WordPress-iOS#15296 on iOS.

[jd-alexander]

@jd-alexander I'm looking back to this because some similar issues have come up for the iOS app recently. Regarding the view count, if the site owner is authenticated shouldn't that also avoid their own visit from getting counted in stats?

Yes, I would expect that to be the behavior @designsimply :) I am going to have a look at this on Monday to see what's happening inside the Android app.

[jd-alexander]

Hi @designsimply I haven't forgotten about this. I am just busy with the File Block project for mobile Gutenberg and I haven't gotten to this task in my list as yet. I am just giving you an update so you know I remember about it.

[designsimply]

No problem! Thank you for looking at it when you have time, that's perfect. It will be good to wrap this one up so we can let the mobile happiness engineers know if anything with the view counts is awry as I know users bring that up from time to time. They love stats!! It will also be good to be aware of the recent iOS changes to Previews and make sure both platforms are consistent. We have some changes being worked on for 16.2. See wordpress-mobile/WordPress-iOS#15296.

Not urgent. Medium priority (because it's come up elsewhere recently).

[designsimply]

Looks like this didn't make it back into the last maintenance rotation (and that's okay), so let's just note that we can leave it in the Groundskeeping To Do list for later consideration but also watch out for any new user mentions about this problem and we can raise the priority if we get more feedback from users about it.

[ParaskP7]

👋 @designsimply and @jd-alexander !

@designsimply I am currently looking into this issue and the solution would be to exclude the preview parameter when a post is published (and has no local changes?).

I am concluding the same.

My question is, would the user be fine with their view count going up when they are viewing their own page? because including the preview within the URL avoids this.

I have the exact same question.

@jd-alexander I'm looking back to this because some similar issues have come up for the iOS app recently. Regarding the view count, if the site owner is authenticated shouldn't that also avoid their own visit from getting counted in stats?

Yes, I would expect that to be the behavior @designsimply :) I am going to have a look at this on Monday to see what's happening inside the Android app.

I am not sure what you mean if the site owner is authenticated, but what I am experiencing is that when you open the preview it launches a web-view without including credentials, as such the site owner is actually not authenticated on this instance, which leads their viewing being counted in stats. However, bare in mind that I am using an atomic site (jetpack connected), and as such I am going through the below flow:

• ActivityLauncher.browsePostOrPageEx(...) -> RemotePreviewType.NOT_A_REMOTE_PREVIEW
• if (site.isJetpackConnected() && site.isUsingWpComRestApi()) { ... } -> WPWebViewActivity.openJetpackBlogPostPreview(...)

For completeness purposes, there exist 4 if/else branches within that ActivityLauncher.browsePostOrPageEx(...) logic:

1. if (site.isWPCom()) { ... } -> WPWebViewActivity.openPostUrlByUsingGlobalWPCOMCredentials(...), which uses credentials.
2. if (remotePreviewType == RemotePreviewType.REMOTE_PREVIEW_WITH_REMOTE_AUTO_SAVE && site.isWPComAtomic() && !site.isPrivateWPComAtomic()) { ... } -> openAtomicBlogPostPreview(...), a preview, which doesn't use credentials.
3. if (site.isJetpackConnected() && site.isUsingWpComRestApi()) { ... } -> WPWebViewActivity.openJetpackBlogPostPreview(...), a preview, which doesn't use credentials.
4. esle -> WPWebViewActivity.openUrlByUsingBlogCredentials(...), which uses credentials

It will also be good to be aware of the recent iOS changes to Previews and make sure both platforms are consistent. We have some changes being worked on for 16.2. See wordpress-mobile/WordPress-iOS#15296.

Yes, I skimmed through the iOS changes as well and although I am not yet fully aware of all the related iOS changes, code-wise, I too agree that we should make sure both platforms are consistent. But, before me going that route I just wanted to make sure I am on the correct path, thus me asking the above questions. @designsimply and @jd-alexander , would you mind letting me know if I am missing anything before progressing any further with any implementation or even further investigation?