User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We need an input in a table cell. Table is used for representation of the data. Table can be sorted, it has a border 1px. Depends on the business rule input will be either validated, accepted or disabled.

To my extent I come up with the solution of a textarea in the table. However this approach looks very backward to me, and I think there are other ways to design and structure the solution.

Let me know your thoughts with all pros and cons of each solution. And what impact and level of difficulty of the development process.

enter image description here

share|improve this question
Are you using a table for styling or why is the textarea there ? – Mervin Johnsingh Aug 16 '12 at 6:12
Table is used for representation of the data. Table can be sorted, it has a border 1px. – Jackie Chan Aug 16 '12 at 6:20
Can you provide a screenshot,it would be easier to visualize – Mervin Johnsingh Aug 16 '12 at 6:22
Thanks for quick reply but I can't provide. It's a policy. I will upload Balsamiq mockups – Jackie Chan Aug 16 '12 at 7:11
Looking at the balsamiq mockup, will you be also be displaying graphs and calender events in the textbox ? Or will it be just text – Mervin Johnsingh Aug 16 '12 at 8:31

It feels like you are mixing apples with bananas here, or in UX terms - the view with actions.

From a software design point of view, there should be a use-case of 'user edits X'. Users also benefit from the knowledge they are now editing something.

It seems that you are dealing with a very simple scenario here, as you did not mention commit/cancel options; but you did mention validation which could yield a message somewhere. Point being is that editing is more than just entering text, and related controls and messages need their own space, which will become an issue if these always exist next to a text area. Although your system may not need it right now, your suggested implementation will be hard to extend if new requirements arise.

Probably the best example against your idea is a spreadsheet - despite being an array of editable cells, only one cell is editable at a time and only upon explicit user action.

One can also easily predict issues with your solution - what if a user enters text in one text area then scrolls that area out of view? Any key strokes will alter data that is out-of-view.

My recommendation would be to keep the table representing the data, but allow an editor upon click / double click (the former could work if no selection is needed).

Depending on the editor complexity and validation/error feedback, you can choose between:

share|improve this answer

Your Answer


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.