From my personal experience and also from the opinion of a great ui/ux designer that I followed recently, it is a bad experience in most cases.
First, you have to wait for the sentence to complete. The more sentence you have, the longer time the user wastes
Second, for someone who has a problem with reading text, they almost can't read your sentence at all ...
I think if we look at the benefits of a progress bar then we can get a better understand of why and when it might be preferred over showing a list of steps.
It takes up less space in the UI
A simple progress bar helps to keep the UI minimal. This in turn helps incentivise the user as they will feel that there won't be much effort to complete the process. ...
showing steps is a great way to keep the users informed and engaged. I've come across a situation where the number of steps varied based on the user selection. In that case, I had to fall back to showing progress bar only. But if you have finite set of steps, I'd definitely recommend showing them to the user.
Welcome to UX StackExchange, Óscar!
What platform are you targeting? If it's an OS-native app, always honor the date format that the user chooses in their device's settings.
If it's a web app, though, who will be your users?
If you're sure that "every" user will be a US American, you can safely use the MM/DD/YYYY format. It's what everyone uses in ...
Each format has its pros and cons.
Nov 20, 2020
Requires less interpretation; better readability.
Not as easy to compare multiple dates.
Easy to compare with other dates to calculate durations.
For example, how many months apart are 2/1/2020 and 8/1/2020?
Easier to calculate than "Feb 1, 2020" ...
I would avoid tooltips for lots of reasons. In your case the main reasons would be:
There would be no way for users to know how to reveal the content. They shouldn’t have to hover (and wait) for a tooltip to (maybe) show.
It wouldn’t work for people without a pointing device like a mouse or trackpad. They wouldn’t work for keyboard users, screen reader ...
The common way is to use the arrows or chevrons to indicate that the container can be scrolled left/right. If that method is not in consideration, then I suppose, you could use some CSS calc() function to determine the best card size using screen viewport width along with the number of cards in your scroll view.
Many applications build nowadays have a horizontal scroll.
Users are used to horizontal scroll, no need to worry about it.
In case your targeted audience not that smart like adults.
Make use of screen width value and set tabs width accordingly so that one tab will appear of its half-width.
here is the code done using viewport width(VW) unit.
Well I can at least address your first question with the information belongs to it's implementation part, even it has considered within development phase which is out of this site's scope.
First, it's pretty easy to find out a client (targeted user here) device's operating system via a server-side programming language. So that you may understand if it's iOS, ...
Perhaps you can make this a choice on the deletion confirmation screen, such as via a checkbox that says "Notify commenter".
A thread owner might want to notify the commenter of the deletion with an explanation ("Sorry, dog photos are not relevant to the topic") -- this is what's done here on StackExchange. A comment can be useful to ...
An event that is instantanous is an event which start = end. Therefore, you may be able to show what you want by having your users to understand where is the end and the start of an event (sometimes equal)
I think this first Idea is quite elegant, but as said in comment might be mistaken with radio buttons. Therefore I propose other options with the idea ...
You should also keep in mind that anything revolving around "hover interaction" is only ever truly available to mouse users, not pure keyboard interaction (probably unlikely for your case), no stylus* or touch interaction. The latter is probably going to be more likely, as tablets tend to be especially popular among surgeons.
So while hover-...
You can put the SUBMIT BUTTON wherever you find it aesthetically good.
In my opinion: Take the example of Screen 1 - when you will enter the app the user sees a page with 4 fields and a button at the bottom and when he clicks on phone no. or email placeholder then the keypad appears(screen 2). So the user already knows where was the button before the keypad ...
Nowadays it's becoming more common to allow users to see their password, using the little eye icon for example. This would remove the need to enter it twice.
We're not really in the internet cafe area anymore where there could be a dodgy person lurking behind you to steal your password at any time.
A click interaction might be better if the user would want to move their mouse outside of the pop-up zone, such as to scroll or check other information on the page. That would also cut down on accidental interactions. You'd need a way to dismiss the pop-up, but a simple "X" icon could accomplish that.
Humans tend to make mistakes every now and then. But that shouldn't stop an user from signing into a particular website or app. Maybe the slightest of mistakes such as accidentally turning on the caps lock while typing in your password can get you denied from logging into that website again. So adding one more text field to double check on your password is ...
Personally I don't see a problem in navigation or interactivity, but in the design.
Mainly the lack of contrast between the elements to be selected and the rest of the content makes them seem part of the same kind of information.
I would clearly differentiate the info areas from those of interactivity, enhancing the second.
iOS has a Done link that lets the user hide the keyboard. It's also becoming common for webforms to have just one input field and button per screen, so that the CTA button stays accessible. You can also experiment with CTA buttons that are always in a fixed visible position on the screen.
I got one simple solution to this:
We can group things with a simpler statement like "All of these conditions" instead of using "AND" , "Any of these conditions" instead of using OR ~ Nontech users can very much relate what these things are
Even it's a matter of choice as you explicitly told by,
"I know that comments should be deleted silently"
I don't see any benefit here by not notifying user that his/her comments or posts deleted or removed. It's easy to ran into similar situation a lot when blocking performed by someone you are directly in relationship.
Even there are apps that handle ...
Swapna, if you look at rule builders in consumer-oriented applications, you can often find a design approach that is slightly different from directly mapping a boolean equation to graphical symbols.
When using AND and OR, these must be embedded between the matching criteria, as shown in your screenshot. The slightly different approach also groups the ...
I‘ve not tested this so cannot be sure but I think it's useful to fill out the information for the user if you can reliably do it as it speeds up the process for them.
As long as you tell the user where you got it from so it's not surprising and let them correct any mistakes (like if they changed their name or there‘s a typo).
I can see you are telling the ...