potiuk commented on PR #23335:
URL: https://github.com/apache/airflow/pull/23335#issuecomment-1113101596
>
> This just seems like worse UX, but okay. shrug
I'd say it's message reinforcing. It's a very well known technique in UX to
remind people about something several times. It has various degrees of
complexity (when and how to remind), but reinforcing message by repeating it is
pretty good to make people into doing what you want (and yes the whole UX here
is an attempt to make people what we want - eventually upgrade and make them
aware that error might have been caused by their inaction to defer upgrade).
It's realy putting responsibilty in the user's hand.
> 1. Print a colorful warning ("Breeze is out-of-date. If this fails, try
updating breeze with (`breeze self-update`) and run this again")
> 2. Carry on.
Yeah. This is what `pip` tries to do. And i''ts rather inefficient. I've
been following `pip` story for quite a while. And they keep on complainign that
user do not follow the warnings they issue.
> Another scenario is when we're just trying to delay/annoy the user into
updating breeze, or pulling in changes from `main`, or whatever - cases where
we don't actually need or care about user input, but we do want to apply some
pressure. The steps in that case are:
>
> 1. Print a colorful warning (eg: "If this fails, try updating breeze or
Airflow and try again. You can disable this wait by setting
`DONT_WAIT_JUST_GO=...` or specifying the `--dont-wait-just-go` option")
> 2. Wait for a delay (this does not have to be 30 seconds, it can be lower)
> 3. Continue with what the command doing in the first place (eg: Run breeze
without updating)
The problem with this scenario is that by the time the action of the user
completes, they will forget about upgrading. They have already done the task.
They don't care about fixing the warning they saw - even if it caused a delay.
By giving an opportunity to the user to react at the place and time they are
warned, is the exact place where their attention is focused. And they can act
immediately - with an immediate reward. This is the same mechanism that
controls impulse buying - and it is a well known technique if you want to make
people do something. Act on impulse. All the marketing studies say that if you
wait even short time before the offer and opportunity for an action, the
conversion rate drops dramatically. This "react now" possiblity is there
precisely for that reason - increase conversion rate in marketing terms.
> 1. Ask for user input and hang until they answer (eg: "Recursively delete
'/'? y/n")
You do not know the full history. Tt has been exactly like that for ~ 1.5
year before I changed to timeout based on observations, getting feedback from
people using it, asking them actively on slack and my own experiences with
using breeze. So switching to timeout was a result of that and learnings i had
and a year long experiment I run.
> Waiting for a minimum timeout of 30 seconds here allows the user to read
what's going on and perform various checks to
validate that they're in a good position to continue.
Not sure where the 30 seconds are from. Can you state what it is based on,
really ?
> * Am I on wifi or did my laptop tether to my phone with it's highly
throttled/expensive connection? My wifi coverage has been spotty recently and
when it does my laptop "helpfully" likes to automatically switch to using my
phone's connection.
The decision might be taken for you in this case. And you will do all the
mental effort. But next time when it repeats it's going to be faster.
> * How big is the diff between my branch and `main`? If it's too big, I may
not want to pull in changes yet. If it's tiny, then yes, pull in changes and
run again.
This check is already done automatically. When you are asked the question,
we already checked and we are sure the chages are significant enough. This is
one thing that we want to "teach" people by reinforcing the message. Again -
the interface here is also designed to "teach" people and get them learn it
over time. But there is no big harm if you don't make the decision.
> * Is the Docker daemon running? Oh right, I disabled it from automatically
starting on my old MacBook because it spins up the fans, but that means I have
to manually start it and I haven't done that yet. Gotta do that, and Docker
takes a bit to start on my old laptop.
If the docker daemon not running you will not get here. It woudl fail much
earlier at "docker check".
> * Wait, I just pulled in changes it shouldn't be asking about this! Oh
wait, whoops, no, I wanted to run this command in my other terminal, in my
other Airflow repository.
Oh yeah. That's why we print important information during "self-upgrade"
about the "other repository" so that you can make decision faster. That's
actualy a good point to add this information to the message with image
building. Fixup is coming.
> Every item of that mental checklist can take time, and it's very
presumptive that everybody running Breeze can tick off everything in that
checklist within a short timeout (eg: 10 seconds). Even 30 seconds is still
majorly presumptive, which is why I said that it should be minimum.
The idea is that they eventually will. Not the first time, not the second,
but aafter 10th time they will. And that's fine to wait. I am not looking for
"immediate" results. I think in much longer timespan and take into acount the
fact that people get similar message multiple time and learn. This is what my
goal is - to also let people learn over time and support it.
> If that's what it's going to take to make this change, then I'm just going
to give up and disengage from this discussion. That would be a very large
amount of effort to change this. I highly doubt that the original author of
this code went through such a study when selecting the timeout values, so I
think it's a bit unfair to ask somebody to go through so much effort to change
something that is (if I have adequately explained it here) pretty obvious and
non-subtle IMHO.
It took initially 1.5 years of running in the mode 3) you proposed and based
on this 1.5 year experiment, it took the author (me) to make the decisions
about the timeout. And I reverted my original decision (which was similar to
your proposal) by learning. So yes - I run such an experiment for quite some
time and thought a lot an analyzed people usage.
Let me ask you - how long is your experiment going to think that your
proposal is better?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
