Am I reading your comments correctly that the bug appears for you when entering/leaving bg's, but when you reload inside a bg it'll work all thruout that one bg?
Here is how it works so far ( i have only tested it in battlegrounds aka in raids ):
I am in dalaran w8ing for the queue. i lay down my totems.. everything works
When i am solo questing again everything works ok
When i enter a bg ( or wintergrasp) some times i will try to lay down totems at the begining and it will work.. some other times it wont. The point is that either at the begining or at some other point durring the battleground/wg my totems will just stop showing up in the totem bar. I dont get an error then.. they just stop appearing. The first time it hapened.. i did /console reloadui (which is when i get the error ) and they would show up again for a little while until they got bugged again.
So to sum up..I think it has something to do witht the fact that i am in a raid.. and maybe totem bar responds badly to it..?? ( also i have party not to show when i am in a raid.. but i doubt thats important)
PS: i havent tried it in 5 man situations.. ill try and ill let you know how it went
Edit: i run some 5 man dungeons and i had no problems there so i guess this narrows it down a bit. looking forward to hearing from you!
Interface\FrameXML\UIPparent.lua:232: attempt to concatenate local 'reason' (a nil value)
I can tell you that this error message has nothing to do with PitBull4. It's actually a bug in the Blizzard UI. LoadAddOn doesn't work until later than it used to. The default UI tries to use it and the function doesn't load the addon but also doesn't bother to return the reason why it didn't. Which of course it then tries to use and it's empty. In particular you see this when reloading in a battleground because it tries to load the minimap.
I can tell you that this error message has nothing to do with PitBull4. It's actually a bug in the Blizzard UI. LoadAddOn doesn't work until later than it used to. The default UI tries to use it and the function doesn't load the addon but also doesn't bother to return the reason why it didn't. Which of course it then tries to use and it's empty. In particular you see this when reloading in a battleground because it tries to load the minimap.
Great.. so we know where it comes from i guess. Any chance i can do something to prevent it?( say..hide the minimap? will that help?)
Great.. so we know where it comes from i guess. Any chance i can do something to prevent it?( say..hide the minimap? will that help?)
Nothing you can do. I don't think it has anything to do with your totem issues though. I could be wrong. I believe it's fixed in 3.2.2 but I haven't bothered to test it on the PTR.
...In particular you haven't been using language that conveys your understanding of the design paradigm used in the configuration while identifying the usability issues. I'm open to suggestions and ideas and even criticism. But I haven't been responding to criticism nor has anyone else...
Where I work, when design issues are identified (by myself or anyone else in the department), time is not wasted on diplomacy. Issues are identified and forwarded, as are ideas for improvement (unlike some workplaces, test ideas are held in equal weight with coder ideas). There is no "role playing" involved; continuing the view of how a design first struck the tester in further discourse is part of the process. Sorry for not spending more time to smooth out the posts more diplomatically and/or getting away from my RL work process.
If you want to demonstrate how you think something is confusing it'll be much more constructive to just come out and say "I found this confusing in this way." Then make suggestions on how to make the configuration convey the existing design more clearly. As opposed to making suggestions of how to make the configuration fit how you think the addon should work.
A grand total of 0 of this has anything to do with "how I want to see things", "how I want it to work" or anything similar. I don't care what I think about things ;). As per above, improvement suggestions were forwarded, do with them what you will.
When you have different "menu" selections (dropdowns as they are now, words on a bar the provide their own dropdowns, etc.), its atypical and not intuitive behavior for options for such selections to directly affect the options of other, different selections.
For a very general example, take the Windows Explorer menu bar. Select "Tools", "Disconnect Network Drive". In doing so, you don't expect "View", "Status Bar" to automatically checkmarked as well. Its the same issue when talking about identical options attached to multiple, different selections.
A few ways around this. One is to group the options that change name or function between Unit group selections, say, all together in a separate section at the bottom of the frame. So that its more clear which options are effectively "global" between Unit group selections and which are different (in name or function).
Or, with more coding work needed, what was brought up before about "separate global menu choice" among the Unit Group dropdown selections. When you choose "Global" from the menu, the only options that appear in the current option frame are those that are identical in name and/or function among all the frame Unit Group selections. Then when you select a different Unit group like "Party targets", the frame is cleared and only options (if any) specific to that unit group show in the frame.
Or, connected to the above, instead of separate Unit groups in a dropdown menu, instead have them as a column of checkboxes. Along with a "Global option" checkbox. Checkmark the "Global" one, it behaves as above; the options that are universal among the selections appear on the frame. Checkmark an actual frame unit group, the unique options (if any) for it appear in the frame instead.
Or something else that makes it more clear which Unit Group options are shared.
Except that there's a couple of other considerations about making groups prebuilt for users:
a) It implies, though inaccurately, that the premade groups are the limit of the possibilities. Having no raid group, communicates something. We advertise that we have raid frames. If there's no raid group, then there must be someway to make them.
Or the other possibility: the thought that there is no first-apparent way to make them at all. Have generally never found that having default settings affects perceptions of available options. Other than among those who would never look for options in the first place.
b) A significant proportion of our user base doesn't use our raid frames. Probably the vast majority of the user base uses grid. They have no interest in raid frames. To those users no raid group is a perfectly reasonable default state.
c) There is overhead in having uneeded groups defined. It takes up memory, it takes up disk space, it adds clutter to the configuration.
Yep for sure. If that's the specific, intended audience--unit-frame users-who-don't-want-raid frames--it might save even more memory, etc., completely removing "Raid" from the unit group options and elsewhere. Put it all in the LOD "Raid" module. Or remove the frames entirely.
Or something. Having raid frame availability but to not have them active at all without a lot of setup is atypical and is not a common expectation for self-contained unit frame mods. Same thing with party targets, etc..
What you consider a good default state may very well not be for the majority of our users..
Yep, no question. What I want is completely irrelevant. The only reason for me making the "increased number of defaults" suggestion was to have it more in line with what other unit frames (besides oUF) do. So that new users coming to this have less to initially deal with and improve the OOB experience.
Where I work, when design issues are identified (by myself or anyone else in the department), time is not wasted on diplomacy. Issues are identified and forwarded, as are ideas for improvement (unlike some workplaces, test ideas are held in equal weight with coder ideas). There is no "role playing" involved; continuing the view of how a design first stuck the tester in further discourse is part of the process. Sorry for not spending more time to smooth out the posts more diplomatically.
A lot gets lost when all we have is text instead of face to face.
When you have different "menu" selections (dropdowns as they are now, words on a bar the provide their own dropdowns, etc.), its atypical and not intuitive behavior for options for such selections to directly affect the options of other, different selections.
I don't think this is atypical behavior at all. I disagree with this sentiment entirely. Options impact other options all the time. I think you'd be hard pressed not to find a major app that doesn't cause some options to disable based on others.
For a very general example, take the Windows Explorer menu bar. Select "Tools", "Disconnect Network Drive". In doing so, you don't expect "View", "Status Bar" to automatically checkmarked as well. Its the same issue when talking about identical options attached to multiple, different selections.
This seems like nothing more than a straw man argument. The options that change aren't arbitrary. They are very much connected to what you're changing.
A few ways around this. One is to group the options that change name or function between Unit group selections, say, all together in a separate section at the bottom of the frame. So that its more clear which options are effectively "global" between Unit group selections and which are different (in name or function).
The only two that change are the vehicle and the Include player options. They're both at the bottom now. They're both situated now so that they don't move and appear in the same location regardless of the presence or removal of the other.
All the options are global. There's not a single option that isn't impacted by what you set no matter what the Unit group is set to. The only sorta exception to this is the two I mentioned above. However, while they might have slightly different meanings depending upon what the Unit group is set or even not be relevant and then hidden. The underlying storage is still the same.
So I'm not sure what you're advocating that I move to convey more clearly is different from other things when they are all the same as it is.
Or, with more coding work needed, what was brought up before about "separate global menu choice" among the Unit Group dropdown selections. When you choose "Global" from the menu, the only options that appear in the current option frame are those that are identical in name and/or function among all the frame Unit Group selections. Then when you select a different Unit group like "Party targets", the frame is cleared and only options (if any) specific to that unit group show in the frame.
I think this is entirely illogical. The dropdown to choose which set of units the group will be showing is not intended to be selected through to configure different things. Like I said, you're editing one object. Not a set of objects. Some of the sets of units have different options. Mostly, because Blizzard only uses some options for certain units. Not because I like that they're limited to that.
I really do honestly believe that your proposed change is more likely to cause confusion. Not less.
Or, connected to the above, instead of separate Unit groups in a dropdown menu, instead have them as a column of checkboxes. Along with a "Global option" checkbox. Checkmark the "Global" one, it behaves as above; the options that are universal among the selections appear on the frame. Checkmark an actual frame unit group, the unique options (if any) for it appear in the frame instead.
Or something else that makes it more clear which Unit Group options are shared.
You're trying to use the Unit group dropdown as a configuration compression tool. It's not. It's a real choice. You get to chose one set of units for the group. I don't think your suggestions are an improvement.
Or the other possibility: the thought that there is no first-apparent way to make them at all. Have generally never found that having default settings affects perceptions of available options. Other than among those who would never look for options in the first place.
Yep for sure. If that's the specific, intended audience--unit-frame users-who-don't-want-raid frames--it might save even more memory, etc., completely removing "Raid" from the unit group options and elsewhere. Put it all in the LOD "Raid" module. Or remove the frames entirely.
The raid frames share all their code with the party frames. Outside of some options that Blizzard flat out ignores (and thus I hide for those unit sets) there is no code difference at all from a Party frame and a Raid frame.
Or something. Having raid frame availability but to not have them active at all without a lot of setup is atypical and is not a common expectation for self-contained unit frame mods. Same thing with party targets, etc..
Yep, no question. What I want is completely irrelevant. The only reason for me making the "increased number of defaults" suggestion was to have it more in line with what other unit frames (besides oUF) do. So that new users coming to this have less to initially deal with and improve the OOB experience.
I don't really consider what you have to do a lot of setup. You go to groups, type Raid in New groups, select Raid from the Unit group drop down and for all practically purposes you're done short of positioning and formation type stuff.
That said I'll consider adding in a raid group as a predefined group with it disabled. But I don't think I need to make groups for every set of units. The design of the groups as independent objects that you can define as many as you want is a deliberate design decision. That is intended to be very different from other existing unit frames.
If people are looking for what the other unit frame addons offer as far as a preset list of what you can do that you play within the sandbox that the developer intended, then you're not likely to be happy with PitBull4. That's just not the direction we're taking PitBull4.
We're certainly trying to make it easier to configure. I think it is drastically easier to configure. That's not to say there isn't some degree of learning curve due to some of the concepts being entirely different from other unit frame addons. But I don't think the concepts are particularly difficult to understand.
All that said, I really do think you pretty much don't understand the configuration model for that panel. You're still thinking like the structure of the configuration is as follows:
[ Current group
[ Unit Group
Various Options
]
]
When it's really:
[ Current group
[ Unit group ]
[ Various options ]
]
Unit group is really just one of the various options for the Unit group.
I just did an addon update and reinstalled Pitball w/ v4.0.0-beta5 but when I log in, I can't see any of the Pitbull frames and the default WoW UI is loaded. I can still access the Pitbull options via /pb and everything is enabled. Any ideas or suggestions?
I think the point Shefki is trying to get across is that each frame or group of frames has options, and among those options is the unit or group of units for which it displays data. All the options configure how a certain frame is displayed, not how a certain unit's information is displayed, and some of those are dynamically hidden when they're not relevant to the unit chosen for display. All the options are global, though, because there would be no meaning to non-global options that are unit-specific: the frame can't change the unit it displays by itself or by any conditional logic (vehicles notwithstanding), and if you frequently change which unit a frame displays, that speaks to a totally different problem.
It might be more clear that all these options are global if they were checkboxes that become gray when the option is not relevant for the unit of display, but that has little functional bearing on how the frames work now, and I can understand how showing irrelevant options might be confusing to users.
In the end, though, I think PB4's model is sound: units are data sources, nothing more, and how you want that data displayed is the job of the frame or the layout to handle. Units in and of themselves need not have display options associated with them, only insofar as to handle the differences in the data they provide.
I think the point Shefki is trying to get across is that each frame or group of frames has options, and among those options is the unit or group of units for which it displays data. All the options configure how a certain frame is displayed, not how a certain unit's information is displayed, and some of those are dynamically hidden when they're not relevant to the unit chosen for display. All the options are global, though, because there would be no meaning to non-global options that are unit-specific: the frame can't change the unit it displays by itself or by any conditional logic (vehicles notwithstanding), and if you frequently change which unit a frame displays, that speaks to a totally different problem.
Correct.
It might be more clear that all these options are global if they were checkboxes that become gray when the option is not relevant for the unit of display, but that has little functional bearing on how the frames work now, and I can understand how showing irrelevant options might be confusing to users.
I'm not a huge fan of disabled boxes that aren't relevant. I think disabling the boxes makes a lot of sense when they're just disabled because of a checkbox or something. E.G. the way things are disabled when the Enable boxes on bars, units, groups etc are disabled.
However, when how you enable them isn't particularly obvious it leads to people going "But I want to uncheck that box" or check it and then they burn time trying to figure out how. That's why we generally hide options that don't make any sense for the settings you have.
I agree about the disabled vs. hidden options aspect being difficult (and confusing). Since the dependencies involved are quite complex, and since there are no easy solutions to laying them out with appropriate visual hierarchical cues within the limitations of AceConfig, users will become confused one way or the other.
However, which is potentially more disconcerting to a user: An option the user expects to be there and can't find at all, or an option the user expects to be there, but can't change?
My suggestion would be to disable the option, but leave it visible. In addition, when you disable the option, add an explanation to its description (shown by default in a mouseover tooltip) detailing why the option may not be available. (.. "Option Y requires Option X to be enabled/does not apply when Option X is disabled.")
This is a design principle that has worked well for me in applications with ridiculously complicated dependencies among their settings. After all, you can't tell the user that an option they expect to see doesn't apply if they can't see it! :)
Edit: A special concern about hiding options is that it can cause remaining options to reflow. This can result in the options that are actually there not being in the place users expect to find them.
However, when how you enable them isn't particularly obvious it leads to people going "But I want to uncheck that box" or check it and then they burn time trying to figure out how. That's why we generally hide options that don't make any sense for the settings you have.
I was speaking more along the lines of how the addon select screen's checkmarks work, where you can freely enable or disable dependencies while the main addon is disabled, even though that will only be relevant when the main addon is enabled again. I could envision the same sort of thing here, where options that aren't relevant can be freely checked or unchecked, but they will still be somewhat faded to note that they are not pertinent to the display unit. I know exactly what you mean when you say that just disabling the whole checkbox as a whole can greatly puzzle and confound a user. I personally don't have a problem with PB4's configuration (I think the layout and frame system is quite logical). I'm merely trying to help understand the thrust of Zidomo's concerns.
In the end, though, I think the different philosophy of Pitbull is to "blame": unit frame mods of the past made the unit the object of primary importance, and a user more familiar with that model may simply expect settings to be associated with units, not individual layouts or frames. No amount of playing with the configuration will really change that expectation; they simply have to get used to it. This isn't a bad thing, for once they do, they realize they can do a lot more with the layout-frame model than they could being handcuffed to the "one unit, one frame" mentality.
All that said, I really do think you pretty much don't understand the configuration model for that panel. You're still thinking like the structure of the configuration is as follows:
[ Current group
[ Unit Group
Various Options
]
]
When it's really:
[ Current group
[ Unit group ]
[ Various options ]
]
Unit group is really just one of the various options for the Unit group.
Regardless of your assessment of what I do or do not understand...heh...was just pointing out that that model is less than intuitive for many. Anyway, GL.
I was speaking more along the lines of how the addon select screen's checkmarks work, ...
The "irrelevant, but enabled" and the related "partially enabled" control paradigms can provide some very powerful results, but they tend to become confused with one another easily. They usually require a visual hierarchy or textual cue to pull off successfully.
Blizzard can get away with this in the AddOn List screen because they provide the extra visual cue next to the addon's name saying "Dependency disabled" in bright yellow text, AND it lists the dependencies in the tooltip for the addon's checkbox.
I just did an addon update and reinstalled Pitball w/ v4.0.0-beta5 but when I log in, I can't see any of the Pitbull frames and the default WoW UI is loaded. I can still access the Pitbull options via /pb and everything is enabled. Any ideas or suggestions?
Make sure you completely exit out of the game after updating.
Hello again. I've tried everything to get this text just how I want it. Tried to use the suggestions given to me previously, but I am just dumb when it comes this for some reason.
Here is what I want for my target's name:
Level(colored by difficulty), Elite/Rare status(+ or R, preferably), Name(colored by class), AFK/DND status with time, followed by a "..." if it is too long.
I would be very appreciative if someone could just write that up for me so I can copy/paste it into my target's name text area. Thanks so much. Sorry to be a bother.
Didn't have time earlier to respond to everything. As it seems there is more interest in discrediting suggestions to "protect the baby" than actually discussing things, will make this my last post.
The only two that change are the vehicle and the Include player options. They're both at the bottom now. They're both situated now so that they don't move and appear in the same location regardless of the presence or removal of the other.
Haven't tried the latest alphas where this has happened. If so, great.
I don't think this is atypical behavior at all. I disagree with this sentiment entirely. Options impact other options all the time. I think you'd be hard pressed not to find a major app that doesn't cause some options to disable based on others.
Right. But not necessarily among _identical_ options among different selections, which is what we are talking about here. And if its among completely different options that are not immediately visible (which is common), it increases usability to alert the user to the behind-the-scene change, whether via tooltip help or otherwise.
LOL. The problem with that is what I was referring to in this case. Have generally never found that having default settings affects perceptions of available options...when talking about software in which common expectations of what options are available are shared ;).
When you have a lot of alternative software all performing the same functions (i.e. different unit frame mods all with a certain frame set as a default), if a function common to them is missing from your software, you'll have many not realizing that they have to create what's missing. And/or for those that do, it adds to the effort of setting things up. That's the problem.
If it was typical for such mods to have certain frame sets missing, the "default effort problem" would have more relevance.
My suggestion would be to disable the option, but leave it visible. In addition, when you disable the option, add an explanation to its description (shown by default in a mouseover tooltip) detailing why the option may not be available. (.. "Option Y requires Option X to be enabled/does not apply when Option X is disabled.")
This is a design principle that has worked well for me in applications with ridiculously complicated dependencies among their settings. After all, you can't tell the user that an option they expect to see doesn't apply if they can't see it! :)
No tooltips are shown on disabled options in AceConfig. Which is part of the reason I prefer to hide them. If you look at the two options and what they do:
include player: Adds the player to the group. Only relevent to the party because the player doesn't get a party unit id. In a raid you do get a raid unit id. Very few people ask for how to hide the player from the raid (the answer is you can't without resorting to name lists which sucks) and I imagine disabling that option would encourage people to think it was possible.
swap with vehicle/owner: Swaps the frame with the owner/vehicle if the unit is in a vehicle. This applies to raid and party frames but is irrelevant for target frames, because the vehicle and it's owners target are pegged to each other.
In both of these cases I don't think very many users are really going to wonder where these options went. Every other option in the General tab and all the options in the Unit formation tab are identical no matter what unit group is set to. Filtering shows Party as a Show when in option for Party based units but not raid, since when you're only in a party there are no raid units so there is nothing for raid based frames to show. Raid based groups get a filter, which is not supported by the blizzard code for party frames.
I strongly doubt this is too terribly confusing once the issue of options moving is fixed. Which it's now been fixed.
Edit: A special concern about hiding options is that it can cause remaining options to reflow. This can result in the options that are actually there not being in the place users expect to find them.
Right, and this was a very valid argument. I've moved the include player option to the end. Since it is a double wide option it will never take the spot the swap with vehicle has and will always occupy the same slot. No options reflow regardless of which ones are available.
Didn't have time earlier to respond to everything. As it seems there is more interest in discrediting suggestions to "protect the baby" than actually discussing things, will make this my last post.
Just because I don't agree with your suggestions doesn't mean I'm just out to discredit them. I've already implmented one of them by moving the options so they don't move. I'd also said I'd consider adding a preset Raid group. But I really don't think your other suggestions are improvements.
Right. But not necessarily among _identical_ options among different selections, which is what we are talking about here. And if its among completely different options that are not immediately visible (which is common), it increases usability to alert the user to the behind-the-scene change, whether via tooltip help or otherwise.
I do think our tooltip on the Unit group dropdown could be better. Unfortunately, as I've pointed out even if I leave the options showing but disabled the tooltip would not show as tooltips are disabled on disabled controls in AceConfig. There's a lot of things that are not exactly ideal, but my hands are somewhat tied if I'm going to use AceConfig. Initially ckknight started to write a custom config system for PB4. But it was determined to be too time consuming and so we're using AceConfig. It's less than perfect but it works. It has a lot of quirks and limitations.
LOL. The problem with that is what I was referring to in this case. Have generally never found that having default settings affects perceptions of available options...when talking about software in which common expectations of what options are available are shared ;).
When you have a lot of alternative software all performing the same functions (i.e. different unit frame mods all with a certain frame set as a default), if a function common to them is missing from your software, you'll have many not realizing that they have to create what's missing. And/or for those that do, it adds to the effort of setting things up. That's the problem.
If it was typical for such mods to have certain frame sets missing, the "default effort problem" would have more relevance.
I'm well aware of the difficulties our different paradigm presents. When computers migrated from command line interfaces to GUIs there was a huge shift. You can say that the GUI is far more intuitive for a user. But that doesn't make the command line useless. It's just different. However, there are a lot of things that I think the GUI makes a hell of a lot harder to do than it is to do with a command line too. Imagine moving large groups of files named a certain way, it's much harder to do that with a GUI. Does that difficulty demand a rethinking of the paradigm? I don't think so.
I really don't think there's anything I can do short of predefining every unit group as a group in the pre-defined group list or entirely changing the design of PitBull4 that will make you happy. I'm leaning towards adding Raid.
To reiterate, I've listened. I've engaged in a conversation. Just because I've rejected some of your suggestions, maybe even rejected what you considered the most important suggestions doesn't mean I haven't considered your input.
If you want to consider that protecting the baby so be it. We'll just have to agree to disagree.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Here is how it works so far ( i have only tested it in battlegrounds aka in raids ):
I am in dalaran w8ing for the queue. i lay down my totems.. everything works
When i am solo questing again everything works ok
When i enter a bg ( or wintergrasp) some times i will try to lay down totems at the begining and it will work.. some other times it wont. The point is that either at the begining or at some other point durring the battleground/wg my totems will just stop showing up in the totem bar. I dont get an error then.. they just stop appearing. The first time it hapened.. i did /console reloadui (which is when i get the error ) and they would show up again for a little while until they got bugged again.
So to sum up..I think it has something to do witht the fact that i am in a raid.. and maybe totem bar responds badly to it..?? ( also i have party not to show when i am in a raid.. but i doubt thats important)
PS: i havent tried it in 5 man situations.. ill try and ill let you know how it went
Edit: i run some 5 man dungeons and i had no problems there so i guess this narrows it down a bit. looking forward to hearing from you!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI can tell you that this error message has nothing to do with PitBull4. It's actually a bug in the Blizzard UI. LoadAddOn doesn't work until later than it used to. The default UI tries to use it and the function doesn't load the addon but also doesn't bother to return the reason why it didn't. Which of course it then tries to use and it's empty. In particular you see this when reloading in a battleground because it tries to load the minimap.
Great.. so we know where it comes from i guess. Any chance i can do something to prevent it?( say..hide the minimap? will that help?)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNothing you can do. I don't think it has anything to do with your totem issues though. I could be wrong. I believe it's fixed in 3.2.2 but I haven't bothered to test it on the PTR.
Where I work, when design issues are identified (by myself or anyone else in the department), time is not wasted on diplomacy. Issues are identified and forwarded, as are ideas for improvement (unlike some workplaces, test ideas are held in equal weight with coder ideas). There is no "role playing" involved; continuing the view of how a design first struck the tester in further discourse is part of the process. Sorry for not spending more time to smooth out the posts more diplomatically and/or getting away from my RL work process.
A grand total of 0 of this has anything to do with "how I want to see things", "how I want it to work" or anything similar. I don't care what I think about things ;). As per above, improvement suggestions were forwarded, do with them what you will.
Sorry, I should have fleshed it out more.
When you have different "menu" selections (dropdowns as they are now, words on a bar the provide their own dropdowns, etc.), its atypical and not intuitive behavior for options for such selections to directly affect the options of other, different selections.
For a very general example, take the Windows Explorer menu bar. Select "Tools", "Disconnect Network Drive". In doing so, you don't expect "View", "Status Bar" to automatically checkmarked as well. Its the same issue when talking about identical options attached to multiple, different selections.
A few ways around this. One is to group the options that change name or function between Unit group selections, say, all together in a separate section at the bottom of the frame. So that its more clear which options are effectively "global" between Unit group selections and which are different (in name or function).
Or, with more coding work needed, what was brought up before about "separate global menu choice" among the Unit Group dropdown selections. When you choose "Global" from the menu, the only options that appear in the current option frame are those that are identical in name and/or function among all the frame Unit Group selections. Then when you select a different Unit group like "Party targets", the frame is cleared and only options (if any) specific to that unit group show in the frame.
Or, connected to the above, instead of separate Unit groups in a dropdown menu, instead have them as a column of checkboxes. Along with a "Global option" checkbox. Checkmark the "Global" one, it behaves as above; the options that are universal among the selections appear on the frame. Checkmark an actual frame unit group, the unique options (if any) for it appear in the frame instead.
Or something else that makes it more clear which Unit Group options are shared.
Or the other possibility: the thought that there is no first-apparent way to make them at all. Have generally never found that having default settings affects perceptions of available options. Other than among those who would never look for options in the first place.
Yep for sure. If that's the specific, intended audience--unit-frame users-who-don't-want-raid frames--it might save even more memory, etc., completely removing "Raid" from the unit group options and elsewhere. Put it all in the LOD "Raid" module. Or remove the frames entirely.
Or something. Having raid frame availability but to not have them active at all without a lot of setup is atypical and is not a common expectation for self-contained unit frame mods. Same thing with party targets, etc..
Yep, no question. What I want is completely irrelevant. The only reason for me making the "increased number of defaults" suggestion was to have it more in line with what other unit frames (besides oUF) do. So that new users coming to this have less to initially deal with and improve the OOB experience.
Appreciate your reply.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNope, we don't have support for that at this time.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumA lot gets lost when all we have is text instead of face to face.
I don't think this is atypical behavior at all. I disagree with this sentiment entirely. Options impact other options all the time. I think you'd be hard pressed not to find a major app that doesn't cause some options to disable based on others.
This seems like nothing more than a straw man argument. The options that change aren't arbitrary. They are very much connected to what you're changing.
The only two that change are the vehicle and the Include player options. They're both at the bottom now. They're both situated now so that they don't move and appear in the same location regardless of the presence or removal of the other.
All the options are global. There's not a single option that isn't impacted by what you set no matter what the Unit group is set to. The only sorta exception to this is the two I mentioned above. However, while they might have slightly different meanings depending upon what the Unit group is set or even not be relevant and then hidden. The underlying storage is still the same.
So I'm not sure what you're advocating that I move to convey more clearly is different from other things when they are all the same as it is.
I think this is entirely illogical. The dropdown to choose which set of units the group will be showing is not intended to be selected through to configure different things. Like I said, you're editing one object. Not a set of objects. Some of the sets of units have different options. Mostly, because Blizzard only uses some options for certain units. Not because I like that they're limited to that.
I really do honestly believe that your proposed change is more likely to cause confusion. Not less.
You're trying to use the Unit group dropdown as a configuration compression tool. It's not. It's a real choice. You get to chose one set of units for the group. I don't think your suggestions are an improvement.
This should be enlightening then:
http://www.kk.org/thetechnium/archives/2009/06/triumph_of_the.php
The raid frames share all their code with the party frames. Outside of some options that Blizzard flat out ignores (and thus I hide for those unit sets) there is no code difference at all from a Party frame and a Raid frame.
I don't really consider what you have to do a lot of setup. You go to groups, type Raid in New groups, select Raid from the Unit group drop down and for all practically purposes you're done short of positioning and formation type stuff.
That said I'll consider adding in a raid group as a predefined group with it disabled. But I don't think I need to make groups for every set of units. The design of the groups as independent objects that you can define as many as you want is a deliberate design decision. That is intended to be very different from other existing unit frames.
If people are looking for what the other unit frame addons offer as far as a preset list of what you can do that you play within the sandbox that the developer intended, then you're not likely to be happy with PitBull4. That's just not the direction we're taking PitBull4.
We're certainly trying to make it easier to configure. I think it is drastically easier to configure. That's not to say there isn't some degree of learning curve due to some of the concepts being entirely different from other unit frame addons. But I don't think the concepts are particularly difficult to understand.
All that said, I really do think you pretty much don't understand the configuration model for that panel. You're still thinking like the structure of the configuration is as follows:
[ Current group
[ Unit Group
Various Options
]
]
When it's really:
[ Current group
[ Unit group ]
[ Various options ]
]
Unit group is really just one of the various options for the Unit group.
It might be more clear that all these options are global if they were checkboxes that become gray when the option is not relevant for the unit of display, but that has little functional bearing on how the frames work now, and I can understand how showing irrelevant options might be confusing to users.
In the end, though, I think PB4's model is sound: units are data sources, nothing more, and how you want that data displayed is the job of the frame or the layout to handle. Units in and of themselves need not have display options associated with them, only insofar as to handle the differences in the data they provide.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCorrect.
I'm not a huge fan of disabled boxes that aren't relevant. I think disabling the boxes makes a lot of sense when they're just disabled because of a checkbox or something. E.G. the way things are disabled when the Enable boxes on bars, units, groups etc are disabled.
However, when how you enable them isn't particularly obvious it leads to people going "But I want to uncheck that box" or check it and then they burn time trying to figure out how. That's why we generally hide options that don't make any sense for the settings you have.
However, which is potentially more disconcerting to a user: An option the user expects to be there and can't find at all, or an option the user expects to be there, but can't change?
My suggestion would be to disable the option, but leave it visible. In addition, when you disable the option, add an explanation to its description (shown by default in a mouseover tooltip) detailing why the option may not be available. (.. "Option Y requires Option X to be enabled/does not apply when Option X is disabled.")
This is a design principle that has worked well for me in applications with ridiculously complicated dependencies among their settings. After all, you can't tell the user that an option they expect to see doesn't apply if they can't see it! :)
Edit: A special concern about hiding options is that it can cause remaining options to reflow. This can result in the options that are actually there not being in the place users expect to find them.
I was speaking more along the lines of how the addon select screen's checkmarks work, where you can freely enable or disable dependencies while the main addon is disabled, even though that will only be relevant when the main addon is enabled again. I could envision the same sort of thing here, where options that aren't relevant can be freely checked or unchecked, but they will still be somewhat faded to note that they are not pertinent to the display unit. I know exactly what you mean when you say that just disabling the whole checkbox as a whole can greatly puzzle and confound a user. I personally don't have a problem with PB4's configuration (I think the layout and frame system is quite logical). I'm merely trying to help understand the thrust of Zidomo's concerns.
In the end, though, I think the different philosophy of Pitbull is to "blame": unit frame mods of the past made the unit the object of primary importance, and a user more familiar with that model may simply expect settings to be associated with units, not individual layouts or frames. No amount of playing with the configuration will really change that expectation; they simply have to get used to it. This isn't a bad thing, for once they do, they realize they can do a lot more with the layout-frame model than they could being handcuffed to the "one unit, one frame" mentality.
Regardless of your assessment of what I do or do not understand...heh...was just pointing out that that model is less than intuitive for many. Anyway, GL.
Blizzard can get away with this in the AddOn List screen because they provide the extra visual cue next to the addon's name saying "Dependency disabled" in bright yellow text, AND it lists the dependencies in the tooltip for the addon's checkbox.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMake sure you completely exit out of the game after updating.
Here is what I want for my target's name:
Level(colored by difficulty), Elite/Rare status(+ or R, preferably), Name(colored by class), AFK/DND status with time, followed by a "..." if it is too long.
I would be very appreciative if someone could just write that up for me so I can copy/paste it into my target's name text area. Thanks so much. Sorry to be a bother.
Haven't tried the latest alphas where this has happened. If so, great.
Right. But not necessarily among _identical_ options among different selections, which is what we are talking about here. And if its among completely different options that are not immediately visible (which is common), it increases usability to alert the user to the behind-the-scene change, whether via tooltip help or otherwise.
LOL. The problem with that is what I was referring to in this case. Have generally never found that having default settings affects perceptions of available options...when talking about software in which common expectations of what options are available are shared ;).
When you have a lot of alternative software all performing the same functions (i.e. different unit frame mods all with a certain frame set as a default), if a function common to them is missing from your software, you'll have many not realizing that they have to create what's missing. And/or for those that do, it adds to the effort of setting things up. That's the problem.
If it was typical for such mods to have certain frame sets missing, the "default effort problem" would have more relevance.
Anyway, thanks, GL.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo tooltips are shown on disabled options in AceConfig. Which is part of the reason I prefer to hide them. If you look at the two options and what they do:
include player: Adds the player to the group. Only relevent to the party because the player doesn't get a party unit id. In a raid you do get a raid unit id. Very few people ask for how to hide the player from the raid (the answer is you can't without resorting to name lists which sucks) and I imagine disabling that option would encourage people to think it was possible.
swap with vehicle/owner: Swaps the frame with the owner/vehicle if the unit is in a vehicle. This applies to raid and party frames but is irrelevant for target frames, because the vehicle and it's owners target are pegged to each other.
In both of these cases I don't think very many users are really going to wonder where these options went. Every other option in the General tab and all the options in the Unit formation tab are identical no matter what unit group is set to. Filtering shows Party as a Show when in option for Party based units but not raid, since when you're only in a party there are no raid units so there is nothing for raid based frames to show. Raid based groups get a filter, which is not supported by the blizzard code for party frames.
I strongly doubt this is too terribly confusing once the issue of options moving is fixed. Which it's now been fixed.
Right, and this was a very valid argument. I've moved the include player option to the end. Since it is a double wide option it will never take the spot the swap with vehicle has and will always occupy the same slot. No options reflow regardless of which ones are available.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust because I don't agree with your suggestions doesn't mean I'm just out to discredit them. I've already implmented one of them by moving the options so they don't move. I'd also said I'd consider adding a preset Raid group. But I really don't think your other suggestions are improvements.
I do think our tooltip on the Unit group dropdown could be better. Unfortunately, as I've pointed out even if I leave the options showing but disabled the tooltip would not show as tooltips are disabled on disabled controls in AceConfig. There's a lot of things that are not exactly ideal, but my hands are somewhat tied if I'm going to use AceConfig. Initially ckknight started to write a custom config system for PB4. But it was determined to be too time consuming and so we're using AceConfig. It's less than perfect but it works. It has a lot of quirks and limitations.
I'm well aware of the difficulties our different paradigm presents. When computers migrated from command line interfaces to GUIs there was a huge shift. You can say that the GUI is far more intuitive for a user. But that doesn't make the command line useless. It's just different. However, there are a lot of things that I think the GUI makes a hell of a lot harder to do than it is to do with a command line too. Imagine moving large groups of files named a certain way, it's much harder to do that with a GUI. Does that difficulty demand a rethinking of the paradigm? I don't think so.
I really don't think there's anything I can do short of predefining every unit group as a group in the pre-defined group list or entirely changing the design of PitBull4 that will make you happy. I'm leaning towards adding Raid.
To reiterate, I've listened. I've engaged in a conversation. Just because I've rejected some of your suggestions, maybe even rejected what you considered the most important suggestions doesn't mean I haven't considered your input.
If you want to consider that protecting the baby so be it. We'll just have to agree to disagree.