UI to generate scripts for users discussion

[Cosmic Cleric]

I wanted to start this subject so we could start collaborating on
ideas on what a UI that would be used in place of typing the XUB
script would look like and how it would function.

This UI will present to the user a different way to setup/configure
their XUB buttons than how they are used to doing so via the scripting
language, in an attempt to simplify the setup of XUB for the users.
Along the lines of GroupButtons and BeneCast, etc.

The first order of business is deciding how 'automated' this UI should
be. By that I mean, do we design it so someone new to XUB could get a
default profile and default groups auto-created for them that match
the frames, and then the user just creates buttons to add to a group
that is associated to a frame?

Or do we just literally have a UI front-end that matches the XUB
syntax, and let the user be responsible for creating profiles and
groups on their own?

I would advocate the former and not the latter, but allow the expert
XUB user to be able to go in and modify existing default groups, add
new profiles, and add new groups if they want.

So, for example, we could have a UI that borrows from the AH window,
where a tree on the left side would present the following options...

PROFILES
default
player
playerpet
target
party
raid
floating

GROUPS
castonplayer
castonplayerpet
castonparty
castonraid
castontarget
castviafloatingbar

BUTTONS

Each profile created (including the 'default' one we create if no
profiles exist), would have an entry in it for each of the possible
frames groups (buttons) can be attached to.

When the user selects a frame under a profile, the right side of the
window would show a list of possible groups to associate to the frame

When the user selects a group name under a group, the right side would
show a list of possible buttons that can be associated with a group.

For the BUTTONS header, below it will list all of the buttons that the
user has created so far. When a user clicks on a button under the
header, the right side would show all of the configuration options
that a button could have (blinking, classes to hide it from, etc.).
We could always populate the list of buttons underneath the BUTTONS
header with a list of all of the spells the user's character can cast
to help the user out.

So a novice user would just go to each group, assign what buttons it
should have, and they are done. The default profile 'player' frame
entry would be auto-associated with the castonplayer group, etc.

We could even go one step further and instead of a profile named
default, we could create profiles for each class, and auto-load that
profile information on first-time run of XUB. The only issue with
this approach though would be we would define the buttons for a level
70 character, and at level 1 the majority of the spells will not be
know to the user, and currently XUB generates an error if you try to
tell it to cast a spell that is not currently the user's spellbook.
An extra-credit assignment option to do. :P

An expert user could go in, delete all of the default entries, and
build up their own configuration. Also, when XUB starts up it would
read in all of these existing script entries and put profiles under
PROFILES, groups under GROUPS, etc.

Each header section would have a right-click associated with it to
create a new entry under it.

Thats it for now. Thoughts?

[Tayedaen]

Hi !

Do you know the new configuration for fubar (fubar 3.0) ?
It's part of the rock framework... Anyway: Take a look at it.
You'll see there are two frames, a list of addons in the left frame
(some of them with subcategories ), and a large window to the right.
My idea for the XUB GUI goes along the same thinking as the fubar
config does.
In the left frame we would have a "Tasks", and in the right frame
the corresponding windows.

I'll show you my ideas.
If I'm talking about "lines" from now on, then every item in one
line is added from left to right.
An example for this is the unitframe window, where everything is
arranged in such lines.

Tasks-Frame Rightframewindow
Add Button Window 1 (detailed description below)
Edit Button Window 2 (detailed description below)
Edit Groups Window 3 (detailed description below)
Add Groups Window 4 (just enter a groupname and save)
Edit Profiles Window 5 (details follow in a later post)
Add Profile Window 6 (just enter a profilename and save)
Options Window 7 (already existing)
Unitframes Window 8 (already existing)

Window1 (Add Button):
Heading "Buttons"
Line 0:
Label: Buttonname
Editbox where the User may enter a buttonname
Line 1:
Label: Group
Dropdownbox to select a group
Dropdownbox contains the names of all existing groups
default entry: Name of group1 (eg. 'default')
Line 2:
Label: Buttontype
Dropdownbox to select the buttontype (default entry: spell)
Dropdownbox contains all existing buttontypes
(eg. Spell, Buff, Debuff, Use, Macro, XUB-Macro)
Line 3:
subheading: Mainbutton (Leftclick)
Line 4:
The content of this line depends on the buttontype in line 2
Buttontype Spell/Buff/Debuff:
Label: Leftclick
Next to the label is a an empty icon box
In this icon box the user drags a spell from his spellbook
Buttontype Use:
Label: Use Item
empty icon box
In this icon box the user drags am item from his inventory
Buttontype Macro (will be added in a later stage !):
Label: Macro Item
empty icon box
In this icon box the user drags a macro from the macrowindow
The rest of the window is empty (if buttontype = Macro)
Buttontype XUB-Macro:
Label: Macro text
Below this label is a big editbox to enter a macro
The rest of the window is empty (if buttontype = XUB-Macro)
If the buttontype is not XUB-Macro, and the user has entered
no name yet, then the name of the dragged item is entered
into line 0.
Line 5:
Still belongs to the mainbutton section
The content of this line depends on the buttontype in line 2
Buttontype Spell/Use/XUB-macro/Macro/: not shown
Buttontype Buff/Debuff:
Label: Conditions
Next to the label: an empty box where to enter conditions
Line 6:
Still belongs to the mainbutton section
The content of this line depends on the buttontype in line 2
Buttontype Spell/Use/XUB-macro/Macro/: not shown
Buttontype Buff:
Checkbox "Blink"
Label: "Blink last X seconds"
EditBbox where the user may enter a number X
Buttontype Ebuff:
Checkbox "Blink"
Line 7:
subheading: additional buttons
Line 8:
Label: Middlecklick
The rest of the line is the same as line 4
Line 9:
Label: Rightlick
The rest of the line is the same as line 4
Line 10:
Label: Button 4 Click
The rest of the line is the same as line 4
Line 11:
Label: Button 5 Click
The rest of the line is the same as line 4
Line 12:
Button "Save"
If check is OK, then the button is saved, line 0 is emptied,
all settings are reset to defautl, except the group selection
that remains.

Window 2 (Edit Button)
This window is nearly the same as window 1.
The only difference is in line 0.
Line 0:
Label: Buttonname
Dropdownbox to select a button
default entry: Name of the first button
Next to the dropdownbox are two buttons "Delete" and "Rename"
"Delete" needs a confirmation window since it will remove this
button from all groups
All other lines are the same as window1.

Window 3 (Edit Groups):
Line 0:
Label: Groupname
Dropdownbox to select a button
default entry: Name of the group1
Next to the dropdownbox are two buttons "Delete" and "Rename"
Line 1:
Listbox
In this listbox all spells of the selected group are displayed
Line 2:
Button "Remove Button"
This button removes the selected spell(s) in the listbox from
the selected group.

To be continued - no more time now :(

At the beggining, there is one predefined (empty) group,
named 'default'. And there is one predefined profile,
named 'normal', containing only group1 'default'.

Sorry to interrupt here, but RL calls ;-))

cu
tay

P.S.
Did you try beta 3?
What are your impressions?

[Cosmic Cleric]

I'll take a look at fubar 3 and see if I can visualize what you are
describing.

I was wondering though, if you had a chance to read what I was
proposing, and what you thought of it? I didn't see you make any
mention of what I already commented on. Thoughts?

One thing I'm trying very hard to do is not present to the user a UI
version of what the XUB script is, at least not for the novice user,
but instead something a human being can see on the screen and intuit
how it works naturally.

P.S. Beta 3 is still laggy on raid changes :( though I like how it
notifies you when its do delayed updates. I keep getting killed in BG
when my screen freezes for 3-10 seconds during raid changes.

[Drome]

> Thats it for now. Thoughts?

I like it. I think a ui on top of that would get a novice user up to
speed quickly. I assume that if "Holy Light" was put into the
castonparty group the config that this would create would be

Buttons
- none
groups
castonparty,HolyLight,*
profile
default,party,castonparty


Adding Flash of Light to party, putting both on castonplayer and
adding Divine Shield in castonplayer would give:

Buttons
- none
groups
castonplayer,HolyLight,*
castonplayer,FlashOfLight,*
castonplayet,DivineShield,*
castonparty,HolyLight,*
castonparty,FlashOfLight,*
profile
default,player,castonplayer
default,party,castonparty


If so the generic first pass interface is a drag and drop from a
button (default spell list) to a group.


castonplayer
[Flash Of Light]
castonplayerpet
[Holy Light]
castonparty
[Divine Shield]
castonraid ...
castontarget
castviafloatingbar

I think filtering / paging of the spells would be good. (check boxes
for Racial, Holy, Retribution, Protection, Defined) middle three
based on class

Second phase could be to add a button creator where you can create
Ranked spells, use spells, de/buff/blink buttons, and macros. This
would be an optional capability that modifies the button list we are
already using.

third phase could be the interface to profiles. Copy groups to
profiles.

phase 0 or 2 could be the XUB minimap button for setting profile
(default), getting to ui configuration, option, unit frames, text
configuration.

Drome

[Drome]

> Did you try beta 3?
> What are your impressions?

I have and I have configured the MB-Ranked. It is working - but when
i /xub c the next time the line is missing. the round trip is failing
somehow.

>Do you know the new configuration for fubar (fubar 3.0) ?

I will look at what i have - i think it is fubar 3 what I am
visualizing now is this could be naviagtion off of the minimap button
that gets the user to the configuration screens. I want to make the
most basic use cases straight forward. Adding a default spell to the
player and party is 3 clicks and two drags.

Click on Minimap button
click on UI config Wizard
Drag button to castonplayer
Drag button to castonparty
click on OK

ignoring UnitFrame Selection here


Drome

[Tayedaen]

> Do we design it so someone new to XUB could get a

> default profile and default groups auto-created for them that
> match the frames, and then the user just creates buttons to add
> to a group that is associated to a frame?

> Or do we just literally have a UI front-end that matches the
> XUB syntax, and let the user be responsible for creating profiles
> and groups on their own?

> I would advocate the former and not the latter, but allow the
> expert XUB user to be able to go in and modify existing default
> groups, add new profiles, and add new groups if they want.

I would advocate the later.
Or at least something that is more like the later then like
the former ;-)))
Let me explain why.

The thing I like the most with XUB are the groups.
With XUB you can define a group (this is a one time action),
and then you can attach this group to many frames.

Now this implies that groups are completely independant
of targets (destination units).
Lets say we have a group "Dispel" with the Spells
'Dispel Magic', 'Remove Disease' and 'Remove Poison'.
This group can be attached to player, party and raid etc.

Now in your proposal there is a group called 'castonplayer'.
This is a completely different thing: It's a group for only
one target!
This makes groups basically unnecessary, because if a group
goes only to one target, then instead of using groups we could
just go on and attach buttons directly to the destination unit.
This dilutes the the best and most important feature of XUB!
We should never present this to newbies, since this would
lead to false assumptions and misunderstandings about how XUB
really works.
So I do not like the idea of 'costOnX' groups.

On the other hand I agree that it would be great to help
newcomers by presenting them a starting configuration where
they can immediatly start playing with.
But it should still use groups like we used them up to now.
Groups like: 'Heal1' Heal2' 'Dispel' 'Emergency' 'Hostile1' etc.
We even should provide at least one 'macro' and one 'use' button ;-)
Yes, we could (or even should) provide one simple (working)
configuration for each class, that simply helps the user by showing
him what he can do.

The look of the GUI you descibed ("like the AH") is nearly the
same as the look I was describing. So, yes I like that idea ;-)
We could even change the addon so that it uses Rock, with the
additionaly advantage of beeing a fubar plugin.
This would not add a lot of overhead probably since we would
only use it for the config. This could be load on demand.

[Tayedaen]

I'd like to add some general ideas on where we should go,
after all a GUI is just a visualisation for ideas.
Perhaps it was not wise to explain you my GUI ideas
without presenting the ideas behind the GUI.

1) Idea 1:
In the future there should be no difference between a
'normal/simple button' and a 'custom button'.

At the moment we have a distinction between a simple and
custom button. The simple button is just drag and drop, with
no additional features. The custom button needs additional
text imput from the user.

If we remove the text part by creating a better GUI, then all
buttons are 'simple buttons'.
The degree of their customisation is just depending on what
options the user checks in the config screen (window 1).

2) We should use 'drag and drop' wherever possible

So we no longer generate a spellist- the user just drags a spell
from his spellbook. All 'modern' addons use this approach.

3) We should provide Dropdownboxes whenever possible
So the user has to enter no text at all except he wants to
add a new group or profile


All these three ideas led me to the GUI ideas I was presenting
in my first post in this thread.

[Drome]

On Dec 5, 7:18 am, Tayedaen <vogt.mar...@gmail.com> wrote:

> Now in your proposal there is a group called 'castonplayer'.
> This is a completely different thing: It's a group for only
> one target!

One of us is missing what Cosmic is suggesting.

My understanding is that castonplayer is a group that is created by
default to help the
novice user get the first buttons working quickly and easily (the same
for
the default profile). An intermediate user could delete these
groups and create new ones called 'Heal1' Heal2' 'Dispel' 'Emergency'
'Hostile1' etc. and do anything they can do to day. For what it is
worth
the groups (only showing one spell for each) on my pally are:

cleanse,Cleanse,*
healbuf,DivineFavor,player
grpheal,HolyShock,*
grpcombat,BlessingofFreedom,*
grpbuf,BlessingofMight,*

slfcombat,DivineShield,*

pet,FlashofLightRank5,*

focus,_focus,*
cfocus,_cfocus,*

raid,Cleanse,*

so I am not against the target specific nature per se - I think they
are easier to understand then abstract groups and therefore help the
novice user.

Drome

[Drome]

On Dec 5, 7:34 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> I'd like to add some general ideas on where we should go,
> after all a GUI is just a visualisation for ideas.

I would like to make the ui do the simple things very easy, provide
options to perform as much of the advanced features as possible and
allow a text mode to handle teh cases where we cannot come up with a
realistic UI.

> 1) Idea 1:
> In the future there should be no difference between a
> 'normal/simple button' and a 'custom button'.

Yes, from a UI perspective when dragging spells to groups default and
custom
spells should both show up on the button pallet. I would prefer to
have the pallet
of buttons not include the rank (IE the button you drag is the
unranked spell)
and provide a context menu in the group to specify the rank. I think
this is workable
but involves some slight of hand in the UI.

> no additional features. The custom button needs additional

> text input from the user.

I would propose that the custom button is an optional dialog that the
user
could activate that allows them to add a new button or maintain an
existing button.

> If we remove the text part by creating a better GUI, then all
> buttons are 'simple buttons'.

I can not envision removing the text interface completely -I do not
know if
we can create a UI for all of the things that a user can do.
Hopefully I am
just not envisioning hard enough :-)

> 2) We should use 'drag and drop' wherever possible
>
> So we no longer generate a spellist- the user just drags a spell
> from his spellbook. All 'modern' addons use this approach.
>

Yes on drag and drop - I do not know if the Blizzard spell book is
good enough.
I think there are issues with placement of the Blizzard window and the
inclusion of all ranks.


> 3) We should provide Drop down boxes whenever possible

> So the user has to enter no text at all except he wants to
> add a new group or profile

I think that any of the GUI elements should be used where
appropriate.
the issue is deciding which goes where.

[Tayedaen]

On 5 Dez., 19:06, Drome <1Dr...@gmail.com> wrote:
> I would like to make the ui do the simple things very easy, provide
> options to perform as much of the advanced features as possible

me too

> and allow a text mode to handle teh cases where we cannot come
> up with a realistic UI.

I think there is a realistic UI that does not need any text. See my
proposal above, it's already VER detailed, and gives all that we want.

[Cosmic Cleric]

Yes! That was exactly my point. My intent is not to get rid of
groups, but just to hide them from the novice user, but make them
available for the advanced user, since they are very powerful (I
myself have a heal group which I reuse on multiple target frames).

I totall agree on the drag and drop nature too.

In fact, what I bascally want to do is mimic how GroupButtons did it
but add functionality so that the user can define new profiles and
groups (a feature that GroupButtons didn't have).

How GroupButtons did it was basically have a row of buttons on the
left side, one for each target frame (player, playerpet, party, etc.),
and when you clicked on it the right side became an empty matrix of
empty button holes with an option button next to them. You could drag
a spell from the spell book into one of the empty button holes, then
click on the option button next to it to configure the button (should
it blink, should it be a rank spell, etc.).

The only issue with how GroupButtons did it was that since it didn't
have a concept of groups, it just assigned a fixed number (up to 20 I
think) buttons to each frame. By suggesting the AH type of tree, we
could create default groups, one for each target frame, but the user,
once being sophisticated with XUB, could go back, delete the group,
and create a new one called Heal, and then assign that to the profile/
target frame.

Here's a screenpic of how the GroupButtons setup screen was like:
http://www.wowinterface.com/downloads/full529.jpg

Its a little crowded, but I think you can get a feel for what I just
described when looking at the screenpic.

When I first started using extra buttons add-on, I was using Benecast,
which automated EVERYTHING (http://www.wowhealers.com/mods/
benecast.jpg), so moving to GroupButtons (when Benecast stopped
working) was hard to do, allot more to configure/setup. Then going
from GroupButtons to XUB script was a whole other level of
complexity. Kind of like going from Basic to C to Assembly! :p

If I could, I would even go more towards the Benecast method of doing
things, but I could not imagine a way of doing that and still allow
the advanced user to take advantage of multiple profiles and/or
groups, so I settled on a GroupButtons configuration methodology that
allows us profiles/groups.

The reason why I want to focus the UI for making it as easy as
possible to setup for the new user is from my own experiences with
Benecast/GroupButtons, as well as this article...

http://www.wowinsider.com/2007/05/31/the-creamy-gui-center-group-buttons/

Search for "eXtreme Unit Buttons" in the article and read up on what
they say about XUB.

On the subject of regular vs. custom buttons, I too was thinking just
make all buttons enhanced. There does seem to be different branches
of code internally that processes an regular spell button vs. a CUSTOM
one though (at least from observing how XUB does its thing; I could be
wrong), so we'd have to make sure we don't lose any functionality by
making all buttons custom buttons.

---
BTW, on a completely different subject, we're talked about on
alt.games.warcraft: http://groups.google.com/group/alt.games.warcraft/browse_thread/thread/04aa8d810a326e5d

Seems the person didn't like XUB because of button alignment issues??
I've never seen any. In fact XUB is very customizable for button
layout, but meh. /shrug

[Cosmic Cleric]

Er, please ignore the typos. I was on the phone for a job interview
while typing this. I wish we could go back and edit this stuff! :p

> http://www.wowinsider.com/2007/05/31/the-creamy-gui-center-group-butt...

>
> Search for "eXtreme Unit Buttons" in the article and read up on what
> they say about XUB.
>
> On the subject of regular vs. custom buttons, I too was thinking just
> make all buttons enhanced. There does seem to be different branches
> of code internally that processes an regular spell button vs. a CUSTOM
> one though (at least from observing how XUB does its thing; I could be
> wrong), so we'd have to make sure we don't lose any functionality by
> making all buttons custom buttons.
>
> ---
> BTW, on a completely different subject, we're talked about on

> alt.games.warcraft:http://groups.google.com/group/alt.games.warcraft/browse_thread/threa...

[Cosmic Cleric]

The link for the Benecast picture was broken out into two lines.
Here's how it should be (hopefully)...

http://www.wowhealers.com/mods/benecast.jpg

On Dec 5, 10:52 am, Cosmic Cleric <CosmicCle...@gmail.com> wrote:

> http://www.wowinsider.com/2007/05/31/the-creamy-gui-center-group-butt...

>
> Search for "eXtreme Unit Buttons" in the article and read up on what
> they say about XUB.
>
> On the subject of regular vs. custom buttons, I too was thinking just
> make all buttons enhanced. There does seem to be different branches
> of code internally that processes an regular spell button vs. a CUSTOM
> one though (at least from observing how XUB does its thing; I could be
> wrong), so we'd have to make sure we don't lose any functionality by
> making all buttons custom buttons.
>
> ---
> BTW, on a completely different subject, we're talked about on

> alt.games.warcraft:http://groups.google.com/group/alt.games.warcraft/browse_thread/threa...

[Tayedaen]

hihi, I once was a coauthor for benecast ;-))
My name at wowui was 'Tayeaden', since I made a typo at registering,
and they does not allow to change your name later :(

But the benecast code had become very unreadable over time.
I asked myself: Should I rewrite large portions of it?
I then looked for alteratives, and found XUB.
Then I decided to quit benecast and switch to the more
powerfull addon.
So I know benecast very well (even from the code !).
But it's too limited when compared to XUB.

Back to topic:
Why not create predefined groups, but not for targets?
Like: 'Heal' 'Buff' 'Dispel' 'Emergency' 'Hostile' ?
Or even just 'noharm', 'harm' ?
Because I think the predefined grousp are examples, and
by seeing these examples the user get's an idea how the
addon works. I really doubt that many users are reading
a manual (I seldom do ;-)) )
So teaching by example would be very wise here.

We also could add these groups to predefined destination,
so in the end this would mean the same amount of work for
the user as target specific grousp are.

[Cosmic Cleric]

Very cool about Benecast! I used that forever until it started
breaking because of WoW secure frames changes.

One thing you should know, in the guild I was in, many used it, and
were not PC people per say, and when it broke, they did NOT switch to
GroupButtons (or anything else), because they did not want to deal
with configuration scripts and a whole lot of stuff. Basically they
lacked the ability to do complex add-on configuration stuff. The kind
of people who you had to talk through how to unzip the add-on into
their WoW add-on folder, etc. Also, did you read that article I
linked on in my last post? It basically slammed us for being too
complex. The philosophy of allowing those who would normally not use
XUB is what is driving my wanting to design the UI to be "easy to use"
for novices but allow experts to work "under the hood" with it as
well. I didn't want to make things UI wise to complex by trying to do
all things possible, but instead have the default novice mode mimic
what other add-ons in the past did, then allow the expert user to
modify things any way they want, adding new groups and profiles, etc.
Its easy to 'geek out' and design the Mother of All Add-Ons that does
everything we hard-core types would want, but we should try to make
the add-on accessible to those who are not geeks too, but still allow
the geeks to 'geek out' with our add-on.

Having said that, I was hoping of hiding the concept of groups from
the novice user, to be honest, since its not a concept people who used
Benecast and/or GroupButtons would be familiar with. They are
familiar with targets (frames) though.

Just off the top of my head, the thing with having predefined groups
like healing (for example) and such would be that one persons healing
spells is not another persons healing spells. Even amongst my own
chars, my Draenei pally has the racial HOT for himself and all party
members, while my Draenei warrior has it just for himself. Some would
want a USE for bandages and others would not. It would be a nightmare
to auto-populate the groups based on the class of the character using
the add-on. Also, we'd have to have a huge matrix of what spells are
heal spells, which ones are attack, utility, etc. I'd rather have the
human become proficient with XUB and start setting up their own
groups.

Anyway, my $0.02 worth. :)

On Dec 6, 3:31 am, Tayedaen <vogt.mar...@gmail.com> wrote:

[Drome]

On Dec 6, 4:36 pm, Cosmic Cleric <CosmicCle...@gmail.com> wrote:

> Just off the top of my head, the thing with having predefined groups
> like healing (for example) and such would be that one persons healing
> spells is not another persons healing spells.

...

> It would be a nightmare
> to auto-populate the groups based on the class of the character using

I think Tays suggestion is to use predefined groups like Heal, Buff
and
Debuff instead of castonplayer, castonparty, etc. One of the
strengths
of XUB is the re usability that you can get by using groups. So
rewriting
your example:

PROFILES
default
player
Heal
Buff
Debuff
playerpet
target
Heal
Buff
Debuff
Attack
party
Heal
Buff
Debuff
raid
Heal
Debuff
floating

GROUPS
Heal
Buff
Debuff
Attack

and users could copy buttons into the four groups
and the buttons would show up on the units based
on the predefined profiles. To get started teh novice
user would opnly drag spells into the four premade
groups. This could create the following scripts:

groups
Heal,HolyLight,*
Heal,FlashOfLight,*
Buff,BlessingOfMight,*
Buff,BlessingOfWisdom
Debuff,Cleanse,*
Attack,SealOfRetribution,*
Attack,Jundgement,*

profile
default,player,Heal
default,player,Buff
default,player,Debuff
default,party,Heal
default,party,Buff
default,party,Debuff
default,target,Heal
default,target,Buff
default,target,Debuff
default,target,Attack
default,raid,Heal
default,raid,Debuff


So the tradeoff is between starting people down the benefits
to the group concept versus the the easier to understand
direct assignment approach. To choose between them I
would prefer to go the simpler approach and figure out a
way to get the next concept it once they are hooked.

We could look at offering both mechanisms to the new user:

PROFILES
default
player
Heal
Buff
Debuff
castonplayer
playerpet
target
Heal
Buff
Debuff
Attack
castontarget
party
Heal
Buff
Debuff
castonparty
raid
Heal
Debuff
castonraid
floating

GROUPS
Heal
Buff
Debuff
Attack
castonplayer
castonparty
castontarget
castonraid

Drome

[Cosmic Cleric]

Thanks for the reply. Yeah I gathered that is what he was after, and
on the surface is not a bad idea at all.

The issue I could think of is if someone wanted buffs before heals, or
buffs on a separate line from heals for one character but not for
another, etc. Plus, a dps class wouldn't have Heal spells, but if
they didn't manually delete the group (or we added extra code not to
add it for dps classes), then they'd have a space between their
buttons they do not potentially want. These kind of decisions are
more of 'advanced' user mindset than 'novice' user in nature.

I personally know of one person who just wants buttons under target
frames (basically he wants Benecast back), which is why I suggested
creating groups that match the target frames they are attached to, and
users can just drag a button from a spell book and add it to the
player frame, etc. Its the simplest form that a novice user could
understand. If a user wanted more functionality like a heal group,
they could just add the heal group to the profile themselves.

Doing both ways would most likely be even more confusing to a new
user, than choosing one or another. There would be these empty groups
associated with a profile, creating spaces between buttons (if the
configuration has been defined for spaces between button groups).

For both of you, please, take a look at this article...

http://www.wowinsider.com/2007/05/31/the-creamy-gui-center-group-buttons/

The last section talks about XUB. What the writer of the article
speaks towards is what I am trying to combat by making the UI
simplistic but powerful to do. For the novice user groups and
profiles should not even be visible to the user. Let them just drag
buttons to target frames (which under the cover would be groups
associated to the frames). An advance user could add new groups,
delete old groups, and then drag buttons to the groups.

[Elenesski]

I have read the creamy gui article a few weeks ago. He compares XUB's
flexibility to Group Buttons. But the key difference, which is the
reason why I never worked on a graphical UI for XUB in the first place
was that group buttons restricted you to no more than 20 buttons per
unit or 6 buttons per raid unit. I intentionally wanted to make sure
that XUB had no 20 buttons per unit restriction. However, with that
decision I was faced with the daunting task of trying to figure how to
write an editor with scrolling to have an unlimited number of buttons
per unit/group. For example, if you look at the UI component that
scrolls the icons when selecting a macro icon, what I do is I capture
the scroll event and replot all the icons in the window. This is why
I felt overwhelmed by the prospect of trying to recreate a group
editor and profile editor that I could scroll and also support the "OK/
Cancel" capability too.

In practice, I discovered that I rarely created groups with more than
10 buttons. Usually 7-8 was the maximum; I don't know about your
experiences. In retrospect, if there was an artificial limit of say
10 buttons per group and 10 groups per profile, then it would be far
easier to create a UI, because I would completely eliminate the need
to do any kind of scrolling. If some user had some weird necessity to
to create 105 buttons per unit (eww), or more than 10 groups per unit,
then they could use the multiple profile mechanism of "/xub p profile1/
profile2/profile3".

For a button editor, I think the Window1 (from above looks pretty
good), but I'm not sure why you cannot selectively hide/show buttons
to implement the functionality of Window2 on Window1. It would be
easier from a maintenance perspective.

For a group editor, all you need to do is define a text field for the
name (or have a pre-defined list of suggested group names), and have
10 (ish) rows, one for each button in the group. The first column
would be a drop-down with 1 to 10 in it & DELETE. This allows you to
reorder the buttons, so that if you wanted to add a new button into
the 4th position, you could do it without drag-and-drop or having to
do a bunch of clicking and Delete to remove a button in the middle of
the group. Next to it, a drop-down pre-populated with the list of the
character's spells and custom buttons. Perhaps when selected you
could show the Icon for the spell (see below). And another drop-down
of known units "*", "unit1", "focus", "target", etc. with a text
field for really wild custom specifications, such as,
"unit1focustargettarget", etc.

Note: While you suggested drag-and-drop for the spell/button, you
might run into the problem where the Icon doesn't give you enough
information about what you actually specified. For example, how do
you tell the difference between a GreaterHeal, GreaterHealRank4, and a
GreaterHealRank4 which blinks?

For the profile editor, perhaps a text box for the name, and 10 (ish)
lines for each group. Once again a drop-down for unit, drop-down for
the group (which includes CR), and pair of text fields for the offset.

To initialize the Editing UI, you simply read and write the group/
profile to/from the arrays specification. There wouldn't be a need
to rewrite how most of the mod works because it would always still
using the arrays as the basis for constructing the UI.

In my opinion, the biggest problem with XUB is remembering the
syntax. The UI's job is to construct the specification without
needing to know the syntax.

That's my $0.02. Hopefully you don't ignore it because I disappeared
from the game.

I have been thinking about returning.

[Tayedaen]

Hi E.,

thanks for taking part in our discussion.

> For a button editor, I think the Window1 (from above looks pretty
> good), but I'm not sure why you cannot selectively hide/show buttons
> to implement the functionality of Window2 on Window1. It would be
> easier from a maintenance perspective.

Yes, I agree, this could be done.
But to demonstrate the idea I prefered to keep them separate.

> For a group editor, all you need to do is define a text field for the
> name (or have a pre-defined list of suggested group names), and have
> 10 (ish) rows, one for each button in the group. The first column
> would be a drop-down with 1 to 10 in it & DELETE. This allows you to
> reorder the buttons, so that if you wanted to add a new button into
> the 4th position, you could do it without drag-and-drop or having to
> do a bunch of clicking and Delete to remove a button in the middle of
> the group. Next to it, a drop-down pre-populated with the list of the
> character's spells and custom buttons. Perhaps when selected you
> could show the Icon for the spell (see below).

You idea is good, but I think it's too complicated.
I would prefer a double listbox.
On the left, the user sees all his self-defined buttons.
On the right (below the groupname), he has the listbox for the
buttons of this group.
And he can move/reorder them via
">" , ">>" , "<" , "<<" and "Up" and "Down" buttons.

Additionally, we could prefill the left listbox with all spells of his
spellbook, just as simpe "spell" buttons.
And if he chooses one of these button,s we could add this button to
the list of custom buttons, with target "*". ;-)
So when a user just wants to use "simple" buttons, he would never need
to go to window 1.

> And another drop-down of known units "*", "unit1", "focus",
> "target", etc. with a text field for really wild custom
> specifications, such as, "unit1focustargettarget", etc.

I really like 'unit1focustargettarget' ;-)))))))))))))
But I disagree on the destination part:
My plan was to allow different mouseclicks, where different clicks
on one button may target different destinations.
That is the reason why I wanted to keep the destination selection
in window 1.

> Note: While you suggested drag-and-drop for the spell/button, you
> might run into the problem where the Icon doesn't give you enough
> information about what you actually specified. For example, how do
> you tell the difference between a GreaterHeal, GreaterHealRank4, and a
> GreaterHealRank4 which blinks?

I don't know, I've just seen other addons doing it.
But I haven't studied their code yet.
I that's not possible, we could just add a slider next to the drop-in
box, where the user can adjust the rank.
Example: Renew Rank 5 is the maximum the user knows.
We could then populate the slide with (from elft to right):
1 - 2 - 3 - 4 - 5 - max

> For the profile editor, perhaps a text box for the name, and 10 (ish)
> lines for each group. Once again a drop-down for unit, drop-down for
> the group (which includes CR), and pair of text fields for the offset.

Yes, very good. It's kind of similar to the double dropdown list for
groups.

> In my opinion, the biggest problem with XUB is remembering the
> syntax. The UI's job is to construct the specification without
> needing to know the syntax.

Yes, that is the problem.
And with all the modifications I added, the syntax has not become
easier ;-)))

> That's my $0.02. Hopefully you don't ignore it because I disappeared
> from the game.

No, I really appreciate your ideas!

> I have been thinking about returning.

I would be glad to have you back ;-))))))))))

cu
tay

[Elenesski]

I've decided that I will not be returning to the game at this time.
Blizzard hasn't really addressed a lot of the fundamental issues with
the priest class (no CC, no escape mechanisms) among other issues and
they seem to be taking their time in addressing the fundamental issue
of the viability of the priest class in the game. They are planning
on changing the class in the future in advance of the Lich King
release, so I'll wait until they do this before considering rejoining
the game.