Spinner vs progress bar is not short vs long operation, it's non-progressive vs progressive operation (though you may opt for a spinner if a progressive operation is consistently, predictably very short).
In the software world, designers need to be engineers (or work very closely with engineers, very early in the process). We recently had designers give us a nice looking progressive indicator for a non-progressive operation that happened to take a somewhat predictable amount of time. Business loved the look and visual feedback. Then we got use cases where the operation could be instantaneous. They didn't want to skip the progress animation because they liked how it made the app feel like it was doing something, and also if the user got the result instantly, it was "jarring". So now, even if the operation finishes instantly, we show the animation, wasting the user's time.
> Spinner vs progress bar is not short vs long operation, it's non-progressive vs progressive operation…
Spinners are typically used for "indeterminate" operations while progress bars are typically used for "determinate" operations¹.
"Progressive" is a less useful adjective here because indeterminate operations progress too, and it's just that their total duration can't be usefully estimated.
And as you note these aren't hard-and-fast rules, and a spinner is generally a perfectly fine choice for short determinate operations.
¹ Progress bar controls typically have an indeterminate flavor too, and these can be mixed. For example, you'll typically see an indeterminate form of a progress bar until a total duration can be estimated, at which point the progress bar will change to its determinate form.
>Progress bar controls typically have an indeterminate flavor too
Good point - I was simplifying by referring to all progressive animations as "progress bars" and all non-progressive animations as "spinners".
>indeterminate operations progress too
I normally think of "non-progressive" and "indeterminate" as synonymous in this context. If the UI can't tell what fraction of the whole has been completed by any metric (which could even include best guesses based on historical data), I refer to that as non-progressive or indeterminate, interchangeably.
Even determinate progress bars are challenging because they typically represent a portion of a known measure that doesn't necessarily match with the user's measure of reference. Example: "75%" complete might mean 75 of 100 files updated while the user is thinking "It's taken 15 minutes so 5 minutes longer.
> though you may opt for a spinner if a progressive operation is consistently, predictably very short
For greater guidance on this, the Nielsen Norman Group spake thusly:
> Use a progress indicator for any action that takes longer than about 1.0 second.
> [A looped loading animation] should be reserved for actions that take between 2-10 seconds. For anything that takes less than 1 second to load, it is distracting to use a looped animation, because users cannot keep up with what happened and might feel anxious about whatever flashed on the screen
> Generally, percent-done progress indicators should be used for longer processes that take 10 or more seconds.
On the opposite side of jarring there are times where an app refresh action works so fast that users think that it's broken since they didn't visually see a change (even though it did refresh and there is nothing new to show).
My solution to that is to simply have a last updated time on the page with precision down to seconds. Just update it to the current time every time there's a response from the server even if it's empty.
> So now, even if the operation finishes instantly, we show the animation, wasting the user's time.
I thought it was fairly well accepted that small deliberate UI delays (for things like loading spinners and animations) can in many cases result in a better user experience. Of course, that would depend on how long this animation is that you're talking about.
You're absolutely right, in some cases. It depends on who you are and what kind of software you use. Delays or animations can improve communication between the UI and the user. Or, they can be pointless and frustrating, e.g. if the software's task feels utilitarian, and there's no confusing or hard-to-perceive transition that an animation would help to bridge, and the user knows the animation is functionless.
Recently worked on an iOS app with the exact same thing, delays inserted on every write which was basically instant as it was writing to SQLite. Client refused to remove it too, you need to pick your battles as a freelancer to get anything done, so I left them there.
Junk apps have taught me that a spinner that takes too much time could be an indication of failure though. The user will be inclined to refresh or close the app.
Same, but only if it "looks like" the app expects it to take a short-ish amount of time. If your operation will take more than a few seconds, the app can include text saying "This usually takes a few minutes" (or whatever is appropriate), and I'll know that a long of a delay to expect before I think something's wrong.
Perhaps you can reduce the animation time by 5% every month. One day people will have gotten used to the faster behavior. Eventually you can remove it without anyone feeling that something is off.
I had this on a project recently, they wanted the spinner to appear for at least 5 seconds even if the operation took less than that. Most of the time it took under 2 seconds - made me so annoyed.
I hate software bloat and thrown away milliseconds, but even then I realize that our visual cortex is really good at noticing movement, but hasn't had any experience in the last millions of years with stuff just popping up out of nowhere or teleporting. I know nothing about usability but just from knowing that, and my own experience, I can't dismiss any and all "useless" animations out of hand. There was a time when we couldn't afford them, now it depends.
Maybe this would be a useful way to look at it: if the average disorientation caused by instant change (which also depends on whether the change is predictable, makes other things change position, etc.) takes longer to recover from than the shortest animation/fade you could come up with, have a transition.
(but even then it doesn't hurt to gate all of that behind a global configuration option, IMO, and if you want to be really fancy make it a float, not a boolean)
> They didn't want to skip the progress animation because they liked how it made the app feel like it was doing something, and also if the user got the result instantly, it was "jarring".
Like hard bristle toothbrushes. Hard bristle toothbrushes are not good for your gums. So why do they make them? Because customers like hearing the sound of the toothbrush brushing. They like hearing it do something.
A proper UI is not about telling people how the things are done, it's about managing/meeting users' expectations on how the things are done, so it's pretty valid to let the users wait longer if that makes them feel better (not saying there are no better ways), pretty much like a placebo.
His "flash mode" example, which he labels "good," is bad, in my opinion.
He's drawn one of those circle-in-a-slot switches. I often have trouble figuring out what the on / off state of those is supposed to be. And then the discription "flash mode" makes it even more unclear how a switch state corresponds to app state (does on mean enabled? does on mean suppressed?).
The good example for "email weekly summary" is actually good, because checkboxes have a clearly enabled / disabled state and if it's enabled the user knows the thing in the text next to it will happen. It's clear. "flash mode" should be re-written in the "email weekly summary" style. It would have a checkbox with a label "use Adobe Flash for rendering."
His flash example is particularly bad because it's not a setting that should be binary in the first place. Auto/On/Off are all important settings for flash photography. Removing one of them would actively anger a lot of people. This section is actually a really great example of how tiny decisions made in UI can actively reduce usability even though on the superficial level it seems like a good idea.
I also think flash mode is represented well on most camera apps. I wouldn't change a thing about them other than maybe adding a text label.
The absolute worst is the "iPhone is dead / charging / not charging" graphic on my phone. I have absolutely no idea which one indicates that the charger is successfully connected. Like PLEASE can you just put the label "Charging" on it.
One of the worst trends in UX over the last decade has been that words have been replaced by iconography. Google seems to have really led the way on this from what I can tell. They've also pushed hard to make every one of their icons impossible to tell apart at a glance: they used to have distinct colors and shapes for each of their apps. Now every app is a white circle with a slightly different rainbow in the middle. It's baffling.
Not owning an iPhone, I would say this is an instruction. Once it's charging, the battery indicator should show a lightning symbol in the middle, or a "Charging" text as you said.
One of the problems compounding unusable UI that I've noticed is the trend to use as little text as possible.
I can understand why designers and even developers want to not use text: Handling multiple languages is annoying and getting people to read is impossible.
But you know what? I don't understand what that fucking black-and-white hieroglyph you pulled out of your ass five days ago fucking means.
For booleans I tend to prefer using “Enable/Disable”. In this example, “Disable Flash” with a checkbox that is clearly in an “Enabled” state can reduce ambiguity. Alternatively, displaying the state and using tooltips that describe the action can be great, but falls apart on mobile devices.
That leads to the extremely common confusion of if "disable flash" is a description of what you will do when you interact with the control (the verb describes the action to be done), or a description of the current state (it's a "yes, disable flash" confirmation). Both are common. Some apps even use both on different controls.
Compare that to a checkbox next to "Flash is disabled". Or a toggle. Or a button. The control and its vague state or bad color blindness choices doesn't even matter if you're clear with your words.
Toggle slider switches are the blue/gold dress of UI design. In a given population roughly 50% will swear with absolute certainty the given state is "enabled" and the other 50% will be ready to start a holy war with the conviction it is "disabled".
The population can be further subdivided into camps which disagree over what enabled and disabled even mean in this context.
>He's drawn one of those circle-in-a-slot switches. I often have trouble figuring out what the on / off state of those is supposed to be.
iOS has an option to display I/O labels on these toggles too, and as it turns out, not everyone knows that I/O refers to on/off. I found out about this when I had to explain to a friend that those symbols meant open and closed respectively on the vents in a car.
I know what I/O refers to, and I have for the last, I dunno, 30 years. Do I know which letter refers to which state? Not a damn clue. I have never been able to remember it.
Yeah, terrible convention, especially because on and off both begin with O. And memory-aid stories don’t help: “those symbols meant open and closed respectively on the vents” - hang on - is O like an open vent or does it mean off?
Genuinely curious, not challenging you: Do you have trouble figuring out the on/off state on iPhone toggles? They've always been obvious to me, but I have seen bad toggles out in the wild.
On Androids I have this problem all the time. It's a combination of bad color and bad text - I don't know if iOS forces the color OS-wide, but the text is app dependent.
Furthermore, communicate why the function is disabled. Nothing is more frustrating than knowing a function existents but not knowing the conditions required to enable it.
Even better, don’t gray it out, allow people to prematurely click, and if they do, guide them to the precondition with a focus and a message about what must be done.
Disagreed. As a newcomer to Grafana, some features were hidden because of privileges and I was super confused about how to do them.
Being disabled with a tooltip saying 'Not available for your user. Contact your administrator.' would have massively helped me rather than going on a wild goose chase.
That's a pretty good counterexample, and probably the more common one. But what if your company only paid for a tiny subset of the product? Would you want to see everything that's unavailable along with a tooltip even if it really detracts from the user experience of the features you did pay for?
Small quibble: I agree with No. 1, but I'm annoyed with the example of the "Good" version, because it gives no option for an amount that doesn't exist. Imagine buying your next coffee and having the barista swivel that iPad around to you to pay, and your options for tipping were ONLY "$5, $10, or $15." In reality, there's always a backdoor to put a custom amount, so I acknowledge I'm being fussy.
You're right, it's not user-centered design, it's creator-centered design, like those god-awful lightbox overlays for subscribing to newsletters that are the most horrible interference ever. And no, I don't care that they have huge conversion rates, they piss off the user, so they are bad design. This is the kind of garbage designed by marketing people, not tech design people who know anything about good UX.
I wish there were a way to quantify "they piss off the user" -- I was never able to successfully do that. Even if we were to show 10 of 10 people in qualitative interviews hated them, Marketing would still point to how many signups they yielded.
I communicated with my son's doctor through a system that included a checkbox with label Not Urgent that defaulted to checked. As I submitted an urgent message, I clicked that checkbox and hit submit in quick succession.
Later I went through sent messages and the urgency indicator was opposite of intended on all. I looked at the form more closely and realized that the label was actually indicating what clicking the checkbox would change the state to, so clicking indicated it was not urgent.
I emailed the company about the confusing behavior and received no response.
Just to clarify, when the checkbox is checked the label is "Not Urgent" and the message is considered urgent. When it is unchecked the label becomes "Urgent" and the message is not considered urgent.
One thing I haven't seen discussed before are the two different types of options, which should be handled differently.
- Options which any particular user might want to change on a regular basis. These should be near the "front" of the UI within reach according to how often a user might be expected to change it.
- Options which different users may select differently, but which a specific user is unlikely to change. These can be buried, as long as they are easily discoverable so that users are at least aware of the option.
Also please make toggles unambiguously on or off. Those little sliders, especially solo, can be difficult to figure out the current state of. Maybe put the word "On/Off" right on the slider itself. Or put the state in the label: (-0) Flash is ON. (0-) Flash is OFF
Now that you got the UI right, stop tweaking and changing it. I can't stand when the UI on so many apps and webpages change simply because the UI folks and programmers need something to do.
UI doesn't change because UI folks have nothing to do, it changes because people love to complain, and sales loves to be able to tell customers "we made that change you asked for".
If you like an app and don't want the UI to change, tell the company. as long as all the people who like it are silent and all the people who don't like it are complaining loudly, apps are going to keep changing.
Sure, because you don't know if the 900 people are silent because they're happy or lazy. A 10% complaint rate feels quite high for a typical feature and would tell me that I probably got something wrong.
* Avoid single choices. If there's only one possible choice, don't waste the user's time by requiring an action. At most show that that value is chosen.
* Select the best defaults you possibly can. If some extra coding work allows pre-selecting the right default infor 50% of the users without making it harder for the rest of the users, it's a win.
* Remember the user's input. Making the user select the same thing again and again is insulting.
* Don't have an explicit setting when an implicit one will do. The width of a panel can be remembered from the last time the user resized it, there doesn't have to be a place to enter a value for it.
When programming DVD menus, this was a very common issue. I used to think to myself that at least in web design, this isn't an issue since the :hover type action is what caused the highlight. Then we got touch screens without :hover and it now haunts me again.
I'd add that I've noticed older people struggling with hidden UI elements. (E.g. not knowing that button X will appear if they do Y (and then not remembering if told...)).
That's why UI elements should almost never appear and disappear. There's a reason that GREYING OUT disabled controls has always been a fundamental concept of GUI design. It shows users that the function exists, where it exists, and that it's conditional.
Peek-a-boo UI is incompetent. It's even dumber when you consider that, in most cases, the space for the disappearing controls has already been reserved; so nothing is gained by hiding them.
And almost as bad as peek-a-boo UI is "flat" UI, where most controls aren't demarcated as such. So you're reduced to clicking on plain text labels and other inert-looking components to see if there are hidden goodies associated with them. Absurd.
This is age-related only in that that it's about visual cues, which are the entire point of GUIs to begin with. Physical buttons on a device are inherently discoverable, as were the controls in GUIs for decades. Younger people are used to the incompetence of newer designs, and more tolerant of having to click every pixel on the screen to find things. It's unfortunate.
The bright spot is that there has been some backlash against the "flat" laziness and a return to some visual cues.
There must be a whole branch of design geared towards older generations. I have been trying to work in this area and have noticed older people are very persistent and will read instructions carefully, but are very hesitant to click and explore things. Meanwhile young people immediately click and interact with everything without any fear but will completely ignore any kind of written instruction.
I was testing a web app out on my dad and he dragged the cursor to the bottom of the screen, which brought up the Mac Dock which immediately confused him and he asked my why I did that. I am not sure how to code around just general inability to use a computer, maybe avoid elements at the edges of the viewport haha.
I've noticed this as well. Ironically, I believe it's because product design was generally worse "back in the day." Normal items you'd buy from a store or catalog could be legitimately dangerous if you operated them incorrectly (electrically powered appliances like lamps and toasters that were not polarized/grounded, for example). So, rather than risk the very real likelihood of breaking your new gadget or injuring yourself, you were better off reading the instructions and only using the device as you were instructed to.
These days, things are pretty much "stupid proof." No matter how many times I insist on it, people my parents' age simply refuse to believe that there is nothing they could reasonably type or click while using their computer that will irreparably harm it. (Yes, of course they could somehow format their hard drive, etc, but there's zero chance you'd be able to do that on accident.)
"I believe it's because product design was generally worse 'back in the day.'"
I don't agree with this generalization. Here's an example: A stereo receiver, even today's A/V receiver, has a certain number of physical inputs. Back in the day, you had buttons on the front to select the input you wanted, clearly labeled. One press gets you the source you want, every time.
Many receivers today force you to press an Input button or turn a wheel to iterate through a list of inputs, a list of unknown size and unknown beginning and end. This is because the display idiotically doesn't show a complete LIST of the inputs at once, or even a moving dot to show you where you are in the list. So you could be one input below the one you're trying to select in the list, but if you happen to turn the dial the other way you'll go through 10 inputs to get back to it. Granted, this is much less commonly encountered now because nobody is going over to his receiver to put a disc in the player, but it was a problem for many years when people were still doing so.
In some cases, older designs were also better for safety. When safety is on the line, the best design (or at least universally-understood standards) often percolate to the top and stay there.
But I also acknowledge that there have been major safety improvements. The other day I rented a chain saw for the first time and was comforted to see the safety brake on it.
Point taken, and I agree. "Design" in general has not improved monotonically in time or across all types of products. I still think that it's like the stock market in that it has, overall, gone "up" over time.
> people my parents' age simply refuse to believe that there is nothing they could reasonably type or click while using their computer that will irreparably harm it
Do you not tell them not to click on links in email messages? That doing so could infect them with malware?
Fair point. I wasn't thinking about that angle. I'm mostly talking about them exploring menus and options in applications. But, you're right that you can cause some damage (mostly to your meat-space self) by clicking naughty links and/or running untrusted code.
The latest example of this I've seen is that after the latest cable box update - full screen ads will show for shows when it turns on and my mom doesn't know how to close them and I have to come help. She only knows how to change the channels, not interact with GUIs. She's never used a mouse before or used "arrow" keys to move an interface. She only knows "this button does this".
Another example is that our last TV had a "Source" Button. But it doesn't change the source, it brings up a list so you can choose a source. Nearly every week she would accidentally hit Channel Up or Down on the TV remote and then not know how to switch it back to the Cable Box. She'd hit Source and it wouldn't change the source and then call me.
I think that beyond a relatively obvious menu, non-obvious UI elements are an anti-pattern. And I'm someone that largely came up in text-based UI interfaces (BBSes, terminal apps, etc). Things should be largely discoverable in practice for graphical user interfaces, even if there's a shortcut.
ESPECIALLY "buttons" that are basically text links without the underline. If you're lucky, you might have a "pill" border or drop shadow, but that hasn't helped my dad in my experience observing him.
I’m generally not a fan of this design pattern. If an action is required before the button is applicable, consider disabling it instead of hiding it, or—even better—allow clicking it and simply guide the user to the required action (e.g. focus the required element and show and error message under it; maybe shake it a little if you‘re up to it).
While pair programming I will say something like "just click on it with your mmb" and I always hear "what's that do?" I have yet to work with a single developer that uses the mmb. I live and die by mine. This doesn't include the "I don't have a MMB" Mac club.
It is quite handy as a clipboard in Linux distros.
That said, I learned the hard way the switches put for MMB are often subpar and fail quite fast. I replaced an Omron (?) switch in a Logitech mouse... twice. Thankfully the current Corsair M55 (pretty basic wired gamer mouse) goes strong.
What? It's much worse now, I routinely see rich web apps which refuse to open a detail view in a new tab, and reject the attempt by the middle mouse button to do so. Instead I get a huge noticeable lag to switch between the two. Ick.
I can't help but notice, the first rule there has an overlap with dark patterns. It makes sense, you're trying to encourage a specific behaviour through an option, so it represents how far you're willing to go.
You can generalize this: if you have to implement the UI element because it's not there by default (like a slider), it's probably worthwhile to investigate why.
Slide toggles are such an annyoing fad. I find them really unusable. If you're going to implement one, please label which side is on vs off. Or just use a damn checkbox -- it's the same thing, but actually clear when it's enabled or disabled.
Appple iOS design uses these instead of checkboxes and the web followed. Don’t see how they are better - maybe when used without a submit button to imply that the change takes place immediately.
I'm curious about the hierarchy one. On one hand, it seems like a good rule, because one of the hallmarks of a dense, hard-to-use UI is the presence of deep option trees. On the other hand, there is ALWAYS complexity in something large enough, and it cannot be abstracted away, best we hope for is to organize it well -- and hierarchies are a natural way of doing that.
A good middle ground that I've seen across programs, apps and OS-level menus is to add a search box that "skips" the hierarchy navigation when the user knows what they're looking for.
Another interesting idea was "adaptive" menus where the most used options (per user) would be "nearest" / easiest to get to. That one is nice in theory, but in practice it causes things to move around, and makes it harder to develop familiarity with the nested menus.
On the point of familiarity: a solution that appears clever and great, but hasn't taken off (probably because it still feels "unusual") is the circle menu. It makes good use of muscle memory, as all the options are arranged in concentric rings around a start point, with selection on one ring opening the next (more outer) ring with more options.
As far as the author's suggestion -- I guess it aims to keep the top-level menus simple. Where does the complexity go? If it's boxed away in some other dialog, per "category" or "subject", it could work relatively well. A bit more effort from the designers to make it that way, but generally that means it's less effort for the user to interact with.
>A good middle ground that I've seen across programs, apps and OS-level menus is to add a search box that "skips" the hierarchy navigation
I use this in the iOS Settings all the time. It truly is a great and important UI element.
Web sites could benefit from adopting this as well. With the rise of Google, it seemed like everybody just kind of gave up on search. "They'll just Google it anyway." But for a lot of Web sites, having a decent and working search tool is really important.
I remember a lot of articles talking about how to handle search on your Web site, with lots of tools and libraries and whatnot, and it just kind of dried up. There's still work happening on Big Time search technologies (Lucene, et. al.), but other than built-in things for platforms like Wordpress, it's kind of stale and quiet.
> A good middle ground that I've seen across programs, apps and OS-level menus is to add a search box that "skips" the hierarchy navigation when the user knows what they're looking for.
Or, when searching, keep the hierarchy but only show the items that match and their parent folders. Can give users a sense of "oh, that's over there, so similar stuff is in that same location".
i don't think there's a good answer on the hierarchy problem. there's two types of users - the ones who like to see all the settings available to them, and the ones who get angry or confused if any settings are displayed that aren't relevant to them. these two groups of users will never agree on what settings should be visible and what should be hidden.
Do you have any idea how hurtful the phrase is to people without thumbs? And if we only follow "rules of thumb" where does that leave canines, whales, and tardigrades? Not to mention mycelium. What UI best practices are they to follow?
I find the slide left/right buttons shown as the first diagram in point 2 to be confusing. Is the text referring to the current state or what happens if I click it? Is there an official name for that button type? Give me a check box any day.
I'm starting to get into frontend development after sticking to backend for years. Does anyone know of a more fleshed-out set of rules of thumb for beginners in UI/UX development?
Full of great tips and no fluff. Basically gives you a large but fantastic set of rules to live by, cohesive enough that you don't have to deviate from them unless you know what you're doing and have a solid need to. But otherwise it's a great foundation that you can implement in any design system.
Not really, but browsing Smashing Magazine[1] or A List Apart’s[2] more popular articles could give you a better sense, and some more in depth knowledge.
Don’t Make Me Think by Steve Krug is an absolute must book for any UX beginner. Easily digestible and lasts through the ages as an example of good rules to follow.
From the quick searches I've done, it seems a lot of people agree with you. Do you have any opinion on whether the 2nd edition is preferable? Either way, thank you for the recommendation!
There’s a couple that stand out as “nice ideas in theory, but rarely practical in reality” - undo over confirmation, and progress bar over spinner.
Confirmation dialogs take about 2 minutes to implement. Undo, while there’s the odd problem where it’s easy, very often it’s a massive amount of work to implement, like many months.
Likewise, a spinner is a few mins of work, while an ACCURATE progress bar can be much, much more. It’s often really hard to predict how long a given operation will take.
One thing I hate about my phone is that certain apps have horizontal swipe to delete list items. It presents an undo option, but the undo option doesn't appear for very long, and can itself be dismissed quite easy by accident. Text message conversations are especially prone.
The number of times I've deleted something with no recourse because my dog bumped my hand while holding the phone (or some similar unintentional action) went from frustrating to embarassing to enraging long ago.
I think the key thing to keep in mind is that the end user really, really, and I cannot emphasize this enough, absolutely and totally does not care about how much effort something was for a developer.
This guide is from a UX person, they are looking at things from a usability perspective. Developer effort is not a consideration here, and rightfully so.
> Confirmation dialogs take about 2 minutes to implement. Undo, while there’s the odd problem where it’s easy, very often it’s a massive amount of work to implement, like many months.
UX is a feature.
Might be irrelevant for yet another SaaS, but for consumer-facing products it will be the reason you succeed.
Depending on the task, Undo can be relatively easily implemented as "queue up the change in the background, but don't do it until 30 seconds have passed" and "undo" is actually implemented as "cancel". Does put a time limit on how long you have to undo, though.
Or along a similar line of thought, restyle your confirmation dialog as an undo dialog, but treat dismissal as confirmation instead of cancel.
A problem with confirmation dialogues is users become accustomed to confirming everything (“of course I want to do that”) and then miss the important irreversible change and just hit the button.
So far 3 out of 5 items in the list have been called into question. Seems like an entire domain of knowledge might be a bit too broad to be summarized into listicles, even with the caveat that they are "rules of thumb".
Does anyone have recommendations for learning physical user interface design or hci? A lot of the articles I find on UI design are focused on websites or apps.
In the software world, designers need to be engineers (or work very closely with engineers, very early in the process). We recently had designers give us a nice looking progressive indicator for a non-progressive operation that happened to take a somewhat predictable amount of time. Business loved the look and visual feedback. Then we got use cases where the operation could be instantaneous. They didn't want to skip the progress animation because they liked how it made the app feel like it was doing something, and also if the user got the result instantly, it was "jarring". So now, even if the operation finishes instantly, we show the animation, wasting the user's time.