Feature request: Field behavior

John_muccigrosso

Some fields behave in odd ways, IMO, WRT sizing.

For Book Sections, the Book Title field is nice and big...until you click in it when it shrinks. I don't think I've ever seen that in another app.

Title is really big when you click on it, then shrinks to the minimum size when you get out of it. That also seems odd to me. I'd expect it to expand

Abstract gets big like Title does, but then shrinks to one line. This strikes me as the most "normal"behavior of the three.

dstillman

For Book Sections, the Book Title field is nice and big...until you click in it when it shrinks.

All fields other than Title, Abstract, and Extra are a single line when selected, since they generally take short values. It's a bug that Book Title isn't treated like those three fields, and I've created an issue for that.

Title is really big when you click on it, then shrinks to the minimum size when you get out of it. That also seems odd to me. I'd expect it to expand

Not sure what you mean here. When not selected, Title behaves like all other fields, expanding enough to show the full content. The only difference is that, like Abstract and Extra, when selected it gives you more room to type in, because longer values are expected.

Abstract gets big like Title does, but then shrinks to one line. This strikes me as the most "normal"behavior of the three.

You can click on the "Abstract" label to expand and collapse the content.

DWL-SDCA

When I click in the title field and select or all of the text, the wrap or line break is different from the unselected text. It is almost as though the character size or the kerning differs depending upon the selection status of the text. There are two ways this makes it difficult.

When I see a title in title case that I want to convert to sentence case and there are several-word place, association, or other names; rather than convert the entire text, I cut the words that should remain with upper case characters, convert the title to sentence case, and paste the cut text in the proper place. When text is selected, the word that was at the end of the line in unselected text is moved to the next line of text.

Sometimes an item has both an English language title that is imported into Zotero but also has a title in the original language. My practice is to manually copy the other language title after a spacer character into the title field.

I hope that the word wrap difference will go away when a new editor version is included with a future Zotero update.

John_muccigrosso

Not sure what you mean here. When not selected, Title behaves like all other fields, expanding enough to show the full content. The only difference is that, like Abstract and Extra, when selected it gives you more room to type in, because longer values are expected.

Yeah, I'm not sure what I meant here either. :-)

I just realized that Publication and Library Catalog (and so probably other fields) behave like Book Title: they shrink to one line when being edited, regardless of how long they is when you stop editing. I don't think any fields should behave like that.

BTW, it's also unexpected that when editing a field clicking in the rightmost panel, but outside of a field does not take the focus out of the field it's in. For most fields a return will do that, but not Abstract. The one exception to this seems to be clicking on the field's title, which will also end the editing.

You can click on the "Abstract" label to expand and collapse the content.

Good to know. From a UI perspective, I'd have expected one of those triangles that switched from right-pointing to down-pointing to indicate that this field can be expanded. The parenthetical ellipsis didn't mean anything to me. I realize that that triangle is used in the author field to indicate a drop down, but there should be another way to show that.

dstillman

I just realized that Publication and Library Catalog (and so probably other fields) behave like Book Title: they shrink to one line when being edited, regardless of how long they is when you stop editing.

Right, but as I say, it's rare for those to be longer than a single line, so this generally isn't an issue. In any case, it's mostly a technical limitation with the way editing currently works — the options are a single-line input field (as used in most fields) or a multi-line input field with a fixed number of rows (as used in Title/Abstract/Extra), and neither automatically adjusts to the length of the content. (Example: this form.) Could be made to work, but the real fix here will just be switching to a different input mechanism in a future version.

For most fields a return will do that, but not Abstract.

In Abstract and Extra, where you need to be able to enter newlines in the text, Shift-Enter closes the field. Not sure what you mean about clicking — clicking outside the field should always close it.

John_muccigrosso

Clicking outside fields doesn't close them for me.

I don't mind some fields being minimized to one line when not in edit mode (though Publication doesn't do that), but it makes no sense to me to have them shrink to one line when being edited. As I said, I don't I've ever seen that elsewhere. Why not have them behave like Abstract even if without the way to expand them.

Glad to hear there will be a new input method.

dstillman

Clicking outside fields doesn't close them for me.

You can start a new thread for that, and describe exactly where you're clicking and what's happening. You're saying you have to press Enter? That's definitely not normal behavior.

it makes no sense to me to have them shrink to one line when being edited. As I said, I don't I've ever seen that elsewhere. Why not have them behave like Abstract even if without the way to expand them.

Because, again, almost all fields are generally a single line, so clicking just toggles between an uneditable and editable field in-place without creating a huge text area that shifts the whole view.

Even when we switch to a new text input method, all but the few fields that are expected to be longer would start as a single line in edit mode and only expand to multiple as more text was typed into them.

John_muccigrosso

Because, again, almost all fields are generally a single line, so clicking just toggles between an uneditable and editable field in-place without creating a huge text area that shifts the whole view.

(I find that the Publication field is frequently more than one line, though I don't much mind that it's shortened to one when viewing.)

My problem is that having the field _shrink_ to one line when editing is strange and undesired behavior. It makes it much harder to edit, and in fact it does shift the view of everything below it - though I don't think that's a problem.

Even when we switch to a new text input method, all but the few fields that are expected to be longer would start as a single line in edit mode and only expand to multiple as more text was typed into them.

This would be an improvement over the current behavior, so I look forward to the switch.