Maintain a selective history of pages visited

[alxndrsn]

When switching between views of different content, the app should maintain a history stack so that Android's hardware-back-button (HBB) can be used to reverse the navigation through this list.

Examples

Example 1

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
select place in list	Place: District 1	Contacts	Contacts
select place in child list	Place: Health Centre A	?	?
select place in child list	Place: Alice A's Family	?	?
[edit]	Edit (page 1): Alice A's Family	?	?
[next page]	Edit (page 2): Alice A's Family	?	?
[save]	Place: Alice A's Family	?	?
[add child]	Create: Person	?	?
[save]	Person: Bob A	?	?

Example 2

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
[search]	Contacts (filtered by search term)	Contacts (unfiltered)	N/A
select contact in list	Person: Bob A	Contacts (filtered by search term)	?
select family that Bob A belongs to	Place: Alice A's Family	Person: Bob A	?

Design work required

Please:

1. review the tables already filled above and correct as necessary
2. fill in unknown value in tables (currently marked ?)
3. add extra examples detailing other cases not included above

   Useful links

It may be useful to consider the Android UX guidelines ref temporal vs hierarchical navigation, e.g.:

• https://developer.android.com/design/patterns/navigation.html
• https://developer.android.com/training/implementing-navigation/temporal.html
• https://developer.android.com/training/design-navigation/ancestral-temporal.html
• https://developer.android.com/guide/components/tasks-and-back-stack.html

[abbyad]

Thanks @alxndrsn, I'll do a first pass and confirm with other team members/users.

[abbyad]

Here is my first pass, I will check with other team members and users before final confirmation. Given that this is not something that will be implemented before the field test we can use actual user feedback for this as well.

Example 1

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
select place in list	Place: District 1	Contacts	Contacts
select place in child list	Place: Health Centre A	Place: District 1	Place: District 1
select place in child list	Place: Alice A's Family	Place: Health Centre A	Place: Health Centre A
[edit]	Edit (page 1): Alice A's Family	Place: Alice A's Family	[X]: Place: Alice A's Family
[next page]	Edit (page 2): Alice A's Family	Edit (page 1): Alice A's Family	[X]: Place: Alice A's Family (different than HBB)
[save]	Place: Alice A's Family	Place: Health Centre A	Place: Health Centre A
[add child]	Create: Person	Place: Alice A's Family	Place: Alice A's Family
[save]	Person: Bob A	Place: Alice A's Family	Place: Alice A's Family

Example 2

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
[search]	Contacts (filtered by search term)	Contacts (unfiltered)	N/A
select contact in list	Person: Bob A	Contacts (filtered by search term)	Contacts (filtered by search term)
select family that Bob A belongs to	Place: Alice A's Family	Person: Bob A	Person: Bob A

[alxndrsn]

Can I update the original ticket with your table?

[abbyad]

Sure, although I am still not convinced about Example 2 action 4.... We should do more research before finalizing.

[abbyad]

We should also have an example for going from the patient profile to a report details page in the History/Reports tab.

[abbyad]

Alternate using the filter back button strictly as "hierarchical up", and the HBB as "temporal back", as per the design guidelines.

Example 1

action	navigates to	HBB target (temporal)	filter-bar-X/< target (hierarchical)
Contacts tab	Contacts	primary tab	N/A
select place in list	Place: District 1	Contacts	[<] Contacts
select place in child list	Place: Health Centre A	Place: District 1	[<] Contacts
select place in child list	Place: Alice A's Family	Place: Health Centre A	[<] Contacts
[edit]	Edit (page 1): Alice A's Family	Place: Alice A's Family	[X]: Place: Alice A's Family
[next page]	Edit (page 2): Alice A's Family	Edit (page 1): Alice A's Family	[X]: Place: Alice A's Family
[save]	Place: Alice A's Family	Place: Health Centre A	[<] Contacts
[add child]	Create: Person	Place: Alice A's Family	[X]: Place: Alice A's Family
[save]	Person: Bob A	Place: Alice A's Family	[<] Contacts

Example 2

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
[search]	Contacts (filtered by search term)	Contacts (unfiltered)	N/A
select contact in list	Person: Bob A	Contacts (filtered by search term)	[<] Contacts (unfiltered)
select family that Bob A belongs to	Place: Alice A's Family	Person: Bob A	[<] Contacts (unfiltered)

Example 3

action	navigates to	HBB target	filter-bar-X/< target
Contacts tab	Contacts	primary tab	N/A
select contact in list	Person: Bob A	Contacts (filtered by search term)	[<] Contacts (unfiltered)
select report about Bob A	Report tab: Alice A's Family	Person: Bob A	[<] Reports (unfiltered)

[abbyad]

We already use color for context, but if we use the < as "hierarchical up" then we may want to include the tab's icon with the chevron to specify where the user would be going if they press up.

[abbyad]

Assigning to @diannakane for review.

[diannakane]

Here's the latest comments on this, done just before Christmas. The disputes are mostly in column D, in regards to whether places should target directly back to Contacts ("owned" individually by contacts), or if they should target to their hierarchical next-level-up place. https://docs.google.com/a/medicmobile.org/spreadsheets/d/1yo6p7gccJrlg5wbtgV6z0CrKWTII-a_4kkzpUJQ3XRw/edit?usp=sharing

Let's revisit when you're back from vacation, @abbyad?

[alxndrsn]

My notes from discussion:

1. enketo forms and their pages should not be written to browser history (window.history.pushState()); this may require an angular change)
2. login page should not be written to history stack (is this possible? perhaps we can overwrite if we check referer header? perhaps we only care on mobile?)
3. we may need to check in angular history writing that we don't write the same history item twice in a row (e.g. if an enketo form returns the user to the page that triggered the form)

On desktop:

Browser back button:

In enketo:

• "you may lose data warning" (window.onbeforeunload)

Otherwise:

• window.history.back() (no special handling required)

On mobile:

Filter bar back button (<) triggers window.history.back(). Hardware back button:

In enketo forms:

• page === 1 or no pages: HBB triggers close-warning dialog
• page > 1: HBB goes to previous page of form
• filter bar contains X instead of <, and triggers close-warning dialog
• confirming the close-warning dialog calls window.history.back()

In a modal (hotdog menu, fab action menu, upgrade modal etc.):

• if modal has pages an page > 1: go back a page (i can't think of examples of paged modals)
• otherwise: close modal

If the history stack is empty:

• minimise the app (if back stack is empty) (this may just happen by default if we defer to the webview?)

Otherwise:

• window.history.back()

[abbyad]

@amandacilek this issue is a little old but perhaps still relevant. It would be good to get your opinion to know if navigation problems still exist, and how they should be corrected.

[amandacilek-zz]

Yes, back/forward navigation problems do still exist. We had originally planned to address these at the same time as the navigation UI update. We should consider pulling this work out and addressing it separately cc @MaxDiz. The fixes won't be as comprehensive without the UI updates but I think there are still improvements to be made.

In addition to Alex's summary above, please also reference this deck with visual diagrams: https://docs.google.com/presentation/d/1YHSNwx7hFyHrb3vWYUCTgH41AtQsn9WxDWo-CJGz4ug/edit#slide=id.p

Here is a summary of our conclusions:

On mobile

• HBB is back, but skips/ignores modals
• SBB is back, but skips/ignores modals
• Enketo forms are treated as modals. You can navigate back and forth between the questions while you are in a form, but once you submit the form you can’t go “back” into it using HBB or SBB (although you can of course still view it on the History page)
• [[This doesn't yet apply until the navigation UI updates]] Search is also treated as a modal (meaning the back arrow goes back through stages of the search experience while you are in search) until such time as you clear the search or navigate away from the page entirely via bottom bar or menu drawer.

On desktop

• Browser back goes back, functions very similarly but slightly differently than mobile HBB. Mainly, we don’t get to override what the back button does in relation to modals.
• No such thing as SBB on desktop, since the LHS and RHS are always visible. We do provide quick links to parent pages on the People page only, since that page only has more levels of hierarchy. These quick links are always there and function the same regardless of how you got to the page (whether the page was a saved bookmark or a direct link etc.)
• Enketo forms are not treated as modals. They open up in the RHS replacing whatever was previously in the RHS.
• [[This doesn't yet apply until the navigation UI updates]] Search doesn’t have a back arrow on desktop

[antonykhaemba]

Feedback shared by Brac team Brac are piloting v3.8.1 for 40 CHP's in one of the branches and they are expected to upgrade from the current v2.8 to v3.8.1 in a few weeks time. A concern was raised by the CHPs that when a user is under contact profile clicking back takes them to all families in the area instead of the immediate parent profile. This also happens when a user opens a task on the contact profile when he clicks back the app takes the user back to all the tasks that a user has instead of the contact profile. The previous v2.8 was working well and most of the CHP are concerned and some confused. They feel like there are changes on v3.8.1 and yet they have not yet been updated. Brac team have requested that if it possible we could fix the issue before the upgrade of all the branches, tentatively in the next 2 weeks. cc @MaxDiz @dianabarsan @kennsippell @jonathanbataire @derickl and @PhilipNgari

[MaxDiz]

Hi @antonykhaemba glad to hear this upgrade is moving forward. A 2-week turnaround for a non-critical improvement is a tough sell. It is possible to review this issue for a late add to v3.10 (in development currently). Would BRAC be willing to upgrade to v3.10 when released?

[garethbowen]

This is a highly complex issue (as you can tell by the comments above) which probably needs another round of design before we look at how to solve it. Adding it to 3.10 would undoubtedly delay its release.

@antonykhaemba How critical is this issue for Brac?

[antonykhaemba]

Adding @brian256 to discuss with Brac Team and advise if Brac will be willing to upgrade to 3.10 or maybe 3.11.