Text with title

[JohnSouthgate]

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

[Farling]

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

[JohnSouthgate]

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,

[Farling]

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.

[Zaphod Beebledoc]

There has been some discussion about this here (http://forums.wolflair.com/showthread.php?t=45315).

[Kendall-DM]

+1 from me.

[Zaphod Beebledoc]

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

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?

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 text here Text that will come after it.

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

[rob]

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 "text" 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 "text", 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! :)

[JohnSouthgate]

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.

[Farling]

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.

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

[rob]

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.

Your proposed solution fails to handle a number of nasty complexities that you're probably not considering. Those issues turn your "easy" solution into a decidedly more complicated task.

So here's a critical question to consider...

Would you rather have us do it sooner using a simpler solution that we can implement relatively quickly? Or do it your way and likely have it take months longer before it actually gets implemented because there are numerous other features of significantly higher priority?

Tasks that take less than a day can be slotted in between "big tasks", allowing us to get some of them done on a steady basis. Tasks that take multiple days get prioritized along with all other meaty tasks, which means they don't get tackled for a much longer time unless they are high priority.

If you take the attitude of "don't settle for less", then you're effectively saying you're happy to wait a potentially long time for a feature, as it has to be weighed and prioritized against everything else. That's just the reality of the situation, since there are hundreds of things on our todo list, all of which are screaming for attention, and we can only do a few at a time.

Please keep this reality in mind when making requests.

Also, given all the complexities inherent to Realm Works, declaring something as "easy" without a thorough analysis of the actual technical implications is "bad form" on so many levels - not to mention that it's utterly misleading to others. You may have an idea of how it MIGHT be easy to do, but that doesn't mean it IS easy until you've actually considered all the technical implications. As a techie yourself, I'm sure you've encountered such situations numerous times, and I'm disappointed you allowed yourself to fall into that trap here.

Offering suggestions is GREAT, but please don't make assumptions about what is or isn't easy from a technical standpoint with Realm Works. I'm sure you'd be quite surprised at some of the things that seem easy and are actually hard, as well as some of the things that seem hard and are actually easy. :)

Thanks!

[Parody]

Put 1 and 2 together by adding a "Multi-line" checkbox to the "Labeled Text" snippet definition. When unchecked you get the Tags snippet without a Tag entry box, checked you get the indented multiple line edit control. Let us decide how much much text we tend to enter for a particular snippet type. :)

[Bidmaron]

Rob, I don't want to get in a coding urination contest, and maybe the engine you are using is primitive enough that it doesn't support a 'LostFocus' type of event and maybe you can't interrogate a screen control that is set as auto-resize and you can't use an rtf type control where you can set the first line indent of the rtf control to the width (plus a comfortable offset) of the control that lost the focus (the label). I apologize for assuming your development environment was at least as capable as visual basic for applications, which can do all these things.

As to whether I'd wait, well, I might be alone on that, but yes, I'd wait for an effective solution rather than a half-assed one. What you have is a wonderful, friggin' outstanding product. It works as is pretty dang well. Solutions 1 and 2 are barely better than the existing workaround IMO.

Sorry for assuming your development tool is evidently less capable than I had imagined. This is not completely trivial in VBA, but it is hardly a full day's worth of coding (probably not an hour's worth).

Again, Rob. You guys have done a fabulous job, please don't consider that I'm not appreciative of the major magic you folks have worked. But this is a feature request list, and I don't think I'm out of the box expecting a feature like what we're requesting.

[Bidmaron]

I request everyone to please disregard what I intended to be a constructive suggestion on how to implement what folks are requesting. Rob is right (of course). This is probably ten times harder than I'm giving it credit for.

I've been involved in projects before, and it is my fear that if we settle for a short-term, incomplete (which I have inappropriately deemed half-assed), then we will not get the full, workable solution (after all, we'd have something a little better than the original, why spend more effort on polishing that cannon ball?).

Anyway, I apologize to all concerned, not the least of which is Rob and his development team, who have done one heck of a great job. I really did mean it in a constructive way, but ... enough said I suppose.

[rob]

@Bidmaron: The problem is that you are not considering a whole bunch of factors that you're simply unaware of under the covers. The framework we're using is quite capable. However, we've also had to seriously customize it in ways it was never designed for in order to do some of the stuff we've done. That makes certain things that are normally simple actually quite hard, and it also makes various normally hard things quite simple.

Your assumptions are based on the premise that we've not done any of the serious customization work. That's the crux of the problem. Everyone's lack of insight into those details makes it impossible for them to know the implications for any given feature request - yourself included.

We're listening to all the suggestions and have been working to tackle of few them already. But please don't make assumptions about what is and isn't easy, since the rules are completely different from normal due to the ways we've customized things to create Realm Works. That's what I'm asking.

And it definitely is hurtful to make statements like your "constructive" one above wherein you've gone out of your way to belittle the "engine" underneath it all with multiple aspersions. Even with the "please disregard" post following it, the message above is still "you guys must be stupid to have chosen such a primitive framework". That is definitely NOT the case.

So my request stands: Please don't assume things for which you lack the appropriate information upon which to make a valid judgement.

Thanks!

[Bidmaron]

As I said, please forgive me, Rob. Thanks for your clarification.

[LordOfAnnora]

I really hate to jump into the thread at this point, seeing as the topic's four months old and left off with an argument, but as a new user to Realm Works, I was both surprised and discouraged to find out text snippets couldn't include labels. I understand there are UI complexities, and I'm not downplaying those. I just think the application would benefit from this feature.

Rob, Option #2 sounds fine to me. As a user, I am comfortable with the tradeoff in UI real estate if I decide I want an obscenely large multi-line text snippet. As long as I can choose between a labeled text snippet and an unlabeled one I'll be perfectly happy. Under the vast majority of circumstances, I'd only choose the labeled one if I knew my content was just going to be a one-liner. If I'm going to write paragraphs, that's almost always going to go into a separate section with an unlabeled text snippet.

[Dark Lord Galen]

@Lord of Annora (great SN by the way)

Don't be afraid to dive in ...

While Rob barks often (wink) he seldom bites (though have been bitten once or twice now that I think on it hehehe)

.....but don't let that deter you, he is just very passionate about producing not a good product, but a great one.... I think that is where he and Bidmaron stepped off badly (IMHO).

Rob's natural reaction is to defend his product, his team and who in his place would do it any differently? I'd much rather have a few "heated debates" than a company (and the owner in this case) not communicating at all with the consumer.

As to your feedback
+1
There is always compromise.. Rob is offering a short term solution within the timing his limited resources allows, he isn't telling Bidmaron no, he is simply saying your proposal oversimplifies the challenge (understandable since in all likelihood Bidmaron doesn't have access to the intricacies of the core coding).

It might be likely in the future, after other more pressing challenges are met and in the "rear view mirror" that a more robust and fuller featured method may come to light. (all ways the case on any software)

And Bidmaron may certainly be the spark that led to the light..... but even light takes time to travel.....

And now back to your regularly broadcast thread
:O)

Humbly
DLG

[gamemasterbob]

Hi all. I'm jumping in. labeling text snips is a +1 for me. For example I was creating a topic template for D&D 5th monster. I want data for each item in it's own place. I can easily make a tag list for Race. However, Hit Points are NOT made for a tag list.

A temporary fix could be adding the feature "Label" that would go above ANY snip and give us some ability to choose text format/alignment? This would do it for me. It takes up more space but it would be a much simpler way to get this done. We're adding the title above. A divider with text.

Sub-sections could work here but there is no formatting/text control and you would need a way to OMIT the TEXT snippet that is automatically created with a section. For instance, in category management you could put a check box that allows you to omit the added text snip IF you have entered your own snippet. (I would really like to see this feature)

Just some thoughts. RW rocks.

Thanks.

[Parody]

Don't forget that there are Numeric snippets, which have proper titles.

It is annoying that sections with no text snippet (regardless of other snippets) get assigned a text snippet. A related request thread: Sections without snippets (http://forums.wolflair.com/showthread.php?t=49330).

[Dr_Automaton]

Since Rob appears to still be compiled the survey list, I figured I'd bump one of these labeled text snippet request threads.

[rob]

There's NO need to bump anything. Unless a thread has lain dormant for well over a year, I've gone through and noted it. :)

[Bidmaron]

Sorry, Rob. Noted someone else had done so without comment and just thought it was "THE THING TO DO"

[rob]

I apparently missed that "bump" or I would have flagged it as well. I'm running pretty ragged on this end...

[Kendall-DM]

Now that we've reached the point of release status, I can understand why you would and wouldn't consider some of the solutions to this. Personally, I would have wrapped all the snippet types up in some kind of designer pattern, probably the decorator one. That way all the snippets could have worked hand in hand, thus adding an additional 'label' would have been ideal. But that's water under the bridge at this point.

Though I was initially for it, I'm not in favor of using tags as labels either (as was mentioned very early on). Tags have a set limit on what they can hold (10 characters), plus each tag has its own label. I still wish the tags could hold more than 10 characters, it is really sad to see truncated tags. I know there is a short description for it, but 10 characters is a short description if you ask me. Enough of that.

My proposal is a rather simple one. Is there some way we can template our snippets for our categories? It would be nice to be able to template a text snippet so that it always has a standard set of formatting within it. For example, if I have a Category called Characteristics and within that Category I put various snippets regarding basic character characteristics, let's say Character Name, I think it would be nice if the snippet could be templated with a bolded Character Name: to start the snippet out with, so that when it is added to the Category that is already in place and I don't have to type it in or copy and paste it in each time. This goes for tables too, I tend to standardized my table sizes, fonts, layout, etc. and it would be nice to have that templated as well beforehand. Just some food for thought, as I don't that this would require too much tinkering with anything 'under the hood'. However, I have no idea what the infrastructure of the code is, so I'll leave this for you to decide.

I seem to remember that originally there was going to be templating, and sometime during the beta when things changed to the current version that went away. Am I misremembering that?

[Parody]

Though I was initially for it, I'm not in favor of using tags as labels either (as was mentioned very early on). Tags have a set limit on what they can hold (10 characters), plus each tag has its own label. ...
I have plenty of tags that are more than 10 characters that show completely in their snippets. Long tags are only truncated if you have multiple tags in the same tag snippet. Most of my tag snippets are designed to be single tags so I can add notes in the text box.

My proposal is a rather simple one. Is there some way we can template our snippets for our categories? ...
Sounds like a different thread. :)

ObTopic: I posted my idea upthread (http://forums.wolflair.com/showpost.php?p=183271&postcount=22).

[Kendall-DM]

Right you are, seems I'm using a lot of multi-tags and forgot that the single ones don't truncate. Frankly, having the multi-tags truncate is annoying, but what can you do.

[Mystic Lemur]

I very much would like this to be a thing. I'm currently trying to create a topic category, and was surprised to find that when I picked a snippet type of "Text" that the "Name" showed up where I thought the "Description" would show up. I hoped the "Name" would show up as a label. :'(

[MaxSupernova]

Right you are, seems I'm using a lot of multi-tags and forgot that the single ones don't truncate. Frankly, having the multi-tags truncate is annoying, but what can you do.

Feature request! :)

[whump]

I've just encountered this issue in RW and found this thread. I wasn't able to express a view on it in the road-map survey.

Can I ask someone from LoneWolf to give a very brief note on whether labelled text snippets are in the to-do list? If so would they be able to give a rough idea of whether they're likely to be added soon or if they are waaay down the list? Just a rough idea would be great!

If labelled text snippets have really dropped off the radar, would other users be able to share their workarounds if not already in this thread? I've yet to work out a nice way to get a labelled text effect.

Thank you everyone!

[EightBitz]

I've just encountered this issue in RW and found this thread. I wasn't able to express a view on it in the road-map survey.

Can I ask someone from LoneWolf to give a very brief note on whether labelled text snippets are in the to-do list? If so would they be able to give a rough idea of whether they're likely to be added soon or if they are waaay down the list? Just a rough idea would be great!

If labelled text snippets have really dropped off the radar, would other users be able to share their workarounds if not already in this thread? I've yet to work out a nice way to get a labelled text effect.

Thank you everyone!

This was the last official word:

http://forums.wolflair.com/showpost.php?p=179904&postcount=8

[Kendall-DM]

Which is why I made the suggestion that we be allowed to template text fields with some default text. It would be great if my text field I called Description could be templated with the default text "Description:", so that I don't have to put that in every time, and it solves the labeling problem in a way that doesn't interfere with the layout and design portion of RW. In general, any ability to template fields with default data would go a long way to helping the data entry portion of RW.

[whump]

This was the last official word:

http://forums.wolflair.com/showpost....04&postcount=8

Thanks! I saw that further up the thread but mmy search skills are low and I wondered if there was anything else I had missed. Clearly not!

I understand the design challenge this presents but I see it as a question of choosing the lesser of two evils. Like many GMs I have my own quick-note way of describing key attributes of places and people in my campaigns.

Right now I can either:
1. Use text snippets and write my own labels e.g. "Clothing: leather armour" or "Archtecture: carved wood frames, no stone". In such case I have no prompt text and I need to remember what order/section I want the snippets in for consistency, or use a separate reference document;
or
2. Make my own custom category with 1. appearance; 1.1 clothing; 1.2 first impressions; 1.3 etc etc. which gives me a nice framework but is displayed in a fairly bulky way with lots of lines and headings down the page.

If we could have labelled text snippets with prompt-text in them that would solve this issue much more neatly for me. We could tick a box to limit characters and keep the snippet on a single line, or untick and allow the snippet to run onto multiple lines. In any case, the user can choose what works best for them.

So I wonder if anyone from LWD is reading - is this something LWD plan to tackle or has it been mothballed?

[Fox Lee]

So hey - thread necromancy and all, but this just occurred to me: what about just making the heading levels looks distinct from one another? I don't know about everybody else, but I'd be more comfortable with the current (presumably for the foreseeable future) no-labels design if every subsection of a topic didn't have the same formatting (and big divider line) as its containing top-level section.

While there are still places where I really, REALLY want a label for a snippet, heading levels that appear distinct from one another (we've all seen these in official documents, well-designed wikis, et cetera) would allow us to better use sections as they seem to be intended, and could potentially solve some issues with removing snippet labels. Plus, we'd have a better idea of how broad/specialised each section of a topic is, and better ability to tell them apart, just at a glance.

(Better yet, let us choose our own formatting for section levels. But I won't be holding my breath, since right now even customisable text styles seem to be off the table :p)

[Bobifle]

Like whump, I'm interested in a solution (I would be statisfied with option #1).

Maybe in the 1.0.38 ? :cool:

[Madmaxneo]

I don't understand, why LW can't just add a text entry to the the behavior dropdown much like they have a Numeric entry? That would solve many problems for now and if there was anything else they could implement they could do that later.

[AEIOU]

Ah, Grasshopper. All things seem simple when viewed as a single entity and one excludes everything else. But combined, many simple pieces become a complex whole. And all the pieces must be kept in balance with one another or the whole ceases to exist.

Without knowing how this particular piece of RW was coded and what else in RW relies upon this same bit of code that could stop working as intended, it's impossible to determine if it's a simple change from our vantage point.

I'm willing to bet RW utilizes some third party libraries for speed, consistency and simplicity. The behavior you seek may be reliant on code from a third-party that LWD would have to rewrite from scratch or convince the third party to change. It becomes a cost-benefit question then.

[spader]

I wonder if using the code for Tags or Numeric Value and setting the box to "not visible" would be possible. Leaving just the Label and Annotation entry.

I could work with something like that.

[Greebo]

Which is why I made the suggestion that we be allowed to template text fields with some default text. It would be great if my text field I called Description could be templated with the default text "Description:", so that I don't have to put that in every time, and it solves the labeling problem in a way that doesn't interfere with the layout and design portion of RW. In general, any ability to template fields with default data would go a long way to helping the data entry portion of RW.

+1

In my opinion the ability to define topics as subtemplates with pre-filled / prepopulated snippets would be quite usefull.
Currently I create generic topics of some templates with pre-filled snippets (e.g. with "description: nn", "geographical position: between nn and nn" or "origin: nn") and place them in a list. Whenever I create e.g. a character, I copy the generic topic and fill in the specifics.
Since it makes no real difference whether I have to copy my customized topic from my own list or the announced staging area, this process will stay cumbersome even with Content Market fully functional.

[rob]

Support for labeled text snippets will be included in the next release. We heard you! :)