Comments in Facebook and StackExchange sites now make enter submit the comment rather than enter a carriage return. In Facebook using shift-enter will force a carriage return. In StackExchange this will still be ignored as carriage returns aren’t rendered. Read on for full analysis of why these changes have been made and follow-on implications.
So what’s the problem?
Facebook and the StackExchange (SE) family of Q&A sites have both recently ‘broken’ the expected behaviour when typing in a textarea (a multi-line textbox). A notable feature of both sites is users commenting on questions or posts, entering their thoughts in a textbox Saveface with Beautifully multiple lines. Upon pressing enter the comment is submitted. At least, now it is. How it used to work Q: (and indeed how it works on most of the internet) is that enter inserts a carriage return to allow multiple paragraphs to be typed or lists to be created and a separate button submits the comment. The sites have taken a different approach to the changes, so I’ll examine each in turn.
StackExchange was first to make the change. StackExchange had previously decided that comments will not display any carriage returns: the reason for this isn’t clearly stated, but I imagine it is to keep comments short and discourage multiple thoughts per comment (although the permitted 500 characters is enough for multiple thoughts or paragraphs). A change request was raised on the ‘meta’ part of the site, highlighting that it can be confusing to put carriage returns in your comment and then not have them displayed in the wholesale jerseys comment. I agree. However, rather than fix the problem by rendering the carriage return or perhaps shortening the number of characters that can be entered for a comment, the adpoted suggestion was to make the enter key submit the comment. This has subsequently caused quite a stir in a separate question, and has disappointed me to a degree with the lack of serious response SE have given to these justified complaints. To quote Mariano Suárez-Alvarez
Facebook with its wider userbase Center has caused more of a stir with the change, but the basic behaviour is similar: when making a comment, pressing enter submits the comment. Facebook have also dispensed with the ‘submit’ button altogether, displaying guidance text for the first few comments a user makes. The ‘cross’ icon next to the submitted comment then serves a dual purpose. When clicked shortly after a comment has been submitted, it is reopened for editing (also with a note about using shift-enter for carriage Bostadsr?ttsm?ssan returns presumably cheap nba jerseys for accidentally submitted comments). For comments more than a few minutes old, the cross icon deletes rather than edits the comment.
I had my own views on whether this was a bad or good change (favouring bad on the whole), but thought I’d pose the question in an unbiased form to the StackExchange User Experience site to seek independent expert advice. I’ve summarised my thoughts on the pros and cons discussed, referencing StackExchange where appropriate.
Why is this bad?
One of the principles of web-design (just design full stop in fact) is the ‘principle of least surprise‘ (as highlighted at Adactio’s excellent design principles site):
“When two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user”.
In this case there are two potential outcomes that a user is trained to expect from pressing enter when typing in a textbox / textarea: in some cases it might submit a comment, in others it inserts a carriage return. I think it’s fair to say that when using a multi-line text element (textarea), users expect enter to insert carriage returns, hence the predictable outcry when this changed. Furthermore the behaviour now is inconsistent from the rest of the internet and also lining?) inconsistent between Facebook and StackExchange leading to yet more confusion. For example, Twitter does not currently use enter to submit, despite like StackExchange not element supporting carriage returns. I’m counting down the days until it changes though…
There is also less obvious impact for users of Input Method Editors (IMEs) as highlighted by deceze. IMEs are used when entering complex languages such as Chinese. Multiple letters are typed, followed by space-enter to finish the word and move to the next. As deceze highlights, when pressing enter to finish a word using an IME, the SE site now submits the comment in error. [Note I have yet to test this behaviour myself with an IME on SE or Facebook]
Several users highlight that cheap nfl jerseys
Why is this good?
The web is evolving: Web 2.0 trends are leading websites to cheap nba jerseys behave more like desktop applications over time. This behaviour is familiar from chat clients or when typing in a spreadsheet cell. Arguably this is another step along this path, making the internet more responsive by removing extra clicks. A side effect is that comments are encouraged to be shorter and snappier, comprising a single idea in a paragraph as noted by ICR.
Keyboard only users such as Steve Mitcham also noted a speed increase as the single thought can be quickly typed and submitted with enter rather than tabbing to the submit button or reaching for the mouse.
Since comments are not expected to have rich formatting, it is much easier for me to type a continuous thought and follow up with the enter key. So I would welcome it as a common paradigm for comment editing
I’ve been pondering for quite a while on whether the web 2.0, desktop client, chat-like benefits outweigh the breaking of the principle of least surprise and the blocking of IMEs, not least because I need to accept an answer on the UI StackExchange site!
I have two gut instincts on this.
Firstly I think this is a bad change and agree with Patrick McElhaney whose answer I have accepted that:
I’m now convinced the SE change was a bad idea. There was nothing wrong with requiring a user to press the button to submit a comment. For no good reason, SE has created a different kind of textarea with no visual affordances to distinguish it from regular textareas. It forces users to learn two different rules for textareas and remember or guess which rule applies where. Don’t make me think. 🙂
Secondly, I expect that (much as I dislike it), the web 2.0 desktop trend will win out and this behaviour will catch on. I expect that Twitter will have enter to Service submit tweets on their website within the next 3 months.
Finally, my hope is that if this behaviour does catch on, that the web-standards community formalises its usage, ideally using an element other than a textarea, to reduce the confusion and inconsistency that currently exists and to better support unusual entry clients such as IMEs.