Image Designer Archive
Thread: Let's Talk About: The ID UI and Client's Peace of Mind
TechnoCan wrote:
Ok, lets see if we can put our thoughts together a bit.
What is the problem we are looking to solve?
Customers complain, that some IDs not only migrate their stats, but also change other aspects of their avatar they didn't want to have changed. Those changes go unnoticed at first, because either the customer still wears his armor since he only needed a stat migration, because the armor-bug still displayed his armor in the interface or because the unwanted changes are that subtle, that they are not noticed at once.
What criterias should our solution meet?
- The customer needs to be notified of changes, that are done to his avatar
- The changes to the interface should be kept as small as possible so they are easier to implement and players don't have to learn a complete new interface again (IDs and our customers alike)
What possible solutions do we see?
- Maybe the most simple solution would be to add on-screen messages for the customer telling him which part of his avatar is being changed by the ID. PRO: very simple to implement, CONS: Could be overseen easily, difficult to "trigger" (would the message appear with each slider tick? Spam-my!)
- Still pretty simple, but maybe more effective would be to add a list of checkboxes at the side of the customer-ui to show which aspects have been changed. PRO: still pretty simple todo, CONS: could still be overseen pretty easily
- More complext, but more comfortable: when the ID hits commit, the customer gets a popupwindow with a list of all done changes (no hard numbers just a list of the changed bodyparts and where possible comments like 'made larger/smaller/thiner..') PRO: Pretty hard to overlook; give the possibility to maybe reject some of the changes CONS: more complex to implement and likey to just be 'clicked away' by the customer
- A customer-side ui-part to allow the ID to change a bodypart only with aproval of the customer. PRO: Gives control to the customer CONS: would require the ID to explain it nearly every time to the customer, very complex to code that in the ui, just a first step into the direction of degrading the ID to an ID-terminal
What else can be helpfull?
- Fix the Armor-display bug
- Unifying the colorcodes for Tailors/Armorsmiths/Droids/Vehicles/IDs (and whoever else might use a color somewhere)
- Numbers on sliders or other more reliable methods of measuring a setting there.
I hope I didn't forget anything important here.
Message Edited by TechnoCan on 09-13-2004 03:31 PM
Awesome summation. Added some thoughts in purple. Personally, I'm in favor of a combination of 2 and 3, with a slight additional tweak to the commit process to make it more like the secure trade interface.
Syzygy-Gorath wrote:
And for those that can't redon armor unbuffed? Like I said, there are lots of reasons to be wearing armor while being IDed, and we can't easily place the onus on the client in such cases. If there is no reason for the client to take off their armor due to a lack of interest in cosmetic/physical changes, the client should not have to take off their armor.
Ah well, I think we are just going to have to agree to disagree. I am not seeing these "lots of reasons", at least as legitimate ones. Perhaps you listed them but,I was not swayed.
I understand that you may not be able to don your armor if not buffed but, you are going to need to buff that stat for any occasion that is going to require the armor. I also do not think it such a huge thing to ask for that our customers come to us covert and without a helmet. RP wise, it is just plain rude and I do not subscribe to a "oh, it is just RP" mentality that would excuse it.
We should not mess around with appearances because we can. We owe that to our customers. By the same token we have the right to expect that our customers show us the professional courtesy to do what they can to make the whole process run as smooth as possible.
I play combat characters as well and understand the customer side of this too. I have my expectations of my customers and in turn give them the best service I can. If they do not like my prices or expectations, I won't be hurt if they take their business elsewhere.
To get back on track, I hope they do give us a way that customers can be aware of the changes that were made but,I wonder ifit will be heeded. We do not need layer after layer of code, if customers are not going to pay attention and use the protection available to them anyway. We could put a check box after each change and many would just keep checking OK and get burned anyway.
Training customers to be wary and dealing with the griefing offenders will do more to help this than any sort of specific consent system would. All such a system would do is bog down the process and probably cause more frustration and in the end cause customers to hurry through their consent , since the whole process and wait to see an ID took longer than they wanted.
Chasing Amy - Bria
TechnoCan wrote:
I don't think this would work very well... it would slow down the whole process, would require us IDs to explain the whole process over and over again and it would be much more difficult to implement without being really that helpfull. and last but not least it would be the first step to degrade our services to be completely treated like a terminal.
All in all this advance would lead to more trouble than it's worth, especially since there are much easier ways to solve the problem with fewer disadvantages.
I don't see how this would slow it down much...it's only ONE question before the session starts in the samemanner we're using right now. And sincethree checkboxes & a continue button are all that they see at first, there is nothing to get confused over or have to explain over & over. It would not be difficult to implement without being any help...on the contrary, it is extremely simplistic & solves the EXACT problem we are trying tocorrect here in the most efficient & unobtrusive way possible.
And, the first step in degrading us to being "terminals" was already taken whenSOE allowed the customers to adjust the stats in the UI instead of us.
Message Edited by ToppDog on 09-14-2004 07:55 PM
I'm not sure why you would have to start over. The checkboxes at the beginning are a way to get the session started, but their decisions are not locked in place until the session is over. Lets say you had a customer that originally only selected migrations, but after chatting with you a bit he agrees to let you make his chin & jaw look stronger. He would simply click on thephysical appearancebox that he left blank before, & you would now be authorized to perform ID changes on him. It would be very fluid & simplistic,& all part of the same session. You would not have to start all over to redo an eye-color, because all changes would be remembered until the very end where both of youcommit & execute the changes.
Syzygy-Gorath wrote:
…pre-session allow checkboxes are also problematic in that people do change their minds on what they'd like done mid-session, and I for one would prefer not to have to start over simply to change eye color or the like.
ToppDog wrote:
TechnoCan wrote:
I don't think this would work very well... it would slow down the whole process, would require us IDs to explain the whole process over and over again and it would be much more difficult to implement without being really that helpfull. and last but not least it would be the first step to degrade our services to be completely treated like a terminal.
All in all this advance would lead to more trouble than it's worth, especially since there are much easier ways to solve the problem with fewer disadvantages.
I don't see how this would slow it down much...it's only ONE question before the session starts in the samemanner we're using right now. And sincethree checkboxes & a continue button are all that they see at first, there is nothing to get confused over or have to explain over & over. It would not be difficult to implement without being any help...on the contrary, it is extremely simplistic & solves the EXACT problem we are trying tocorrect here in the most efficient & unobtrusive way possible.
And, the first step in degrading us to being "terminals" was already taken whenSOE allowed the customers to adjust the stats in the UI instead of us.
Message Edited by ToppDog on 09-14-2004 07:55 PM
Well I understand that you want to defend your idea, but I think you see this a bit too enthusiastic and shortsighted.
Let's start with my last argument, the degration to just terminals. Yes, the fact that the customers set their own stats might be a step in that direction, but in difference to the changes in appearance the stat-migration is all about hard and exact numbers. But its about numbers that actually only the customer needs to know and should know. The devs don't want others to see the exact settings of another player, atleast for his secondary stats, because PvP is an essential part of the game. If you let the ID now do the changes there, too he/she would have to see those exact numbers on the secondary attributes, too. Why is this dangerous, do you ask? Now think about jedi and bountyhunters. A BH that knows that a jedi has only a very low setting at his/her mind stats would have an unfair advantage over the jedi when it comes to combat... a very small one you would say in the days of very efficient buffs and brandy and the like, but still and advantage... especially since the jedi will rarely know when the bh will seek him out and attack him.
The other changes we do are all about appearance and we don't see the numbers coding them in the system. Players usually don't think in terms like a colorcode or hairstylenumbers. (Well, some do, but that's a minority). So here the dialoge between ID and customers is not only a good way to handle the system but since this is still a role playing game the way it should be and stay.
And the fact that SoE have decided to let the customers remain in control of setting their new stats to migrate to does not mean they WANT us to degrade to mere terminals... and it does not mean that it's a good idea to take another step that will definintly lead into that direction.
Another reason to not use your idea of a customer-side-pre-set-system is, that it has to be the ID to initialize the prozess. Not only because of coding issues. In reality (yes, this strange other universe some of us still live in) I don't go to my hairstylist and activate some button to allow him to cut my hair, I tell him what I want and then HE/SHE starts to cut my hair, asking more questions to see which haircut/stlye I'd like to get or what other services he/she can offer me. (Yes, I know, RL-hairstylists don't use a ui to cut our hair... atleast mine does not)
And last but not least: In your idea the customer starts the process of iding... that would mean, that a) an ID allways has to wait for the often lazy customer to start it... and second would mean that in busy times it would be nearly impossible to build up a working queue of customers... the impatient ones would allways start to spam with id-session-starts and the like or group invites or other stupid stuff, even more than they sometimes do now.
Message Edited by SFXGenesis on 09-15-2004 10:15 AM
Message Edited by SFXGenesis on 09-15-2004 10:15 AM
Message Edited by SFXGenesis on 09-15-2004 10:16 AM
Now that would work. Being able to flip between clothed and not would allow both the ability to match clothing and the need to be able to SEE what changes are being made. I have also often wished that the ID side gave a "before" as well as an "after" view... especially when working on my own characters.
Erann wrote:
The Id session window should display the players avatar in the "naked" view, with the undies so you can see everything. what it isn't I dunno... your guess is as good as mine.. I suppose it is to allow a player to match a look to clothing.. I do that allot I would however like the ability to flip the session between fully clothed and not. it would make things easier.
Technocan, I don't think you understood what I was trying to say in my earlier posts in this thread. It sounded like you were also including other stuff I said in different posts that weren't necessarily meant to be included in this particular discussion.And, if that's because of how I wrote it, then I'm sorry. Just forget whatever I wrote before & I'll start over...
Okay, the main reason of thisthread is to find a way to prevent customers from having unwanted ID changes, right? And this ultimately means the customers have to have some way of cancelling them or preventing them from happening in the first place, right? So, this means the current system HAS to be changed in some way to enable the customers to have that small bit of control. Again, I will say there is absolutely no other way around this...every proposal (including mine) that does not give the customer a way to deny or prevent these unwanted changes is worthless.
Once we all agree that we have to give the customers this ability, the next question is "How?". Some have suggested puttinga safeguardat the beginning of the session, some have proposed putting the old safeguard in the middle with the customer approving each individual change, & some have proposed putting it at the very end. So far, here are the pros & cons of each:
Checkboxes at the beginning:
pros:
1.Immidiately solves the problem of unwanted ID changes by having the customer select which categories the ID is permitted to work in (migrations, emotes, & physical appearance).
2. Does not alter the current function of the new ID system in any way whatsoever other than adding the above function.
3. Offers the flexibility to have the categories changed mid-sessionif the situation changes & the customers either agree to additional work, or desire to cancel work in a current category.
cons:
1. Requires the customer to check the boxes in the desired categories before the session can begin, which may add a minimal amount of time & customer education over the current system.
Customer approval of each change in the middle:
pros:
1. Provides the absolute best type of safeguard for the customers,because itgives the customers complete control to accept or deny each individual change, which forces the customers to be more involved & aware of what those changes are.
cons:
1. Disrupts the free-flowing & fluid nature of the current ID system & turns it into a stop & go affair, which many ID's have expressed they would not like.
List or checkboxes at the end:
pros:
1. Offers customers the ability to review & unckeck any changes they don't want prior to ending the session.
2. Does not alter the current function of the new ID system in any way whatsoever other than adding the above function.
cons:
1. This does not stop the unwanted changes from being made in the first place, but instead places the burden on the customers to scrutinize a list at the very end of the session for errors or malicious changes which they have to either check or un-check to prevent from being executed.
2. Because of the above, more unwanted changes will go through without being noticed due to problems such as the customers forgetting to read the list, etc. than would happen in the other two systems due to their design to have the customers authorize the categories or changes up-front before the session can continue.
Again, we're not really talking about the current UI screen, or numbered sliders& colors, or any other stuff we'd either like to see (or not) that doesn't directly address the issue of unwanted changes...they may be all be a little related to this topic, but they are not necessary to solving the problem at hand & are better left for separate discussions.