They redesigned the sign in / account selection page earlier this year, but I haven't been able to find any material indicating they changed the OAuth consent screen as part of it (such as before/after screenshots), though it's certainly possible.
Agreed that there's definitely something different in the behavior.
I looked through the HAR files I've captured comparing my company's app to Termly. After clicking "Continue", in both cases there's a redirect to a URL of the form https://accounts.google.com/signin/oauth/consent?as=redacted.... For my company's app, hitting that URL results in another redirect to my Auth0 tenant, whereas for Termly, hitting that URL results in HTML showing the loading indicator (no immediate redirect).
Why the difference? As you said, maybe it's something in the OAuth consent screen configuration (though there are no options I see that could explain it). Maybe it has to do with the age of the account.
That's an interesting possible solution if you're in control of the server. If you're using a third-party vendor like Auth0 to handle the redirect callback, then of course you're beholden to their implementation.
In Auth0's case, it appears the nonce is consumed early in the handling of the callback. In my correspondence with them, I confirmed that they do see that the first request is aborted (in the form of a log), but they take no action as a consequence.
After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality.
If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website.
The immediate workaround is to switch to opening the Google OAuth login page in a new window.
edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).
Very interesting. I just tried in Termly.io as well, and I do see the loading indicator you mentioned, albeit not _immediately_ (if I throttle the network speed, there is a delay before it appears). I captured a HAR file and am inspecting it to see if it has anything revealing about why the loading screen appears in some cases but not others.
> Absolutely love this! The design language and focus on simplicity is right up my alley.
Thanks for the compliment! We did put a lot of thinking and attention to detail into our design language.
> Are there any restrictions on the free plan? I'd be more than willing to pay a reasonable fee to make the "single-person-plan" sustainable without the need to restrict it in the future.
Nope, there are no restrictions, and we don't intend for there to be in the future. The free plan is 100% fully-featured with no difference versus the paid plan aside from the limit on the size of your team.
> Also, one thing that I notice in the demo is a flurry of requests triggered on just about any user activity. Is this just extra analytics in the demo or is this also present in the full app?
There's no difference between the demo and the full app. You're right that some of what you're seeing is for analytics. There's also admittedly more network chatter than we'd like to keep the frontend synchronized with the backend, but we actually have work already in progress to reduce that substantially.
> Nope, there are no restrictions, and we don't intend for there to be in the future. The free plan is 100% fully-featured with no difference versus the paid plan aside from the limit on the size of your team.
Love to hear it! I'll remind myself to give feedback in return.
Strange, sorry about that! While we investigate, feel free to shoot us an email at support@constructor.dev if you continue to have the issue in another browser.
Thanks! All of our core UI components (e.g., buttons, text inputs, etc.) are "hand crafted". We do use https://blueprintjs.com/ for some components, but we apply our own styling on top.
Amen ravenstine. "A tool that stays out of your team’s way" is quite literally the tagline of the Trello-for-devs product I'm working on (Constructor, https://constructor.dev/).
As to the article, I agree with a lot of the author's points. The author talks about lack of features for collaboration. and I agree. What's wrong with the comment systems in Trello or Jira? I think it's that they don't model how people actually collaborate, which often goes something like this: (1) I have a question for someone else on the team, (2) that person answers or passes it to someone else who can, (3) repeat until I've got the answer, (4) reflect the answer somewhere (designs, description, etc.), (5) consider the matter resolved. Many of these might be going on in parallel, and the back-and-forth is often asynchronous. A single comment stream just doesn't lend itself to this kind of collaboration. Neither does Slack where, as the author says, requests for follow-up easily get lost.
The extreme flexibility of the "circles" is interesting. On the one hand, it's nice to give control over to the users and let them model whatever use case they have. On the other, a tool that's too open-ended may overwhelm users with options when they should really be focusing on dev. (Of course, that could be solved with intelligent default templates, or something along those lines.) I'm curious to read others thoughts about that.
> On the other, a tool that's too open-ended may overwhelm users with options when they should really be focusing on dev.
Author here. I agree. A big concern is I build this flexible system and a user jumps in to use it and sees a blank screen. No story section, no sprint section, no epic section. They get bewildered and end up not using it. Do you have any other thoughts on how to combat users being overwhelmed by a blank screen? I could have templates that people could "load" that would set a project up like a traditional project mgmt solution would?
Yeah, templates for "traditional" structures sounds reasonable. Or along the same lines, it might be sufficient to have purely illustrative versions of those setups ("here's how some teams have used this"), to get the idea across, even if they can't be "loaded" as a template.
