Because we like to bother users with all this stuff, haven’t you been paying attention yet? 
I do not see this as ‘bothering’ the user with anything.
We simply use analogies to make users aware of the most important aspect of Grin, which is the need for multiple signatures. Let us not stumble on the exact terminology.
We can describe this to the user as starting a ‘contract’, ‘transaction contract’, ‘drafting a transaction’, or something different all together. The main point is to emphasize the step of letting users collect the necessary signatures to finalize a transaction/contract.
I think some are misunderstanding this proposed change as becoming more complex while the opposite is true IMO.
Just image how Grin++ looks right now, with as addition a column that shows two check-marks on the righ, just like in any messenger APP such as Telegram, Whats-app or Signal. Two check-marks for two signatures, once two out of two are green, it means the transaction is done.
Now image doing a MultiSig of 4 out of 6 , exactly the same look, but with 4 checkmarks because that is the threshold needed to finish broadcast the transaction. Any type of transaction will fit in this model, no matter how many signatures you need.
Instead of calling the “Receive” button “Receive”, we can call it “Sign & Receive”. It makes the user aware that he or she is putting a signature as well as how many out of the required signatures have been collected for any type of transaction. Extra complexity such as ‘RSR’ flow, or ‘SRS’ flow is hidden from the user since it will not matter to him. The user only needs to understand that he needs 2 signatures. Since all messaging APPs work with such as double checkmate system, I think it only makes using Grin easier, not harder for an average Joe.
Added bonus, average Joe will subconsciously become aware of putting signatures. This will make it much easier for average Joe to understand why pressing ‘Cancel transaction’ results in the UI asking him if it is ok to safely cancel the transaction by self spending. This similar to how you retract/unsent a message in any messaging APP. Average Joe will also have much less trouble understanding MultiSig, PayJoin and other complex transactions because he does not need to understand the procedure/transfer-protocol at al. which can become nightmarish complex under the hood if you want for example a no cheating MultiSig, average Joe will only need to understand the signatures/check-marks needed.
So lets not focus on the name ‘contract flow’, lets focus on the simplicity of not letting a user think about transfer protocols and order of steps, but simply about whether he collected enough signatures/check-marks for his transaction. We can always put water by the wine and go for ‘transaction contract’, ‘draft transaction’ or ‘draft contract’ as long as the signature part is there it will means a more simple and generalized concept for Grin transactions/contracts.
1 Like
this is my suggestion:
Draft
Accept
Complete
2 Likes
i think sign is more appropriate than accept/complete (easier to explain safe-cancel + you actually tell them that they’re signing this thing which is what happens behind the scenes). The problem i have with draft is that you don’t accept/sign a draft, you add something so that it’s not a draft anymore, but in this case draft becomes complete only after the last signature
1 Like
Draft has so many different definitions, it even means a check too.
If i were to see draft in this context that’s how I would read it, not like drafting a contract but as in bank draft. Which would be misleading, because the whole point of a bank draft is it’s a check that can’t be cancelled after the first signature.
1 Like
Draft/propose/new/init all seem ok to me. But sign/sign is better than accept/complete IMO
1 Like
Hmmm, Not sure it has “too many” definitions, it can also mean a draft of beer or alcohol. What matters is how it applies as a word in the context it’s being used.
I think either way, either being used to mean a proposal (unfinished) that requires additional modification (signing) or in the case of a bank draft, such as a payment, I don’t think this confuses the user at all. Also checks to do require two signatures, The person issuing the check and then the depositor has to sign it as well.
But that’s just like my opinion of course
I also think “sign” might be more technically appropriate… but hear me out, please… think of it this way… the initial slate is actually a draft, which is a preliminary version of a transaction proposal; this proposal is sent to the recipient, the recipient then can decline or accept the proposal by adding their signature; the sender receives the signed transaction, adds their signature completing the transaction.
I am not sure… my focus is on what it means to add the signature… from the recipient perspective adding their signature means accepting the proposal, but from the sender perspective means completing the transaction, what do you think?
The ability to accept or reject a transaction is why I am in favor of Manual Confirmation, but that’s another topic.
1 Like
If we were using the term draft as in check that would be interesting, because yes checks require two signatures (technically, not always in practice) but I don’t think it’s being proposed here by that definition.
1 Like
pretty cool 
Interesting, but still not something I’d support. Draft as in check is a very uncommon usage.
Doesn’t Lightning network have a lot of similar interactive steps? And a lot more eyes on it. And afaik they have stuck with the term transaction.
i don’t see why we would make a distinction between the signature of one party and the other party
i’m not a native speaker so my understanding of draft was limited. I’ve come across draft in emails etc, so as an unfinished thing only. Maybe my english is not good enough but i doubt non-native speakers will understand draft the way you want it
It’s actually not that uncommon. I used to work at a bank and people frequently used “draft” to mean drafting a check or for flow of money, as in “oh God I overdrafted my account!” Lol
I don’t think everyone is going to agree on everything though. Curious what the next step would be to closing out this matter, or is it just forever in limbo until we find the magical perfect word?
I also want to add that I am sensitive to the international community in effort to make an accessible user experience for all. The term “draft” would be translated into their respective languages?
3 Likes
Overdrafted! A vestigial usage of the term still in use. I think draft for check might still be in use in British English too.
For next steps I would be happy for either OC or whoever’s actually writing the code to make the decision. If they decide on contract I’ll be happy to move on and go with it.
My support is for tx or transaction. Keep it simple and common.
2 Likes
Me neither, I am not a native english speaker. But let me add more context so that you guys can understand what I am basing this on.
I do not know if you are familiar with heuristic evaluation; a heuristic evaluation helps to identify usability issues. Jakob Nielsen is considered the “king of usability”, and there is a list of 10 Usability heuristics by Nielsen. These are used by UI/UX teams all around the world, and they are the next:
- Visibility of system status.
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
I think a “draft” command is self explanatory of what is happening. When the status code of the slate is S1 the slate is actually a draft that includes the sender’s inputs and change output; you are intentionally producing something (a transaction proposal) that will incorporate a result (a transaction).
I like “accept” because it means literally that: the recipient can either accept or just ignore (a sub action) the draft. If the recipient accepts, their signature is added to the the draft and the status code of the slate is now S2, where the recipient has created their outputs(s) and supplied their excess, nonce and partial signature, ready to return to recipient for completion.
When the transaction is “finalized”, the status code is S3 which means that the slate is now complete, contains all inputs, outputs and final signatures, and is ready for posting. That’s why I think “complete” fits better here.
If you are not convinced yet you might be saying now: “sign - sign could be also use here”… keep reading please.
- Match between system and the real world.
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical manner.
My first contra against “Signing” or “Sign” is that when the recipient accepts the transaction draft it is doing more than just adding their signature therefore “Sign” is not completely true. Also “Sign” is used in different contexts in the real world, making the word too subjective.
- User control and freedom.
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
This is something that I think is indirectly related but still important. I think transaction drafts should be accepted manually by default, I think it’s more natural. But in the context of slatepack, the command can be named as “accept” and when the command is called users paste the slatepack message and the wallet should display the transaction information. After reviewing the information, the recipient then confirms that they accept the proposed draft.
The sender call “complete” and also review now the almost finished draft and if everything is OK then the sender “finalizes” or completes the transaction.
I do not see how “Sign - Sign” fits here.
- Consistency and standards.
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow conventions.
This is my last argument against “Sign - Sign”. Besides not being self-explanatory of what is going on (please read more about status codes), also from the receiver’s point of view, “sign” means one thing, but from the sender’s point of view it is something else. “Sign” becomes inconsistent.
-
Error prevention.
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. -
Recognition rather than recall.
Minimize the user’s memory load by making objects, actions, and options visible. -
Flexibility and efficiency of use.
Allow users to tailor frequent actions. -
Aesthetic and minimalist design.
Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. -
Help users recognize, diagnose, and recover from errors.
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
This is applicable because by using more generic words we could be more explicit in explaining to users if something goes wrong in any of the steps of the transaction building process. It cannot be “Sign” because in both cases there is something else going on besides “signing”.
- Help and documentation.
Information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
Explaining the interactivity process like this feels more natural:
First, the sender creates a draft of the transaction. Next, this draft is reviewed by the recipient, when the recipient accepts the draft, the draft with the required information from the recipient is sent back to the sender and the sender completes the transaction and publishes the transaction on the network.
Also Draft - Accept - Complete can be applied to invoices too and when more than two parties are involved. IMO.
Doesn’t it mean the same in both cases?
Namely, add inputs, outputs, kernel offset, and sign?
The initiator is also responsible of broadcasting the transaction. The transaction must also be broadcasted, meaning that the last action also includes posting the transaction, not only “signing” but “signing + broadcasting” = “completing”.
For consistency then, a separate broadcast button/action can be added.
This is already present in Electrum for multi party transactions.
“Draft of a transaction” is not something I think you’d normally see in due to the confusion with Draft’s other payment related definition. If you google the phrase you will get a bunch of results regarding drafts as in payments.
Even if you do understand that it’s Draft as in version of a document, completing or finalizing a draft is still just a draft. A “completed draft of the transaction” would mean to me a complete example of what a potential transaction would look like, not an actually executed transaction.
Oh but I see your idea doesn’t include the repeated command. It’s not draft new, draft accept, draft complete, etc.