投稿日:

IE6外しを上手く説明するトーク


第2回「HTML5など勉強会」 に行ってきました。

その中で、「IE6問題」を強く投げかける発表がありました。「IE6」がいつまでも Web 制作会社を苦しめ続けるのは、「そもそも Web 制作会社が IE6 をサポートし続けていることが一番の原因」と言う提言があって、僕的にはまったくその通りだなぁーと思ったりしたわけです。…とはいえ、実際のところお仕事の中には競争があります。お仕事を失うリスクを考えたりして、なかなか IE6 外しをお願いできない状況があることも事実みたいです。

そこで、僕なりのお客様とのコミュニケーション例を少しですがまとめてみました。少しバイアス掛けているトークもありますが、嘘は無いと思っています。どなたかの参考になればー嬉しいです!

IE6は既に10年も前のブラウザです。国内で7%ぐらいのシェアを残していますが、主にシステム移行が難しい企業内ユースですので、コンシューマでのシェアは無視できる程度だと考えています。

IE6は最近のモダンなブラウザと比べてセキュリティに劣る部分もあります。 Webアプリケーション全体のセキュリティを重視するのであれば、IE6を対象外とするのも、ひとつのアプローチです。(ちょっと無理あるかな?)

最近では、IE6を対象外とするメジャーなサイトも増えて来ましたね。実際、弊社がデサインで参加させて頂いている月間数千万ページビューの或るサイトでは、IE6を対象外とするよう、先方の担当者さまより依頼がありました。その理由として、十分にシェアが下がったという認知はもとより、無駄なマークアップやハック、JSの採用を減らせることで、結果、サイトの構造がシンプルになりSEO性能を高めやすく、またサイトの保守性が向上するため、将来に渡る保守コストの低減が期待できるからでした。

IE6の対応は正直なところコストが掛かります。…古いブラウザですし、コンシューマシェアも殆どありません。これにコストを掛けて対応するよりも、IE6非対応であることを利用者に明示する方法もあります。たとえばこういったアプローチも紹介されています。 http://moongift.jp/2011/01/20110114-2/

ie6alert-js の採用は、最新の Flash バージョンを採用してアプリケーションを開発するよりも、利用者に与えるインパクトは少ないのではないでしょうか? ie6alert-js は、IE6のユーザーに対して、なるべく違和感のない方法で、ブラウザアプリケーションのアップグレードを提案します。

同じ見積もり額で、IE6にも対応する業者様があるとのことですが、よく考えてみてください。IE6対応コストが無くなる訳でありません。サイトの本質的なクオリティを高めるために本来適用されるべきコストを、その業者はIE6対応に割くわけです。

明かな嘘があればご指摘くださいまし。
また、他にも良いのあれば教えてくださいまし♪

投稿日:

Androidで必須なのに意外に抜けている処理


Androidでアプリ作ってたら普通にハンドルしなきゃ行けない処理だろうだけど、意外に抜けてしまっているっぽい処理エトセトラです。見積もりやディレクションの際にも抜けないように注意したいですね。

インターフェース

  • もろもろ処理に時間が掛かって ANR 発生
    ⇒時間のかかる処理は別スレッドで処理
  • 何かでユーザーを待たせたら…
    ⇒プログレスを出す。終わったら知らせる

ネットワークアクセス

  • ネットはだいたい時間掛かるので
    ⇒別スレッドで処理
  • オフラインに処理しようとして失敗
    ⇒処理前にオフラインチェックして、オフラインの時はユーザーに知らせる
  • 通信に時間が掛かり過ぎて帰ってこない
    ⇒タイムアウトを設定する
  • 通信に失敗
    ⇒適切に例外をハンドリング。必要なら処理をリトライさせる

スレッド

  • 複数のスレッドが同じ変数に同時にアクセスして時々変になる
    ⇒synchronized や volatile を使って正しく同期制御する。
  • いくつかのスレッドが同時に走って重たい。そもそも同時に走る必要無ければ…
    ⇒タスクのキューを用意して、1つ以上のスレッドでタスクを順次処理
  • スレッドを途中でキャンセル(UI的にキャンセルに見せて、実際にはキャンセルしないで走らしたままじゃないか?)
    ⇒Interrupt を正しく使い、また適切に自分で終わらせる(スレッドの基礎知識は正しく身に付けましょう)
  • ボタンタップでスレッド起動する処理とかで、連打されて同じ処理のスレッドが乱立するようになっていないか?
    ⇒今の処理が終わるまで次の処理要求はスキップする
    ⇒今の処理をキャンセルして、次の処理要求を実行する
    ⇒今の処理が終わるまでボタンを無効にして連打できないようにする
  • ファイル保存(インターネットやカメラなど、さまざまなデータをデバイスに保存する時)
    • どこに保存するかちゃんと検討する?(ローカル領域 or SDカード)
    • そのまま保存してても大丈夫か考える?(データを抜かれるリスクと対策の検討?)
      ⇒暗号化して保存するなど
    • ディスクいっぱいでエラー(大きなファイルなら意外にある)
      ⇒ちゃんと例外を処理しよう

他にもあると思いますが、ご指摘いただけると幸いです。

投稿日:

Androidでのプッシュ通知の検討と実装メモ


お知らせなどのプッシュ通知の実装は、ユーザービリティなどを考慮すると、非常にセンシティブな要件項目です。情報を出したいお客様は、時に過度な情報送信を主張されますが、それがお客様の目的と合致するかというと、必ずしもそうではない…というか、私の経験上は、どちらかというと間違った選択であることが多いですね。ディレクションにおいてはお客様とよく相談し、お客様にプッシュ通知の利害をよく説明し、ご理解いただくこと、またご理解頂けるように説明する能力が、制作会社にも求められると思います。

さて、例えば目覚まし時計などのように、通知されること自体が、ユーザーがアプリケーションに求める主たる機能である場合を除いては、コントローラブル(ON/OFF可能)であること、かつ「あまりうるさく無い」こと、といったあたりが良い落としどころのようです。

今回は、先日制作したアプリケーションについて、その仕様検討・実装のメモを残しておきます。

通知仕様の検討

アプリケーションの概要

まず、アプリケーションの要件は次のような感じでした。

  • 定期的に電力会社の情報をチェックする
  • 電力不足になると、ユーザーに通知する

アプリケーションの目的は、「節電」です。ユーザーはアプリケーションをインストールすることで、節電の為の行動を促される仕組みを持っています。通知は、電力不足の傾向が高まった時にそれをユーザーに知らせて、さらなる節電を促すものです。

ユーザー特性

今回、ユーザーには次のような特性があると推定しました。

  • 能動的に節電に取り組む意思がある
  • ある程度頻繁な通知も、許容される可能性が高い
  • 通知はなるべくタイムリーに欲しいと考えている
  • 電池消費の多いアプリは困る
  • 過度な通知を嫌う

検討

これをもとに、次のような検討をしました。
  • どんなふうに通知するか? 画面表示だけで良いか?
    …音声やバイブレーションでの通知は過剰ではないか?
  • 画面表示だけの通知なら、お知らせは画面ONの時だけで良くないか?
    …OFFの時はどっちみち見えないし
  • じゃ逆に、画面OFFの時は、電力チェックしなくて良い
    …電池節約できる
  • 最低チェック間隔は必要か?
    …頻繁に画面ON/OFFする人もいると思われる
  • 電源つないでデスクトップに置いてる人もいるよね?
    …画面ONの時だけじゃしばらくお知らせ出ないから、画面ON時は定期的なポーリングが必要
  • 通知のON/OFFは必須

決定された仕様

以上から、結果的に以下の通知仕様とすることになりました。

  • 通知方法
    • Notificationで表示する
    • 音やバイブレーションでの通知はしない
    • 次回の電力チェックで通知要件が無くなったらNotificationをキャンセルする
  • 電力チェックのタイミング
    • スクリーンON時、電力チェックする
    • 最低チェック間隔を設けて、過度な電力チェックをスキップ
    • スクリーンON中、定期的にポーリングして、電力チェックする
    • ポーリング間隔は、電力会社の情報更新間隔と合わせる

実装メモ

今回は上記の仕様を満たす為に、以下のような実装を行いました。

  • BroadcastReceiver
    • android.intent.action.SCREEN_ON
      1. bindService して、サービスの checkAndNotify() でチェックして必要なら通知
      2. Alarmで次回の定期チェックをセット
    • android.intent.action.SCREEN_OFF
      1. Alarmをクリア
    • android.intent.action.BOOT_COMPLETED
    • android.intent.action.PACKAGE_CHANGED
      1. SCREEN_ON/OFF 用の IntentFilter を登録(これらは動的にしか登録できないから)
  • Service
    • checkAndNotify
      1. 前回チェック時間を確認、最低チェック間隔を超えていたら:
        1. 別 Thread でチェック~必要なら通知
      2. 前回チェック時間として現在時間を保存(Preference)