Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm writing an internal web application to generate subtitle text for videos. Part of the requirement for this project is that each line not exceed X characters, except where circumstances warrant.

I don't necessarily want to prevent the user from entering more than X characters, but I do want to show them that they are approaching (and then possibly exceeding) that number.

Ideally, they won't normally go over the limit. The application is to be used in-house by those who have received some level of training in best practices, or who have done this type of work before. I attempted to bring my own experience to the project, as I have done this sort of work before myself.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Method 1 - Counting Up

I implement a character counter beside the text input field which counts up from zero, restyling to show that they are approaching the limit, and then again in some dramatic way to reflect that they have gone over the limit.

Method 2 - Counting Down

I implement a character counter beside the text input field which counts down from the limit, and then restyles to show that they are going over their limit by n characters (say, by using negative numbers)?

Method 3 - Purely graphic cues

I implement a progress bar underneath the input field which fills to the soft maximum number of characters and which then restyles to show that they have gone over the limit. In this method, the exact number of characters by which they have gone over can be concealed from the user.

I have a strong preference for the progress bar, or for counting up, mostly because captioning is extremely cognitively taxing and I don't want the user to be overly distracted by exactly how many characters they have left until it actually becomes a problem. Furthermore, after 2 or 3 inputs, the user has developed a good idea of how much they can type, reducing the need for this warning mechanism.

mockup

download bmml source

Additional:

Regarding Ben Brocka's comment: Twitter and SE's comment counter is exactly what I don't want to emulate, actually. In both, you enter only one message which you can craft carefully over a few minutes. In that circumstance, having a counter is appropriate because you have a strictly-enforced maximum, and every single character matters. In my scenario, users have mere seconds to enter text and shouldn't (really, ever) have to drag their eyes across to a numerical counter. My case is also different in that it tracks a soft maximum: we don't really care if it sometimes goes over by 3 characters.

Additionally, the only reason the style change of SE's comment box character counter is obvious without looking directly at it is because it contains the words "characters remaining", making it a fairly large area whose colour change can be perceived without looking at it directly. I should have mentioned originally that the layout of this page will probably end up being fairly tight.

Edit 2: Now that I think about it, a large number beside the input field (the red 16 in my mock-up) is probably perfectly easy to read.

share|improve this question
    
Can you provide an image to what you currently have in place? –  JeffH Apr 4 '12 at 18:31
2  
Twitter's method for this is pretty sweet, and Stack Exchange's is alright as well. Do you find anything wrong with either of those systems for your situation? –  Ben Brocka Apr 4 '12 at 18:34
1  
@BenBrocka My response was too long to post in a comment, so please see my edit. I drizzled my question with some balsamiq as well ;) –  msanford Apr 4 '12 at 19:28

8 Answers 8

up vote 12 down vote accepted

Something I have seen code syntax highlighters do is to indicate long lines of code by changing the color of text that exceeds the limit, something like the below:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

The advantage of this method is that it takes up no additional space. However, it doesn't give any indication of how close they are to reaching the limit, but I think users will quickly get a feel of how much they can enter before reaching the limit.

share|improve this answer
    
That's a neat idea. I wonder how I might implement that... –  msanford Apr 6 '12 at 20:41
    
@msanford Google Autocomplete adds gray text to the end of your query in the search box sometimes (when it's pretty sure that that was what you wanted to type), you could look at how they do that. –  Na7coldwater Apr 6 '12 at 22:55
    
@msanford: what technology are you using? –  sergiol Jul 18 at 23:46

Since the soft limit seems to be based on available space and not an actual character count, why don't you just display that visually? Give them a full text box to work with and an overlay that displays the limited space.

Textbox with boundary showing overflow text

share|improve this answer

let me start with saying that the count down is wrong from my point of view. The problem I see here is that you count down to 0. This would suggerate the user that he reached the absolute limit. As you just want to indicate a proposed max. that's not what you want.

I like the other two ideas - and find the progress bar interesting, though it might e quite unconventional (which doesn't mean bad :) Make sure you inform the user about the suggested character max. in form of a static label above the entry field. indicate the characzers already used and put them into relation - in both directions - even if the user goes over the limit. In case of the bar, the scale should still grow when more characzers are used as recommended.

In general, I think use of colors would make perfect sense here

share|improve this answer
    
Thanks for your comment. I basically have the same mindset. I mentioned in my question that this will only be used in-house by trained staff (i.e., less than a handful of people) but I will certainly still have to include a cue somewhere of where the progress bar is moving toward. –  msanford Apr 4 '12 at 19:32
    
Progress bar is a nice idea, if designed nicely. Simple math to calculate percentage of charatcers used against the limit, and animate the progress bar accordingly. Simples. –  PaparazzoKid Jul 24 at 22:01

the text field should be wide enough to accomodate the recommended amount of text, and no wider.

i'm assuming that the limit is meant to be about equal to the width of the video player, so style the input field so it matches the font size and typeface of the displayed text, and make it the width of the video player. when the text starts overflowing the entry field, the user will know they've gone too far

any cues like colour or progress bars are going to have to be learned, and a countdown will make it hard to communicate that it's a soft limit. limiting the actual size of the input is immediately obvious.

share|improve this answer
    
+1 for actually considering the case in question and coming up with what seems to me personally the best resolution to the problem –  Roland Tepp Apr 11 '12 at 20:09
    
Modification of this, rather than posting my answer which be nearly duplicate. Do this, but have a different colored background starting where the input would hit the soft maximum. That way they can still see their whole message, and type over it, but there is a clear line where they know it's time to wrap it up. –  aslum Apr 23 '12 at 16:14

JavaScript to display number of available characters left as you type?, follow Twitter UI and denote a "soft" exceed with a "-" sign.

Blah, this is me typing

(-6 characters, too long!)

share|improve this answer

I've used a progress bar in this type of situation with mixed results. Most people seem to understand the purpose of the progress bar, but they are upset when it's not exactly precise due to technical limitations of measuring variable width fonts. Also, progress bars have a hard limit metaphor built in.

share|improve this answer
    
Thanks! The hard-limit metaphor of a progress bar is a great point to bring up, but it isn't really a big concern. Also, it's only counting characters, not absolute presentation width (which I brought up internally as somewhat of a problem), so precision won't be an issue, at least for now. –  msanford Apr 4 '12 at 19:31
4  
Instead of a progress bar you could try a change in the border style color on the input field. Green -> Yellow -> Red based on characters remaining. –  sirtimbly Apr 4 '12 at 19:44
    
You could a progress bar and show progress towards the optimum value, but if they go over that then you are effectively redefining what 100% is -- so lengthen the full progress bar (and possibly change its colour). –  Andrew Leach Apr 4 '12 at 22:27
    
@sirtimbly I like that idea! I had another idea involving a colourized widget in the place of the number (the red "16") but this is far more elegant. –  msanford Apr 5 '12 at 13:54
    
@AndrewLeach Also an effective strategy. –  msanford Apr 5 '12 at 13:55

Why not a simple text?

Suggested maximum amount of characters left (x) (i)

The x represents a counter, and the (i) represents an icon that, when clicked, gives more info and a well designed/worded example of why this soft maximum is there. Make the counter number green when OK and orange when going over the soft limit. That's not as dramatic as red, but still grabs attention.

I have a feeling you/we are maybe trying to over-engineer this one. Especially since you mention on the job training. These are people (I imagine) that have some affinity with the work they are doing (writing/typing subtitles).

share|improve this answer

Have you thought about providing commentary as users type? When users hit or approach the soft limit, perhaps a small, unobtrusive, yellow callout with:

"be careful, this caption is probably too long to fit on the screen"

If they continue onto an unreasonable level of characters:

"this text will not format on screen correctly, if possible, cutting back is advisable"

Ideally you'd want the callouts to fade away if the user continues to type, perhaps changing the input box border to yellow/red to indicate the issue, and show the callout on a long hover of the input box.

The advantage of this is that you're upfront with users on why this is an issue, so even an untrained user will understand not to caption too long unless absolutely necessary. It also makes it clear that you're only advising the expert user, rather than dictating their behaviour.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.