Hot answers tagged

75

There's an easy way to approach user-select: none, and that is to ask a single question: Would selecting the text be the primary/secondary interaction a user would intend if touching the screen there, or would it be a hindrance to the task they were trying to carry out? Image Carousels (love them or hate them) are a fantastic example of this. In a touch ...


64

In general, you shouldn't use it globally. Oftentimes, users select some text, maybe to highlight something to show a part of the text to a friend, to copy text or to mark the text just to be able to read it better (which I do when the text is pretty wide and it's hard to follow the text wrap in the sentence). However, there are really good examples where ...


46

Not only is Helvetica not safe, but it is also a copyrighted font, so you need a license to use it if you load it as webfont. As a matter of fact, there are no 100% safe web fonts, since it will depend on the fonts the user have on his/her device, and different operative systems have different font sets. Hence, you need to do something like this: p{font-...


26

There are such people as "selection readers". I am one of them. I (for some reason consciously unknown to me) have a tendency to select text while I'm reading it. Sites that stop me from doing so make me very sad and mess up my user experience. I also completely disagree with the point in what is currently the top answer. Those things that pop up whenever ...


18

I think you've answered your own question. The special cursors demonstrated on that web site are rarely needed, whether in a browser or outside of one. Of the 31 cursors, 14 of them are for resizing elements, which isn't really a common task.


15

I see Progress and Help used fairly regularly. Other than that, the rest of them are mostly situational... there's no need to use them out of specific tasks and environments. Using cursors where not absolutely necessary violates the rule of don't confuse your users, ever. If you can use a normal cursor, do.


13

Not being able to select text is the most annoying anti user-friendly css property there is right now in modern websites. Reasons: Lets not try to act as if our website is something it isn't. It's not a mobile app and the reason you cannot select text in an application is because it is not inside a text-box and therefor is not supposed to be selected for ...


12

As mentioned there is no such thing as a safe web font. But there is a way to load in missing fonts from your server through the use of @font-face. @font-face was first introduced in CSS2, includes fallback file types, and is widely supported. This wouldn't be a 100% solution but it would be more promising than depending on the machine's font selection. ...


11

"Default", "Pointer" and "Text" are defaults in browsers. Others we forget to specify for developer — because we paint static images. But if we work with interaction our-self, we will remember to use "Not available" cursor for disabled elements for example.


9

There are many contexts in which it is good UX, and many where it is bad UX - there's no one-size-fits all answer. As you flag in your question a button or action that when clicked highlights the text isn't good UX, and there are likely to be very few circumstances when a user should need to highlight that text. However bodies of text shouldn't be disabled ...


9

be accessible on any device Really no such thing as 'available on any device'. If you're not using embedded fonts, then you need to use a font-stack, so you have some back up options in case the first isn't available.


8

Helvetica is not part of any Windows default font-set, therefore Windows users are likely to see another secondary font. If that's not a concern for you, use Helvetica.


7

I cannot answer #2, but I can take a stab at #1 with some explanation. Background The Web Content Accessibility Guidelines (WCAG) 2.0 (the basis for Section 508 in the US, some international regulations, and the ADA guidelines that the DoJ has used in recent lawsuits) have some guidelines on this. Success Criterion (SC) 1.4.1: Use of Color: Color is ...


5

The requirement for running pages without CSS enabled is there to ensure that your pages make sense when the user is reading them via a non-visual device such as a screen reader. The problem here is that some screen readers do actually read what is on the screen while some read the underlying HTML. The first kind usually produce a chaotic stream of garbage ...


4

Messing around with standard application features (eg selecting text in a browser) is a bad idea in almost every instance ... the user expects to perform whatever action they've done. They can't, because you've broken it - ergo you've failed to meet user expectations. Simple as that. Personal rule of thumb: In all cases, disabling highlighting of text is ...


4

EM and PERCENT are both very similar, the only difference between the two can be observed when changing text size on the client browser. Summary In theory, the em and rem units are the new and upcoming standard for font sizes on the web, but in practice, the percent unit seems to provide a more consistent and accessible display for users. Original ...


3

I wouldn't say it is always a bad UI design, but scrolling is one of those things that should not be counter-intuitive and behave in a way the user does not expect. On a touch device, for example reverse scrolling feels natural (as you would drag paper UP to read DOWN. However with a desktop environment we have decades of training to tell us: Moving the ...


3

The best way would be not to use colour. In fact colour is not necessarily the best way to do it as it relies a lot on good eyesight (which designers usually have, don't forget). Here are some alternate ideas and ways of emphasising disabled state without using colour - these are suggestions, doing all would probably be overkill and observing users ...


3

I am sorry for answering instead of commenting but I lack the reputation. I don't think I understand your question. What exactly you want to know? As far I can see the website was build by front-end developer(s). It uses Node.js, socket.io, three.js for 3d rendering, TweenMax for the animation and navigation. Sites like this can be designed with tools like ...


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


3

The 2 most popular ways of indicating misspelled text are to underline it with either red dotted line or red wavy line – the practice adopted by word processors and browsers. The easiest way is to set dotted underline: just apply border-bottom: dotted 1px red property to your <span> element. The implementation of wavy line is a way trickier: http://...


2

Wow. I can't even reply to comments to my own response until I get 50 rep points? Talk about usability... @aames, all good questions. I fully understand the situation with your code base. Having worked at Salesforce in both a UX and Dev capacity, particularly around accessibility, I know what it's like dealing with legacy code and developers who don't ...


2

Andrew is exactly right (I can't comment yet, not enough rep points). The idea of CSS disabled is not meant as an actual browsing experience but to ensure that your content makes sense semantically and in the order it's presented because that's how, the better, screen readers evaluate the content. On the idea that the same group suggesting display:none is ...


2

One word for you: storyboards. I need to write an article about this. But here's what a good storyboard looks like as a jumping off point: Notice: two colors, one for actions, one for animations. The description below each wireframed panel describes what moves when why. You'll work off these, and things are bound to change as you enter dev, but for ...


2

A good way? No. Any verbal or text description will be open to interpretation. Methods that could work would include front end prototyping and/or pair programming.


2

You could, but assistive technologies handling of title tags isn't perfect (more on WCAG). A better solution is not to use a title tag and instead hide the element text using css. CSS: a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; } HTML: <a href="#"> <span>Washington stimulates economic growth </...


2

In terms of behaviour, there is no difference. The difference cited above is simply a buggy browser implementation, in my opinion. I just did a quick test in current Chrome and Firefox, and there is no difference in sizing of child elements : smaller; : larger when the parent is either 1em or 100%. I would very be surprised if this bug was present in any ...


2

Here your problem is what will happen when list increase. So short answer make it simple for the developer and for the user. Add 2 drop down (from, to) that will handle if lists go long and even as a developer it's easy to maintain in future. Current UI Users have to search for what they are looking for. If list goes long then it's difficult to ...


2

If the user is likely to use the same dictionary over and over, then put your selector in a prefs pane so they don't have to make that selection every time. They can then simply click or double-tap and see the translation immediately, in whichever dictionary they last chose. (Or in whichever dictionary you set as the default, before they pick one.) (One of ...


2

There is no silver bullet here, but from my experience there are only two solutions: Make a responsive layout. All elements are "rubberish", can adjust to the content without breaking the design. Layout is adaptive to browser page size. Work with translators to shorten the words. When translators are not clear on boundaries they come up with long words. If ...



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