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.
These are early symptoms of a Truth-Market-Fit approach[1] where "fact-checking" is defined by the financial benefits in keeping a following or customer base.
The "Fact checkers" have become Trust Providers. Different groups of people will choose to 'believe' different Trust Providers according to their own views.
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.
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.
My son is reading a book about conquerors and came across the portion on taxation, how the conquerors would tax the conquered and send the profits back home. We talk about what he is reading on our daily walks.
He said "there are no more people to conquer, so we tax ourselves"
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.
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.
I feel like they address this in the article. What you say makes sense in a technical UML diagram point of view, but that's not how people work.
The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account.
Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.
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.
People don't care about usernames and other crap. They want an easy option - enter email, communicate over email and be found using email. This isn't their banking app or anything that important.
Nobody "wants to use their email". They just want to start using whatever app or service they're trying to connect to as quickly as possible - why exactly do you think "Sign in with X" became so popular in the first place?
+1 Any authentication method that I have enabled for my email should work -- there shouldn't be a need to remember which one is associated with a particular service...
With rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time.
The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats.
No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two.
It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.
You can create an iCloud account with your own email address. That avoids getting another email address.
When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.
Then why do most of my non-tech relatives have an @icloud.com address that they never needed and never read?
Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.
I have one too (which I've since swapped for an email I actually use). I'm not one hundred percent sure, but I think it was the only option for a while (inherited from MobileMe, perhaps), or at least it wasn't clear that you could/should add another email.
Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.
I can't answer that. However, if you go to appleid.apple.com to create a new AppleID, you must use an existing email address.
When I create a new user account on the mac, it asks the new user if they want to create an AppleID. The default is to use their existing email address. You must specifically select an option to get an iCloud account. If you purchase an Apple device, you again have the option of an iCloud account or using your existing email address for your AppleID. Apple is not using some deceptive UI to get you to create an iCloud email address.
However, I guess you still feel it is somehow evil that Apple does allow you to get a free email account where the provider does NOT read your email content and use it to target ads at you. Suboptimal for Apple from a pure profit perspective.
Whatever the UI is now, doesn't speak for what it used to be over the years. The cumulative effect matters.
There are tons of people with @icloud.com email addresses that they never use who will fall into the login / customer support traps described in the article.
But sure let's not even acknowledge those very real problems, deny Apple's role in this, and blame users. That will surely solve the issues.
I think you are missing the point and are perhaps letting this app vendor create an impression of a large problem based on anecdotal evidence. Perhaps they are just whining because they don't want to lose all that data. I have no idea that that is the case, but we can't rule it out.
Tons of people falling into these alleged traps? Really? What is that based on?
Apple is saying they want their platform to support personal privacy. If an app on their platform offers third party sign-ons that are known to abuse personal privacy, that app must offer Apple's solution that respects personal privacy. Despite it being an imperfect solution, I personally am thrilled that I have that option and I'm happy with Apple taking a stand on one of the most important issues today and going forward.
Some occasional customer support issues vs. providing customers with a real solution to significant privacy issues. From a user perspective the value of having such a choice is high.
Nobody is blaming users. Frankly, I think users are smarter than we typically assume. The support situation is really pretty trivial. If you save the onboarding email sent to the anonymized email address, you've got all you need to interact with an app customer support. People will quickly learn this and get on board if they want the privacy benefit. Its just not a big deal.
Apple's role is about increasing privacy and respecting their user's right to privacy. I fully acknowledge that. Does this create some hassle for app vendors? Yes, but I don't care about that in relation to the greater gain.
I think the problem is that many apps, use the same form for login/signup. So a user thinks they're logging in, but they're actually creating a new account with a new authentication method...
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