Skip to content
This repository has been archived by the owner. It is now read-only.

new spinner is terrible UX #5340

Closed
dominictarr opened this issue May 25, 2014 · 43 comments
Closed

new spinner is terrible UX #5340

dominictarr opened this issue May 25, 2014 · 43 comments
Milestone

Comments

@dominictarr
Copy link

@dominictarr dominictarr commented May 25, 2014

The rule of silence, as it's usually stated, is that "if a program has nothing surprising to say, is should say nothing at all"

Looking at this the reverse way, if something surprising HAS happened, then you must inform the user

A progress bar is nice, because it gives the user some idea about how long they will be waiting for, even log output can work in this way... even non-programmers learn to recognize patterns in the log output at boot, or the sound that the modem makes when it's about to successfully connect)

But the only thing that a steady spinner communicates is that the computer is still operating... And worse, it appears to be trying to communicate, but the movements mean nothing.

Really a spinner is the UX equivalent to when you are on hold, and you get hold music plus a message with "thank you for waiting, you are a valued customer".
An empty platitude, that instead of making you feel reassured, actually makes you feel more ignored.

A spinner that does not mean anything is worse than no output at all.

What would be acceptable:
If the spinner only moved when something actually happened (say, if it moved when ever the old log would have output a line) then, it's much more reassuring to the user - if it changes slowly - it must be waiting - if it changes fast, then the network is good right now...

@edef1c
Copy link
Contributor

@edef1c edef1c commented May 25, 2014

+1

Loading

@refack
Copy link

@refack refack commented May 27, 2014

👎 I love it. Even submitted a PR to improve it. But it's incompatible with other packages that play with cursor position such as mocha:
spin-with-mocha

Loading

@mantoni
Copy link
Contributor

@mantoni mantoni commented May 27, 2014

+1 for (at least) not showing the spinnter when running scripts, especially npm test and npm start

Loading

@xaka
Copy link

@xaka xaka commented May 30, 2014

+1 as it makes Travis CI and Capistrano to generate huge logs. I'd either disabled it completely by default or change it back to previous version. Everything that changes cursor position (including \r) is bad for automation. As an option you could consider using infinite dots as an indicator of activity.

Loading

@mgol
Copy link

@mgol mgol commented May 30, 2014

I submitted #5363 for not showing the spinner in npm scripts like npm test.

Loading

@nullivex
Copy link

@nullivex nullivex commented Jun 2, 2014

+1 this is driving me nuts on Windows as well. Its not compatible with any of my terminals and the old format was just perfect.

Loading

@timoxley
Copy link
Contributor

@timoxley timoxley commented Jun 2, 2014

It'd be nice if the spinner could be toggled on off as the install is running (without losing previous log output) via hotkey.

Loading

@timoxley
Copy link
Contributor

@timoxley timoxley commented Jun 2, 2014

i.e. press the hotkey to take a peek at what's actually happening.

Loading

@nullivex
Copy link

@nullivex nullivex commented Jun 2, 2014

It would be okay if it worked properly in windows but I dont see the point in the work required to make it cross OS compatible at least just disable it in windows by default?

Loading

@isaacs
Copy link
Contributor

@isaacs isaacs commented Jun 2, 2014

npm config set spin=false will disable it.

"The computer is operating" actually is relevant information. When the loglevel is set too low, people frequently think that npm is "hanging" when in fact, it's just fetching a lot of stuff. When it's set to include http, people complain about it being too noisy.

This is the reason why, as infuriating as it might be, "your call is important to us" is much better UX than silence. Silence would not tell you that you're still connected.

A more informative progress indicator would be better, no one is arguing that point. But that requires much more extensive work on the install process, which is planned, but will take a while.

Loading

@nullivex
Copy link

@nullivex nullivex commented Jun 2, 2014

@isaacs Thanks for the config option at least it will make it tolerable on Windows.

You are correct on people thinking its hanging. Its just that this particular solution doesn't really work well for everyone at the moment so it is frustrating for those of us that don't have terminals capable of displaying the spinner correct and having it on by default.

Loading

@cyrusdavid
Copy link

@cyrusdavid cyrusdavid commented Jun 3, 2014

👍 I'd prefer seeing the http messages than a spinner.

Loading

@nullivex
Copy link

@nullivex nullivex commented Jun 3, 2014

Why not both? Or a percentage on the HTTP request?

On Tue, Jun 3, 2014 at 4:20 PM, Cyrus David notifications@github.com
wrote:

[image: 👍] I'd prefer seeing the http messages than a spinner.


Reply to this email directly or view it on GitHub
#5340 (comment).

eSited LLC
(701) 390-9638

Loading

@dominictarr
Copy link
Author

@dominictarr dominictarr commented Jun 4, 2014

@isaacs a really simple fix that would still be slightly meaningful would be to have the spinner tick when the the log would have output something. then you can look at it and distingiush between working and waiting. A progress bar is very difficult in this case, because does not know how much work it will be upfront.

The "thank you for waiting" is patronizing, hold music is enough to let you know you are still connected.
Maybe the CLI tool equivalent would be animated ascii art...

Loading

@75lb
Copy link

@75lb 75lb commented Jun 4, 2014

with npm start the typical goal is to launch a server, so I assumed the spin would cease once my goal was met.. but the spin persists.. did my server launch successfully? the spin says "no" but it seems up.. i'll write a "server is up, disregard the spin" message to the console.

Loading

@cnvo
Copy link

@cnvo cnvo commented Jun 7, 2014

My suggestion would be to use dots.

"..." from 1-3
.
..
...

and loop. No more than 3.

Loading

@medikoo
Copy link

@medikoo medikoo commented Jun 22, 2014

+1

I just upgraded to latest node, and saw this.

This spinner is a terrible idea, breaks most scripts I use.

To my understanding this should be provided by configured scripts and not by script runner which now just breaks output of every single script it manages.

UPDATE: Glad to see it fixed

Loading

@tjwebb
Copy link

@tjwebb tjwebb commented Jun 22, 2014

Actually breaking things is worse UX than merely seeming to break things. Surely though you have a closer read on the community pain points than I; if people have been clamoring for more spinner, I must have just missed that discussion by having not searched for it.

npm is very verbose by default already (in a good way). It behaves very similarly to apt-get in output format, and to the extent they've also seen requests for ASCII spinner, I'm glad they've chosen to not implement it. Foaming -\|/-/ all over the place seems like an over-correction.

+1 thanks for npm config set spin=false.

Loading

@razzmatazz
Copy link

@razzmatazz razzmatazz commented Jun 26, 2014

👍 silence is golden, unless there is something I should know

Loading

@rlidwka
Copy link
Contributor

@rlidwka rlidwka commented Jun 26, 2014

It behaves very similarly to apt-get in output format

apt-get prints out 1 line per package, npm at http level usually prints out 4 lines. So apt-get is a bit less verbose.

Loading

@matejkramny
Copy link

@matejkramny matejkramny commented Jun 29, 2014

👍
Is there option to make it more verbose? I know there's -v but thats too verbose :P

Loading

@kumarharsh
Copy link

@kumarharsh kumarharsh commented Jul 15, 2014

npm config set spin=false just hides the spinner, but shows nothing in it's stead.
How do I get back the logs output?

Also, it is really useful seeing the logs to see which command is breaking, or where did the error come while building some package. The npm-error log which is generated at the end is not always very useful, or atleast, takes a much higher effort to understand sometimes. Is there a way to turn on the logs?

Loading

@mgol
Copy link

@mgol mgol commented Jul 15, 2014

@kumarharsh

npm config set spin=false just hides the spinner, but shows nothing in it's stead.
How do I get back the logs output?

npm config set loglevel=http. Generally, read https://www.npmjs.org/doc/misc/npm-config.html, those options can be set permanently via npm config set.

Loading

@kumarharsh
Copy link

@kumarharsh kumarharsh commented Jul 15, 2014

Thanks for that info !

Loading

@plato-cambrian
Copy link

@plato-cambrian plato-cambrian commented Jul 28, 2014

+1 how frikkin irritating
Edit: Suggested fix, just set the default to spin=false and leave the command there for ppl who want to reenable it

Loading

@pgorsira
Copy link

@pgorsira pgorsira commented Aug 2, 2014

+1

Loading

@rick-kilgore
Copy link

@rick-kilgore rick-kilgore commented Aug 5, 2014

+1 - running scripts via npm and saving or parsing output does not work well with the spinner.

sorry, didn't see the workaround in this thread before I posted - setting spin=false works for me

Loading

@DomT4
Copy link

@DomT4 DomT4 commented Aug 5, 2014

The spinner is supremely irritating. I appreciate knowing that npm hasn't started hanging on me, but can we not achieve this in a slightly better format that an arbitrarily spinning /. A loading percentage would be more useful, ... would be more aesthetically pleasing. The spinning / just manages to be irritating.

Loading

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Aug 5, 2014

One way or another, npm will have an improved progress display before the end of the year. The current spinner is roughly about as good a job as we can do with the current install algorithm. Once we've figured out one-step full dependency tree resolution, it gets closer to being possible to do things like display the percentage complete / progress meters / rough estimates of time to completion a la apt-get. Until then, though, the spinner is what we've got.

Loading

@othiym23 othiym23 added this to the multi-stage install milestone Aug 5, 2014
@rlidwka
Copy link
Contributor

@rlidwka rlidwka commented Aug 5, 2014

The current spinner is roughly about as good a job as we can do with the current install algorithm.

Right now you can't estimate how many http requests you've got to do.

But you can show user an exact amount of http requests already made, and progress of each pending request. And it is possible to do it with minimal changes to current npm code.

Loading

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Aug 5, 2014

@rlidwka I'm disinclined to put too much time into this, because I know that all the code related to this is going to change a bunch in the very near term (and because we have a lot to do along the way). If you feel strongly enough about this to submit an upstream patch extracted from yapm, we can probably work together to get it landed, but it's not on my list of things to do before I get to multi-stage install.

Loading

@xaka
Copy link

@xaka xaka commented Aug 5, 2014

Guys,

While working on improving npm please keep in mind that there are tools
like Travis CI, Jenkins, etc. that do run "npm install" which means you
could end up with bloated log output from those tools simply because people
knew nothing about "--no-spin" option and new spinner was introduced with
no announcement. When open such logs you see thousands of lines with just
one "/" character. The point is we always need an option to disable/change
behavior when we want to run npm in non interactive environment (i.e. no
terminal).

On Tue, Aug 5, 2014 at 12:37 PM, Forrest L Norvell <notifications@github.com

wrote:

@rlidwka https://github.com/rlidwka I'm disinclined to put too much
time into this, because I know that all the code related to this is going
to change a bunch in the very near term (and because we have a lot to do
along the way). If you feel strongly enough about this to submit an
upstream patch extracted from yapm, we can probably work together to get
it landed, but it's not on my list of things to do before I get to
multi-stage install.


Reply to this email directly or view it on GitHub
#5340 (comment).

Loading

@rlidwka
Copy link
Contributor

@rlidwka rlidwka commented Aug 6, 2014

@othiym23 , I'm working on it, should be easy enough.

@xaka , npm disables spinner when stdout is not TTY, so this "/" character should not appear in logs anywhere.

Loading

@plato-cambrian
Copy link

@plato-cambrian plato-cambrian commented Aug 6, 2014

My preference is:
Disable the spinner by default
Allow granular controls for:
npm install npm test and any npm run * script.

On Tue, Aug 5, 2014 at 7:00 PM, Alex Kocharin notifications@github.com
wrote:

@othiym23 https://github.com/othiym23 , I'm working on it
https://github.com/rlidwka/yapm-progress, should be easy enough.

@xaka https://github.com/xaka , npm disables spinner when stdout is not
TTY, so this "/" character should not appear in logs anywhere.


Reply to this email directly or view it on GitHub
#5340 (comment).

Loading

@xaka
Copy link

@xaka xaka commented Aug 6, 2014

Alex,

I wonder if it was fixed recently because about a month ago it's exactly
what was happening to all of my builds using Travis CI. I had logs full of
lines with only one well known character on each and only "--no-spin"
helped to solve it.
On Aug 5, 2014 6:00 PM, "Alex Kocharin" notifications@github.com wrote:

@othiym23 https://github.com/othiym23 , I'm working on it
https://github.com/rlidwka/yapm-progress, should be easy enough.

@xaka https://github.com/xaka , npm disables spinner when stdout is not
TTY, so this "/" character should not appear in logs anywhere.


Reply to this email directly or view it on GitHub
#5340 (comment).

Loading

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Aug 6, 2014

@xaka: The spinner was changed to only run on fetches in npm@1.4.15.

Loading

@empiricalthought
Copy link

@empiricalthought empiricalthought commented Oct 29, 2014

Can the isTTY property of process.stdout be used to determine when the spinner/color/progress blinkenlights should be displayed? http://nodejs.org/api/process.html#process_process_stdout

Loading

@othiym23
Copy link
Contributor

@othiym23 othiym23 commented Oct 31, 2014

@empiricalthought char-spinner, which is what npm uses to implement the spinner, does this already. But @iarna has a different solution in mind as part of her multi-stage install project: real progress bars! Stay tuned.

Loading

@empiricalthought
Copy link

@empiricalthought empiricalthought commented Oct 31, 2014

Ah, can it be added to color output as well then? (Possibly not related to this issue.)

Loading

@sicktastic
Copy link

@sicktastic sicktastic commented Nov 5, 2014

please take the spinner away...... 🚑

Loading

@KenanY
Copy link
Collaborator

@KenanY KenanY commented Nov 5, 2014

@antwonlee Is npm config set spin=false and spinner-on-fetches-only not sufficient?

Loading

@iarna iarna mentioned this issue Dec 12, 2014
5 tasks
@iarna
Copy link
Contributor

@iarna iarna commented Dec 12, 2014

Improvement to this is going to be implemented in #6911. As such, I'm going to close this ticket so that future discussion can happen around the actual implementation.

Loading

@iarna iarna closed this Dec 12, 2014
@iarna
Copy link
Contributor

@iarna iarna commented Dec 13, 2014

This is going to be addressed (hopefully) by #6911, so I'm going to close this ticket so we can move new discussion there.

Loading

@npm npm locked and limited conversation to collaborators Jun 24, 2015
rpappalax referenced this issue in mozilla-services/services-test Jan 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet