You can only view the post list view that鈥檚 been cached while online - Example: You open the post list view, it defaults to drafts, you toggle to view published but can鈥檛 access recently published posts because the view hasn鈥檛 been loaded
I think this needs some discussion on how empty states should be handled. From what I can see, when loading either _Published_ or _Drafts_:
| Has Cached Data? | Online | Offline |
|--------|-------|-------|
| NO |
|
|
| YES |
|
|
My opinion is that if there is no cached data and the device is offline, we should still show the _Create a Post_ button.
I tend to agree. There's also some space for a technical discussion here on what kind of changes we may need in order to have persistent caching. I'll try to check that side of the problem.
You open the post list view, it defaults to drafts
It seems like when opening the post list it the selected tab is the last one you chose. So if you are on the published tab and you remove the app from the background and go back to post list it will be on published. At least thats what it is for me now.
My opinion is that if there is no cached data and the device is offline, we should still show the Create a Post button.
I remember seeing some suggested improvements to the post button from design (like a floating button) but I can't find the post.
I think this needs some discussion on how empty states should be handled
I agree. I don't have scheduled posts and the app opts to show the "no connection" empty view when it could show the "no scheduled posts" empty view even when offline.
It seems like when opening the post list it the selected tab is the last one you chose
You're right @yaelirub that is the behavior.
I remember seeing some suggested improvements to the post button from design (like a floating button) but I can't find the post.
The design team is slated to take a look at the app's information architecture and navigation in ~2 weeks. I imagine we'll be exploring something like this.
I think this needs some discussion on how empty states should be handled
Also agree, thanks for identifying this @shiki. It definitely makes sense to show the empty state in favor of the offline message for those cases.
@diegoreymendez , how can we move forward with this?
Do we need design input?
I've moved @shiki 's suggestion of adding the "Create a Post" button to a separate issue here: https://github.com/wordpress-mobile/WordPress-iOS/issues/11997
@yaelirub - We don't need design input on this one. We most definitely need a technical analysis on what we have, and what could be done to implement this - it's definitely a discovery issue in that sense.
Just looking through this and agree, there's not much for me to do at this point. We've decided to add the button in the linked issue. If something comes up here loop me back in!
The only question I would have is whether we should be loading all posts when the user drills in to Blog Posts? Or loading the requested tab first, and the other tabs in the background. Then everything would be cached not just the current tab.
Maybe that's too resource intensive or technically difficult. But as a user I expect a full view to need some loading when I drill down. But segmented controls and tabs I expect to be more instant / filters of the view that I'm on.
Might be something I'm missing here but no harm asking I figure :)
Maybe that's too resource intensive or technically difficult. But as a user I expect a full view to need some loading when I drill down. But segmented controls and tabs I expect to be more instant / filters of the view that I'm on.
Might be something I'm missing here but no harm asking I figure :)
I really appreciate your input on this @osullivanchris. I tend to agree that the user would want the switching between tabs to be mostly immediate.
This is going to be one of the trickiest issues to implement for sure, but I believe we can learn a bit from talking with @malinajirka and @maxme about how this is done in Android.
@yaelirub - I'm self assigning this now, since I have some capacity to tackle something else. Feel free to de-assign yourself if that's fine, or let me know if I should let you go forward with this.
I'm closing this for now because:
This was discussed and agreed together with @yaelirub
Most helpful comment
You're right @yaelirub that is the behavior.
The design team is slated to take a look at the app's information architecture and navigation in ~2 weeks. I imagine we'll be exploring something like this.
Also agree, thanks for identifying this @shiki. It definitely makes sense to show the empty state in favor of the offline message for those cases.