Tag Info

Hot answers tagged

46

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


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

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


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


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

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

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

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


2

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


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


1

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


1

The authorization rules set by the Super admin should be implemented asap. The question arises what if a particular user is already in the system or edit mode ? The best solution would be to notify the user then and there that he/she is not authorized for the action he/she is trying to perform without wasting any time of that respective user. One should ...


1

The site should respond according to the authorizations set by the super user. This means that the deleted user should subsequently get "not authorized" responses from any links (s)he clicks that require the authorization that was just deleted. This should happen immediately and should not be dependent on a session time out or (re-)login. Of course any ...


1

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



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