購入直前のユーザーを逃さない。モバイルECサイトの「買い物かご」のユーザビリティ（第9回） | モバイルサイト構築のユーザビリティいろは
前回ではモバイルショッピングサイトのトップページから商品検索結果ページ、商品ページまでのユーザビリティポイントについて紹介しました。第9回となる今回では、実際にユーザーが商品を購入するまで、「買い物かご」ページから決済に至るまでの「購入フロー」の構築ポイントを、ユーザビリティ調査結果の内容を基に紹介します。 商品購入を決めたユーザーをスムーズに「決済」に誘導する事が重要オンラインショッピングの利用経験があるユーザーにショッピングサイトで商品選択後に購入を断念したことがあるか尋ねたところ、「よく断念することがある」「たまに断念することがある」という回答がPCで32％、モバイルでは48％となり、モバイルがPCを16ポイント上回る結果となりました。 購入を断念した理由をPCとモバイルで比較したところ、「通信速度が遅かったから」「住所入力が面倒になったから」の2つがPCとの差が最も大きく、モバイル
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
C＋＋クラス設計に関するノート
C++が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。よくよく注意しないと、削除し忘れたり、同じオブジェクトを2度削除してしまうというエラーが発生します。このノートでは、オブジェクトを「値オブジェクト」と「参照オブジェクト」というカテゴリに分け、詳細設計の段階で注意すべき点を整理しておきたいと思います。 0. はじめに 私自身今までいくつかのプログラミング言語を使ってきましたが、C++ が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。例えば、 Person* person = new Person(); と生成したオブジェクトは、使い終わったら次のように削除しなければなりません。 delete person; 生成してすぐ削除するなら簡単なのですが、実際に
第65回 ［図解］Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング：ITpro
今回は，Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品，つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが，ご参考になれば。 図は，一番上は「4つのステップ/3つのタスク/12の要素（第62回 持続可能なWebサイト開発を支える12の要素）」。その下は，人的配置をロール(役割)ごとに記述しています。その下は，大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が，「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基本的には，その流れの順で進んでいきます。その下は，それぞれのステージのアウトプットのイメージで，更にその下にはよく使うファイルアイ
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方
今回から，3回にわたって，【画面編】と題して，画面に関する外部設計書の書き方のコツを解説していきます。 画面に関する工程成果物の定義は各社でさまざまですが，発注者ビュー検討会では，次の6つを，画面に関する工程成果物として定義しました。【画面編】でも，これらの工程成果物を扱います。 （1）画面一覧：システムで利用する画面の一覧表。 （2）画面遷移：アプリケーションを実現する画面の流れを表したドキュメント。表示される画面とその画面の順序関係，画面から画面への遷移を起こすきっかけとなるイベント，条件分岐がある場合はその条件と条件に対応する分岐遷移を記述する(次回に詳しく説明します）。 （3）画面レイアウト：発注者が実際に操作する個々の画面の設計図。画面の構成や個々の部品など，画面上に何が表されているのかを示すだけでなく，画面の操作やその操作によってどんな処理が発生するかを記述する。 （4）画面遷
親世代に PC
親世代に PC 2003-09-02-2 [Book] 両親にインターネットを使わせるとしたら <http://www.zdnet.co.jp/news/0309/01/cjad_kodera.html> (via <http://papalagi.org/diary/200309.html#20030902>) なるべくトラブルが少ないようにせよ、ということですね。大いに賛成。残り少ない人生なのに、しょうもないトラブル対処法を覚えても仕方がない。私だったら、還暦過ぎてまでバッドノウハウなんか覚えたくない。 以下、D.A.ノーマンの「パソコンを隠せ、アナログ発想でいこう!」からの受け売り。 ■パソコンを隠せ、アナログ発想でいこう! 1922 年のラジオの取り扱い説明書には、真空管をどうたら、加減抵抗器をどうたら、フィラメントがどうたら、再生コイルをどうたら、など、なんだかとても複雑な操作方
キャズムを超えろ！ - 団塊～シニア層向けのWeb設計 やっちゃいけない10のＵＩ
一時期パソコン教室の講師をやっていたことによる経験と、昨今Webサービス運用にあたって中高年層からのクレームなどを自分なりにまとめた結果として、50代以上のユーザに対するWebサービス＆PCアプリケーションのUI設計における以下10のTIPSを公開してみたいと思う。...といってもたかだか10個で収まる簡単な話ではないので、思いついたら都度追加して行きたい。 ID，ニックネームを考えさせてはいけない。半角英字開始限定は論外 IDやニックネームが思いつかない方が多い。これはシニアに限らず、ITリテラシーがそれほど高くない若年層についても言えること。作る側の人間も「過去にWebで使ったID,Nicknameは全て使っちゃダメ。何か新しいのを考えて入れてみて。」と言われると結構悩んじゃうもの。それと同じ状態に陥ると思っていただけるとわかりやすい。「IDのかわりに電話番号でもいいですよ」というと結
特集：無線LAN構築のABC 1. アクセス・ポイントのチャンネル設定 - ＠IT
特集 無線LAN構築のABC 1. アクセス・ポイントのチャンネル設定 デジタルアドバンテージ 2002/07/31 電波は思ったよりも遠くへ届く 導入する規格が決まったら、アクセス・ポイントの設置場所を決めることになる。ここで気をつけなければならないのは、窓際などに設置すると、屋外にも電波が漏れてしまうことだ。予期せぬ第三者が電波を傍受することにより、不正なネットワーク侵入やデータの盗聴を許しかねない。無線LANの電波は意外と広い範囲に到達するので注意が必要だ。カタログでは、屋内で50m、屋外で100mといった記述を見かけるが、設置場所によってはさらに遠くへ到達することがある。例えば、電波の到達距離が半径50mだったとしたら、約70m四方（約1485坪）のオフィスの中心にアクセス・ポイントを1つ置くだけで、すべてカバーできることになる。逆にいえば、これよりも狭いオフィスでは、電波が届いて
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Network Notepad Homepage
http://nlftp.mlit.go.jp/ksj2/index.html
30分間データモデリング 〜ER図を描こう！〜（1/4） ― ＠IT
