Image Designer Archive
Thread: Let's Talk About: The ID UI and Client's Peace of Mind
This seems like a step backwards, given that one of the big advantages of the new system is realtime client-side updates. Having to keep clicking a "do you like it?" button just seems like it would get really annoying, really fast.
ToppDog wrote:
Na, I meant to incorporate how we used to do it before this whole new UI came to be. Lets say we agreed to do some ID for a customer...we would click on the radial to initiate a session & the customer would do the same to accept the session. We would be able to chat during the whole process like before to figure out what the customer wants. Ifthey only want Migration thenthey dotheir thing & we wait for the timer to run out, but ifthey want a "real" ID change, thenthey can tell you want they want or you can make suggestions, etc. Once you actually make a change forthem to see, you press commit (just like the old way) & they will decide ifthey like it or not & can press "accept this change" or "deny this change" for each option you offer, such as weight, height, hairstyle, etc. Only at the end of the timer (or even later if you are doing along makeover) will you both agree that you are finished with the session & each click on a totally different button that wll make all the agreed to changes final & transfer the agreed to price & completely end the session.
Syzygy-Gorath wrote:
This seems like a step backwards, given that one of the big advantages of the new system is realtime client-side updates. Having to keep clicking a "do you like it?" button just seems like it would get really annoying, really fast.
I don't understandwhat you mean bythe client-side real time update comment. I see no difference in this. In the old system your customers could see the changes before accepting them, just as in the new system...And in the old system the changes did not become finalized until the customer clicked accept, just like in the new system. The only differences in the new systemover the old system in these respects is in theuse of a static timer to replace mind usage & introducing a secure method of payment.
I do not see allowing the customer to still view & accept all the changes individually as a step backwards, but merely as a way of incorporating some of the useful parts of the old system to make up for the lack thereof in the new system. If we do not want to be bothered by interacting with our customers while at the same time providing them a way to not be changed without their consent, then we may as well make ID work the same way as the Stat Migration currently does & let the customer make all their own adjustments & just wait till the timer runs out. I have a feeling nobody here would be happy with that alternative though...I know I would not.
Maybe having the customers choose the TYPE of ID session would partly solve this. If they click at the beginning that they want a Stat Migration & don't click on Holo-Emotes or ID Changes, then the ID wouldn't be permitted to make those changes in the first place.
But I'm still not sure how you would prevent unwanted ID changes during an actual ID session unless there was some way for the customers to actually know& approve of thechanges you were making. This has to either be done by the players ahead of time by clicking check boxes of each individual change you are allowed to adjust, or by letting them approve or deny these individual changes after you make the suggestion. I really see no other way around this that is fair & safe for both sides of the ID chair.
Message Edited by ToppDog on 09-11-2004 05:46 PM
Syzygy-Gorath wrote:
Maybe I'm misunderstanding what you mean. The way I read your proposal an ID session would work like this:
Client asks for heigt, weight, hair color, hair style, and eye color change. We group, and I begin the modifications. In order for the changes that I make to be included in the client's view, and to be finally committed, I have to click a 'suggest' button which they can then accept or deny. So, I change height and click 'suggest,' and the client says no, taller. I make him taller and click 'suggest' again. Et cetera ad infinitum.
Now, if this is what you mean then yes, I do think it's a step backwards. The current free-flowing system is far more organic for both image design and client. On the other hand, if this isn't what you mean I apologize, and really have no idea what it is you're suggesting, so if you could break it down for me I'd apreciate it.
One other thing, there is a third choice for approval: you can either do it before, during, or after—and if I'm reading you right, I think the after is what you missed. Which is what the manifest suggestion was intended to cover, as well as a great post-commit checklist suggestion (apologies to the author, I've forgotten who suggested it.) Either way, I see an all-at-once approval approach to be far less irritating than a one-at-a-time, as-they're-suggested approach.
Okay, I've tried responding to this three times & kept getting new thoughts that made me rewritemy post. I finally had what I wanted to say & clicked submit & it went poof...Damn you SOE !!! 
Anyway, I did (past tense) mean to have the customers click each time. But this was because it really is the most effective way to make sure the customers are fully aware of what is happening to them, when it is happening to them...even if it is more restrictive & less convenient for us ID's.
After more thought on it though, I agree that with respect to the increased freedom allowed to ID's, the old way is a step backwards. But the new system is also a step backwards in regards to customer awareness. So where do we go from here? Hmm...
I do like the idea of the checklist for theafterpart, & didn't miss it. I just felt that having the safeguard only at the end would still cause us problems for the following two reasons:
1. The customers may accidently press the accept button before getting a chance to read the list & only find out later of the changes, prompting more postings on the subject in these forums.
2. If the customers do read the list at the end of the session & only then notice something they don't want, you have basically wasted your time waiting for the timer to count down & now have to spend extra time after the timer has expired redoing changes until your customersare happy.
This is why I thought having the customers going back to the old system of accepting each change would work better as far as the customers being completely aware of all changes.
But, a better solution for us as well as our customers may be to put in safeguards both at the beginning & the end of the sessions, leaving the during part "as is" to retain the freedom & convenience of the new system.
This could be as simple as having three checkboxes in the customers UI to represent the three main focuses of ID - migrations, emotes, & ID changes. The customers would check the ones that applybefore the ID could begin the session. After that the ID can perform changes in the manner currently allowed, but only if the customers have clicked that checkbox first, giving them permission. The three checkboxes would remain in the UI so that the customerscould change their mind if they wish & select additional boxes allowing the ID to do additional work that they both agree to. At the end the customers would get the final checklist to view over & can either deny certain changes by checking them off, or have the ID redo them to tweakthem some more.
Anyway, that's the jist of what I tried posting earlier...gotta remember to highlight & copy EVERY time, hehe.
Rrowann wrote:
I saw an idea for a changing room for a tailor, where the room would be linked to what boxes a tailor had, so a customer could go in, pick his or her own outfit, and then the Tailor would get a sort of order for it. I thought it was cool. But in the end, I think picking clothes is for people to do with Tailors, not ID's.
The last thing I want to be approached for is to stand around and be a hypothetical changing room while someone tries to decide what shade of brown his leather coat should be when he has it custom-made.
Addendum to my previous post: just realized that simply dropping the ID and client back to the UI won't help. There would need to be per-slider/picker revert buttons to cancel individual changes, unless the manifest presented a checklist that would allow the client to revert specific features while denying the overall package (note: I do not like the idea of a client checklist. Better to have them explain which bits they want reverted than have them click the wrong thing through lack of familiarity with the UI.)
Rrowann wrote:
Syzygy-Gorath wrote:
Okay, what about this:
Add a checkbox to both sides of the interface called 'accept.' This would work in much the same way as the secure trade accept checkbox, and would allow the 'commit' button to be clicked once both 'accept' checkboxes had been checked. Once the image designer clicks 'commit' the manifest pops up and the client may either accept or deny the changes. If the changes are denied the UI does not close. Instead, it drops back to the interface, unchecking both 'accept' checkboxes to allow for further modifications without additional time requirements.
Much as I would very much like to see the ID UI stay up until both parties had accepted the changes like the trade window, I think this doesn'taddress the issue -- the issuebeing that people in armor helmets find their heads rearranged when they take off their helmet later.
Well, that's what the manifest is for. They expect to see 'migration,' instead they see 'migration, nose protrusion, eye shape, eye angle, et cetera.' At this point they say "Whoa, hey now, what do you think you're doing?"
But really, I'm wondering how much of a problem this facial rearranging actually is. We've suggested things to make the client aware of the changes going on, but I'm wondering if most of this argument is driven by our rampant general outrage that some schmucks out there think it's okay to rearrange other peoples' avatars when they can't tell. How many people have actually run into this? How big a problem is it really?
Good question. Personally, I think you may be right about the outrage thing, but those few smacktards can give our whole profession a bad name, and if we can have something done to help prevent that I'm all for it.
Even client notifications won't save clients who aren't paying attention to the checkboxes. How often have you done a stat migration to have the customer go afk in the middle of it so that you need to send him a /tell when it's done. At that point they're just looking to finish up, they're not fearfully inspecting their characters to see if anything's been rearranged -- if they were really worried about that they'd've taken their helmets off in the first place.
Again, that's the point of the manifest. Something obvious staring them in the face that they don't need to hunt for and verify.
I like that a lot! I'm assuming this would be what both parties would see & dotowards the end of the session? I would still like to see something like this complimented by a change to the UI at the start of the session where the customers click the boxes to tell us what kind of services they are requesting. The two safeguards together should improve things immensely.
Syzygy-Gorath wrote:
Okay, what about this:
Add a checkbox to both sides of the interface called 'accept.' This would work in much the same way as the secure trade accept checkbox, and would allow the 'commit' button to be clicked once both 'accept' checkboxes had been checked. Once the image designer clicks 'commit' the manifest pops up and the client may either accept or deny the changes. If the changes are denied the UI does not close. Instead, it drops back to the interface, unchecking both 'accept' checkboxes to allow for further modifications without additional time requirements.
Syzygy-Gorath wrote:
Okay, what about this:
Add a checkbox to both sides of the interface called 'accept.' This would work in much the same way as the secure trade accept checkbox, and would allow the 'commit' button to be clicked once both 'accept' checkboxes had been checked. Once the image designer clicks 'commit' the manifest pops up and the client may either accept or deny the changes. If the changes are denied the UI does not close. Instead, it drops back to the interface, unchecking both 'accept' checkboxes to allow for further modifications without additional time requirements.
Much as I would very much like to see the ID UI stay up until both parties had accepted the changes like the trade window, I think this doesn'taddress the issue -- the issuebeing that people in armor helmets find their heads rearranged when they take off their helmet later.
But really, I'm wondering how much of a problem this facial rearranging actually is. We've suggested things to make the client aware of the changes going on, but I'm wondering if most of this argument is driven by our rampant general outrage that some schmucks out there think it's okay to rearrange other peoples' avatars when they can't tell. How many people have actually run into this? How big a problem is it really?
Even client notifications won't save clients who aren't paying attention to the checkboxes. How often have you done a stat migration to have the customer go afk in the middle of it so that you need to send him a /tell when it's done. At that point they're just looking to finish up, they're not fearfully inspecting their characters to see if anything's been rearranged -- if they were really worried about that they'd've taken their helmets off in the first place.
Syzygy-Gorath wrote:
As I said in the other thread, there are more reasons than simply a bug to have armor display during an ID session. Clients should not have to take off their armor when they neither want nor expect cosmetic/physical changes.
Syzygy-Gorath wrote:
Addendum to my previous post: just realized that simply dropping the ID and client back to the UI won't help. There would need to be per-slider/picker revert buttons to cancel individual changes, unless the manifest presented a checklist that would allow the client to revert specific features while denying the overall package (note: I do not like the idea of a client checklist. Better to have them explain which bits they want reverted than have them click the wrong thing through lack of familiarity with the UI.)
Personally I do not like checkboxes either even though I suggested it. I just don't like the idea of the entire profession being hurt by a few people who are having fun rearranging other people's faces. It *should* be sufficient just to fix the armor bug so that people can actually see themselves in an ID session and for the image designer (or the interface) to give a strong warning that they should carefully examine all parts of their character before they click accept because once they do it all changes will bemade and anything they want changed after that will be their responsibility. This depends completely on whether this armor bug can be fixed quickly or whether it will be like the neckalce bug for tailors and hang around for a year, though.
As I said in the other thread, there are more reasons than simply a bug to have armor display during an ID session. Clients should not have to take off their armor when they neither want nor expect cosmetic/physical changes.
Gyopi wrote:
Syzygy-Gorath wrote:
Addendum to my previous post: just realized that simply dropping the ID and client back to the UI won't help. There would need to be per-slider/picker revert buttons to cancel individual changes, unless the manifest presented a checklist that would allow the client to revert specific features while denying the overall package (note: I do not like the idea of a client checklist. Better to have them explain which bits they want reverted than have them click the wrong thing through lack of familiarity with the UI.)
Personally I do not like checkboxes either even though I suggested it. I just don't like the idea of the entire profession being hurt by a few people who are having fun rearranging other people's faces. It *should* be sufficient just to fix the armor bug so that people can actually see themselves in an ID session and for the image designer (or the interface) to give a strong warning that they should carefully examine all parts of their character before they click accept because once they do it all changes will bemade and anything they want changed after that will be their responsibility. This depends completely on whether this armor bug can be fixed quickly or whether it will be like the neckalce bug for tailors and hang around for a year, though.
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.
SakeO wrote:
Syzygy-Gorath wrote:
As I said in the other thread, there are more reasons than simply a bug to have armor display during an ID session. Clients should not have to take off their armor when they neither want nor expect cosmetic/physical changes.
Since most of the changes revolve around the head or can be noted in armor, we are basically only talking about removing your helmet. When functioning properly, you only need to remove your helmet till the session starts and then don it again. If you are not in a safe enough place to remove your helmet for a few seconds, you probably should not be getting IDed
Chasing Amy - Bria
- 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
- 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