Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DESIGN: Unify flyout designs #253

Open
carldebilly opened this issue May 9, 2022 · 12 comments
Open

DESIGN: Unify flyout designs #253

carldebilly opened this issue May 9, 2022 · 12 comments

Comments

@carldebilly
Copy link
Member

carldebilly commented May 9, 2022

Here's few flyouts:

NEW LIST

Image

NEW TASK

Image

DELETE A LIST

Image

DELETE A TASK

Image

@agneszitte agneszitte self-assigned this May 9, 2022
@Xiaoy312
Copy link
Contributor

Xiaoy312 commented May 9, 2022

This is due to the fact that we are using two systems:

  • MessageDialogViewMap which is like a msgbox with limited customizability (we can only pass string for title/content). This is mostly used for confirmation (like xyz deletion or sign out) where the question is basically a yes/no.
  • Flyout which has full xaml support. This is used for slightly more complex screens, like one that would requires the user input, eg: name of new list/task.

@Xiaoy312
Copy link
Contributor

Xiaoy312 commented May 9, 2022

The question being, do we: // pick one
A. drop the show-case for MessageDialogViewMap, and replicate the same screen with flyout; OR
B. reskin the flyout to look like whatever "MessageDialogViewMap" is using (presumably MessageDialog...)
C. consider this as a non-issue for now

@agneszitte
Copy link
Contributor

@nickrandolph / @NVLudwig / @carldebilly / @francoistanguay (cc @kazo0 / @Xiaoy312)
So do we switch for Flyouts for the entire app and that way we have control over the customization or do we keep MessageDialog for some messages but it will be platform-specific over the look and feel ?

@NVLudwig
Copy link

NVLudwig commented May 9, 2022

@francoistanguay I think we need your call here

@francoistanguay
Copy link

Ultimateyl we'll probably want to make sure we can either style the MessageDialogs (if possible to change the default style) or switch to Flyout but let's keep the Delete actions as MessageDialog confirmation from now and revisit next week

@agneszitte
Copy link
Contributor

@kazo0 do you think we can style the MessageDialogs if possible? I have some doubts about this

@francoistanguay
Copy link

They clearly have a Fluent Style on WASM right now.

@agneszitte
Copy link
Contributor

agneszitte commented May 9, 2022

I know that we maybe could find a way to style it for all platforms. But in the end, I'm wondering if it's something we should do as in my head MessageDialog should be something native depending on the platform.
For example, I think that WASM should use Window.confirm() instead of having a look-alike fluent message dialog right now.
Not sure what do you think @kazo0 / @carldebilly / @Xiaoy312 / @nickrandolph / @jeromelaban ?
(https://platform.uno/docs/articles/feature-flags.html#messagedialog)

@francoistanguay
Copy link

Pretty sure Martin (cant tag him somehow) had a reason for the WASM MessageDialog to be richer than just a Confirm/Alert native dialog.

In all cases, I think we'll want to make it uniform with Flyouts everywhere. We can do this once we're done with everything else.

@MartinZikmund
Copy link
Member

@agneszitte-nventive @francoistanguay The reason the MessageDialog defaults to the WinUI styling instead of native is that with the native dialog there is no way to use commands (buttons), which is quite problematic. - it was lacking all features compared to other platforms. We could expose alert and confirm as a WASM specific API, but it is not too suitable for MessageDialog, where the user can customize the commands...

@agneszitte
Copy link
Contributor

Ok I understand, thanks for the details @francoistanguay and @MartinZikmund!
Will keep this issue aside until we're done with everything else and will make it uniform with Flyouts everywhere.
(cc @nickrandolph, @Xiaoy312, @carldebilly, @kazo0 for info)

@agneszitte
Copy link
Contributor

@kazo0 / @Xiaoy312 / @nickrandolph / @carldebilly / @MartinZikmund
I'm a bit unsure regarding the status for this issue at the moment (in case I missed some changes in the past few months)
Thanks in advance for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants