![ドブログ[Do-Blog]](/do-blog/img/blog_title.gif)
GoogleMapsAPIで日本海（東海）表記をしない対応方法
2013年4月12日 金曜日@12:13Yahoo!ニュースなどでも騒がれているので、GoogleMapを使用した地図サービスサイトにおいて、日本海（東海）と併記される問題について、今回調べた対応方法をメモ。
GoogleMpasAPIを使用しているページのヘッダー部でGoogleMapsAPIを呼び出している箇所に手を加えます。
デフォルト状態
<script type=”text/javascript” src=”http://maps.googleapis.com/maps/api/js?sensor=false”>
↓
日本的バイアスをかけた状態
<script type=”text/javascript” src=”http://maps.googleapis.com/maps/api/js?sensor=false®ion=JP”>
以上。簡単。→地域のローカライズより。
正直面倒くさい問題
いやしかし、この問題は非常に気がつきにくいですね。
サイトの製作者はいちいち日本海の併記問題なんか気にしていませんからデフォルトでそうなってしまうことは指摘されないと分からない。
Webクリエイターは皆さんが思っているほど暇じゃないので、要件や指示でこのような対応が明記されているならいざ知らず率先して日本バイアスをかけようなんざ夢にも思わないですねー。
NHKがやり玉に上がって炎上していますが、これもどうかなぁと思います。
日本語版GoogleMapとGoogleMapsAPIを比較していますが、サービスとしては別もんだし、国賊扱いするのはなんともアレかなと。
ちなみに併記バージョンの地図の提供元は「SK Planet」という韓国の地図サービス会社のようですね。うーん。正直面倒だ。
Gumroadで小銭を稼ぎたい。
2012年2月25日 土曜日@19:46gumroadというサービスが流行っているようです。
一言でいうと、「決済を簡潔にしてくれるサービス。」
もうちょっと詳しくいうと「自分が持ってる写真やプログラムなどのコンテンツひとつひとつに値段を付けて売りに出せるサービス」です。
こういうのは体験したほうが早い。
さっそくニホンアマガエルの写真のオリジナルサイズデータを売りに出してみました｡
アカウントの作成は簡単。Facebookアカウントでログインして終わり。はやいはやい。
まず、売りに出したいコンテンツを選びます。
ローカルファイルをアップロードするタイプとすでにWeb上にあるデータへリンクする方法があります。
アップロードタイプだと、amazonのs3クラウドにアップロードされるようです。
カエルの写真は10MBぐらいあったのですが、問題なく売りに出すことが出来ました｡
これが売り出された状態です。
「欲しい！」ボタンを押すと↓クレジット決済へ遷移します｡
情報を入れて「支払う」を押すと決済完了。簡単ですね。
購入完了画面です。
「カエル写真」リンクをクリックすると購入したデータがダウンロードされます。実にシンプル。
売りに出したリスト（管理画面）です。
不思議な日本語が随所にちりばめられてます。
値段は1$から1000$。円も使えます。
販売者への支払いはPayPalで行います。ボクはさっきPayPalアカウントを作ったのでまだ開通していませんが。
FacebookとTwitterへの拡散が容易で、死蔵しているコンテンツが一瞬にして白日の下にさらされます。
うーん。やっぱ「簡単」って大事ですね。
リンク（商品URL）を作成するタイミングでどうも2重作成が行われているっぽい？など、挙動に不思議なところがありますが、ものすごいポテンシャルを感じるサービスです。
さっそくWikiウサギにカンパリンクを付けてみました。（よろしくお願いします！）
今後欲しい機能
・販売者の出品を一覧できる機能
・購入完了用リンクはコピーし放題なので何らかの解決。
・ブログなどへの貼り付けツール
・ジェネレータ
など。基本の設計がシンプルなので夢が広がりますね。APIもあるからすぐにアプリが開発されそうですね。
アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。
アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。
いいかおまえら。スマートフォンWeb制作する前に読んどけよ。
2011年7月28日 木曜日@21:18TwitterでスマートフォンWebの制作メモの要望が有ったので、公開しときます。これによって生じた不利益や不幸については一切責任を持てないばかりか、逆にボクなんかを信じる方が悪いんだぜ。
ここ数ヶ月でスマートフォンに最適化されたWebサイト（通称スマホWeb。スマートフォンアプリではない。）を制作する機会が有ったので、メモ。
コーディング寄りです。
開発環境について
まず開発環境を整えます。
欲しいのは内蔵ブラウザのエミュレータだけなので、バカでかいSDKをインストールするのはちょっと抵抗あります。そんなときは同じ描画エンジンを持つSafariやChromeで８割方のエミュレートが可能ですのでSDK入れないのも手。ボクは最初のざっくりコーディングの時にはSafariを使ってます。
AndroidSDKはその使い方がやたら複雑です。そうとう面倒なので好みでいいと思う。
余談ですがJAVAのアプリって総じてインターフェースが垢抜けなくて、文字が小さくて、使い勝手が面倒くさいですよね。
実機
iPodTouch 第4世代を１台とAndorid端末のバージョン2.2と2.1の一台づつ欲しい。
Web開発に限った話ならiPhoneは必要ないです。iPodTouchで十分。中古で１万円ぐらいのものを見つけてくればＯＫ。ただし第４世代であること。
Andoridも持ってる人に貸してもらったりするレベルで大丈夫だと思います。ただ、OSバージョンの2.2と2.1を実機で確認できるようにはしておいた方がいい。こちらも通話機能は必要ないので白ロムで良いです。
ブラウザについて
スマートフォンは、大きくわけて３タイプあります。
iPhoneを始めとするiOS、Android、その他（Windowsケータイ＋Blackbery）です。
この中で要件となりやすいのがiOS。次いでAndroidです。それぞれiOSにはSafari(Lite)、AndoridにはChrome（Lite）が標準ブラウザとして搭載されています。（Liteというのは便宜上の名前であって、正式名称かどうかは知りません。）このどちらもWebkitが描画エンジンとして採用されていて、レンダリングに関してはそれほど変わりません。IEの無い環境（ウホーウ！）ですのでCSS3、HTML5が主軸になります。
注意したいのが、Andoridの2.1。さらに1.6以前のバージョンです。
1.x系はもうほとんど見られませんが、2.1は無視できないシェアを持っているため、これにどう対応するかが制作コストに大きく反映します。
「2.1でも同じように見られる」となると、HTML5に対するバグと、未実装のCSS3プロパティへの配慮が必要となります。体感で３割り増しのコスト増です。慣れてしまえばどうということはないですが、最初は工夫が必要だと思います。
画面サイズについて
デバイスをいろいろ見渡してみると、かなり多種多様な解像度があることがわかります。
最小幅240pxあたりから、最長1000px越えまで。
これらデバイスの幅をうめるのは容易ではありません。よって、画面のピクセル数に影響されないように、後述するリキッドデザイン・リキッドレイアウト＋Viewport設定をする必要があります。
タブレットＰＣについて
iPadやGALAXY Tabなどの中途半端な画面サイズは、完璧なリキッドレイアウトでないとゴマカシが効かない為、非常に難易度が高いです。
「スマートフォンと同じように見せたい」というクライアントの要件には慎重に対応しましょう。タブレットＰＣはスマートフォンというよりはノートPCに近いです。注意が必要。
jQtouch
・jQTouch — jQuery plugin for mobile web development
スマホWebを手っ取り早くアプリっぽくするには、このjQueryプラグイン一択です。（２０１１年７月現在）
ただし、かなり癖の強い実装をしなければならないのと、いろんなバグがある点で、上級者向けといえます。しかしながらjQtouchのもつAjax機能やテンプレート機能は非常に強力であるため、使用を決断する場面もあると思います。jQtouchはその性質上、制作過程の途中で導入（もしくは排除）するには難しいものとなっています。制作を始める前に、使用するかどうか決めておいた方がよいです。
・jQtouchで構築されたページへのリンクは[#home]というハッシュをつけます。
これで、リダイレクトによってバック（戻る）ボタンがkillされる状態を防ぎます。（なんのことやらとお思いでしょうが、やっていくと分かります。）
・jQtouchでは、なぜか画像に対してリンクをつけることができないため、画像リンクの場合は画像を背景化し、text-indexでテキストノード部分を飛ばします。よく見るあれですね。あんまりこの技法は好きじゃないんですが。しかたなし。
例：
background:url(./image/bg.png) no-repeat;
text-indent:-10000pt;
・jQTouchを使用する場合meta要素によるViewportの設定は必要なくなります。
デバイス依存の機能：ホーム画面にファビコンを設置する機能
iOSと一部のAndoridの限定機能です。この機能を使うと、ホーム画面にアプリケーションのようにアイコンを設置することができます。
・iPhone/iPadのホーム画面用アイコンapple-touch-icon.pngをサイトに設定しよう
デバイス依存の表現：Ajaxなどで利用する画面切り替えエフェクト
主にjQtouchで利用することになる画面切り替えなどのエフェクトですが、機種によって実装状況が異なります。また、jQtouch自体にバグがありリンクなどがうまく動かなかったり、誤動作などもあります。
iOSならば「Flip」を、Andoroidならば「slideup」をお勧めします。比較的意図どおりに動くと思います。
Viewport
スマートフォンのブラウザには、Viewportという拡大・縮小設定が可能です。詳しく説明すると大変なので以下のサイトを参照してください。
簡単に言うと、解像度やディスプレイサイズの異なるデバイス間で横幅をピタピタにして見せる技術です。
jQtouchにはこれをコントロールする機能が搭載されているので、あまり意識する必要はないと思われます。
下記のorientationchangeと合わせて制御するといいかも。
Androidでorientationchangeイベント
AndoroidとiPhoneには、画面回転機能が搭載されています。縦位置と横位置の制御は意外と難しく、またAndoridではなぜかJavaScriptで画面回転イベントがうまくとれません。よって回転を利用した機能を搭載する場合、以下のScriptを仕込んでください。
・Androidでorientationchangeイベントが意図した通りに動かないので。[do-blog]手前みそですが。
PC版とのデザインの違い
PC版とスマホのデザイン面での大きく違う点をいくつか。
・リキッドレイアウトでないと無理。印刷デザイナーさんはキツいと思う。
スマートフォンは、1pxにこだわるデバイスではありません。
そんなことより画面全体の美しさが重要になります。これまでのようにピクセルピクセル言いながらデザインできないので要注意です。いや、デザインしてもいいんですけどね。
多様な解像度・画面サイズにおいてはズームイン・ズームアウトが常用されるわけで、コーディングから上がってみたら想像してたのと全然違う！ってなります。絶対。
・（今はまだ）フォントはデフォルトでいいよ
スマホは総じてフォントがきれいなので、無理に変更することないと思います。
また、画像化されたテキストをデザインに組み込むのもＮＧ。テキストは画像化しない。
・グラデーションはCSSでやる。
例：background: -webkit-gradient(linear, 100% 100%, 100% 0%, from(#DDDDDD), to(#FFFFFF));
・テキストドロップシャドウもCSSでやる。
例：text-shadow: rgba(0,0,0,.2) 0 1px 1px;
・ボックスシャドウもCSSでやる。
例：-webkit-box-shadow: 1px 1px 8px #A0A0A0;
・画像は基本は全部PNG。
GIFやJPGはあまり使用しません。（魅せる為の写真はJPGかな）アルファチャンネルを使いまくるデザインになります。
・アルファチャンネルをうまく使えないとデザインできない！そういう時代になりつつあります。
PC版とのコーディングの違い：ＨＴＭＬ
基本的にHTML5で組むのが主流です。
が、別にHTML5でなくても動いちゃいます。これは好みでＯＫだと思います。
ただし、Andorid2.1では、HTML5の新しい要素（section要素、Header要素、Footer要素など）を正常に解釈しません。新しい要素を使用する場合は、ブラウザに新しい要素を認識させるところからスタートします。
・HTML5 を IE や Firefox 2 でも使えるようにする方法
JSの冒頭で新しい要素をブラウザに教えてあげるという感じです。
例：
document.createElement('header');
document.createElement('section');
document.createElement('footer');
PC版とのコーディングの違い：ＣＳＳ
リキッドレイアウトでコーディングします。
・できるだけ「％」で大きさを指定していきます。ピクセルで指定する場面は、縦幅に対しての精密な設定ぐらいです。
・bodyでは、とりあえずフォント指定。メイリオが使いやすいです。
例：
body {
font-family:'Helvetica','メイリオ',Meiryo,arial,sans-serif;
}
・CSS3のプロパティを多用します。デザインの項で説明したようにグラデーション、ドロップシャドウ系はCSS3で実装します。以下、現時点で使えることが確認できているプロパティです。
・バックグラウンド画像を引き伸ばすプロパティ
例：-webkit-background-size: auto 100%;
・はみ出た文字列の省略
例：text-overflow: ellipsis;
・Borderの角丸
例：border-radius: 4px;
・Borderに背景を設定して幸せな気持ちになる
例：-webkit-border-image: url(image/bg.png) 0 0 15 0;
このプロパティは使いどころが難しいです。
・Media Queriesを使用した画面サイズによる振り分け
例：最大画面サイズが300px以下の場合P要素のフォントサイズは10pxとなる
@media screen and (max-width: 300px) {
p {font-size: 10px;}
}
・タップ状態のスタイルを設定する
スマートフォンではマウスオーバーという状態がないがない（正確には感知できるほどのものではない？）のですが、かわりにクリック中（タップ中）という状態が目立つようになります。
その状態を制御する為に以下のプロパティを使います。
例：-webkit-tap-highlight-color: rgba(0,0,0,0);
PC版とのコーディングの違い：JavaScript
PC版に比べると実行速度が大きく劣るのですが、安定面からjQueryの使用をお勧めします。
（ただし、込み入ったことをやろうとしたり、プラグインを多重にぶち込んだりしだすと実端末でシャットダウンされちゃったりします。よって実機による検証とチューニングは的確に行った方がいいと思います。）
jQueryの依存度は上がるとおもいます、CSSと同じぐらいの比重で書いていくことになるんじゃないかな。
・端末の振り分け関数
var agent = navigator.userAgent;
if(agent.search(/iPhone/) != -1){
$('body').addClass('iphone');
}else if(agent.search(/Android/) != -1){
$('body').addClass('android');
}
iOSならBody要素に「iphone」クラスを、Andoridなら「android」クラスを追加します。あとはCSSでカスケードしてくらはい。
・アコーディオンやタブなどの小さいインターフェース
jQueryプラグインをバカスカいれるのでは処理が追いつかないので、jQueryでスクラッチした方がよいと思います。
まとめ
スマートフォンに最適化されたWebサイトは今後加速度的に増えていくと思いますので、知ってて損はない情報をまとめました。
「そんなの知ってるよ！」という方は、お友達になってください。
「へーそうなんだ！」という方は、お仕事ください。
ほかに聞きたいことが有ったら、Google＋やらFacebookやらTwitterやらで聞いてくださいませ。
またまとまったら書くかも。