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

Comments

Projects
None yet
@dominictarr
Copy link

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

This comment has been minimized.

Copy link
Member

edef1c commented May 25, 2014

+1

@refack

This comment has been minimized.

Copy link

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

@mantoni

This comment has been minimized.

Copy link
Contributor

mantoni commented May 27, 2014

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

@xaka

This comment has been minimized.

Copy link

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.

@mgol

This comment has been minimized.

Copy link

mgol commented May 30, 2014

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

@nullivex

This comment has been minimized.

Copy link

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.

@timoxley

This comment has been minimized.

Copy link
Member

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.

@timoxley

This comment has been minimized.

Copy link
Member

timoxley commented Jun 2, 2014

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

@nullivex

This comment has been minimized.

Copy link

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?

@isaacs

This comment has been minimized.

Copy link
Member

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.

@nullivex

This comment has been minimized.

Copy link

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.

@vohof

This comment has been minimized.

Copy link

vohof commented Jun 3, 2014

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

@nullivex

This comment has been minimized.

Copy link

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

@dominictarr

This comment has been minimized.

Copy link
Author

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...

@75lb

This comment has been minimized.

Copy link

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.

@cnvo

This comment has been minimized.

Copy link

cnvo commented Jun 7, 2014

My suggestion would be to use dots.

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

and loop. No more than 3.

@faiq faiq added the feature-request label Jun 7, 2014

@vvo vvo referenced this issue Jun 13, 2014

Closed

no output #2

@medikoo

This comment has been minimized.

Copy link

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

@tjwebb

This comment has been minimized.

Copy link

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.

@razzmatazz

This comment has been minimized.

Copy link

razzmatazz commented Jun 26, 2014

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

@rlidwka

This comment has been minimized.

Copy link
Contributor

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.

@matejkramny

This comment has been minimized.

Copy link

matejkramny commented Jun 29, 2014

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

@kumarharsh

This comment has been minimized.

Copy link

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?

@mgol

This comment has been minimized.

Copy link

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.

@kumarharsh

This comment has been minimized.

Copy link

kumarharsh commented Jul 15, 2014

Thanks for that info !

@plato-cambrian

This comment has been minimized.

Copy link

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

@pgorsira

This comment has been minimized.

Copy link

pgorsira commented Aug 2, 2014

+1

@rick-kilgore

This comment has been minimized.

Copy link

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

@DomT4

This comment has been minimized.

Copy link

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.

@othiym23

This comment has been minimized.

Copy link
Contributor

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.

@othiym23 othiym23 added this to the multi-stage install milestone Aug 5, 2014

@rlidwka

This comment has been minimized.

Copy link
Contributor

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.

@othiym23

This comment has been minimized.

Copy link
Contributor

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.

@xaka

This comment has been minimized.

Copy link

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).

@rlidwka

This comment has been minimized.

Copy link
Contributor

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.

@plato-cambrian

This comment has been minimized.

Copy link

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).

@xaka

This comment has been minimized.

Copy link

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).

@othiym23

This comment has been minimized.

Copy link
Contributor

othiym23 commented Aug 6, 2014

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

@empiricalthought

This comment has been minimized.

Copy link

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

@othiym23

This comment has been minimized.

Copy link
Contributor

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.

@empiricalthought

This comment has been minimized.

Copy link

empiricalthought commented Oct 31, 2014

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

@antwonlee

This comment has been minimized.

Copy link

antwonlee commented Nov 5, 2014

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

@KenanY

This comment has been minimized.

Copy link
Collaborator

KenanY commented Nov 5, 2014

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

@iarna iarna referenced this issue Dec 12, 2014

Closed

New npm progress indicator #6911

3 of 5 tasks complete
@iarna

This comment has been minimized.

Copy link
Member

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.

@iarna iarna closed this Dec 12, 2014

@iarna

This comment has been minimized.

Copy link
Member

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.

@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.
You can’t perform that action at this time.