|
|
The design talks about "coupons". What about subscriptions? |
|
|
coupons here is generalization of discounts and subscriptions. Do you think it is better to use "Applied discounts/subscriptions" and "Issues discounts/subscriptions"? |
|
|
That's fine, as long as it is clear for the developers that both types are meant here. Related issue is probably that there could be multiple coupons needed (collect 10 coupons, get one product for free). I don't see a counter in the design. |
|
|
Oh, and what happens if coupons are to be combined? (Multiple inputs, multiple outputs?). The current design seems to limit to only 1 coupon. |
|
|
For multiple selection spa uses this design everywhere, and we can extend it to quantity. image.png (15,974 bytes) v1_search.jpg (35,650 bytes) |
|
|
order creation has input tokens and output tokens. applied coupons is for which of them? applied is in past, so those are applied to the order to be created, right? your design only shows discounts but you are saying that coupons also work for the suscription use case? how is this going to be rendered? |
|
|
Applied coupons = input tokens Issued coupons = output tokens Applied coupons were issued coupons in previous orders, so the buyer already has in his wallet these "applied coupons" and after purchase will receive "issued coupons" I just showed a search example on discounts; it works the same for subscription, but without quantity selection. |
|
|
I still have doubts that what is written here is enough to decide all the possible outcomes and details for orders ant templates v1. I will list all my question and we can talk in the next wallet ux session. |
|
|
IMO before just implementing "something" here, we need more clarity on why we're doing it / who we're doing it for. As far as I can tell, this was supposed to cover the developer/expert UI. Thus we don't need to hide the underlying technical concepts, we can just call it "input tokens" and "output tokens" For templates, this certainly somewhat makes sense: It allows us to easily configure advanced templates (possibly on behalf of a customer!) without needing to fumble around with JSON and without needing an API key. But what about order creation? Order creation via the merchant portal is very niche in the first place, and I don't see a use case for us other than testing (say, the wallets). And for that, we can just use the API / have some taler-harness tooling to make it easier. |
|
|
Well, with respect to choices (inputs/outputs) orders and templates are basically equal: they both technically support exactly the same feature set. So I would expect that the SPA (with the "right" personality) offers the same options for both. Also because the SPA is supposed to show devs how to use the API. Plus, if it is a nice UX for templates (which we expect normal users to use!), then it also should be a nice UX for orders (even if that's likely too much in practice for a one-off order to type in). That said, I could even see a case where a merchant decides that they need a one-off order to say award tokens (or a subscription) to a customer. Here, they could just create an order with price 0 and the desired output tokens to pacify/reward the customer. That's a one-off case (certainly not one for a template) where manual order creation with output tokens could make a lot of sense. |
|
|
In the latest wallet meeting we talked about this implementation and decided that this will not cover any use cases for users outside expert users. Any merchant will be expected to be guided by someone who understand the usage. So I will change the title "for testing purpose" to make this clear. Given this scope, it is enough to have a family token selector for input tokens and a family token selector for output tokens. Both + price will make a "choice". And the template and order should be able to have multiple choices. The semantic of discount (and the respective price) or subscription will be managed and configured by the user. |
- Anonymous
