Phanx mentioned all points that bothered me with DogTag.
What I'd like to see would be an improvement on how DogTags are entered.
At the very least multi-line edit boxes are needed because it is not easy to create long/complex DogTags.
I could imagine a WYSIWYG editor, where one could
- select text and change the color/outline/... on the selected text
- insert DogTags from a drop-down which can be split up into categories (e.g. much like the ingame help or the wiki is organized)
- see the effect of the DogTag (like the ingame preview thingie)
and what not more.
Just look at the buttons above the edit box when you write a reply in this thread ;)
FWIW such an editor does not need to be available ingame but could also be a <insert favorite language here> application that allows copy+pasting of the DogTags to the ingame edit box.
As a "regular" user of addons Dog-Tags have always been a place I never ventured. I just imply didn't understand the logic as to how you create dogtags and which commands does what. When going into the help menu I'm almost scared away due to the complexity and unfamiliarity of the syntax. I don't know anything about code and how it's being read, so dogtags doesn't make much sense either.
A way which would benefit a user at my level would probably be examples to explain what the dogtags does. I need this mod to hold my hand and guide me every step of the way sort of thingy. A drag n' drop interface would be awesome, and a sort of preview would be to.
Bottomline I think most resources should be put into making DogTags as user friendly as possible. For instance by rewriting the help menu and adding examples. I think the author really needs to be aware he's writing it to dummies like myself, else it's just too unfamiliar for the average user.
Using "blah" instead of [Text(blah)] would go a long way to making things easier.
I'm like using & for and | for or and : for else, and at the risk of getting to may brackets enclosing the "if" like this [curhp == maxhp ? "true" : "false"] seems straightforward, and would allow for [curhp == maxhp ? "ready to fight " curhp : curhp "/" maxhp] fairly intuitively -- at least for me it is better than having a concatenation operator.
Seems that white space is a logical concatenation operator.
Going back to pastamancer's post about Lisp, I think that DogTag really only has two large syntactical ideas behind it.
First is piping, as some may know from bash. echo 'alpha'|sed 's/p/s/' will pipe the results of echo 'alpha' into sed 's/p/s/'.
Much in the same way [CurHP:Green] pipes the results of CurHP into Green.
Second is basic logic statements, if something then do something else do another end, which DogTag has done with [Alpha ? Bravo ! Charlie]
There's not really anything beyond this, there's no list manipulation, no iteration.
Umm...ever looked at the in-game documentation (/dog)? Is there anything that you think could be improved there?
The problem with the in-game documentation (I think) is that it isn't broken up enough, and results in having to scroll around forever trying to find a specific tag in a list of 200. I'd suggest either improving the in-game documentation to something like this:
Level 1: Broad Categories (characteristics, math, talent trees, etc.) - click a category to get to...
Level 2: Tags In Category (listed alphabetically or in some immediately logical order) - click a tag to get to...
Level 3: Description of Tag (short paragraph, one or two examples)
Right-click to go up a level (much like how Assessment's windows work; very easy to learn and doesn't require extra buttons to find and click).
The examples in the in-game documentation are also not very helpful. Take this one for example (I just opened a random DogTag module and grabbed a random help text):
[Text(Blood Elf):ShortRace] => BE; [Text(Hello):ShortRace] => ""
Aside: does anybody use the ShortRace tag as a modifier that way? Probably not, since you could just do Text(BE) yourself. :P
Back on topic: the => and ; make this look very cluttered, and confusing. I think a better way to do this involves the "more verbose proper English" you were considering for tags earlier:
[Text(Blood Elf):ShortRace] -- since "Blood Elf" is a race, the ShortRace modifier will turn it into the short "BE".
[Text(Hello):ShortRace] -- since "Hello" is not a race, the ShortRace modifier won't have anything to turn it into, and you'll end up with a blank text string "".
Possibly too verbose, but you get the idea. Written-out explanations of each example, even if they're basically repeating the description, would be of great help to non-programmers in illustrating how the syntax works.
Quote from Seerah »
I think concatenation would go the other way on the scale of easy to understand - hard to understand... But maybe that's just me. I look at that and think "huh?"
Yeah, ixnay on the .. for concatenators. Whitespace inside [brackets] should never be considered literal unless it's in quotes such as Text("one two").
Quote from Pastamancer »
I find DogTag's syntax to be awkward at best. Trying to decipher any complicated DogTag string gives me a headache. I'll throw my two cents in and suggest that you adopt a more regular syntax.
I think with the changes I suggested in my first post, complicated strings would be more readable. Multi-line edit boxes (with tab support if possible) would also be a great improvement. Currently I work with long strings in a text editor where I can use multiple lines and indentation.
Another thing I'd like would be a true "and" operator. Currently I can do this:
[IsPlayerOrPet ? [IsFriend ? Level ! Level:DifficultyColor] ! Level:DifficutlyColor]
or this:
[ [IsPlayerOrPet ? IsFriend] ? Level ! Level:DifficultyColor]
but I think it would be much simpler and more intuitive to do this:
[IsPlayerOrPet & IsFriend ? Level ! Level:DifficultyColor]
For the average Joe User you'd get instant success if you made a sharedDogTags library and enabled a list for dogtag using addons configuration. Generally users would only want to pick their favorite dogtag. Dogtags stored in that library should have clear english description and perhaps an example of the output.
New dogtags could be submitted for library entry by Jira. Maybe they could be voted on as well. Joe User would only need to update the library from SVN and get instant access to good dogtags made and tested by those who understand the dogtag manipulation better, be it current or future improved syntax.
I don't know what all other addons use DogTag, but PitBull already includes quite a few "default" DogTag strings to pick from for each type (health, power, name, class, etc.). I don't think it's really necessary to have an in-game library of 500 premade strings; if users aren't satisfied with one of the default choices, they can browse through the "Post your DogTags" thread and find one (or ask for help with one) that matches their needs.
If there were a stand alone addon, like DogPark, in which a person could play with a virtual frame and experiment with different tags and perhaps copy paste tags into.....well that would be something I would use. A safe place to play with tags without ruining my existing set-up while waiting for a raid to start or while flying on the bird. (Thus my idea for the name DogPark.) Perhaps an option to save tags or send a tag to a friend like with in Talented?
Memory would not be an issue for me really, I don't see myself having an addon like this enabled all the time.
I always dreaded LISP, but I have to say that I find Pastamancer's example way more easy to read than the complicated DogTag. :)
[Alpha ? Bravo ! Charlie] is probably as far away from any spoken language as you can get. It is ok if you wrap your mind around the idea, tho. ckk mentioned piping in *nix shells - that is a concept most people have serious trouble grasping, too.
[Alpha and Bravo else Charlie] is even worse, and has nothing to do with making the syntax more english. For that you'd have to do something like
[IF Alpha THEN Bravo ELSE Charlie] or whatever. Not good, either.
[Alpha ? Bravo ! Charlie] could become [Alpha and Bravo else Charlie]
Along those lines, the one thing that would make me happy would be C-style selectors a la:
[Alpha ? Bravo : Charly] or, more to the point, [PercentHP < 10 ? "Die Scum" : "Just a flesh wound"]. This is more along the lines of cleaning up and styling my Cowtip tooltips than anything.
Hoern, that actually already exists with [PercentHP < 10 ? Text(Die Scum) ! Text(Just a flesh wound)]. Uses ! instead of : since : is used for piping.
The main issue that I see is that simple if-then and if-then-else statements are necessary, and currently handled by the [Alpha ? Bravo] and [Alpha ? Bravo ! Charlie] syntax, but that is complex and unintuitive for some people. I just don't know how to make it better and turning it into Lisp doesn't seem like the best solution to make things easier for users.
I could have something like [If(Alpha, Bravo)] or [If(Alpha, Bravo, Charlie)], but I don't think that that necessarily provides a better landscape.
If there were a stand alone addon, like DogPark, in which a person could play with a virtual frame and experiment with different tags and perhaps copy paste tags into.....well that would be something I would use. A safe place to play with tags without ruining my existing set-up while waiting for a raid to start or while flying on the bird. (Thus my idea for the name DogPark.) Perhaps an option to save tags or send a tag to a friend like with in Talented?
Memory would not be an issue for me really, I don't see myself having an addon like this enabled all the time.
There is already a sandbox in the help frame (/dog). And since DogTags are just simple text strings, you can send them in a simple chat message. Is there anything more you think could be added?
I hate the C 'if ? then : else' operator because once you get more than one level deep it's difficult to tell where you are in the nesting.
[If(condition, iftrue, iffalse)] would definitely help the readability of nested ifs since my eyes (and those most other programmers) match the parens.
I think the 'piping' really isn't necessary if you have functions that take parameters.
A dog tag "builder" would be awesome, but probably incredibly complex to make. I usually just copy other people's suggestions and tweak them. I really can't think of any way to make such a powerful system less complex without compromising functionality.
[If(condition, iftrue, iffalse)] would definitely help the readability of nested ifs since my eyes (and those most other programmers) match the parens.
[If(Not(HasNoMP), Concat(Short(CurMP), PowerColor("/"), Short(MaxMP)))]
Personally I rely on indentation... without visual brace matching I'm simply lost in the sea of parentheses. In your example I had to carefully read over it a few times to figure out what was going on. Not intuitive to programmers who've never programmed in a language that uses parentheses so gratuitously (I haven't), and certainly not intuitive at all to the non-programmers who make up the majority of DogTag users.
Quote from Pastamancer »
I think the 'piping' really isn't necessary if you have functions that take parameters.
It may not really be necessary, but again I think it's simpler and visually cleaner to do MaxMP:Short than Short(MaxMP), especially when you get into multiple modifiers. Compare:
For non-programmers, and "casual programmers" (this is what I'm going to refer to myself as from now on, not having learned any "real" languagues like C), the first is much more intuitive. "Okay, the value of CurMP will be hidden if it's 0, then hidden if it's the same as MaxMP, then shortened, then colored according to power type." It's closer to normal left-to-right reading, whereas the nested-parentheses example requires starting from the inside and working one's way out in both directions.
Like that, it's not very readable. When I'm making changes to this tag, I open a text file I have saved with all of my DogTags spread over multiple lines with proper indentation, so that one becomes:
Much easier to read, but still messy due to all the extra brackets needed to clarify what's actually "A and B ? X" instead of "A ? B ? X" due to there only being a single "and" operator.
Ideally I'd be able to write that one this like:
[IsPlayerOrPet & IsFriend & Classification ~= "Non-combat Pet" ? Level:Hide("70"):Color("ccccff") ! Classification ~= "Boss" & Creature ~= "Critter" ? Level:DifficultyColor]
For extra clarification of the multiple levels, the editor would probably add more brackets, like so:
[IsPlayerOrPet & IsFriend & Classification ~= "Non-combat Pet" ? Level:Hide("70"):Color("ccccff") ! [Classification ~= "Boss" & Creature ~= "Critter" ? Level:DifficultyColor] ]
As an aside, the current version really needs a way to do ~[Creature = Text(Critter)] or [Creature ~= Text(Critter)] so I don't need so many pointless condition ? Text() ! tags I actually want sequences.
Another issue to consider with regard to syntax is the number of users who've already become accustomed to the current syntax; changing it as drastically as Pasta is suggesting and making so many users who have likely never even seen code more complex than BBCode before learn another "alien language" is probably not the best plan.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
What I'd like to see would be an improvement on how DogTags are entered.
At the very least multi-line edit boxes are needed because it is not easy to create long/complex DogTags.
I could imagine a WYSIWYG editor, where one could
- select text and change the color/outline/... on the selected text
- insert DogTags from a drop-down which can be split up into categories (e.g. much like the ingame help or the wiki is organized)
- see the effect of the DogTag (like the ingame preview thingie)
and what not more.
Just look at the buttons above the edit box when you write a reply in this thread ;)
FWIW such an editor does not need to be available ingame but could also be a <insert favorite language here> application that allows copy+pasting of the DogTags to the ingame edit box.
A way which would benefit a user at my level would probably be examples to explain what the dogtags does. I need this mod to hold my hand and guide me every step of the way sort of thingy. A drag n' drop interface would be awesome, and a sort of preview would be to.
Bottomline I think most resources should be put into making DogTags as user friendly as possible. For instance by rewriting the help menu and adding examples. I think the author really needs to be aware he's writing it to dummies like myself, else it's just too unfamiliar for the average user.
I'm like using & for and | for or and : for else, and at the risk of getting to may brackets enclosing the "if" like this [curhp == maxhp ? "true" : "false"] seems straightforward, and would allow for [curhp == maxhp ? "ready to fight " curhp : curhp "/" maxhp] fairly intuitively -- at least for me it is better than having a concatenation operator.
Seems that white space is a logical concatenation operator.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCSS has concatenation by juxtaposition, and it seems like it could simplify things for users quite a bit.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFirst is piping, as some may know from bash. echo 'alpha'|sed 's/p/s/' will pipe the results of echo 'alpha' into sed 's/p/s/'.
Much in the same way [CurHP:Green] pipes the results of CurHP into Green.
Second is basic logic statements, if something then do something else do another end, which DogTag has done with [Alpha ? Bravo ! Charlie]
There's not really anything beyond this, there's no list manipulation, no iteration.
The problem with the in-game documentation (I think) is that it isn't broken up enough, and results in having to scroll around forever trying to find a specific tag in a list of 200. I'd suggest either improving the in-game documentation to something like this:
Right-click to go up a level (much like how Assessment's windows work; very easy to learn and doesn't require extra buttons to find and click).
The examples in the in-game documentation are also not very helpful. Take this one for example (I just opened a random DogTag module and grabbed a random help text):
[Text(Blood Elf):ShortRace] => BE; [Text(Hello):ShortRace] => ""
Aside: does anybody use the ShortRace tag as a modifier that way? Probably not, since you could just do Text(BE) yourself. :P
Back on topic: the => and ; make this look very cluttered, and confusing. I think a better way to do this involves the "more verbose proper English" you were considering for tags earlier:
[Text(Blood Elf):ShortRace] -- since "Blood Elf" is a race, the ShortRace modifier will turn it into the short "BE".
[Text(Hello):ShortRace] -- since "Hello" is not a race, the ShortRace modifier won't have anything to turn it into, and you'll end up with a blank text string "".
Possibly too verbose, but you get the idea. Written-out explanations of each example, even if they're basically repeating the description, would be of great help to non-programmers in illustrating how the syntax works.
Yeah, ixnay on the .. for concatenators. Whitespace inside [brackets] should never be considered literal unless it's in quotes such as Text("one two").
I think with the changes I suggested in my first post, complicated strings would be more readable. Multi-line edit boxes (with tab support if possible) would also be a great improvement. Currently I work with long strings in a text editor where I can use multiple lines and indentation.
Another thing I'd like would be a true "and" operator. Currently I can do this:
[IsPlayerOrPet ? [IsFriend ? Level ! Level:DifficultyColor] ! Level:DifficutlyColor]
or this:
[ [IsPlayerOrPet ? IsFriend] ? Level ! Level:DifficultyColor]
but I think it would be much simpler and more intuitive to do this:
[IsPlayerOrPet & IsFriend ? Level ! Level:DifficultyColor]
New dogtags could be submitted for library entry by Jira. Maybe they could be voted on as well. Joe User would only need to update the library from SVN and get instant access to good dogtags made and tested by those who understand the dogtag manipulation better, be it current or future improved syntax.
Memory would not be an issue for me really, I don't see myself having an addon like this enabled all the time.
[Alpha ? Bravo ! Charlie] is probably as far away from any spoken language as you can get. It is ok if you wrap your mind around the idea, tho. ckk mentioned piping in *nix shells - that is a concept most people have serious trouble grasping, too.
[Alpha and Bravo else Charlie] is even worse, and has nothing to do with making the syntax more english. For that you'd have to do something like
[IF Alpha THEN Bravo ELSE Charlie] or whatever. Not good, either.
Along those lines, the one thing that would make me happy would be C-style selectors a la:
[Alpha ? Bravo : Charly] or, more to the point, [PercentHP < 10 ? "Die Scum" : "Just a flesh wound"]. This is more along the lines of cleaning up and styling my Cowtip tooltips than anything.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe main issue that I see is that simple if-then and if-then-else statements are necessary, and currently handled by the [Alpha ? Bravo] and [Alpha ? Bravo ! Charlie] syntax, but that is complex and unintuitive for some people. I just don't know how to make it better and turning it into Lisp doesn't seem like the best solution to make things easier for users.
I could have something like [If(Alpha, Bravo)] or [If(Alpha, Bravo, Charlie)], but I don't think that that necessarily provides a better landscape.
Color me redfaced. You know, I should really learn to RTFM.
Edit: just managed to confuse myself... the above makes no sense, or does it?
There is already a sandbox in the help frame (/dog). And since DogTags are just simple text strings, you can send them in a simple chat message. Is there anything more you think could be added?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium[If(condition, iftrue, iffalse)] would definitely help the readability of nested ifs since my eyes (and those most other programmers) match the parens.
I think the 'piping' really isn't necessary if you have functions that take parameters.
Going back to the earlier example, consider:
vs. a regular ALGOL-ish syntax:
[If(Not(HasNoMP), Concat(Short(CurMP), PowerColor("/"), Short(MaxMP)))]Similar to SQL decode().
Personally I rely on indentation... without visual brace matching I'm simply lost in the sea of parentheses. In your example I had to carefully read over it a few times to figure out what was going on. Not intuitive to programmers who've never programmed in a language that uses parentheses so gratuitously (I haven't), and certainly not intuitive at all to the non-programmers who make up the majority of DogTag users.
It may not really be necessary, but again I think it's simpler and visually cleaner to do MaxMP:Short than Short(MaxMP), especially when you get into multiple modifiers. Compare:
[CurMP:Hide("0"):Hide(MaxMP):Short:PowerColor]
[PowerColor(Short(Hide(Hide(CurMP, "0"), MaxMP)))]
For non-programmers, and "casual programmers" (this is what I'm going to refer to myself as from now on, not having learned any "real" languagues like C), the first is much more intuitive. "Okay, the value of CurMP will be hidden if it's 0, then hidden if it's the same as MaxMP, then shortened, then colored according to power type." It's closer to normal left-to-right reading, whereas the nested-parentheses example requires starting from the inside and working one's way out in both directions.
First, I think HasNoMP should be renamed HasMP and work in reverse. I can't really think of any use for HasNoMP without the ~ negation operator.
Anyway, compare:
[HasMP ? CurMP:Short Text("/"):PowerColor MaxMP:Short]
It's both shorter and easier to read than either the current method or your proposed syntax filled with parentheses.
As for the readability of nested conditions, I'll use part of a tag I'm actually using as an example:
[ [IsPlayerOrPet ? IsFriend] ? [[Classification = Text(Non-combat Pet)] ? Text() ! Level:Hide(70):Color(ccccff)] ! [ [ [Classification = Text(Boss)] | [Creature = Text(Critter)] ] ? Text() Level:DifficultyColor ] ]
Like that, it's not very readable. When I'm making changes to this tag, I open a text file I have saved with all of my DogTags spread over multiple lines with proper indentation, so that one becomes:
[
[IsPlayerOrPet ? IsFriend]
?
[
[Classification = Text(Non-combat Pet)]
?
Text()
!
Level:Hide(70):Color(ccccff)
]
!
[
[ [Classification = Text(Boss)] | [Creature = Text(Critter)] ]
?
Text()
!
Level:DifficultyColor
]
]
Much easier to read, but still messy due to all the extra brackets needed to clarify what's actually "A and B ? X" instead of "A ? B ? X" due to there only being a single "and" operator.
Ideally I'd be able to write that one this like:
[IsPlayerOrPet & IsFriend & Classification ~= "Non-combat Pet" ? Level:Hide("70"):Color("ccccff") ! Classification ~= "Boss" & Creature ~= "Critter" ? Level:DifficultyColor]
For extra clarification of the multiple levels, the editor would probably add more brackets, like so:
[IsPlayerOrPet & IsFriend & Classification ~= "Non-combat Pet" ? Level:Hide("70"):Color("ccccff") ! [Classification ~= "Boss" & Creature ~= "Critter" ? Level:DifficultyColor] ]
As an aside, the current version really needs a way to do ~[Creature = Text(Critter)] or [Creature ~= Text(Critter)] so I don't need so many pointless condition ? Text() ! tags I actually want sequences.
Another issue to consider with regard to syntax is the number of users who've already become accustomed to the current syntax; changing it as drastically as Pasta is suggesting and making so many users who have likely never even seen code more complex than BBCode before learn another "alien language" is probably not the best plan.