VisualEditor: Edit summary box should be a text input box and not textarea
Closed, DeclinedPublic

Description

Author: KilliondudeWP

Description:
The edit summary box currently uses a textarea input box. Current functionality has the return key starting a new line in the textarea, but upon save the edit summary is truncated into one line in the page history (line breaks are turned into spaces). Thus, the textarea box is misleading.

A more sane option would be to use a single line text input box, where the enter key processes the edit rather than starts a new line.

See T40042 and T42034, and specifically T42034#467450.

bzimport added a project: VisualEditor-MediaWiki.Via ConduitNov 22 2014, 1:54 AM
bzimport set Reference to bz52133.
bzimport created this task.Via LegacyJul 27 2013, 4:37 AM
bzimport added a comment.Via ConduitAug 1 2013, 7:08 PM

KilliondudeWP wrote:

Another issue brought up with having a text area box is that previously entered summaries are not suggested. Most browsers suggest prior terms entered into text input boxes, this allowing editors to choose from their (frequently) used summaries.

https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Improvements&oldid=566754323#Autofill_edit_summary

Jdforrester-WMF added a comment.Via ConduitAug 1 2013, 8:20 PM

By making the summary a textarea rather than an inputbox we've seen a radically-greater number of editors (especially, anonymous and new editors) entering edit summaries for their edits. I think we should think very seriously about the impact of such a change before just making it.

bzimport added a comment.Via ConduitAug 2 2013, 3:39 AM

sk8er_97456 wrote:

I seriously doubt that that is the reason you have a higher incidence of edit summaries. What you did in parallel to making it a textarea was that you hid the "Save page" final submit button behind a dialog that prominently presents the box for an edit summary. Users no longer feel free to skip a mysterious text box and click "Save page" right away, the look and feel of the modal dialog forces them to consider filling it out in full before proceeding. That's why you're getting more edit summaries.

Jdforrester-WMF added a comment.Via ConduitAug 2 2013, 3:55 AM

(In reply to comment #3)

I seriously doubt that that is the reason you have a higher incidence of edit
summaries. What you did in parallel to making it a textarea was that you hid
the "Save page" final submit button behind a dialog that prominently presents
the box for an edit summary. Users no longer feel free to skip a mysterious
text box and click "Save page" right away, the look and feel of the modal
dialog forces them to consider filling it out in full before proceeding.
That's why you're getting more edit summaries.

Sure, but collapsing the box down to a single line would de-emphasise the edit summary, however, and turn it back into "a mysterious text box" that uses "feel free to skip".

bzimport added a comment.Via ConduitAug 2 2013, 4:41 AM

sk8er_97456 wrote:

Sure, but collapsing the box down to a single line would de-emphasise the
edit
summary, however, and turn it back into "a mysterious text box" that uses
"feel
free to skip".

Why would it?

It's still hidden behind a modal dialog. I will wager that editors still feel forced to fill it in simply because it is there.

Jdforrester-WMF added a comment.Via ConduitAug 2 2013, 6:01 AM

(In reply to comment #5)

> Sure, but collapsing the box down to a single line would de-emphasise the
> edit summary, however, and turn it back into "a mysterious text box" that
> uses "feel free to skip".

Why would it?

It's still hidden behind a modal dialog. I will wager that editors still feel
forced to fill it in simply because it is there.

The numbers went up when we switched from inputbox to textarea. Expecting them not to fall when we reverse that change seems unlikely to me.

bzimport added a comment.Via ConduitAug 2 2013, 10:40 AM

JohnCD67 wrote:

Killiondude's comment 1 is an significant usability point - for repetitive tasks it is very helpful that the browser pops up a list of suggestions to click on, which is context-sensitive and based on previous usage. I did not realise how helpful that was until with VE I found myself having to type the full edit summary each time.

PamD added a comment.Via ConduitAug 3 2013, 9:19 AM

Bug 48274 seems to cover the same ground, and was one of the first things I found problematic with VE: those of us who do a lot of regular work on many different articles usually have a set of standardised edit summaries which can convey a lot of useful information, with links, to help other editors. The autocomplete facility provided by browsers for a one-line input box worked well.

Amire80 added a comment.Via ConduitAug 28 2014, 5:39 PM

Is it possible to meet in the middle: To show it as a textarea, but to allow saving using Enter/Return? And maybe provide autocomplete?

Spinningspark added a comment.Via ConduitSep 22 2014, 1:18 PM

(In reply to Amir E. Aharoni from comment #9)

Is it possible to meet in the middle: To show it as a textarea, but to allow
saving using Enter/Return? And maybe provide autocomplete?

That will lead to another problem: newbies will accidentally save before they have finished entering the summary.

The fact is, the edit summary *is not* a text area and should not be displayed as such. It can only ever be a single line of text. That is what should be shown. Enter should initiate a save.

Spinningspark added a comment.Via ConduitSep 22 2014, 1:45 PM

(In reply to Spinningspark from comment #10)

However, the input box should be large enough to accomodate the maximum permitted length of edit summary, even if that means using two lines.

Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 4:24 PM
Ypnypn added a subscriber: Ypnypn.Via WebMay 15 2015, 5:09 PM
matmarex edited the task description. (Show Details)Via WebMay 16 2015, 1:58 PM
matmarex set Security to None.
Neil_P._Quinn_WMF added a comment.Via WebMay 18 2015, 7:46 PM

Just merged in very similar task arguing that enter should submit the summary field. (On a similar note, I've proposed using meta + enter as a general shortcut for submitting dialogs in T98105.)

Good points in the comments:

@matmarex:

This could be confusing since the summary text field looks like a multiline text input, possibly causing users to accidentally submit with incomplete summaries (which can't be corrected afterwards).

It could be interesting to try something else – maybe pressing Enter twice to submit the form, maybe Ctrl+Enter? We should probably do some research.

...

  • Facebook: comments to posts on the timeline are normally single-line (pressing Enter in the text field submits a comment), but you can make them multi-line by pressing Ctrl+Enter or Shift+Enter (or by copy-pasting text with newlines). Pressing Enter submits the comment even if it is multi-line.
  • My bank has these "wrapped single-line" inputs in some fields and pressing Enter always does nothing in them. Accidentally submitting a form could potentially have dire consequences there.

@Deskana:

For the advanced user, the current approach where enter adds new lines is counterintuitive. The advanced user not only knows that edit summaries cannot be multi-line, but it also feels wrong because they're also used to enter submitting their edit.

For the new user, the current approach feels misleading, as you're giving the user an expectation that edit summaries can be multi-lined when in fact they cannot. This user has no expectations about enter submitting the edit, so probably doesn't care too much about that.

I think the best approach would be to make the edit summary box single-line, and make enter submit the edit.

matmarex added a comment.Via WebMay 19 2015, 2:31 PM

For comparison. The last one looks positively tiny. We'd need to come up with something smart if we were to make it single-line.

Current edit summary field
Wikitext editor edit summary field
Proposed edit summary field (single-line)
Deskana added a comment.Via WebMay 19 2015, 8:56 PM

For comparison. The last one looks positively tiny. We'd need to come up with something smart if we were to make it single-line.

That's not necessarily a bad thing. We want users to be fairly brief with their edit summaries, and bigger boxes are more likely to encourage them to write more. Smaller boxes encourage the opposite.

That said, we'd have to be sure that the user's attention isn't drawn to the wrong place; in the last screenshot, the box is so small that the user's attention may not immediately be drawn to that text box. You could try try making the font in the box slightly larger, and slightly increasing the width of the dialogue to compensate.

MSGJ added a subscriber: MSGJ.Via WebMay 21 2015, 2:54 PM
awight added a subscriber: awight.Via WebMay 21 2015, 7:32 PM

@Deskana, I'm curious why you say that,

We want users to be fairly brief with their edit summaries

Deskana added a comment.Via WebMay 21 2015, 7:34 PM

@Deskana, I'm curious why you say that,

We want users to be fairly brief with their edit summaries

Edit summaries are intended to be quite brief summaries of the edits. I don't think encouraging users to write a lot of text in there is a good idea.

awight added a comment.Via WebMay 21 2015, 7:50 PM

Okay, I understand where that's coming from. On the other hand, sometimes it's really helpful to have a brief summary sentence, then a few more paragraphs of relevant things which fall into the "why" category and are therefore more appropriate in a summary or the Talk page than in the main article.

How would you suggest we broaden this discussion? I'm not sure this is the right place, and donno if wikitech-l is the best mailing list, cos we should involve editors.

Deskana added a comment.Via WebMay 21 2015, 7:58 PM

Okay, I understand where that's coming from. On the other hand, sometimes it's really helpful to have a brief summary sentence, then a few more paragraphs of relevant things which fall into the "why" category and are therefore more appropriate in a summary or the Talk page than in the main article.

Well, edit summaries are limited to around 200 characters. Changing that limit would involve redesigning the UI, which is doable, but is a fairly big undertaking that should only be done if there's some specific need to change this. I don't think there's a need for that.

How would you suggest we broaden this discussion? I'm not sure this is the right place, and donno if wikitech-l is the best mailing list, cos we should involve editors.

I expect that the product folks in the VisualEditor Team will take our input then make an appropriate decision. :-)

Whatamidoing-WMF added a comment.Via WebMay 21 2015, 8:40 PM

The last thing I heard is that making the edit summaries any bigger required redesigning the database (yes, that database), not merely the user interface.

Whatamidoing-WMF added a comment.Via WebMay 21 2015, 8:44 PM

I've said this in several places, but I repeat it here: I don't care what size or shape the edit summary box is on my computer screen.

I care whether it behaves like the wikitext edit summary in terms of interacting with my web browser. I want to type a complex edit summary once, and have that edit summary automagically re-appear whenever I start typing it on my next edit. If you can give me that useful function while making the box a perfect square, then I'm satisfied. I need the function, not the appearance.

Quiddity added a comment.Via WebMay 21 2015, 11:25 PM

I care whether it behaves like the wikitext edit summary in terms of interacting with my web browser. I want to type a complex edit summary once, and have that edit summary automagically re-appear whenever I start typing it on my next edit. If you can give me that useful function while making the box a perfect square, then I'm satisfied. I need the function, not the appearance.

Yup. IIUC, changing the textarea to a text input line, will solve T50274: VisualEditor: For edit summary field, give users an auto-fill drop-down (or similar) of recent edit summaries they've used (possibly that should be listed as blocked by this?)

Re: keeping it visually highlighted - do note that the textarea has the bright blue border now, when the field is active, which it is automatically when opened, (but not shown in matmarex's screenshot above), and I think that could be sufficient.

Spinningspark removed a subscriber: Spinningspark.Via WebMay 21 2015, 11:29 PM
matmarex added a comment.Via WebMay 22 2015, 9:54 AM

I think I have a pretty good idea on how to implement this, I'll try to do some pre-hackathon hacking on it today.

gerritbot added a subscriber: gerritbot.Via ConduitMay 22 2015, 4:42 PM

Change 212795 had a related patch set uploaded (by Bartosz Dziewoński):
Allow wrapped singleline inputs

https://gerrit.wikimedia.org/r/212795

gerritbot added a project: Patch-For-Review.Via ConduitMay 22 2015, 4:42 PM
matmarex added a comment.Via WebMay 22 2015, 4:44 PM

The idea may or may not actually be a good one. It's definitely interesting. The gist is that we dynamically swap the <input type=text> for a <textarea>. It has some funny behavior but sort of works.

The patch above makes it impossible to type a newline into the field, and should let it display the automatic browser's autocompletion when it is single-line. Ed mentioned that it can break with IMEs if you're typing a word and it changes from input to textarea in the middle of it.

gerritbot added a comment.Via ConduitJul 20 2015, 11:19 AM

Change 212795 abandoned by Bartosz Dziewoński:
[WIP] TextInputWidget: Allow wrapped singleline inputs

Reason:
This is not going to be compatible with different text input methods.

https://gerrit.wikimedia.org/r/212795

matmarex closed this task as "Declined".Via WebJul 20 2015, 11:30 AM
matmarex claimed this task.

As discussed on the patch, assuming that we want the text to wrap, this is not actually possible to do for most languages, and an English-only half-solution would be inappropriate. Browsers are really letting us down here.

As I understand, there are two reasons why we would want this, which have separate tasks:

We should focus on resolving these, which should be possible regardless of the underlying text field used.

Ricordisamoa added a subscriber: Ricordisamoa.Via WebJul 20 2015, 12:53 PM
Ricordisamoa added a comment.Via WebJul 20 2015, 1:33 PM

How about making it an input box and just set padding-bottom to make it feel like a textarea?

matmarex added a comment.Via WebJul 20 2015, 2:09 PM

Such input box will still not wrap the typed text, which is terrible enough by itself for users, and even worse in VE than in wikitext editor because the input field is narrower.

Ricordisamoa added a comment.Via WebJul 20 2015, 2:29 PM

even worse in VE than in wikitext editor because the input field is narrower.

Putting a (wider) summary box in the main editor UI would solve T52961: VisualEditor: Provide simultaneous access to editor and edit summary as well.

Add Comment