Your question revolves around signifiers for a button's design (i.e. hints that communicate what an element can do/how to interact with it).
I assume your primary concern with buttons is that many of them are becoming flat, borderless areas of text or icons, which often lack many of these important signifiers that indicate clickability.
There has been a ...
Option 2 leaves the modified content in place and visible. It means that your users don't have to recall the data they just submitted / modified.
Inline notification (Option 2):
Does not make the user recall/remember the data.
Keeps the modified data visible, allowing the user to catch any mistakes they may have made
Keeps the state indicator ('Saved') in ...
Option 2 is better, as discussed by Mike M. I would actually recommend a third option, similar to Option 2. I would replace the "Submit" and "Cancel" buttons with the "Saving" message and spinner. This ensures the first thing the user sees is the "Saving" message. When a user presses the button, their eyes will linger there until something else catches their ...
What I've found works best for my use case is to, like @Hugo-Viallon suggests, put the spinner in the save button and disable all other buttons. After completion I show a toast if the user isn't redirected.
Without the toast I had users saving multiple times just to make sure it worked, a small confirmation helped prevent that.
I'm expanding my comment on maxaathousand's answer as requested and have added some additional insight:
The most important visual key to a button is contrast. This refers to:
The button contrasting against the background behind it
The button contrasting against surrounding elements and the whole page
The text or symbol within the button contrasting against ...
You could have a variant of Option 2 :
The loading could be put on the "Save" button, as a spinner that'll replace its text. You also disable buttons.
This way you show that something is happening, and the spinner being on what was the "Save" button tells the user that something is happening. The other buttons being greyed out make it even more obvious ...
If the text field can contain more than a very few words, then better not hide it, and better not make it unselectable either.
It's very annoying if I fill out a large text/comment field, hit submit, the saving icon is animating, animating, animating, then the connection drops or some other error occurs. If my screen wasn't hidden, I could at least select ...
You need no invent something new, just look how the widely used apps behave. In this way you can exploit users' previous experience, so they'll find this feature is "intuitive" ;).
Some points to consider:
Use clear visual cues for users: change cursor type and show the border between rows (as on the pictures)
Increase the ...
I would suggest introducing an "unsorted" icon that you could apply to the columns that are sortable. So any column that is sortable will have this grayed out "unsorted" icon, sorted columns will either have the up or down arrow, and unsortable columns will have nothing.
DataTables does this out of the box, and I think it's a great way to indicate where the ...
I think you can display the error message inside the dropdown if the typed text is incorrect and doesn't find any results.
You can also suggest them to add the incorrect option as an option if that is the case.
There are ways to indicate the possibility to resize without hovering, but they aren't commonly used and therefore act as an indicator for the affordance only. Don't expect any signifier to be understood directly when it is seen for the first time. A few examples of possible signifiers:
While they are clearly indicators (the lack of contrast put aside) they ...
I think recently searched should be on top.It depends on the use case still recent works better as if the user has travelled recently to one of the favourites it is automatically listed there.
Alternatively, you can also show favourites before user enter "From and To" so that user can choose favourites (Routes or destination).
I just had a half hour Skype talk with my old mom. She understood she must hit the button - she was not able to see the two buttons on the screen right in front of her! This definitely would never happened decades ago, when the buttons pictured like the true 3D buttons. It is also true for windows and other GUI elements. Older people just do not see them on ...
Try clear delineation between groups that are bounded by a similar time context. Take advantage of proximity and hierarchy so users are not confused by two different date ranges.
In your example, you have a top level time picker (which also suffers visibility), and you then change that context about 400px later down the view.
Why not take advantage of the ...