Closed SilkieSabra closed 2 years ago
Medea-Destiny
commented
3 years ago @SilkieSabra thanks for opening this up and starting the discussion.
Medea-Destiny
commented
3 years ago There's a lot to pick out here, but I'll start with commenting on a few of the issues that @SilkieSabra raises.
"Macros" is a standard terminology for the function that these buttons perform - allowing multiple selections to be made from a single click. Windows has macros. Microsoft office has macros. MMO games have macros, and most gamers will be familiar with the concept of setting up keyboard macros. We should always be wary of discarding standardized interface terminology for a new terminology we have invented for the same purpose. If we're going to go with a different name, I'd suggest using "Presets", which while less accurate than "macros" at least is a familiar enough and intuitive term to describe what's going on. "Mixes" is a nice parallel, but it's an unfamiliar one -- instead of having to explain this to some people, we'd have to explain it to everyone.
In deciding the precedence of Macros/Presets/Mixes or Individual restrictions first, we have nothing but anecdotal user information to go on. This should not be relied on, because it's self-selecting -- you hear from people who want a change, not people who like things the way they are. I believe that the precedence should be other way around based on a. User Interface design principles, and b. the principle of minimizing interface changes -- that way around reproduces what people are used to seeing from the Restrictions button since 2015. This is a complicated issue, and also raises questions of menu fitting. I'll address this at more length in another post later.
I am very much for rationalising the macro/preset/mixes buttons as you suggest. In the current test versions of my rework, I have renamed the "Rummage" button to "Inventory" and the "Dazzle" button to "Names/Maps", which more clearly indicates what they actually do. As an indicator of the confusion that arises from current name choices, I believe that when @SilkieSabra referenced Dazzle above, she actually meant blur. We should be careful about removing things people are used to, but this is a valuable usability discussion. I would highlight that in my test changes, I have implemented a feature that allows the menu to list what restrictions are actually applied by each macro button on the menu. This is a very useful feature for user clarity that has been missing since the buttons were introduced. However it does make for a spammy menu. The first thing I'd like to use a spare button from removing a macro/preset/mix for is to put this into a button labeled "List Macros" or similar, which chats out details of what restrictions the buttons apply rather than having it in the menu.
If we go with the bottom-up rather than top-down approach (i.e individual restrictions above macro/preset/mix shortcuts), there will be significant problems with menu layout unless we DO recategorize individual restrictions as @SilkieSabra suggests to reduce the number of them. However with specific reference to the suggestion of moving acceptpermissions from misc to outfits, I would strongly oppose this on the basis that it would be entirely miscategorized - it has nothing whatsover to do with outfits. Additionally, the fact that there is a single restriction in the misc category is a bug which I have fixed -- we had several restrictions missing previously, and there are now several other misc restrictions listed.
SilkieSabra
commented
3 years ago to 1, a poll might be fun on what to call it--there's a strong argument for leaving it at "Macros" since by now at least some people are used to it.
@2) the widespread user confusion that led to a much applauded change for V8, in the placement of the button toward Restrictions, is not merely "anecdotal". All complaints are "self selecting". I think I disagree on your logic.. the logical directory should be "RLV > Restrictions > | Chat | Teleport | Interact | Macro . I liked "Mixes" because it emphasizes the difference between restrictions grouped \ across type and restrictions grouped by type. I was not suggesting "bottom up." Macros belong under Restrictions as they group some restrictions across type.
@3, I actually meant "Dazzle" because all the Dazzle Macro does is blur. It's Daze for some reason that uses the Navigation restrictions.
@4, again I am not suggesting we place individual restrictions above Macros. The Restrictions menu includes categories of restrictions; Macro is one way to group restrictions and should be on that page, not above it. In reference to Outfit, there might be another way to make room for an extra button.
Medea-Destiny
commented
3 years ago @SilkieSabra Calling the information "anecdotal" is not intended as a slight, please don't take it that way. You are presenting, to quote Wikipedia, "a claim relying only on personal observation, collected in a casual or non-systematic manner." - i.e anecdotal data. Because it is information collected in a non-systematic, non-empirical manner, we have no idea whether that information is representative.
Let me give you an example. You talk about "the widespread user confusion that led to a much applauded change for V8". I can equally point out that I have heard from people who dislike the change because they find the current Restrictions menu to present far too many options and be overwhelming. In a couple of cases I've pointed out that the buttons they were looking for are still there, just renamed Macros, which they were unaware of. This is ALSO anecdotal evidence. We could count the number of times we've heard one or the other and compare, but even that is of very limited value, because it's self-reported, non-systematic testimony. We have no idea whether people who are pro have the same likelihood of reporting as people who are anti, so we can't even guess at the weighting that we should apply to these numbers to make them meaningful.
I have gone through my logs of OpenCollar and OpenCollar R&D groups over the last year since the first alpha release of 8. All I can find that relates remotely to user opinion on this is: 1 user hoping that the restrictions menu be simplified. 1 user asking about the legacy restrictions script and being informed that they are available by default in 7.5 and 8.
This is contrary to the change being 'Much applauded'. Obviously I'm not on 24/7, but this is still a sampling of 175,000 words of discussion about OC, and provides at best 1 pro and 1 anti, if we're being generous. This is not to try to invalidate what you are saying, so much as to point out the whole issue of limited evidence. You've heard people saying it's great, but that's in a different arena/sample than my 175,000 words of group chat. Which is more accurate of the whole community? if we consider one source valuable and not the other, you get one story. If we do it the other way around, you get another. We do not have the user research to tell which story is more accurate.
There are two approaches to figuring out the best way of doing this. One is user analysis, the other is work analysis. User analysis would require making a language-neutral survey, and polling for opinion from a wide number of users. Work analysis involves basing the decisions on task-oriented work flow, and that's what produces the option I have come up with. I'll clarify that in the next post.
Medea-Destiny
commented
3 years ago "Macros", or whatever we call them, are short cuts. They are intended to provide a quick and easy way to issue restrictions that cover a majority of cases, from a single button press, with minimal technical knowledge required.
Individual restrictions allow the setting of about 60 different restrictions, some of which are far from being clear what they do without significant technical knowledge. Because of the sheer number of them, they are subdivided into various categories. Each one requires a minimum of 1 button press to activate (assuming the user is already in the correct category menu.
EXAMPLE: User wishes to stop wearer from dressing / undressing.
Using 8.1: Click RLV, click macros, click dress. 3 clicks total. Alternatively, click RLV, click Restrictions, click outfit, select 4 restrictions. 7 clicks total.
Note that in the use of single restriction macros (Hear, Talk), this comparison would only be 4 clicks not 7. On the other hand for macros that combine functions from several categories, it can be higher. For example to duplicate the actions of Stray via the 8.1 style restrictions menu would take 9 clicks vs 3.
Setting a macro with the two alternatives for a combined menu:
Macros at top level: Click RLV, click Restrictions, click dress. 3 clicks total.
Categories at top level: Click RLV, click Restrictions, Click Macros, click Dress. 4 clicks total
Setting a single restriction with the two alternatives for a combined menu (example: Temp Run) Macros at top: Click RLV, click Restrictions, click Detailed, click Movement, click Temp Run: 5 clicks
Categories at top: Click RLV, click Restrictions, click Movement, click Temp Run: 4 clicks.
From this we can conclude that:
Thus we can see from a workflow analysis that if we give equal weighting to macros and to individual settings then it is more efficient to put macros at the top.
This raises the question of whether we should give them equal weighting. If we knew for sure that individual restrictions were more popular, we should give it a higher weighting, which might balance out the workflow efficiency. If we knew for sure that macros were more popular, we should give that a higher weighting, but the workflow analysis favours that anyway.
We should consider the fact that:
CONCLUSION: Both workflow analysis and standard user interface design principles lead to the conclusion that macros should go first. The only thing that should contradict this is user analysis, which we do not currently have. As we do not collect usage data in any form, this could only be provided by polling data. In the case where user data is collected, the workflow analysis shows that it should take something more than a small majority to shift to a category-first arrangement, as the loss to people who would prefer a macro-first approach by going category-first is greater than the loss to people who would prefer category-first by going with macro-first. Historically we have done a bad job of explaining the utility of macros, and this will bias a sampling of users unless that sampling provides a clearer picture of the options than many people currently have. Thus such polling should include a clear explanation of the options, indication of the improvements to informative feedback that will be provided, and an explanation of how macro saving can be used.
SilkieSabra
commented
3 years ago I'll boil this down as much as possible.
I have a friend who is an expert on Egyptian ethnography, speaks Arabic, is married to an Arab, and has spent many years in both Cairo and Israel. Once a paper of hers was declined for a conference panel so she went to hear the paper that got in. The author did not speak Arabic and had an Egyptian co-author who administered and translated her survey. The survey was about street talk and asked Egyptian women how often strange men complimented them on the street. The answers on the survey led her to conclude that street compliments are very rare in Cairo.
In the discussion, my friend rose and said, "you can hear compliments being tossed out in the street any day just by walking down the street. Egyptian women, however, will never say so, not even on a survey, because that would be considered immodest."
The Egyptian co-author privately acknowledged this observation. The author dismissed my friend's objection as "anecdotal."
Social scientists, among whom I must reluctantly include myself (I'm more of a humanist at heart), love to argue about what is and is not anecdotal. "No we did not conduct a survey. Yes we addressed actual problems finding something in the collar that some people experienced because they couldn't find it in the menu. And yes, if you bury the Restrictions menu inside something called "Macros" again, the same problem will recur. The problem is lack of context for the term "Macro". If it's inside the Restrictions menu, it's clear that it's a Restriction macro, not some macro of something else RLV related.
Medea-Destiny
commented
3 years ago Ok, this long discussion about the nature of anecdotal evidence is probably confusing people and is really besides the issue. :D You have reported hearing people state a particular opinion. That is the very definition of anecdotal evidence! I'm not sure why this is even a discussion, though perhaps you being a social scientist may explain it. To be clear, I'm not making an attack on social science as being a "soft science" that relies purely on anecdotal evidence, which is something you may well have experienced before. I am merely pointing out that anecdotal evidence lacks the data about significance to allow it to be assumed to be reliable. If I was doing the hard science thing, I would suggest that my sampling of somewhere of the order of 10% of a year's worth of talk in OpenCollar and OpenCollar R&D, which is clearly a very statistically significant sampling, invalidates your anecdotal evidence. I'm not. I only pointed it out to show that we have contrary evidence. I'm just pointing out that we don't know. Anecdotal evidence can be useful. It might be correct. See your anecdote about anecdotal for an example. However, we don't know.
That out of the way, let's get onto the important stuff:
Using these kinds of parallels can be a useful way to get a clearer picture of something when we're all perhaps too close to the issue, so let's follow that method.
The "Macro first" model, applied to animals:
London Zoo Seattle Zoo Paris Zoo Berlin Zoo Bronx Zoo Singapore Zoo Individual animals Settings Back
Compared to the "Categories first" model:
Birds Mammals Fish Insects Reptiles Marsupials Zoos Settings Back
The first one makes more sense. People are more likely to want to see more than one animal at a time, and have the experience curated for them. However we have a submenu for people to look up individual animals if they want. The second one places Zoos at the same hierarchical level as classes of different animals, which makes no sense, and requires people to navigate further on average (see my work analysis above).
Medea-Destiny
commented
3 years ago To clarify what is being discussed here without similar misunderstanding as the "buried in something called macros" one, here's what the two options being discussed actually look like. On the left you can see a "category first" approach, and on the right a "macros first" approach. In both cases, you're seeing what you would see if you click the RESTRICTIONS button in RLV.
This should help clarify things for people who haven't tried the new system yet (gimme a holler in world if you want to). You can immediately see one of the consequences I discussed in the work analysis above -- in the categories first menu, you are ALWAYS going to need to click at least 1 extra button after entering the Restrictions menu before it is possible to actually add any restrictions. On the contrary in the Macros First arrangement, the collar user can immediately set restrictions from the Restrictions menu.
Just to be clear, this is solely a question of user interface arrangement. Click the macros button in the categories-first option, and you'd get all the options you see in the macros-first option. Click the [Detailed] button in the macros-first option and you'd get all the options in the categories-first menu.
lillith-xue
commented
3 years ago Wow, what a huge discussion. The idea behind the default macros at the "front" page of rlv was to imitate the menu of the previous rlvsuite. The older version only provided those Buttons, and for people who where ok with that, the default macros where made to be found at the same place, with the same name. Only the ones who want more need to enter the more complex menu's.
Pingout
commented
3 years ago I personally do not have a preference either way. One click more, or one click less does not make much difference to me. That being said, I do think the discussion is a good thing. I've enjoyed reading all of the comments. I really appreciate @Medea-Destiny's idea (paraphrased) of getting these changes in front of as many eyes as possible. What we're moving toward, I hope, is a true collaboration between script writers and script users.
totcorr
commented
3 years ago I have a strong preference for what Medea calls the "MACRO" layout, because in my experience, the average user of the collar isn't likely to go digging around into multiple levels of menus to try to find out how to do something. Especially since the documentation for OC always lags significantly, so there's nowhere for them to go look things up .. even if they were likely to RTFM, which, lets face it, most people will never do either. So making the simple restrictions available directly at a higher level of the menu structure makes a lot more sense (to me), because the majority of people will then actually discover them.
To think of it another way, consider trying to instruct a new user HOW to go turn off the ability to hear things. The more menus they have to traverse, the more likely that even the average helper trying to instruct them is going to say something like .. "Open up the collar menu, then find the RESTRICTIONS button .. then .. find a button labeled something like 'Chat" .. and then under THAT .. find another button labeled ... oh hold on .. let me open up my collar so I can find out what the names of those are." In a two tier system, at least you say "Find the Restrictions button, then under that look for Hear."
SilkieSabra
commented
3 years ago My point about "anecdotal" was that empirical experience of actual support hours spent in inworld might be filed away and dismissed as "anecdotal" because it was not recorded on a time sheet. The evidence that remains is the fact recorded in the Release Notes that we did move away from that scheme for cause once before. The whole long piece about why a "Macro" is not a category is also beside the point. Would it help if i used the word "class" instead of "category"? This is just semantics. A Macro is a group of restrictions related to one another by coordinated effect rather than type (to repeat my earlier post). It might have a conventional definition in the computing world but it's being used metaphorically here and I'm looking at the underlying logic for how it is being used in this particular context. I am advocating for the image on the left above. In the image on the right, what you see under "Restrictions" is all the Macros, plus something called "Detailed" . It loses me. The image on the right, sans "Detailed", should be what you see when you press Macros in Restrictions.
Trinkitz
commented
3 years ago I have worked with these menus quite a bit, and do a fair amount of assisting new users. I can say without hesitation that I believe the image on the left above is absolutely the best option. Giving users a list of macros when they click on "restrictions" in the RLV menu will only add to what I see as widespread confusion about what macros do.
In the image on the right above, a user who wants "restrictions" (that are NOT macros) has to click "restrictions" and then "detailed" - in order to get to those restrictions they were looking for in the first place. Seems quite backwards to me.
Also, and I think this should be a priority: Many "macros" are nothing of the kind, as they only apply a single restriction. I think we should either eliminate them, or add more restrictions to them so that they are truly macros.
Medea-Destiny
commented
3 years ago @SilkieSabra As I keep am not dismissing your evidence just because it's anecdotal. I am simply pointing out that it is not systematic comes with no indication that it's representative and therefore can only be considered a datapoint rather than proof of general opinion. The systematic, repeatable, and also empirical data I provided (sorting through significant proportions of the actual group chat logs) doesn't support it. A data scientist would probably call it much better data that your anecdotal data, but I'm not even saying that. I'm just saying that it shouldn't be dismissed either, and we have to conclude that neither case has been proven. When it comes to broad user-preference, we do not know. Lacking user analysis, the logical thing is to go with workflow analysis, which favours the macro-first approach, and standards in user interface design, which also favours macros-first.
The point that macros are not a category is an important one, because treating them as if they are one is nonsensical. Macros are a higher level of abstraction of the user-activity of applying restrictions to the wearer. They require fewer clicks to achieve common user goals. It is backwards to put a higher level of user-abstraction at a lower level of user-attention. It is backwards to give a high-level abstraction the same user-interface weight as the low-level function. Decades of user-interface practise oppose this. If we had solid user-preference information in favour of breaking these standards that would be one thing, but we do not.
Medea-Destiny
commented
3 years ago @trinkitz Macros apply restrictions. They are what people have seen for most of the past six years when they click the Restrictions button. I don't think people will be more confused by seeing the same options they have been used to seeing for years than seeing something different.
Conversely to your point about people having to make an extra click to get to individual restrictions, the category-first approach requires them to make an extra click to get to the restrictions buttons they have been using for years. This is in favour of the individual restrictions, which will require more than one click anyway, because clicking from that menu only takes you to a category, it doesn't set a restriction.
That is a very important point to emphasise, and I'll reword it in this fashion:
With categories-first, you are forced to enter submenus before ANY restrictions can be set. With macros first you can set common restrictions immediately, and only have to enter submenus for more complicated or less usual tasks.
Remember the golden rule user experience: increasing depth drives people away. Setting individual restrictions is fundamentally a depth task -- she sheer number of options requires this. We can't get around that. We can offer an alternative that doesn't require people to go hunting through submenus to find out what they want to do, and that's what macros offers. It doesn't make sense to create an option that saves people from hunting through submenus and then hide it away in a submenu.
Consider this in terms of assisting users, as you bring up. Your new user wants to apply some restrictions. With the macros-first approach, the conversation might go something like this: New User: "I want to restrict the collar wearer, how do I do that?" Helper: "Go to the restrictions menu and you can see restrictions options. If you're not sure what they do, click the "list macros" button and it will tell you." New User: "Got it, thanks. What does the Detailed button do?" Helper: "That lets you pick and choose specific individual restrictions, you can explore that level when you get used to what they do." New User: "Cool, I'll look into that later as I learn more about RLV."
OR category first New user: "I want to restrict the collar wearer, how do I do that?" Helper: "Go to the restrictions menu, and you can find lots of submenus that lead to 60 different options for individual restrictions." New user: "That's a lot of sub menus to hunt through. How do I find the one I want? I just want to stop someone from doing X." Helper: "Well you could set restrictions a, b and c." New User: "Uh. Okay, I found b. Where's a and c? You know, never mind." Helper: "Or you can click the macros option for common tasks" New user: "Oh that sounds useful. Why's that hidden?"
Conversely, a more advanced user: Advanced user: "I never did like the limited options for restrictions. I want to do something more in depth." Helper: "No problem, click the Detailed button." Advanced user: "Oh! Yeah I know where I'm going now, thanks."
As for improving the default macros that we currently present? Sure, sounds like a good plan.
Trinkitz
commented
3 years ago I have accounted for every point you raise. I understand, but do not agree. It's OK. We are all not going to agree on everything. I feel very strongly that macros should be a spur from restrictions, not the other way 'round. Your support explanation would be much shorter if the left image were used, as the user would get restrictions - actual ones, not shortcuts to groups of them - when they click the "restrictions" button. "How do I restrict their chat?" - "Click rlv - restrictions-' chat" and then select what you want." - sorted...and forms a good basis for introducing the concept of macros.
The use of the macros button would be a valuable discussion for the beginner wanting to short-cut, or even build their own. But I think they will learn better this way; having macros as a button in the restrictions menu clearly establishes their relationship with true, stand-alone restrictions.
It's just much more linear in my opinion to do it this way, and that simplicity is well worth an extra click. But again, no worries about disagreements. I have my opinion, and given the amount of time and effort I spent developing it, I am very confident it's the best way to proceed. But I understand I am far from the last word, and will work with whatever is decided.
Medea-Destiny
commented
3 years ago @Trinkitz It's all good, having a proper debate is what we're all about here! Having alternative viewpoints and discussing them is healthy. As you can tell from the work analysis I did and the references to good UI design practises, I am equally confident that macros-first is the best way to proceed!
Let me just deal with your:
"how do I restrict their chat?" "click rlv - restrictions-' chat" and then select what you want."
I think for a new user, the likely way this conversation actually goes is:
"how do I restrict their chat?" "click rlv - restrictions-' chat" and then select what you want." "I'm not sure what I want. What do all these different options do?"
Let's contrast this with the macros approach:
"how do I restrict their chat?" "click rlv - restrictions-' chat"
and then select what you want. Done!"
This is the power of using abstractions in user interfaces. Say the user's going to set two restrictions for blocking chat. The category approach requires traversing 3 levels of menu depth (remember that each additional level of menu depth requires greater user-attention and drives more people away from performing the function) and making 5 button clicks. The macro approach requires traversing only 2 level of menu depth and making only 3 button clicks.
SilkieSabra
commented
3 years ago Except "chat" is not a macro, and neither is "talk", because it's only one restriction, it's really a shortcut to a popular restriction
Trinkitz
commented
3 years ago My focus is on teaching when I deal with new users; teaching from the left image builds on base concepts, rather than teaching the fast way and then hoping they de-construct it on their own sometime later...to understand what that "talk" button they pressed really does. I want people to not just get somewhere, but to understand how they got there. But again, whatever is decided, I will go with.
Medea-Destiny
commented
3 years ago @SilkieSabra
Except "chat" is not a macro, and neither is "talk", because it's only one restriction, it's really a shortcut to a popular restriction
This isn't a good counter-argument. Shortcuts to popular functions are a good thing.
We absolutely could improve the user-experience by looking over the macro functions and improving them. I think everyone agrees that is worth considering.
SilkieSabra
commented
3 years ago I'm just saying it's in the Macros menu because when Macros menu was a top menu in RLVa, and Restrictions wasn't, it was added to the Macros menu to be a shortcut, not to be a Macro. It's not a Macro. If we don't need it as a shortcut, I agree with Trink we should delete it.
Medea-Destiny
commented
3 years ago @SilkieSabra Entirely understood! That just raises the IF of if we don't need it. At the moment it provides quicker access to a common function, and less exposure to technical and unintuitive functions. Many if not most OC users are not power users and find that huge list of restrictions confusing and intimidating. We should be catering for them.
Without that button, people would have to navigate to the chat category, then look through the 12 options there, and would need to know whether what they want is "Send chat" or "normal chat", whether they need to click "whisper" and "shout" as well, and maybe "send emote" and "gesture" as well.
We shouldn't remove a button people have been seeing and using for the last six years just plus because there is a more complicated way to perform the same function for power users. I think a more useful consideration would be that now we do have the individual restrictions available as well, whether we can use those macros in a better way.
Trinkitz
commented
3 years ago Then it's a "shortcut" not a "macro" - which further blurs what is already a confusing topic for new users. It's true that new users do have to navigate a bit to get to the restrictions they want; during that entire journey they are learning. Their next time there, they may explore other options, or decide that a macro is better suited for them. Even better, they may decide to build their own macro.
Something I see time and again is that experienced users are only familiar with a small percentage of OC's capabilities and menus; I think shortcuts like macros have a lot to do with that. As I see it, if our goal is to get them somewhere we think they want to go as quickly as possible, then it's macros first. If we want to teach them while allowing them to find the best OC options to suit their needs, then it's restrictions first.
Medea-Destiny
commented
3 years ago Ok, let's talk about the TALK macro, and why it's NOT just a shortcut.
Click Talk, and you'll see the @sendchat=n restriction being set. Seems like a shortcut, right? Nope! Because it does more than that. If you have muffling active*, it will ALSO send a chat redirection, which is required for the muffle function. If we get rid of that, we entirely remove the capability of the collar to provide chat muffling, unless we put that option back in elsewhere, in a further buried menu.
BUT, we can make this TALK macro even better. Activate it with muffle inactive, to get that @sendchat=n restriction. Now type "/me doesn't seem to be able to talk! I am restricted!" See what happens? It gets truncated. This is a standard effect of the @sendchat restriction. We can stop it happening, by very counter-intuitively issuing the @emote=n restriction, or as it is equally confusingly called in the chat category menu, EmoteTrunc (we could make this a bit clearer by renaming it something like "EmoteFull", but it's never going to be explained in a 10-12 character button). So, let's make the talk restriction smarter by adding the @emote=n restriction to that macro, rather than removing it and expecting people to know that "chat" means "I'm going to shorten your emotes", and that to fix that you have to restrict emote truncation with "EmoteTrunc".
People who aren't scripters or highly advanced users shouldn't need to learn all this stuff. We should be providing easy, intuitive ways for end users to quickly get the effects they want, not requiring them to dig through multiple sub-menus and learning the arcane inner-workings of the RLV API to be able to get on with having fun.
*NOTE! I have just noticed a typo that stops the muffle option in [MANAGE] actually going to the muffle options menu in the v4 tester suite. Testers can fix this themselves by changing line 654 of oc_rlvsuite to: else if( sMsg =="Muffle") llMessageLinked(LINK_SET,iAuth,"menu managechat",kAv); -- but I'll send out a v5 soon.
Trinkitz
commented
3 years ago Bolstering the single-restriction "macros" would be wonderful. I would much prefer that to eliminating them. As you and I saw the other day, there are some strange restrictions triggered by some of those macros. Hopefully those will be sorted as well. Look forward to v5 .
Medea-Destiny
commented
3 years ago @Trinkitz Yes you should find those oddities are all fixed in the current test version you have. One of the beauties of the Macro system is fixing those things is trivial. Remember you can click the "List Macros" button to see exactly which restrictions will be set by each Macro button - that isn't pre-written text, it's actually drawn from the macro settings, so it's always accurate, and will be provided for any custom macros that are created too!
SilkieSabra
commented
3 years ago They were put there as shortcuts. If you want to make them real macros, that's fine with me.
nirea
commented
3 years ago I have skimmed the discussion above. I haven't read the really long comments.
It seems to me that we're all tangled up in this distinction between "macros" and "restrictions", and that's probably focusing on the wrong thing.
Think of the thousands of users of the collar; not the super advanced power users that we developers are. The average user has no fucking clue about the distinction between a macro and a restriction. And we shouldn't require them to.
Users care about turning off chat. Or teleport. Or whatever. If there are nuances to that which require multiple RLV commands, fine, send multiple commands. I'm not convinced that a separation between "Macros" and "Restrictions" makes sense from a typical user's perspective. I don't think changing it to a distinction between "Restrictions" and "Mixes" fixes that.
I'd rather start with a menu design that asks the question "What specific things are users trying to accomplish when they click that RLV button?" Let's make those things fast and easy. If there are more niche use cases, those can be stuck in an Advanced submenu or moved to an add-on script
nirea
commented
3 years ago Here's my mockup of a design that puts commonly-used functionality front and center for the user, while moving more advanced stuff deeper. When someone clicks Restrictions, I think they should see this:
Common functionality is right there. Under the hood, those "Hear", "Talk", etc. buttons use the macro system to issue multiple commands at once. But we don't need to use the word "Macro" with users or bother explaining it. They're just buttons. If they want to customize the buttons, they can do that. If they want to get down to the level of individual RLV toggles (what we've formerly considered "restrictions"), that's under the Advanced menu.
nirea
commented
3 years ago Maybe the [Customize] one would be clearer if labelled [Buttons]. I could go either way.
nirea
commented
3 years ago Oh and I guess the dialog text would change, since it wouldn't need to explain "Macros" anymore.
Medea-Destiny
commented
3 years ago I'd rather start with a menu design that asks the question "What specific things are users trying to accomplish when they click that RLV button?" Let's make those things fast and easy. If there are more niche use cases, those can be stuck in an Advanced submenu or moved to an add-on script
This is exactly the purpose of this redesign. @nirea said this in the weekly meeting today that I think sums things up nicely:
Redefine the concept of "Restrictions" to include sending multiple RLV commands when it makes sense. Make the most-used buttons easiest to find and if people want to get into the fine-grained RLV toggles, that can be an Advanced submenu
This discussion can and should be considered to address two separate issues.
A reversion of the 8.0 change to Macros and Restrictions as separate menus. As Roan has said, this change was made reflecting the fact that there are people who want access to the fine-grained control that setting individual, low-level restrictions provides. The way this was handled was to move the fine grained control returned to OC in 7.4 up from being a submenu of RESTRICTIONS to being the actual RESTRICTIONS menu, and creating a second top-level menu called MACROS -- which is in fact also for setting restrictions, and provides the functions that people are used to seeing if they click the RESTRICTIONS button.
People who click RESTRICTIONS expecting what they have been used to seeing there since OC4 have to be told to go to a menu called MACROS to set those restrictions instead. This is a confusing change, and the benefit is solely to save one extra button click for power users. I suggest that what we should actually be doing is telling those power-users who want to have access to the fine-grained control that it's right there in the submenu, be that submenu called ADVANCED, [Individual], [Detailed] or whatever. Thus my proposal is that the change made for OC8 was a mistake that provides a very minor benefit to power users at the expense of a more complicated menu structure and added confusion to regular users, and should be reverted
Improving the user experience and user interface for Restrictions. This is the bulk of the changes I have made, and I think the focus on the discussion of the above has meant we haven't discussed this part enough. You will notice for example that there is now a listing of what restrictions are actually in place in the menu prompt. This is a lot better than having to troll through a dozen submenus to find out what is or isn't ticked. You'll see there is a button called LIST MACROS which chats out the actual effect of each macro button, so users are no longer going in blind when they click a button called "Daze" or whatever. Note that this is not a pre-defined text, it is generated dynamically -- if people make their own custom macros, it will include those.
What we are left with is the question of terminology. Macros? Burn the term. Happy to. ADVANCED or [Detailed] or [Individual]? So long as we now actually have menu prompt text that at last explains what that button is, no big deal. CUSTOMIZE, Settings or [Manage]? Same thing. It's all just a question of terminology, and I come into this discussion with very little preference. Renaming some of the macros/presets/whatevers? All for it. I already renamed "Rummage" to "Inventory"; "Daze" to "Names/Maps"; "Dazzle" to "Blur". I think these are a lot more intuitive, but I'd love for people to offer their own suggestions.
On the specific issue of what is currently called MACROS, I think it is important that we create some differentiation between them and setting individual RLV restrictions, because they are conceptually different. They can set more than one restriction, and they are customizable. Neither is true of the individual restrictions stuff, which is about exposing the low-level functionality of the RLV API to users who want access to that. In my recent tweaks of menu text I have tended to favour PRESETS which I think is nicely non-technical and explains what they are reasonably enough. The fact that they'd be put in the RESTRICTIONS menu makes it clear enough that these are preset restrictions, and this differentiates them from the fine-grained restrictions sufficiently.
Medea-Destiny
commented
3 years ago Well, #664 . This has been fun. While hammering at oc_rlvsuite to try to break it as a way of testing if it can cope with the smaller amount of free memory it now has (it seems to be able to), I tried setting MANY restrictions, and what do I find but the restrictions menu (since 8.0) is pretty broken. Basically if you've got any of the first half of the list of restrictions set, you cannot set any of restrictions in the second half of the list. It took me a while to figure out what was going on, but I have a fix for this now.
I'd say given that nobody appears to have noticed this rather major bug yet, it probably suggests that the individual restrictions menu just isn't all that popular, and it's probably best keeping it there in that advanced menu...
Talking of which, this is what the menu looks like, as per @nirea 's suggestions:
Trinkitz
commented
3 years ago Is the testing team going to have the opportunity to test the menu structure with restrictions listed first? The one as shown in the left-side image above. There is really no way to compare functionality / ease of use without seeing and using both proposed menu structures. Thank you.
In V 8.1, Macros and Restrictions are buttons side by side in RLV : RLV > Restrictions | Macros. This was done for V 8.0 because there were a lot of complaints about having "Macros" on the front page of Restrictions and other restrictions grouped under that: RLV > Macros > Various Macro Buttons | "Individual". Even before that fix, some popular restrictions were given top billing on the Macros page: Talk, Touch, Hear, IM. This has resulted in an inflated number of "Macros." I believe the best way to reorganize this is to: