OPDS: How to handle outdated feeds in the user interface?

[mickael-menu]

@qnga and @io7m came up with an interesting question that surfaced with SimplyE and that we also encountered with Aldiko.

While browsing through an OPDS feed, a user might open several successive screens, e.g. publications feed -> details of a publication -> another related feed, etc. But if the user triggers an action (borrow, hold, acquisition) on one publication, going back in the screens stack might show outdated information.

This problem can also occur outside a navigation flow, for example a Home screen showing the user OPDS bookshelf should be refreshed when the user borrow another publication.

Let's explore some possible solutions and talk about it. Feel free to share more ideas!

Solution 1: Refresh when reappearing

A simple way to solve this would be to refresh the feeds every time an OPDS screen regains focus. This is not energy and data efficient, and the user might still see outdated information for a few seconds while the feed is being refreshed.

Solution 2: Selective refresh when reappearing

Same as 1, but only if a particular event (borrow, hold, etc.) was triggered down the navigation stack.

Advantages

• This will prevent useless refreshes in most cases.

Disadvantages

• There might be false positives when navigating through related feeds.
  • This could be alleviated by comparing the publication identifiers in the feed to determine if it should be refreshed.
• This is more cumbersome to implement in the UX layer, because we need a way to propagate these events to the parent screens.
• Refreshing the feeds outside the navigation stack (e.g. Home) is not so obvious. We could monitor events globally.
• The user might still see outdated information for a few seconds while the feed is being refreshed.

Solution 3: Monitoring layer/facade over the OPDS catalog

Instead of having one-shot requests in the UX layer, the screens could subscribe to an Observable feed which will automatically get updates. It's similar to observing an SQL query.

The observable feeds could be provided by a new facade/controller wrapping an OPDS catalog, with the following responsibilities:

• Performs HTTP requests and return Observable responses
  • The rel of the requested link can be used to determine what will refresh the Observable, for example:
    • http://opds-spec.org/shelf refreshes on any borrow/buy
• Monitors requests to register events, by using the rel information of the requested links, e.g. borrow, hold, addToWishlist, etc.
• Automatically updates live Observable feeds when needed, e.g. if the feed contains a publication identifier that was part of an event.

Advantages

• We can refresh the feeds in the background to get up-to-date information as soon as a screen reappears.
  • Or not, we certainly don't want to update 10 feeds. It might be only when requested by the screen.
• Does not depend on a particular navigation stack, so it can be used to refresh feeds anywhere in the app (e.g. Home).
• More flexible if we need to observe different kind of events, e.g.
  • Push notifications
  • Background monitoring of new available loans
• This code might be provided in Readium 2 OPDS modules, as it is not app-specific.
• Easy to use in the UX/app layer, as there are no communication with other views. We observe the feed like we would observe a database query.

Disadvantages

• Harder to implement.
• More complicated so error-prone. However, this should be easy to unit-test.
• The lifecycle of the observable feeds or the facade itself could be tricky.

[mickael-menu]

Note that @HadrienGardeur argued that refreshing the navigation back stack is not necessarily useful or desired in this context (e.g. there's the same issue in a Web Browser, and they don't do anything fancy). According to him, the most important things are:

• Updating the app homepage feeds. This is pretty app-specific.
• Refreshing screens locally, e.g.
  • A publication details view when borrowing
  • A feed when doing a context menu action on a publication

I think that a monitoring facade still makes sense to simplify the UX layer, even if the scope might be different.

[qnga]

Unfortunately, we ideally need to know whether a book that was available for loan is always available when going back to the view in question. The only way to get up-to-date information would be to make a new request to the server.
We also may give up on doing something better than presenting a stale view, as Hadrien suggested. Most problematic cases should rarely occur and would be handled in the same way as concurrent loan requests are.

[HadrienGardeur]

@qnga for a library, the catalog will always be stale, no matter how often you refresh things. Between the moment when you display the feed and a patron tries to borrow a book, there's always the possibility that the book will no longer be available.

When an action returns a payload (borrow, place a hold, cancel a hold) it's useful to refresh the context in which the action was done, but otherwise it's not worth doing IMO. Being able to instantly go back several times in a row is worth more from a UX perspective than refreshing those feeds.