We have a textarea field in a desktop client server application which in the end stores all the data in a database server, this text area is used to take notes and similar text areas have been put throughout our application as a marketing choice so that users can never blame the application for missing some fields and the marketing department can always answer “put it in the notes field”.
Recently however we realised some customers use the notes area heavily to write letters or copy paste documents, so we had to increase the notes field in the database from 1024 to 10240, we are realising however that this way the desktop application takes always more time to download all this backlog of information.
What is the compromise between giving practically no limit to user input length and letting the users use it as they deem necessary and putting a strict limit justifying the choice as “performance mandated”?
3
similar text areas have been put throughout our application as a marketing choice so that users can never blame the application for missing some fields and the marketing department can always answer “put it in the notes field”
Sloppy design leads to sloppy product (a “write-it-all-here” field actually used to “write-it-all-there”, what a surprise).
The compromise depends of the usage, there is no general rule (“560KB should be enough for everyone”). A few hints:
- Take your current data and find percentiles per size. Probably, a high percentaje of your records won’t need so much data
- Identify how people are using the field
- maybe some uses require its own data field, which could allow also for standardization
- follow-up notes should be in separate items, not in the same field used by the user. Most probably, an 1-N relationship with the original record.
to write letters or copy paste documents, any reason not to allow file uploads?
- Once you have dealt with these needs of your users and have provided them a better way to get them covered, you can reduce back the size of the text area.