議論/良いデザイン


Top / 議論 / 良いデザイン

このページは何か? (by ひげぽん)

自分が良いデザイン、悪いデザインだと思うものを列挙していき価値観を共有できると良いなというページです。
デザインの粒度は特に気にせず、UIでもコーディングでもプロジェクト運営でもどうぞ。
「良いデザイン」「悪いデザイン」の追記を歓迎します。(テンプレに従い追加してください。)
感想はコメント欄にどうぞ。

デザイン

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • なるほど。お題をしぼることが大事なようですが、何が良いかな。MonAPIに関しては正直まだそこまで、こうあるべきだというものが浮かんでいません。Monaでアプリを書かないからか。 -- ひげぽん 2006-10-05 (木) 00:27:48
  • このページの本来のお題に沿って良いデザインと聞いてイメージするキーワードを書いてみます。(↓のコメントでだいぶ、背景のイメージを書いたのでキーワードにしても比較的伝わるに違いない、、、伝わると良いな) -- Gaku 2006-10-04 (水) 00:36:21
    • 良いデザインは意思を持つ。 → デザインには作者の「こーいう事をしたい」って意思が反映されると思うのです。例えば「おれの考えるMonAPIの世界はこうだ!」とかね。 -- Gaku 2006-10-04 (水) 00:44:40
    • 良いデザインは目的を実現する。→作者の「こーいう事をしたい」という目的を実現するためにデザインする訳で、良いデザインは、何がしかの目的を実現してるハズです。 -- Gaku 2006-10-04 (水) 01:28:51
    • 良いデザインは人々に選ばれる。→作者の目的と、それにより与えられる何がしか(例えばメリットとか)を選ぶ、人々の選択が一致したとき、それが良いデザインなのだと思います。 -- Gaku 2006-10-04 (水) 01:38:12
      • "思います"が入ってしまった。弱気だ。 -- Gaku 2006-10-04 (水) 01:38:36
  • ユーザが全員開発者という原状で、ユーザに見える必要のないものってなんだろう。むしろ、できることはなんでも、手軽にできるって方がいいんジャマイカ。もちろん、最低限の保護は要るだろうけど。メモリ保護を解除するには少し長い名前のシステムコールを呼ばなきゃいけないとか。 -- ひらっち 2006-10-01 (日) 02:17:18
    • 開発者にとって手軽にというのはGakuさんが引用しておられるhttp://cvs.m17n.org/~akr/pub/rubykaigi2006-06-10.pdfの方向性が望ましいのではないかと思いました。これは特定の処理に焦点を絞ってユーザー側のコード量を削減するという方向での「手軽」なので、何でもかんでも見せるというのとは反対の方向です。何でもかんでも見せると処理はなるべくシステムコールの組み合わせで書くようなイメージになると思いますし、そうすればどんなことでも出来るかもしれませんが、記述がプリミティブ過ぎてまったく手軽ではないでしょう。 -- Tino 2006-10-01 (日) 08:32:02
      • プリミティブ過ぎるということで思い出しましたが、マウスやキーボードを扱うためにサーバーに登録してメッセージループを書くというのも、かなりプリミティブですね。Monaのコードを見てまず独特な雰囲気を感じるのはこの部分でしょう。そのためMonAPIにはMonaApplicationというクラスがあって、これを継承してonMouseClick()などをオーバーライドするような仕組みが用意されていますが、メッセージループが固定化されてしまうので、それ以外のメッセージを扱う場合には結局自前で書いた方が手軽ということになってしまって、全然使われなくなってしまいました。個人的な意見ですが、最初からどんなことにも対応できるスマートな設計なんて絵に描いた餅で、最初は泥臭くても使いながら叩き上げるしか方法がないと考えています。色々と作っているうちに定石みたいなものが出来てきて、同じようなコードがあちこちに分散して冗長になってきたら、それをまとめるということを繰り返すしなかいのではないか、ということです。こういうことをイメージして、ひげぽんさんには「北斗神拳は戦場の拳!千変万化する闘い中にこそ、その奥義を見出した」ということをいつも申し上げていました。 -- Tino 2006-10-01 (日) 08:57:25
      • たとえばオーバーライドにしても、必ずクラスを継承しないといけないという面倒くささがあります。コールバック登録制にすると、インスタンス関数を直接呼び出せなくなって、これまた迂回コードを強いられる面倒くささがあります。このようなことに両方対応しようとすれば継承と委譲を対等に扱うというWindows Formsの流儀に行き当たりますが、逆にそれしか方法がないというのはブラックボックス過ぎて気持ち悪いです。そうなると自前でメッセージループを書くのが一番好きにできて気楽ということになってしまいます。ですが常に自前で書くのは明らかにプリミティブ過ぎます。多分、万人向けの標準仕様に統一するというのは無理で、好みに応じて好きなようにできる余地を常に残すくらいが落とし所ではないかという気がします。 -- Tino 2006-10-01 (日) 09:22:57
    • システムコールを直接呼ぶことと保護とはあまり関係がないでしょう。メモリ保護についても、プロセスから見て同じアドレスでもマッピングされている物理アドレスが異なるので、解除するためにはプロセスでも物理アドレスを使うような構造にしないといけませんが、それをするとプロセスのロードがアドレス決め打ちにできなくなるので、配置済みの生バイナリという手軽さが失われて、常に再配置することになってしまいます。つまりOSの仕組み自体が変わってしまうので、システムコール一発で移行できるようなものではないです。プロセスの壁が邪魔になるときは共有メモリを窓として使えば充分でしょう。 -- Tino 2006-10-01 (日) 08:35:01
  • そろそろ、ここはお前の日記か?て感じですがデザインに関してつらつらと考えた事を書いてみます。何なら、この内容は自分のページの所に移しても構いません。 -- Gaku 2006-09-30 (土) 16:57:02
    • Mona OS や MonAPI やその他ライブラリをデザインするって事はどーいう意味があるでしょうか?デザインする事の意味は、やりたい事を実現するってことだと思うのです。成し遂げたい目的を実現するデザインをする訳です。
    • では、目的は何でしょうか?モノを作るなら使ってもらう事が目的だと思うのです。だから、使ってもらえるデザインをする訳です。
    • 使ってもらえるってどーいうことでしょうか?使う人に利益を提供する事だと思うのです。人はメリットがあるからそれを使う。だから、メリットを提供するデザインをする訳です。
    • ここで立ち止まって、良いデザインってどーいう事でしょうか?より良く目的を実現できたデザインが良いデザインだと思うのです。より良く使ってもらえるデザインであり、より良くユーザにメリットを提供するデザインです。
    • では、良いデザインにして行く、って事はどーいうことでしょうか?現在のデザインのどこが良くて、どこが悪いかを考えて、どこを直せばより効果的に目的を良く実現できるデザインとなるか?良し悪しを把握してデザインを改善する事が良いデザインにして行くという事だと思うのです。
    • これはライブラリを作る場合でもfile_serverを作る場合でも同じです。現状では目的を実現していない部分があって、なぜ駄目か、どうすれば良くなるかを把握して良くして行きますよね。だからデザインも、なぜ目的を実現できなかったか、なぜ駄目か、どうすれば良くなるかを把握して良くして行くものだと思うのです。
    • デザインが悪ければ、今のデザインを打ち壊して新しいデザインを作れば良いと思います。でも、ただ闇雲にデザインを打ち壊しても駄目です。なぜそれでは悪いか、なぜそれで良いか、を考えてより良いデザインを打ち立てるのです。
    • と、脱線しつつあるので最初の目的に戻ります。良いデザインにして行くという事は、より良く目的を実現するようにデザインを改善する事だと書きました。てことは、目的が何か分からなければ良いか悪いかも判断できないよね。と。
    • 最近はGUI改善であったり、file_server改善であったり、目的を明らかにして改善案を出して、着実に直す。という方向で Mona PJ Wiki は進んでいるようです。良い事だと思います。では、なぜ、Mona OS や MonAPI に対してそれができないのでしょうか?多分、まだイメージが具体化されてないからだと思います。でも、イメージが具体化できてないなら、色々話してみたら良いと思う訳です。
    • んー。でもまあ、物事には順番ってものもありますし、急いては事を仕損じるってこともありますから、イメージが具体化できてないってことはまだまだ時期ではないのかもね。てな事を思ったんですが、、、まぁデザインに関するイメージの共有化ってことで。
    • 「なぜ、Mona OS や MonAPI に対してそれができないのでしょうか?多分、まだイメージが具体化されてないからだと思います。でも、イメージが具体化できてないなら、色々話してみたら良いと思う訳です。」この話は良く分かりました。色々話し合うってのが難しいですよね。どうしたら良かろうか。経験上具体的な程発展するんですがうーん。 -- ひげぽん 2006-10-03 (火) 22:55:03
      • お。3回目のトライにして言いたい事が通じた気ですか。3回とも言いたい事の基本線は同じで↑だった訳なのですけど、通じていたかな?(1回目、2回目、3回目、とだんだん整理してきてる所が我ながら、、、最初から整理しとけよ。という。) -- Gaku 2006-10-04 (水) 00:30:58
      • やはり自分なりにイメージを固めて、もって行きたい話の方向ができて、それからこう思うのだけどどうかな?って切り出し方になるのかなぁ。とか。ってそれだと、イメージが湧いてないときに色々話す事ができないですな。困ったね?<具体的な程盛り上がる -- Gaku 2006-10-04 (水) 01:54:49
  • もう少し具体的な話題に振り分けた方が良いだろうとも思いますけど、下の方で書いた話もそれなりに必要な事だと思うのですよね。てな訳でもう少し続けてみます。てか、どーいう話に持って行こうとしたかをもっと明瞭に書いてみよう。 -- Gaku 2006-09-28 (木) 04:12:23
    • まず、このページのお題は「良いデザインに関するイメージを共有する=良いデザインに関してだれがどんな事を考えているかを見せ合う」だと受け取っています。けれど、元の話題がひげぽん/ぐだぐだ箱の「どのレイヤを切り取ってもデザインセンスの良い環境の提供」だと思っているので「Mona OS のデザインを良いものにしたい or Mona OS で良いデザインがしたい」というお題もあるのだと受け取っています。 -- Gaku 2006-09-28 (木) 04:22:09
    • それで、イメージ共有のお題はこうしてコメント書いてるので良いとして、「Mona OS のデザインを良いものにしたい」なんですけど、良いデザインをするためには、良いデザインについて考えないといけないと思うのです。なので「良いデザインについて考えようよ」という意図で昨日はコメントを書きました。(昨日書いた文は「最高に良いデザインってのがあって、そこに一発で行けば何でも組み込めるし、使いまわせるじゃん」てな事では全く無くて、良いデザインの切り口という物が考えられるはずで、そーいう切り口で、Mona OS で実現する file_server なり、MonAPI なりの良いデザインの話をしないか?と書いたつもりですが、意図が不明瞭だったかな。) -- Gaku 2006-09-28 (木) 04:26:18
    • 「良いデザインについて考える」をもう少し詳しく書くと、例えば、良いデザインのライブラリorAPIってどんなもの?とか、良いデザインのサーバ郡ってどんな構成?とか、良いデザインのGUIってどんなもの?とか、そーいった類の話です。参考になりそうな例を引き合いに出してみます。例えば、ライブラリの良いデザインについて考えるという事はhttp://cvs.m17n.org/~akr/pub/rubykaigi2006-06-10.pdfのような事を書き出すイメージです。(良いデザインと言ったときには、そのデザインがなぜ良いのか?を書き出せるものだと思うのですよね。なので、デザインと、そのデザインが良い事を裏づける考え方は切り離せないと思うのです) -- Gaku 2006-09-28 (木) 04:30:52
    • 大体良いかな?ついでに話を続けた理由を書きます。Mona OS はどーいう機能を提供するのか?その機能はどんな(サーバの)構成で提供するのか?ていう構成に関するデザインの話をしたいなー or どうしたいのか聞きたいなー、と思ってるからです。ライブラリの例を出しておいて何ですが、いきなり、じゃ、MonAPIは、どういうクラス、どーいう関数、を作ろうか。てな話から始めたくないなぁ。という感じです。が、参考になりそうな例が今日は見つけられませんでした。「こーいう話がしたい」って例が示せると良いのですけど。だれか「ソフトウェアアーキテクチャの良いデザイン」とかそんな感じの参考になりそうな資料知りません? -- Gaku 2006-09-28 (木) 04:49:16
    • そんな事は言ってもデザインに関する話が進まないのも何なので「MonAPIをどうするか?」なんて所から話を始めた方が手っ取り早いかもですね。シチュエーションを決めずにデザインの話をするとhttp://www.shiro.dreamhost.com/scheme/trans/taste-j.htmlみたいな感じになると思うのですが、読む側がシチュエーションを与えないと、何となくそーいう事が多いけど、そーでない事もある、みたいな事になってしまいますし。(パターン集はシチュエーションを与えて初めて生きてきますよね) -- Gaku 2006-09-28 (木) 05:00:52
    • 最後に「イメージ共有のお題」のために昨日書いた「メリットがあるから良いデザインだ」に少し触れておくと、http://www.shiro.dreamhost.com/scheme/trans/taste-j.html、を見せて「ほら良いデザインってのはメリットを提供してるでしょ?」って言ってしまうような感じですかね。 -- Gaku 2006-09-28 (木) 05:07:55
    • んー。もう1つ書きたくなってしまった。という訳で今まで書いた事を一言に凝縮してみよう。一言:「Mona OS でこれから何を作ろうと思ってる?」 -- Gaku 2006-09-28 (木) 05:29:46
  • うーん。もっと議題をしぼった方が良さそうですね。Monaのデザインが悪くて、改善の余地がある部分というのを探した方が良いのかな。 -- ひげぽん 2006-09-27 (水) 22:14:21
  • 議論/成果を取り込もうで書いた、だれかがインタフェースに合わせて書いてくれさえすれば自動的に成果を取り込めるって事を補足します。 -- Gaku 2006-09-27 (水) 02:45:13
    • 誰かが書いたコードを取り込む際に、インタフェースが合わなければ書き直したりします。でも書き直すのはそれなりに大変です。大変な訳なので放置されます。つまり、誰かの書いた成果は取り込まれない訳です。なんで、インタフェースが合わないかって言えば、インタフェースが決まってないからです。Mona OS の機能をどう構成するか?どこでレイヤを切り分けるか?インタフェースはどうするか?が決まってれば、後はそれに則って書けば、その部分は交換可能になります。誰かがコードを書いたらそのままMona OSに組み込みしたりできるって事です。 -- Gaku 2006-09-27 (水) 02:47:55
    • んー。こういうのは機能構成とでも言うかな?機能構成のデザイン? -- Gaku 2006-09-27 (水) 02:50:41
  • Mona OSのデザインをお題にしてみます。 -- Gaku 2006-09-27 (水) 01:53:00
    • まず、デザインの話をする際の切り口を書かなきゃいけないかな? -- Gaku 2006-09-27 (水) 01:50:40
    • 良いデザインに関して幾つか良く言われる特徴的な事があると思います。例えば、シンプルが良い、1つの物は1つの所に、どこを取っても一本スジが通ってる、などなど。で、これらの特徴は実際的な理由で決まってるハズです。例えば、そのデザインが何を意味するか理解し易い、理解した考え方を再利用して当てはめる事ができる、実際に修正するとき修正箇所が明瞭、などなど。つまりメリットがあるから良いデザインだ、と言われる訳です。 -- Gaku 2006-09-27 (水) 01:51:05
    • てことは、Mona OSが良いデザインであるためにはユーザにメリットを提供しなきゃいけません。とりあえず↑で書いたものは含むとして、議論/成果を取り込もうに書いたように何かコードを書いたらMonaに組み込める、なんて事もメリットになるハズです。それで次はMona OSが何を持ってユーザにメリットを提供するか?です。(つまり、メリットを提供する何かが良いデザインである必要がある)まぁ「Mona OSが何を持ってユーザにメリットを提供するか?」なんてのはユーザを誰にするかで変わりますけど、とりあえず、アプリ開発者であるとしてみます。(もちろん、他のレイヤのユーザも想定できますよね。できてます?)すると、アプリ開発者に「何」を通して「どんなデザイン」でメリットを提供するか検討できるハズです。 -- Gaku 2006-09-27 (水) 02:06:21
    • それで「何」の話です。何かって言えば、アプリ開発者にMona OSの機能を提供するものです。例えば、ユーザライブラリ(MonAPI)、ファイルシステム(file_server)、ユーザインタフェース(BayGUI、MonaFrms)、とか。(特に各種ユーザライブラリはアプリ実装の際に直に使うので直接関わります)で「どんなデザイン」ですけど、アプリ開発者に「ユーザライブラリ」「ファイルシステム」「UI」などがMonaOSの機能をどう提供するか?先ほど書いたメリットを提供できているか?という事が良いデザインになっているかを決めるわけです。 -- Gaku 2006-09-27 (水) 02:21:42
    • そんなこんなで、例えば、「MonAPI」はアプリ開発者にMona OSの機能をどう提供して、どんなメリットを提供して、そのためにどんなデザインにするか?てな話はしないのかな?と思ったりするんですけど、んーMonAPIじゃ限定しすぎかな?もしくは、何を話題として取り上げるべきか、まだ整理付いてないかな? -- Gaku 2006-09-27 (水) 02:29:34
  • あれ。意見がないということは全面賛成?切り口が悪かったかなあ -- ひげぽん 2006-09-26 (火) 20:42:00
    • 切り口は悪い気がしますね。デザインの幅が広すぎます。んー。実用化・成果を取り込もう、辺りのページと同質だと思うと良くないかな。お題で書いてある事を読んでみるに、今日の一言みたいな感じでデザインに付いて思うところをだべってみるって感じのページですかね。と言いつつ、テキトーな話題に絞って始めてみます。 -- Gaku 2006-09-27 (水) 01:08:02

MENU

now: 2

リンク


最新の20件
2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 2819, today: 2, yesterday: 2

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:03 (3829d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.056 sec.