• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

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
 
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.
 
I mentioned something on LWD's Facebook page about labels yesterday and got this reply.

Me said:
I've looked through the World Builder's Guide and can't find anything about custom labels. (In the snippet section anyway). Can you point me to the page number or section please?

Realm Works said:
Anthony, they're called tags. Check out page 33 of the World Builder's Guild. You'll need to add your custom tags first. Then, if you need assistance, I can walk you through how to set up the custom snippet with the attached tag.

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...
 
Last edited:
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.
 
Last edited:
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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 :)
 
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.
 
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.
 
Back
Top