[Feature] More functional area locations list

[Khat]

Right now, it can be difficult to understand how locations correlate to exits. They are shown on two different tabs and are not implicitly linked. As it seems we are likely to soon have exit linkages shown on map pins, I think we can continue to improve the navigability of Wolfery.

• When clicking on a room in the area locations list, nothing currently happens. If there is a local, non-hidden exit connecting to that room, I think it would be expected behavior for this interaction to move the character through that exit.

• When clicking on a sub-area in the area locations list, we currently see a brief description. This makes sense, but I think what would be better is to open that area’s full description page.*

• We could sort locations based on navigability first, then alphabetical, displaying all sub-areas on top, then all rooms with an accessible exit, and finally those rooms beyond reach or whose exits are hidden.**
  ⠀

---

* In either case, this behavior should probably be normalized with the prior suggestion, so that users are not confused by the presence of two different outcomes when they click on two different items in the same list.

Perhaps clicking on a room with an accessible exit leading to it should open its own description page, with a prominent “Go To This Room” button right up top, or simply offer a similar button in the dropdown that would otherwise have the brief description currently displayed for areas.

** Sub-areas could be separated into their own list, since they are fundamentally different from rooms and do not have the same functional meaning. This would allow us to use the current styling (white text for sub-areas and grey text for rooms) while retaining clarity, and address the previous note.

[Tlancaalek]

Actually, I seem to remember that if a summary is set for a room, it will be displayed when you click the room in the area room list, but since providing this is the exception rather than the rule, this isn’t always obvious.

[Khat]

How does one set a summary for a room? I don’t see it in the help set room attributes or a text field for it in the edit room tab.

[Tlancaalek]

Unfortunately, I don’t either, but I’ve never owned a public area, either. I’m assuming either that kind of thing becomes visible once you own a public area, or you have to ask a moderator or builder to set that up. I can only see the results, unfortunately (Check out the White Hearth Inn or The Plum for examples of places with summaries).

[Khat]

I could not find examples of this in either of these areas. The only locations in their area contents lists that have a summary are the sub-areas, such as the second floor and basement of The Plum.

[Tlancaalek]

Interesting. I hadn’t dug around in the area itself; I’m mainly thinking of what’s visible from elsewhere. Maybe it’s set at the area level, somehow.

[Khat]

The light text indicates a sub-area, which does have a desc field for the area locations list. The rooms, in grey text, do not have such a field as far as I can tell.

This particular confusion is part of why I think we ought to separate out sub-areas from rooms. They are mechanically distinct in that you cannot go to an area, so clicking on them should probably do something different (as it already does).

[Jagrabbit]

The summary is set directly in the area gui so long as you own it. short description field.

[Khat]

Yes, that’s true of areas. But rooms have no such field, and that is what the confusion stemmed from. That said, I don’t think a short description is the best use of this interaction in either case.

To reiterate, these are the changes that I think would be most flexible:

• I think areas should be in a separate list (to prevent this confusion) and display their full description page when clicked, as if one were standing in a room in that area.

• I think rooms should be sorted such that rooms with immediately accessible (and visible) exits are displayed on top in light text, while rooms with no such exit, but within the same area, showed lower in grey text.

• Upon clicking, it could display the room’s full description page, including a prominent “Go to this room” button up top.

• Pan the area map to the room’s location within as the default position for anyone using the nesting tabs to figuratively zoom out.

[Jagrabbit]

I agree with some of this.
Not sure I’m keen on fully replacing the existing area list, but having some more travel-mode options would be useful. Caught myself more than once trying to click on room names to travel around - clarifying which exits exist from the vantage of current room and allowing people to exclusively use only those links might not be a bad thing.

As far as separating sub-areas from rooms however, I disagree with splitting the two. The feature is intended to be a list of all rooms contained within an area, even if some of those rooms are grouped up as a sub-area. Not really all that different from folders and files on a computer. An area list is nothing more than saying these things live in this area and the white vs grey tells you if its a parented sub-area or simply a room.

I feel that this feature should be left alone. Room names of non-subarea rooms are often self explanatory or capable of being adjusted with better room name choices if they’re not explanatory enough in the first place - if they are part of a more complex sub-area, its simple to put them into one for the sake of gaining a sub-area short desc when appropriate.

The one issue we need to fix with this particular system is that we need about/rules field inheritance from parent areas, something I still need to bring up to Accipiter.

–

However, as far as the topic of splitting things is concerned - I do feel it would be good to split off any nearby exits to a nearby locations sub-section displayed above the rest of the area list. My thoughts for this are that it would make for easy travel should we allow exits to be accessed this way.
Probably also want it to state the name of the room the exit leads to (instead of the usual exit info) with sub-area shown in parenthesis for the sake of notifying users when they’ve changed areas and may need to update their rules knowledge.

For example: ◄ Stororkery Storefront **(Sub-area Place)**►

–

Considering the idea, remote viewing of rooms may also be undesirable other than nearby locations for the sake of privacy. Area owners may desire privacy to inaccessible areas. if a user can’t see an exit, it’s probably best not to let them view into the room they can’t otherwise get into, regardless of them knowing it exists somewhere.

Question is, do we simply allow one-click travel or do we make people click twice to unnecessarily view the room first every time? Might get clunky with extra clicks all the time. Having remote room viewing might be best to keep to a small side button (eyeball or something?) or avoided entirely for the sake of simply having clickable travel to nearby locations. I know that functionality wise, I’d prefer to have single click travel.

Unless we’re letting people see who is in remote rooms and introducing that loss of privacy along with it, I’m not sure how much value we gain in remote room view - tackling that matter is its own can of worms however. Lots gained by allowing people to find out where people are without having to dash around frantically, but also some loss of privacy if people don’t have lockable areas to go with privacy tagged rooms.

[Khat]

@Jagrabbit

As far as separating sub-areas from rooms however, I disagree with splitting the two. The feature is intended to be a list of all rooms contained within an area , even if some of those rooms are grouped up as a sub-area. Not really all that different from folders and files on a computer.

In that case, I think another way to do this would be to sort them above rooms, as we generally expect file browsers to do with folders. There really is no way to know the difference, aside from the text color, which means nothing to users who haven’t experimented a lot with the interface or building tools and such, since it’s sort of niche and undocumented.

I dig a little bit deeper into what I think this could look like here:

@Khat

We could sort locations based on navigability first, then alphabetical, displaying all sub-areas on top, then all rooms with an accessible exit, and finally those rooms beyond reach or whose exits are hidden.

But if areas remain a part of the same list category while adding a third mechanically-distinct list item, we will need a better signal than text color for whether an item describes an accessible room, an inaccessible room, or an area. Perhaps section headers could be inserted in the list for each of nearby locations, sub-areas, and other rooms.

---

@Jagrabbit

Considering the idea, remote viewing of rooms may also be undesirable other than nearby locations for the sake of privacy. Area owners may desire privacy to inaccessible areas. if a user can’t see an exit, it’s probably best not to let them view into the room they can’t otherwise get into, regardless of them knowing it exists somewhere .

@Khat

Perhaps clicking on a room with an accessible exit leading to it should open its own description page

---

@Jagrabbit

Question is, do we simply allow one-click travel or do we make people click twice to unnecessarily view the room first every time? Might get clunky with extra clicks all the time. Having remote room viewing might be best to keep to a small side button (eyeball or something?) or avoided entirely for the sake of simply having clickable travel to nearby locations . I know that functionality wise, I’d prefer to have single click travel.

I agree, traveling through the exit on-click and saving the look-through option for a separate button off to the side (like we have for character notes in the awake list) would be a wonderful way to minimize unnecessary clicking. Much better than opening a page and clicking a button up top. I imagine it’s a little less work to implement, too.

My question is whether we should be concerned about the change in behavior; people are currently accustomed to rooms in the area locations list doing nothing but auto-panning the map. How can we make that transition smoother? Or is this something that’s not much of a concern?

---

@Jagrabbit

Unless we’re letting people see who is in remote rooms and introducing that loss of privacy along with it, I’m not sure how much value we gain in remote room view - tackling that matter is its own can of worms however. Lots gained by allowing people to find out where people are without having to dash around frantically, but also some loss of privacy if people don’t have lockable areas to go with privacy tagged rooms.

I definitely lean in favor of simply omitting the present characters list when viewing a room remotely. Players already have access to the population of each room in the world, and it sounds like Accipiter intends to add a population heatmap to further advertise that information. I think that’s a good enough gauge of whether it’s worth visiting a room to see what folks are up to without deprivatizing character locations.

The utility, however, in enabling players to remotely view rooms (and, ideally, areas and sub-areas too) is in permitting folks to explore the world of Wolfery without spamming rooms with intermittent …

Khaterín arrived.
Khaterín left.

… messages. We can mute these and that helps, but I think that I do want to know when people arrive … and intend on staying. So reducing this demographic of ephemeral traffic (people who are probably not interested in getting involved in any incidental scenes anyways), is ideal to that end. It also offers some privacy to folks who don’t want to be noticed when all they’re trying to do is figure out the lay of the land.

[Jagrabbit]

It would be good to know how much work Accipiter thinks a remote look function would be, whether or not users would be able to find that functionality if developed and whether or not they would use it instead of simply travelling around directly.
It’s a nice thought that we could mitigate a small amount of the travel spam, but from my position as staff and having interacted with the rush of new users since launch, I do believe that most new users barely even recognize the area function at the top of the output window, let alone look at it for functionality sake.

It was a real struggle to get a significant amount of the new users to even recognize we had tools to identify areas, let alone rules in them - which lead to the creation of more tutorials and guides to help with education.

–

I feel like a vast majority of that wandering traffic is people actively trying to find people they know in places. If they can’t see people in the room list by using remote look, then the adjustment won’t stop them from rushing around endlessly.

We’re currently lacking a tool for viewing users currently in listed area rooms. We do have a room privacy area flag to utilize for creating anonymous spaces, but at some point in order to kill that particular type of traffic (where people rush through every room) we need a tool/command that allows people to see who is around in a space defined by the area owner which can be customized for the sake of mitigating travel spam in otherwise populated lanes.

[Khat]

At the risk of splitting the thread, aheh…

What if we had a privacy setting that allowed players to display their location to “All”, “Mutual Watchers” (or a specialized handshake thing like a friend request) or “None”? It could be displayed under their name/status in the awake list or similarly in their profile to those eligible to see it. No need to search for (most) of your friends if they’re happy to just passively reveal their location to you.

(Though it occurs to me that join fulfills this just as well. Then I wonder why people go wandering about instead of just asking to be brought along.)

[Shinyuu]

@Khat

(Though it occurs to me that join fulfills this just as well. Then I wonder why people go wandering about instead of just asking to be brought along.)

My guess would be – because it’s fun?

[Jagrabbit]

(Usually because they don’t know what they’re looking for until they find it, I imagine.)

[Accipiter]

I feel my input in this thread can be benefitial

I will mainly write why things work the way they do, and my thoughts behind their behavior. Can it be improved? YES! So, just because I had some intial thoughts, it doesn’t mean they are the best thoughts.

Mixing of location types

We currently have 2 location types: room & (sub)area
As location goes, the two share similar traits; they have a name, a map position, a population.

This has mainly been the reason for mixing them in the list.
But I admit GUI wise, their difference is far from obvious. I have multiple times gotten the question why some “rooms are white”. So, I am up for improving it!

Purpose of Area page

The area page was created for (roughly) the following purposes:

1. Map giving a better sense of you being inside a world
2. Map gives a sense of how where you are in relationship to other places.
3. To encourage exploring as you can see places in the area
4. Show population - to encourage visiting places to see “what is going on”

And that is mainly why the list is created in the way that it is, with the sorting to focus on the most populated places to make it easy to see where things are going on.

Sorting by nearby rooms

@Khat, your suggestions are mainly aimed towards improving point 3 - exploration.
Having the exits in the Room page does indeed work against the exploration aspect of the Area page. Some sort of exit usage would be nice.

Problem

• No destination info available - Because how exits work, I currently don’t reveal the destination for exits through the API. One reason why exits doesn’t show their destination is because I don’t plan for it to always have one single destination. With the coming (in the future) of scripts, exits may or may not take you to the ‘default destination’ that you configure for the exit.
• Non-area destinations - Exits may lead to rooms not in the area. Or to rooms that belongs to a subarea of the current area.
• One way exists - Exits are one way. But this is a minor issue

Because of this (especially the first and last one), it is not as easy to map a location on the map that you click on, to an exit to use.

This can be mitigated with the idea of the exit linkage that I was talking about. By letting ‘links’ be their own entity that you can add to an area.

However, I would wish to find a way to avoid the “double work” of adding both exits and links in order to bridge the info-gap between rooms and locations.

Room short desc

Maybe we should have short desks for rooms too that you can see when hovering a location pin?
Hmm, or maybe short desc should be a Location property instead of area/room property…? Let me think about that

Seeing room desc while not in room

I prefer the idea that you have to be in a place to actually see its description. The same with characters descriptions. While being able to see a room without going there can be convenient, I’d rather want inconvenient exploration instead
Kind of like why people use lead/follow instead of summon/join.

Optional character location visibility

From a technical point, the “mutual watchers” option is far from trivial to achieve, nor would I want it. Such a feature would start leak info about who is watching who, which is something I’d rather avoid:

“Hey! Why can’t I see your room, but mrX can see it? You are watching him but not me?!”

However, it would be possible to make a “Show character location for all” setting.

Did I miss something that you wish my feedback on?

[Khat]

@Accipiter

We currently have 2 location types: room & (sub)area
As location goes, the two share similar traits; they have a name, a map position, a population.

This has mainly been the reason for mixing them in the list.
But I admit GUI wise, their difference is far from obvious. I have multiple times gotten the question why some “rooms are white”. So, I am up for improving it!

…

Because how exits work, I currently don’t reveal the destination for exits through the API. One reason why exits doesn’t show their destination is because I don’t plan for it to always have one single destination. With the coming (in the future) of scripts, exits may or may not take you to the ‘default destination’ that you configure for the exit.

This approach makes sense from a categorical standpoint, and since there are some technical hurdles in the way, rooms and sub-areas lack any distinguishing factors in this context; so it sounds like this one belongs in the “large effort for insufficient gain” bin. Maybe when we have access to some of the API changes you intend on making in preparation for Lua scripting and linkages and such, this could be re-approached.

---

@Accipiter

Maybe we should have short desks for rooms too that you can see when hovering a location pin?
Hmm, or maybe short desc should be a Location property instead of area/room property…? Let me think about that

I think this would be a nice little addition, if only to homogenize the list’s behavior. Probably not especially valuable, so whether or not that is simple to implement would definitely weigh heavily on my mind in your shoes.

---

@Accipiter

I prefer the idea that you have to be in a place to actually see its description. The same with characters descriptions. While being able to see a room without going there can be convenient, I’d rather want inconvenient exploration instead
Kind of like why people use lead/follow instead of summon/join.

lead/follow is wonderful, and things like it are definitely one of the factors contributing to the spatiality of MU*s in general. We don’t, after all, generally ask our friends in wetspace to travel on our behalf to later offer a teleport, we simply come along with them!

Actually, this came up at some point but it seemed too small to write a whole thread for: Would it be practical to remove the party size cap and instead display group arrivals/departures in one line? Or is this a limitation of how such notices are delivered in the backend?

Khaterín arrives.
Buddy arrives together with Khaterín.
Chum arrives together with Khaterín.
Pal arrives together with Khaterín.
Friend arrives together with Khaterín.

vs.

Khaterín arrives with Buddy, Chum, Pal, and Friend in tow.

Regardless, I can see why you want to be careful about incentives and information accessibility. Just a few tweaks can interfere with Wolfery’s illusion of spatiality, especially given modern expectations for omnipresence in apps such as Discord where users can keep tabs on any number of channels at once.

I do think that, for lack of either travel-on-click or look-through features, the area page remains an obscure and inscrutable interface. I cannot, for example, find the Silver Crescent in Do’nezo, and I don’t know whether that is because the exit is hidden or if I’ve repeatedly walked right past it.

Exit links on the map could help with such things, along with some of the other improvements to the map we’ve talked about already in the other thread. Perhaps being able to hide a room or sub-area from the locations list while still being attached to the overarching area could make this a little clearer; if the Silver Crescent is merely rumored in the area description, it’s more of a treasure hunt than a session of confused wandering.

---

@Accipiter

From a technical point, the “mutual watchers” option is far from trivial to achieve, nor would I want it. Such a feature would start leak info about who is watching who, which is something I’d rather avoid:

“Hey! Why can’t I see your room, but mrX can see it? You are watching him but not me?!”

However, it would be possible to make a “Show character location for all” setting.

That’s a good point; I hadn’t considered that. I think an opt-in global setting like that is useful for its own reasons, seeing as folks are unlikely to accept an unsolicited join request from someone they’ve never spoken to before, but had they arrived on their own and initiated an organic scene I would call that the MUCK working as intended.

That doesn’t as much address the steady stream of explorers passing by, but it sounds like that is less a problem and more an unavoidable consequence of spatiality. I usually leave arrival/departure toasts on even in high traffic areas, which is, at worst, an overstimulating nuisance that I can just turn off when I need to.

Maybe the toast notifications could be delayed for a few seconds and gagged if they depart within the grace period? Still have a notice in the log and such. That feels like a really comprehensive solution to a not very big deal, though, so .

[Accipiter]

@Khat

Would it be practical to remove the party size cap and instead display group arrivals/departures in one line? Or is this a limitation of how such notices are delivered in the backend?

It is partially a limitation.
Can a single grouped list be achieved? Yes
So, why hasn’t it?
Simplicity’s sake.

By grouping, I would also need to consider how to do with:

• muted characters - only mute if all of them are muted?
• focus - if one of the followers are focused, what to do with focus colors?
• language - to contruct the travel message, I would need a more advanced syntax, such as the icu-syntax or similar, to support any type of language.
• … and probably some more things

And also, I would need to do a bit of work on the backend. Not a big deal, but still.
So, I went with the simply way and sent a travel event for each!

But yes. We need to improve Area.
One think you should look at is my suggestion of exit icons, and especially the sentence about giving them a semantical meaning. Maybe this idea can be part of the Area navigation thoughts as well.

The Silver Crescent? A place completely unreachable? Cool!
But… yeah. I totally see your point!

[Tlancaalek]

@Accipiter

With the coming (in the future) of scripts, exits may or may not take you to the ‘default destination’ that you configure for the exit.

This is my favorite sentence in this whole discussion, and I can’t wait to see what sorts of stuff this makes posssible!

[Jagrabbit]

@Khat

Khaterín arrives with Buddy, Chum, Pal, and Friend in tow.

Looks simple up front, but I imagine there are multiple commands all interacting in the background which aren’t being accounted for in this summarization.

Exit travel/arrival/leave text is formatted in a specific way expecting that only the prefixed name will travel, so if we make any changes it will need to consider that.

The logic behind what we see feels to me like the follow and lead commands are processing their own arrival information in addition to the exit usage - trying to ball them all together would probably going to add extra complexity behind the scenes as well I’m thinking? (accipiter would know best on this one).
There might be an easier way to reduce this down to exit use and then pawning off the follow arrival having them instead to talk to the leader and having the leader output a simplified departure/arrival line on behalf of all successful followers who otherwise silently arrive in the room with them? I’m not entirely sure if this is as simple as I’m thinking since the follower would probably have to contact the leader and then the leader would output text according to those responses - maybe even more difficult to juggle for departures than arrivals too? This might be too bulky programming-wise even this way. Dunno, just brainstorming a bit on the idea because it would be nice to clean up at some later date as time allows.

Either way, the overall gains for the extra work feels pretty small overall compared to some of the things we need developed other than small clean-up and polish jobs when we only have the one developer currently.