Usability Testing and Updates to e-sign Invoice

[kitblake]

When filling in the RContributor Invoice Agreement form, I noticed some usability problems and hit a bug.

• The Ethereum address field is too short. It should display 42 chars: size="42"
• The Reward Voted field should only accept numeric chars.
• Placing a Dollar sign to the left of the Reward Voted field would be a useful hint.
• Displaying placeholder text in the Reward Voted field would mitigate confusion about the amount format: placeholder="1234.56"
• Typically the positive button ("I Agree") is located on the right in order to move forward. The negative button ("I Disagree") should be on the left to indicate non-continuation. Or, the buttons should be stacked, with the most likely course of action ("I Agree") on top.

After clicking the "I Agree" button, a Javascript alert pops up saying:

Data provided doesn't match the values on file.

Afaik the data matches the invoice. This alert appears regardless of what I enter in the Reward Voted field: #### | #,### | ####.## | #,###.## | $####.

Bug: the md5 checksum generated in the Javascript for my ETH address is incorrect.

Since the form can't be submitted due to the alert, I clicked the ("I Disagree") button. The form submitted. It went to invoice.rhobot.net/../disagree and replied "Thank you for contributing!". Maybe it should say "Thank you anyway!".

[motionfactory-digital]

From my side - the process was seamless and worked a charm

[owans]

The process was also smooth on my end

[nonnykul]

The process was Smooth and precise from my end.

[allancto]

@kitblake thanks for your well considered feedback.

1. BUG (fixed): the md5 checksum generated in the Javascript for my ETH address is incorrect.This was indeed a bug. We neglected to treat eth_address as a number and ended up with a case sensitive comparison of text. @kitblake gets extra points for reading the client javascript 👍

2. DESIGN FLAW: there was no positive confirmation of receipt, this will now say something like "Agreed at ". Thanks to @zsluedem.

3. UX amount. The purpose of this field is to positively confirm that you have actually read and are agreeing to the pdf. So i suppose it might say "Please confirm "Total to pay" matches the reward voted for your contributions" rather than "Please agree to the reward voted by entering the amount below". On the other hand it does say "Please check your invoice carefully and confirm the information below." Anyone who has an opinion about this, feel free to speak up!

4. UX eth_address. this is a bit complicated so i'll put it in a separate comment.

5. Button location. Is on the right more typical? Is there a ux design principles or equivalent link you can provide confirming this? we should absolutely conform to standard practice.

6. Popup. This is absolutely lame, you are correct, should be fixed soon. Our design is for sequential enabling of ux elements. We took a shortcut to get this version out more timely.

Thanks! -allancto

[allancto]

@kitblake , about the description of the eth_address text. I agree that it's bad UX, the reason is we haven't found a simple way of describing the purpose of this field.

Here's the purpose. It's a safety check for you. We have had a small but significant number of cases in the past where contributors change eth_addresses for various reasons (expose a private key in a Colab video, for instance). Transmitting to an incorrect eth_address would be problematic. The screening we provide, as you point out written in the javascript, is a simple comparison of the hash you provide against the hash we have on file.

How to communicate this with an intuitive and simple UX? -@allancto

[allancto]

@kitblake , all.

The question has been raised again as to whether language in the board resolution of Jan 25 should be interpreted to protect bounty contributors against rhoc market price fluctuation during the time between contribution pay period and payment processing. I believe that this protection was unintended and we should remove ambiguous language in the invoice form itself.

Here is a draft email I am proposing to seek consensus to change the invoice language to reflect this. Please comment below if you disagree with this email and with making corresponding modifications to the e-sign agreement.

DRAFT Dear Kate and Kenny

The recent market valuation of rhoc has again raised the question of how to interpret the clause referring to "day prior to payment" in the Board resolution of Jan 25, 2018. It's possible the clause was either intended to cover situations other than the bounty system or perhaps was simply a "bug" around which now we have clearer understanding. Our actual practice has been to use the monthly average interpretation for rewards, except for a one time special adjustment on June 20 when the issue was first recognized.

I believe i speak for the vast majority of contributors that using the monthly average is fair, appropriate, and aligns bounty contributors with other holders of rhoc. Setting the rhoc rate to an average price for the month in which contributions were made seems clear and correct. Any adjustment places bounty contributors in a different situation than other rhoc holders, a situation we do not wish.

Going forward I propose we change and simplify the invoice agreement to reflect our actual practice. Attached below is a copy of a proposed invoice format which reflects this. Please let me know if you have any objections to bounty contributors using this simplified format and unambiguously e-signing this rhoc denominated agreement at the monthly average rate.

Thanks!

attached: simplified invoice format reflecting our actual practice by removing text "Exact Units are set by Board at date of payment", "Units (indicative)", and "Coin..Eth".

[allancto]

I sent the email drafted above just now to @kate and @kennyrowe cc @lapin7, representing my understanding that it's the consensus of contributors. I included a reference to this issue and comments. If anyone disagrees that the average price for the month in which contributions were made is appropriate and desirable in order to align your interests with those of fellow members and fellow rhoc holders, please comment below.

Thanks! -@allancto

[dckc]

If this is development, somebody point me to the source code, please.

[whereyouatwimm]

@dckc apologize for the delay, haven't been keeping up with github as much as i should.

https://github.com/whereyouatwimm/rchain-invoice

[dckc]

Thanks for the pointer.

I see no reason to apologize; if I had been in a hurry, I could have found your work via https://github.com/rchain/bounties/issues/912#issuecomment-419293648

[allancto]

@kitblake @zsluedem regarding the bug list above, 1 and 2 are fixed, 3 and 4 didn't seem to cause problems in themselves and will be addressed with better instructions. 6 (feedback via popup) is still being considered (alternative is to gray the agree/disagree). 5 is wont_fix based on investigation into the ux issue (cancel/ok typically follows the continuation pattern, but agree/disagree typically follows the pattern as implemented,

[dckc]

I suggest tweaking the scope (i.e. title) of this issue to something like "usability testing of rchain-invoice".

[dckc]

Has the treasurer started trying this thing out? If so, please summarize the results. If not, please make (and share) plans for that.

[dckc]

@allancto you've contacted the compensation committee, which is the right place for the discussion, but in case anyone only looks here...

I sent the email drafted above just now to @kate and @kennyrowe cc @lapin7, representing my understanding that it's the consensus of contributors. I included a reference to this issue and comments. If anyone disagrees that the average price for the month in which contributions were made is appropriate and desirable in order to align your interests with those of fellow members and fellow rhoc holders, please comment below.

1. Clearly #969 is the more relevant issue; I don't think it's reasonable to expect all bounty system contributors to express their position on USD/RHOC conversion rate for invoices under "usability testing..."
2. There is evidently not a consensus around using the monthly average. @AyAyRon-P disagreed in https://github.com/rchain/bounties/issues/969#issuecomment-422128176 and @barneycinnamon and I argued that the Jan 25 board decision applies until it's changed through due process.

[allancto]

@dckc yes, i created #969 AT_TIME_OF_CONTRIBUTION vs AT_TIME_OF_PAYMENT to have the discussion. It's also true that I sent the email without consensus yet and that's why i raised #969. In that discussion it became clear there was not consensus which i reported and ultimately will result in this question being addressed by the Compensation Committee sometime this week.

Please help me to clarify in any of the channels you may have noticed any miscommunication on my part. Thanks! -@allancto

[allancto]

Work done in September.

• Usability upgrades
  1. @zsluedem06 (positive confirmation) the app now provides a time stamp for signed time.
  2. eth address 42 characters
  3. $ hint as suggested
  4. left/ right research indicated cancel/continue different ux than agree/disagree

• bug fix
  1. eth address case sensitive

Suggested reward: @whereyouatwimm 1200 @allancto 1000

[dckc]

After discussing this with @allancto and some others in the coop who work with budgets in this area, I supported this work with a $2K budget vote, with the expectation that @allancto and @whereyouatwimm will split it.

More to follow under #912 .

reminder: you can do your own reward votes in 201809; see #785 .

Regarding my question above, @allancto wrote in #bounties:

yes Kate has said "I like it" :p.

[dckc]

This looks done.

If it's not please clarify what work is left to do and how we'll measure completion.