Open Rhime-design opened 6 years ago
A method for eradicating GOX due to mistakes in authentication number in Deposit to exchanges for NEM / XEM.
認証番号忘れと暗号化によるGOXをなくしたい。 そのための修正案。
暗号化メッセージと認証番号忘れによる取引所GOXを、UIデザインというアプローチから撲滅するためのフロー修正をRaccoonに取り入れる。
取引所へのXEM入金時に、多くの場合NEMのメッセージ機能を使った認証方法が取られている。 しかし認証番号を添付する際、メッセージを暗号化すると、おそらく大体の取引所のシステムが複合処理を行って認証するまでのシステムを組み込んでいない場合が多く、ブロックチェーン上では送金が完了しているものの取引所上でDepositが正常に完了せずにGOXするケースが多く見られる。
この場合、ブロックチェーン上では正常に通貨移転が完了しているため、対応できるのはDeposit先の取引所のみとなり、ユーザーはサポートに連絡し、スタッフによる救済措置を待つしかなくなる。
多くの場合、暗号通貨取引所のサポートは局所的なバブルを経た今でも対応が遅いことがあり、NEM/XEMを取り扱うソフトウェア開発者と関係者は、このような原因からGOXしてしまったあとの対処法への周知ではなく、事前の問題発生を起こらないようにすることが必要である。
「メッセージを添付しますか?」No/Yes 「メッセージを暗号化しますか?」No/Yes
これではミスを引き起こす操作が可能。 結果、これは悪いUI。
修正は、取引所への送金と個人宛の送金の2つに分けることから始める。 それから、送金手続き時にユーザーに選択カードを提示して、送金先がどちらなのかという選択を必須にする。
もし選択された送金先が個人宛の場合、可能なメッセージ機能:
もし選択された送金先が取引所の場合、可能なメッセージ機能:
また認証番号のGOXについては、そもそも認証番号を入力し忘れるミスも多く見られる。 そのため取引所への入金を選択したユーザーには、その入金手続きに認証番号が必要かどうかを確認させるステップを設ける。
ここでYesが選択された場合、可能なメッセージ機能は通常のみになり、最終的な選択が導かれる。
通常
QRコード読み取り時、情報が加えられていた場合
※QRコードにメッセージの暗号化を指定することは可能なのか?について確認が必要。 暗号化事前指定が可能で、かつユーザーが取引所送金を選択した条件が発生した場合、エラーを返す。この場合、勧告ではなく、操作続行不可とする。
ここまでは取引所宛てが選択されたときの想定だった。 個人宛が選択されたときは、
この時はじめて、上で示したようなYes/No方式のメッセージ添付UIが正しく機能する。
こうした配慮をステップ・バイ・ステップで実装すると、当たり前だがステップが増える。 この場合、Toolbar下部あたりにStepperを導入するといいと思う。
Poor:配慮一切なし Better:勧告あり Best:そもそもミスができない🎉
まだ作っていないので、あとでコメントします( ੭๑・ᴗ〃 )੭
概要
A method for eradicating GOX due to mistakes in authentication number in Deposit to exchanges for NEM / XEM.
認証番号忘れと暗号化によるGOXをなくしたい。 そのための修正案。
暗号化メッセージと認証番号忘れによる取引所GOXを、UIデザインというアプローチから撲滅するためのフロー修正をRaccoonに取り入れる。
問題点
取引所へのXEM入金時に、多くの場合NEMのメッセージ機能を使った認証方法が取られている。 しかし認証番号を添付する際、メッセージを暗号化すると、おそらく大体の取引所のシステムが複合処理を行って認証するまでのシステムを組み込んでいない場合が多く、ブロックチェーン上では送金が完了しているものの取引所上でDepositが正常に完了せずにGOXするケースが多く見られる。
この場合、ブロックチェーン上では正常に通貨移転が完了しているため、対応できるのはDeposit先の取引所のみとなり、ユーザーはサポートに連絡し、スタッフによる救済措置を待つしかなくなる。
多くの場合、暗号通貨取引所のサポートは局所的なバブルを経た今でも対応が遅いことがあり、NEM/XEMを取り扱うソフトウェア開発者と関係者は、このような原因からGOXしてしまったあとの対処法への周知ではなく、事前の問題発生を起こらないようにすることが必要である。
現在のRaccoonにおけるデザイン上のUI
「メッセージを添付しますか?」No/Yes 「メッセージを暗号化しますか?」No/Yes
これではミスを引き起こす操作が可能。 結果、これは悪いUI。
修正
修正は、取引所への送金と個人宛の送金の2つに分けることから始める。 それから、送金手続き時にユーザーに選択カードを提示して、送金先がどちらなのかという選択を必須にする。
もし選択された送金先が個人宛の場合、可能なメッセージ機能:
もし選択された送金先が取引所の場合、可能なメッセージ機能:
認証番号忘れのGOXへの対策
また認証番号のGOXについては、そもそも認証番号を入力し忘れるミスも多く見られる。 そのため取引所への入金を選択したユーザーには、その入金手続きに認証番号が必要かどうかを確認させるステップを設ける。
ここでYesが選択された場合、可能なメッセージ機能は
通常
のみになり、最終的な選択が導かれる。追記:QRコード読み取り時の動作
QRコード読み取り時、情報が加えられていた場合
※QRコードにメッセージの暗号化を指定することは可能なのか?について確認が必要。 暗号化事前指定が可能で、かつユーザーが取引所送金を選択した条件が発生した場合、エラーを返す。この場合、勧告ではなく、操作続行不可とする。
追記:個人宛のメッセージ選択
ここまでは取引所宛てが選択されたときの想定だった。 個人宛が選択されたときは、
この時はじめて、上で示したようなYes/No方式のメッセージ添付UIが正しく機能する。
更に良くするには
こうした配慮をステップ・バイ・ステップで実装すると、当たり前だがステップが増える。 この場合、Toolbar下部あたりにStepperを導入するといいと思う。
アプローチの本質
Poor:配慮一切なし Better:勧告あり Best:そもそもミスができない🎉
実際の修正案
まだ作っていないので、あとでコメントします( ੭๑・ᴗ〃 )੭