Power Auras Classic 5.0
View Single Post
07-22-12, 05:13 PM
A Chromatic Dragonspawn
Join Date: Nov 2010
Warning: This is a literal wall of text.
I'll help you out here
. Now, after reading that feel free to elaborate on the following points, 'cause all I got out of that post was one usable piece of feedback.
The point I got was: GUI too complicated in terms of navigation. I'll cover it in a lot of depth.
Originally Posted by
Where is the logical navigation in using this utility versus its predecessor?
You have to program for the end user in mind, not to pat yourself on the back for making a utility convoluted in it's utility. It loses its function & purpose.
The 'end user' is a terrible term simply because it's too broad. People who like advanced features would ask me to cater to them, people who like the basic stuff would ask me to cater to them instead. Blizzard gets a lot of hate because catering to 10 million people is kinda difficult, and it's still true even with a much smaller figure.
Regarless of this however, the end user is still in mind at all times. The difficulty comes in balancing power with ease of use, and the ugly truth of it is you simply can't have both. You can try, and do a damn good job in the process, but ultimately some things will be sacrificed on either side of the fence. As an example, I'll say that even with the 'advanced' editor you cannot match the power of just outright manually editing the saved variables.
Let's imagine for a second that ease of use and raw power are two fields of grass, right next to each other. The current state of the GUI is what you'd get if you tried to ride a unicycle across the field while juggling pianos and breathing fire.
And that's perfectly fine, because:
alpha quality release
Nothing is final, and all is subject to change. In fact, the reason the GUI is 'complicated' right now is actually a concious decision made for the alpha release. Most people probably won't use, or will very rarely use the 'advanced' features that 5.0 adds, so they'll be sticking to the basic editor tools
which are still under works
But for the sake of testing, we don't want that - an unused system simply gets a lot less interaction and will be subject to far more bugs than a simple one would, and we want to iron out the issues with the advanced systems as a priority. Having the advanced ones work mean that we can safely say, should something go pear-shaped, "oh you'll need to do x and y to get it working, here's how".
In addition, the basic tools need work so that they're easy to use for the average end user, so delaying an alpha release just for them is a bit of a silly idea when we can just slap in a basic tutorial and the words 'alpha', which it would seem that too many people are skipping over.
As for patting myself on the back, I'm curious where you're getting that impression from. Generally that happens after a job well done no? Well we're lacking the critical 'done' point still, and the 'well' point is still somewhere over the hills.
Originally Posted by
I applaud your exceptional skill in coding
Judging from this and the patting on the back, I imagine you view me as some sort of highly conceited egotistical person just out to ruin the addon. I don't do this stuff for kicks and to show off, I can safely assure you of that.
Originally Posted by
but I disgusted by the underlying premise that one has to be perplexed by a simple addon (that is so widely used,) that uses simple logical functions,
Simple? No. While the 'mission statement' of the addon sounds simple (show/hide stuff in response to buffs/debuffs, paraphrasing the description), that was maybe three-four years ago. Simple buff/debuff tracking was the bread and butter, and it grew to house other conditions (pet, combo points, etc.) until the addon became a fully featured kitchen.
The thing is, the 4.x series is comparatively weaker than most alternatives. There's no possible way you can refute that, let's list some of the limitations or great 'user experience' choices that 4.x has:
Basic display types only
: You can have either a texture, or textual string (not both), and a timer/stacks counter per aura. Want both a texture and text display? Make two auras, and either manually duplicate and edit both auras to activate via the same conditions, or use the unintuitive and complicated aura linking system. Now tell me which of those is actually intuitive and isn't a major pain to manage? In addition there's also no support for things like timer bars, which has been requested a lot.
Limited activation conditions
: I want to track my rage when my target's health is <= 30%. Generic execute style aura, yes? Now create it. You'll first need one aura to track one condition, then you'll need to hide or otherwise disable it, and then you'll need to configure the second aura with the other condition, make it look pretty and
link the two using that ID's editbox that isn't even labelled
. Do you realise how many comments we get asking about this type of scenario? Quite a few.
Altering a display in response to something
: This expands upon the previous point, say you want the aura to change colour based upon another condition. Good luck with all the linking and configuring.
Now let's see how 5.0 solves these issues (in order of what was mentioned before):
You can have up to 128 displays of any type. "Wow, now I don't have to link displays. Wait, if I want to, there's dialogs for visually picking the element I'm linking to? Cool, no more guessing ID's!".
You can use the 'basic' activation editor, which
will be functionally the same as the old one
, or the 'advanced' editor which you have now and that allows you to combine up to 63 triggers in order to show a display. I'll also add that user friendliness doesn't involve having 1.5 million controls visible onscreen at once, that's called scaring people, and is something we fixed.
Display actions. 'Nuff said.
And I'll point out the tutorials tab while I'm here. Before you retort with 'if I need a tutorial to use the GUI, then it sucks', I'll happily point out that the contents of the tutorials are actually going to cover a broad spectrum of areas both basic and advanced. And I might even drop the most basic tutorials, simply because they sound
condescending. I do like to imagine our users having the aptitude to at least tie their shoe laces correctly.
Originally Posted by
only b/c you have to prove something to your audience.
Either offer constructive feedback without personal attacks, or get out.
Curiously enough, we have a place where users can submit suggestions and vote on them. Know what the highest upvoted feature is? Changing the styles of displays in response to events. Take a guess as to what the core feature we decided to do all this work for was. Then we expanded on it to match the feature set offered by various alternative addons, and now we're at that point where we can say 'yep'.
To infer that we did all this work just for accolades and to show off is downright insulting, especially when combined with a post from someone who clearly missed the word 'alpha', which has appeared in the first post alone
times, and is even mentioned ingame via that huge changelog dialog which covers a lot of points. One is also led to assume you skipped over that.
Originally Posted by
Are we supposed to traverse the app from left to right, top-down, or a combination of both?
What a mess. What were possibly thinking in this monstrosity in design navigation?
Let's start with the aura list, or the 'browser'. Navigation-wise, the browser is, functionally,
exactly the same
between the two versions, or it at least will be when the missing things get implemented. The visual style is different, and we added a tab for the Layouts feature which may not even make it fully into 5.0 (delayed until 5.1 maybe). Things we changed were removing character/global auras, and adding a toggle between a more compact (icon) view, which is identical to before, and the default list view.
Character/global auras were removed because profile support was another heavily requested feature, and logically we can't keep trans-profile (global) auras in without messy hacks that threaten the stability of parts of the loading code.
Moving on to the editor, that's changed. Completely. So let's begin with the immediate issue.
Tabs at the top will confuse new users. They likely won't know what an action/trigger is, as they're not common terms. A display is pretty straightforward, so that's not an issue. The tutorials tab is hosted in the editor
The immediate and 'simple' fix to this is to hide the top tabs unless the user says they want full power. But let's say we did do that, where would we put the option? We need somewhere obvious that isn't a hunt for the user to find, 'cause that's equally just as bad. We could slap the checkbox on the window, and then it looks ugly and fixes nothing, because now you've got controls sticking out that don't make any sense. We could slap it in the Displays section, but then it's not relevant to the displays. See the issue?
Next up, use of breadcrumbs as the main navigation. Hate to say it, but it's the best choice. We tried
navigation methods, but this was by far the best of the lot.
4.x navigation isn't really 'navigation', it's more "how many controls can we blind the user with at one time". It has one real advantage, it's quick to use if you want to edit one specific thing within ~0.1 second. The downsides on the other hand are fairly numerous; we can't add new features to it simply because there's no space. The window is already far too large, and having half a million controls in your face isn't user friendly. In addition, a lot of the controls are poorly labelled, or completely lack labels, and some of the behaviour is just bizarre.
We tried a treeview approach, whereby the displays were listed on the left inside of a tree and on the right was a tab frame with each tab being dedicated to a specific task (style/activation/animation). This was almost the one we settled on, and was pretty effective. We then moved to the breadcrumb style we have now, and stuck with it for the following reasons:
Less screen real-estate is needed, the treeview was ~170px wide and the rest of the pane was our editor. Even with the current editor size, the end result was it being highly cramped. The breadcrumb system uses a 40px high bar. That's all. And we traded that free space for a usable sidebar with relevant information based upon what you're editing, with help text included.
Expanding on the crampedness, three tabs was all we could fit on the window without risking it overflowing in certain localisations (German is a real schmerz* for this). This meant adding more stuff to the existing tabs, which results in lengthy editor pages with scrollbars and lots of visible controls, or having to introduce collapsible headers which we tried and didn't like.
It didn't end up being any harder to use than the treeview. Arguably, it was easier: the treeview's items were labelled like 'Display #1', and so on. We then categorised it by display type, but that hides the ID numbers which can be used in certain situations. With the breadcrumbs, we moved to a previewable grid so you know what you're picking, because you're visually clicking a miniature preview of it. And if they're too small/large, there's a zoom button in the tray.
Comparing the breadcrumbs and 4.x style navigation has kind of been done, and as I said they both have advantages and issues. One point you could raise is that the breadcrumbs make things too 'distant', and that there's too many clicks to get to a certain section. It's something I'm
aware of, and have been desperately trying to avoid for a while now, however this is an issue that is mostly only prevalent with the 'advanced' editors - simply because 'advanced' things include multiple animation channels, display actions, and complex trigger logic.
The 'basic' editors won't include any form of support for these. In fact, the 'basic' animation editor is going to be completely akin to the existing 4.x one with the whole "single"/"repeat" concept hidden, along with channels.
Coming to the list of categories after selecting a display, we tried various ways of sorting and filtering that list too. Alphabetically is just a 'nice' way of doing it, but is far from ideal. The problem is how do you weigh each area in importance? Style is important, but Activation is what you need to make it show. Animations aren't too important, neither are sounds, but how do they weigh when compared to the advanced features, more or less important? I'd argue that the look and feel is the least important, but there's many people who would disagree when sorting those out.
We could filter them, but going back again I mentioned that
this release is designed to test the advanced components, because we need them to be working.
You aren't going to do a whole lot of testing if I just filter half the categories out, and most people aren't going to read a simple 'please test this', because as has been proven time and time again, people don't read stuff. We cover a lot of 'basic' things in the addon description, yet it still frequently crops up in a comment.
There's a significant amount of things I particularly hate about the current system, most notably I think the Sources system is still a major thorn. It adds a lot of power, but is about as friendly as a hungry shark. We can fix this with the basic editor by simply outright removing it in some way, but that's a
off right now in terms of priorities (in fact, the 'basic' components are quite low on priority until after the next release).
Another thorn in our side is the handling of action 'sequences', but as actions are an advanced feature on purpose it's likely going to be much less of an issue than I'm thinking.
One solution I frequently see is some sort of basic/advanced toggle. We'll be using them, but they'll be used
. For instance, the basic activation editor has one of these toggles for swapping between the basic version and your current advanced one. Basic will automatically become unusable if you create something too advanced for it to handle safely, but otherwise all's good.
Judging from your post, you've seemingly got some ideas (which you chose
to share) on how to tackle navigation so I'll invite you to
give feedback. Simply calling the current system a monstrosity and implying it need to be scrapped immediately is far from constructive. We've tried many systems and settled on these ones, and it'll make a lot more sense why we've done so when all of the editor features are actually implemented.
Jesus, thirty paragraphs...
* Google translate, if it makes no sense blame it, not I.
Last edited by Meorawr : 07-22-12 at
View Public Profile
Send a private message to Meorawr
Find More Posts by Meorawr