Overhaul Commission Information Management

[Hendikins]

/control/editcommissionprices has never been pretty, but it's been left as-is because we've not really had a reason to mess with it. #180 is going to draw attention to it.

Here's how Edit Commission Prices looks on Testing with #180 if you've got classifications and prices set - and you can't change your commission state on that page either (have to use /control/editprofile).

I'm not sure what the best way to deal with this is, although the following ideas have come to mind:

• Moving the commission settings from /control/editprofile and the additional information/preference tags from /control/editcommissionprices to a separate page, and only using /control/editcommissionprices for price editing.
• Using checkboxes and "Remove selected" instead of dropdowns for removing classifications and prices.

[hyena]

One way I could see re-organizing this would be into a lengthy page of stacked sections where every sections has all the inputs you need to perform a particular task. e.g.:

---

"Add a new class (Also creates a base price)"

---

"Create another price for a class"

---

"Edit a cost (green button) or remove it and all its prices (red button)"

---

"Edit a price (green button) or remove it (red button)"

---

"Preferred Tags" and "Opt out tags" (side by side?)

---

Here's a screenshot of some quick template tweaking showing the start of what the first section might look like (ignore the spacing issue I'm debugging): http://i.imgur.com/qbl8ZlT.png

It's not as streamlined on space as it could be, but the intent of this approach is to associate all the inputs required for a particular operation into their own section to maintain an intuitive workflow.

[taedixon]

I've made a quick mockup of my idea, just to show where I'm thinking from personally https://projects.weasyl.com/bin/uploads/67/8f/b0/678fb0145ff94119cf8677ce6614fda3ff5d457d936763c7c8733ff8b641b645.png The presentation is a bit lacking but what I'm going for is kind of an editable representation of the data that's there, and then a preview of what it will look like on the profile. The aim is to take a lot of the guesswork out of price management as well as reducing clicks overall. But right now it takes up way too much space imo so that will need to be pared down.

[taedixon]

https://projects.weasyl.com/bin/uploads/ef/df/69/efdf696e340f5811e71098120f8c1003d4636b78c1ca963ea3ba23e577d6f0d6.png second iteration

[hyena]

Editorializing on that mock up a bit. It's progress but we still have a ways to go:

• The biggest issue is that the flow still feels like a disaster. It's like someone drove a Flex-Box into a CSS factory; there were no survivors.
• The top is getting there. But could be improved: "Additional Information" needs a better name that's less misleading. The preview needs to go on the right not the left since most readers scan from left to right and expect an intuitive progress through the UI in that direction.
• Divisions between functionality need to be clearer to make it obvious which form elements are associated with which task. The headers alone don't do it because the sizes aren't clear and the layout is too much of a mess: It needs HR's imo.
• We could get things into two columns + preview (Which could be narrower than the other two) if 'Add New Price' goes under Existing Commission Price's pull down.
• Is New Commission Type missing a name field?
• The UI seems to suggest one currency per user now. How will we handle those users who have more than one currently?
• Also I see multiple currencies in the preview but no place to select multiple currencies in the UI. Possibly just an oversight?
• Should creating a class should go 'before' editing existing ones? I don't know. It's the more intuitive ordering but maybe we feel that it's the less common task.

[taedixon]

Is New Commission Type missing a name field?

I changed it to use the "dropdown + appearifying input field" to match behaviour of the equivalent field on the Marketplace search

Currencies

I'm still not entirely sure it's necessary to be able to specify multiple currencies but I guess since we've been allowing it and we don't have to remove it they would continue to be specified per. individual prices. I didnt like how adding it would've increased the vertical size of the page a lot but I've thoughts on how i would reconcile that further down. The values in the preview are leftover from other testing data.

Should creating a class should go 'before' editing existing ones? I don't know. It's the more intuitive ordering but maybe we feel that it's the less common task.

I think most commonly people will be adding/removing/editing prices rather than classes, since I imagine "what I do" may not change as often as "how I do it / how much I charge" etc. So it would make more sense to have those be most accessible especially since as of now each edit requires a pageload, more or less.

"Additional Information" needs a better name that's less misleading.

I don't have any clever ideas for this yet

We could get things into two columns + preview (Which could be narrower than the other two) if 'Add New Price' goes under Existing Commission Price's pull down.

I've actually flipped back to wanting to adopt some variation of the original 3-column view myself, for a couple reasons. Primarily being that I think the Description / Additional Info might actually need to be in a column of its own, because some people tend to write quite a fair bit of content in there and the fact that that input field has no height limit AND it has an equal-or-greater sized preview thing underneath it, it can become quite large. I think it's probably sensible to otherwise keep the layout of the top section the same, just rotated 90 degrees and pushed over to the right.

With the other column(s), I figure it might make sense to actually do a smarter version of the original layout's "pick a thing to modify from the dropdown", only the dropdown would instead reveal the prepopulated fields like my previous proposals. This way we only have one set of each relevant control onscreen at a time. If you're having a hard time imagining it that's fine, because I am too, but I will create a crude drawing of what I mean in a little bit that might.. help.. maybe..

[taedixon]

no existing type selected https://projects.weasyl.com/bin/uploads/7c/e4/5f/7ce45f77858c76581d18bb21adfaedca288f03e7cd6b700dfaf3d7eb9b8a915d.png

existing type selected expanding prices under that type with a price selected (the most number of form elements) https://projects.weasyl.com/bin/uploads/f9/08/d2/f908d23954978cfc2d84a4cf6869ef57756fc13783b021e60e315eee9110b8fd.png

q: why is the middle column empty in the first shot a: because I didn't plan ahead

[taedixon]

or maybe just

[taedixon]

Thoughts on Hyena's layout proposal: https://github.com/taedixon/weasyl/pull/3

• I think the flow of this is probably the easiest to follow out of what we've got so far but I feel like we shouldn't even show the create price / edit class sections until we have at least one class, because they aren't useful otherwise
• the "pick & populate" method for editing is really annoying so if we do stay with that I would want to at least have a javascript thing to autopopulate with existing data or something similar. I don't think this is an unreasonable thing to accomplish.
• The preview has been omitted in this layout but I imagine it would go beneath the tags or something?
• Classes don't (currently) have a title that's distinct from its "preset/custom classname" so that extra field isnt actually necessary. Removing the extra fields will really throw off the left/right balance of the "Edit" section though.
• I think cost type should be just a checkbox because a two-option combobox is silly and I don't forsee any more cost types arising in the immediate future.
• echoing your sentiments about the vastness of the layout (the stacked full-width text inputs that will most likely hold 1-3 words feels particularly wasteful) but I had the same problem with my own attempts so I haven't really got a genius idea to solve that right now

Overall I think though something like an "in-place editable preview" might be the nicest option but probably out of our grasp if we want a timely release. i think what you've presented can be made to work at least in the short term with a few important adjustments:

• add in the preview so users can see the effect of their actions
• auto-populate fields when selecting from the dropdown to cut down on repetitive data entry
• don't show sections of the layout that can't be used

[hyena]

Thanks for the reply and summarizing the adjustments as a todo-list. Some comments:

I feel like we shouldn't even show the create price / edit class sections until we have at least one class, because they aren't useful otherwise

Agreed. They're shown here for completeness but in a real patch, they'd be wrapped in $if statements within the template.

would want to at least have a javascript thing to autopopulate with existing data or something similar. I don't think this is an unreasonable thing to accomplish.

It isn't with reasonable jquery, I think. At a bare minimum, it would be nice if selecting a class from a pull down filled in the price fields, say. Or a price filling in its minimum/maximum currency. We'd have to decide how we'd store the data. Do we have another example of how we've done this (well) in the codebase?

The preview has been omitted in this layout but I imagine it would go beneath the tags or something?

Not sure yet. Probably. Maybe give it the entire right third of the layout and stack it below tags for narrow views?

Classes don't (currently) have a title that's distinct from its "preset/custom classname" so that extra field isnt actually necessary.

So 'editing' a class really means moving all its prices below a different category?

I think cost type should be just a checkbox because a two-option combobox is silly and I don't forsee any more cost types arising in the immediate future.

I was thinking a radio button for minimum ambiguity.

[taedixon]

So 'editing' a class really means moving all its prices below a different category?

That's one way of looking at it, I'd call it "renaming the category" though. But yeah, classes don't really have a lot of metadata associated with them at the moment. Just more of a named container for prices.

I was thinking a radio button for minimum ambiguity.

That's good too

Not sure yet. Probably. Maybe give it the entire right third of the layout and stack it below tags for narrow views?

The right third of the top row, I presume. Maybe, depends whether we want to take that space away from the description which would force it to take up more vertical space. Maybe 50% description, 50% tags/preview?

We'd have to decide how we'd store the data. Do we have another example of how we've done this (well) in the codebase?

Not that I can think of, or at least not for something like this. One idea I had was to actually just include the pre-populated fields as hidden elements in the DOM and then just reveal the appropriate item on selection. possibly similar to how the "Find" field on the search page makes relevant sections appear or disappear. link to "full" search page for convenience