...Walk us through things a user might want to do with the indicator configuration. Try to be as specific as possible. Abstract user stories aren't very useful...
All right, here is one scenario I envision for a from scratch config with minor changes. It is not fully elaborated but I could maintain and upgrade it with more details if that would be helpful.
A user logs in with Grid2 for a new class and / or spec. The default system swings into action and creates defaults from the minimal default settings. These are similar to or identical with Grid defaults for that class (+/- the defaults thread). They try it for a bit but want to make some changes: move the aggro indicator to the left side; make it larger; add the Earthliving aura which is missing from the minimal config.
Opening Grid2 config for the first time they see a page offering them a choice between minimal / medium / detailed settings with the default minimal one currently selected. They change to detailed, hoping it will have the missing Earthliving aura.
They also click on the GUI layout. It shows the contents of the current Grid2 frame with draggable indicator objects. They can see the aggro indicator in its default location at bottom left and hovering the mouse over it provides a tooltip showing its name and listing its statuses as well as hint text "Drag to move to a different location, ctrl-drag to adjust position". The mouse changes to the grabby hand so they know it is draggable. They click and start to drag it around. Below the GUI panel, basic info about the aggro indicator appears as it is now the selected indicator. It snaps to the nearest predefined location as they drag, with the indicator's location property updating as they move it around. After it snaps to the side-left location they let go.
Next they use the size slider to adjust its size. Already they can see that they want to adjust the position a bit to compensate for the increased size. This time they ctrl-drag it. As they do this the x and y offsets update as they drag it around. They settle for moving it further away from the edge than before.
Satisfied they go test their settings. While Earthliving is now present, so is a bunch of other stuff and it feels cluttered. Aggro is in the spot they prefer at the size they prefer though.
They open the Grid2 config again and go back to the main page and choose the medium settings.
The clutter is much reduced and their desired aura is still present. In addition, the aggro indicator remains in their desired location at side-left. The changes they made to it are not reset just by switching configs. If they do want to they could click the reset button to discard all changes and start from scratch with the selected medium config.
They decide that if they delete one indicator (buffs-mine), and remove the other statuses that are also on the same indicator as Earthliving (the indicator-with-bunch-of-auras indicator because we are not done with the defaults thread yet) it would be just right for them. They select buffs-mine and click its delete button. They select indicator-with-bunch-of-auras and disable its other statuses. (At this point I do not know if they will have to double click to go to the indicator and adjust its statuses, or if there will be enough room to display them on the same page. TBD).
Finally they rename indicator-with-bunch-of-auras to earthliving. This does 3 things:
1) indicator-with-bunch-of-auras is marked as deleted.
2) Config mods that modify indicator-with-bunch-of-auras will modify its default setup only.
Switching to the detailed config at this point will not bring indicator-with-bunch-of-auras or buffs-mine back without clicking the reset button for the config. They can however be resurrected by choosing it from a list of premade indicators as part of the new indicator process. This rename and its effects is identical to deleting the indicator and creating a new one called earthliving.
3) The renamed indicator is different from indicator-with-bunch-of-auras and will only change through actions taken by the user. indicator-with-bunch-of-auras on the other hand is a built in indicator and is updated when Grid2 updates its list of statuses. This will happen when Blizzard makes an aura obsolete or adds a new aura in a patch that belongs with indicator-with-bunch-of-auras. There is an explicit lock setting on such indicators which if checked prevents automatic updates.
They try it for a bit but want to make some changes: move the aggro indicator to the left side; make it larger; add the Earthliving aura which is missing from the minimal config.
I'm curious to know how many people you've physically observed using Grid's configuration. I've probably watched at least a dozen unrelated people trying to set something up, and walked 50+ people through making specific changes in-game. Every single one of them has immediately made the connection between "what I want to see" and "where I want to see it". Someone who wants to see aggro on the left side square opens the configuration, finds "left side" and checks "aggro". I don't think most (or any) of them would so easily make the connection between "what I want to see", "what group it's in", and "where I want to see that group".
Opening Grid2 config for the first time they see a page offering them a choice between minimal / medium / detailed settings with the default minimal one currently selected. They change to detailed, hoping it will have the missing Earthliving aura.
This seems awfully complicated, unnecessarily so, and certainly more code bulk than is warranted. Use one set of defaults. Don't force or even expect that someone should cycle through various configuration presets to find one that has Earthliving shown already instead of just adding Earthliving directly. Again, I don't think most people will make that connection. They'll just open the configuration and muddle around until they either figure out how to add Earthliving, or find someone who can walk them through it, or give up and install Healbot and tell all their friends how terrible Grid is.
They also click on the GUI layout. It shows the contents of the current Grid2 frame with draggable indicator objects. They can see the aggro indicator in its default location at bottom left and hovering the mouse over it provides a tooltip showing its name and listing its statuses as well as hint text "Drag to move to a different location, ctrl-drag to adjust position". The mouse changes to the grabby hand so they know it is draggable. They click and start to drag it around. Below the GUI panel, basic info about the aggro indicator appears as it is now the selected indicator. It snaps to the nearest predefined location as they drag, with the indicator's location property updating as they move it around. After it snaps to the side-left location they let go.
Again, this is not intuitive. It sounds great on paper, but wait until you watch someone try to figure out how to move Renew from its default location on a square in the top-left lcation to an icon in the center location. First, they will click the top-left square that currently shows Renew and drag it to the middle of the frame. Then, they will poke around until they figure out how to turn the square into an icon. Then, thinking they have succeeded in their goal, they'll close the config and go play... only to realize almost immediately that along with Renew, they just moved everything else that was shown on the same indicator, even though that emphatically is not want they want. Now they have to ask their group to wait while they go back into the config mode, drag the indicator back, turn it back into a square, and spend yet more time trying to figure out how to drag just Renew.
Even once they find the place to configure which statuses are shown on the selected indicator, they're back where they were in my last post -- stuck resorting to the completely illogical measure of assigning the "Renew" status to the "Ready Check" indicator. While they may eventually figure this out, the drag-and-drop configuration certainly isn't helping, and the experience will probably lead them to just live with the rest of the settings as-is rather than thrash around blindly trying to move other things around between locations that don't make any sense.
From a web development perspective, your proposal is sounding a lot like the bad old days in the early 90s when the pinnacle of web design was "mystery meat" navigation, in which users had to blindly click on unlabeled icons or abstract image maps in order to maybe get to the part of the site they wanted. People don't like feeling stupid or helpless. They don't enjoy having to just try random things hoping it will do what they want. They don't enjoy having to learn new concepts just to perform simple tasks or use things. Websites which require users to search for unlabeled image map links and scrutinize the URL in the status bar to guess where each link will take them aren't very successful. Neither are websites which require users to become familiar with cutesy metaphors or new terminology, or websites which require users to just deal with things that don't really make sense. Websites which are clearly labeled, use plain language, and are logically structured tend to have much greater success (provided of course that this nice interface is coupled with content users actually want :p).
The same concepts apply to WoW addon design, or anything else that involves regular people using something they have no idea how to create. You have to remember that the overwhelming majority of the people who will use Grid2 will not know you, will not have read anything about the addon, may never have used Grid1, and may never even have used an addon before.
Next they use the size slider to adjust its size. Already they can see that they want to adjust the position a bit to compensate for the increased size. This time they ctrl-drag it. As they do this the x and y offsets update as they drag it around. They settle for moving it further away from the edge than before.
Why on earth would offsets persist from one point to another? I shouldn't have to adjust offsets every time I move or resize something. If an indicator is anchored to TOPLEFT with offsets of 0, 0 and a size of 12, and I resize it to a size of 18, I shouldn't have to move it to get it back to 0, 0.
Satisfied they go test their settings. While Earthliving is now present, so is a bunch of other stuff and it feels cluttered. Aggro is in the spot they prefer at the size they prefer though.
They open the Grid2 config again and go back to the main page and choose the medium settings.
You do realize that the Ace profile system doesn't work this way, right? You'll have to write your own profile handler if you want changes from one profile to carry over to another profile. There are much more useful things you could be spending your time doing than writing all of that code to support a feature that is not intuitive to most people anyway. People who have used addons before know that each profile is a separate set of settings. If they change something on ProfileA, and then switch to ProfileB, the changes they made on ProfileA are not carried over. Breaking this functional paradigm will cause nothing but confusion.
The clutter is much reduced and their desired aura is still present. In addition, the aggro indicator remains in their desired location at side-left. The changes they made to it are not reset just by switching configs. If they do want to they could click the reset button to discard all changes and start from scratch with the selected medium config.
Again, most users will NOT think to cycle through configuration presets to add a buff. They'll just add the buff.
They decide that if they delete one indicator (buffs-mine), and remove the other statuses that are also on the same indicator as Earthliving (the indicator-with-bunch-of-auras indicator because we are not done with the defaults thread yet) it would be just right for them. They select buffs-mine and click its delete button. They select indicator-with-bunch-of-auras and disable its other statuses.
How do you think that the average user, or a new user, will figure out that the intended way to configure things is to delete an indicator, remove statuses from another indicator, and rename the indicator? That's not intuitive at all, and is goes against the logical "what I want to see, where I want to see it" concept.
Consider the following ways a user could achieve a goal of "add Earthliving, and make it show up in the bottom left corner". Assume for the sake of illustration that the Earthliving status already exists, but isn't assigned to any indicators.
1. Open the configuration. Go into the statuses section. Select the status labeled "Earthliving". Select "Bottom Left Square" from the list of available indicators. Done.
2. Open the configuration. Go into the indicators section. Select the indicator labeled "Bottom Left Square". Select "Earthliving" from the list of available statuses. Done.
3. Open the configuration. Go to the statuses section. Select the status labeled "Earthliving". Take a wild guess at which of the available indicators might be in the bottom left square. Spam heals on a group member until Earthliving procs. If it's not in the right place, take another guess and try again until it is in the right place. Done.
4. Open the configuration. Go to the indicators section. Click through all of the indicators to find the one that's assigned to the "bottom left" location and has the type "square". Select "Earthliving" from a list of available statuses. Done.
5. Open a drag-and-drop GUI. Click on the bottom left square. Note that it's named "Aggro". Scratch head for a minute, then decide that this doesn't matter. Drag Earthliving from a list and drop it onto the indicator. Done.
I would prefer that #1 and #2 are both possible; both are logical, and easy to understand for anyone. I can only say that #3 and #4 are just horrible; there is no other way to put that. #5 is slightly better, but essentially renders your "names by purpose" irrelevant, since users will just ignore the names, since it doesn't make sense to assign the Earthliving status to an indicator named "Aggro", but that's the easiest way to get Earthliving to show up in the bottom left corner of the frame.
Finally they rename indicator-with-bunch-of-auras to earthliving. This does 3 things:
1) indicator-with-bunch-of-auras is marked as deleted.
2) Config mods that modify indicator-with-bunch-of-auras will modify its default setup only.
Again, not intuitive, and not a very efficient way to get a specific status in a specific spot.
Switching to the detailed config at this point will not bring indicator-with-bunch-of-auras or buffs-mine back without clicking the reset button for the config. They can however be resurrected by choosing it from a list of premade indicators as part of the new indicator process. This rename and its effects is identical to deleting the indicator and creating a new one called earthliving.
Again, not intuitive. This is actually extremely confusing, as it is unlike the profile systems in use by nearly every other addon that uses profiles.
3) The renamed indicator is different from indicator-with-bunch-of-auras and will only change through actions taken by the user. indicator-with-bunch-of-auras on the other hand is a built in indicator and is updated when Grid2 updates its list of statuses. This will happen when Blizzard makes an aura obsolete or adds a new aura in a patch that belongs with indicator-with-bunch-of-auras. There is an explicit lock setting on such indicators which if checked prevents automatic updates.
Again, not intuitive. Most users will be annoyed and confused if after a patch Grid is suddenly showing them new buffs or otherwise has changed its behavior without any user intervention.
...Then think about the one most important thing that defines an indicator. What makes the square in the top-left corner different from the icon in the bottom-right corner?..
All this homework sux. There are just 3 choices imo. The type, the location, the associated statuses. All three have some claim to the MVP award.
To make a choice I will use individual binary comparisons, because thats what humans excel at. To make it concrete we use type = debuff-Poison and buff-Rejuvenation
type vs location: Location wins, no debate imo. Users know that at a particluar location I see debuff-Poison and at another buff-Rejuvenation. The fact that it is a square or an icon has no material effect except that the icon type potentially shows information the square cannot: what type of poison it is. But that just makes it a better indicator type than square at the cost of being larger.
type vs statuses: statuses win because they determine when the indicator shows up and what action I take or can take as a result. Type only determines the format, not the nature of the information conveyed. An uncontroversial result I think.
statuses vs location: This one is tougher. Lets resolve it by examining how an error would affect them. A status error would be bad because you would get unexpected / wrong results. A location error is temporarily bad. It could be mild like slightly out of position which makes no difference or in a totally different location. Its behavior is still the same in this new location and thus discoverable. Either way you can get used to the location error same way people get used to furniture that got moved.
So statuses win because they determine how the indicator behaves. Where they are located is only important as a way of mapping anonymous types like squares which do not show the texture/text etc. of their highest priority status, or to spacially map indicators in the frame to your keyboard as I do.
Phew, I did not end up with a 3-way cyclical tie!
So for me what makes the square in the top-left corner different from the icon in the bottom-right corner is the statuses connected to it. So content is king. Next most important is location. Least important is the type.
...(Personally, I think indicators should be named by type and location/anchor because that's what people see. There is a square in the top left corner, an icon in the center, another square in the top right corner, etc.)....
I think that made sense for Grid because thats how it was done in Grid.
The only valid reason I see for continuing it in Grid2 is that thats the way it was done in Grid and people are used to it. This is a valid but weak reason. It makes it easy for Grid users that will need to customize their settings to switch over to Grid2 but who also insist on only configuring their UI via properties and not the GUI. It is irrelevant for users who will make no changes to the indicator defaults provided, or use the provided GUI to edit them.
The downside is as I mentioned before. It just completely blocks particular high level config scenarios. And for what? To slightly speed up the config time of people who are using the slowest and least intuitive config method in Grid2? It just does not make sense. What was required and useful in Grid (naming by type-location) is just not important anymore. What is important now is the content of the indicator. The type and location is self evident in the GUI. Baking it into the name is possible but redundant and worse has bad side effects*. In addition, it is not as if you cannot see location and type in the config page for an indicator. These can even be added in brackets at the end of the name or as tooltips as additional information in the text only sections of the config.
*Baking in type is bad in the same way baking in location is. The important thing as we discovered above is not the type but the contents being displayed by an indicator. Switching type does not change the fact that the indicator displays aggro or debuff-Poison. Switching type and therefore name because it has to be baked in and thus screwing up the config system makes no sense imo.
Jerry has made it faster and stronger, now lets make the config better.
Why does anything have to be "baked in"? Have the name be dynamic. If you set it to the "Top Left" location, its name automatically changes to "Top Left ____". If you change it to the "Icon" type, its name automatically changes to "_______ Icon". Disable the automatic name changing if the name contains words other than locations and types, to allow for naming an indicator "My HoTs" if you want to.
Also, you've still failed to address the example I pointed out of an indicator that shows dispellable debuffs, and aggro, and low mana, and my target. You keep describing "My HoTs" and "Aggro" and "Debuff-Poison" indicators, while completely ignoring the fact that not everyone arranges things this way. >_<
Also, I disagree that icons are always better indicators than squares. Unless someone can actually claim to recognize every single curse icon in the game, and differentiate between different curses that share the same icon but have different effects and are applied from different sources, it's actually easier to recognize "purple square = curse" than peering at an icon trying to guess if it's a curse or something else.
First off Phanx, you need to realize that given a choice between doing what I think is right and what you think is right and no other inputs I am going to choose my way. That is just the way the world works. Now we clearly disagree on a few things. In my opinion these things are just a laughably trivial part of Grid2 config. The important thing is to have a config with a sensible set of defaults. Since I know for a fact that what I require for Druid/Tree is more detailed than what Maya needs that means multiple configs to easily choose from.
Since I and multiple people in this thread want a GUI config to help lay out a grid frame that will be done as well. I am sorry you think a GUI is unintuitive, or the one I described is unintuitive, or whatnot. I do not share this opinion. If you read this thread you will know that a simulator is not far behind so that you can see what is going on in your Grid2 config without having to "run around trying to proc stuff", join a raid, etc.
Who cares about some kitchen-sink indicator that shows dispellable debuffs, and aggro, and low mana, and my target? If you want it then make it. Name will be identity for indicators. For your kitchen-sink you made that fact is irrelevant. For the ones provided by Grid2, "hots", "aggro" and whatever else gets distilled from the defaults thread however this identity is important. They form a set of well know indicators. Furthermore they are the outcome of a thread dedicated to it. Not stuff I am just making up on the spot but consensus of a sort from multiple people working together in that thread. I am not ignoring that all people do not set up Grid the same way. I am facilitating the process. Furthermore I am distilling common threads from all that variety so it is easy to adopt these common threads or to delete them.
By having an identity, these indicators can be manipulated by plugins and Grid2 config itself. Now I realize you do not care about that part or think it unimportant. However I do care and it is important for what I have planned.
...Also, I disagree that icons are always better indicators than squares. Unless someone can actually claim to recognize every single curse icon in the game, and differentiate between different curses that share the same icon but have different effects and are applied from different sources, it's actually easier to recognize "purple square = curse" than peering at an icon trying to guess if it's a curse or something else.
You just like to argue don't you? Ok I will bite and analyze just your last paragraph. J'accuse! Straw-Man.
What I actually wrote was "But that just makes it a better indicator type than square at the cost of being larger."
What can we deduce from this statement?
1) There is a trade off of size.
2) This trade off (cost) implies that sometimes a square is better.
You state "I disagree that icons are always better". Well I never said that. You are making up a silly argument and accusing me of saying it. This enables you to attack the silly argument instead of dealing with what I said. In other words, you are committing the logical fallacy of straw man
"Unless someone can actually claim to recognize every single curse icon in the game, and differentiate between different curses that share the same icon but have different effects and are applied from different sources..."
The gist of what you are trying to convey is that it is just impossible to use an icon effectively without idiot-savant like memory. Now I am not attempting to commit a fallacy with that statement, just trying to be amusing. At any rate here is the counter example which negates it: Each week I go into Naxx on my Druid, and sure as god made little green apples we do the spider wing and ... oh good grief, there is poison flying everywhere and a curse of super sucky healing intravenously injected via scary long, yet accurate, fangs. Now I am crazy and as I have described elsewhere I have 1 icon for poisons and one icon for curses instead of just 1 indicator for both as is standard in Grid. This is super lucky though because in this case I need to remove the curse before the tank dies from the curse-reduced healing losing out to the massive damage it is taking. Now I have no crazy memory as described, I have just learned over time what the green goo and the spun web icons mean in this context. So there it is, counterexample and gonna have to go with red-herring.
You also state "it's actually easier to recognize "purple square = curse" than peering at an icon trying to guess if it's a curse or something else". All right, but the icon has a colored border that matches its debuff type, so purple or whatnot, right? Tough call, should I call this straw-man or just go with the more generic red-herring? Or shall we just let it burn along with the straw man in a sight not seen since the last Burning Man? Either way it is a premise in your straw-man argument that is false and thus lends no weight.
Oh man, lucky for me that I took Philosophy 101: "Kung Fu for the Mind". Sadly the corollary is that if I am patient and teach you how to argue properly then by the same infallible logic whereby love is a fallacy, I will not be able to date you in the future unless I have a raccoon coat. I just don't know what to do.
I think the moral of the story is the old saw "you can't please all of the people all of the time". I will just have to accept that it is unlikely that I will be able to convince you of the merits of my approach. Clearly I lack the communication skill required. This is acceptable to me. It is just how life works.
Meanwhile I am done writing long essays. And this time I mean it! Time to write more code and make progress.
Since I know for a fact that what I require for Druid/Tree is more detailed than what Maya needs that means multiple configs to easily choose from.
No, it means a configuration UI that anyone can use to customize the addon how they want -- not multiple configurations for people to choose from. For any given configuration, you will find very few people who don't want to change anything. Why waste time, add code bulk, and add more complexity to an already complex addon for a feature that's not going to save most people much time?
I am sorry you think a GUI is unintuitive, or the one I described is unintuitive, or whatnot. I do not share this opinion. If you read this thread you will know that a simulator is not far behind so that you can see what is going on in your Grid2 config without having to "run around trying to proc stuff", join a raid, etc.
As much as you like to accuse me of making "straw man" arguments and taking your remarks out of context, you sure do like putting words in my mouth. Nowhere did I say "a GUI is unintuitive". I said the GUI you described in which indicators would be dragged and dropped, and resizing would require readjusting offsets, etc. was unintuitive. I gave specific reasons based in real-world usability terms why what you described was unintuitive. If you don't share my specific opinions, fine, but you clearly are not interested in working toward any compromise or in considering the usability issues that are very real for "normal" users of addons.
Who cares about some kitchen-sink indicator that shows dispellable debuffs, and aggro, and low mana, and my target? If you want it then make it. Name will be identity for indicators. For your kitchen-sink you made that fact is irrelevant.
And this is exactly why I do not think you should be in charge of this project. You quite obviously feel that your viewpoint is the only one that matters. You have no sense of objectivity or perspective. You say "who cares" when quite obviously someone does care. You keep hammering away at your own personal vision while ignoring and/or deriding anything anyone says that doesn't fit in with that vision.
By having an identity, these indicators can be manipulated by plugins and Grid2 config itself. Now I realize you do not care about that part or think it unimportant. However I do care and it is important for what I have planned.
I do care. I want a configuration UI that is 100% usable for everyone without plugins, without automated manipulation, and without having to learn a whole new set of concepts and terms.
What I actually wrote was "But that just makes it a better indicator type than square at the cost of being larger."
Which anyone who wasn't captain of the debate team would read as meaning that you think icons are better indicators than squares, with the drawback of being bigger. A drawback doesn't logically mean that something is sometimes not better. You don't hear someone say "I think a New York steak tastes better than a McDonald's cheeseburger, but it's more expensive" and take that to mean that there are any circumstances under which they think the cheeseburger tastes better.
The gist of what you are trying to convey is that it is just impossible to use an icon effectively without idiot-savant like memory.
Not at all. I was giving a specific example of a status for which an icon isn't a better indicator. For more unique statuses, such as Kel'Thuzad's mind control debuff, I do think an icon is better.
So there it is, counterexample and gonna have to go with red-herring. ... Tough call, should I call this straw-man or just go with the more generic red-herring? Or shall we just let it burn along with the straw man in a sight not seen since the last Burning Man?
This is an Internet forum. It's not a debate team. I have better things to do than spend hours researching formal debate terms and editing everything I post five times over to be sure there aren't some obscure logical fallacies in there anywhere.
All in all, this discussion has convinced me to spend time working on my Grid-like layout for oUF, since I am interested in getting rid of the Ace2 dinosaurs in my addon collection, but I am not interested in using the addon you are writing.
Oooh, I wish I had more time to write up a proper response but I'm heading out of town for the weekend.
Azethoth, let me know if I'm understanding you correctly. Doing that 'homework' helped me figure out where you're coming from.
Phanx, I think I already understand your point of view so you get a short summary.
Azethoth wants the default indicators to have task-oriented names so that status modules can provide task-oriented default settings. This would also allow users to change the location and type of a default indicator while still picking up defaults from other modules. Renaming or deleting a default indicator would prevent those defaults from affecting it.
Phanx is concerned that task-oriented names for the default indicators will be non-intuitive and actually conflict with how she has Grid currently setup.
I'm intrigued by the task-oriented defaults but also concerned that having a one-to-one mapping between tasks and indicators (by default) is going to be awkward.
Consider the case of the 'center icon' in Grid. By default it has generic debuff types and ready check statuses assigned to it. If you call it 'debuff types' then ready check doesn't really fit. What about having status categories for each task 'generic debuff', 'specific debuff', 'my hots', 'other hots', 'aggro', 'health' (including dead/ghost), etc. and only let users assign those categories to indicators in the simple config mode. The advanced config would let people assign individual statuses.
...Azethoth wants the default indicators to have task-oriented names so that status modules can provide task-oriented default settings. This would also allow users to change the location and type of a default indicator while still picking up defaults from other modules. Renaming or deleting a default indicator would prevent those defaults from affecting it...
...I'm intrigued by the task-oriented defaults but also concerned that having a one-to-one mapping between tasks and indicators (by default) is going to be awkward.
Consider the case of the 'center icon' in Grid... What about having status categories for each task 'generic debuff', 'specific debuff', 'my hots', 'other hots', 'aggro', 'health' (including dead/ghost), etc..
.
I agree that a one-to-one mapping between tasks and indicators in all cases is unlikely. Right now I am hoping it can be made to work and be good enough for the cases we care about as identified in the defaults thread.
Creating status categories is a good idea and probably where this is all headed anyway. Formally creating categories would allow a status to have multiple categories and still benefit from them being updateable and modifiable by the config. I like the concept in AutoBar and am absolutely willing to do the extra work required to implement it here.
It would mean that the category identity is no longer baked into the indicator name, and names can go back to being what they were before or auto-generated as suggested, including by type/location etc.
But not infallible like the pope so this does not help us decide.
Yes, this got a quote from me. You say Phanx is not infallible, no one is. No ones views are better than anyone elses (unless your name is some genocidal dude who shall not be named or some serial killer psychopath, the views of those suck.), we are human and we have the right to voice our opinions.
The only valid reason I see for continuing it in Grid2 is that thats the way it was done in Grid and people are used to it. This is a valid but weak reason. It makes it easy for Grid users that will need to customize their settings to switch over to Grid2 but who also insist on only configuring their UI via properties and not the GUI. It is irrelevant for users who will make no changes to the indicator defaults provided, or use the provided GUI to edit them.
So people who use the GUI are important to be heard, others are not? (That's how this does read imho.)
The downside is as I mentioned before. It just completely blocks particular high level config scenarios. And for what? To slightly speed up the config time of people who are using the slowest and least intuitive config method in Grid2? It just does not make sense. What was required and useful in Grid (naming by type-location) is just not important anymore. What is important now is the content of the indicator.
While to you, and others, this may not be important, to others it is. Phanx and myself being two of them. I don't see the intuitiveness in relocating "aggro" to topleft, and having "topleft" be shown on some other location. This is where confusion sets in.
Let the locations be the name, where we can check stati to be shown there. I honestly feel this will be less confusing for quite a few people and can increase productivity.
Jerry has made it faster and stronger, now lets make the config better.
Agreed.
Also, you noted you wished to include a GUI setup option, with drag 'n drop etc. Please please make that a seperate part, not included in the Grid2OPtions, you could call it Grid2GUIOptions.
Azethoth wants the default indicators to have task-oriented names so that status modules can provide task-oriented default settings. This would also allow users to change the location and type of a default indicator while still picking up defaults from other modules. Renaming or deleting a default indicator would prevent those defaults from affecting it.
While I completely consider Azethoth's views as valid, it would be nice if there would be some form of compromise possible, because sadly for some of us, his views of how things should be done, don't concur with ours, therefore one of us will be on the totally losing end. Wouldn't it be better if we do try to make a compromise.
Also, I don't feel it is needed to have 3 levels of advancement in the config. Simple and Advanced - ok, that is doable, more than that, isn't really needed.
Eg. Simple config utilizes that GUI setup with mainly preconfigured settings, advanced drops you fully into the complexity of a setup, with the ability to start from the basics (only the base indicator/locations and stati are setup already, everything else has to be done manually.)
Phanx is concerned that task-oriented names for the default indicators will be non-intuitive and actually conflict with how she has Grid currently setup.
I'm intrigued by the task-oriented defaults but also concerned that having a one-to-one mapping between tasks and indicators (by default) is going to be awkward.
That is mainly what me and Phanx are worried about. The awkwardness of having a location named after a status (thus being taskbased) while that task isn't even assigned to that particular location, which is how it is now.
Consider the case of the 'center icon' in Grid. By default it has generic debuff types and ready check statuses assigned to it. If you call it 'debuff types' then ready check doesn't really fit. What about having status categories for each task 'generic debuff', 'specific debuff', 'my hots', 'other hots', 'aggro', 'health' (including dead/ghost), etc. and only let users assign those categories to indicators in the simple config mode. The advanced config would let people assign individual statuses.
This, I think, is a good idea and I can find myself in it.
Now, I will try my best to keep up with all this, I am starting a new job for which I will be away from home 14/15hrs a day (8hrs to work, the rest is train+bus), so I doubt I'll do much other then that during the week. But that said, if there's need to try new things or anything, drop me a pm, I'll do my best.
Also, can we try and get the texture/hp/heals thing solved? It is rather annoying and at this point - it does make Grid2 unusable for me at times.
The latest alpha:
--Hooks up Blink Threshold for buff-statuses.
--Fixes lowmana which was broken
--Adds threshold config for lowmana
--Options for the alpha indicator
--Options for the border indicator
The purpose of it is to figure out how to do shared or universal settings across multiple characters and / or specs. If you have no interest in that then the thread is not for you, and neither will the results of the thread impact your current usage of the config and you can safely ignore it.
...So people who use the GUI are important to be heard, others are not? (That's how this does read imho.)...
Sort of. I intend to build a better config in Grid2 than in Grid. The goal is to be better, and not just different for the sake of being different.
This specifically means that I want to change things that I found clumsy in Grid and that I know to be clumsy because I have helped many other people set up Grid, or seen posts about them in Grid and Grid2 threads. So for instance making thousands of users set things up from scratch is clumsy. It is better to get some idea of what they end up with and offer that as one or more built in options.
It also means that usage patterns can change. Grid had a particular way that you set up your config. Grid2 will still have the same methods or equivalent methods for setup as Grid did, but may also have faster or better ways as well. If the new expected pattern is that 95% of people use the faster or better ways and only 5% use the old way then in my opinion it is acceptable to give more weight to the needs of the 95% than the 5% when there is a conflict.
"The needs of the many outweigh the needs of the few or the one" - Spock, Star Trek: The Wrath of Khan
So back to the issue of naming indicators. It sounds like assigning multiple Categories of statuses to a single indicator is acceptable. This makes it so indicator names do not have to be specific in order to track their associated categories. This removes my previously unavoidable reason for changing the naming convention.
I like Phanx' idea of automatic naming. This can even be configurable so the indicator name is constructed from one or more of location, type, and its categories with some scheme to ensure uniqueness. It also has the big advantage of avoiding the need to actually name indicators and type that name in. In addition, by allowing the included categories to be exposed, it solves my need to have indicators be identified by their purpose.
Therefore my current thinking is to do automatic naming for indicators. Unless a better idea comes along of course.
Just keep in mind while trying to be "better" that users are accustomed to certain paradigms in user interface and configuration for WoW addons. Deviate too far from that, and no matter how great your UI is, users will hate it because it's unfamiliar and they have to spend time learning new concepts in order to use it effectively.
Instead of having categories that group certain statuses together (and introduce yet another entity in the configuration to cope with), you might consider implementing that as kind of "meta-status", a status that collects information from several statuses. To the statuses it collects its information from, it would look like an indicator, but to the user it would show up as status.
An basic example would be a meta-status that can use the state of other logical statuses in boolean expressions. For example, you have the status buff-renew and the status buff-regrowth. Then you could create a meta-status "hots" that is active, if one of the former two is active (logical or). This would also make the plugin Grid2StatusAuraGroup you are planning obsolete.
Instead of having categories that group certain statuses together ... consider implementing that as kind of "meta-status", a status that collects information from several statuses...
This sounds totally kool, especially if you are a comp sci or math or physics major. What could be neater than complex pipelines of statuses and boolean operators on them? It would surely make a delightful class project in a 2nd year comp sci course! In Grid though it has already been done, competed with other ideas, found unfit, then recently became extinct just as Darwin would have predicted.
That was one half of it. The other half was that it had bad consequences in the core in terms of knowing what is hooked up or not. Pastamancer could comment on that more if the sad fate of GridStatusControlPipes is not convincing enough.
Ooh, breaking news, a guid grid specimen of GridStatusControlPipes was made. I guess Julith decided not to abandon it after all. Well you can go play with that and see if you like the concept in reality.
If you reached that conclusion then you either did not read the entire post or I was not clear.
You did say that people like myself shouldn't be heard ;)
Basically all I am trying to convey is :
- Keep the config simple, the naming dynamic (as per other topics).
- Use defaults on which people can build for more complex set-ups.
- And please rename "aggro" back to top-left :P It makes me personally (and I do know of a few others) assign things to "aggro" while we "relocate" another prenamed indicator to that very position. It's confusing.
You did say that people like myself shouldn't be heard ;)...
Bad Moonwitch! Mr. Spock would so totally disaprove! On the other hand he comes from a nerd-race that only gets laid once every 7 years or something so ignoring his views may be the right thing to do sometimes.
while talking about the Grid2 config i my thoughts where thus
instead of having a massive tree with indicators and locations how feasable would it be to show a blown up single grid in the options and then have 3 options add text and add indicator add border
you click add text and a new text(indicator) would show up on the middle of the cell you can then move that to where ever you want within the cell and you can click it to get to the options of what to display in the text indicator.
same would go for the indicator(little squares) you move it to where ever and then click it to tell it what it does or to remove it
border wouldn't have the movement option but would simply be the border.
some sort of sane default should be given on first install but also the option to wipe the grid and start from scratch (and of course the option to go back to defaults)
this way you could have people with little x-mass trees on their screen lighting up and blinking all over the place or have the minimalist with his one indicator that does everything he needs
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
All right, here is one scenario I envision for a from scratch config with minor changes. It is not fully elaborated but I could maintain and upgrade it with more details if that would be helpful.
A user logs in with Grid2 for a new class and / or spec. The default system swings into action and creates defaults from the minimal default settings. These are similar to or identical with Grid defaults for that class (+/- the defaults thread). They try it for a bit but want to make some changes: move the aggro indicator to the left side; make it larger; add the Earthliving aura which is missing from the minimal config.
Opening Grid2 config for the first time they see a page offering them a choice between minimal / medium / detailed settings with the default minimal one currently selected. They change to detailed, hoping it will have the missing Earthliving aura.
They also click on the GUI layout. It shows the contents of the current Grid2 frame with draggable indicator objects. They can see the aggro indicator in its default location at bottom left and hovering the mouse over it provides a tooltip showing its name and listing its statuses as well as hint text "Drag to move to a different location, ctrl-drag to adjust position". The mouse changes to the grabby hand so they know it is draggable. They click and start to drag it around. Below the GUI panel, basic info about the aggro indicator appears as it is now the selected indicator. It snaps to the nearest predefined location as they drag, with the indicator's location property updating as they move it around. After it snaps to the side-left location they let go.
Next they use the size slider to adjust its size. Already they can see that they want to adjust the position a bit to compensate for the increased size. This time they ctrl-drag it. As they do this the x and y offsets update as they drag it around. They settle for moving it further away from the edge than before.
Satisfied they go test their settings. While Earthliving is now present, so is a bunch of other stuff and it feels cluttered. Aggro is in the spot they prefer at the size they prefer though.
They open the Grid2 config again and go back to the main page and choose the medium settings.
The clutter is much reduced and their desired aura is still present. In addition, the aggro indicator remains in their desired location at side-left. The changes they made to it are not reset just by switching configs. If they do want to they could click the reset button to discard all changes and start from scratch with the selected medium config.
They decide that if they delete one indicator (buffs-mine), and remove the other statuses that are also on the same indicator as Earthliving (the indicator-with-bunch-of-auras indicator because we are not done with the defaults thread yet) it would be just right for them. They select buffs-mine and click its delete button. They select indicator-with-bunch-of-auras and disable its other statuses. (At this point I do not know if they will have to double click to go to the indicator and adjust its statuses, or if there will be enough room to display them on the same page. TBD).
Finally they rename indicator-with-bunch-of-auras to earthliving. This does 3 things:
1) indicator-with-bunch-of-auras is marked as deleted.
2) Config mods that modify indicator-with-bunch-of-auras will modify its default setup only.
Switching to the detailed config at this point will not bring indicator-with-bunch-of-auras or buffs-mine back without clicking the reset button for the config. They can however be resurrected by choosing it from a list of premade indicators as part of the new indicator process. This rename and its effects is identical to deleting the indicator and creating a new one called earthliving.
3) The renamed indicator is different from indicator-with-bunch-of-auras and will only change through actions taken by the user. indicator-with-bunch-of-auras on the other hand is a built in indicator and is updated when Grid2 updates its list of statuses. This will happen when Blizzard makes an aura obsolete or adds a new aura in a patch that belongs with indicator-with-bunch-of-auras. There is an explicit lock setting on such indicators which if checked prevents automatic updates.
I'm curious to know how many people you've physically observed using Grid's configuration. I've probably watched at least a dozen unrelated people trying to set something up, and walked 50+ people through making specific changes in-game. Every single one of them has immediately made the connection between "what I want to see" and "where I want to see it". Someone who wants to see aggro on the left side square opens the configuration, finds "left side" and checks "aggro". I don't think most (or any) of them would so easily make the connection between "what I want to see", "what group it's in", and "where I want to see that group".
This seems awfully complicated, unnecessarily so, and certainly more code bulk than is warranted. Use one set of defaults. Don't force or even expect that someone should cycle through various configuration presets to find one that has Earthliving shown already instead of just adding Earthliving directly. Again, I don't think most people will make that connection. They'll just open the configuration and muddle around until they either figure out how to add Earthliving, or find someone who can walk them through it, or give up and install Healbot and tell all their friends how terrible Grid is.
Again, this is not intuitive. It sounds great on paper, but wait until you watch someone try to figure out how to move Renew from its default location on a square in the top-left lcation to an icon in the center location. First, they will click the top-left square that currently shows Renew and drag it to the middle of the frame. Then, they will poke around until they figure out how to turn the square into an icon. Then, thinking they have succeeded in their goal, they'll close the config and go play... only to realize almost immediately that along with Renew, they just moved everything else that was shown on the same indicator, even though that emphatically is not want they want. Now they have to ask their group to wait while they go back into the config mode, drag the indicator back, turn it back into a square, and spend yet more time trying to figure out how to drag just Renew.
Even once they find the place to configure which statuses are shown on the selected indicator, they're back where they were in my last post -- stuck resorting to the completely illogical measure of assigning the "Renew" status to the "Ready Check" indicator. While they may eventually figure this out, the drag-and-drop configuration certainly isn't helping, and the experience will probably lead them to just live with the rest of the settings as-is rather than thrash around blindly trying to move other things around between locations that don't make any sense.
From a web development perspective, your proposal is sounding a lot like the bad old days in the early 90s when the pinnacle of web design was "mystery meat" navigation, in which users had to blindly click on unlabeled icons or abstract image maps in order to maybe get to the part of the site they wanted. People don't like feeling stupid or helpless. They don't enjoy having to just try random things hoping it will do what they want. They don't enjoy having to learn new concepts just to perform simple tasks or use things. Websites which require users to search for unlabeled image map links and scrutinize the URL in the status bar to guess where each link will take them aren't very successful. Neither are websites which require users to become familiar with cutesy metaphors or new terminology, or websites which require users to just deal with things that don't really make sense. Websites which are clearly labeled, use plain language, and are logically structured tend to have much greater success (provided of course that this nice interface is coupled with content users actually want :p).
The same concepts apply to WoW addon design, or anything else that involves regular people using something they have no idea how to create. You have to remember that the overwhelming majority of the people who will use Grid2 will not know you, will not have read anything about the addon, may never have used Grid1, and may never even have used an addon before.
Why on earth would offsets persist from one point to another? I shouldn't have to adjust offsets every time I move or resize something. If an indicator is anchored to TOPLEFT with offsets of 0, 0 and a size of 12, and I resize it to a size of 18, I shouldn't have to move it to get it back to 0, 0.
You do realize that the Ace profile system doesn't work this way, right? You'll have to write your own profile handler if you want changes from one profile to carry over to another profile. There are much more useful things you could be spending your time doing than writing all of that code to support a feature that is not intuitive to most people anyway. People who have used addons before know that each profile is a separate set of settings. If they change something on ProfileA, and then switch to ProfileB, the changes they made on ProfileA are not carried over. Breaking this functional paradigm will cause nothing but confusion.
Again, most users will NOT think to cycle through configuration presets to add a buff. They'll just add the buff.
How do you think that the average user, or a new user, will figure out that the intended way to configure things is to delete an indicator, remove statuses from another indicator, and rename the indicator? That's not intuitive at all, and is goes against the logical "what I want to see, where I want to see it" concept.
Consider the following ways a user could achieve a goal of "add Earthliving, and make it show up in the bottom left corner". Assume for the sake of illustration that the Earthliving status already exists, but isn't assigned to any indicators.
1. Open the configuration. Go into the statuses section. Select the status labeled "Earthliving". Select "Bottom Left Square" from the list of available indicators. Done.
2. Open the configuration. Go into the indicators section. Select the indicator labeled "Bottom Left Square". Select "Earthliving" from the list of available statuses. Done.
3. Open the configuration. Go to the statuses section. Select the status labeled "Earthliving". Take a wild guess at which of the available indicators might be in the bottom left square. Spam heals on a group member until Earthliving procs. If it's not in the right place, take another guess and try again until it is in the right place. Done.
4. Open the configuration. Go to the indicators section. Click through all of the indicators to find the one that's assigned to the "bottom left" location and has the type "square". Select "Earthliving" from a list of available statuses. Done.
5. Open a drag-and-drop GUI. Click on the bottom left square. Note that it's named "Aggro". Scratch head for a minute, then decide that this doesn't matter. Drag Earthliving from a list and drop it onto the indicator. Done.
I would prefer that #1 and #2 are both possible; both are logical, and easy to understand for anyone. I can only say that #3 and #4 are just horrible; there is no other way to put that. #5 is slightly better, but essentially renders your "names by purpose" irrelevant, since users will just ignore the names, since it doesn't make sense to assign the Earthliving status to an indicator named "Aggro", but that's the easiest way to get Earthliving to show up in the bottom left corner of the frame.
Again, not intuitive, and not a very efficient way to get a specific status in a specific spot.
Again, not intuitive. This is actually extremely confusing, as it is unlike the profile systems in use by nearly every other addon that uses profiles.
Again, not intuitive. Most users will be annoyed and confused if after a patch Grid is suddenly showing them new buffs or otherwise has changed its behavior without any user intervention.
All this homework sux. There are just 3 choices imo. The type, the location, the associated statuses. All three have some claim to the MVP award.
To make a choice I will use individual binary comparisons, because thats what humans excel at. To make it concrete we use type = debuff-Poison and buff-Rejuvenation
type vs location: Location wins, no debate imo. Users know that at a particluar location I see debuff-Poison and at another buff-Rejuvenation. The fact that it is a square or an icon has no material effect except that the icon type potentially shows information the square cannot: what type of poison it is. But that just makes it a better indicator type than square at the cost of being larger.
type vs statuses: statuses win because they determine when the indicator shows up and what action I take or can take as a result. Type only determines the format, not the nature of the information conveyed. An uncontroversial result I think.
statuses vs location: This one is tougher. Lets resolve it by examining how an error would affect them. A status error would be bad because you would get unexpected / wrong results. A location error is temporarily bad. It could be mild like slightly out of position which makes no difference or in a totally different location. Its behavior is still the same in this new location and thus discoverable. Either way you can get used to the location error same way people get used to furniture that got moved.
So statuses win because they determine how the indicator behaves. Where they are located is only important as a way of mapping anonymous types like squares which do not show the texture/text etc. of their highest priority status, or to spacially map indicators in the frame to your keyboard as I do.
Phew, I did not end up with a 3-way cyclical tie!
So for me what makes the square in the top-left corner different from the icon in the bottom-right corner is the statuses connected to it. So content is king. Next most important is location. Least important is the type.
I think they work. Wait, stories plural! Doh!
But not infallible like the pope so this does not help us decide.
I think that made sense for Grid because thats how it was done in Grid.
The only valid reason I see for continuing it in Grid2 is that thats the way it was done in Grid and people are used to it. This is a valid but weak reason. It makes it easy for Grid users that will need to customize their settings to switch over to Grid2 but who also insist on only configuring their UI via properties and not the GUI. It is irrelevant for users who will make no changes to the indicator defaults provided, or use the provided GUI to edit them.
The downside is as I mentioned before. It just completely blocks particular high level config scenarios. And for what? To slightly speed up the config time of people who are using the slowest and least intuitive config method in Grid2? It just does not make sense. What was required and useful in Grid (naming by type-location) is just not important anymore. What is important now is the content of the indicator. The type and location is self evident in the GUI. Baking it into the name is possible but redundant and worse has bad side effects*. In addition, it is not as if you cannot see location and type in the config page for an indicator. These can even be added in brackets at the end of the name or as tooltips as additional information in the text only sections of the config.
*Baking in type is bad in the same way baking in location is. The important thing as we discovered above is not the type but the contents being displayed by an indicator. Switching type does not change the fact that the indicator displays aggro or debuff-Poison. Switching type and therefore name because it has to be baked in and thus screwing up the config system makes no sense imo.
Jerry has made it faster and stronger, now lets make the config better.
Also, you've still failed to address the example I pointed out of an indicator that shows dispellable debuffs, and aggro, and low mana, and my target. You keep describing "My HoTs" and "Aggro" and "Debuff-Poison" indicators, while completely ignoring the fact that not everyone arranges things this way. >_<
Also, I disagree that icons are always better indicators than squares. Unless someone can actually claim to recognize every single curse icon in the game, and differentiate between different curses that share the same icon but have different effects and are applied from different sources, it's actually easier to recognize "purple square = curse" than peering at an icon trying to guess if it's a curse or something else.
Since I and multiple people in this thread want a GUI config to help lay out a grid frame that will be done as well. I am sorry you think a GUI is unintuitive, or the one I described is unintuitive, or whatnot. I do not share this opinion. If you read this thread you will know that a simulator is not far behind so that you can see what is going on in your Grid2 config without having to "run around trying to proc stuff", join a raid, etc.
Who cares about some kitchen-sink indicator that shows dispellable debuffs, and aggro, and low mana, and my target? If you want it then make it. Name will be identity for indicators. For your kitchen-sink you made that fact is irrelevant. For the ones provided by Grid2, "hots", "aggro" and whatever else gets distilled from the defaults thread however this identity is important. They form a set of well know indicators. Furthermore they are the outcome of a thread dedicated to it. Not stuff I am just making up on the spot but consensus of a sort from multiple people working together in that thread. I am not ignoring that all people do not set up Grid the same way. I am facilitating the process. Furthermore I am distilling common threads from all that variety so it is easy to adopt these common threads or to delete them.
By having an identity, these indicators can be manipulated by plugins and Grid2 config itself. Now I realize you do not care about that part or think it unimportant. However I do care and it is important for what I have planned.
You just like to argue don't you? Ok I will bite and analyze just your last paragraph. J'accuse! Straw-Man.
What I actually wrote was "But that just makes it a better indicator type than square at the cost of being larger."
What can we deduce from this statement?
1) There is a trade off of size.
2) This trade off (cost) implies that sometimes a square is better.
You state "I disagree that icons are always better". Well I never said that. You are making up a silly argument and accusing me of saying it. This enables you to attack the silly argument instead of dealing with what I said. In other words, you are committing the logical fallacy of straw man
"Unless someone can actually claim to recognize every single curse icon in the game, and differentiate between different curses that share the same icon but have different effects and are applied from different sources..."
The gist of what you are trying to convey is that it is just impossible to use an icon effectively without idiot-savant like memory. Now I am not attempting to commit a fallacy with that statement, just trying to be amusing. At any rate here is the counter example which negates it: Each week I go into Naxx on my Druid, and sure as god made little green apples we do the spider wing and ... oh good grief, there is poison flying everywhere and a curse of super sucky healing intravenously injected via scary long, yet accurate, fangs. Now I am crazy and as I have described elsewhere I have 1 icon for poisons and one icon for curses instead of just 1 indicator for both as is standard in Grid. This is super lucky though because in this case I need to remove the curse before the tank dies from the curse-reduced healing losing out to the massive damage it is taking. Now I have no crazy memory as described, I have just learned over time what the green goo and the spun web icons mean in this context. So there it is, counterexample and gonna have to go with red-herring.
You also state "it's actually easier to recognize "purple square = curse" than peering at an icon trying to guess if it's a curse or something else". All right, but the icon has a colored border that matches its debuff type, so purple or whatnot, right? Tough call, should I call this straw-man or just go with the more generic red-herring? Or shall we just let it burn along with the straw man in a sight not seen since the last Burning Man? Either way it is a premise in your straw-man argument that is false and thus lends no weight.
Oh man, lucky for me that I took Philosophy 101: "Kung Fu for the Mind". Sadly the corollary is that if I am patient and teach you how to argue properly then by the same infallible logic whereby love is a fallacy, I will not be able to date you in the future unless I have a raccoon coat. I just don't know what to do.
I think the moral of the story is the old saw "you can't please all of the people all of the time". I will just have to accept that it is unlikely that I will be able to convince you of the merits of my approach. Clearly I lack the communication skill required. This is acceptable to me. It is just how life works.
Meanwhile I am done writing long essays. And this time I mean it! Time to write more code and make progress.
No, it means a configuration UI that anyone can use to customize the addon how they want -- not multiple configurations for people to choose from. For any given configuration, you will find very few people who don't want to change anything. Why waste time, add code bulk, and add more complexity to an already complex addon for a feature that's not going to save most people much time?
As much as you like to accuse me of making "straw man" arguments and taking your remarks out of context, you sure do like putting words in my mouth. Nowhere did I say "a GUI is unintuitive". I said the GUI you described in which indicators would be dragged and dropped, and resizing would require readjusting offsets, etc. was unintuitive. I gave specific reasons based in real-world usability terms why what you described was unintuitive. If you don't share my specific opinions, fine, but you clearly are not interested in working toward any compromise or in considering the usability issues that are very real for "normal" users of addons.
And this is exactly why I do not think you should be in charge of this project. You quite obviously feel that your viewpoint is the only one that matters. You have no sense of objectivity or perspective. You say "who cares" when quite obviously someone does care. You keep hammering away at your own personal vision while ignoring and/or deriding anything anyone says that doesn't fit in with that vision.
I do care. I want a configuration UI that is 100% usable for everyone without plugins, without automated manipulation, and without having to learn a whole new set of concepts and terms.
Which anyone who wasn't captain of the debate team would read as meaning that you think icons are better indicators than squares, with the drawback of being bigger. A drawback doesn't logically mean that something is sometimes not better. You don't hear someone say "I think a New York steak tastes better than a McDonald's cheeseburger, but it's more expensive" and take that to mean that there are any circumstances under which they think the cheeseburger tastes better.
Not at all. I was giving a specific example of a status for which an icon isn't a better indicator. For more unique statuses, such as Kel'Thuzad's mind control debuff, I do think an icon is better.
This is an Internet forum. It's not a debate team. I have better things to do than spend hours researching formal debate terms and editing everything I post five times over to be sure there aren't some obscure logical fallacies in there anywhere.
Now who's breaking out the ad-hominem remarks? :p
All in all, this discussion has convinced me to spend time working on my Grid-like layout for oUF, since I am interested in getting rid of the Ace2 dinosaurs in my addon collection, but I am not interested in using the addon you are writing.
Azethoth, let me know if I'm understanding you correctly. Doing that 'homework' helped me figure out where you're coming from.
Phanx, I think I already understand your point of view so you get a short summary.
Azethoth wants the default indicators to have task-oriented names so that status modules can provide task-oriented default settings. This would also allow users to change the location and type of a default indicator while still picking up defaults from other modules. Renaming or deleting a default indicator would prevent those defaults from affecting it.
Phanx is concerned that task-oriented names for the default indicators will be non-intuitive and actually conflict with how she has Grid currently setup.
I'm intrigued by the task-oriented defaults but also concerned that having a one-to-one mapping between tasks and indicators (by default) is going to be awkward.
Consider the case of the 'center icon' in Grid. By default it has generic debuff types and ready check statuses assigned to it. If you call it 'debuff types' then ready check doesn't really fit. What about having status categories for each task 'generic debuff', 'specific debuff', 'my hots', 'other hots', 'aggro', 'health' (including dead/ghost), etc. and only let users assign those categories to indicators in the simple config mode. The advanced config would let people assign individual statuses.
Exactly right.
I agree that a one-to-one mapping between tasks and indicators in all cases is unlikely. Right now I am hoping it can be made to work and be good enough for the cases we care about as identified in the defaults thread.
Creating status categories is a good idea and probably where this is all headed anyway. Formally creating categories would allow a status to have multiple categories and still benefit from them being updateable and modifiable by the config. I like the concept in AutoBar and am absolutely willing to do the extra work required to implement it here.
It would mean that the category identity is no longer baked into the indicator name, and names can go back to being what they were before or auto-generated as suggested, including by type/location etc.
With that I agree.
Yes, this got a quote from me. You say Phanx is not infallible, no one is. No ones views are better than anyone elses (unless your name is some genocidal dude who shall not be named or some serial killer psychopath, the views of those suck.), we are human and we have the right to voice our opinions.
So people who use the GUI are important to be heard, others are not? (That's how this does read imho.)
While to you, and others, this may not be important, to others it is. Phanx and myself being two of them. I don't see the intuitiveness in relocating "aggro" to topleft, and having "topleft" be shown on some other location. This is where confusion sets in.
Let the locations be the name, where we can check stati to be shown there. I honestly feel this will be less confusing for quite a few people and can increase productivity.
Agreed.
Also, you noted you wished to include a GUI setup option, with drag 'n drop etc. Please please make that a seperate part, not included in the Grid2OPtions, you could call it Grid2GUIOptions.
While I completely consider Azethoth's views as valid, it would be nice if there would be some form of compromise possible, because sadly for some of us, his views of how things should be done, don't concur with ours, therefore one of us will be on the totally losing end. Wouldn't it be better if we do try to make a compromise.
Also, I don't feel it is needed to have 3 levels of advancement in the config. Simple and Advanced - ok, that is doable, more than that, isn't really needed.
Eg. Simple config utilizes that GUI setup with mainly preconfigured settings, advanced drops you fully into the complexity of a setup, with the ability to start from the basics (only the base indicator/locations and stati are setup already, everything else has to be done manually.)
That is mainly what me and Phanx are worried about. The awkwardness of having a location named after a status (thus being taskbased) while that task isn't even assigned to that particular location, which is how it is now.
This, I think, is a good idea and I can find myself in it.
Now, I will try my best to keep up with all this, I am starting a new job for which I will be away from home 14/15hrs a day (8hrs to work, the rest is train+bus), so I doubt I'll do much other then that during the week. But that said, if there's need to try new things or anything, drop me a pm, I'll do my best.
Also, can we try and get the texture/hp/heals thing solved? It is rather annoying and at this point - it does make Grid2 unusable for me at times.
--Hooks up Blink Threshold for buff-statuses.
--Fixes lowmana which was broken
--Adds threshold config for lowmana
--Options for the alpha indicator
--Options for the border indicator
The purpose of it is to figure out how to do shared or universal settings across multiple characters and / or specs. If you have no interest in that then the thread is not for you, and neither will the results of the thread impact your current usage of the config and you can safely ignore it.
Sort of. I intend to build a better config in Grid2 than in Grid. The goal is to be better, and not just different for the sake of being different.
This specifically means that I want to change things that I found clumsy in Grid and that I know to be clumsy because I have helped many other people set up Grid, or seen posts about them in Grid and Grid2 threads. So for instance making thousands of users set things up from scratch is clumsy. It is better to get some idea of what they end up with and offer that as one or more built in options.
It also means that usage patterns can change. Grid had a particular way that you set up your config. Grid2 will still have the same methods or equivalent methods for setup as Grid did, but may also have faster or better ways as well. If the new expected pattern is that 95% of people use the faster or better ways and only 5% use the old way then in my opinion it is acceptable to give more weight to the needs of the 95% than the 5% when there is a conflict.
"The needs of the many outweigh the needs of the few or the one" - Spock, Star Trek: The Wrath of Khan
So back to the issue of naming indicators. It sounds like assigning multiple Categories of statuses to a single indicator is acceptable. This makes it so indicator names do not have to be specific in order to track their associated categories. This removes my previously unavoidable reason for changing the naming convention.
I like Phanx' idea of automatic naming. This can even be configurable so the indicator name is constructed from one or more of location, type, and its categories with some scheme to ensure uniqueness. It also has the big advantage of avoiding the need to actually name indicators and type that name in. In addition, by allowing the included categories to be exposed, it solves my need to have indicators be identified by their purpose.
Therefore my current thinking is to do automatic naming for indicators. Unless a better idea comes along of course.
Then I have nothing more to contribute here I suppose >.<
But:
"The needs of the one outweighed the needs of the many." - Kirk, Star Trek III: The Search for Spock
Elbereth.
An basic example would be a meta-status that can use the state of other logical statuses in boolean expressions. For example, you have the status buff-renew and the status buff-regrowth. Then you could create a meta-status "hots" that is active, if one of the former two is active (logical or). This would also make the plugin Grid2StatusAuraGroup you are planning obsolete.
If you reached that conclusion then you either did not read the entire post or I was not clear.
Very good grasshopper, but totally premature. That will not apply till we get to Grid3
This sounds totally kool, especially if you are a comp sci or math or physics major. What could be neater than complex pipelines of statuses and boolean operators on them? It would surely make a delightful class project in a 2nd year comp sci course! In Grid though it has already been done, competed with other ideas, found unfit, then recently became extinct just as Darwin would have predicted.
That was one half of it. The other half was that it had bad consequences in the core in terms of knowing what is hooked up or not. Pastamancer could comment on that more if the sad fate of GridStatusControlPipes is not convincing enough.
Ooh, breaking news, a guid grid specimen of GridStatusControlPipes was made. I guess Julith decided not to abandon it after all. Well you can go play with that and see if you like the concept in reality.
Basically all I am trying to convey is :
- Keep the config simple, the naming dynamic (as per other topics).
- Use defaults on which people can build for more complex set-ups.
- And please rename "aggro" back to top-left :P It makes me personally (and I do know of a few others) assign things to "aggro" while we "relocate" another prenamed indicator to that very position. It's confusing.
Bad Moonwitch! Mr. Spock would so totally disaprove! On the other hand he comes from a nerd-race that only gets laid once every 7 years or something so ignoring his views may be the right thing to do sometimes.
Done.
instead of having a massive tree with indicators and locations how feasable would it be to show a blown up single grid in the options and then have 3 options add text and add indicator add border
you click add text and a new text(indicator) would show up on the middle of the cell you can then move that to where ever you want within the cell and you can click it to get to the options of what to display in the text indicator.
same would go for the indicator(little squares) you move it to where ever and then click it to tell it what it does or to remove it
border wouldn't have the movement option but would simply be the border.
some sort of sane default should be given on first install but also the option to wipe the grid and start from scratch (and of course the option to go back to defaults)
this way you could have people with little x-mass trees on their screen lighting up and blinking all over the place or have the minimalist with his one indicator that does everything he needs