‘モバイル’ タグのついている投稿


すっかり忘れておりました

WEBサイトをガラケーでアクセスした場合、UserAgentで判別して、ガラケー用サイトにリダイレクトするように設定して運用していました。
URLを打ち込んでの動作は問題無いのですが、ツイッターにURLを書き込んだ場合、リンクを踏むとPC用サイトを無理やり表示したような画面になっているという連絡が。
過去にも似た事例あったなあ、ということで小一時間ばかり数年前の記憶を辿っていました。人はすぐに忘れてしまうものです。

Googleの変換なのでGoogleに聞こう

「PC用サイトを無理やり表示したような画面」というのはGoogleの変換サービスだということは、すぐに思い出しました。実際アクセスログを調べてもそのタイミングでのガラケーのUserAgentは見つからないので、直接アクセスが無いのは明白です。
Googleが変換しているんだから、Googleが情報を出しているだろう、ということで調べてみました。

ありました。というか思い出しました

あー、これこれ。というものでした。

携帯端末での表示について
https://support.google.com/webmasters/answer/35312

ページのheader部分に1行記述するものでした。

<link rel="alternate" media="handheld" href="ガラケー用ページ" />

本当に綺麗さっぱり忘れていました。

ノウハウの蓄積も必要とされてこそ

わざわざ今更書くような事柄では無いのかも知れないけれど、実際自分が忘れていて、あれえなんだっけ?という風に思ったりするわけで、必要とされている間は誰かが情報を出し続けないといけないかな、なんてことを考えました。
フィーチャーフォンの新規サービスは先細り、というか、先細りももう無いくらいな現状ですが、それでも定期的にメンテナンスが発生する案件などもあるわけです。

もしこのタイミングで同じ問題にぶつかってここに来た人がいたら、ちょっとだけ嬉しいです。


またもやニッチなノウハウ。

PC用URLを代表にして、mod_rewriteでUserAgent毎にページを振り分ける処理をしていました

RewriteCond %{HTTP_USER_AGENT} "KDDI" [NC,OR]

こういった記述でUserAgentで振り分けしていました。よくやる手法です。.htaccessなんかに書きます。

FacebookにPC用URLでシェア投稿しました

お知らせや宣伝でよくやりますね。スマホで見ても、UserAgentの振り分けでスマホ用ページに行ってくれるだろうという見込みです。

それが予期せぬページが表示されていました

うーん、謎ですね…ということで調査しました。

FacebookのスマホアプリだとUserAgent文字列が違いました

auのiPhone5の場合、こんな感じでした。

"Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 [FBAN/FBIOS;FBAV/14.0.0.25.26;FBBV/4017285;FBDV/iPhone5,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/7.1.2;FBSS/2; FBCR/KDDI;FBID/phone;FBLC/ja_JP;FBOP/5]"

お尻の方に、まんまとKDDIが入っていました。
それが原因でガラケーの判定に引っかかり、結果ガラケーページに飛ばされていました。
他キャリアはどうかなと思い、ログをみたところ、DoCoMoは「NTT DOCOMO」が入っていました。ソフトバンクは入ってない様子。

判定の順番は上からなので、先にスマホの判定をいれるように順番を変えて解決しました。やれやれ。

ガラケーの判定はうしろに

今もガラケーの手当しているサイトはそんなに多くないと考えるのですが、逆に言えばそういう所はガラケーの対応の後にスマホの対応をしてきた経緯がある可能性が高いです。
ということは、記述も先にガラケーの判定があり、その後にスマホの記述したケースが多いかも知れません。その場合は今回のようなトラブルにぶつかる可能性があります。
 

今回もレアケースな対応例でした。


あいかわらずのニッチなネタ。
「いわゆるガラケーのWEBサイトの対応はいつまで続くのか?」という問題は開発の現場でたびたび話題にのぼる。

「ゆるやかに減りつつも完全にゼロになるのは大分先」だろうという結論にだいたい落ち着く

あるあるネタ的な内容であるけれど、おおよそこの結論になる。理由はざっとこんな感じ。

まだユーザーがいる

実際にユーザーがいるのは揺るぎない事実。スマホに乗り換えるケースがどんどん増えているものの、携帯ショップに行けば僅かではあってもガラケーも選択肢として用意されている。
誰もがスマホに移行したいわけではないのも事実だし、スマホを使った結果、ガラケーの方が便利なのでは無いかということを言う人も。
現状の認識として、ガラケーの後継サービスがスマホであるということが決定的な状態では無い雰囲気でもある。

サービスが継続している

ガラケーからWEBにアクセス出来てしまう。今のところ出来なくなるというアナウンスは出ていないし、恐らくしばらくは出ないだろう。
インターネット接続サービスとしてメールとWEBアクセスをまとめて提供している限りは、無くすのは難しいのではないか。

注目がスマホにシフトしただけでは

スマホのサービスがイケイケな状態なので、相対的に地味になってきているだけという説。サービスは継続しているわけで、使っているユーザーがスマホの足を引っ張っていると考えれば目の敵にする傾向だって想像できる。
若干思い込みの部分もあるものの、お金に結びつきにくい存在になっているだけで、現状維持としてありつづけるサービスと考えるのは確かに無茶な話ではない。

でも開発現場が減っていますよね

ガラケープラットフォームがメインとして開発されるプロジェクトは圧倒的に少なくなったようだ。
実際、お手伝いさせてもらっているところでもガラケーもしますけどね…といった感触。切り捨てはしないけれど対応デバイスの一つであり、深追いして開発が手間取るなら機能削りましょう、という言葉が簡単に出る。

その結果

よくあることで、新規の開発者や蓄積されて資料の活用が減ることで、サービスの企画も差し障りの無いものになりやすい。
FlashLiteバリバリのサイトを作ろうという企画を立てるならばスマホのアプリを充実させた方が良いとか。
ガラケー特有の仕様についても深くケアされることが減り、cookieを使えない端末があることや、表示できる容量についての検討などもそこまでキッチリされなくなった印象がある。
大雑把に言えば開発に工数をあまりかけなくなった。

それでもサービスは残る

ということで最初に戻ってしまう。
言ってしまうと日陰の技術になりつつあるガラケー開発だけど、華やかでないにせよ、それでもお仕事としてまだまだありますよね…という部分は間違いない。

新しい技術だけは技術では無いけれど、進化の速度が早い業界の中ではもう恐ろしいほど古い技術になってしまったんだなぁと思うと、不思議な気持ちになったりする。


本当にちょっとした小ネタ。
いまさらながらFlashLite1.1を動的生成するという作業があった。本当にいまさらなんだけど、さてさて…とネットをざっと見た感じ、swfmill0.2系にパッチをあてるインストールの記事が上位にあったので最新情報を書いてみることにした。
情報は常にアップデートされるべきだとは思うけど、追い続けられるわけでも無いから、気づいた誰かが新しい記事を書いていけばいいんじゃないかな。

現時点の最新バージョンは、0.3.2です

swfmillというのは、swfファイルからXMLファイルを作成したり、逆にXMLファイルからswfファイルを作成してくれるツール。

基本的な流れは、AdobeFlashなりで元になるswfファイルを作成。それをswfmillを使ってXMLファイルに変換。そのXMLの中身を変更して再度swfを作成という風。
XML中に、画像はbase64のエンコード文字列で、テキストはそのままテキストで記述出来る。最新版のドキュメントを見ると外部の画像やフォント、swfファイルも指定できるみたい。

0.2系ではパッチがあった

ざっと検索して出てくる日本語の記事は、まだ0.2系だった頃の内容のようだ。FlashLite1.1の内部文字コードはCP932なのだけど、swfmillではUTF-8がデフォルトで文字コードを変更できないので対応パッチをあてましょうという事が書いてある。
最新版の0.3.2でも

#swfmill swf2xml test.swf test.xml
error : xmlEncodeEntitiesReentrant : input not UTF-8

とエラーが出た。これはパッチの登場か?と思いきや

#swfmill -help

swfmill 0.3.2
    XML-based SWF processing tool

usage: swfmill [<options>] <command>

<command> is one of:
    swf2xml <in> [<out>]
        convert from SWF to XML.
        <in> is a single SWF file, or 'stdin'
        <out> is a single XML file, or (by default) 'stdout'

    xml2swf <in> [<out>]
        convert from XML to SWF.
        <in> is a single XML file, or 'stdin'
        <out> is a single SWF file, or (by default) 'stdout'

    simple <in> [<out>]
        convert from a movie definition file to SWF.
        <in> is a single XML file, or 'stdin'
        <out> is a single SWF file, or (by default) 'stdout'
        (for details, see README)

    xslt <xsl> <in> [<out>]
        transform <in> to <out> as described by <xsl>.
        <xsl> is the XSLT stylesheet,
            and can use the swft: extension.
        <in>  must be some XML (depends on <xsl>)
        <out> is either SWF (when it ends in .swf)
            or XML, by default on 'stdout'

<option>s are:
    -h print this help and quit
    --version print the version number and quit
    -v verbose output
    -V extra-verbose debugging output
    -d dump SWF data when loaded (for debugging)
    -e specify text encoding in SWF (for SWF 5 and earlier only;
           default: UTF-8).
    -n deactivate libxml network access

Please report bugs at https://github.com/djcsdy/swfmill/issues

と、ありがたいことにエンコーディングのオプションが実装されていた。

ということで

#swfmill -e cp932 swf2xml test.swf test.xml

で、無事にXMLファイルが作成された。めでたしめでたし。ちなみにXMLファイルのエンコードはUTF-8になる。

まぁこれだけの話です

以上、最新版ではパッチあてなくても平気ですよ、というお話でした。
正直、現時点でFlashLiteやFlashの動的生成に需要がそんなにあるのか?という部分はあるけれど、だからこそ気づいたことを書いて公開しておこうかなと思った次第。ちょっとでも役に立てば嬉しいです。


人と話をしたり 何処かへ行った記録 都市文化生活
エイトビットカフェ 5周年イベント用フリーペーパーの制作でインタビューを自分でやってまとめるという作業をやった。それに味をしめて、という分けではないけれど、人と話をした記録をメインにしたサイトを立ち上げてみた。

1回目は、イラストレーターのトリバタケハルノブさんとお話をさせてもらっている。
また同時に、トリハルさんのキャラクターでTシャツを作ってみましょうという企画も進んでいる。
どうなっていくか楽しみだ。

サイトロンチのタイミングで観測した興味深い傾向

サイトのロンチは、3/4(金)の夕方に、Twitterでボソッとつぶやいた。
サイト内でも、トリハルさんのTシャツが欲しい人はツイートしてサイトURLを告知する仕掛けを設置し、第一弾はTwitterのみでのロンチとなった。

ロンチ後、アクセスログを流してみていたのだけど、予想以上にモバイルからのアクセスが多かった。
iPhoneや通常の携帯電話 (携帯電話からでは残念ながらちゃんと表示されない。ごめんなさい) だけでなく、Androidからのアクセスも同じように目にした。IS03,HTC,Xperiaなどなど。

という状況から考えれば、会社帰りや、遊びに出る時間帯に外でTwitterを眺めていて、ツイートから直接アクセスしているというシーンが容易に想像できるのだけど、実際ここまでバラエティに富んだ状態になるとは思っていなかった。
Andoridの普及は、進んでいるのか、そうでも無いのか、いまひとつ分からないのだけど、普及のスピードはどうか分からないけれど着実に進んでいるのだなぁと思った。少し前に「XperiaでTwitterしている人をあまり見ないよね」なんて話をしたことを記憶しているし。

携帯用のTwitterサービスからのリンク

そういえばの付随した話題。
携帯用Twitterサービスで、ツイート中の外部リンクが直接リンク先に遷移せず、モバイル用コンテンツ変換サービスを利用したページに遷移させるようなケースがある。
リンク先のサイト側でユーザーエージェントを判断して表示するページを振り分けている場合は、コンテンツ変換を経由せず直接リンクしてきてもらった方が良いわけで、その辺ちょっとヤヤコシイ感じになってしまう。確かにPCページへのリンクの場合にはコンテンツ変換してもらえれば便利なのだけど。
対策としてPC用のページのヘッダ部に

<link rel="alternate" media="handheld" href="モバイル用サイトのURL" />

を入れれば良いようだ。
ガラパゴスなどと揶揄されるものの、まだまだ既存の携帯電話からのアクセスは多数存在していて、IE6のように「もう変えよう」という風潮でもない。当面は、PC/スマートフォン/携帯電話という3種類の環境を意識したサイト運営が続けられることだろう。

ということで

携帯電話用のページは追いついていないですが、淡々と更新していければと思いますので、気が向いたらアクセスしてみてください。


紀伊國屋書店 Forest Plus スマートフォンに対応
お手伝いさせていただいている「紀伊國屋書店 Forest Plus」がスマートフォン用のページをリリースした。
 
URLはPCと同じ http://forest.kinokuniya.co.jp/ で、スマートフォンでアクセスすると、専用ページが表示される仕組み。
トップページだけでなく、商品ページも同様に対応しているので、公式Twtterアカウントの商品を紹介するTweetからのリンクでも問題なくスマートフォンページが表示される。
 
トップページはPCページのメニューから要素を削って、商品検索と商品紹介の読み物系を配置しているので、移動中に情報を眺めるのに適している。
紀伊國屋書店ならではの商品ラインナップもあるので一度チェックしてはどうだろうか。


PCサイトのスマートフォン対応時の考え方 に引き続く感じで思いついたことをまとめたメモ。
サイトが用意出来たら、そこにどうやって人を引き込むかという課題は、サイトの企画段階からあるべきもの。とはいえ、サイト開発中に状況が変化したりもするし、リリース後にだって刻々と変わっていく。サイトの特性によって一般論にあわない部分もあるだろうし、現実にやってみないと分からないことだって沢山ある。
ということで結局は常にトライ&エラーになるんだろうけど、そんなこと言っても仕方が無いので、思いつきをいくつか書いてみる。

PCサイトとスマートフォンの自動振り分けを用意する

検索エンジンやブックマークなど、今までPCサイトを表示していたURLで、スマートフォンからのアクセスの場合にはスマートフォンサイトを表示するようにする。
これでスマートフォンユーザにとっては今までと変わりなくスマートフォンサイトへ誘導することが出来る。
ただし、PCサイトで閲覧したいという要望であったり、PCサイトと同じ機能を提供しないページの場合には検討が必要となってくる。
スマートフォンサイトに対応すべきページは、サイトに入ってくる所からになるということも言える。

PCサイトにスマートフォン用サイトへのリンクを設ける

スマートフォン用ページが用意されていない、用意はされているが機能が一部異なっている為PCサイトのURLではスマートフォンページを表示出来ない、などの理由で自動振り分けに対応できないページには、PC用ページ上でスマートフォン用のリンクを用意する。この場合のリンク先をどこにするかは検討が必要。
単純にPCからのアクセスの場合でも、スマートフォン用サイトが用意されていることをアピールすることで、認知を増やし、アクセスする機会を増やすことも考えられる。

告知ページやメールマガジンなどでスマートフォン対応したことをお知らせする

同じく、スマートフォン用サイトが用意されていることをアピールすることで認知を増やし、アクセスする機会を増やすことも考えられる。
メールマガジンや告知のRSSなどは別サービスからの閲覧が発生することも予想できるし、それらは、移動中などモバイル環境から閲覧するシーンが容易に想定できる。サイトに告知を上げるだけでは無く、色々な手段でアピール出来た方が可能性は広がる。
Twitterアカウントがあれば、定期的にアピールすることで、RTなどで情報が広まるなんてことも考えられる。

TwitterやFacebook、mixiチェックなどSNSへのリンクを取り入れる

上記の告知機会を作っていく為の手段。
SNSとスマートフォンの組み合わせは非常に相性が良く、モバイル環境から閲覧するシーンが容易に想定できる。その為、ユーザがSNSにリンクをアップ出来るような、「ReTweet」や「いいね」「チェック」などのボタンを用意する。

 

なんだか書いていて、当たり前のことばっかりだなぁと思ったりもするけれど、これが半年先ではどんな風になっているのか?比較することを考えるとちょっとだけ面白そうだ。


PCサイトのスマートフォン対応時の考え方について、ゴチャゴチャと頭のなかにあったので、まとめる意味でも書いてみる。

スマートフォンは、Flashが駄目だとか、マウスオーバーなど一部のjavascriptが思うように動かないといった若干の制約はあるものの、基本的にはPCと機能的には変わりが無いブラウザが動く為、それ専用のポーティングを急ぐ必要性は無かった。ちょっと使いづらくてもブラウザで見れば何とかなった。
つまり極端な言い方をすれば、対応するだけであれば最初から実現できているわけ。
では、それならばという考え方で、スマートフォン用に使いやすいサイトを用意したらどうだろうというのが基本にあると考えられる。

傾向として

といったものが見受けられる。どれも利にかなった内容だと思う。

ここで、少しだけ面白い発見がある。

それは、PCサイトを携帯電話向けサイトに対応しはじめた時も、殆ど同じ傾向だったということだ。
もちろん、携帯電話はスマートフォンに比べたら貧弱な表現力と容量しか持っておらず、画面に入れられる情報もはるかに少なかった。

その為

と、ほぼ同じ傾向での対応方針がとられることが多かった。iモードが登場した、2000年前後のサイト企画では、上記傾向を前提とすることが多かったと記憶している。

それから10年以上経つ現在、PCを使わず携帯電話からのみでインターネットアクセスを済ませるユーザーも増え、携帯電話だけで完結したり、携帯電話専用だけど、PCサイトも一部対応しているサイトなど、多種多様な状況が存在している。PCサイトの機能をポーティングするという考え方がそもそも存在しない企画も沢山存在する。

そしてその視点をもう一度スマートフォンに戻すと、同じように近い将来スマートフォン専用のサイトというのも登場するのではと考えられる。
もちろん携帯電話とユーザーの行動は異なるわけで、まったく同じということは無いと思うが、スマートフォンならではの文化が新たに生まれるのであれば、それはそれで楽しみなことだと思う。

でも、しばらくは、PCサイトの機能見直しの機会としてスマートフォン対応案件が存在してもらうと、個人的にはありがたいというのは本音でもある。