1

I am designing desktop application. In that application user can edit name of model or component.

The question is do I prevent user from entering garbage text (such as paragraphs of text) that will cause application to look ugly on some occasions or do I somehow edit the text by removing new lines and reducing number of characters.

I am afraid that if I do some editing user might be frustrated by the application.

Currently the application works on rule "garbage in garbage out" that means if you enter ugly text that is what you get in return.

P.S. Ugly text do not cause any errors in the application and is totally valid model or component name.

  • You can prevent most of these issues by using a single-line textbox, rather than a multi-line one, and limiting the number of characters. Further limits on actual characters valid may be okay or not, depending on how your users intend to use it. – Steve Jones Mar 16 '16 at 8:16
2

This feels related to ellipsing labels. (not a duplicate of) You've got user-generated text of unknown length, and you don't want to display more than a certain amount.


The possible solutions

Do nothing. Just use the text as typed.

+ Simple. Can lead to many errors.

Limit text length. Force users to edit their text to be shorter.

+ Control, good looks More user effort. Missing some information.

Automatically truncate text. Use a simple script to delete excess text.

+ Only implementation effort, good looks. Missing some information. High chance of broken sentences. Unexpected endresult for user.

Automatically hide long text. Hide excess text behind a "show more" button. Either show inline or link to separate page.

+ Only implementation effort, good looks, all text. Will still give errors after interaction. Button will take up space.

(Personally, never automatically truncate text. Either let users edit, or have toggle to show/hide the remainder)


Decide what you want

You'll have to answer several questions, and then you have to decide whether you want to limit the text, automatically truncate, have a 'show more' button, or just let the text flow freely.

  • Is the endresult aimed at consumers, b2b, or internal usage? The more public, the more looking good matters.
  • How much do you trust your user? Would they just copy, paste, post, or are they going to think and edit?
  • Is the text picked from a centralized database, so you should conform to that?
  • How bad is the 'breaking'. Will text run over a flat colored background, or interfere with pictures? Will it just break the textbox or the whole layout?
  • What does it cost you? Solving issues elegantly can take more time to develop.
  • What does it cost them? How much extra time will it cost the end user to input new data? What's the potential CPU impact?
  • How often do you expect the problem to occur?

Communicate the problem

No matter which solution you pick, you should tell users what's happening, and why.

enter image description here

Twitter won't allow me to post over 140 characters and it highlights excess in red. It also lists the exact amount of characters that I need to remove.

Facebook is more lenient. I can copy thousands of words in to a post and I can submit it, but it shows me an alternative format which might look better.

Similarly, you should inform the user of the expected amount of text. Tell them how many characters is good. Show when they're using too few, enough, almost too much, or too much. Tell them what problems might occur; the text will stretch the layout, it will run over images, it will get resized to a terribly small font. You needn't do all of these, just make sure users know what will happen.


Can you show a preview?

A picture says a thousand words.

If it's possible to show a WYSIWYG preview of the endresult, or at least a mockup of it, people will much better understand the issue, and they can at a glance decide if they're okay with it.

enter image description here

The above image is easier and faster to comprehend than just an error message:

using more than 5 lines will break the layout.

This leaves some wiggle room

You might want to have a roomy 32 pixels worth of whitespace around your text, but maybe your users will squeeze in just that one extra line at the bottom, keeping it in bounds, but with only 16 px of whitespace. This is something that's hard to decide ahead of time.

And word/line lengths aren't always easy to predict either. HTML still has heaps of problems with hyphenation, justification and kerning. Even the amount of characters doesn't translate to text length very well:

wwwwwwwwww - 10 w's

iiiiiiiiii - 10 i's

So sometimes you can fit 200 characters in, sometimes 220. Why not let the end user decide?

0

You could restrict the number of characters to a limit and provide a post-note to the user requesting him to click a button (which you might have to add to your design) if he wants more space. Now, this button should redirect him to a big text-box, where he could type in the Bible, if he wants. Get the data from the user and check if it contains garbage. Also, prior to clicking the button, you could ask him to provide his input in a single line. So even if it is gibberish, it wouldn't look ugly on your application.

This is an example,

  1. When the user wants to log a complaint:

enter image description here

  1. When the user wants to add more than 100 words, he clicks the button, and this happens:

enter image description here

This is a possible suggestion. Hope I could help. Cheers.

0

I'd say that depends on the type of data you want to get from your user. If you're saying they can enter names and you have valid reasons to believe that these names usually wouldn't exceed a certain character count or have line-breaks, then I think you have every reason to prevent your user from inputing this kind of data in the first place, also as a means of helping your users to avoid entering faulty data by mistake. If you do this, you should give your users a comprehensible reason why you are not accepting these inputs.

However, what you shouldn't do is prohibiting bulky data solely on the grounds of avoiding having to come up with a good strategy of how to display it properly.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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