雑なアップデートは非難を浴びる
先日、公開中のアプリをアップデートした。
いい感じの機能が出来て、旧来の機能はそれで補えるだろうということで、軽い気持ちで旧機能を削除してしまった。
とすると、どうだ。かなりの数のお怒りのメールと共に、アプリの評価が下がってしまった。まだ★の数に影響するほどではないが、最近の評価は上がる一方だったので大ショックである。
メールをくれたユーザさんに聞いてみたことろ、旧機能には自分が全く予想していなかった使い方があり、それは新しい機能では補えないものだったことが明らかになった。
結局、その使い方ができるような修正を行うことにした。
改めて今後のために、ユーザさんが現在利用中のオプションを全て把握できるような仕組みを組み込んでみた。その結果を見ると、今回影響を受けたユーザさんは全体の3%ではあったが、この1年でかなりユーザさんが増えたので3%でも結構なボリュームになる。これでは迂闊な機能削除や仕様変更は出来ないと思った。
競合アプリのレビュー欄を見てもUI変更などをした日には、「前のが良かった！」という書き込みで溢れいてる。それが良い方向であったとしても変化を嫌う人は一定数居て、ユーザ規模が大きくなるとその数も無視できないものになる。これは心すべきだなぁ。
電卓ができません
今リリースしているアプリに電卓的な機能がある。電卓といっても入力する金額の四則演算ができる程度なのだけど、さきほどユーザさんから「電卓ができません」とサポートメールがあった。この前後に文章はない。ただこの1行のみ。
まるでGoogle先生に問い合わせているみたいだ。
以前は、ほとんどの質問がしっかりとした文章だったのだが、最近、アプリのユーザ数が大きくなってからは、このような「1行質問」が増えてきた。
ユーザが増えるとは、いろいろなレベルの国語力を持ったユーザさんを相手にしなければならないんだと痛感した。
で、本題の「電卓ができません」という質問だが、当然この情報だけではどうにもならんので詳しく教えてくださいと返信した。
これまでの経験では、だいたい半数くらいはここで回答が無く終わってしまう。面倒になったのだろう。
が、今回はちゃんと回答が返ってきた。
「かけ算、足し算が出来ません」
うーん。一歩前進だがまだ分からない(笑)
この後、何回かのやりとりを重ね、やっと問題が見えてきた。
ひとつは掛け算の計算過程を表示するときに＊を使っていたこと。
ｘではなく＊だったのが混乱を招いていたらしい。
何の迷いもの無く＊を使っていたよ(笑)
パソコンユーザなら自然に理解してくれるだろうが、スマホオンリーの人にとっては確かに「打ったものと違う！」となるだろう。
ここは改善したい。
もうひとつの問題点は「＝」ボタンが無いことだった。
スペース的に「＝」を配置する場所がなかったので、ボタンサイズを小さくして詰め込むよりは、「＋」ボタンを押せばその時点での計算結果は表示されるし、問題ないと考えていたのだが、これが大甘だったようだ。「＋」で結果を表示させるという発想はなかなか出ないみたい。これも改善が必要だ。
そういえば昨日読んだ記事は絶妙なタイミングだったなと思い出した。
ユーザ目線で考えて、迷わせないUI設計を心がけたいものだ。
二の補数
昔、学生の時に習った補数表現。
今まで何度かお仕事で使う機会があったのだが、その仕事が終わるとすぐに忘れてしまうので、備忘録的にまとめておく。
二の補数はマイナスの表現方法だ。
計算方法としては全ビットを反転させて、＋１する。ただそれだけ。
例えば8bitの-1の二の補数は
1) 元データ： 0000 0001
2) ビット反転： 1111 1110
3) プラス１： 1111 1111
十六進数だと0xFFとなる
もうひとつ、-128だと
1) 元データ： 1000 0000
2) ビット反転： 0111 1111
3) プラス１： 1000 000
十六進数だと0x80となる
単純に最上位ビットを符号判定に使うほうが人間的には分かりやすいと思うのだが、コンピュータ的にはマイナスを二の補数にすることで全て「加算」で処理できるという大きなメリットがあるので、こちらが使われているようだ。
例えば5-3を考えると3の二の補数表現は111 1101なので
0000 0101
+ 1111 1101
------------------
1 0000 0010
となる、先頭の桁あふれ部分は捨てられるので2が得られる。
多分、もう忘れないはず。。。
ＡＩ的思考な息子
下の息子が前回の中間テストでファンキーな点を取ってきて以来、毎晩30分ほど勉強を教えている。
何回か教えている中で、息子には計算や単語力とかそれ以前の問題として、驚くほど読解力が無いことに気づいた。
そもそも、まともに文章を読もうという気が無いのか、自分が知っているパターンを片っ端から当てはめている感じなのだ。
なので、ひとつの問題が解けたからといっても全く油断できない。似たような問題を出してもトンチンカンな答えをしたりする。
本当に理解して解けたのか、たまたま彼の持ってるパターンに一致して正解したのかを見極める必要がある。
そんな感じで四苦八苦してる時に、「ロボットは東大に入れるか」というプロジェクト（東ロボ）が東大合格を断念したというニュースを耳にした。
なかなか興味深い記事だった。
実はAIも文章の意味を理解できていないのだ。基本的には問題を検索と確率だけで解いている。
動詞や接続詞などを拾うことで選択の精度を高めることはできるが、「理解」はできていない。
さらにこの記事では、実は子供たちもAIと同じようにキーワードとパターンで解いている子が意外に多いと指摘している。
AIと同じことをしてたらAIに駆逐されますよというのが、この記事のテーマのようだ。
うーん、うちの子も駆逐されちゃうよ、、、
どうやったら読解力を鍛えることができるのか。
頭を抱える日々が続いている。
GoogleAnalyticsにビビらされる
GoogleAnalyticsには、ほんとお世話になっている。
今、リリースしているアプリに仕込んでいるのだが、やばい不具合があるアップデートをしてしまった時など、アクティブユーザ数が素早く減るので、早めの対策がうてる。
先々週にようやく一連の不具合を解消したアップデートをだしてから、ユーザ数が順調に伸びてきて、毎日、GoogleAnalyticsをチェックするのが楽しみだったのだが、昨日、いきなり１日のアクティブユーザ数が激減し、前の日の１割程度になってしまった。
前のアップデートからかなりの日数が経過しているし、月末とかではないので時間的な要素がからむ可能性も考えにくい。ユーザの評価をチェックしても変化は無い。リアルタイムのユーザ数をチェックしてみても、むしろ増えてるように見える。全くこうなった理由が見当たらなかった。
こうなるとGoogleAnalyticsの障害かなとGoogleのサービスステータスをチェックしてみても障害情報は見当たらない。
しばらく様子見にすることにして、もやもやした気持ちのまま一夜が経ち、今日ふたたびチェックしてみると、よかった、回復している。相変わらずサービスステータスには不具合情報は出ていないけど、こういうこともあるんだなー。
基本なことだけど品質は超重要
またまた更新をさぼっていた。
自分ではそう感じてなかったけど、案外、余裕が無い日々を送っていたのかもしれない。
日々の作業時間としては、そんな多くは無いと思っていたのだが、数年前にキチガイなプロジェクトに参加して、定時はPM10:00みたいな環境に長く身を置いてしまったせいか、感覚がズレてペース配分がうまくいかなくなっている。
今、思えば深夜まで働いたといっても、多くは無駄な会議とか、あまり意味の無い割に量だけは多いレポートを作成するとか、大して頭を使ってない。全労働時間に対して本質的な設計やコーディングにかける時間の割合はかなり低かった。
対して、今は会議時間ゼロ、形式的な文章作成は無し、ほとんどの時間を本質的な設計とコーディングにかけて頭を酷使しているので、時間が少なくても疲労度がデカイのは当然だ。
時間だけで頑張った度を計るのはよろしくないと再認識した。
で、余裕が無かったのは請負でやっているお仕事と平行して、リリースしたアプリのアップデートやら不具合対策に追われたからだ。
アプリの反響が良くて、ユーザさんからいろんなリクエストをもらって、調子にのってガンガンアップデートしてたら、結構な不具合を埋め込んでしまっていた。テストが不十分だったのだ。
大きな不具合があるとアプリの評価はてきめん下がり、ユーザ数の伸びもピタっと止まる。
魅力的な機能を素早く投入するより、不具合の無い品質の高いものを提供することのほうが重要だと身をもって知った。
あらためて、高い評価を得ている競合アプリをGooglePlayでチェックしてみると不具合的なレビューはとても少ない。やっぱり基本はおろそかにはできないなぁと反省するのでした。
WebViewのソフトキーボードにはまった
いま開発してるAndroidアプリでWebViewのテキストBOXをタップするとキーボードがでるんだけど、文字を確定させて「実行」とやってもキーボードが消えない問題があった。いちいちBACKボタンで消す必要がある。
これは不便なので、「実行」ボタンのタップを検知してJava側のコードでキーボードを消そうとしてハマったので、その記録を書いておく。
当初はWebViewにsetOnKeyListenerというメソッドがあるので、これを使えば楽勝！ と思っていたが、ハンドラが呼ばれない。ではWebViewを拡張してonKeyDownをoverride！ とやったがこれもダメ。
WebView.onKeyDownのリファレンスを注意深く読むとソフトウェアキーボードには効かないよと書いてあった(涙)。
StackOverflowなどを徘徊してdispatchKeyEventを実装する方法などを試してみたが、キー検知はできるものの日本語が入力できなかったりとうまくいかない。
結局、その他の試行錯誤もことごとく失敗し、半日程度を費やして失意のうちに帰宅。
翌日、InputConnectionWrapperを使えばうまくいけそうという情報をつかんでトライし、ようやく実現できた。
InputConnectionWrapperはキー入力のプロキシ的に動作するラッパクラスで以下のように使う。
まずはWebViewのラッパを作り、利用側で「実行」キーがタップされた時のコールバックを用意してそれを登録するという流れ。
わかれば簡単なのだけど、はまると時間喰うなぁ。。。
