Hot answers tagged

47

This is not as simple as it may seem, and although your instinct may be to ban someone, you should first consider the following: How do you determine what is offensive or not? There are many surnames (last names or family names) that would be considered swear words in English, let alone some other cultures. So you run the very real risk of banning ...


20

YES, but.... 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 ...


8

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 ...


6

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 ...


5

Short answer: No There are users who like obscenity and vulgarism, there are those who don't. Generally those kinds of people don't like to mix, and will always try to segregate into separate groups. If you ban offensive names (which is not that easy from technical standpoint), you remove one of the flags those people use to distinguish themselves. However ...


4

It depends on the service and your expected user base. Deciding between blocking and allowing potentially offensive usernames is fairly easy. The more difficult decision is where exactly you draw the line. You are making a tradeoff. You are disallowing some users from doing something they'd like to do (use a vulgar/offensive name) in order to create a more ...


4

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:


4

The best solution is for a site to have "safety" levels. By default, content created by users who are identified as offensive is completely hidden from view. You don't see their questions, answers, comments or accounts at all, unless you switch to unsafe mode. When you switch to unsafe mode for the first time, you have to acknowledge a dialog that you're ...


3

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 ...


3

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 ...


3

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, ...


3

Given that you stated that you're going to cater for mostly British folks, you should consider following their laws. I am not a lawyer, but reading Wikipedia's article on the topic you'll need to account for users who use hate speech in their nicknames. This might be a hard requirement for you, something you don't really decide “if”, but “how”.


3

Short answer: Yes, ban it. Always a good idea to prevent the user from creating such names. There will be some who bypass this and use numbers for letters and stuff, but you should not make it easy for them use it blatantly. Also, depending on the context, it is highly desirable, for example, here on stackexchanges, it shouldn't be that big a deal, but in ...


3

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 ...


3

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.


3

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 ...


2

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 ...


2

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 ...


2

Why not both? A GUI that outputs XML.


2

Alternate approaches:- 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 ...


2

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 ...


2

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?


2

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 ...


2

If I understand your question correctly, you would like the user of your app to change the text that appears on your app so that is can be written in their own language or for it to say whatever it is they want it to say. You idea was to create a long list of inputs to accomplish this. As for if that's "bad"... there is no good or bad in UX, just a degree ...


2

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

For simplicity it may make sense to: For all user roles (except the non-authenticated users) have 1 settings area - label it as you see fit. Within that area anddepending on the user roles (and the access rights that this implies) have completely different Setting pages. For example: An Administrator may land in the Settings page and see a ...


1

If your "Representative" is able to change "data about the organization they represent" (and I assume this organization page is somewhere on your site map), then why not place these editing functions on that page? I have no idea how your site is structured (i.e., how easy it will be for the representative to get to the organization page), but my first try ...


1

I would recommend using a Crown icon to give that more human feelings since you are assigning that icon to a person. A super admin is the king!


1

Usually the show page displays information in a more compact way. Sometimes it may even show related objects: For example the show page of a CRM might list notes associated with the contact, whereas the edit page will let the user edit the contact details. I think the best option is to have a mix of the two: Have a single page, perhaps divided into multiple ...


1

It all depends upon development time and product scope. If your (development) resources are limited and you are short of time for release choose the completely separate admin/user dashboard approach. You will benefit with specific and fast implementation let alone future simple modifications for admin purposes. One the other hand if you want a well-...



Only top voted, non community-wiki answers of a minimum length are eligible