Re: Decision for the autofill subDialog inside preference

[Tim Guan-tin Chien]

The first proposal is going to regress what Fischer is doing, which is finishing up the remaining "move perferences to in-content" work that has been lengering for YEARS. I would prefer not to do that unless that really cuts efforts significantly.

I don't have strong opinion between the second and the third. We could pick one of them that takes the less effort (seems to be the 2nd one from your description but I am not sure.)

My 2¢. 

Steve Chung <sch...@mozilla.com> 於 2016年10月27日星期四 寫道：

Hi Joe,

Luke and I are starting to implement the autofill profile list and edit dialog in preference panel, but we faced a problem while discussing about the nested dialog. There's no existing mechanism for dealing nested dialog behavior, so we just discussed with MattN for the possible solutions:

- The fastest way is implementing the first list dialog as in-content dialog and displaying the second window-dialog on top of the first one(See the attached images). But the window-dialog will be removed and depreciated in long term.

- Implement another dialog(or other type) component for handling 1st dialog, and using original subDialog module for the 2nd dialog.

- Refactor the original subDialog module to support nested dialog case.

We prefer the first solution since we could spend less efforts for it, and we might still need to refactor the subDialog module once the preference panel refresh is ready(but the schedule is unconfirmed). Could you help us to coordinate and finalize the decision about dialog implementation in MVP?

Thanks,

Steve.

--
(Apologies — sent from mobile)

[Matthew N.]

On Thu, Oct 27, 2016 at 8:04 AM, Tim Guan-tin Chien <timd...@mozilla.com> wrote:

The first proposal is going to regress what Fischer is doing, which is finishing up the remaining "move perferences to in-content" work that has been lengering for YEARS. I would prefer not to do that unless that really cuts efforts significantly.

 

​Fischer is going to hit the same problem that we are so if he's fixing the CA trust dialog then we would be able to use the same solution and wouldn't need to worry about this causing more work for us.

I personally don't think ​it's worth anyone's time to fix that CA trust dialog since it's buried and I also don't think using a real dialog for the 2nd level is the end of the world as we're talking about the case where we're two levels deep. We can declare that dialogs are acceptable on top of another dialog if we want. I was suggesting that it's more of a UX decision to figure out the long term approach. Approach 1 is the easiest to adapt into future approaches as it keeps the markup for the two dialogs separate..

I don't have strong opinion between the second and the third. We could pick one of them that takes the less effort (seems to be the 2nd one from your description but I am not sure.)

My 2¢. 

Steve Chung <sch...@mozilla.com> 於 2016年10月27日星期四 寫道：

Hi Joe,

Luke and I are starting to implement the autofill profile list and edit dialog in preference panel, but we faced a problem while discussing about the nested dialog. There's no existing mechanism for dealing nested dialog behavior, so we just discussed with MattN for the possible solutions:

- The fastest way is implementing the first list dialog as in-content dialog and displaying the second window-dialog on top of the first one(See the attached images). But the window-dialog will be removed and depreciated in long term.

- Implement another dialog(or other type) component for handling 1st dialog, and using original subDialog module for the 2nd dialog.

​e.g. like the panel subviews (see the menu panel and identity panel)​

 

- Refactor the original subDialog module to support nested dialog case.

We prefer the first solution since we could spend less efforts for it, and we might still need to refactor the subDialog module once the preference panel refresh is ready(but the schedule is unconfirmed). Could you help us to coordinate and finalize the decision about dialog implementation in MVP?

Thanks,

Steve.

​I think we should find out from UX what the ideal behaviour is and build towards that but not necessarily exactly that for M1. https://mozilla.invisionapp.com/share/AP8TFZ22G#/screens/185446458 implies that the list dialog isn't visible behind the the add/edit dialog so maybe we can do the other option that Luke or Steve mentioned yesterday which is to simulate nested dialogs by switching the contents of the dialog wrapper. My concern is that there will be a flicker navigating from the list view to the add/edit view and that this approach would require the inner list view page being able to call gSubDialog.open which is in the top-level scope.

I think regardless of what the final UX is, it will be safest to implement the dialogs as standalone documents for now since they will be usable in all four solutions that way. We can do automated tests on the dialogs as if they're standalone with window.open (like I planned anyways) and figure out how to tie them together properly later. i.e. I don't think any of the four proposals significantly affect the implementation for M1, only what happens when clicking add/edit from the list view or ok/cancel/close from the add/edit view.

Matthew​

 

[Juwei Huang]

Hi all,

From UX perspective, it’s acceptable for proposal 1 at the moment since we are in stage M1.

Regarding implementing 2nd dialog UI, the decision should be taken by preferences UX. I will talk with them to see if they have plan in mind for Preferences redesign.

Thanks :)

Juwei

--

Juwei

[Tim Guan-tin Chien]

Agreed to go with proposal 1, since we are not regressing anything and UX find it acceptable :)

[Peter Dolanjski]

The only thing to call out is that we may not have the Preferences redesign before autofill, in case that changes anything..

Peter

_______________________________________________
autofill mailing list
auto...@lists.mozilla.org
https://lists.mozilla.org/listinfo/autofill

[Joe Cheng]

Had a discussion with Steve and Juwei earlier.

It looks like with approach 1, the window behavior would be different for different OS (Windows/Linux/Mac) and the UX is only acceptable for Milestone 1 but not for actual release to users.

We could probably wait a bit and see if we have more clarity around preference redesign or if Fischer makes any progress on the CA trust dialog at a later time.

Steve will discuss further with Luke on the approach that Matt was suggesting to reuse the same dialog and estimate the effort then we will discuss if we want to go down this path and when.

Re,
Joe Cheng

[Luke Chang]

Hi Joe,

As I know, Fischer (cc'ed) doesn't have any plan on this as he has another project on hand.

Steve is estimating the effort of switching contents. However, it's not the approach that fulfills all nested dialogs. It can only deal with the scenario that the first dialog is hidden by the second one. That is, we cannot apply it to the CA trust dialog or any other dialogs which first dialog has to be visible. Also, there might be a flicker as Matt mentioned, so I'm not sure if it meets our need better. All these would need UX to define which is the correct behavior though.

BTW, I personally would choose approach 1 and second Matt's words: "approach 1 is the easiest to adapt into future approaches". 

Thanks,

Luke

[Joe Cheng]

Hi Luke,

Thanks for the update.

Let's discuss further during our weekly meetings but for now let's go with approach 1 since it doesn't seem like we have any better options at this moment

Re,
Joe Cheng
——————————
Mozilla Corp.
jch...@mozilla.com