Text with title

[Bidmaron]

Databases can have computed fields in most implementations. Why not display it so that it all looks like one field, but when you go to edit, it breaks it out into two separate columns as in #2. When user clicks to edit, it should be relatively simple to figure out whether he clicked in the heading or the text and put the cursor/selection into the proper field.

What I'd probably do is z-order the two fields with the heading on top. When user goes to edit mode, I'd insert enough spaces in front of the text so it appears to start to the right of the heading. If the user edits the text and tries to delete these justification spaces, I'd force them back in. Kind of code-kludgey, but it should work.

When we get styles we can apply to things, the program should remember what the default style is for a heading and for the text and use those unless user overrides.

[Bluephoenix]

option 2 sounds perfect, especially since it shows that "everything right of this label and whitespace" is the snippet that relates to the label. it also has precedence in many other database type programs and form layouts, so should be familiar.

[Farling]

I see the main reason for this feature is to put prefix/heading on the left of the main text. My intention would be to keep the prefix short and let the text body auto-adjust its left column based on the size of the prefix/title.

The existing sections allow for headings that appear above text.

[Cornelius]

There are two examples where I would use this:
1) Event: <date> <Text>
2) Holdings: <text>

I would think option 2 would be the best for me. the 'waste' would depend on the length of the label. Most of the time I would use only one or two words.

Currently I use the section/subsection option, but it now looks like this:
2. Family holdings
2.1 Demesne
<text>
2.2 Enfeoffed
<text>

While I would like to have it look like this:
2 Family holdings
Demesne: <text>
Enfeoffed: <text>

the <text> in these cases is just a list of names of manors, towns and counties. Most of the time it is only 1 line long.

[Kendall-DM]

Seeing as this functionality is already kind of in place, how about using a tag type for this, where the tag only displays the tag itself. For example, a tag type that is Descriptor, that has Name, Ethos, Race, Personality, etc. However, unlike other tags, this tag should only show the Descriptor name, and never the Descriptor label itself. Normally, it displays Descriptor: <Tag Name/Abbrev.> <annotation>, when what I mean is just <Tag Name/Abbrev.>: <snippet type>

While not ideal, it can get you there. Might not even need the snippet type there, but it would be nice to put the snippet right after the tag (in the same way annotation appears after the tag). I'm sure you've abstracted all this, but it would go a long way to providing some kind of labeling.

[JohnSouthgate]

I could see having a <null> tag type that doesn't display when not in edit mode as a work around. A labelled text input would be nicer though i think.

[darloth]

I'd prefer labelled text input as well, and I'd be fine with option #2. Currently the tags display in a slightly smaller font than the default text-snippet font, so setting that small font to be used for labels as well would be great to help use as little space as possible.

Most of the labelled fields won't run onto two lines, and if they do it'll take a bit more space but it won't look terrible - It's not as if there's excess whitespace in this interface at the moment, if anything, I could do with just a little MORE between snippets and sections

[Zaphod Beebledoc]

Must say thanks to Rob for explaining things above!

I think I'd go with option 2 to be honest though...

[MaxSupernova]

Another vote for option #2.

I know it wasn't actually being presented as "Here are your choices" but I came in here to request a text field with a title, and it seems others have too. If it's technically possible and people are okay with the limitations of one of the possibilities, I'd like to see it.

[Bidmaron]

Folks, I gave them an easily workable solution in my previous post that does exactly what we want. We shouldn't settle for a half-assed solution. It is easy. You compute a field that is the concatenation of the label and the content and this is what is visible in view mode. In edit mode you hide that computed field and show the separate label and text fields. The only issue is that the display code would have to set like a word paragraph indent to start the first line past where the label ends. The code would have to redetermine the indent amount any time the dynamically-sized label is edited. The z order of the label would be maintained on top of the content field. This is not that hard to do. Don't settle for something less.