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

Async media: Scroll to failed post from error notifications #6424

Merged
merged 9 commits into from
Jul 31, 2017

Conversation

aforcier
Copy link
Contributor

@aforcier aforcier commented Jul 28, 2017

Addresses a suggestion from @iamthomasbishop (marked in the to-do list here).

#6420 should be merged before merging this PR.

When tapping a notification for a failed post upload, the post list is opened. Instead of showing a dialog, the list will now scroll down to the post that failed, and a dialog is no longer shown.

async-scroll-to-failed-post-demo

@iamthomasbishop it looks to me like it would be better to scroll a bit more, so that the post appears at the top of the list (rather than scroll just enough to reveal it at the bottom as in the demo above). I can change that but waiting for any more feedback on that you might have before diving in.

cc @mzorz

@iamthomasbishop
Copy link

it looks to me like it would be better to scroll a bit more, so that the post appears at the top of the list

Agreed. I'm starting to think we should also add an outline of the posts w/ their associated alert color (error = red, alert = yellow, etc), but let's obviously hold on that idea.

@aforcier
Copy link
Contributor Author

@iamthomasbishop updated to display the post is at the top of the list instead:

async-scroll-to-failed-post-demo-v2

@mzorz
Copy link
Contributor

mzorz commented Jul 28, 2017

one thing that I'm not sure about here is that when you tap the notification and you're shown the list of posts, with the error one being the first one shown, it looks like that is actually the absolute first in the list. We do have the subtle hint that it is not because the scrollbar appears and disappears on the right, but still wondering if we could maybe not make it the top most item but center it in the screen, or maybe just show a little offset so the item above it shows a bit, to hint the user there's more stuff up there? Just thinking aloud here, what do you think @iamthomasbishop ?

@iamthomasbishop
Copy link

@mzorz I very much agree. If we could have the post before it hang 10-20dp off the top there, that'd be helpful.

Another option - start at the top of the list when the page loads, and smooth scroll quickly to that post.

@mzorz
Copy link
Contributor

mzorz commented Jul 28, 2017

What if we leave it as is, but make an animation on the alpha highlighting the item to bring the user's attention?

@iamthomasbishop
Copy link

@mzorz I'm okay with that!

@aforcier
Copy link
Contributor Author

@iamthomasbishop @mzorz I did two options, the smooth scroll (can be made slower than this), and the alpha highlight. The alpha one is maybe going to be a bit more error prone as it had to be done in a somewhat hacky way.

Smooth scroll:

async-post-scroll-option-2-smooth-scroll-25f

Alpha highlight/blink:

async-post-scroll-option-3-alpha

@aforcier aforcier added the [Status] Needs Design Review A designer needs to sign off on the implemented design. label Jul 31, 2017
@folletto
Copy link
Contributor

The alpha one feels almost like a glitch to me, not a highlight.

The scrolling one seems solid.

@mzorz
Copy link
Contributor

mzorz commented Jul 31, 2017

LGTM @iamthomasbishop if you agree I'll merge 🙇

@aforcier aforcier changed the base branch from issue/6386-async-design-tweaks to feature/async-media July 31, 2017 13:30
@aforcier aforcier mentioned this pull request Jul 31, 2017
12 tasks
@iamthomasbishop
Copy link

@aforcier @mzorz That's much better! Very small request - Can we make the post before the error'd one hang off the top of the screen 10-20dp? Very rough sketch for reference: https://cloudup.com/c3hjt8YwZhD

@aforcier
Copy link
Contributor Author

@iamthomasbishop sure! Here are 10dp, 20dp, and 40dp (that's including the margin between the posts, so it's not exact):

async-scroll-offset-10dp
async-scroll-offset-20dp
async-scroll-offset-40dp

@mzorz
Copy link
Contributor

mzorz commented Jul 31, 2017

I like 20dp the best

@aforcier
Copy link
Contributor Author

@iamthomasbishop asked to bump the offset a bit to 23dp. Pushed the change for that in 711f21e. Here's what it looks like:

async-post-scroll-option-2-smooth-scroll-25f-23dp-offset

Design review is done @mzorz, ready for a new code pass 🎉

@aforcier aforcier removed the [Status] Needs Design Review A designer needs to sign off on the implemented design. label Jul 31, 2017
PostsListFragment oldFragment = mPostList;
mPostList = PostsListFragment.newInstance(mSite, mIsPage);
mPostList = PostsListFragment.newInstance(mSite, mIsPage, targetPost);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PostsListFragment.newInstance() only uses targetPost to obtain it's id and set a parcelable argument. Later on that id will be properly used to retrieve the actual PostModel from the db when it is actually needed.
Also, the only reason why PostStore is imported and injected here is to be able to get the PostModel.

Why don't we just remove the use of mPostStore in PostsListActivity altogether, and pass the ID here as well?

This would also be in line with the decision taken on trying to avoid this kind of PostModel passing around because of potential OOM problems, like in this PR here #5856

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case we're passing the PostModel directly to a method, it's not being parceled, so #5856 shouldn't apply.

I decided to use the model for two reasons:

  1. We won't create a new instance of the PostsListFragment if the post has since been deleted (since it would have a non-0 id, but the PostModel obtained from the store would be null)
  2. This avoids PostsListFragment.newInstance() taking an int id argument, which is error-prone and the main case for using models over ids

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case we're passing the PostModel directly to a method, it's not being parceled, so #5856 shouldn't apply.

Forgive me, I wasn't clear: I was trying to acknowledge how the same treatment to this case is given within the fragment by using the ID instead of the PostModel. I should have said something like "it's great to see we're using this in the same way here".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having discussed these 2 points in Slack, and acknowledging point 1 is better kept as is as per the advantage of keeping fragments, and leaving point 2 for a longer discussion elsewhere, here's one minor thing users could benefit from:

If the user taps on an error notification for which the referred PostModel doesn’t exist anymore (i.e. has been deleted) we should do something else then, maybe show a Toast or something, indicating the Post wasn’t found.

To test:

  1. start draft
  2. make it fail
  3. delete draft
  4. tap on notification

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added toast in fece2bf.

@@ -21,13 +21,14 @@

public class PostsListActivity extends AppCompatActivity {
public static final String EXTRA_VIEW_PAGES = "viewPages";
public static final String EXTRA_ERROR_MSG = "errorMessage";
public static final String EXTRA_TARGET_POST_ID = "targetPostId";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we rename this to EXTRA_TARGET_POST_LOCAL_ID - I'd be happier :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂️ yes, good catch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 3e0b6f6.

@aforcier
Copy link
Contributor Author

Ready for another pass I believe @mzorz.

final int position = mPostsListAdapter.getPositionForPost(mTargetPost);
if (position > -1) {
RecyclerView.SmoothScroller smoothScroller = new LinearSmoothScroller(getActivity()) {
private static final int SCROLL_OFFSET_DP = 23;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a comment here explaining why we are moving this offset? maybe something like // we're showing just a bit of the item above to hint the user they can navigate up (feel free to re-write to something better worded than this)

@mzorz
Copy link
Contributor

mzorz commented Jul 31, 2017

There's one thing I found: if you rotate the device the List is always scrolled to the top. So, say the problematic post is somewhere in the middle, it fails, you tap on the error Notification and are correctly scrolled to it, but then rotate the screen, the list loses its position and the first item is shown.

To test:

  1. choose from an old draft in your list (something that is below or in the middle of your list)
  2. modify it and make it fail sync
  3. see the notification appear
  4. scroll the item away of your post list
  5. tap on the notification
  6. observe you're taken to the correct item
  7. now rotate the screen
  8. the first item is shown

@mzorz
Copy link
Contributor

mzorz commented Jul 31, 2017

I confirmed this is happening in develop, so opening a new issue here #6437

@mzorz
Copy link
Contributor

mzorz commented Jul 31, 2017

LGTM :shipit:

@mzorz mzorz merged commit b0ddcf3 into feature/async-media Jul 31, 2017
@aforcier aforcier deleted the feature/async-error-scroll-to-post branch August 1, 2017 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants