persona

OP is talking about the NCCN Guidelines, which doesn't seem to be available in other formats or API. From their website:

NCCN Clinical Practice Guidelines in Oncology (NCCN Guidelines®): The NCCN Guidelines® document evidence-based, consensus-driven management to ensure that all patients receive preventive, diagnostic, treatment, and supportive services that are most likely to lead to optimal outcomes.

Format(s) Available for Licensing: PDF API not available

> Putting ideas into words doesn't have to mean writing, of course. You can also do it the old way, by talking. But in my experience, writing is the stricter test.

As pg brings it up, writing is one of the many ways to shape ideas and even change them. But I wouldn’t go so far to say it’s the stricter test.

Each way of expressing and sharing ideas will test it in different ways. Writing may look for conciseness, flow and completeness while talking about it can validate ideas for collaborative building.

Going a step forward, I’d suggest that putting Ideas into Action IS the stricter test.

There is a strong counter-argument though, based on the increase of online meetings and screen sharing scenarios... Not everybody always remembers to silence screen notifications while sharing screens.

Which leads to more-than-once-a-week situations of "Hi - full question or comment notification that probably shouldn't be seen by co-worker/boss/client" popping up during the share.

A simple "hello" --wait for answer-- protocol makes it a quick way of checking if it's a good time.

Finding good threads are hard. :) A quick “unroll” or “thread” search will uncover thousands of threads every day...

Trying to tell / explain to somebody (or even an imaginary someone) what I’ve read or studied. Most good insights or opinions happen at that moment for me.

In complex systems, it's tempting to look for a silver bullet: If we only did "this".

This Capitalism 2.0 would also need to be a system of things that enables a new direction - whatever that may be - based on the fragile regression to the mean of what an expected aggregated view of that looks like.

UBI can or cannot be part of that system, but by itself it can quickly become irrelevant.

Most economic theories of capitalism are based on (mostly) rational behaviors of the majority of market participants. Social studies will show that in topics related to finances/money, behaviors are all over the place.

Want to drive towards Capitalism 2.0? Start with financial education, support systems, relevant incentives (maybe UBI is one of them) and a good shared vision of what that 2.0 is.

I'd argue that this makes more sense in the real world than in a diagram, after being burnt in multiple real life experiences :)

The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.

You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.

Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.

This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing.

It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.

If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.

Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.