PoGo-Devs / PoGo

UWP Client for Pokemon Go
https://pogo-windows.com/
MIT License
38 stars 9 forks source link

(Discussion) UI shell for overlaying elements #26

Open swisszeni opened 8 years ago

swisszeni commented 8 years ago

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

These are:

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:

ST-Apps commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

jakubsuchybio commented 8 years ago

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 commented 8 years ago

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

swisszeni commented 8 years ago

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 commented 8 years ago

Also we should have

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 commented 8 years ago

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

swisszeni commented 8 years ago

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 commented 8 years ago

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

swisszeni commented 8 years ago

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.