Feature request: Change Mudlet's text label workflow #2162
Comments
|
I will readily agree that Map labels really need some TLC right now! The UI is, as you point out, incredibly clunky and the workflow too long - and the absence of most editing facilities makes it almost impossible to create a consistent series of labels from the UI (and the scaling process for text label does not always leave pretty results.†) I'll mark this as a bug but because it is possible to create Map labels via † if you check the changes to the room symbol code #1543 you will see that the lettering is much better nowadays because I make the |
|
Further thoughts on improvements: I often need to move both rooms and their labels together, at the same time, so that the labels stay in the same position relative to the rooms when both have been moved to a new location (ex: if a certain label was 50 pixels above and 70 pixels to the left of a given room in the old position, it should remain exactly 50 pixels above and 70 pixels to the left of the same room in the new position). However, currently when one selects some rooms by clicking and dragging, the labels are not selected, so it's not currently possible to move both together. As a result the labels get left behind when I move rooms, making it necessary to separately move the labels to their respective locations next to their corresponding rooms. This is made more difficult still, as currently text labels can not be positioned precisely but can only be positioned on a grid, which doesn't always line up with where the labels are supposed to go. So what I usually wind up doing when I have to move a lot of rooms and labels is first move the rooms as a group, then delete all the existing labels I'd already created for them and then recreate the labels in their new locations. Needless to say that this is hugely time consuming, given the current excruciatingly slow label creation workflow (as described in my original post above). It would be so much more convenient and infinitely more efficient if rooms and labels could just be selected together and moved together as a group. |
|
More suggestions: Text in a certain fonts size should always match the size of identical text written in the same font size, no matter how zoomed in to the map you are. Currently the zoom level will affect the font size. So, for example, if you write "foo" in a 12-point font size, then zoom out and write "foo" again in the same font with the same 12-point font size the second "foo" will be renderd larger than the first. This makes it almost impossible to write in a consistent font size as you zoom in and out of the map. |
This is really interesting work, and may be sufficient for users who want every room on their map to have its literal room name as a text label next to it. Unfortunately, it doesn't fit the way I map, because while many of the rooms on my map do have their literal room name next to them, many don't. When I map I label the rooms with labels that "make sense" to me. Sometimes that will be the exact room name just as it appears in the game I'm mapping, but other times it will be something related to some aspect of the game that I need to know when I move in to that room, or something else (it's hard to generalize, and my method of labeling may change from game to game, area to area, or even room to room). For example, in the most recent game I'm playing you have to go through portals in many of its rooms to get to other rooms, so quite often I'll just label many of this game's rooms with the portal name and the portal's destination. Sometimes that will be the only label for such rooms, but at other times there'll be multiple such labels because there could be many such portals in the or, etc.. Sometimes actually having the room's name as a label will even be confusing, or undesirable for some other reason. Yet another reason that this solution wouldn't work for me is because I like to have full control over where labels are positioned on a room-by-room basis. Having them be positioned the same for every room just wouldn't be nearly flexible enough for me, because for me where I decide to put a label is based on the context and how I want that section of the map to be laid out. In short, the proposed solution is just not nearly flexible enough for my needs, though I'm sure it would be great for someone who maps differently from the way I do. I'd prefer to have manually created and manually positioned text labels, but also would like to have them be selectable and movable along with the rooms I select along with them when I click and drag a rectangle around both a set of rooms and labels. |
|
Umm, you already can control on a per-room basis what the name is. Nothing forces you to unconditionally propagate the MUD's idea of the room name onto the map. You also can control whether to display it and where to place it relative to the room. Changing the font and font size on a per-room basis is … somewhere on my TODO list. Reasonably easy to implement. I readily admit that it's not a panacea, esp. since you want more than one label. Would multi-line work (just asking, as my code doesn't do that yet either), or do you want to place them individually? NB: Yes I agree that room labels that get dragged along with the rooms in question would make a lot of sense. As would be room selection via shift-click or shift-drag. We'll get there someday, I assume … |
There are actually multiple reasons to keep the map's room names in sync with the game's room names. The first is that I want to know when I or my mapping script made a mistake mapping. In order to do that I need to know whether or not any given room on my map corresponds to a particular room in the game. If a room on my map is called "foo" and the room in the game is called "bar" then I can't know if there's been a mistake without further investiagtion (such as checking the exits in the room). Another reason is that sometimes I want to use the game's speedrun or direction-finding features to go to some room based on a room name I see on my map. That's impossible to do if the map's and game's room names are out of sync. Related to this is that sometimes I may want to use a speedrunning script I've created in Mudlet to speedrun to a room whose name I got in-game. Again, if the map's room names are out of sync with the game's room names then I can't do what I need. Yet another reason is that say I notice that in-game I'm in a room named "foo". Well, based on that where am I on the map? If the mapper is working properly then I'll be shown to be in the proper location. But what if it's not? If the room names are in sync I can still figure it out, but if not I'm lost.
Well, if I can do that manually, on a per-room basis, and using the mouse instead of typing in coordinates then I'm happy to do that. But I will need to be able to create multiple labels per room.
I'd like to place them individually, because where I place them will depend on context. For example, sometimes I'll want one label between two rooms indicating the name of the portal to use to get between these two rooms, but at the same time I may still want to see the room names beneath each room, so multi-line labels would not work for this use case. |
|
I just thought of another reason to keep at least some labels independent of any particular room. That is the situation where I need to delete a room for some reason. If all my labels were associated with rooms but some of the labels were about something that did not have anything to do with any particular room (like, say, a note about the area) then I wouldn't necessarily want that label deleted when I deleted the room it was associated with. This argues for keeping at least some labels unassociated with any room. But I'd still want such labels to be repositioned along with the rooms if I select them both and move them somewhere. |
|
The thing is that the map labels are associated with the area as a whole - there is nothing that links them to a particular room. OTOH You can get the details of the labels that an area has - and @Delwing has just done PR #4541 that means you can get more of those details so it might be feasible to identify a label by it's Id number and arrange for some user data in a particular room to store an offset to maintain between the label and the room and then delete and recreate a new label with a script that scans through the rooms in the area looking for those details and regenerates a label when it is not in the right position. I can't recall if there is a Lua function to move an existing map label - but if there isn't it should definitely be possible for me to make one... |
That's true for ordinary labels, but earlier in this thread #3992 was mentioned, which does (if I'm reading it right) associate labels with rooms, and I'd expect each of those types of labels to be deleted along with the room they're associated with.
I think that should work for my needs if the association between a label and a room only lasted during the move itself, and this association was removed afterwards, allowing rooms to be deleted without affecting any labels (unless the user wanted to delete both a room and a label together, which they could do by selecting them both). Another thing that might be useful could be to have a way to link a label (or labels) to a room and have this link last until it's explicitly unlinked. Such a linked label-room entity could be moved and deleted together, but if they're not explicitly linked then naturally the deletion or movement of the one shouldn't affect the other. One shouldn't need to make such an explicit link, however, to move labels and rooms together. The default should be to keep their relative positions to one another at any time both are moved together as a unit (such as after a selection and movement of them both at one time). Incidentally, I'm not against having labels be associated with rooms (even by default), as long as there's some way to make some labels that are not associated with any room and still have them moved along with rooms when both are selected and moved. |
|
Here's a situation I ran in to today where I needed more than one label for a single room, and it wouldn't have worked the way I wanted if both labels had to be in the same paragraph: I had a room with north and south exits, and I wanted labels for both the room name and where the down exit from the room lead, and didn't want them one under the other. So I put the room name label to the west of the room, and the down exit label to the east of the room and made them different colors so it's be easy to tell which was which at a glance without even having to read them since for my full map I use a certain color for every room name and a different color for every exit name. Putting one label under the other would have been less clear to me than keeping them well separated like this. Also, it would be nice to be able to link those labels to the room (or even have them start off linked by default) so when I moved the room the labels would follow. Again, that's not always what I want, so the ability to unlink or make completely independent labels would also be useful. |
Brief summary of issue / Description of requested feature:
I'd like to request that Mudlet's text label workflow be changed to make adding and modifying labels much easier.
Please see the "Ideas for how to solve / implement" section below for details.
Reasons for adding feature:
Currently, Mudlet's text label creation process is by far the most painful part of using Mudlet for me. It is so awkward that for a long time I avoided creating labels at all, but when my maps grew large enough I started getting lost, and started making lots of labels, out of which experience this feature request comes.
Please bear with me as I describe the current tedious and error-prone process of label creation, the many ways it breaks, and the way it can be improved.
To make one single little text label, this is the gauntlet the user has to run through:
Finally, after 12 steps (!) the label has been created. These 12 steps have to be gone through again and again for every single label!
Imagine creating a hundred labels this way. That's 1200 steps if the user is lucky and has made no mistakes during the process or doesn't change their mind about one of the parameters above. If they do, it gets even worse.
Because Mudlet has offered no visual feedback during the label creation process, it's only after the 12 steps have been gone through and label is created that the user may notice that the text is actually too small.
In such a case there's currently no way to change the size of the label, so the user has to delete it and start over or live with the size being too small because doing it all over is too much trouble.
But then the text is probably positioned in the wrong place because the bounding box is too large, but when you try to move the text to line up with the center of a room or with an arrow, you can't because the text is on some kind of grid that's spaced differently from the rooms themselves.
Even if there was no grid, when moving the text, Mudlet fills in bounding box with an orange color which overlays the text, making it almost impossible to see the text so lining up the actual text with a room is very difficult.
If the fonts size of the text in the label is too large, the Mudlet will actually truncate the text to fit in to fit in to the bounds the user had selected in step 3, in which case there's no recourse but to start all over. I've messed up quite a few labels that way and had to redo them. One really just has to guess at the bounding box size and the font size, as there's really no way to know if the text will fit until after the 12th step.
The user also has to start all over if they want to change any other properties of the label except its position. There's also no way to rotate the label (vertical labels are sometimes useful).
If while making the label the user decides to cancel it any time after step 5, currently there's a bug that ignores the cancel request and makes the user click through the remaining dialog windows.
There's also no way to link text to a room, so when one inevitably needs to move some rooms around, the labels don't go with them rooms so need to be repositioned separately, and by hand.
I could have filed bug reports on these, but, really, it's better to scrap this slow, painful process and start over.
Ideas for how to solve / implement:
I strongly recommend Mudlet's developers take a look at Inkscape's label creation workflow. Inkscape gets this right, and makes creating labels infinitely easier and less painful.
In Inkscape you can just click on the "Create and Edit Text Objects" button (or press F8), click on any part of the page and start typing. That's only 3 steps!
It's just two steps if the text tool has already been selected. Then you can just click and type to make another label.
To make 3 labels, you can just click and type, click and type, click and type and you're done. With Mudlet you'd need to go through 36 steps for just those 3 labels!
In Inkscape, when done typing you can just move on to work on something else by clicking elsewhere, or if you want to make modifications, you can press F1 to select the text you just created and either grow or shrink it by dragging one of the corners or edges, or click on it to allow its rotation by one of its corners.
You can fix typos, insert, or delete text by clicking in the text (if you haven't yet clicked away to work on something else or pressed F1 to select the text object), or by double clicking on the text (after the selection step, or after going away to work on some other page element and coming back).
There are much fancier things that can be done with text in Inkscape, but Mudlet does not need them.
All throughout this process Inkscape gives the user instant visual feedback on how the text is going to look. They see the label with the selected font as they type it. They see it rotate as they rotate it. They see it shrink or grow as they change its size. This makes getting the label to look right much easier than Mudlet's way of delaying feedback until 12 steps have been gone through.
In Inkscape, if the user needs to change the font or other text properties, they can just double click on the text, make their change in a dialog window that's optionally docked to the main window and click "Apply", or set the chosen font as the default by clicking "Set default".
In Inkscape the text is not limited to moving on a grid, it can be freely created and moved anywhere, though if the user wanted the to snap to a grid they could do that, and even precisely define the grid spacing. The grid can also be made visible or hidden.
It's easy to line up elements in Inkscape, and it gives the user a number of options on how to do that -- lining up on the left/right sides, vertical/horizontal centers, and top/bottom edges. This might be a little overkill for Mudlet, but it would be nice to have a quick way to line up vertical or horizontal centers of text labels with rooms or arrows without having to fiddle with it to get it just right.
(It's also possible in Inkscape to group text with other elements so that when those elements are moved or grow or roates the text moves, grows, or rotates with them. Of course, grouping is easy, as is ungrouping.)
I recommend that Mudlet adopt Inkscape's workflow. It would be a tremendous improvement.
Expected result of feature
Text labels could be created in 2 or 3 steps instead of the 12 steps they currently take in Mudlet. This would make labeling big maps in Mudlet painless instead of the slow torture of the current workflow.
It would also let users actually change labels instead of having to delete them and start from scratch, which is what the current workflow demands.
It would give users instant visual feedback on how their labels are going to look while they're creating them, instead of having to wait until the process is over, as they have to with the current workflow.
In every way label making will become less painful, faster, and easier.
If Inkscape's workflow is not adopted, at least please simplify the current process, offer the user instant visual feedback on each of the steps so they can instantly tell if at any step their label looks right or needs to change, and drastically reduce the number of steps needed to create a label. Also, please make the labels modifiable rather than requiring the user to start all over from scratch just to make a simple change like grow/shrink the label or edit a typo.
Finally, once you've settled on some workflow, please, please try making and changing 100 real labels on a real map yourself, including all the mistakes and corrections that entails. Then you'll see if the process is something that's actually workable or if it's too painful to live with.
The text was updated successfully, but these errors were encountered: