タグ

設計に関するOkadaHiroshiのブックマーク (8)

  • 100%失敗するWebアプリの作り方 - 最速チュパカブラ研究会

    誰にとは言いませんが、私からの警告です。 要件 「Web上で日記を書いて、コメントをつけるシステムを作りたい」 普通の技術者の設計 えーと、日付ごとに分けてテキストを保存しておけばいいんだな。一日に複数の話題を書くこともあるだろうから、先頭に * がある行は見出しとして扱おう。コメントはシンプルなテキストで、各日付に関連させておけばいいな。 以上。 天才(自称)の設計 ふむ、コメントつきの日記システムか。凡人にはコメントと文は別物のように見えるかもしれないけど、俺に言わせると実は同じものなんだ。だって、どちらも何かの話題に対して何らかの意見を述べているものだろ? 違いは、ある話題のツリーのトップにあるのが文、そこにぶら下がってるのがコメント。ツリーといえばファイルシステムだ。そう、つまり我々が作ろうとしているものはファイルシステムの一種なんだよ。日記を書けるファイルシステムというものを

    100%失敗するWebアプリの作り方 - 最速チュパカブラ研究会
  • デモではものができあがっているように見せない

    Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも

  • キャズムを超えろ! - 団塊~シニア層向けのWeb設計 やっちゃいけない10のUI

    一時期パソコン教室の講師をやっていたことによる経験と、昨今Webサービス運用にあたって中高年層からのクレームなどを自分なりにまとめた結果として、50代以上のユーザに対するWebサービスPCアプリケーションのUI設計における以下10のTIPSを公開してみたいと思う。...といってもたかだか10個で収まる簡単な話ではないので、思いついたら都度追加して行きたい。 ID,ニックネームを考えさせてはいけない。半角英字開始限定は論外 IDやニックネームが思いつかない方が多い。これはシニアに限らず、ITリテラシーがそれほど高くない若年層についても言えること。作る側の人間も「過去にWebで使ったID,Nicknameは全て使っちゃダメ。何か新しいのを考えて入れてみて。」と言われると結構悩んじゃうもの。それと同じ状態に陥ると思っていただけるとわかりやすい。「IDのかわりに電話番号でもいいですよ」というと結

    キャズムを超えろ! - 団塊~シニア層向けのWeb設計 やっちゃいけない10のUI
    OkadaHiroshi
    OkadaHiroshi 2006/11/18
    パスワードに数字4桁はだめすぎるが、これは銀行等のキャッシュカードが駄目な例をいまだに放置しているせいかも。確かに桁の多い英数字は苦痛な人もいるだろう。そろそろパスワードに日本語OKにしてもよいのでは。
  • 技術メモ帳 - 拡張子ごとにコマンドを対応づける

    拡張子ごとにコマンドを対応づける事が出来る Suffix Alias という機能が zsh 4.2系から実装されていたらしい。 知らなかった。 どんな事が出来るのかというと たとえば、 alias -s txt=cat とした場合、 以下のようにするだけで、 % ./file.txt 先ほど設定したコマンドが自動で実行されるようになる。 % cat ./file.txt あとはもうアイデアしだいだが、 拡張子が *.log のときは、tail -f するなんて事も出来る。 alias -s log='tail -f' 参考: http://zshwiki.org/home/examples/aliassuffix http://slashdot.jp/articles/04/03/27/2333234.shtml?topic=80 http://zsh.dotsrc.org/Doc/Rel

    OkadaHiroshi
    OkadaHiroshi 2006/11/07
    GUIでは当たり前の機能がやっとCUIに、#!と競合する場合はどうするのかな?この件はMacみたいにクリエータタイプとファイルタイプもっているのが、便利なんだが。
  • いまどきのデスクトップ処理系 steps to phantasien t(2006-09-22)

    いまどきのデスクトップは色々モダンになっている. ただモダン化は API の裏側で進んでいるため, あまり興味を持たれていないらしい. 一見いろいろウォッチしていそうな知り合いと話していてわかった. 利用者視点の話題では, いまどきのデスクトップというとたとえばウィンドウが ヘナヘナ揺れるといったアイ・キャンディばかりが連想される. でもそのアイ・キャンディに至るにはきっと山ほど苦労があったはず. そのへんをちょっとねぎらってみたい. 念頭にあるのは Windows Vista, Mac OSX, XGL あたり. まず共通の階層化されたアーキテクチャを想定し, ケーススタディを交えつつその層を下から上へ順にたどっていきます. 復習: デスクトップ処理系の階層構造 そもそもデスクトップの中味はどんな構成をとっているのか. ざっと眺めておこう. 典型的なデスクトップ処理系のアーキテクチャはだ

  • すでに入り口にいるのに、ホームに導くボタンは親切か ― @IT

    Webアプリケーションのユーザーインターフェイス[7] すでに入り口にいるのに、ホームに導くボタンは親切か 「可視性とフィードバック」 ソシオメディア 上野 学 2006/2/15 前回の「『戻る』で入力データが消えてしまうフォームはいらない」では、経験則その2として「寛容性とユーザーコントロール」の話をしました。システム側がユーザーを信頼し、ユーザーのコントロール下でユーザーの思いどおりの振る舞いをすることで、ユーザーとシステム(あるいはサービスの提供者)との間に信頼関係が生まれ、利用効率や生産性が高まっていきます。 そこで今回は、どうすればユーザーが思いどおりにシステムをコントロールできるのか、どうすればユーザーはシステムが自分の思いどおりに動いていると感じるのか、ということを考えたいと思います。これが経験則その3、「可視性とフィードバック」です。

    OkadaHiroshi
    OkadaHiroshi 2006/02/15
    電車式と自転車式
  • Infoperience - 「OK」ボタンの秘密

    「OK」ボタンの秘密 デザイナーというものはいつも、混沌とした事物の断片を整理して、どこまで最終的に求められる方向性を保ったままそれらを秩序立てることができるのかという挑戦を強いられている。そのために、最終目的に合わせたひとつの法則を作り出し、細かな選択(この部分は青にするのかそれとも赤にするのかといったこと)を行う上での判断基準にするのである。しかしひとつのデザインに求められるのはひとつの機能だけではない。論理的に考えれば機能衝突を起こすような要望があるのが普通であり、また、デザインにはそれを解決するだけの力があるのだ。 例えば、上級者にとっての使い勝手を向上させるために新たなインターフェイス要素を導入することが決まったとする。これは既存のデザイン言語に合わせてきちんと設計された機能であり、デザイナーはそれをどうやって定着した画面要素に加えようかと悩むことになる。そして一貫性を保ったまま

  • FC2Blog - 404 Error

    Page not found ご指定のファイルが見つかりませんでした 30秒後にトップページへ移動します

  • 1