Text with title
 

Could we get an additional entry type for snippets that is a text entry, but has a defined title too please. It feel clumsy to have to either have to use a tag field just for the title or have to type in additional info to give a text field relevance.

Thanks

If you want a title, can't you create a sub-section within the topic?

When I say title, I'm sorry I used the wrong terminology - I'm referring to the label at the start of the snippet rather than a category title.

I would like to have a text based field that has a label for a snippet type please

Thanks,

I would very much like these too, so that you can list lots of things in a more compact fashion than having lots of titles running down the screen.

There has been some discussion about this here.

+1 from me.

I mentioned something on LWD's Facebook page about labels yesterday and got this reply.

At the moment then, it looks like we will have to use custom tags as labels.

Edit: Just had a moment of inspiration! How about something like: [Label] Label text here [/Label] Text that will come after it.

Something that can be stored as text, but shown as a label...

We gave the idea of labels on text snippets some serious thought during development, but there's a nasty complication that arises and we couldn't come up with a clean solution during our analysis. There may still be a good solution that we overlooked.

The "label" field would need to be a completely separate control, just like it is for the other snippet types. So how do we lay things out?

Option #1: We limit the text snippet's contents data to be a single line so the label and contents can be placed side-by-side.

Option #2: We force the snippet's contents data to be displayed in a much narrower region so that the label is shown on the left. This would look a lot like two columns of data, with the label being on the first line and the contents data to its right. The problem is all the empty space that now appears beneath the label.

Option #3: We put the label on an extra line ABOVE the contents data. This will usually NOT be what the user wants, as it's visually distracting and fails to present the material in a useful way.

The big problem is that we need a solution that cleanly handles snippet contents data running for multiple lines. If so, then we aren't able to put the label on the same line with the contents data unless we go for the visually ugly option #2 that is also very wasteful of visual space. This "waste" becomes much more of an issue on smaller screens (e.g. laptops).

We could theoretically do something along the lines of what @Zaphod proposed with the "[label]text[/label]" technique. However, that has a major drawback as well. When you are in View mode for a topic, double-clicking within text should let you enter Edit mode at exactly that spot. But if we use formatting controls like "[label]text[/label]", we completely lose that ability. The label text would be displayed as "Label: contents" in View mode, but switching to Edit mode would move the text around, so now the snippet contents would move out from under where the user double-clicked.

There's no good solution here that we could think of. So we left it where users can readily insert their own labels at the start of the text if they really want them. You can also user whatever formatting for the labels that you prefer.

If anyone has a good idea for how to solve all these issues, I'd love to hear them! :)

Option 1 sounds good as it keeps the functionality in line with the annotation box on the other snippet types. If a snippet requires several lines then you have the text snippet to cover that scenario. If you want to support multiple lines i don't think that option 2 sounds terrible.

Another solution could be to allow us to add pre-formatted text into text fields at the category management level. As having to type in and then format the 'fake' label for every entry seems like a massive waste of time for something that should be standardised across multiple topics.

Option 2 could work for those snippets for which you want a prefix.
Any snippet without a prefix would be placed flush with the left of the panel.

I can think of several cases where this would be useful.

Option #1 then just becomes a particular use-case for Option #2 (only putting in enough text to fill one line).

If I was using a multi-line snippet body, then I would most likely use a short prefix anyway.

It would be nice, with option #1 or option #2, if the break-point between prefix and main text was aligned on all snippets in the same section. (I would be happy with the break-point being different between different sections, since there is a header in the way to break up the flow of text.)

I don't see the prefix being a replacement for section headers. It mostly just to have some nice labels on certain snippets. I don't think the "visually ugly"-ness will really occur unless the wrong approach is taken by the person entering the data.