In fact, you don't need to delete the promo code itself, but the association to the product. However, it's always good to delete the promo code as well, for the reasons below:
Make your user's life easier
You're building this for an user, and you're building an usability paradigm, thus this paradigm has to keep the user in mind. One of the ...
This is a security antipattern
It's not a good idea to let admins see a user's actual password ever.
Users often use the same password for multiple sites (against better advice), so it's a moral hazard to allow admins to see user passwords.
You don't need to see a user's password to change it.
Showing a user's password on screen, especially in a web app, ...
One thing that hasn't been mentioned here is history.
Do you need to know if a discount code applied to an order that has been placed in the past? If so, deleting the discount may lead to confusion if you are investigating the order - you may not know what discount was applied (it depends on if you save the discount information with the order or just keep ...
By removing the icon, you can separate viewing from modifying a record. You also reduce ambiguity from icon interpretation.
Since a common use of a list is to access a record and view its details, you could keep the actions as 'actions' which you have as specifically editing and deleting a record.
Try to remove ambiguity
If it's obvious that you can select ...
What you're talking about is a classic drill down approach. Given your stated limitations and the dynamic nature of your content, I think it's the best approach.
It's more common than you think. In the world of dashboards and admin tools, we talk about CRUD (create read update delete) apps all the time, but most actually follow the BREAD view pattern (...
Well you could think about applying miller's columns: http://en.wikipedia.org/wiki/Miller_columns
I've seen very nice implementation of this pattern in deviantart.com with a search input above selector, screenshot:
I agree with what you are trying to do in spirit - but I think you may run into problems with the animation you're proposing. In addition to challenges relating to accessibility and mobile, tilting the label when the field becomes active obscures what is being requested of the user.
The example below is taken from Yahoo's user signup form and demonstrates ...
The idea is good, but there are two peculiarities of such approach, that you should concern:
In traditional case, administration options and front-end options are naturally divided one from another. These are different interfaces and even different web-sites (in user's perception). The navigation for reading and navigation for administration are different, ...
It is a data integrity thing. I may have edit permission and I may be selecting field values for copy paste.
But I don't want to inadvertently change a value.
Also a view only mode typically will have less clutter.
Like a date - you just show the date and not a date control.
An enumeration you just show the current value and no pull down to select ...
I had experience with both approaches reaching the market. I find that having one UI component is better in most cases, especially if you look at the long term planning. If reporting features are configurable or require little coding to adapt to different data sets, incorporating them into other aspects of the product helps with user's decision making. For ...
I would separate the option of add a new one completely and add the edit option for each element. In the way that inside of each category section we have an "Add new one" button at the beginning of the list and a "edit" button per bike.
In this way is easier to edit a specific bike and even easier add a new one.
Every user has a timeline showing the timeslots available for allocation. The diagram shows weekdays, halfdays would probably be better for original question.
Tasks for the project being planned are shown in colour; otherwise occupied timeslots are marked with grey transparent tasks.
Dependencies are marked with an arrow pointing at any tasks that must be ...
Allow users to leave the group before they are accepted by providing an option to Cancel Request.
Once the user cancels request the task to approve request disappears from Admin's tasks list (this is something the program needs to take care of). I think this will resolve the confusion.
Can you make a school a persistent object, and assign a 'year' to a school?
A school can be a parent object to a 'year'.
A school is created one time, and years are created annually.
We haven't seen any mockups, so I'm not sure I understand your use case well.
If you keep the persistent values such as:
History and background
Faculty (fairly ...
We have a similar system in place in our org for customers. We follow scenario 2 for the following reasons:
New users need training
New users require administrative assistance to determine rights (not everyone should get the keys to the castle, and we don't determine that, customers do)
New users don't know anything and can't necessarily be trusted to ...
There are various pros and cons for each. For instance, XML files can be emailed and shared over the internet, whereas a GUI application need someone to click about.
But I think that from a pure UX perspective the main argument in favour of GUI is that text (or XML) files are far more prone to user errors, as any programmer who's application didn't work ...
If you can actually get the users to quickly perform specific tasks rather than doing a demo that would be be helpful as you can observe their reactions and user flow and define what are the usability concerns.
If that's not feasible, One approach you can do is to define what are the different user flows you want to evaluate (it would be good if you can ...
If you have promo codes that are dependent on items/services you have for sale, for example:
Buy item "A" and get item "B" for free
If item "A" (or "B") ceases to exist, runs out of stock, or is disabled, then the coupon/promo should no longer remain active. Without either, the promo code cannot work.
If you create "states" for your coupons so that they ...
We don't know. This is a business/user requirements decision and not a UX decision.
You should probably talk to your users. How likely would the administrator recreate that product or another product in which that promo code also applies to? If/when that happens, would the admin want their customers to continue to be able to use that promo code?
You are correct that these should be distinct areas because the primary tasks are different:
one is related to an individual user's settings (typically under a user menu at the header level and called Settings or User Settings)
another area is related to settings that impact 1 or more users (typically called "Administration" and only available for users ...
When designing an UI, it is better to go as standard as possible -- don't try to reinvent the wheel. Use things that the user is familiar with.
Animations are a non-standard way to focus user's attention on a field, and may confuse the user which didn't expect it.
Furthermore, either you go for an animation that shortly ends (and will not serve its ...
1) You can think of showing summary of changes in a popup confirm dialog, when user click 'Submit' button.
2) Or mark modified fields(background color or border color), and show old value during mouseover in a tooltip.
Above approaches satisfies both requirements :-
1) Uncluttered Modify UI without third column to show previous ...
What's the most likely scenario?
Do admins commonly add several articles? - - create and add another
Do the articles have formatting they have to review? - - create and review
Otherwise send them back to where they come from.
In some cases you need them to edit what they just created, like add some data, then i send them to the edit page.
You can display a simple menu that contains the different actions when the User element is clicked.
Taking the actions out of scope makes the Admin take an extra step but frees space in the page.
Either a menu or a second page. An example of a contextual menu:
First of all, I have to say bravo to your effort and care to solve this problem even though you have no relation to UX.
Moving on, I think indeed that a multi-level "tree" navigation is the way to move forward for what you need.
Essentially you keep all your navigation options in the sidebar and you nest them accordingly under their parent navigation ...
Including a breadcrumb like:
Events / Event 1 at the top or a "Back" button prior to the "Event 1" title or even an "X" close button on the top right corner of "Event 1" should be good solutions to your issue.
Here is a suggested approach:
In the search box, state that the user may search users or roles. Do not present any other choices at this point.
When the user enters a search query, present the appropriate choices.
When the user makes a selection, for example "UX Designer", clearly state the associated role. Offer a button to assign that role to the current ...