新・携帯サイトの作り方：ラウンドアバウトコンセプト

スマートフォン対応：PCとケータイサイトを持っている場合

2011-09-13T22:05:00.000+09:00

PCと携帯サイトを持っている場合、スマホ対応後もこれまで通り携帯をサポートしなくてはなりません。スマホは、使い方は携帯と同じ、能力はPC並みというデバイスであるため、４つの選択肢があります。 ①スマホ専用サイトを開発し、PC/スマホ/携帯の３サイト ②モバイル（スマホ&携帯）サイトを開発し、携帯サイトは廃止し、PC/モバイルの２サイト（スマホ→携帯変換） ③携帯サイトを利用してスマホ対応し、PC/モバイルの２サイト（３キャリア変換） ④PCサイトを利用してスマホ対応し、PC&スマホ/携帯の２サイト（PC→スマホ変換JS）スマホ対応の目的を追求するなら、スマホ専用（①）かスマホ⇒携帯変換（②）スマートフォンを１つのメインデバイスと捉えてスマホ対応をするのであれば、スマホを直接ターゲットにする①又は②を選択することで、適切な操作性と情報量を持つ高いサービスレベルのサイトが実現できます

スマートフォン対応：PCサイトだけを持っている場合

2011-09-05T20:38:00.000+09:00

PCサイトだけを持っている場合、今後伸びていくスマホ対応の検討は、最初にモバイル全体に対してどのようなアプローチをしたいか判断することから始めます。モバイル端末である携帯とスマホですが、携帯は２種類あると考えることを奨めます。全ての買い替えユーザーがスマホになるのではありません。2011年時点ではスマホ買換え派は、まだ半数を超えないと予想されています。 ①iPhone/Android　...　約1,500万台。12年末には2,500～3,000万だとも。 ②ハイスペック携帯　...　約3.000～3,500万台。今後のDC/SB携帯は全て ③ロースペック携帯　...　約6,000～6,500万台。au携帯は全てここに入る（※台数の推計値は各種公表値から推定） ②ハイスペック携帯は、ハード的・性能的にはスマートフォンに負けないスペックを持っています。今しばらくは③から②への流れは

スマートフォン対応の目的と最適なソリューション

2011-09-02T16:55:00.000+09:00

現在、ラウンドアバウトは、スマートフォンサイトを作ってスマートフォンとケータイをフルカバーできる唯一のソリューションとして、多くの企業に導入されてきています。様々な検討の末、ラウンドアバウトを最適ソリューションとして選択してもらえた時は、非常に嬉しい瞬間です。重要なことの１つは、顧客がラウンドアバウトを正しく理解して、最適解として選択してもらうことです。選択後に誤ったソリューションだと気づくのは、両者にとって不幸です。そのようなことを防ぐために、ラウンドアバウトとそれ以外のソリューションが、どのように違うのか、ここで整理してみることとします。モバイル変換ソリューションやスマートフォン（以下スマホ）対応とインターネットで検索すれば、おおまかに次のようなグループに分かれます。【ソリューションの種類】 ① ３キャリア変換　製品・ASP ② スマホ→携帯変換　製品（ラウンドアバウト＆

スマホサイトでケータイも対応する－モバイルノウハウ不要編－

2011-08-23T16:55:00.001+09:00

スマホ＆ケータイサイト制作を先延ばしにされたことはありませんか？ [モバイルサイト専門ではない制作会社の気持ち] 今までにケータイサイト制作を先延ばしにされたり、先延ばしにしたことはないでしょうか？もし、心当たりがある場合は、その理由を思い出してみてください。費用対効果が合わない・読めない、モバイルを運用する人がいない、等々、先延ばしとなった理由は様々だったと思います。とはいえ、先延ばしになった事情の根底には「ケータイの特殊性」があったのではないでしょうか？同じモバイルでもスマートフォンは標準技術で制作可能同じモバイルでもスマートフォンサイトの制作であれば、制作する上での特殊な技術が少ない（PCと共通）のため、PCサイト制作を主とする制作会社としても積極的に取り組めるものだと思います。それに対して、ケータイサイトとなると、キャリア依存、機種依存の事象が多く、

スマホサイトでケータイも対応する－文字問題もCSS変換で解決編－

2011-07-26T14:00:00.000+09:00

文字が問題で、読みづらいサイトをスマートフォンに見せていませんか？ [スマホでは文字が小さ過ぎてPCサイトが見づらくありませんか] スマホユーザーがスマホを持ちたい理由のトップが「PCサイトにアクセスできるから」だそうです。しかし、実際にスマホでPCサイトを見ると文字が小さ過ぎて読めず、文字を拡大しながら読むと上下左右に移動しながらページ全体を閲覧することになるので、快適なブラウジングとは決して言えない状態になってしまいます。従ってスマホにはスマホに適したページを作るのがベストとなりますが、これをケータイで見ると、文字が大き過ぎて縦に長くなったりページ全体のレイアウトが崩れるなどの問題が出てしまいます。スマホとケータイはディスプレイの大きさが類似しているにもかかわらず、それぞれに適したサイズのページを用意しなくてはならないのです。 [スマホとケータイは文字サイズの見え方が違

スマホサイトでケータイも対応する－画像問題解決編－

2011-07-07T17:46:00.003+09:00

画像が問題で、スマホサイトとケータイサイトが１つにはならないと思っていませんか？ [ラウンドアバウトでスマホサイトをガラケーで表示した場合] スマートフォン基準のコンテンツからケータイも対応するコンセプトのモバイルコンテンツ変換「ラウンドアバウト」を使えば、画像のことは気にする必要はありません。通常、スマホ向けに高画質画像をたくさん使ったサイトをそのままガラケーで表示すると、画像サイズが大きすぎたり、１ページの容量が大きすぎたりで、下の画像のようにレイアウトが崩れるなど、トラブルが出てしまいます。 [スマホサイトをガラケーでそのまま表示] しかし、スマートフォン向けのサイトをガラケーにも展開できる「ラウンドアバウト」は、２つの強力な画像変換機能を搭載しているので、こうしたレイアウト崩れなどの画像に関する諸問題をすべて解決します。その２つの強力な機能とは

スマートフォンとラウンドアバウト ⑥iPadで見せた将来性

2010-06-23T09:00:00.003+09:00

iPadに一度触れると大概の人は、その魅力に取り付かれてしまいます。その使い易さやコンセプトも素晴らしいですが、我々を魅了する理由は、我々に未来を感じさせてくれるからでしょう。だから、我々は”Web&MobileマーケティングEXPO”においてラウンドアバウトをiPadで説明しようと考えました。展示会では、iPad/iPhone/Android/3G携帯/2G携帯が、全て同じようにRichな表現できることを示し、大好評を博しました。最初のリリースからおよそ２年を経て、ようやくラウンドアバウトの持つスマートフォン対応が、マーケットに受入れられた瞬間でした。ようやく時代が製品に追いついたと言ってもよいでしょう。今はスマートフォンをどう扱うか、iPadをどうするか、不確実な未来を予想しながら、多くの企業がその対応を考え始めています。トレンドに敏感な企業では、iPhoneアプリを

スマートフォンとラウンドアバウト ⑤標準ブラウザーの秘めた能力を引き出す

2010-06-14T09:00:00.005+09:00

スマートフォンは携帯電話の一種なので、サイトを２つ作っても対象ユーザが増えるわけではありません。２００９年末の状況は下左図の通りです。伸び行くスマートフォンマーケットをターゲットにしたいけど、多数派の３G携帯も重要だし...スマートフォン用のサイトは３Gでは見えないし... ちょっと待って！実は携帯の標準ブラウザーだって、十分な表現力があるんです。右の写真は４年位前のQVGA端末での表示です（ラウンドアバウトのカタログの写真）。これを見れば、随分以前からブラウザーの表現能力は非常に高かったのが分かります。つまり、ブラウザーの表現能力に関して言えば、3G携帯とスマートフォンには、大きな差はなく、一部は3G携帯の方が高い場合さえあるのです。携帯サイトは貧弱、携帯の回線は遅い、携帯サイトの閲覧には高い料金がかかる、そう考える人は多いのですが、それらはすでに過去の話です。

スマートフォンとラウンドアバウト ④スマートフォンの課題

2010-06-11T09:00:00.013+09:00

タップ・フリック・ピンチアウト＆イン...その操作名は覚えていなくとも、iPhoneが実現しているマルチタッチ・インターフェースは真に画期的で、誰でもすぐに操作を覚えてしまう優れものです。ユーザーは小さな画面に映るPC用のWebを、伸ばしたり縮めたり、追い払ったり引き寄せたり...優雅なモバイル生活を満喫できるようになりました。 ■（左から）iPhoneでのページ全体、部分拡大、Flashは見えない（上部の青い点の空白部）ところが、いくつか都合の悪いことも見えてきました。第一に、如何に優れたインターフェースがあっても、3.5インチのディスプレイでは、PCサイズのサイトはあまり見易くはないということ。第二は、Flashがサポートされないことです。　１．ページ全体の閲覧では文字が小さすぎ、拡大すると全体像が見えない２．転送量が多いので1ページが出るまでの時間が遅い３．Flash

スマートフォンとラウンドアバウト　③iPhone快進撃、XPERIA追撃。スマートフォンは一般化へ...

2010-06-09T09:00:00.003+09:00

2009年のiPhoneの目に見える大成功は、スマートフォンに懐疑的な人々、そして行き着くまで来た感のある携帯電話機に、新たな未来を感じさせることになります。また極めて重要な個人ツールである携帯は、ブランドも重要であり、そこでドコモが出したのが、ドコモから撤退していたSony/Ericsson のAndroid端末、Xperiaです。ブランド力、デザインも格好よく、プロモーションも大々的に行い、Docomoから出たこともあり、これは売れました。漸く、iPhoneに対抗できるスマートフォンが出たと言えます。今年に入り、スマートフォンは多くの機種が出ています。 04 Xperia (docomo/Android/Sony Ericsson) 04 Desire (softbank/Android/HTC) 05 IS01/IS02 (au/Android/Sharp) 05

スマートフォンとラウンドアバウト　②Android端末よりiモード2.0

2010-06-07T08:00:00.003+09:00

アップルは基本的に１国１キャリアというルールがあるので、ドコモが急いで出したのが、HT-03AというAndroid端末です。iPhone3Gから遅れること丁度1年、2009年7月でした。またアップルもiPhoneの改良版iPhone3GSを、2009年6月に出しています。【ドコモ初・日本初のAndroid携帯 HT-03A】ところが、実は2009年の携帯端末関連で、おそらく最大の話題となったのは、Android端末よりも、iモードブラウザがFOMA始まって以来の仕様拡張をしたことです（iモードブラウザ2.0）。ラウンドアバウトは、その対応に僅か3日しか掛かっていません。それもそのはずで、何も変更しなくても新ブラウザーに対応できしまうので、確認とプレスリリースの時間だけだったのですから。 iモードブラウザ2.0の仕様は強力です。ほとんどフルブラウザと言える内容にまで進化しています。

スマートフォンとラウンドアバウト　①生粋のスマートフォン対応だったが...

2010-06-02T22:11:00.002+09:00

今日、ラウンドアバウトHPのTOPを更新し、スマートフォンに関するページを追加しました。 http://www.symmetric.co.jp/roundabout/index.php http://www.symmetric.co.jp/roundabout/smartphone.php スマートフォンを前面に押し出していて、俄かにスマートフォン対応をしたように思われるかもしれませんが、実は、「生粋のスマートフォン対応」なのです。スマートフォンへの対応はラウンドアバウトという製品にとって、あまりに自明な特性であり、そこを特に強く訴求するが無かっただけなのです。それには理由があり、そしてここに至るには長い道のりがありました... ラウンドアバウト1.0が発売されたのは、2008年7月。それは、iPhone3Gが発売された月であり、翌8月にはデモページをiPhone対応として発表

携帯サイト制作の実践ノウハウ：iPhone用の画像で操作性を一層向上させる

2009-12-08T09:00:00.015+09:00

前回は、CSSプロパティをiPhone用に設定することで、使いやすいページにアレンジする方法を説明しました。今回は、よりiPhoneでの閲覧や操作に向いたデザインの作り方について説明していきます。 1. 押しやすい画像のボタンに変える小さい画像や高さのない画像を使ったボタンは、携帯には適していてもiPhoneでは指タッチがしにくいので改善が必要です。iPhoneでの操作を考慮する際、ボタン画像は適度な大きさと高さがあることが望ましいです。例えば下の例のように、二種類の画像を用意します。iPhoneからのアクセスかどうかによって画像ファイル名を切り替えるような変換ルールを変換シートに記述すれば、それだけでも操作性を上げることができます（変換シートについては過去のエントリを参照してください）。（用意する画像の例 - 通常用とiPhone用）（変換ルール記述

携帯サイト制作の実践ノウハウ：CSSでiPhoneで操作しやすい携帯サイトを作るコツ

2009-12-07T09:00:00.007+09:00

前回のエントリで、ラウンドアバウトの変換シートを使いiPhone専用の外部CSSファイルを使うことができると説明しました。今回はiPhone向けにデザインや操作性を改善するCSSプロパティについて、少し詳しく説明していきます。 1. bodyの余白を作らないまず下の画像を見てください。iPhoneでは左に余白ができてタブメニューに折り返しが発生しています。ラウンドアバウトは横幅320ピクセルのiPhoneの画面サイズに合わせ、画像を縮小している（大きさは正しい）のですが、iPhoneのMobile Safariではブラウザ表示領域とコンテンツの間に数ピクセルの余白ができるため、このように見えてしまっています。この余白はbody要素の余白サイズを0にして調整できます。一口に「余白」といってもmarginとpaddingとありますが、Mobile Safariについては

携帯サイト制作の実践ノウハウ：ラウンドアバウトでリッチで快適な携帯サイトをiPhoneにも

2009-12-03T09:00:00.011+09:00

ラウンドアバウトでiPhoneに対応した携帯サイトを作る際、おさえておきたい制作のコツについて説明していきます。 ●VGA基準で制作 iPhone対応に限らず、ラウンドアバウトで作る携帯サイトでは常にお勧めしていることですが、VGA端末をターゲットにページレイアウトを作ります。 iPhone のブラウザ幅（縦向き・portlaitモード）は320ピクセルです。従来では一般的なQVGA端末（横幅240ピクセル）では、iPhoneの画面では全体的に小さい内容表示になります。480ピクセル基準で作った画像はラウンドアバウトが自動的に縮小してデザインレイアウトを保持するので、画面に合った大きさで見せることができます。なお、ラウンドアバウトは、iPhone端末の画面サイズを320×480ピクセル（portlaitモード）として画像を縮小します。 ●viewportの設定

携帯サイト制作の実践ノウハウ：iPhoneで携帯サイトが見たい！に応える

2009-12-02T09:00:00.001+09:00

iPhoneには高性能なフルブラウザ（Mobile Safari）があるので、iPhoneからのアクセスはPCと同じとするサイトが多いようです。iPhoneには容量オーバーエラー（メガバイトレベルは別として）やマークアップ言語の差異といった携帯固有の問題が生じませんが、本当にPCとiPhoneが全く同じデザイン・コンテンツでよいと考えてもよいのでしょうか？例えば下はiPhoneからアクセスしたPCサイトです。ページ上部のFlashコンテンツが表示できておらず、内容全体が一見しては読めないほど小さく表示されています。 iPhoneでは縦の場合約３分の１に縮小表示されるため、読みづらく指でのリンクやボタンの操作がしにくいということも、iPhoneで見るPCサイトによくある問題の一つと言えます。こうしたこともあってか、iPhoneに機種変更したことで（PCブラウザ拒否設定などにより）

携帯サイト制作の実践ノウハウ：CSSで背景画像を付ける

2009-12-01T09:00:00.001+09:00

ラウンドアバウトの画像変換は、img要素の画像に限りません。変換対象となる画像は次のとおりで、今回はラウンドアバウトを使った背景画像デザインを取り上げます。インライン画像（img要素のsrc属性）背景画像 background属性 background、background-imageプロパティフォームのイメージボタン（input要素のsrc属性）リストのマーカー画像（list-style-imageプロパティ）画像へのリンク（a要素のhref属性）背景画像のCSSプロパティですが、本当はdivやtable関連要素にも変換対応しています。ただ、ドコモがbody要素にしか背景画像のCSSプロパティに対応しないので、３キャリアで背景画像を使う場合は実質body要素だけということになります。背景画像を使ったデザインは淡い色調のパターン模様がよく使われます。例えば、下の画面

携帯サイト実践ノウハウ：auで発生する「画像の隙間問題」を解消する

2009-11-30T09:00:00.001+09:00

ブロック要素に背景色を付けるデザインは、ページにメリハリを付けるのに効果的なのでよく使われますが、auではたびたび「隙間発生問題」という意図通りの表示がされない問題にも遭遇します。詳しくはsympleブログのエントリーで解説されていますが、このエントリではラウンドアバウトが用意している拡張タグを使った実例を紹介します。この拡張タグを使うことで、キャリアによってdivとtableを書き分けるという煩雑なことをせず、シンプルなソース記述で隙間の発生を防ぐことができます。隙間が消せないというデザインの限界・制約を乗り越えられるので、画像同士やブロック要素を隙間なく並べたデザインが簡単にできるようになります。隙間を解消するラウンドアバウトの拡張タグ「ra:field」「ra:area」は、

携帯画像変換・ラウンドアバウトの実力：価格の比較

2009-11-26T09:00:00.005+09:00

機能が横並びで差別化しにくい商品であるほど、価格（安い）が売り文句になってしまいますが、携帯画像変換もその様相を呈してきています。価格は、機能・価格構成・隠れコストなどの違いがあり、単純比較は危険ではあるけれども、あえて２つの指標で比べて見ます。なお、R.A.は、ラウンドアバウト従量版ライセンスを示しています。このデータは最新のものを確認したわけでもありませんし、全てのプランでの最適化も図っていません。また、比較の為に単位を合わせたりもしています。ということで、あくまでレンジの目安程度の扱いです。月間100万AC（アクセス）という指標も不利・有利になるので、くどいようですが参考です。 ■ラウンドアバウトの300万アクセスの本当の数字比較させてもらった他社サービス・製品については、解説する立場にはありませんが、ラウンドアバウトの300万アクセスについて解説します。

携帯画像変換・ラウンドアバウトの実力：機能の比較

2009-11-25T09:00:00.002+09:00

携帯画像変換の製品やサービスでは、色々な機能を謳っていますが、メイン機能となる自動変換機能と、必要であれば利用する手動（指定）変換の２種類に大別できます。基本的に自動変換機能は、何もしなくても全ての画像に対して必要であれば施される機能であり、手動変換は必要な際に何らかの特別な指定を行って実現する機能です。 □自動変換・基本この機能は、端末の画面サイズと対応フォーマットに合わせて行われる変換であり、この機能があるものが、「携帯画像変換である」といえるものです。基本の中でも、アニメGIFをサポートだとか、プログレッシブJPEG対応だとか、細かな対応の違いはあります。新たな携帯端末の属性が自動で配信され、何もしなくても自動で行われる基本の変換です。 □自動変換・拡張この拡張機能があるものは、ラウンドアバウトだけです。この２つの機能は、画像が載っているHTMLを読み込むために可能

携帯画像変換・ラウンドアバウトの実力：方式の比較

2009-11-24T09:00:00.002+09:00

実は、携帯コンテンツの開発に当たり、最もポピュラーなサービスは画像変換サービスです。コンテンツ変換は画像変換機能を含みながら、システム構成や料金レンジから別カテゴリーとして認知されてきました。しかし、ラウンドアバウトはシステム構造と新・従量版による料金体系から、携帯画像変換というカテゴリーとしても非常に魅力的な製品となっています。まずは、携帯画像変換の製品やサービスにはどんなものがあるか、分類してみます。主な方式だけでこれだけあり、それぞれ一長一短があります。それぞれのシステム特性を見ながら比較してみたいと思います。画像変換ソリューションはHTMLコンテンツ変換のように複雑ではありません。文書解析やURLのパスの解釈などの問題や、HTTPヘッダーについて必要な知識も遥かに小さなものです。つまり、これらに起因する問題もそれほど多くはありません。その結果、様々な形式には優劣と

従量プランを定額化する、新・従量プラン

2009-11-20T09:00:00.004+09:00

従量性のサービスは「使った分だけ払う」という点でリーズナブルですが、それでも３つの弱点があります。サイトの規模が大きくなるとどんどん固定費が膨らんでいく掛け捨て方式費用が変動するので予算が組み辛い料金レンジに対して無駄が発生するラウンドアバウトでは１．についてはWeb版への移行パスを用意して解決しています。残る２点についても解決を図っています。 ●従量課金の問題点 ●ラウンドアバウトの解決策 ■アクセス数の平準化による、月次コストの適正化これは一括前支払い優遇として提供されます。例えば６ヶ月分を一括前払い（５ｘ６＝３０万円）すれば、６ヶ月間のアクセスが、５・７・２６・３１・３６・５５万とすれば、平均２７万アクセスとなります。月締めであれば、０・０・０・１０・１０・３０と合計５０万PVに当る超過料金が掛かります（ラウンドアバウトは１０万PV毎の超過料金設定

ビジネスリスクをヘッジする：種蒔きライセンス”Seed”

2009-11-18T09:00:00.001+09:00

所有リスクは少なくとも「ビジネスリスクはクリア」している時の問題です。しかし、多くのビジネス、特にWebましてや携帯であれば、ビジネスリスクがはっきりしないことが非常に多いです。「まずは費用を掛けないでトライアルしてから投資判断したい」というケースが殆どではないでしょうか？その時、コンテンツ変換製品を使えば、簡単にできたりもっと可能性を追求できたはずが、貧弱なプロトタイプの為にそのビジネスアイデアを正当に評価できなければ、非常に残念なことです。そこで生まれたのが、”roundabout Seed”です。一言で特徴を言えば、「無料」なのですが、ユーザーが蒔くビジネスの「種」、そしてシンメトリックとしては製品普及の「種」になるという意味から、”Seed”と名づけました。 ■Seedがターゲットする用途携帯ビジネスのプロトタイプ携帯サイトデザインのユーザビリティ・テスト社内など

所有リスクとコストを減らす：スモールスタート＆出世払いの新・従量モデル

2009-11-17T11:00:00.005+09:00

「ラウンドアバウト導入済みホスティング」を選択できないケースでは、ソフトウェアライセンスを購入し導入する必要があります。Webサイトはビジネスが確立するまで時間が掛かり、爆発的にヒットする場合も、逆に場合によっては撤退するケースもある世界です。システム開発自体の初期コストは実際にかなり工数も掛かるので、工数が発生しない製品などは「出世払い」にして欲しいのが本音です。現状を図にすればこんな感じです。初期のコストを考えれば役に立つ製品を使わない選択をするケースも多くなってしまいます。しかし開発・運用コストが上がってしまえば、利益モデルが確立する時期も遅れてしまいます。ラウンドアバウトの新・従量モデルはこれを解決するライセンスモデルであり、一言で言えば、「出世払い」できるライセンスの利用形式です。 ■出世払いライセンスモデルとは？詳しく、正確な情報は、ここをご覧ください

導入・所有コストを無くす：だから、ラウンドアバウト導入済みホスティング

2009-11-16T09:00:00.001+09:00

現在ITの世界でのはやり言葉、クラウド・SaaS・XaaSですが、その流れの中には「導入・所有コストの削減」が大きな目的になっています。salesforce.comが、”Success,Not Software”といって一定の支持を得ているのも、必要なものを必要なだけ使い、使った分だけ支払うということが、１つの流れになってきているのだと思います。ラウンドアバウトはソフトウェア製品なので、”Not Software” だけだと語弊があって困りますが、実際に所有コストは非常に高くつくものです。これは、ライセンス・保守費などの見えるコストではなく、学習コストと同様に見えないコストです。製品の調査・選定・見積・決済まで決定に至るプロセスの確定・承認コスト購入後の発注・納品・導入・確認の入手・設定コストソフトウェア権利の保管・保守更新の事務コストソフトウェアのバグフィックスやデータ

導入容易性を上げるために：学習コストとビジネスモデル・ミスマッチ

2009-11-13T09:00:00.001+09:00

製品開発の悩みの１つは、導入可能性と導入容易性のジレンマです。一般に強い支持を受けるほどターゲットは狭くなると思いますが、システムも同じで特定のシステムへの親和性を強めるとそれ以外のシステムでは使いにくくなってしまいます。ラウンドアバウトが現在CentOS上のApacheモジュールをプラットフォームに選択したのは、Webサーバーの環境としては一番のシェアがあるからです。それでも日本でそのシェアは50%前後のようです。今は残念ながら残りの半分はあきらめるざるを得ません。RH系Apache環境では、Apacheと一体となって動くことで、システム的には圧倒的に高い導入容易性を誇ります。しかし、導入容易性はシステム特性ばかりではありません。ラウンドアバウトでは、４つの切り口でさらに導入容易性を高める施策を打ち出しています。 ■４つの切り口学習コスト：製品利用に対して必要とされる

Apacheモジュールである圧倒的なパフォーマンス上の優位性

2009-11-11T09:00:00.004+09:00

通常のWebアプリケーションにおけるHTMLはキャッシュできないので、Apacheモジュール型のラウンドアバウトは、サーバー型（リバースプロキシー型とも言う）に比較して圧倒的に有利です。更に言えば、多くのシステムのフロントエンドにはApacheが配置されています。つまり、ラウンドアバウトは既に起動しているプロセスの中で１つのファンクションコールとして動作するという、パフォーマンス上圧倒的な有利な位置にいます。ラウンドアバウトはプロセスの起動も管理もメモリ管理さえも既に起動したApacheからのサービスを受け、独自のIOも殆ど無く、ネットワーク通信も発生しません。つまり、サーバー型がラウンドアバウトにパフォーマンスで勝つには、少なくとも以下の要件を満たす必要があります。ラウンドアバウトの言語変換の処理時間＞サーバー型における、通信時間、プロセス管理、言語変換の処理時間

コンテンツ変換でHTMLキャッシュありのパフォーマンスは意味が無い

2009-11-10T09:00:00.002+09:00

前回のエントリーで書いたように、同じコンテンツとして保証できない、またユーザーアクセスをアプリケーションに届けなければいけないために、HTMLはキャッシュしてはいけないので、変換後のHTMLキャッシュを基準にパフォーマンスを計測することは、意味がありません。特定のコンテンツが、ユーザーセッションも使わず静的と確定しているケースであれば、HTMLキャッシュをしても良いかもしれません。それでも幾つかの問題があることを認識しておかなければなりません。カウンターのようなCGIはその時、動作しないアクセスログに残らないその上、変換後のHTMLキャッシュを別サーバーのコンテンツ変換同士で共有することは、アプリケーション・セッションの混在を招く恐れがあり、非常に危険です。セッションの混在は、最悪の場合、個人情報などが他ユーザーに漏れる可能性もあります。おそらく、これらのリスク

HTMLをキャッシュしてはいけない

2009-11-09T09:00:00.004+09:00

コンテンツ変換システムでは、パフォーマンスを確保するためにキャッシュをどのように設計するかは重要な設計方針です。画像については幾つかのエントリーで触れていますが、ここではHTMLについて考えてみます。最初に単純な問いかけを想定します。 ”http://ra.jp/index.html”というアクセスは常に同じコンテンツとなるか？答えは”NO”です。なぜ、同じURLなのにコンテンツが同じではないのか？それは、”http://www.mobile.co.jp/index.php”であれば、違うことが納得いくのと同じ理由です。つまり、現代のコンテンツのほとんどは動的なページであり、ユーザーの履歴やその時のサイトの状況や時間などによって、刻々とコンテンツの中身が変わります。アプリケーションのセッションや、クエリーパラメータ、クッキーの値、POSTデータなどなど、同じURL/

携帯サイト制作の実践ノウハウ：コンテンツ変換をカスタマイズする２つの方法

2009-11-06T09:00:00.036+09:00

ここ数回のエントリーで、「PI機能」や「変換シート」を利用してコンテンツの表示コントロールをする方法を紹介しています。どちらもカスタマイズが可能なコンテンツ変換機能ですが、今回はこの２つの機能の違いや使い分けについて説明します。 ●PI機能を使った変換イメージ ●変換シートを使った変換イメージまず大きな違いは、上の絵のように、「PI機能」はコンテンツの部分ごとに書き分けられるCASE式のようなもので、「変換シート」はサイト内で一括管理される変換設定である、という点です。また、画面サイズやGPS対応/非対応など、機種スペックに応じた出し分けが可能なのはPI機能だけということも、決定的に違うところです。２つの機能にはそれぞれ次のような特長があります。 PI機能の特長機種の属性やスペックを出し分け条件に使えるので、細かい出し分けが可能 HTMLに記述すればサイト

携帯サイト制作の実践ノウハウ：破線や色付きの区切り線をhr要素で表示する

2009-11-05T09:00:00.087+09:00

以前外部CSSでのエントリーでも触れましたが、区切り線（hr要素）はキャリアごとにCSSプロパティの効き方が異なるので、破線や色で装飾したhr要素を３キャリアで使うのは大変です。hr要素の代わりにいっそ画像を使うというのも一つのよい判断です。しかし画像にしたらしたで、src属性を書くことでHTMLソースが長くなります。区切り線はサイトの中で頻繁に使うものなので、

そのままの記述で簡単に画像が表示できたらなぁと思いませんか？できます。ここ数日のエントリーでも紹介している、変換シートを活用することで可能です。区切り線画像を用意し、次のイメージタグの記述を、変換シートに記述します。 ●区切り線変換ルール（イメージ）変換元キーワード

変換後ドコモ

携帯サイト制作の実践ノウハウ：キャリア別にメール受信設定リンクを出分ける

2009-11-04T09:00:00.028+09:00

空メールを使った携帯サイトやサービスがよくあります。迷惑メールを懸念し携帯ドメイン以外のメールアドレスからの返信を拒否するユーザーも多いので、ユーザー離脱を起こしやすいです。こうしたユーザーに配慮し、ドメイン拒否指定をの解除がしやすいように、メール受信設定が行えるキャリアのURLにリンクを貼るなどします。ラウンドアバウトのない静的なHTMLでは３キャリア分のリンクを列挙することになります。違うキャリア用のリンクを踏むとエラーになるので、ユーザビリティを考慮して出し分けしたいところです。前回書いたように、ラウンドアバウトではPI機能または変換シートの２つの方法で出し分けをすることができます。 ●PI機能を使う場合以下のサンプルのように、キャリアを出し分け条件にしてPIを記述します。（XHTMLソース） ﾒｰﾙ受信設定は

携帯サイト制作の実践ノウハウ：プログラムレスで全角カタカナを半角カタカナに変換・表示する方法

2009-10-30T09:00:00.004+09:00

PCでは見やすい全角文字も、携帯では表示可能な幅が小さい関係上、縦に長くなりやすく見難くなるので、半角カナがよく使われます。全角を半角に変換する作業を人手で行うのは大変です。特にPC・携帯でデータソースを共有したりコンテンツ量が多い場合は、変換処理を行うアプリケーションが必要になります。ラウンドアバウトでは変換ルールにカスタムルールを追加することができるので、こうした全角カタカナを半角カタカナに一括置換することもプログラムレスで可能です。ラウンドアバウトの言語変換はHTMLの構造変換ではなくキーワードに一致するテキストを置換する仕組みで動作しますから、全角カタカナを半角カタカナに変換するというような、マークアップ以外のニーズにも応えることができます。「ア」→「ｱ」、「イ」→「ｲ」・・・「ン」→「ﾝ」と、カタカナ１文字ずつについて変換ルールを用意し、CSV形式の変換

携帯サイト制作の実践ノウハウ：マルチキャリアで見えるコピーライトマーク（©）の出し方

2009-10-29T09:00:00.002+09:00

コピーライト「©」や登録商標「®」のような文字参照は、auでは「C」「R」と表示されます。下のように英字テキストと接したところが「R」や「C」になってしまうと、ユーザーに正確な情報が伝えられないので困り者です。（W61Kでの登録商標マーク、コピーライトマークの表示）ラウンドアバウトのデフォルトの変換シートには、一部の文字参照について変換ルールが盛り込まれています。auはコピーライトや登録商標の絵文字があるので、「©」「®」をそれぞれ絵文字に変換します。この他にも変換させたい表記があれば、必要に応じて変換シートを編集し対応させることができます。反対に、意図通りに表示できない文字を文字参照に変換させるルールを記述し、うまく表示させることも可能です。例えばこのブログエントリ「iPhoneでブラウザに円記号を表示するには？」にあるように、

携帯サイト制作の実践ノウハウ：ドコモ絵文字を本来の色で見せたい

2009-10-28T09:00:00.005+09:00

デフォルト（青）以外のリンク色が設定されたページで、リンクテキストに絵文字を使うと、ドコモでは絵文字の色がリンク色と同じになります。リンクに限らず通常のテキストに色指定した場合も同様のことが起きます。これでは絵文字の装飾が際立たず、見栄えもしません。本来の絵文字の色に戻すには、下のソースのようにspanタグ（XHTMLの場合）かfontタグ（CHTMLの場合）で文字色を指定する必要があります。（XHTML） 注目ｺﾝﾃﾝﾂ
└新作Xmas限定ｼﾞｭｴﾘｰ

どこまでも拡張できる超大規模システムを目指して

2009-10-27T09:00:00.001+09:00

"THE MAGIC ROUNDABOUT"というものがあるそうで、ラウンドアバウトがいくつも連結しています。大きな地図で見る運転するとなれば、これはちょっとびびりますね... 携帯コンテンツ変換のラウンドアバウトでは、大規模システムをターゲットした製品です。大規模システムに要求されるシビアな品質と拡張性こそ、ラウンドアバウトが実現している比類なき特性です。大規模システムにおいては、まず拡張性です。システムが拡張できないことには大規模にそもそもなりません。大規模システムは、トラフィックが多く、アプリケーションが複雑です。サーバーの台数も種類もネットワーク機器も多く、回線も複雑です。このようなシステムにミドルウェアを導入しようとすれば、機能以外のシステム要件は次のようになるでしょう。・ネットワークに影響しないこと、アプリケーションに影響しないこと、他のミドルウェアに

快適な交差点→安定して高速な変換システムを目指して②

2009-10-26T09:00:00.001+09:00

通行量が適切であると、実際のラウンドアバウトでは不思議なくらい、うまく機能するようです。携帯コンテンツ変換のラウンドアバウトでは、大量の通信が発生しても常に安定的なサービスが出来るように不断の努力をしています。（前回の続きです） ■安定性の確保。メモリ消費量を減らすこと。実装のアイデアは色々ありますが、安定性を確保するため１つだけ方法を挙げるとすれば、とにかくメモリ消費を抑え込むことです。どんなシステムでもスループットの限界がありますが、メモリ消費を少しでも抑えれば、当然スループットの限界値がUPします。Apacheのようにマルチプロセス・マルチスレッドのシステムでは僅かな節約でも大きなリターンがあります。幸いApacheにはAPRという優れたメモリ管理ライブラリがあるので、これを使うことで安全でパフォーマンスが高く、仕様の安定した標準化されたコードを書

快適な交差点→安定して高速な変換システムを目指して①

2009-10-23T09:00:00.003+09:00

パリの凱旋門はもしかしたら一番有名なラウンドアバウトかもしれません。大きな地図で見るそこでも、交通量が増えてくると、ノロノロの渋滞も起きるようです。携帯コンテンツ変換のラウンドアバウトでは、このようなことが無いように設計・実装されています。ラウンドアバウトでは、システムのパフォーマンスと安定性は表裏一体、という考えに基づいた設計・実装をしています。優秀な実装のソフトウェアであれば、トラフィックが少ない時にパフォーマンスが良く、扱うケースが少なければ高い安定性を維持できることでしょう。しかし、ラウンドアバウトに要求されていることは、TV連動や携帯メール一斉配信のような極端なピークが発生し、豊富な画像が配置された言語不定の入力を全携帯端末に配信するような非常に複雑な処理を、高いパフォーマンスと安定性で実現することです。 ■Apacheモジュールとして実装した理由。

事故の無い交差点→ロバストなシステムを目指して

2009-10-22T09:00:00.003+09:00

本当のラウンドアバウト（交差点）の運転は、最初は非常に難しいらしい（人伝の話ですが）です。なかなか入れない、下手をすればグルグル回ったり、違うところへ出ちゃったり...経験が無くても想像はつきます。最悪、事故になることもあります。でも、コンテンツ変換エンジンである製品では、事故はどうしても防がなければなりません。これが「ロバストなシステムを目指す」の意味するところです。携帯サイト開発・運営では事故が日常茶飯事です。事故が多ければ、安全運転が必要になり、たくさんのルールができます。ルールはできても守れなければ意味がありません。そして、携帯サイト開発では、このルールが複雑すぎて守れる人が少なく、これが大きな問題です。ラウンドアバウトのアプローチはルールの強化ではありません。むしろ、ルールの撤廃です。ルールが必要なのは、ある制約が存在しているためにそれを回避する術です。

“ラウンドアバウト（roundabout）”という名の由来

2009-10-21T09:00:00.001+09:00

「ラウンドアバウト」という名前は多くの日本人にはなじみ名の無い単語だと思います。なぜこんな名前をつけたか、名前に込めた意味を書こうと思います。ラウンドアバウトとはイギリスなどにある交差点の形につけられた名前です（回転木馬と言う意味もありますが）。こんな交差点です。そう、最近のラウンドアバウトBLOGの表紙のGoogleMapで表示されているものです。動きますので、拡大していけばどこだか分かります。この交差点は見て分かるとおり、たくさんの道が交錯しているのに関わらず、信号がありません。ラウンドアバウトという交差点は、様々な道から道へ自由に行くことができながら、基本的には一般的なルールをうまく適用するだけで、信号のような制約と投資をすることなく、複雑な方向変換を効率的に機能させます。携帯コンテンツ変換エンジンを開発するに当って、「様々な制約を取り払って、極めて効率的な

携帯サイト制作のヒント：クローラーをキャッチしSEO対策をしやすくする

2009-10-20T09:00:00.022+09:00

カスタマイズ可能な端末グループの１つ、「クローラーグループ」は、携帯サイトのクローラー対策に役立つ端末グループです。クローラーのUser-Agentを設定ファイルに書いておくと、クローラーからのアクセスが判別でき、PIやアプリケーションでクローラー向けの処理を書くことができます。 ●クローラーグループの設定クローラーグループを設定するファイルはCSV形式のテキストファイルです。クローラーグループ名,ユーザーエージェントパターンユーザーエージェントパターンの比較方法に関する詳しい解説については「開発リファレンス」を参照してください（デベロッパーコネクションにて公開中）。ラウンドアバウトには以下のクローラーグループが予め設定されています。サイト開発者で追加・変更も可能です。CSV形式なのでExcelなどを利用して簡単に編集できます。 crawlerFroute,*

携帯サイト制作のヒント：端末グループを使いこなす

2009-10-19T09:00:00.007+09:00

PI機能で使える条件式には、ラウンドアバウトが持つ機種情報の項目名以外に「端末グループ」を使うことができます。またリクエストヘッダ「X-RA-Device-Group」から取ることもでき、アプリケーションの開発サポートとしても活用できる機能です。端末グループはいくつかの機種をグループ化したもので、デフォルトではラウンドアバウトが定義するグルーピングだけの状態ですが（システム端末グループ）、この他にユーザー定義のグループを作ることができます。ユーザー端末グループクローラーグループ ※クローラーグループは次回のエントリで紹介します。 ●ユーザー端末グループ PIをユーザー端末グループとして設定ファイルに書くことができます。繰り返し使う記述や複合条件で長くなった記述を書いたり、記述が将来変わる可能性がある場合に集約させることができます。（端末グループ設定ファイル）

携帯サイト制作のヒント：PI機能で表示コントロール

2009-10-16T09:00:00.007+09:00

ラウンドアバウトの機能の１つに、アクセスした機種の属性に応じて、コンテンツ内の表示の一部を切り替える機能（PI）があります。出し分けたい内容をHTML上に記述すれば、条件にマッチする機種にのみ表示させることが可能です。 PIとはProcessing Instructionの略記で、XML文書中に特定のソフトウェアへの命令を埋め込む、処理命令のための記述です。で表され、PHPではこのPIが使われています。ラウンドアバウトの表示コントロール機能はこのPIを利用しているので、表示コントロール機能のことを「PI機能」と呼んでいます。 PI機能の利用シーンの一部待受画面幅・高さに応じた配布する待受画像ファイルを切り替える対応アプリの種類やバージョンに応じて配布アプリを切り替える Flash Liteバージョンに応じてFlashコンテンツの表示をコントロールする

携帯サイト制作のヒント：2ペインレイアウトをするには？

2009-10-15T09:00:00.002+09:00

ページを縦に分割する２ペインレイアウトは、一目で多くの情報を見せることができ、ユーザビリティ向上に効果的なレイアウトです。 PCサイトではdivなどのブロック要素にfloatプロパティを指定することで２ペイン・３ペインのレイアウトをしますが、携帯サイトではdivにfloatが効かず横に並べられないので、テーブルを使います。 ●XHTML・CSSのポイントテーブルの幅に100%のwidthプロパティを指定サブコンテンツ側のセルに30%程度のwidthプロパティを指定メインコンテンツ側のセルはwidthプロパティを指定しない（自動算出）テキスト装飾のCSSは、divかspan要素に記述するサブコンテンツ側には画像を使う CSSはもちろん外部CSSが使えます。最後の点ですが、ここがとても重要で、セル幅の狭いサブコンテンツにテキストを入れてしまうと、1行に4,5文字程度しか入

携帯サイト制作のヒント：綺麗な箇条書きを実現するには？

2009-10-13T09:00:00.002+09:00

箇条書きリストは情報を整理して見せるのに効果的ですが、PCサイトでは一般的でも携帯サイトでは使われません。下の例のように字下げ幅やマーカーの見た目の違いが大きいことや、ドコモはCSSプロパティでアレンジできることがほとんどないことから、見た目をアレンジしたくても３キャリアで同じような表示ができないのです。（画面：左からdocomo 904i、au G9、SoftBank 920P）ドコモはデザイン的に貧弱です。しかもマーカーの見た目が変えられないので対処できません。ソフトバンクだけやけに字下げし過ぎて短いテキストもすぐに折り返してしまいます。情報量がさほど多くなくてもスクロールがたくさん必要な縦に間延びしたコンテンツになりがちです。auはまあまあバランスがいいですが、マーカーとテキストとの間隔がもう少し狭くてもいいかと思います。そのため、リストを使うのはやめて単純に絵文字

ラウンドアバウト・ホスティングの存在理由

2009-10-09T09:00:00.000+09:00

ラウンドアバウト・ホスティングは、「コンテンツ変換製品やサービスは高すぎる」「携帯サイトを手作りするのは大変だ」という中で、もっと安く素晴らしいコンテンツが作れないと「モバイルはこれ以上発展しない」という危機感から生まれています。サービスコンセプトは次のようなものです。今やクラウドという時代にあって、サーバーや製品を個々のユーザーが購入する時代ではなくなってきています。そのような意味からもホスティングに組み込まれているのは、ユーザニーズにマッチした形といえるのではないでしょうか？多くの人にラウンドアバウトという新しいテクノロジーを活用してもらうにあたっては、製品単体売りという方式では自ずと限界があります。これは購入コストだけの問題ではなく、ミドルウェア製品（サービス）の調査や判断そのものが非常に難解であることです。だから、いっそ最初から最高のものが入っていれば、何も悩まないで済み

携帯コンテンツ変換ASP：プロキシ型携帯変換の限界

2009-10-08T09:00:00.003+09:00

敢えて単刀直入に書けば、次のようになります。「ドコモ端末用にコンテンツを作っているので、ドコモ端末は変換を通さずにアクセスする」という一見理に適ったように思える構成でも２つの疑問が生じます。ドコモ端末に生じる問題は解決してくれないのか？であれば、ドコモ端末での問題は自分で解決しなくてはならないのか？キャッシュ容量制限や端末毎の画面サイズ違いを吸収せず、CSSの使えないドコモが基準だとすれば、コンテンツ変換エンジンとしては、今後も多くの生産性向上は望めないことになります。今はドコモ端末FOMA用のコンテンツの開発方法を少しアレンジすれば、全てのキャリアで使えるXHTMLになるのは周知の事実です。唯一絵文字だけが解決できないので、なんらかの手段でこれを補完しているのが現状です。つまり... キャリア間の言語変換だけでは変換エンジンの意義は非常に薄いといえます。もちろん、

携帯コンテンツ変換ASP：プロキシ型の２URLとドコモ無変換の問題

2009-10-07T09:00:00.001+09:00

プロキシ型携帯コンテンツ変換ASPでは、２つのURLが存在します。１つは元のコンテンツのあるWebサーバで、もう1つが変換プロキシサーバです。多くの場合、まず本当のURLを持っているコンテンツサーバにアクセスし、au/softbankの時は変換サーバにリダイレクトされます。そして、この事がこの方式の問題となるケースがあります。プロキシ型変換ASPの場合には、本当のアプリケーションのあるサーバとプロキシサーバの両方がインターネットに出ているために２つのURLが存在します。また、コンテンツがドコモ端末基準で作られているため、一般にドコモ端末からのアクセスはコンテンツ変換サーバを通しません。このことは３つの点で有利です。最大シェアのドコモが通過しないので、顧客企業はその分従量コストが節約できるドコモ端末のパフォーマンス劣化が起きない ASPシステムキャパシティを節約できる

携帯コンテンツ変換ASP：コストと運用面の比較

2009-10-06T09:00:00.008+09:00

ASP利用では導入コストが低くても、運用コストが高ければ元も子もありません。課金体系について、ラウンドアバウト・ホスティングと変換プロキシ型ASPでは大きく異なっています。基本月額料金従量超過課金（1PV換算）ラウンドアバウト・ホスティング 2～3万円（共用）、10万～12万円（専用） ※サーバ、メモリ、ディスク、回線等のホスティングサービスを含むなしプロキシ型変換ＡＳＰ A：7.5万円（10万PV程度） B：25万円（100万PV）あり２者の大きな違いは、次の通りです。ラウンドアバウト・ホスティングは、サーバ回線など全てのコストが含まれているが、プロキシ型ASPでは別にサーバを立てなければならず、サーバ調達やラック代、またはホスティング費用が別途掛かります。ラウンドアバウト・ホスティングは、月額費固定なのでアクセスが多くてもコストが発生

携帯コンテンツ変換ASPの種類

2009-10-05T09:00:00.003+09:00

ラウンドアバウトや他社競合製品を導入する場合、自ら選定・テスト・購入・導入する必要が生じます。その手間を省くことができるのが、ASPです。ASPであれば、利用したい期間だけ使えたり、製品テストなどをする必要が無いので、気軽に導入が図れます。そして、携帯変換にもASPがあり、2種類あります。１つはラウンドアバウト導入済みのホスティング・サービスです。もう1つが従来の変換プロキシ型のASPサービスであり、２社から提供されています。1番の違いは製品比較同様、そのシステム構造にあります。ラウンドアバウト・ホスティングは、それだけで完結するサービスであり他には何も要りません。プロキシ型ASPでは、コンテンツが動作しているサーバが別途必要です。２つの違いは次のようまとめられます。プロキシ型は別途Webサーバが必要となるプロキシ型は2度インターネットを経由してアクセスされる携帯から

携帯サイト制作のヒント：行間が詰まって読みにくいので改善したい

2009-10-02T09:00:00.006+09:00

新着情報など一覧でテキストを見せるようなページで、行間が詰まっていると読みにくい印象を与えます。背景色の付いたボックスと接する箇所は特に余白が欲しくなります。 PCサイトではCSSのline-heightやmarginプロパティを使えばできますが、携帯サイトの場合、最も普及するiモードブラウザ1.0のFOMAではこれらのプロパティが効かず行間を調整できない事情があるので、画像を使った何らかの方法でしか余白を調整することしかできません。そこでスペーサー画像を各テキストの次の行に配置して隙間を作るテクニックが使われますが、XHTMLソースを見てください。（行間と、絵文字の両端に余白を作るためにスペーサーを配置した例）

フリースタイルな携帯言語変換：絵文字

2009-09-25T09:00:00.003+09:00

携帯絵文字はキャリアごとに種類や数も異なり書き方や互換性もバラバラなので、何らかの絵文字変換ソリューションの導入がコストを抑える手段と考えるのが一般的です。元コンテンツに最も使われやすいのはドコモのiモード絵文字です。絵文字入力ツールが用意され入力が容易なことや、絵文字の種類が最も少ないのでマッピングを考えたときiモード絵文字をベースに考えるのが最も都合がよく、逆を取るのは高コストになるからでしょう。こうした理由からか他の変換ソリューションの多くは変換元絵文字をiモード絵文字としているので、携帯サイト開発の現場で使うことのできる絵文字は自ずとiモード絵文字に限定されます。一方ラウンドアバウトですが、以下は絵文字を使ったサンプルです。全て同じ絵柄（ハート）ですがキャリアごとに違う色々な書き方を混ぜています。どの書き方もラウンドアバウトを通すことで同じ絵文字が表示されます。 ●

携帯コンテンツ変換の選定基準：お試し変換ソース

2009-09-24T19:17:00.004+09:00

携帯コンテンツ変換の導入を考えているなら、実際にどんなソースが動作するのか、試すことが必要です。開発や運用の負担がどれくらい減るのか、どの程度の表現力があるかは試さないと分かりません。ここでは、ラウンドアバウトでの特長が分かり、おそらく他のソリューションでは機種毎に見え方異なるだろう、シンプルでプレーンなhtmlを提示します。製品検討時には、是非こちらを試してみてください。 ①画像メニュー　...　画像を横並びにしたソースです ●HTML

フリースタイルな携帯言語変換：DOCTYPE宣言

2009-09-24T09:00:00.006+09:00

XHTMLでページを作る際XML宣言の他DOCTYPE宣言の記述が必要ですが、何も見ずに空で宣言をタイプする人は少ないと思います。そこでDOCTYPE宣言の内容を書籍やインターネットから調べるのですが、「携帯　XHTML　DOCTYPE」で検索すると、各キャリア向けのDOCTYPE宣言を解説するページがヒットします。キャリアごとに推奨するものが異なり、iモードの場合さらにiモードXHTMLバージョンに応じて記述が変わるので、「まとめ」と称しながら、種類が多くなっています。これを読んだサイト開発者としては結局どれを書けばよいのか悩んでしまうでしょう。またどれか一つDOCTYPE宣言を決めたら、記述するXHTMLもそれに従うべきなのか？と、さらに開発者を迷わせることになります。 ●iモードXHTML 1.0

フリースタイルな携帯言語変換：マーキー

2009-09-18T09:00:00.004+09:00

携帯コンテンツを作る際、マークアップ言語は何を使ったらよいのか？ラウンドアバウトでは次のように考えています。 XHTMLなら何でもOK CSS利用可能各キャリア向けXHTMLは互いに細かいところで違いが多くあるが、体系としてはほとんど一緒なので、ラウンドアバウトは何でも受け入れられます。「何でも」とは、「iモード向けでも」「au向けでも」と、何か一種類の統一されたマークアップなら何でもということに限りません。他のXHTMLが混在していても、さらにはXHTMLの途中にCHTMLの記述が混ざっていてもOKです。こんなルーズな感覚が実際の現場にとっては負担がないのです。キャリアごとのXHTMLやCSSプロパティの記述方法の違いで、複雑になりがちなものの一つに、マーキーの書き方があります。 ●3G向けﾏｰｷｰ

古い端末を非対応にしたい→RA非対応端末リダイレクト機能

2009-09-17T09:00:00.005+09:00

一応、もしかしたら使っているかもしれない古～い端末があります。どんものがあるのでしょうか？・ドコモ P501i　1999年発売　白黒表示　96x120ピクセル表示　5KBキャッシュ SSL非対応 N502i　2000年発売　4色表示　118x129ピクセル表示　5KBキャッシュ SSL非対応・ソフトバンク（2000年当時はJ-PHONE） J-T04　2000年発売　256色表示　96x90ピクセル表示　6KBキャッシュ SSL非対応 J-T04　2001年発売　256色表示　118x124ピクセル表示　6KBキャッシュ SSL非対応・au A3013T　2002年発売　65536色表示　144x135ピクセル表示　9KBキャッシュ SSL対応 A3012CA　2002年発売　65536色表示　125x147ピクセル表示　9KBキャッシュ SSL対応　２Gのユーザーも大事

携帯サイト開発の高コスト構造

2009-09-16T09:00:00.008+09:00

携帯コンテンツ変換ソリューションの導入の大きな目的はコスト削減です。どのコストがどの位削減されるかは、前提システムやコンテンツによって大きな差がでますが、開発・運用全体のコスト構造を考える必要があります。一般に開発費以上に保守費が大きな問題とされます。ラウンドアバウトのコスト削減に対するアプローチ、それは... 開発・保守を誰でも可能とし、専門知識を不要にすることで、人件費を抑えることです。手法は異なりますが、CMSにも通じる考え方です。コスト要因の最大の問題は人件費であり、人件費は専門性が必要とされるほど高くなります。自社や既存の取引先に開発や保守を頼めれば、コスト構造を大幅に改善することが可能になります。携帯サイトは一般にトラブルが多く、アプリケーションの保守にも細心の注意が必要です。このため、専門家や経験豊かな会社に頼むことが多く、逆に専門でない会社は消極的な姿勢に成

携帯コンテンツ変換の選定基準：環境構築と問題の切り離し

2009-09-14T09:00:00.015+09:00

携帯コンテンツ変換を検討するに当たり、機能や性能の他に考慮すべき事項に環境構築と問題発生時の対応があります。 ■環境構築について通常、４つの環境が関係してきます。本番運用環境本番試験（ステージング）環境　...　本番とほぼ同じ状態に保たれている試験環境開発環境　...　開発現場の結合テスト環境開発者ローカル環境（PC）それぞれの環境でアプリケーションが同じように動作しなくてはなりません。複雑な本番環境には、同様に複雑な環境を作っておかないと本番でしか出ない問題が起きたりします。ただ、試験や開発には本番と同じようにコストは掛けられません。この時、決定的な要素は、ソフトウェアか、ハードウェアか？と言う点です。サーバ型であってもソフトウェアであれば、本番と同等の構成を柔軟に構築できます。しかし、ハードウェアであると本番同等の環境を作ることは難しいでしょう。特に大規模

携帯コンテンツ変換の選定基準：変換エラーと変換アーキテクチャー

2009-09-10T09:00:00.004+09:00

コンテンツ変換システムにおいて、変換仕様はもちろん重要ですが、正しい記述で変換仕様にのっとった例） Hello　 →　Hello 実は、変換仕様「外」の振る舞いも、負けず劣らず重要です。間違った記述の変換仕様外の例） Hello 　　（存在しないタグ） Hello　　　　　　　　　　　(閉じてない)

Hello　(インラインタグ内にブロックタグ) このような例は、意図せぬミスや勘違いやバグなどから発生しますが、どのように処理されるべきでしょうか？やはり

携帯コンテンツ変換の選定基準：スループット

2009-09-09T09:00:00.005+09:00

パフォーマンス（1アクセスの平均レスポンスタイム）と並んでユーザにとって重要な指標がスループット（1秒間あたりの処理数）です。「同時接続数はどれくらいですか？」などとよく聞かれます。スループットはサーバ台数に直接に影響を与える数字です。当然、サーバ台数が少なくて済むように、より高い性能であることが望ましいです。１/スループット＝パフォーマンスなのですが、両者には別の相関関係があって、アクセスがスカスカの状態ではパフォーマンスは非常に良く、アクセスが増えてくれば徐々にパフォーマンスは劣化し、アクセスが増えすぎると両方落ち込みます。コンテンツ変換製品でもスカスカの状態では、パフォーマンスの違いは、あまり出ないかもしれません。問題はアクセスが増えてきてからで、どこまでスループットを上げることができるかが重要です。スループットが最大のときのパフォーマンス比較ができれば、信頼できる

携帯コンテンツ変換の選定基準：パフォーマンス

2009-09-08T09:00:00.008+09:00

携帯コンテンツ変換エンジンは、システムのフロントに位置し、常にレスポンスが通過するので、そのパフォーマンスは非常に重要です。パフォーマンス・データはコンテンツや環境や計測方法に非常に大きく依存し、客観的な方法は存在しないので分かり難いものです。良いデータを出しすぎてユーザからクレームをもらうのも好ましくなく、悪いデータを出すこともできず...とベンダー側も悩みます。ラウンドアバウトでは、多少のリスクをとってパフォーマンスデータを公開しています。また1,000/秒のスループットも表明しています。画像キャッシュがある状態で、ノーマルなサーバで１ページ10画像程度のコンテンツで試せば、HTML/画像を合わせて、秒間1,000アクセスは控えめに言っても出るでしょう。ただ、他製品では「独自な技術で高速」というだけで、データも中身が分かりません。 ■ハイ・パフォーマンスには理由がある８：２の

携帯コンテンツ変換の選定基準：ネットワーク設計とセッション

2009-09-07T09:00:00.008+09:00

携帯コンテンツ変換を選定する際、重要なポイントの１つは製品自体がセッションを使う処理をするかどうかです。携帯コンテンツ変換製品がセッションを使う機能がある場合、ネットワーク設計に大きな制約が生じます。セッションを使用する代表的な機能が、「ページ分割」と「クッキーエミュレーション」です。セッションを使うと次のような制約が発生します。アクセス端末は常に同じ特定変換サーバを通過する必要があるこのため単純なラウンドロビンが使用できず、パラメータ等による振分けが必要となるアプリケーションもセッションを利用し、特定サーバでの処理を要求する場合があるこの時、１つの携帯からは特定変換サーバと特定Webサーバを通過するように、ネットワーク設計しなくてはならない。そこで３つのサーバ構成が考えられます。セッションありサーバ型の構成及びアクセスルート左図は2段にロードバランサを配置

携帯コンテンツ変換の選定基準：ネットワーク設計

2009-09-04T09:00:00.006+09:00

コンテンツ以上にネットワーク構成はシンプルでなくてはなりません。複雑なネットワークはトラブルを招き易く、コストも高く、変更リスクも高くなります。ネットワーク設計・設定といっても、ルータやロードバランサ、DNS、HTTPサーバなど様々なレベルのものがあり、１つの課題を解決する方法も多種多様です。ネットワーク技術に長けたエンジニアは少なく、基本的に高コストです。そのため、ネットワークをシンプルにすることはシステム設計上の最重要項目の１つです。負荷分散とフェールオーバーを考慮した複数台のサーバ構成をする場合、サーバ型とラウンドアバウトではネットワーク構成が大幅に異なります。フェールオーバーを考慮したサーバ型とラウンドアバウトのシステム構成サーバ型では、ネットワークに追加するだけ、と言われますが、実際のところ追加するのは簡単ではありません。左図のようにロードバランサを2段に組む必要

携帯コンテンツ変換の選定基準：サーバー台数

2009-09-03T09:01:00.009+09:00

ラウンドアバウトと他社製品の一番の違いは、サーバー台数です。もっとも違いが分かりやすいのは、変換サーバーをハードウェアとして提供している製品です。例えば、Webサーバーが3台ある環境で、ハード提供型は3台の変換サーバーが必要で、合計6台となります。一方ラウンドアバウトはWebサーバーに組み込まれますので3台のままです。サーバー型とラウンドアバウトの台数の違いあなたならどちらを選びますか？？ラウンドアバウトのコンセプトは、Simple is Best.であり、携帯の全ての特殊性を排除することです。携帯システムだからといってシステム構成自体が特殊化することは、コンテンツの特殊性よりも遥かに大きな問題だと考えています。おそらく、サーバー型のコンセプトは、「ネットワークに追加するだけ」「問題の切り分けが容易」というものだと思います。さらに別の例を見てみます。PCも携帯

携帯コンテンツ変換の選定基準

2009-09-03T09:00:00.003+09:00

携帯コンテンツ変換を導入を検討するに当たり、どのような点を選定基準とするか、まとめていきたいと思います。ラウンドアバウトコンセプトというBlogの中では中立性を保つことはできませんが、ここで触れる内容こそラウンドアバウトのコンセプトそのものであり、その違いを示すことができればよいと思います。常に製品は、様々な機能の有無を○×付けて評価されますが、実は”×”であることにも強い意味がある場合もあります。製品のコンセプトを理解してもらうことは、その製品の最も有効な使い方や将来性について、ユーザーに安心して製品を使ってもらうために大事なことだと考えます。コンセプトは製品の外殻であり、この殻が内側に位置する色々な機能の性質・性能に決定的な影響を及ぼします。ユーザーからすれば最小限の機能さえ満たせれば、コンセプトから生じる製品の基本特性が一番重要です。それは製品を選定する上で最初に必要な情報

フットプリントの導入意義

2009-09-02T09:00:00.004+09:00

フットプリントについては詳しい機能の説明や使えるツールなどはHPを参照してください。携帯サイトのユーザー認識できる生ログが記録できるこれがフットプリントの今までに無い価値なのですが、ではフットプリントが無ければどうなるのか、検証してみたいと思います。 au/softbankの端末は、HTTP/SSLの両方ともユニークIDがリクエストヘッダーから取得できますので、設定すればApacheログに記録できます。次にdocomoですが、全てのリンクにguid=onと記述する必要があるので、コンテンツに修正が必要です。また副作用は無いと思いますが、１ソースでこのリンクをつけると全キャリアにその記述が入ります。 docomoのSSLはIDが取得できないので、HTTPアクセス時に１サーバーの場合にはアプリケーションセッションに入れることも出来ますが、複数サーバーの場合には困難でしょう。また

新しい携帯サイトのアクセス解析の方法：フットプリント

2009-09-01T09:00:00.008+09:00

もうすぐラウンドアバウト製品ファミリーである、ラウンドアバウト・フットプリントがv1.0.1となってリリースされます。フットプリントプリントはその名の通り、アクセスログに足跡をつけるツールです。ですから、これ単独ではアクセス解析はできません。しかし、このツールは携帯アクセス解析に大きな進歩をもたらすことができる製品です。 ■背景以前はあまり携帯ではアクセス解析は必要ありませんでした。なぜなら公式サイトが中心であり、アクセス数が多ければ公式メニューの上位に表示され、これがさらに入会を増やす（売上UP）というサイクルだったからです。ところが携帯でもECやコミュニティなどの勝手サイトが台頭する流れの中で、キャリアがTOPメニューに検索を設けるようになりました。検索エンジンも携帯サイト用のクローラーで情報を集めるようになり、ここに至って携帯サイトでもSEOやSEMが必要

imgタグビーコン方式の問題点②高コスト

2009-08-31T09:00:00.005+09:00

■ビーコン式ASPは高い imgタグビーコン方式は通常ASPで提供され、決して安くはありません。有用なサービスを開発・運用しているので当然なのですが、携帯アクセス解析にとってはこれこそが最大の問題です。定常的な固定費のかかるシステムは敬遠される傾向にあり、場合によってはサーバやコンテンツ保守より高価になってしまうアクセス解析の普及の妨げになっていると思われます。 GoogleAnalyticsのように無料で提供されれば良いのですが、おそらくそのようなサービスはないでしょう。ログ解析自体は直接利益を生むわけではないし、PCであればGoogleAnalyticsを初めとする高度な解析サービスが無料で提供されている中で、月額3万～10万、年間30万円や100万円の最低料金を払えるサイトはそれほど多くはないでしょう。導入コストが高いために、本来全てのサイトであるべきアクセス解析が、全

imgタグビーコン方式の問題点①SSL通信時

2009-08-28T09:00:00.006+09:00

■ドコモ端末のSSL通信制限完璧なようなimgタグビーコン方式ですが、ドコモ端末仕様の制限が立ちはだかります。ドコモ端末はSSL通信時に２つの制限があります。 ★ドコモ端末におけるSSL通信時の制限ホストドメイン以外の画像へアクセスすることができない iモードID（キャリアユーザーID）を取得することができない SSL通信領域は、会員情報登録フローや商品購入フローなど、コンバージョンに関わるWebで最も重要なページが含まれています。ドコモの制限があるとSSL通信時にはビーコンを飛ばすことができません。また、通信可能なホストドメイン上でさえユーザーIDを取得できないので、致命的な状況です。このため、多くのサービスではSSL通信には対応していません。＜SSL通信時のimgタグビーコン方式の問題＞ ■SSL通信の制約を乗り越える方法と問題点いくつかのimgタグビーコン方式は

現在の携帯サイトのアクセス解析の方法

2009-08-27T09:00:00.006+09:00

■方法１：アプリケーションでセッションパラメータを生成し引き回す携帯サイトのアクセス解析ですが、クッキーが使えないのでPHPやJavaのセッションなどを利用して、これらの値を引き回してサーバーログにURLパラメーターとして記録してツールで取り込んだりします。このようなアプリケーションで頑張る方法は、開発・運用コストが高くつくことに加え、一度パラメータのセッションが切れてしまったら、次のアクセスは別セッションとなってしまう問題があります。切れてしまえばユーザーがリピーターかどうか判別するには、ログインさせる必要が出てきたりして、ユーザビリティの劣化が発生したりします。もう１つ重要な制限として、静的ページに使えないという点があります。アプリケーションとしてセッションを引き回す必要がないページでも一度切れてしまうと別セッションとなってしまうため、静的なページでも動的なページとして作

携帯サイトのアクセス解析が特殊な理由

2009-08-26T09:00:00.006+09:00

携帯サイトも当然アクセス解析が必要ですが、PCであればとりあえずアクセスログを解析ツールで読み込ませて基本的な解析を開始できます。webalizerやAWStatsなど無料のツールもあります。ただし、これらのツールはIPベースでユーザー識別するので、個人自宅からのアクセスはほぼ同じアドレスからアクセスされるのでよいのですが、ゲートウェイを経由する企業からのアクセスを考慮すると、セッション数（ユーザー数）などのデータには正確性に問題があります。問題はありますが、なんといってもコスト０で実現できる点は大きな利点です。とはいえ、やはりセッション数を把握しない限り正しい解析はできませんし、コンバージョン数や経路分析までも求められて来ると、どうしても個別のユーザーを判別しなくてはなりません。そこでユーザーを識別するために、クッキーを使って個別のアクセスを区別します。方法として、クッキーを使った

フォント問題は画像で解決できる

2009-08-25T09:00:00.013+09:00

テキストには、フォントが不定かつ機種で異なるのでデザイン計算できないという異機種の問題と、1行の文字数は個々の端末としては固定であり自由ではなく、高さもいつも決まった分必要だという問題があります。後者は当たり前のことかもしれませんが、デザインを考える上では制約となってしまします。ラウンドアバウトの下で画像を使って、TOPメインメニューを作れば、文字数もフォントも自由に、そしてどんな端末でも同じように見えます。下図の例は５つの画像を並べた例です。 ”項目名：データ”のようなレイアウトも画像を使えば、項目名の長さに囚われずにインデントを揃えて、そしてデータとの区別をしっかりつけたデザインをすることが出来ます。左図はその例となります。このような画像を１つだけ作るだけで綺麗なユーザビリティの高いデザインを全ての端末で実現することができます。ラウンドアバウトはレイアウトを崩

携帯端末のフォント問題

2009-08-21T09:00:00.007+09:00

昔の端末は1行が8文字～１２文字と決まっていて大きさも変更できませんでした。しかし、現在の端末はサイズが選択でき、かつ組込フォントは機種毎に異なり画面幅も違うので、1行に何文字とは決められません。htmlではフォントサイズは指定できますが、表示を正確にコントロールすることはできません。そもそも、HTML自体がフォントを絶対的な大きさで表現する技術ではないので、コントロールできたところで本来あまり意味は無いのですが、携帯サイトでは事情が異なっています。よくあるのがTOPメインメニューで、ユニクロの携帯サイトを例に取れば、 MEN｜WOMEN｜KIDS｜BABY｜HOME となっています。このメニューの問題を挙げてみましょう。テキストなので、端末によってどこで折り返されるのか不定ですフォントが不定なので、見易いのか見辛いのか不定ですメインメニューにも拘らず、他の

２G端末の現状と対応

2009-08-20T09:00:00.003+09:00

２Gも対応したいんです。と、要望される人も多いのですが、まずは数字から抑えることが重要です。２Ｇサービス１月末４月末７月末ドコモPDC 666万 556万 461万ソフトバンクPDC 275万 197万 150万ａｕCDMAOne 34万 31万 29万その上、ソフトバンクＰＤＣは来年の３月をもってサービス終了となります。auに関してはほぼプリペイド型であるのでWeb対応は考慮しなくてもよいでしょう。ドコモに関しては２０１２年まで続きます。ドコモだけで毎月30万台の端末がＰＤＣから抜けていく計算で、ソフトバンクがなくなることを考えると、おそらく来春にはドコモＰＤＣの200万台以下へのサービスをどうするか？という問題になります。なお、7月末時点で全契約数は１億８９０万台であり、Web契約は９１７３万台なので、PDCのうちWebを見ているものは更に限られます。

ラウンドアバウトが実現するリッチな携帯サイト

2009-08-19T09:00:00.007+09:00

最初にリッチの定義からします。リッチ＝ユーザビリティが高いユービリティが高いとは、コンテンツが見易く、欲しい情報に素早くアクセスし、正確な情報を得ることができ、操作に迷わないデザインです。最終的にコンテンツ制作者の腕にかかってくることですが、携帯サイトでは、様々な制約があることから、特殊な腕を要求していました。例えば... トップメニューは項目を縦棒で区切るタイトルのバックグラウンドカラーを設定して目を引く絵文字の使い方を統一する半角スペースで見出しの字数を揃えるとかとか。これらのテクニックはテキストの中で如何に目出せたり、綺麗に見せるかということを目的にしていますが、如何せん、テキストばかりなので苦労するほどの効果が得られません。テキストベースでサイトに装飾することには限界があり、問題もあります。ところが画像であれば、多くの問題を解決することができます。左は

携帯サイトのデザインが貧弱な理由

2009-08-18T12:00:00.002+09:00

この業界にいる身としては悔しいですが、一般的に携帯サイトはデザインは貧弱と思われています。理由は、小さな画面、テキスト中心、単純なレイアウト（人によってはI型とか言う）などによるのでしょう。小さな画面は仕方ないとして（携帯できないと意味ないですから...）、テキスト中心、単純なレイアウトになってしまう理由として、よく言われるのが携帯は画像の処理が苦手画像は遅いのでテキスト中心にすべき携帯は画面が小さいので、単純なデザインの方が好まれるなどですが、果たしてそうでしょうか？左の２画面はラウンドアバウトのデモ画面ですが、左の絵は34個の画像で全てを合わせて113Kbあります。SoftBankの９３０SH（VGA端末）で、10秒程度で全て表示されます。ラウンドアバウト・サンプルサイト：キッチン.com 見ての通り、画像についてPCと同じように多用しても、現在の端末

携帯画像：ブラウザーキャッシュ容量問題：ラウンドアバウトの解決法

2009-08-17T09:00:00.005+09:00

ラウンドアバウトは、コンテンツ制作からブラウザーキャッシュ容量の制約を完全に除去します。アプローチとして、ブラウザーのハードウェアの容量を上げられないのであればコンテンツの容量を下げるしかありません。ラウンドアバウトも他の一部のソリューションと同様に画像の品質をダウンさせることで、容量を削減しますが、根本的に違うところは次の1点です。アクセス端末のキャッシュ容量内に収まるように、ページ中の全画像を変換するキャッシュ内への容量調整を複数画像変換に対応して行い、決してオーバーフローしないことが、ラウンドアバウトにしかできないものです。また、全て自動で行い、コンテンツには何も記述する必要はありませんセッションレスで動作するのでHTMLと画像が別のサーバーから配信できる。つまりロードバランサーの下で単純ラウンドロビンで動作し、アプリケーションとネットワークに影響しません。

携帯画像：ブラウザーキャッシュ容量問題：これまでの対策

2009-08-14T11:43:00.007+09:00

ブラウザーキャッシュ問題は昔から携帯開発者を悩ませていた最大の問題です。ブラウザーキャッシュが10Kバイトのような時代には、テキストだけでも制限を越えてしまう場合もあり、１ページあたりの情報を少なくするしかありませんでした。しかし、今日の１００Kバイト以上の端末がほとんどを占めるようになると、まずテキストでは超えない制限となったので、画像をいくつ載せるか、どのクオリティにするか、という問題に置き換わってきています。ですから、このBlogでもブラウザーキャッシュ容量問題は画像の話題としています。容量オーバーの問題はとにかく深刻です。右のようなダイアログが画面にでてきてアプリケーションが完全に止まり、制御不能になります。このような事態に比べたらレイアウト崩れやデザインの貧弱さは、許せる範囲だと言えます。ブラウザーキャッシュ容量問題の対策が難しい点を挙げます。 2G端末で６K

携帯サイト画像：VGA問題

2009-08-11T12:38:00.022+09:00

画像の問題のもう１つである容量の違いに触れる前に、新しい問題としてVGA対応について触れましょう。これまでの３～４年間はQVGA（横幅２４０px）の端末が事実上の標準機であり、仕様上の上級機でした。より古い端末でも200pxを切るような端末は５～６年前でもほとんどありません。つまり、画面サイズは上位機種から15%程度の違いでした。このため、さらに古い端末をサポート対象にせず、単純なレイアウトだけであれば、２２０px程度を基準に作ることでデザインも概ね大きく崩れることがありませんでした。このような状況の中でソフトバンクからVGA（横幅４８０px）の端末が２年位前に発売され、この５月にはドコモの新機種の大部分はVGAサイズとなりました。VGAはQVGA比で縦横２倍、面積４倍という大きさであり、これまでと全くスケールが違います。サイズが大きくなったVGA端末では、当然キャッシュ容量も大

携帯サイト画像：画面サイズ問題

2009-08-10T12:16:00.017+09:00

携帯サイト制作の肝とも言える画像問題について考えます。根本の問題は２つです。機種毎に画面サイズが異なる機種毎に容量が異なるここでは画面サイズの問題にフォーカスします。歴史的経緯（？）から過去の端末において、端末のブラウザーからはみ出してしまうとエラーになり、表示されないという問題がありました。つまり、大きすぎて表示できないということです。この問題に対処するのが一般的な画像変換ソリューションであり、大きすぎてエラーになってしまう事態を防止します。しかし一般的な画像変換ソリューションでは、大きすぎない、つまり画面に収まる画像は変換しません。この時、１つの問題が発生します。それは、サイズ変更をする画像としない画像が１ページ中に混在するので、当然レイアウトが変化してしまうことです。せっかく綺麗にレイアウトしても別の画面サイズの端末で見るとレイアウト崩れが生じてしまうのです

HTMLは何を使ったらいいのか？

2009-08-07T16:02:00.019+09:00

全キャリア対応の携帯サイトを作る際に最初に決めなければいけないものが、使用するHTMLです。そして、ほとんどの場合、iモードXHTMLを推奨しています。もしサイトが2Gもサポートしたいのであれば、iモードHTML（CHTML）となるか、2G/3Gで２つの言語を出し分けることになります。細かい仕様の違いは他の情報源を見ていただくとして、実は表現力の違いはiモードXHTMLとCHTMLにはあまりありません。大きなところで背景色が使えるところくらいです。そしてchtmlは2G/3Gで基本的には見れますが、xhtmlは2Gでは見ることができません。なのでxhtmlの時代ということを考えなければCHTML（ver.7）を利用するのは１つの合理的判断だと思います。 2Gはちょっと置いておいて、iモードXHTMLが推奨されるのは消極的な理由からで、au/softbankでは利用できるCSSが使

携帯サイト制作会社の意識の壁

2009-08-07T14:47:00.007+09:00

ラウンドアバウトを紹介して回る先にモバイルコンテンツプロバイダー（MCP）は外せません。ラウンドアバウトの良さを一番に理解してくれる企業にでしょうから。様々なお付き合いの中で、開発現場の方から開発マネージャーや経営TOPに近い人まで多くの人に見てもらってきました。ほとんどの人からポジティブなコメントを頂いていますが、それは置いておいて、常ではないけどよく聞く期になる言葉があります。「ここまで高いデザイン性は携帯サイトに必要なんでしょうか？」「ここまでデザインを追及できるなら、デザインにコストがかかりそうですねー」「デザイン性を追及したいサイトにはいいですね」といったものが１つで、少々乱暴だけど”Web価値＝デザイン＝ユーザビリティ”だと思うので、携帯サイト特有の価値観といったものが業界に存在するようです。「社内の開発者はキャリア個別に作ることに馴れて分業しているからなぁ...

Web制作会社と携帯サイト制作会社の間の深い溝

2009-08-07T12:47:00.005+09:00

ラウンドアバウトが出来上がろうとしていた時期に、Web制作会社（携帯も作るがPCサイトメインの）へ製品紹介をしていた時の話です。そもそもなんでWeb制作会社へ行ったかと言えば、ラウンドアバウトは携帯の煩わしい問題を無くしてしまうので、業務の幅が広がるという話をしにいった訳です。そこで聞いた話は、この先何度も聞くことになるのですが、結構考えさせられるものがありました。要約すると... 「携帯サイト制作は実のところ、営業上できるとは言っていますが、あまりやりたくはないのです。大体、PC/携帯両方を希望するクライアントが多いのですが、その難しさとコスト及び効果を説明することで、時期尚早として２次開発などに変更して、結果的に受注しないようにしているんです」話は続き、「携帯サイト対するクライアントの予算は小さく、ビジネスとしても旨みがすくないし、トラブルが多くて実際としても運営コスト的

ラウンドアバウトのコンセプトを公開していきます

2009-08-07T12:26:00.003+09:00

モバイルWebプラットフォーム：ラウンドアバウトのオフィシャルではあるけど、製品サイトには載っていないような情報を、携帯サイト開発にまつわる話を絡めて公開していくBlogです。ラウンドアバウトとは以下の製品のことです。http://www.symmetric.co.jp/roundabout/このBlogを通じてラウンドアバウトのコンセプトを広く知ってもらえるとよいなぁと思っています。そして、携帯サイト開発について色々な意見を聞ければよいなぁと思っています。

新・携帯サイトの作り方：ラウンドアバウト コンセプト