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

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.

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.

(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".

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.

(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.

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.

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.

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?

(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.

(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.

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.

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)

In T54133#1296269, @matmarex wrote:

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.

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

We want users to be fairly brief with their edit summaries

In T54133#1302396, @awight wrote:

@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.

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.

In T54133#1302437, @awight wrote:

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. :-)

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.

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.

In T54133#1302510, @Whatamidoing-WMF wrote:

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.

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.

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

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

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.

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

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

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.

In T54133#1465077, @matmarex wrote:

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.