Aalk4308
Joined 5 years ago
Karma
42
Submissions
14
Member since
Aug 10
Co-Founder and Lead Software Engineer at Flat (https://flat.app)
View on Hacker NewsRecent submissions
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
Both interesting ideas! I'll pass along in my ongoing chat with Auth0. At first thought, the security implications don't seem problematic.
Comment · 2 years ago
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.
Comment · 2 years ago
Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point.
Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you?
Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.
Comment · 2 years ago
Thanks! We've worked hard to keep it simple rather dumping in lots of extra features.
Comment · 4 years ago
> 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.
Comment · 4 years ago
Strange, sorry about that! While we investigate, feel free to shoot us an email at [email protected] if you continue to have the issue in another browser.
Comment · 4 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.