カテゴリ ‘DigitalStudio’
Skypeでのお問い合わせ - 遠方、海外のお客様の為に
Posted by プロジェクトリーダー on 2008年07月29日 火曜日 10:56:09 | コメント(0)今までスカイプというツールを社内部のコミニケーションツールとしての利用目的で使っていましたが、昨日からウェブサイトにもオンラインステータスを表示し、本格的にスカイプをお問合せのフロントラインとして使い始めました。
遠方や海外にお住まいの方で、対面での新規打ち合わせが現実的でないお客様はこちらをのページをどうぞ。
ＩＴ製品の場合、画面を見ながらサポートや商品の説明をしないと、相手に本当の理解は伝わりずらい。
お互いが同じ画面を見ながら、音声付で説明し、一緒に動作を体験することが、最も効率的な商品説明になると思います。
それにはスカイプがとても便利だと改めて感じます。
ＵＲＬを直接送ったり、画像ファイルを送るのにもドラッグ＆ドロップでできるので、これが電話だとＵＲＬを説明したりするのにも一苦労。。。
お問合せのページは次の通り。
新規のお客様の場合はこちらのような画像が表示されます。オンラインの場合、スカイプのオンラインボタンをクリックするだけで使えます。
サービスをご利用中のお客様はサポートセンターのページで部署を選択するときに、スカイプボタンを新設したので、直ぐに回答を求めたい時には役に立つと思います。
今回書いた海外、遠方のお客様をスカイプでサポートするという件ですが、会社案内のデジタルスタジオでは… にも追加しましたので、今後遠方のお客様にはぜひ活用いただければと思います。
時差のなくなるコンテンツ業界？
Posted by プロジェクトリーダー on 2008年07月20日 日曜日 00:40:57 | コメント(0)世界中のありとあらゆるコンテンツサービスにおいて、時差はますますなくなってきたと思う。
アメリカ発のベンチャー企業が何らかのWEB2.0的サービスを公開したとすれば、その1ヶ月後、2ヶ月後には日本の品質で同じサービスが生まれる。サー ビス品質（顧客サポート、画面デザイン、説明補足）は異なるものの、アイディアやロジックは全部アメリカ生まれのものになる。違うのは日本人の品質に直す 必要があるだけだ。 (more…)
ECサイトで販売機会の損失をしかねない5つの失態
Posted by プロジェクトリーダー on 2008年07月08日 火曜日 11:47:58 | コメント(0)最近ブラウザが新しくなったこともあり、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が示す「検索する」という傾向にあると思います。
Zend FWとcakePHPを見比べた結果、LiveCommerceはZend Frameworkを採用
Posted by プロジェクトリーダー on 2008年06月24日 火曜日 15:25:14 | コメント(0)理由は以下の通り。
cakeや他のフレームワークにあるような自動生成やORMなどは確かに魅力的だが、どれもそれをまたフレームとしてつくれる要素を残した中途半端というか、フレームワークっぽくないところが逆にプログラムの組み手にとっては自由度があって良かったりする。
その中途半端な部分を独自に自由に組み立ててたり、特定の必要機能だけをスポットで使ったりできるのは骨太フレームワークに比べた時、最初の開発に一時的に時間はかかるものの、自分で書いているので迷路入りすることはまずないだろう。
つまりフレームワークのスクリプトの依存度は少なく、自分で書いたコードの範疇で自己解決を見出すことができそうだとZend Frameworkは判断した。
一方cakeやsymfonyを採用した場合、開発スピードを早めたり、余分なコードを書かなくて済んだりと初期開発時のメリットや、第3者が介入してもコードの体裁は保たれるものの、迷路入りした時の自己解決において最終的にフレームワークそのものを理解する必要があったり、フレームワークの外に出たい時に（例えば外部のjavaやaspと連携など..）ドキュメントを1から読み返したりとなると、フレームワークの皿の上で踊らされているスクリプトになってしまうと判断した。
フレームが頑丈すぎて一度操作し始めたら、何を動かしていいかわからなくなってしまう。行きたい所に行けない。フレームワークの呪縛にかかってしまうという懸念がどうしても取り除けなかった。
これもPGのセンスや感覚なので十人十色だと思うが。
入口がPHP4から入ったものとしてのあくまで結論です。
先述した『中途半端というが、フレームワークっぽくないところ』が将来やりたいことを実現するときに苦労はあるが、自分で書ける要素が残っているし何より自分で書いたコードの方がアドバンテージがある。（単なる自己満にすぎないが）
GoogleやIMBがスポンサーになってたり、PHP本体の開発を手がけているZENDがサポートしているのもプラスファクターになっている。
では、Zend Framework一本でコードを書いていきます！
簡単に今後のフローを説明しておくと、MVCのロジックにデータベース、ビュー、スクリプトを全部分解して再度コーディングです。
その後、LiveCommerceで独自に開発したクラスライブラリーやファンクションをZend Frameworkの中にインクルードして両方のスクリプトが利用できるようなイメージで再開発する予定です。
eSupportを使いたくなるわけ
Posted by プロジェクトリーダー on 2008年06月11日 水曜日 18:09:56 | コメント(0)本日、弊社で販売中のヘルプデスクeSupportのさらに分かりやすく、どうしてこんなに使うのかを書いた記事を新たに追加しました。
osComerceの1PageCheckout
Posted by プロジェクトリーダー on 2008年06月10日 火曜日 20:30:37 | コメント(0)今日ダウンロードリンクつけました。
こちらのエントリーです。
osCommerceでランディングページを活用する
Posted by プロジェクトリーダー on 2008年05月27日 火曜日 01:00:54 | コメント(1)Googleアドワーズ、オーバチュア広告と連動して今やランディングページでプロモーションをやっているショップは多いですが支払手続き仕組みまで簡略化し最短手続きでやっているところは意外と少なかったります。
で、osCommerceバージョンで作りましたので皆さんにデモを紹介します。
osCommerceでランディングページを活用する ということですが、簡単に説明すると次のようになります。
ランディング化して最短支払手続きを行うイメージ
 |
 |
 |
|
 |
| ��YahooやGoogleなどからランディングページへ誘導 | �▲廛蹈癲璽轡腑鵑離據璽犬� このページからECサイトのページへつなぐ |
��ECサイトに誘導し決済完了までユーザーを誘導 |
ここで重要なのは、買う意思のある顧客の意識が高いうちに決済完了まで誘導することです。なので、図の��にあたる
プロモーションページ → ＥＣサイト
この過程でECサイトのページ遷移が長いと、もしかしたらユーザーは他のサイトへ行ってしまうかもしれません、買うのをやめてしまうかもしれません。
（ちなみに私は今日、花キューピットでオンラインで友人の移転祝いに花を購入しようとしましたが、あまりにも購入手続きが長く、フォームのエラーがあってもどこを直せばよいかわかりずらいヒューマンインターフェースだったので、結局フォームからの購入を断念してここで買いました）
こういうことが普通にあるので、本当にECサイトは購入プロセスの手間をできる限り簡略化するように努めるべきだと思います。
osCommerceのランディングページ対応1ページ決済はこちらのページで公開してます。
