新機能をだしました

新機能を出したら開発ブログで何か書く、というのが自分のルーティンになりつつありますが、先日、表計算ソフトからのコピー＆ペースト機能を追加しました。

www.misoca.jp

Excelなどからコピーして、Misocaでペタッと貼り付けると一気に明細が作れるというもので、先日開発ブログに書いた電卓機能*1と同じく、こちらも4月に実施された開発合宿の成果物がベースになっています。

とはいえ合宿の成果物でいきなりゴールしたわけではなく、リリースまでにかなりのブラッシュアップを行いました。

というわけで今回は、開発合宿の限られた時間で一人で作った機能が、新機能として正式に提供されるためにどのように磨かれていったかをご紹介したいと思います。

合宿終了時点での成果物

まず、合宿が終わった時点での状態がこちらです。特に誰とも相談せず、思いつくままガッと実装した形です。

f:id:mugi1:20190808171413g:plain — 合宿終了時点の動作イメージ

行列の移動がCSSアニメーションでヌルヌル動く(合宿の成果発表時のインパクトのために作ったのは否めない)
タブ区切り、カンマ区切りの両方に対応できる
実は全項目編集できる

などが特徴です。

UI/UXを練る

これをベースに、まずは「使いやすいUI/UXはどんなものだろう？」というのを、デザイナーの@kanizmbを中心に一緒に練ります。すると、色々と現状のままではイケてない部分が見えてきました。

列移動がパズル状態になる

貼り付けたデータの列をどの項目に挿入するかを選択するのに、ボタンをクリックでの列と列を入れ替えることで実現していました。見た目はヌルヌル動いてオシャレですが、実際やってみると動かしたい列の隣の列も動いてしまうので、まったく直感的ではなく、かなり混乱します。

f:id:mugi1:20190808174654g:plain — 列移動のややこしさに悶絶する図

まるでスライドパズルを解いているような気分に陥ります。

何かほかの方法で列と明細項目の紐付けが必要だな〜という話になりました。

横スクロールがつらい

表計算ソフトで作られた文書の場合、レイアウト調整などの理由から、必要のない列がデータ間に多く含まれる可能性が考えられます。（いわゆる 'Excel方眼紙' などの場合は特に顕著でしょう。）

そういったデータから貼り付けたい場合、大きく横スクロールが発生する可能性があります。

f:id:mugi1:20190808173139p:plain — 横スクロールが発生して困る図

トラックパッドなどが利用できればよいですが、そうではない場合なかなかの使いづらさです。

UI/UXを見直した後のイメージ

ほかにも様々な観点からUIを見直し、次のような修正をすることで方針を固めました。

"列に対してプルダウンから項目を割り当てる"という形に変更する
- 「このデータは数量だな〜」→「項目は数量を選ぼう」という操作ができた方が直感的
行の移動はドラッグアンドドロップでの移動に変更する
- 文書の明細行並べ替えUIと揃えて、操作感を統一する
ひと目で可能な操作がわかるようにする
- 削除ボタンはマウスホバーせずとも常に表示して、行・列の削除できることがわかるように
- 既存の画面で可能な操作（並び替えや削除）とUIを揃える
- 並び替えや削除の範囲が明確になるようにレイアウトを調整する
多すぎる列のデータはグレーアウトして削除だけ可能にする
- まず不要な列を削除する、という操作をすることで横スクロールを回避する
Misocaのアプリケーション全体と見た目を揃える

これらを含め、修正前に一度イメージを共有し、関係者で認識のズレがないことを確認します。

f:id:mugi1:20190808175922p:plain — 初期段階で見直したイメージ図

さらに使い勝手などの面から次の対応も入れることにしました。

データが多すぎると構築するDOMの量が多すぎてブラウザがクラッシュする恐れがある
- 一定の列・行数で打ち切るようにする
空行・空列は邪魔になる
- 空行・空列はすべて削除する

PRレビューでの指摘の数々

見直したイメージに沿う形への修正が完了したら、PullRequestを作成し、まずは開発者でレビューしてもらいます。

コード自体に関するレビューはもちろんのこと、Misocaのレビューでは「そもそも仕様として○○は✕✕のほうがいいんじゃない？」というコメントも頻繁に見かけます。その中でも様々な意見をもらいました。

カンマ区切りいらないのでは？

最初は、表計算ソフトからの貼り付けに加えて、CSVファイル（カンマ区切り）も使えました。合宿時点では「使えるファイルの種類多くて色々できたほうが便利でしょ！」という軽い考えでしたが、レビューの中で次の意見をもらいました。

f:id:mugi1:20190809102534p:plain

できることが増えることは一見良いことに感じますが、選択肢があれば操作時に思考や迷いを生みます。あらためてカンマ区切りの是非について検討しました。

なんとなく対応してたけど、CSVファイル貼り付けるシチュエーションはかなり稀
暗黙的な挙動が増え、ユーザに戸惑いを与える恐れがある
サポートしていることで実装が複雑化し、メンテナンスコストも増える

↓

議論した結果、「最初のリリース時点ではカンマ区切りはサポートしない」とすることにしました。

空列・空行を勝手に削ってほしいとは限らない

「データの中の空列・空行を貼り付けた後にいちいち消すのは手間だから、こっちで除去しておこう！」と空データをフィルタリングしていましたが、これに対して貰った指摘が次のものです。

f:id:mugi1:20190809105150p:plain

例えば普段は次のような請求書を利用していたとします。

f:id:mugi1:20190809105645p:plain:w400

貼り付ける際には「品目→単価→数量」の順番で左からセットされるのを期待し、実際にもそのように動きます。しかし、「まったく同じレイアウトで単価は入っていない」といったデータを考えてみます。

f:id:mugi1:20190809110320p:plain:w400

単価に該当する列には何もデータがありません。この場合、空データのフィルタリングによって「空列」と判断されて削除されてしまいます。同じファイルから同じ範囲をコピー＆ペーストしたにも関わらず、画面上で見えるデータが別のものになってしまうと、「あれっ？なんで違う項目になるの？？」と戸惑うことが予想されます。

便利だと思って入れた空データの除去フィルターでしたが、実際のユースケースを考えると混乱を招く要因になり得ることがわかりました。

↓

「除去するのは末尾の空行・空列のみとする」という方針に見直しました。不用意に除去するより、常にある程度同じ挙動をするほうが使いやすく戸惑いが少ないという判断です。