海外でのオンライン販売をしたい企業担当者にとって打ち合わせの際に必ず聞か
れることがあるのでここで詳しく説明しておきたいと思います。

海外向けにオンラインショップの構築を行う以前に確認しておかなければならな
いのは以下の3点です。

・販売する地域と言語

・決済する通貨

・配送方法、送料ロジック

これはＥＣサイトのシステム関連との連動になるためです。この部分が決まって
いない状態で打ち合わせに来られてしまわれても、どの地域で売れるの？なんていう質問にはお答えできません。

販売戦略を構築する上でコンサルタントなどと十分協議してください。 Read the rest of this entry »

最近ブラウザが新しくなったこともあり、Eコマースサイトのウェブサイトを徘徊しているとたまに、SSLの有効期限切れウェブサイトやSSLにインストールされたドメイン名とウェブサイトのドメイン名があっていなかった為にエラーが表示されたり、またウェブサイト上のあらゆる所に不適切と思われる個所がいくつか見つかったりするものです。

特にEコマースに関しては、自分が制作するサイトと比較しながら見てしまう癖がありますが、少なくとも確認したほうがいい事項があるので今回紹介しておきたいと思います。

1.コピーライトの日付が古い
ユーザーは意外にフッター領域にある Copyright © 会社名< 開始年” の文字列を見ることがあると思います。

この”年”の部分が古い場合（たとえば1995 - 2005）、

・このホームページに掲載されている情報は確かか？（正しいのか）
・この会社は本当にビジネスをやっているのか？

コピーライトの日付が古いだけでユーザーはウェブサイトを疑ってしまう可能性があります。

解決策

PHPプログラムを利用すると次のように書ける。
1995年から開始している場合
Copyright © 1995 - <?=date(”Y”)?> 会社名

次のように表示される
Copyright © 1995 - 2008 会社名

2.SSLがドメイン名と一致していない
SSLがドメイン名と一致していない場合、これは致命的です。IE7、Firefox3のどちらに関してもSSLのインストールしたドメイン名と実用しているドメイン名が違っていたり、SSLの有効期限が切れている場合、下記のような画面が表示されてしまう。

ユーザーがこの画面を見た時、もしかしたら以下のことを想像してしまうだろう。
・フィッシング詐欺にあったのか？
・インターネット回線のトラブルにでもあったのか？
・パソコンが壊れてしまったのか？

ここでこのユーザーはブラウザを閉じることは間違いない。今すぐSSLが正しくインストールされているかどうか確認しておこう。

3.配送方法、決済方法に関する視覚的表示（バナー画像等）をしていない
どのような方法で支払ができるのかをすべてのページに表示すべきです。ユーザーは会社案内やFAQのページなどは実はほとんど見ないです。

商品をクリックしたら、後は購入完了まで一直線にクリックするだけだ。その過程でユーザーが考えることは次の3つくらいしかない。
・何日で届くの？（納期について）
・送料はいくら？（送料について）
・支払方法は何？

クレジットカードのロゴマークや配送業者のロゴマークがあればユーザーは視覚的に理解でき、支払手続きをスムーズに進めることができる。

4.「カートに入れる」などの各ボタン類のデザインへの配慮
ウェブ2.0の流行があってか、ウェブサイト上に置かれるボタン類や素材になんでも影を付ける傾向がある。これはこれでウェブサイトを美しくしていることに違いはないが、ユーザーがそれをボタンであることを認識できないことがある。

そのボタンがどのような目的で存在しているのかをもう一度考えてデザインする必要がある。

ウェブ2.0系のウェブサイトではAJAXについても多用されている。ユーザーがAJAXのアクションを実行したときに、Loaddingしてページを読み込みしていることがわからないとユーザーはその先にあるページを見る前にページを閉じてしまうことがあるかもしれない。

これもAJAXを利用している場合（特にデータ量が多い読み込み）は改善する必要があるだろう。Loadingアイコン素材はこちら

5.貧弱なサイト内検索
Googleは今やとても有名で誰もが使う検索エンジンです。これはGoogleの検索能力の高さが証明しています。また1秒以内に結果をはじき出す高速性も重要です。

サイト内検索機能で、ユーザーがミススペルをしたときに補完語を表示できる機能はありますか？
もしない場合はGoogleをサードパーティーとしてサイト内検索に使うか、それに代わるサードパーティーを探すべきです。
今やユーザーはGoogleが示す「検索する」という傾向にあると思います。

理由は以下の通り。
cakeや他のフレームワークにあるような自動生成やORMなどは確かに魅力的だが、どれもそれをまたフレームとしてつくれる要素を残した中途半端というか、フレームワークっぽくないところが逆にプログラムの組み手にとっては自由度があって良かったりする。

その中途半端な部分を独自に自由に組み立ててたり、特定の必要機能だけをスポットで使ったりできるのは骨太フレームワークに比べた時、最初の開発に一時的に時間はかかるものの、自分で書いているので迷路入りすることはまずないだろう。
つまりフレームワークのスクリプトの依存度は少なく、自分で書いたコードの範疇で自己解決を見出すことができそうだとZend Frameworkは判断した。

一方cakeやsymfonyを採用した場合、開発スピードを早めたり、余分なコードを書かなくて済んだりと初期開発時のメリットや、第3者が介入してもコードの体裁は保たれるものの、迷路入りした時の自己解決において最終的にフレームワークそのものを理解する必要があったり、フレームワークの外に出たい時に（例えば外部のjavaやaspと連携など..）ドキュメントを1から読み返したりとなると、フレームワークの皿の上で踊らされているスクリプトになってしまうと判断した。

フレームが頑丈すぎて一度操作し始めたら、何を動かしていいかわからなくなってしまう。行きたい所に行けない。フレームワークの呪縛にかかってしまうという懸念がどうしても取り除けなかった。
これもPGのセンスや感覚なので十人十色だと思うが。
入口がPHP4から入ったものとしてのあくまで結論です。

先述した『中途半端というが、フレームワークっぽくないところ』が将来やりたいことを実現するときに苦労はあるが、自分で書ける要素が残っているし何より自分で書いたコードの方がアドバンテージがある。（単なる自己満にすぎないが）

GoogleやIMBがスポンサーになってたり、PHP本体の開発を手がけているZENDがサポートしているのもプラスファクターになっている。

では、Zend Framework一本でコードを書いていきます！

簡単に今後のフローを説明しておくと、MVCのロジックにデータベース、ビュー、スクリプトを全部分解して再度コーディングです。
その後、LiveCommerceで独自に開発したクラスライブラリーやファンクションをZend Frameworkの中にインクルードして両方のスクリプトが利用できるようなイメージで再開発する予定です。

なんと昨日買ってしまいました。
６月２３日までだそうです。

デュアルコアCPU+2GBメモリ+160GB HDDと充実構成に
なんと19インチワイド液晶モニタが２台付属！！—–64,980円〜

本日、弊社で販売中のヘルプデスクeSupportのさらに分かりやすく、どうしてこんなに使うのかを書いた記事を新たに追加しました。

eSupportを使いたくなるわけ

今日ダウンロードリンクつけました。

こちらのエントリーです。

LiveCommerceをcakePHPを使って全部１からコードを書きなおそうか、かなり迷ってます…。

独自フレームワークにて開発したものの、時代の流れはZendFWか、cakePHPの色合いが濃くなりそう….。

ただ、cakePHPを使うとなると、将来LiveCommerceをカスタマイズしたりなんやかんややることになったときに、cakePHPそのものをPGが理解する必要性がある。

こうなるとWordPressのようなお手軽さとは方向性がずれてしまう。

例えば、cakeを採用するならあえてLiveCommerceを作らなくとも、ZencartやosCommerceのコードをcake仕様に変更してsmartyでも入れてあげればPHP5時代でも十分通用するEコマースだと思う。

どうしよっかな…。