View Comments (10)

• they see user experience from behind, that's why u see this!

• +alireza hosseini yes, they probably have stats on how many people give up after trying to fit a message in there :)

• Me. I'm the guy that makes those types of decisions. Although usually it's a 255 character limit.

• so how do you end up with such a decision +Ian Zepp ? :)

• [Long discourse ahead. Fortunately G+ has no 128 char limit on comment boxes]...

  There are a number of technical and business reason why this limit might be here. In no particular order:

  Technical reasons:
  - It's an old field, from an old software version, was size-determined years ago, and maps to a fixed width database column.
  - If you change the table column size, you maybe have to rebuild the table.
  - You could change to a varchar, but then that probably affects your indexing and other existing internal and external code that depends on the field type.
  - There are likely third party vendor integrations that may themselves have max size limits. Changing the size of this field means you now have to retest all those integrations.
  - For an integration, it's likely this field is exposed via WSDLs. Changing the size invalidates those WSDLs.
  - Automation (business rules, workflows, emails, etc) certainly depend on this field. Some of those expect data no larger than a certain size from this field. Again, cascading changes.

  Business process reasons:
  - The longer the field, the harder to search/report on data. Analytics would rather have data in fixed-option dropdowns or checkboxes than scattered throughout text fields.
  - This form almost certainly creates a new case/issue for customer support (that's the point, really). Those cases will already have support for case comments internally, and THOSE fields will probably have much larger limits.
  - If you give people the chance to write an essay, a lot of times they will. Keeping the field size small forces a concise summary, and pushes a lot of the supporting data into either the case comments or into the fixed-option fields.
  - Most of the time the text in the box isn't really useful. "It's broken when I do this!" isn't something that really helps. So the box is partially there as a placebo.

  So, there are lots of reasons (some valid, some legacy, some cost-of-change) why it might be that way. :)

• thank you for the analysis +Ian Zepp but you can't describe a problem in 128 characters. in that sense, a support form is the first step to helping the user. if this isn't achieved, there is no point to having a support form

• Have you run analysis of support form average comment lengths? It's quite possible that within a standard deviation or two, most comments fall under 128 characters, and longer issues belong in a case comment, instead of the initial form submission. There is a very real cost to changing architecture once it's in place and other support systems are built around it. You are a sysadmin, you know this. And in the case of this specific screenshot, Cisco WebEx is a large, old, and complex product.

  While at a basic level I agree that the comment size should be larger, you asked why someone would make that decision. That's why people make those decisions. :)

• well i just run a quick query on one of our systems, the average message is 310 characters :)

• Then it wouldn't work for you. But is that correlation or causation? :p Anyways, not going to argue to point any more.

• LOL i'm sure if Cisco does a query they will find that all their messages are below 128 chars so there is no point to make a change :)