(Discussion) UI shell for overlaying elements

[swisszeni]

So the official Apps have multiple UI elements as overlays that persist across page navigation and independent of page state.

These are:

• Top error bar, displaying connection and GPS issues.
• Centered error message popup, displaying when you try to transfer a favorited Pokémon or trying to use PokeStop too far away.
• Received item popups, for each item. When receiving at a PokeStop.
• Transfer Pokémon success message.

My approach to this would be introducing a Shell that manages displaying of these overlaying elements (eg. pass items received, shell shows/hides etc.) and wraps all other Pages of the App.

Did I miss any elements and/or does someone prefer a different approach on handling this?

Functionlist:

• Error bar (GPS, Connection)
• Error message (center of screen)
• Egg Hatch
• Gained Item
• Transfer success
• running request indicator

[ST-Apps]

@PoGo-Devs/ui-team

I think that this can be done, Template10, which we're using now, uses this same approach for the Hamburger Menu template (a Shell which contains the pages and keeps the same Hamburger menu over them).

If you want to start playing with it, download Template 10 VS extension, create the Hamburger app and change Shell's style, so that you won't need to deal with navigation logic.

[swisszeni]

Yes I already know and used Template10 in some other projects. And even MS uses the Shell approach in some of their own Windows-universal-samples. Just wanted to know if some people would prefer a different approach I didn't think of. But doesn't seem like.

Will implement next week when I find time.

@ST-Apps BTW do we have any kind of backlog? Or dev comm channel? Discord seems pretty empty to me

[ST-Apps]

Invited to Slack (and removed your address from here).

[jakubsuchybio]

My ideas from Slack on this topic:
We should have something similar like PoGoMessageDialog without user interaction, just to show things for 1-3secs and dissapear automatically. I would call it PoGoMessageBox. It would have 3 types:

1. would be event/information type for showing (transfer candy, evolve candy, powerup infos, hatched candy+stardust, etc)
2. would be warning type (speed is bigger than 60km/h, gps accuracy low, etc)
3. would be error type (network connection lost, gps lost, battery low)

Also those MessageBoxes would be in queue so they won't overlap and will always wait for the previous to finish.

[ArthurSDev]

would be warning type (speed is bigger than 60km/h..., that warning is boring some times.

[swisszeni]

I don't think we should implement the annoying speed warning... unless there is some server component requiring it. Similar to the annoying popup to "watch your environment" at the start of the game. And if we do, I would implement it with a MessageDialog like in the Niantic Apps.

[jakubsuchybio]

Also we should have

• rotation pokeball for every server request.

Every awaited server request would get triggered. And at the end for a split second (200ms?) it could turn green/red if request had succeded/failed

[jakubsuchybio]

If it is not mentioned here yet. We could use this overlay shell for connection status of requests. Instead of Busy.

[swisszeni]

yeah, well this would be the feature you listed just one post above ;)

We shouldn't add screen overlaying busy indicator (like it is now) anyway.

1. It interupts user experience
2. Isn't like this in the official app

Better disable buttons durng a running request to prevent unwanted user interaction (or animations).

[jakubsuchybio]

Yes, but that will be a lot of work to get right. :) Just sayin..

[swisszeni]

not that much if you hook it up centrally. Set a flag for a running request in the ViewModel, check the flag in CanExecute in each DelegateCommand and RaiseCanExecuteChanged on the beginning and end of every request. around 10-20LOC for every VM.