3

Our Challenges:

It seems to me The Polymer 1.0 developer community faces the following challenges right now:

  1. We have no user auth UX example to follow. This Stackoverflow question requests a user authentication UX example. And describes why it's needed. This Github issue also documents multiple user requests for such a user auth UX example. And there has also been lots of anecdotal chatter on the Polymer Slack Site about this issue as well.

  2. Modals don't currently work inside <paper-drawer-panel>. This open bug issue report, this Stackoverflow question and its accepted answer collectively prove that a bug requires <paper-dialog modal> elements must go outside any <paper-drawer-panel> element in order for the modal to render properly (i.e., in front of the modal's backdrop, not behind it). This issue report and this Stackoverflow question also verify same.

  3. But modals inside panels have become the defacto standard auth UX design. It seems to me a principle of modern web app design that user authentication buttons (e.g., login and signup) go inside the equivalent of whatever version or "analog" of <paper-drawer-panel> any given web app happens to use. (Also, these auth buttons usually appear in the upper right corner of every screen of the app until the user logs in. Then they are replaced with an icon or link indicating login status.)

Code Examples:

Refer to the code examples contained here (in the question and answer). That code would be the same for this question too.

Question:

How do we, the Polymer 1.0 development community, best meet these challenges and build the best user auth UX experience possible? Perhaps there is a mistake in my facts or assumptions stated above? Perhaps someone has a direct (or workaround) solution they can share? Perhaps someone from Google's Polymer team would like to chime in? Any and all ideas, suggestions, feedback and answers are welcome.

Community
  • 1
  • 1
Let Me Tink About It
  • 15,156
  • 21
  • 98
  • 207
  • Thanks to @Tasos for a lovely attempt. However, you missed the mark. The demo you shared [here](http://codepen.io/anon/pen/LVBXBO) _(Note to future readers using Safari: Use Chrome instead)_ misses the question in at least two important ways. 1. The auth button does not appear inside a colored header panel. Say, the one labeled "Title" in your example. In, say, the upper right corner. And 2. The dialog box does not exhibit modal behavior. (i.e., darkened backdrop) Instead, it seems to be a simple popup dialog with sliding animation. Both issues are essential elements of the question. – Let Me Tink About It Jul 19 '15 at 17:25
  • So, of course feel free to disagree, but I'm not sure I agree with #3. A modal in iOS, for example, is actually independent of the view hierarchy; a modal can be generated from one viewcontroller (sort of the container that holds all the UI components), and still be present/dismissed/acted upon in an entirely different viewcontroller (or even _app_). Secondly, besides for academic reasons, I'm curious why you think it's important that the modal be embedded in a particular component/tag? Any business logic can be conducted without that requirement. – mbunit Jul 20 '15 at 05:00
  • 1
    1. Polymer, in general, and this question in particular deal with web apps. _("...principle of modern web app design...")_ Not mobile apps. So iOS is not in play. 2. A core concept for web components and Polymer element design is to create modular, portable, self-contained units of code. Think "plug-n-play" for web apps. So, if one wants to design an element that handles the UX for user auth and one wants modal behavior as part of that UX, then that modal behavior should be native to that element. @mbunit – Let Me Tink About It Jul 20 '15 at 07:05

2 Answers2

1

On this bug report rubenstolk provides a hack-fix as follows:

To implement @dhpollack's hack in a nice way, add this function to your custom element:

// https://github.com/PolymerElements/paper-dialog/issues/7
patchOverlay: function (e) {
  if (e.target.withBackdrop) {
    e.target.parentNode.insertBefore(e.target._backdrop, e.target);
  }
},

And add on-iron-overlay-opened="patchOverlay" to all your <paper-dialog>'s

I have tested it and verifies that it works. So for now, that solves challenge #2 in the question. Therefore, I suppose it is sufficient for now to wait until the bug is fixed.

Let Me Tink About It
  • 15,156
  • 21
  • 98
  • 207
0

I modified the PSK adding a login form, made out of a paper header panel, modifying routes for unauthenticated users and hiding the toolbar, by default. This is done with 

document.getElementById('headerContainer').style.display='none';
document.getElementById('mainContainer').style.paddingTop=0;

The UI reappears with

document.getElementById('headerContainer').style.display='block';
document.getElementById('mainContainer').style.paddingTop=168px;

This is just the beginning of a solution. For a complete solution, I would like an iron auth element supporting generic host and usual OAuth sites.

mico
  • 1,816
  • 1
  • 18
  • 27