In some cases you may want to reconsider the requirement for explicit saving and go with implicit saving instead. (Counter example is applications where it is important for all the data to be saved at once due to relations between the various records.)
There are various practices that I have seen for indicating that the data has not been saved, which I will ...
Of course it's acceptable to break common conventions, but you have to understand the costs of being unconventional.
Control-C was once a very well established command to interrupt and possibly abort the current program. The pioneers of modern windowing GUIs changed to the meaning to copy. Quite a drastic change but the benefits outweighed the cost of ...
The answer is in the 10 Heuristics for User Interface Design by Norman Nielsen, which are a must read if you listen to me.
«Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation ...
Designing a visual indicator here is non-trivial
A charger has at least the following states, and possibly more:
The charger is not plugged in correctly, or there is no power in the wall socket
The charger is plugged in correctly but the device is not charging (e.g. faulty cable, device isn't fully plugged in)
The charger is plugged in correctly and the ...
This is kind of a loose fit for UX (and SE). But there is some general value here ...
Pending, in progress, and completed all look spot on for the message you're trying to convey. My concern would be open and cancelled in the context of task management.
Concerns with your system
Open in task terms is often thought of as "incomplete". I'm not sure how this ...
According to research done by Nielsen/Norman, icons alone are rarely clear enough to convey their meaning; it's better to include labels with them.
So you really have two options: (1) icons with labels or (2) just labels.
Test with your prospective users.
As you suggest, both sides have pros and cons but the best way to settle the matter is to get a bunch of users to test a prototype.
Taking control of the browser's back button can be very productive in situations where the user's view changes to the point where they feel like they are on a new page.
I would suggest ...
Here's how I interpret your question:
How do I show a choice that's already been used?
Once it's been used, make it disappear. Or, if you need to convey additional information about the choice that's already been used, change its visual appearance.
If you don't want to make it disappear, you could change the "already used" choice visually:
Affinity Designer does that. You can change the state of the application by switching between vector, pixel and export modes.
They use these toggles:
The user knows on which mode he is by seeing tools only available on the mode he selected.
You could display something like a modal that you will hook to onbeforeunload to confirm that the user wants to close the app.
To show that the item is not added to the backend, you could either:
1. Use a short text instead of a spinner
2. Make the item in progress semi-transparent
Developers make user change password, when
password is near to expiry
detects a suspicious login, informs user by email/msg and forces the user to change password.
Making the user enter current password makes sense only in the 3rd case. My suggestion would be to avoid asking for current password to an already logged in user. On top of that ...
Icons are subject to interpretation. You could try small text indicators.
I'm not sure if your intention is a list or cards.
Instead of the icon, you can put a simple header for instructions (I just put a light gray header here; you could fit more data in a simple list, where this would be a column header).
Since you haven't posted a mock, here's a try:
I would definitely avoid using that animated icon, as it is very strongly associated with "loading", and gives the impression that loading is incomplete.
You want to show state as clearly "on", or "off". In the real world, people use buttons and switches to perform on or off operations, so it should be clear if you present them with some kind of labeled ...
The term that you're referring to is called, unsurprisingly, MODE :)
It's a long-standing concept in HCI and UX, being criticized from very early on by several design and usability gurus, including Don Norman and Jef Raskin.
As this Wikipedia article defines it:
In user interface design, a mode is a distinct setting within a computer program or any ...
I think color is a very good choice. As far as I understand, you are dealing with only two states, not initialized and initialized. In this case, you only need to flag the risky state, let's say not initialized.
It also depends on how far away you want this to be visible from and the size of your screen. The smaller the screen and the further away you are, ...
A disabled state with a tick makes the situation harder to be understood. Tick gives a positive feedback to the user while disabled button gives the negative one. You need to show the active state more highlighted while other/others get the normal styling.
In addition, if some action is running and can not be reversed by pressing it (like radio buttons) You ...
I would agree with Bharath Selvaraj, but I want to point out that the Hybrid Approach and Option 1 conflict with the expectation of how data is input in the UI from your example and Option 2.
In the first example from your question, the last row of cargo already has its information filled in, and there is a button to add another row. This sets up the ...
The best (in terms of Android Development) and most common practice is to let the Android Application Lifecycle handle this. The way it should work is by keeping the state alive so long as the app remains "alive", in other words, while the app has not been killed by the OS or terminated by the user. The app may be killed for a number of reasons like memory ...
The way a selection is made in your current solution is fine, however the feedback is confusing. You should apply positive feedback to the selected option; highlights, size increase, etc, but keep the other option in the same state as it was before the selection. This informs the user that changing their selection is still possible, which I assume is ...
The disabled looking state with a tick feels all wrong. Using inactive styling for something active is weird.
You want to style this in the same way as the 'Use automatic queue' button and have the tick beside it. [I take it nothing will happen if you click the active state again? It just stays active?]
So all that would happen is when you clicked the ...
Looking at Nielson's top 10 (despite being written in 1995), and based on some user testing, I actually think there's a case to be made for option 1.
Consider the situation where a user believes the file they have prepared for the program is located at a place on the disk. The file is not of the required type, but most users don't always (often) read ...
You should never leave a user in a state of doubt. Always give feedback as to what is happening.
1) If you're loading state is explaining in clear, understandable language, that the submit is being checked or saved and that it will be done momentarily, there should be nothing wrong with that.
But how long could such a request take? Are we talking ...
I think you're talking about two things:
Default state: Everything is set up according to the initial "install".
User on-boarding: The mechanisms designed into the software to help the user develop their proficiency without "reading the manual" or contacting support.
A proposition from me is to use the #3 option starting the message with apology, then briefly explain why the action is unavailable and finally provide instructions on how to fix the error if possible.
Sorry, the action is unavailable due to this. Go here and change this.
Ideally the error message will be concise with red colored and should point to the ...
I personally, hate it when things have lights on them, especially if they're things that I could potentially be running at night while I'm trying to sleep- chargers, speakers, computers, anything really.
Bright little LED's are never a selling point for me when I am looking at something's design.
Most of these things are able to provide feedback in other ...
One may reasonably assume that users are looking to the device being charged to see if charging is happening versus looking to the charger. It's therefore likely, since there is no feedback mechanism in the charger design, that the product designers validated that assumption and found that having such a mechanism would be redundant, not intuitive to the end ...
In my opinion, it depends on the device you are charging.
Because on an iPhone/iPad/iPod touch (and on most devices of that kind) there is feedback whether the screen is turned on or not.
But on most computers, there isn't feedback at all when the computer is in sleep mode, and only a little when the computer is on. In that case, feedback directly on ...
To answer part of the question, the classic example of a 'mode' error was the ease of accidentally putting a wordprocessor into "overtype mode" so that rather than inserting text into existing text it would happily overwrite the existing text.
As it was something that nobody did deliberately it was very difficult for a user to sort out why the wordprocessor ...