5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

理想的なUI【ユーザインタフェース】を考える

1 ::02/09/29 13:23
単刀直入に、UIの理想形を追求します。
「Win vs Mac」対決は下記の関連スレに譲りますが、
何を理想としているかがわかれば、決着はすぐにつくはずです。

Mac VS. WinどっちのUIが優れているか対決!
http://pc.2ch.net/test/read.cgi/jobs/996135239/
なんだこりゃ? マクの破綻したGUI
http://pc.2ch.net/test/read.cgi/jobs/997160386/
Win<UNIXだからUNIX+MacGUIが最強!
http://pc.2ch.net/test/read.cgi/jobs/1005134807/


2 ::02/09/29 13:27
最初のお題は「ゴミ箱」。

1つの動作(ゴミ箱へのドロップ)に、
2つ以上の意味(ファイルの削除とボリュームのイジェクト)があるけれど、
対象によって動作が変わるような仕組みは、理想的なんだろか?

ゴミ箱の他に取り出し用の操作(Windowsだと右クリック)を用意して、
ゴミ箱はファイルの削除に徹した方がわかりやすいのでは無いだろうか?

なんて話で、どうでしょう。

3 :村澤:02/09/29 13:31
 / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 | いまだ2ゲットー
 \_______ _______
         ∨
           ∧_∧  /
     ⊂ ⌒( ´∀【◎】  カシャ!
 ≡≡ ⊂_  _つ9 \
   ズザーーーーーッ

4 :村澤:02/09/29 13:34
 / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 | いまだ3ゲットー
 \_______ _______
         ∨
           ∧_∧  /
     ⊂ ⌒( ´∀【◎】  カシャ!
 ≡≡ ⊂_  _つ9 \
   ズザーーーーーッ

5 :村澤:02/09/29 13:35
1つぐらいズレてたってええじゃないかええじゃないか

6 ::02/09/29 13:38
>>5
2つぐらいズレた投稿がある気がするのは漏れだけか?w

7 :●~*:02/09/29 13:45
>>2
たしかに、Winが先の人には勇気が必要。
CDならまだいいが、書き込み可のメディアだとなんか不安。

8 ::02/09/29 13:49
一応ゴミ箱っていうメタファーが使ってあるけど、冷静に考えてみるとゴミ箱で
ファイル削除ってのも少し変かもしれない、分かりやすくはあるけど。
ぶっちゃけ、焼却炉でも何でもよかったのではないかなぁ。

9 :●~*:02/09/29 13:52
>>2
俺は、不要なファイルを掴んで、すばやく放り投げるようにしたら
ゴミ箱に入って、ゴミ箱にマウス近づけると、中が見えてゴミ箱に
手を突っ込んで、取り出す
ゴミ箱を右ボタンクリックすると火が出て、ゴミに火をつけて燃やす

そんなUIがいいな。

10 ::02/09/29 13:52
旧MacOSの場合、なんかの作業する際にデスクトップっていうけっこう
広い道路を通して、各タスクを連携しているわけで、ゴミ箱はファイルを
削除するっていうよか、目に見えるアイコンを消したいときに使うものなん
かもしれんね。
イジェクト、ファイル削除も、その時目障りなものを見えなくするっていう
役割も果たすわけだし。

作業が単純な時代は、Finderでよかったかもしれないけれど、正直現
状を鑑みると、それほどあれは使いやすいものではないと思うよ。

11 ::02/09/29 13:54
>>9
使うの楽しそうだw

12 :●~*:02/09/29 14:06
で、ここで論議された結果で、
Linuxかなんかのデスクトップ作るんですか?
もしくはKDEとかGNOMEに企画提出するの?

それとも妄想と談話で終わるの?

13 ::02/09/29 14:12
>>12
それは旧板の事ですから、妄想と談話で終わります。w

つーか、理想形がまとまってもいないのに行動考えても仕方ないかと。
まずは「考える」で、その後にいい成果が出たら活用法でも考える、と。

>>9
漏れはゴミは箱から取り出してゴミ捨て場に持っていった段階で終わりなので、
「ゴミ箱を空にする」動作は別に今のままでもいいなあw

>>8
メタファは後でいいやw

>>7
Macが先の人は「そういうもんだから」という納得の仕方をしてると思うんだけど。


14 ::02/09/29 14:12
>>12
Linuxのデスクトップ環境って、なんかアプローチ変な気がするよ。
新規ユーザーが、なんでウインドウズと同じようでありながら、出来の悪いもの使うと思うんだろう。
自分たちがあれを使いたいから作ってるんなら、文句なしだけど。

15 :●~*:02/09/29 14:19
>>13
先の展望が見えないと、真面目に話す気力が萎えるんだよなぁ…

>>14
質問の返答になって無い、書き直し。

16 ::02/09/29 14:20
たとえば、「ゴミ箱」が「物を安全にシステムの外に追いやる」という点で、
動作は異なるが目的は同じである、としよう。

リムーバブルボリュームを「ゴミにする」のは、メディアを排出すること。
ファイルを「ゴミ」にするのは、削除すること。(※語弊含む)

たとえば、このポリシーを徹底するのであれば、
「ゴミにする」事が出来るものはすべてゴミ箱への操作で良いと思うのよ。

固定ディスクボリュームを「ゴミにする」のは、フォーマットすること。
アプリケーションを「ゴミにする」のは、アンインストールすること。

でも、そうする事で意味は増え続けて、ややこしくなる。
最近のMacは、それを踏まえてアイコンへの動作を単機能にしたのでは無いかな。


17 :村澤:02/09/29 14:21
梨はなぜそんなにややこしく物事を変換できるのか。

18 ::02/09/29 14:25
>>15
べつに、返答しているつもりはないが。
逆に問うているんだよ。

必ずしも、GUIでなくてもいいでしょ、Linuxは。
初心者が導入しやすいCUIのあり方を考えてもいいわけで。
実際使っているユーザーや普及させようと頑張っている人から、
なんでそういう声が上がらんのか、不思議でたまらん。

新しいこと考えるのは、しんどいけど。

19 ::02/09/29 14:27
>>15
「理想的なUIを考える」という表題だけで、先の展望は見えてると思うが。

君が望むのであれば、
「理想的なUIを考えるスレの結果を企画書にして提出するスレ」
でも立てて音頭を取ればいいと思う。
少なくともここは2ちゃんねる内のスレッドに過ぎない訳だから、
ここに書き込まれた内容を誰がどのように扱うか、漏れが制限する権利はない。

具体的な行動を明確にしたくない理由は、
企画書を出すなら出す先に対してアプローチが変わるから。
Linuxで作るならLinuxに向いたアプローチしか出来なくなるから。

OSネイティブなUIなんてのは語り尽くされたし、
「このOSではそれが仕様だから」と言われてしまえばそれまでだと思う。


20 ::02/09/29 14:29
>>17
上で企画を出すとかLinuxで開発するとか身構えちゃう人がいる通りに、
ややこしい話をするスレである事は百も承知なので。

>>18
声はあがっているよ。どういうアプローチかはまだ知らないけど、
あれはUIレベルでの改善じゃなくて、アプリのラインナップ的な改善にも見える。

21 :●~*:02/09/29 14:33
壁キャッチボールスレになってしまった訳だが。

22 ::02/09/29 14:34
>>16の続き。

言い換えれば
「メタファとして統一出来ないものを統一してはいけない」
って事なんだろうね。

ゴミ箱は「捨てようと思った物を溜めておいて、取り出したり削除出来る」
から、ああいうメタファになったのであって、
既に箱では無く、ドロップすると即座にメディアを排出する
「イジェクト機能」とは統一出来ないように見える。

そこで新しい概念としてAppleが打ち出したのは、
「メタファ」に依存せずに、ターゲットが違うと、アイコン自体の形を変えて、
「物を安全にシステムの外に追いやる機能」として括ったんだろうね。

ごみを捨てる時はごみ箱になって、
CDを焼却する(?)時には焼却炉になる。
これで、「ターゲットによって、目的は同じでも動作が異なりますよ」
と主張出来ている事になるわけだ。


23 :●~*:02/09/29 14:36
>>20
身構えてる訳じゃ無くて、実のならない木に栄養を与えてもどうしようも無いという事っす。

24 ::02/09/29 14:37
>>20
あくまで、ちょっとインストールししてみての感想なんだが、なんかVineにはバカにされた気がしたw
GUIアプリケーションの設定やらなんやらは、ウイソ位には簡単にできるけれども、それなら今ある
ウイソを使うよって話で。
その奥に進むのになんか訳の分からん障害がたくさんあるみたいな感じだよ。

Gentooはインストールすら出来なかったけども、オモシロイとおもった。
もうチョイ分かりやすかったら、入門にぴったりじゃないのかな。
日本での評判はどうなんだろ。

っていうかUIの話じゃないね、これ。

25 :●~*:02/09/29 14:39
>>24
インストーラーも重要なUIです。

26 :●~*:02/09/29 14:40
LinuxのKDEというかKonquerorの目指す方向性はいいと思うんだが。
今はLinuxなんてhttp://unit.aist.go.jp/it/knoppix/
でちょっと触るぐらいだが、
いまのBetaが完成したら本格的に使おうと思っている。
ただ、なんでも自前でやろうとする姿勢はうなずけない。

27 ::02/09/29 14:42
なんかまわりくどい言い方だな。

「アイコンが変わってしまうから、メタファはどうでも良くなった」

「インタフェースを沢山作って、やりたい事と動作が一対一になるのがWin。
 1つのインタフェースで似たような目的が達成出来るのがMac」

という事です。簡単に言うと。

これをOOP用語で「多態性」(ポリモーフィズム)って言うんだけど、
これを採用する事の問題は、
「本当にMacは様々な物を多態性で表現出来るのか?」
という点にあると思うのです。どうでしょ?


28 ::02/09/29 14:42
>>25
いや、ふっと冷静になって考えてみると、
「折れの最近ムカついた話」
にすぎないかなぁと。

29 ::02/09/29 14:46
>>27
動作の分類が大雑把なんだとおもうけど。

「邪魔なものを見えなくする」=「イジェクト、削除」
「ファイルを別の場所におく」=「ファイルコピー、移動」

ウイソは、それが細かいような。

30 ::02/09/29 14:49
>>23
漏れはまだ「考える」レベルでがんばってるんで、
企画書が出せるレベルにいる君は、Linux開発者のMLなり
なんなりに行って直接意見交換をした方が良いと思うよ。

繰り返すけど、特定のUI開発者の身になるために
考える訳では無いので、即物的な貢献はどこにも無いです。

>>24
「まずはWinを目指す」というだけでも成長したんでないのかね。
結果的にWinをまねる必要なんかは全くないわけだけれど。

>>26
うわ、これ初めて知った。面白そう。
オンメモリブートに使えないかなー。ふふふ。


31 ::02/09/29 14:53
>>29
「Macは直感的だ! おおざっぱにでも扱えるから!」という言い分と、
「Winはわかりやすい! 一覧から目的の動作を探すだけだから!」
という言い分のいいとこどりをする方法が無いかなー、と。

Winが細かいのは、厳密にやりたい事を指定させるからだと思うよ。
自分のしたい事がわかってれば、操作はわかりやすい。

32 :●~*:02/09/29 14:53
GUI=デスクトップということではないような気がするのは折れだけ?

もうちょっといろいろな可能性を考えてみると話が広がる気がする。

33 :32:02/09/29 15:00
補足

ゴミ箱というのはデスクトップという概念があるから存在する。

理想的なUIを考えるというスレタイなので、ゴミ箱一つにこだわらずにもっといろいろ考えてみてもいいのでは思ったので。

わかりにくくてスマソ

34 ::02/09/29 15:01
>>32
問題提起のために、現状からボトムアップ式に話そうかと思ってたんよ。
「Finderからファイルシステム以外の物が、
 まるでファイルのように見えてしまうUI」
を次のお題にしてみたり、
「Dockやタスクバーを超える作業の管理方法」を議論してみたり。

そんな事しなくても「これが理想的だ!」ってのが既にある程度あるなら、
そいつを聞いてみたほうが圧倒的に話は早いだろうなあ。よろしくです。

35 ::02/09/29 15:03
>>33
補足

「UI」って書いたので、「GUI」じゃなくてもいいです。
ただ「脳波を使って、考えたことをそのまま実行する」みたいなのは嫌だな。w

今使っているコンピュータに対して実現可能なネタがよろしいかと。


36 :名無しさん@お腹いっぱい:02/09/29 15:10
sage

37 ::02/09/29 15:19
もうちょっと書くか。

「ゴミ箱」アイコンが形を変えたのと同じく、
「デスクトップ」が、現実の「机」と同じである必要性は全くない。
状況によって形を変えて、時にはディスクの中になったり、
時には作業スペースになったり、時にはメニューや通知に成り下がる。

MacユーザにとってOS9が「直感的」だったのは、
実は「メタファ」では無くて、
あれとそれとを同じように扱える「多態性」だったのでは無かろうか?

OSXになって、「あれはあれ、それはそれ」と厳密に区別されたせいで、
「多態性」を諦めさせられて不便になったような気がするんだが。

38 ::02/09/29 15:23
「ゴミ箱」はOSXで良くなったけど、
「機能拡張」はわかりにくくなったと思う。

「システムフォルダも所詮フォルダだからコピーが自由」ってのも無くなったし、
「コントロールパネルも所詮フォルダ(以下略)」も、
設定がHomeとetcとNetInfoに分かれたのも、
「多態性によって得られる操作の統一感」を損なったが故に不便だな、と。


39 :●~*:02/09/29 15:23
>>37
その通りだよ。
マカは、これは、ここはこうしなきゃだめよ!
と言われると嫌がるからなあ。
ウイナは、そうかい。じゃそうするよ。と素直だからね。


40 :32:02/09/29 15:27
優しいスレですね。

デスクトップのメリットというのはなんなのか、ということを考えてみたいです。
デスクトップがなく、プレステやファミコンのようにカートリッジ形式にして、ソフトを本体に突っ込んだら即起動、みたいなものだったらいちいちデスクトップを経由する必要なんてないのではと思う。
こうすればコピーもある程度防止できるしソフトがOSに悪さしてコンフリクトが起きるようなこともなくなるのでは・・・。それにディレクトリとか階層とかいちいち考える必要ないし、そもそもOSというものを感じなくて済むようになるのでは?

まあでも複数のアプリを同時に起動できないという罠(カートリッジ増やせばいい?)。しかもソフト間の連携とれないし。普通に考えたらダメだけど、用途が限られていたら一つの方向性としては可能だと思われ。

こんな感じで幅広い発想と議論が出来たらおもしろいと思う。

なんか一人で違う方向に突っ走ってる気が・・・

41 :●~*:02/09/29 15:28
梨が長文を書く時は、会社で嫌な事があったという法則。

42 ::02/09/29 15:37
>>40
ピピンってそういう感じだったような。

>>41
嫌なことがあったとき、折れはパソコンの設定を変えるな。
あと、掃除とか。

43 ::02/09/29 16:00
>>41
別に嫌なことは無いがw
最近、日常生活にポリモーフィズムを導入したくて、
それをとっかかりにしてUIの話がしたかった、というのはあるけどね。

>>39
ウィナに言わせれば「ゴミとCDはゴミ箱へ」というように
行動を「統一」される事が嫌なのさ。
マカは逆に、行動を「具体化」させられるのが嫌なんだろうな。

Winは「具体的な行動を詳細に」行わされて、
Macは「抽象的な行動を統一して」行わされる。

別のスレで「Macはオブジェクト的だ」と言ってた人がいたけど、
オブジェクト的なのはWinも一緒で、MacとWinが違うのは、
「抽象的かどうか」すなわち「OOP的かどうか」なんだと思ったよ。


44 ::02/09/29 16:05
>>40
ハードディスクが出来るまでは、そうだったんだよね。
そのような形態にしなかったのは、単にコスト的な問題にも見えるから、
セキュアなSDカードみたいな物にアプリを入れて売るってのは楽しいと思う。

少なくとも今みたいな、OSとアプリが糞味噌になってる状態は打破できるね。
その打破を世の中で一番好まないのはMSなんだと思うけど。w

ちなみに>>26で紹介されてるCDが、
「ソフト本体に突っ込んだら即起動して使えるLinux」です。

ハードウェアの互換性を確保するためと、基本的な操作性を提供するために、
OSはハードディスクに存在しててもいいと思うんで、
それを踏まえてカートリッジ式になってるなら、良いと思う。目から鱗。


45 :32:02/09/29 19:19
>>44
そうそう、OSはHDDに入ってる状態です。これだともうホント最小限の構成で済むから構造も単純かできると思う。

で、冷静にこのことについて考えいたのだが、
>>40で述べたことを実現できるのは、MSかSONY+IBMだと思われ。

MSはまあおいといて、ここで問題なのはSONY+IBM。
今のプレステ2ですでにLinuxが動くことは実践済み。じゃあ、ということでプレステ3になったときにどうなるかを考えると・・・・。もう40で言ったようなことまんま実現可能なわけよね。

しかもCELLとかいって並列分散処理を目指すようなCPU積むってんだから、これもうやんなっちゃうね。
SONYの家庭用サーバにファイルは保存。ソフトはカートリッジ式で。OSはプレステの中に搭載。重い処理も分散処理で!。動画像編集はHDD+DVDレコーダーでどうぞ。みたいな感じで・・・。一家に何台もプレステが・・・。

ってかもうすでに実現してある技術ばっかじゃん!!あとは実行のみ。MSの次はVAIOですか。気づいたら
PC板ん中にVAIOとかできてそう。VAIOマンセーがイパーイいそうだ。

鬱だ。

46 :32:02/09/29 19:25
と、まあ妄想はそれくらいにして、本当にカートリッジ式みたいな方法は理想的なUIと言えるのか考えてみたい。
確かにOSを意識させないことはいいことだと思われるが、その分柔軟性に欠けるという欠点もあるわけで。
そこんとこをもうちょっと考えてみたいですな。

あと、使う人によっても変わってくることを考慮しなければいかんですな。
たとえ今パソコン使ってない人にとって使いやすくとも、今ウィソやマク使ってる人にとっても使いやすいものにならなければ意味がないからね。

47 ::02/09/30 11:31
スレタイトル、UIじゃなくて「ヒューマンインタフェース」にすれば良かったね。

>>45-46
Appleがやっても良いんじゃないかと思うし、
今のハードディスク主体のPCから移行する必然性が無いとどうしようもない気もする。

まーでも、OSをファームウェアみたいな物だと捉えれば、
利用者にとってはファミコン感覚(ビデオデッキ感覚でもいい)なんだし、
ユーザビリティとコピー防止の両方の利点から、
ソフトハウスやサポートをするPC販売メーカに訴求する事は可能かと。

でも、並列分散処理の解釈は微妙に違う気がするよw

48 ::02/09/30 11:43
ソフトウェア的な視点から、>>40のアイデアを設計してみる。
「唯物主義的ヒューマンインタフェース」とでもしておくか。

まず、記録媒体は現在世に普及していて、
媒体自体の完全コピーが困難らしい(?)DVD-ROMを標準とする。

ユーザはアプリケーションDVD-ROMを差し替える事で、
インストールせずに、DVD-ROMから直接アプリを実行できる。

データは、メモリーカード(FDのような物、統一規格が望ましい)
に記録される。

OSは本体ハードディスクにインストールされ、
システムの管理、デバイスの管理、UIの提供に専念する。

これらが大原則。

で、上級ユーザもしくはアプリ併用のために、
DVD-ROMの内容をまるごとHDDにコピーする事が出来る。
(従来のインストール作業に相当。印象としては仮想CDみたいな感じ)

さらに、メモリーカードのかわりに、擬似的にHDDを利用できる。
基本的には、メモリーカードと同容量の仮想領域を作成して、
カード1枚に丸ごと復元/待避が可能となる。


49 ::02/09/30 11:50
>>48
この案の利点は、現状のハードウェアで容易に実現が可能だという事だ。
もちろん、DVD-ROMドライブを2機にして、片方をシステム専用にするとか、
ROMを搭載して更新不可能なシステムを提供する展望もありそう。

この案の一番の欠点は、ソフトウェアのアップデートが出来なくなる事。
これは、DVD-ROM以外の書き込み可能なハードウェア(DVDでもいいが)
を扱う事で緩和出来るかも知れない。

この案の問題点は、
技術者にとって、それでも多少なりの不便さを抱かせてしまうこと、かも。


50 :●~*:02/09/30 11:56
>>48
PS2みたいだね。

51 ::02/09/30 12:24
やっぱり、DVD-RAM(書き込めれば何でもいいけど)の方がいいなあ。

>>50
そうよ。PS2に限らず、どのゲーム機も似たり寄ったりだよね。
それをゲーム機じゃなくてパソコンでやってしまおうってだけ。
ゲーム機のヒューマンインタフェースは洗練されてると思うよ。

52 :●~*:02/09/30 12:32
>>51
でも梨ならそういうのは買わないような気がする。
昔、家電型を否定してたような記憶があるんだけど、
まあでも、デベロッパーの立場からだと不正コピーがされにくくていいのかな。

53 ::02/09/30 12:49
>>52
売りたい物と買いたい物は別なんですよ、
とか言ったら、デベロッパーとしての腕を疑われるかな。
(↑うさんくさすぎて疑う以前の問題な訳だが)

まーでも、律儀にテスト用にWinXPインストール済みPCを用意するくらい、
一般の方々に迎合する覚悟は出来てまっせ。
Windowsで商売するなら常識的、という気もする。あーあ。

54 :●~*:02/09/30 13:15
>>53
2kで動いてXPで動かないものもそろそろ出てきたのかな。(既にあるのかな)

それよりMacは買わないの?
旧板住人として、律儀にテスト用Macを用意とか。
まあ、今Macの新機種買うのは奨めないけどね。

55 ::02/09/30 13:19
>>54
ゲームキューブ買って、金無くなっちゃった。てへ。

別に止められたから買わない訳じゃないんだが、
母艦壊れてテンパってた時に、
「余裕無い時にMacは買わないほうがいいよー」
と助言を受けてしまったので、
L5戻ってきて経済状況が安定してから検討しようかと。

56 :●~*:02/09/30 13:39
>>55
バイオいいよバイオ

ゲェムノネ

57 :●~*:02/09/30 13:44
>>55
一応、PPCなのね。w

正直、梨がMac買うのが先かアポーが逝くのが先か・・・予測がむずい。

UIの話にもどるけど、最近のHDDカーナビは良いところをついてると思うんだけど、どう?
基本はゲーム機と大差ないかもしれないけど、運転しながら使えるだけあって、なかなか良く考えられていると思うんだけどね。



58 :●~*:02/09/30 15:29
>>57
アポゥが逝く前に、梨が逝くに50Xbox

59 :●~*:02/09/30 19:55
理想的な物を考えてなぜ現状よりめんどくさい方向に行くんだろう。

60 :マ狂:02/09/30 22:44
そうだ
デスクトップに例えずに部屋に例えてUIの名前を考えよう

デスクトップパターン>カーペット
ゴミ箱>ゴミ箱
メニューバー>コントロールメニュー
フォルダ>フォルダ

他には?

61 :32:02/09/30 22:46
>>57
最近のカーナビについてだけど、確かに良いところついてると思う。
いろいろ機能が増えちゃって今のパソコンみたいになっちゃったら元の木阿弥だけど、今の機能に留めるならもっと使いやすくなる可能性が考えられるし現状でも実用に耐えうる。スピードも現実的なレベルにやっとなったしね。

で、カーナビには音声認識機能がどれも付いてるけど、音声認識が必要とされるものって現在ではこれだけじゃないの?それ以外のモノで音声認識が実用的だったり必要なモノってないような気がする。(障害者用は除く)

それと、トヨタのG-BOOKとかホンダのインターナビ・プレミアムクラブとか各社車のIT化に躍起になってるけど、これってかなりバランスが難しいものだと思う。
あくまで必要最低限のものだけにしないと、大変なことになると思う。もっといろんな機能つけてって、なんか情報受信するたんびに押しつけがましく表示されたら運転に集中できなく恐れあり。

この辺はでも自動運転とかとからんでくるから難しいところだね。

このスレはマターリしててイイですね。

62 ::02/10/01 01:23
OQOはいつでるんじゃ〜
http://pc3.2ch.net/test/read.cgi/mobile/1033142840/
すっかり忘れていたが、まだでていないらしい。
タブレットPCよか、こっちのほうが良い感じだよね。

63 :●~*:02/10/01 02:52
ここは梨の隔離スレに認定されました。

64 ::02/10/01 11:07
>>56
ちらっと見てみたけど、凄そうね。
でも、次に買うのはゼルダかな、と。
漏れは1本買ったらクリアするまで次のゲームは遊ばない主義なんで、
とりあえずPSOやってきますよ。

>>57
PPC搭載と考えると、C/Pは最高に近いよねw
漏れはアポーは当分逝かない気がしてきた。

カーナビの解説求む。

>>60
マイコンピュータ
マイネットワーク
マイドキュメント
マイミュージック
マイピクチャー

あらあら、違和感が無いようなw

>>62
買っちゃいそうだが、使い道は思いつかないなw


65 ::02/10/01 11:15
http://cycles-of-life.dip.jp/conconcon/mac/
真ん中あたりの使用状況が、スバラシイ。

66 ::02/10/01 11:15
>>59
過去これまでにある程度技術が発達してきて、
その場の判断とかアドリブで「楽そうな物」を開発したツケってのを、
どこかで整理する事が必要なんだと思う。

「ハードディスクがあれば糞味噌もごっちゃに出来て、
 どさくさに紛れてソフトの更新とかウィルス配布したり、
 ファイルのメンテをしたりパーティションの管理も出来ます」

というのを、

「ハードディスク内には抽象的なシステム領域と、
 仮想アプリケーションDVDと、仮想メモリカードしかありません。
 だから、システムとアプリの切り分けもパーティション管理も不要です」
と再定義する事で、アプリの移動やデータの移動を明快に出来るってわけ。

「システムのコピーが簡単に出来る」とか、
「アプリケーションを自由自在に移動できる」というのは、
どこぞのOSユーザさんが最大限に賛辞する機能だと思うんだけどな。

そういった部分が無秩序になる事で、OSXは今のところ不便になったと。


67 ::02/10/01 11:23
>>61
> 今の機能に留めるならもっと使いやすくなる
> あくまで必要最低限のものだけにしないと、大変なことになると思う。

でも、技術の進化とか消費者心理としては、
「新機能を搭載してより活用の幅が広がる」事を、
デフォルトで期待しているし、その流れは止められないんだよね。

進化するにあたって、
「拡張すべき部分だけの拡張に留めて方向性を定めること」と、
「定めた方向性の束縛から解放されるための努力をすること」を、
常に天秤にかけて開発していかなきゃならんのだろうな。

私見だけど、Winは前者、Macは後者の努力が「足りない」ね。

>>65
無茶な使用だけなら負けないかもw

68 :マ狂:02/10/01 20:29
>>64
先生、メタファっすよメタファ
そのまま言ったら意味無いジャンw

69 :山崎渉:03/01/23 02:39
(^^)

70 :●~*:03/03/29 00:24
メニューバーってどうよ?
ウインドウズみたいに個別でも別にいいよな??
今使ってるアプリがどれか分かりやすいし
終了したつもりが別のアプリだったりするし

71 :●~*:03/03/29 00:25
まだあったのか、このスレ

72 ::03/03/29 13:43
結構真面目に語ってるなー昔の漏れ。
UIを語るじゃなくて「ユーザビリティを語る」になってるけど、正解やね。

で、なんとなく、最近の考えでは、
「ユーザがUIをカスタマイズできるべき」
という結論に向かいつつある。

ユーザがカスタマイズしたものは確実だし、
オフィシャルに組み込むことで標準化を追随出来る。


73 :●~*:03/03/29 18:52
ほしゅ

74 :●~*:03/04/13 16:04
OpenDogみたなアプローチかね>UIのカスタマイズ

75 :●~*:03/04/13 16:11
OpenDocとCyberDogを混ぜないように。

76 :74:03/04/13 16:32
逝ってきます

77 :75:03/04/13 17:13
いや、そんな急逝せんでも。カムバーック!

OpenDocはOLEと比較されるけどチョト違う気がする。
InDesignの方が構造は似てる。用途は全然
違うんだけど。

あと、UIのカスタマイズって結構微妙なんだよね。

標準と大幅に違うからこそ「おおっ!」って思って
インスコするんだけど、慣れちゃってインパクトが薄れると
あんまり便利じゃなかったりして結局デフォルトに戻る。
かといって標準仕様と大差ない見た目だと
そもそもインスコする気が起きない。

キーバインドとかのカスタマイズも便利なんだけど
つい忘れて人に説明すると話が噛み合わないことも
あったり。

78 :74:03/04/13 17:45
>>75
ありがとう

UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな
現状ではアドオンで色々入れても所詮ネイティブな環境と同じ事は難しいから小手先で誤魔化してしまう事も有るよね
昔はFinderを置き換えてしまうような物もあったけどいまいちだったし

あと昔からのマカーがよく言うアプリケーションがちがくても同じ操作性を補償するというのは
UIのカスタマイズとは基本的に相反するところが有るよね

現状でもUIを自前で処理してるソフトは多いからね

79 ::03/04/13 18:21
>>78
> んでそう言うところの多様性をOS自体の仕組みとして提供する事は出来るのかな

どうだろうねえ。

漏れはどちらかというと、あるソフトでやったカスタマイズが、
他のソフトや他のPCに対して簡単に反映出来る仕組みを、
OS側で提供できたらいいなーと思う。

もちろん、APIを整備してカスタマイズ可能な状態を作ることも大事だけど、
それは素性の良いソフトがあれば出来る事だし、OSには関係ないからなー。

でも、漏れの発想って、つまるところエンドユーザコンピューティングなのよね。
未成熟な業界に対して過渡期的に働くだけで、
「理想的な」UIとしては、カスタマイズの必要が無いくらい完璧であるべきなんだろうな。


80 :75:03/04/13 19:19
>>78
おかえりー。

>UIのカスタマイズというとせこいレベルだとファイラやランチャなんかも範囲に入るよね
痒いところに手が届く的な定番ユーティリティは、どのOSでも
あるとは思うんだけど、それを全部標準化して組み込めるような
枠組みって言うと結構ムズカシイものがあるかもしれない。
(Linuxとかのフリーの奴だと、あんまり標準って線引きがないけどね)

最近のMacOS XではKonfabulator辺りが注目株ではあるね。
梨だったらWigetくらい、ちょいちょいと作れそうw

自由に設定できてしまうと、メーカーのサポート要員が泣きそうな
気もするし、そこら辺から考えないといかんと思う。

81 ::03/04/13 21:22
>漏れはどちらかというと、あるソフトでやったカスタマイズが、
>他のソフトや他のPCに対して簡単に反映出来る仕組みを、
>OS側で提供できたらいいなーと思う。

あー、それ欲しい。
そういうのってMacよかWinのが得意そうね。

パソコン使ったことない人向けの理想的なUIってのは完成可能かもしれない。
でも、ある程度使いなれた人ってのは慣れとかこれまでの習慣なんかがあるんで、
御仕着せのUIはイヤなんだろうなぁ。

銀行振込みさえ、Ctrl+h のキーバインドで削除したくなる、折れは。

82 :たまき:03/04/13 21:23
konfabulatorってシェアウェアなんだよねぇ。
値段が高いか安いかは人それぞれだけど
おいらは登録すること自体が面倒くせーな人間だから・・・
開発者の皆さんごめんちゃい。

2003.04号のマーパにカラーで紹介されてるね。
Quartz対応でとっても綺麗。
この手のデスクトップアクセサリーって結局邪魔になって
消しちゃうことが多いけどカレンダーは便利そう。

83 :75:03/04/13 23:08
>「理想的な」UIとしては、カスタマイズの必要が無いくらい完璧であるべきなんだろうな。
Appleが狙っているのは、ソコって気はするけれど、それって
結局は大勢のニーズに対しての折衷案って感じになりがちでは
あるよね。「究極のUI」っちゅーのを天才が発明すれば話は別だけど。

MSは「設定でお好みに使って」みたいな感じで放任主義では
あるけれど、自由度を増せば設定が複雑になってとっつきにくい。
それにあそこの会社は設定パネルを1箇所に上手に纏めるのが
今ひとつ上手くない。

ネットを仲介してUIを共有できるようにするのは面白いと思う。
リモートデスクトップの延長線上でできそうな感じはするし。
サポート要員の人も泣かなくて済むかもしれないw

konfabulatorは今のところアクセサリっぽいイメージなんだけど
リアルタイムでオンエア中のTV番組表や道路渋滞を表示する
Widgetとかあるので、本来MSがActiveDesktopでやろうとして
いた事に近いのかもしれないと思ってる。

84 :74:03/04/14 19:36
>漏れはどちらかというと、あるソフトでやったカスタマイズが、
> 他のソフトや他のPCに対して簡単に反映出来る仕組みを、
> OS側で提供できたらいいなーと思う。

これって出来ない事では無いだろうけど
でも根本的に異なる操作大系を実現するのは難しいよね
結局有る程度インターファイスのガイドラインみたいな物を作って
その中で若干の幅を持たせるくらいが関の山だと思う

85 :75:03/04/14 23:38
>>84
XPのエクスプローラとか、表示の仕方はXMLっぽい記述で
設定されていると思ったんだけど。
その延長でウィンドウのデザイン自体やコントロールパネルの
レイアウトとかも記述できるような仕組みになれば大分、近くは
なるんじゃないかと。

MacOS XのQuartzも確かPDFかなんかで記述する筈なので
おおよそ全部のパーツは、どっかにテンプレート化してあると
思うんだよね。(システムの権限で無理っぽいけど)そこらが
弄れるツールがあれば、できそうな気もする。

86 :●~*:03/04/16 02:25
技術的なことは疎いのですが
例えばですね使いやすいかどうかは別にしてマウスのジェスチャーですべての操作をしたい人がいたとして
そう言う操作を可能にすることはアドオンのソフトでも可能だと思います
でもそう言う操作で使うのに最適な見た目であるとかそういった事を実現するのはちょっと難しいでしょ?
ボタンが不要だからといって画面から消して表示領域を増やすことができますか?
結局ユーザカスタマビリティの保証は中途半端なレベルで我慢するしかないのではないかな

87 :VAIOユーザZ:03/04/16 03:12
いい加減にして頂けますか!
僕は遊びも仕事も真剣勝負なITエリートです。

88 :山崎渉:03/04/17 11:28
(^^)

89 :75:03/04/17 12:37
>>86
現状で与えられている環境では、そういうことになる。

どうしてもカスタマイズ鬼になりたいのであれば
システムをハックするか、Unix系のウィンドウマネージャーを
自作するしかなんだが。

90 ::03/04/17 13:28
UIって外観だけでなくて、ショートカットとかもありだよね。
emacs とか使っていると、全部emacs風味な操作をしたくなる。
そういうのって、MacやWinのアプリでもあると思うのよ。
ショートカットだけでも統一出来れば嬉しいなぁ。


91 :●~*:03/04/17 20:17
おれはあるインターフェースがそれ単体としてつかいやすいかどうかよりも
システム標準として採用した時にどれだけ多くの種類の作業に普遍的に適用出来るかッて事に興味が有るな
そのいみでアップルのヒューマンインターフェースガイドラインは当時としてはかなり良い出来だったと思う

あとアレを敢えて逸脱するソフト(例ハイパーカード)にはそれなりのインターフェースに対する提案があったんだよね
そう言う点でも優れた標準が有ると言う事には意味が有ると思う

92 :74:03/04/18 00:27
>>90
ショートカットの統一は技術的にはわりと簡単に実現できそうだよね
ただアプリ作る人に何かしらのガイドラインを守らせないとアドオンソフトで一発設定とはならなそうだけど

93 :山崎渉:03/04/20 05:47
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

94 :●~*:03/04/20 23:03
上げとくぜ

95 :●~*:03/04/24 23:29
ひとそれぞれなんて言うやつは自分でOS作れよ

96 :●~*:03/04/24 23:34
おい。梨マックだぜ。
http://www.ut-info.com/macin/immac/

97 :●~*:03/04/28 17:45
>92
q,w,s,z,x,c,v,p,a,o,n,f,g,.
ぐらいなら、強制しようと思えば出来ると思う。

で、それらを強制したとして、ほかのコンビネーションはどうするか、ってことになると思うよ。

普通のアプリケーションは上のキー+r,u,i,h
あたりをはずして独自の機能をどのコンビネーションに割り当てるかを勝手に決めてる。
それがほかアプリではまったく違う機能であることは当然のように起こる。

で、そのまったく違う無数にあるであろう機能をひとつの枠に収めるのは至難の業だと思うよ。


98 :●~*:03/04/28 21:02
>>97
全ては無理かもしれないが、共通化できるものだけでも
やってもらえるとありがたいでつ。
キーコンビネーションではShift+Command+Sなんかは
共通化されててもいいと思いますのよ。

それとショートカットキーを語るならキーボードのキー配置にも言及したいです。
Ctrlキーが左下の隅っこにあって、更に小さかったりするとキーコンビが押しづらく
ショートカットキーの恩恵をあまり受けられないので、ハードメーカーも協力して
使い勝手を向上してもらいたいなぁ。
UIについてはモニター上だけでなく入力装置も含めて総合的に語りたいものです・・・
話がまとまらなくなるかもw

99 :●~*:03/04/30 11:20
>98
>97では言いたいことが文章になってませんでした、すみません。

言いたかったことは、
たとえば、あるアプリケーションの独自機能(い)に Cmd+D が、
別のアプリケーションの独自機能(ろ)にも Cmd+D が割り当てられているときに、

1,新規作成を Cmd+D に変えた場合、(い)(ろ)は同時に Cmd+N に振り返られるのか?
2,(い)を Cmd+K に変えた場合、同時に(ろ)も Cmd+K に変わるのか?
3,(い)を Cmd+K (ろ)を Cmd+L に変えることは可能なのか?

ということです。

意味的な変更を考えるなら、3,が可能である方が好ましいと思われるが、
そうした場合、「アプリケーション単位での切り替え」機能を備えざるを得なくなります。
この機能を備えてしまうと、UIの破綻を招く恐れがありますし、
変更方法の複雑化につながります。

多ボタンマウスのドライバにも同様の機能がよくありますが、
アプリケーション単位での切り替えはわかり辛いと思います。
#使ってりゃ慣れるだろといわれればそれまでですが。

ようは、ショートカット<->機能が一対多である以上、
一部を統一化してもその他の部分にしわ寄せがきてしまうということです。

んで、>97最終行につづく。

100 :VAIOユーザN505=74:03/05/01 01:50
>>97,98,99
なるほど良く分かりました
95での書き込みはあんまり良く考え手なかったってことです
ただし例えば自由に割り当てられる領域を制限すれば部分的な解決にはなるでしょう
例えばキーボードの左右で左を共通機能右を独自機能にするなど
使って無いキーでもいくつかリザーブしておくとか
あと2の方向性での解決としてショートカットを使う時はキーマップを仮想的に変化させると言う物が考えられるかと
またもう一つの考え方としてはアプリ独自のショートカットとシステム共通の物とで機能キーをわけると言うのも手です
例えばコマンドキーはシステム共通で使いオプションキーはアプリの独自機能に使うなど
これならばショートカット変更の衝突がさけられるので良いのでは無いでしょうか
アプリ独自部分にかんしてはアプリそれぞれによって変化させるつまり3の方向での解決もできるのでは?
またこの方法ならばあるアプリが独自に搭載してきたショートカットを後からシステム標準として採用する際にも
混乱を最小限に押さえる効果があると思われます
考えながらうったので後の方の案程より良い案だと考えています

101 :VAIOユーザN505:03/05/01 02:42
をー
きり番ゲットしてたー
何かきり番とる時ってこんなんばっかしっすよ
たまにはマトモに100ゲットとかしてみたい

102 :75:03/05/01 10:12
>>100
アプリのUIは、AdobeがMacromediaをパクリで告訴したり
Macromediaが逆提訴したりしているので、メニューの配置や
ショートカットを、あえて違うようにデザインしている節もあるな。

全てのアプリで共有できる機能(アプリ終了とか)のキーバインドや
メニューの位置は統一されていた方が便利だと思う。

問題は、グラフィック系固有の機能の標準的なショートカットが
ワープロ系では違う機能のショートカットで普及してたりすると
ちょっと、厄介かも。

103 ::03/05/01 10:15
>>100
それじゃあまるでWindowsの域を脱していないw
Ctrlがアプリ用、Altがウィンドウシステム用と、なんとなく分かれている。

「すべて強制する」という方向に持っていくのが事実上無理なら、
「すべて自由化可能である」という遊びを持たせた方がいいのでは。

「不便だけど一般的だから仕方ない」と言ううちは、
まだまだトレードオフが発生していて「理想的」とは言えない気がするな。

ショートカットキーがうまく統一出来ないのは、
所詮それがパソコンであり、キーボード操作であるが故だと思うよ。


104 ::03/05/01 10:21
それよりも、誰か「ファイルを保存」ダイアログを撤廃させないかな。
あれは無駄の極みだと思うんだけどなー。

ダウンロードのデフォルトをデスクトップに固定したMacIEは偉いと思う。

ファイルシステムとの親和性をあげるために、
すべてのファイルの一時保存先をデスクトップにしてはどうだろうか。
そうするとあのダイアログは出さなくて済むし、
ファイルシステムの操作によって片づけがおこなえると思うんだけど。

まあ「デスクトップが散らかっても気にしない(゚ε゚)」人が
少なくない現状を考えると、それを綺麗にする方法も必要かも知れないね。

さもなくば、アプリごとに固定のフォルダに保存する設定が出来るといいけど、
それでも「デスクトップからどう行けばそこにたどり着くか」を、
ユーザに理解させる事が難しいって点で、あまり良くはないと思うなあ。


105 :75:03/05/01 10:38
>>104
対象はデスクトップでもマイドキュメントでも構わないんだけど
OS側で、一定のルールに従って自動的にデータを振り分ける
ようになっていると便利かな、とは思った。

メールソフトの「ルール」設定みたいな感じ。

106 ::03/05/01 10:45
>>105
ソフトごとに分けるのが正しい分け方だという前提があるなら、
すべてのソフトがDocumentsフォルダを必ず使えばいいのかな。

「ルール」でどの程度制御できるもんだろ?


107 :75:03/05/01 11:09
>>106
メールだと、差出人、受取人、件名、本分中のキーワード等で
コピー、移動や削除のルール設定がユーザー側で、できるように
なってるけどその辺を、ファイルの保存に適したモノで
考えてみれば良いんだよね。

>ソフトごとに分けるのが正しい分け方だという前提があるなら、
拡張子で選別するか、アプリごとに選別するかは、ルールの
設定次第にもできると思う。

システムで認識しているアプリ、拡張子、ファイルネームの一部、日時
(Macならクリエータやファイルタイプもあるね)とかで、ルールを決めて
おいてアプリ側で「保存」ってやった場合は、自動的にルールで処理。

アプリをインスコする時にデベロッパーの作ったルールを自動的に
読み込むか、任意で選択できるようになっている。

……と、いう感じ?

108 :●~*:03/05/01 18:56
       /::::::::::::::::::::::::::::::::::::::::::::::::::\
         /::::::::::::::::::::::::^::::::::::::\
      /::::::::::/|::::::::/ノ::::::::/ヽ:人::::::::::ヽ
     /::::::::::/ |::://∧::::ノ  ソ ヾ::::::::::::丶
     |:::::::::::/  |/ |ノ |/  ノ  |:::/ヾ::::::::|
    |::::::::::/ :::::::::::::      ::::::::::V::  |:::::::|
    |:::::::/ ̄ ̄ ̄ ̄ヽ===/ ̄ ̄ ̄ ̄ヽ |::::|
    | =ロ  -=・=-  |,  |  -=・=-  ロ= |
    |:/丶      /ノ  ヽ      / ヽ|ヽ
    /|/  `─── /   ` ───    | |
   (||        (●_●)        |ノ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     |          l l          | < (!゚∞゚!)それが出来たら苦労はしない
    |      __-- ̄`´ ̄--__      |  \________
    |        -二二二二-       |
    \                    /
      ヽ      _- ̄ ̄ ̄-_     /
       丶               /
       /| \_______/ | ̄\
   / ̄\ 丶           /




109 ::03/05/01 19:14
>>107
その程度なら可能だろうね。使い道は微妙だけど。
今MSが作ろうとしてるデータベースベースの
ファイルシステムみたいな感じになるのだろうか。

今どういう設定になってるかをアプリごとに一覧したり設定したり。
微妙に手間かなーとも思えなくもない。

最初から「ドキュメントフォルダにアプリ名でフォルダを作る」
みたいな統一ルールを用意した方が話が早いのかなー。

まったくもってそれらを無視するか、すべて受け入れるかの二択。
これなら設定もチェックボックス1つで済みそうな。

キーバインドもそうだけど、設定を柔軟にするってことは、
設定の持ち運びが生じるだけ手間なんだよねぇ。

なんかデフォルト主義みたくなってきた。


110 :bloom:03/05/01 19:17
http://homepage.mac.com/ayaya16/

111 :●~*:03/05/01 19:18
名前:●~* :03/05/01 18:17
    / ■\  / ̄ ̄ ̄
/|\( `∀´) <やっぱモロでしゅ
⌒⌒ (    ) \___
  ←-┤ | |
    (__)_)



112 :●~*:03/05/01 19:19
       /::::::::::::::::::::::::::::::::::::::::::::::::::\
         /::::::::::::::::::::::::^::::::::::::\
      /::::::::::/|::::::::/ノ::::::::/ヽ:人::::::::::ヽ
     /::::::::::/ |::://∧::::ノ  ソ ヾ::::::::::::丶
     |:::::::::::/  |/ |ノ |/  ノ  |:::/ヾ::::::::|
    |::::::::::/ :::::::::::::      ::::::::::V::  |:::::::|
    |:::::::/ ̄ ̄ ̄ ̄ヽ===/ ̄ ̄ ̄ ̄ヽ |::::|
    | =ロ  -=・=-  |,  |  -=・=-  ロ= |
    |:/丶      /ノ  ヽ      / ヽ|ヽ
    /|/  `─── /   ` ───    | |
   (||        (●_●)        |ノ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     |          l l          | < (!゚∞゚!)  空気読め
    |      __-- ̄`´ ̄--__      |  \________
    |        -二二二二-       |
    \                    /
      ヽ      _- ̄ ̄ ̄-_     /
       丶               /
       /| \_______/ | ̄\
   / ̄\ 丶           /



113 :75:03/05/01 19:47
>>109
初期のBeOSも、なんかそんなファイルシステムを
うたい文句にしていた記憶があったり。

実際メールソフトで、ルール設定を使ってない人も
いるだろうから、利便性という点では微妙。

Webブラウザとかで、頻繁にバージョンアップするフリーソフトを
ダウンする時とか、自動振り分けがあると便利そう。
ファイルネームの頭何文字かで自動的に保存先を判別して
フォルダに格納されるようにしとくとか。

>キーバインドもそうだけど、設定を柔軟にするってことは、
>設定の持ち運びが生じるだけ手間なんだよねぇ。
上の方で、話題になっているけれど、ランデブーのような技術で
環境設定ファイルがネット上で参照できるようになっていると
いいかも。

114 ::03/05/01 20:18
>>113
ネットワーク上のコンピュータが前提になってくると、
仕事の幅も広がっていい感じやねw
盗難が怖いけど。

で、そうそう、自動バージョンアップは今後標準化したらいいのにね。

ソフトウェア・アップデートにサードパーティ製のソフトを
登録するわけにはいかないんだろうか?
できたらすごい便利だと思うんだけど。


115 :●~*:03/05/01 20:32
なんでおれの乳毛が臭いって解ったんですか?

116 :あぼーん:あぼーん
あぼーん

117 :75:03/05/01 20:55
>>114
セキュリティに関しては専門家になんとかしてもらうとして(w

ファイル保存のルール設定と登録アプリのキーバインドを自由に
出来る機能が(ランデブー対応で)OS側でサポートされると
俺は便利そうだな、と思う。ランデブー自体の存在意義も明確になるし。

ソフトウェア・アップデートもWinだったら「プログラムの追加と削除」に
「アップデート」も組み込めばいいと思うよ。
Macの「ソフトウェア・アップデート」は仕様公開してるのかな?
非公開なのか、公開してるけど例のごとくデベロッパーに支持されて
いないとか。「インストーラ」と統合化すると便利かもね。

118 ::03/05/01 21:05
>>117
自動更新されないとつまんないので、
Windowsなら「自動更新」(露骨なネーミングだなあ)に対応かな。

ソフトウェア・アップデートも、Apple製品と糞味噌にするんでなくて、
区別した上でデベロッパーに開放すれば、
開発する側としても嬉しいんだけどな。
みんなに最新版を使って貰いやすくなるわけだし。

とか思いながら、今日はソフトウェア・アップデートみたいなものを
書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。


119 :75:03/05/01 21:30
>>118
確かにバージョンチェックや更新情報を集めたサイトとか
重宝がられているし、自動更新チェックはあった方が
良いだろうね。

ま、更新アラートが頻繁に出るとウザイかもしれんけど(w

ttp://www.apple.co.jp/server/macosx/pdfs/NetInstall_TB_J.pdf
こーゆーのも、あるみたいなんだけど普及はしてなさそ。
AppleもAkamaiかなんかで、これを稼動させて.mac会員か
有料ADC会員に開放するとかしてみれば良いのにね。
MacOS X Serverの運用実績にもなるんだし。

120 :●~*:03/05/01 21:36
ちょっち話題に乗り遅れました。

ファイルの保存と開くに関しては以前マーパに、
ファイルに細かいデータを付与することでCmd+Oの代わりに
Cmd+Fを使えないかって感じの記事があったような・・・

以下私見。単独使用に限定ですが・・・
ファイルの保存場所はDocumentフォルダに固定する。
Cmd+Oのダイアログ画面をOSXのリスト表示みたいにして
ソートや検索ができるようにする。
当然リストの項目は全てのアプリで共通化する。
という感じでどうでしょう。

マーパの記事ではデータベース化したファイルを瞬時に検索できるようになれば
ファイルをどこに保存するかは問題でなくなる、って書いてあった・・と思う。

素人考えなので真剣に突っ込まないで下さいw

121 :75:03/05/01 21:50
>>118
>とか思いながら、今日はソフトウェア・アップデートみたいなものを
>書いてたなりよ。汎用的にして広く普及すればおいしいと思うけどなあ。

車輪の再発明は信条に反するのでは?(wというのを
ツッコミ忘れた(冗談です)

そういう機能をカバーしたインストーラ開発キットみたいなのが
あればいんでしょうねえ。

>>120
そういう方向のアプローチは各社やってるみたいだよね。
どのOSでも、ファイルダイアログはとかく評判が悪いしね。
ダイアログを差し替えるフリーソフトもあるし。

存在意義の薄くなったSherlockをちょっと改造して
ダイアログに流用するとできそうな感じがする。

122 ::03/05/01 22:19
なんてことだ。帯域資源が乏しいとPDFのひとつもよめしないのか。

>>119
それこそ「自動更新」みたいに「勝手にやっといておくれ」モードがあればいい。
それだけでメディアになりそうな気がするけどな。
誰か真剣に幾千のソフトのバージョンアップをサービスしたい人いたら、
相談に乗るよ。つーかベクターにでも営業いってくるか。

>>120
個人的には固定ってアプローチがいいんでないかと思うぞ。
「初心者モード」みたいなさ。Macにはうってつけだと思うけどなあ。

>>121
多対多の接続をサポートする汎用アップデータって、
漏れの見聞の範囲内では見たことが無いなあ。あったら教えておくれ。

インストーラ開発キットって、地味に儲かりそうよね。
InstallShieldくらいのポテンシャルがあって10万以下なら、
十分競争になるのでは。

Macの場合は、そのへんはAppleが頑張るしか無いだろうけどね。


123 ::03/05/01 22:22
読めた。

>>119
ざんねーん。
インターネット経由じゃなかったら、NetInstallみたいなのは、
いままでにも山ほど出てきたんだけどねえ。

インターネット化の最大の弊害はセキュリティやね。


124 :●~*:03/05/01 22:31
InstallShieldって商品名だったんだ。
初めて知った・・・
てことはInstaller Vise(だっけ?)とかいうのも。。。

125 :75:03/05/01 22:53
>>122
>誰か真剣に幾千のソフトのバージョンアップをサービスしたい
それこそ、管理画面のUIが課題かなあ。間違っても
「プログラムの追加と削除」みたいに全部一覧で表示されても
探すのが大変そうだし、階層化表示も一長一短。

>>123
そーですねー。クライアント側の自動更新チェックはないし。
>>119は「AppleもAkamaiかなんかで〜運用実績にもなるんだし。」と
言うサービスの仕方はできんもんかな?と言う話なので。
これとかCVSとかRPMとか、あともう一歩だと思うんだけねえ。

やっぱり、セキュリティがネックなのかな。なりすましとか。

>>124
その通り。
Apple謹製の「インストーラ」とViseは思い切り競合してる。
どうなるんだろう?

126 ::03/05/01 23:03
>>125
Appleのインターネット技術はどいつもこいつも「あと一歩」さw

「プログラムの追加と削除」と同水準にならざるを得ないかと。

要は、原則的にいちいち取捨選択しなくてもいいように、
セキュリテイフィックスと機能追加で分けるとか、
Windows Updateみたいな形にしてしまえばいいのかと。


127 :75:03/05/01 23:20
>>126
梨にいつもの調子が戻ってきて、何より(w

余力が有り過ぎる割には本質を見落としがちで「あと一歩」の
部分を何十種類も用意するMSもカワイイけど、余力がなくて
いつも転んでるAppleも結構好き。

>「プログラムの追加と削除」と同水準にならざるを得ないかと。
うん、まあ、常識的な線では、そうだろうね。
メーカー謹製のソフト+インストールされている他社製ソフトの
更新情報だとしても、毎回凄い数のアップデートがある訳でも
ないだろうし。

半歩手前のアプローチとして、Yahoo! Alertみたいなサービスを
ベクターに営業してくるといいかもよ?(w

128 ::03/05/01 23:30
話題があるっていいことやねw

>>127
人的資源の配分って難しいやね。
「もう一歩」と言えば、UNIX系の開発者をうまく取り込んで欲しいな。

ベクターって今どんなサービスやってるんだろ?
もし本当に売りに行くなら、収益モデルを考えないとなあ。


UIの話に無理矢理戻すと、ソフトウェア的な面では、
統合と分散を交互に繰り返して進化していくのがベターなのかねえ。

何万ものフィードバックを受ける時期と、
それを優れた設計者がまとめあげる時期に分かれるようなイメージ。
それを両方いっぺんに高速に出来たらいいんだけどなあ。


129 :●~*:03/05/02 01:20
さて、寝るか。

130 :75:03/05/02 02:25
>>128
取り込み第1弾がXonXとかなんだろうね。OS標準で組み込まれる位の
完成度にもっていってくれると期待感は増すと思う。(これも「あと一歩」で
挫折なんてオチは勘弁して欲しい)

ベクターを覗いてみたら「MyVector」ってサービスで更新のメール通知
らしきサービスは稼動しているみたい。考えることは一緒、ってことで
やはり営業するなら自動更新マネージャか(w

UIの話。統合・分散は「どこまでやるか」って、メーカーにしても
手探り部分はあるから、交互に繰り返すのはしょうがないのかもね。
突然変異的な進化っていうのも、相応の能力と先見性が要求される
だろうし。

フィードバックしてきた意見も多種多様で、その平均的な部分(多数派)が
必ずしも最良という訳じゃないし。見極めが難しいと思う。

131 :あぼーん:あぼーん
あぼーん

132 :●~*:03/05/02 07:33










歌えました

133 :●~*:03/05/02 07:34


魔境でつか





134 :●~*:03/05/02 07:35
結局自分の思い通りに行かないと拗ねる奴ばっかなんだよ
この板は


135 ::03/05/02 09:51
>>130
MyVectorから自動更新に切り替えることで起きる影響は、

・トラフィックが増大する
・マルチプラットフォーム対応が難しい
・ホームページに来るユーザが減る
・開発者は最新版を使って貰えて嬉しい
・話題にはなるし多くのソフトを取り込める

ってな事なんで、実はVectorには最初から向いてない。
これから新規にVectorとはりあうようなビジネスをする場合にしか、
自動更新機能を中心にしたソフトウェア情報提供モデルは使えないのよね。

2ch.tora3.netがやりたかった事って、そういう事でないかと思うんだけど、
あれがビジネスを回避したって事は、モデルの成立が難しいのかもね。

仕事ネタになるんで自動更新の話はここで終わり。


136 :●~*:03/05/02 09:53
アプリに一部持ってもらえば良いんだよ。

一度目の起動時に自分がバージョンアップ機構に対応していることをバージョンアップ機構に教える。
特定のメッセージで自分のバージョンを返す。
もしくはOS Xのように、特定のファイルにバージョンを記しておく。
Windowsなら、レジストリに記すのがいいのかな?

これだけやってくれればあとはバージョンアップ機構で勝手に出来る。

問題は検索機構だけど、一番安易な方法はSunが始めてAppleが真似した
ドメインをひっくり返す"com.apple.Application"見たいな奴を使うのがいいと思う。
検索方法はDNSと一緒。
自分がインデックスを持ってなければ、上に聞きにいく。
問題はドメインがない場合だけど、これも商売にしようと思えば出来るし。

137 ::03/05/02 10:00
>>130
XonXは本末転倒だと思うのは漏れだけでつか。
いや、仕方ないんだけど、
本当はAquaがXアプリを完全に取り込むべきでしょ。

「少しずつでもいいから常に進化して周囲の反応を伺う」という
凡才形式の発展が許されるのは、β版OSだけよね。

「商用製品として理想的」というなら、
「原則かなりの部分が固定。でもカスタマイズ可能」ってな所なのかな。

・カスタマイズを受け入れて設定ファイルやサーバに保持する仕組み。
・カスタマイズできなくて不便な部分はカスタマイズ可能なように発展。
・新規ユーザは望まない限り全カスタマイズはデフォルト状態で提供される。
・キーバインドのデフォルトはできるだけ統一の方向に向かう。
・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
・ファイルの検索条件を増やし、ルールによる振り分けも出来る。

いまのところ、そんなもんかね。


138 ::03/05/02 10:05
>>136
それでも良いんだけど、上述の話だとインストーラで記すんだと思う。

すべてのアプリが独自に機構に書き込むと、手間だし危険なので、
統一したインストーラを提供して、その機能としてアップデートを含める。
まあ、前述の通り、政治的にはWindowsでしか実現できんわな。これは。

検索についてはもっといい案があるけど、一応秘密にしておくw


139 :75:03/05/02 10:38
>>135
ベクターもオープンソース系のボランティアって訳じゃあ
ないし、自動更新システムの運用コストとか、そこに書いて
あるようなメリット・デメリットは当然考えるよな。

今のスタイルが最高とは誰も思ってないので、大勢の
開発者や企画者が頭をひねっているとは思うよ。

>仕事ネタになるんで自動更新の話はここで終わり。
ごちそうさまでした(w

>>136
純粋にアプリ側での対応というのは、それなりに独自の
実装でなされているものもあるよね。起動時にチェックする
やつとか。

ただ、各社好きにやっている状態だと思うので、クライアント側で
統括して一元管理を可能にするには、AppleやMSが開発ツールや
SDKとして正式に対応して十分なサポートをするか、デファクト
スタンダードなインストーラ開発ツールが、そういう機構を持つか
って感じだよね。

140 :75:03/05/02 10:58
>>137
XonXがCarbon並みに全体と馴染むのなら余り問題はない
とも思うけど。Cocoa、Carbon、Java2に新しい実行環境が
増えた、という見方だけど。

>凡才形式の発展が許されるのは、β版OSだけよね。
市場が小さいから(w

>・ファイルシステムはデフォルトで隠蔽され、保存先は固定する。
>・ファイルの検索条件を増やし、ルールによる振り分けも出来る。
保存場所を、むき出しのフォルダ名とファイル名で指定する
のではなく、もっと抽象化したものをユーザーに選んでもらって
見えないところでOSが色々な属性値から判断するという方法論も
ありなのかな?

どこまでカスタマイズできるかって議論は微妙だ。
ヘビーユーザーとキニシナイユーザーでは、ニーズが
異なると思う。ここら辺を、どう切り分けて共棲させるかが
ミソだな。

141 ::03/05/02 11:33
>>139
そ。「自動更新をすると誰が得するか」って問題やね。

で、Windows Installerが標準になれない政治的事情もある。
デファクトスタンダードで統制をとることが前提なら、
Appleのほうがソフトを押しつけるには有利。

というか、Project Builderみたいな物を押しつけて開発環境を独占したんだから、
インストーラも面倒みて欲しいよな。
とはいえ、MacOSXってまだ統一されたソフトウェア管理画面って無いんだっけか。
rpmだって簡単に管理操作出来る昨今、どーにかして欲しいけど。

ドラッグアンドドロップでインストールするならするでいいんで、
とにかくダブルスタンダード状態は早いとこ解決して欲しいなあ。


142 ::03/05/02 11:39
>>140
わかる人とわからない人の落差は一層激しくなると思うよ。

で、市場は必ず「最もわからない人」に向けて動いて良い。
ただし、次点で「最もわかる人」をおざなりにしてはいけない。

実行環境は、これ以上増やしてどうするんですか、という感想。
まあ、そうせざるを得ないだろうけどね。
いっそ統一する気が無いなら、増えるだけ増えた方がいいだろうし。

Appleに開発環境を「整えてやる」事は無理。これも「あと一歩」か。


143 ::03/05/02 11:53
ゴミ箱を使った新しいインストールの仕組みは前に提案したけど、
色々な意見を聞いた上でもうちょっと書いてみる。

・原則、CD-ROMから本体をドラッグしてインストールする。
・CD-ROM内の本体をダブルクリックするとCDで起動。
・CD-ROM内のインストーラをダブルクリックすると所定の位置にコピー。
・初回起動時に必要な処理や初期設定の配置をする。
・初回起動時に自動更新に必要な情報を登録する。
・自動更新はバックグラウンド巡回が原則。
・アンインストールはごみ箱に捨てるだけ。自動更新情報も消える。

これだけでずいぶんすっきりすると思うんだけどなあ。
精細にインストールオプションを選びたい人は、
インストーラをダブルクリックすればいいわけで。


144 :75:03/05/02 12:49
>>142
>で、市場は必ず「最もわからない人」に向けて動いて良い。
>ただし、次点で「最もわかる人」をおざなりにしてはいけない。
それは結構禿しく同意。
元々、PC自体が技術者の研究対象かマニアの道楽って感じ
だったので、どうしても「最もわかる人」の方へ引っ張られる傾向が
あると思うんだよな。開発もマスコミも「最もわかる人」系だからね。

>>実行環境は、これ以上増やしてどうするんですか、という感想。
元々DarwinがUnixの亜種でXFree86とかがDarwinに
対応してたから、そんなに無理やり新しい実行環境として
捻じ込んだ訳でもなさそうに見えるけどね。

XonXでUnix系の開発者が簡単にMacOS Xに移植できるなら
それはそれで便利だと思うし、エンドユーザーに全く区別が
付かないのであれば、メリットも多いと思う。
問題は、環境整備の労力や、OS側に起因する不具合が
発生した時にバグの洗い出しがより困難なったり、そういう
面倒を受け入れるAppleのサポート体制かな。

145 :75:03/05/02 12:53
>>141
MacOS XもDarwinレベルで見ると、パッケージ管理は
標準がDebian形式でFreeBSDのportsやRedHatのrpmにも
対応はしている。Appleの関知しないところで対応が増えても
一長一短だけど。

>>143
Apple推奨の「パッケージフォルダ形式」であれば、確かに
ドラッグ&ドロップだけでインストールと削除は簡単にできる。
アップデータをダブルクリックしてやれば更新もするし。
似たような感じで操作を単純化する試みはなされていると思う。

問題はデベロッパーの支持かな。Unix流に/etcや/usr/local/に
設定やシンボリックリンクをばら撒くヤツもあるし。OS 9風に
Libraryフォルダに専用フォルダを作るやつも多い。

マルチスタンダードだ(w

146 ::03/05/02 15:32
>>144
うん。単に、収拾つかなくなりそうだから嫌だなあって。

Appleの数少ないリソース同士が競合しあうのはちょっと悲しい。
まあ、そんな事を気にせずに済むほどにマーケットがでかくなればいいんだけど。

>>145
> 標準がDebian形式でFreeBSDのportsやRedHatのrpmにも

無知で申し訳ないんだけど、GUIのパッケージマネージャはあるの?
そして、それは標準インストーラ形式をフォローするの?

ここにも「さまざまな形式をサポートする」事の弊害があるような。
Appleがさまざまなフォーマットを受け入れるのは歓迎するけど、
Macとしての統一性はほとんど損なわれつつあるんでないかね。

エンドユーザから見ても、ややこしくね?

> Apple推奨の「パッケージフォルダ形式」であれば、確かに

あれ、個人的にはかなり良い出来だと思うんだけどな。
設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。

せっかく良い物も、使われなければ何の意味もない。


147 :●~*:03/05/02 15:49
>146
> 設定がパッケージの中に埋もれるのは賛否両論かも知れないけど。

設定をパッケージに埋めたらマルチユーザーが(ry

148 :75:03/05/02 16:18
>>146
リソースは有効に使ってほしいのは確か。

>ここにも「さまざまな形式をサポートする」事の弊害があるような。
ソースやバイナリのパッケージが開けるという話しで
規格乱立という感じじゃないな。指摘の通り、しっかりした
GUIを備えている訳でもなさそう。

主流としては標準インストーラのpkg形式かViseだと思う。
それと1個の実行ファイルのように振舞うパッケージフォルダ式。

ふと思い付いたので、本来のUI話に戻るけど。
ファイルの保存・開くも、パッケージフォルダで指定するように
するというのは、どうかなと思ったり。

データの保存履歴や属性とかのカタログインデックスを
パッケージ内に置いておいて、ユーザーはもっと抽象的な指
定でOS側が分別してデータを出し入れするようにするとか
できないのかな?

149 ::03/05/02 16:29
>>148
だから、パッケージに埋めたらマルチユーザが(ry

設定ファイルは所定のフォルダに入れないとだめかなーと。


150 :●~*:03/05/02 17:22
アップルから提示されている設定の保存は、NSUserDefaultsを使用する方法のみです。

あと、ほかの場所がないか探してたらこんなの見つけました。

>Your application should never write user-preference data inside the application package.

このあとに余計なことせずにNSUserDefaultsかCFPreferences使え、ボケ!って書いてます。
CFPreferenceは現在NSUserDefaultsがホスト単位での設定をサポートしていないための逃げ口です。

//以下余談
CFPreferencesを使うと
現在のホスト上の現在のユーザー
特定のホスト上のすべてのユーザー
すべてのホスト上の現在のユーザー
すべてのホスト上のすべてのユーザー
という場合わけが出来るようです。


151 :あぼーん:あぼーん
あぼーん

152 :あぼーん:あぼーん
あぼーん

153 :あぼーん:あぼーん
あぼーん

154 :あぼーん:あぼーん
あぼーん

155 :●~*:03/05/02 21:36
他人が見て面白いことを書きましょう。大勢の読者がいることを意識してください。
 

156 :●~*:03/05/02 22:11
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨環‥‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨梨鍋‥‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨梨梨梨梨梨梨梨梨梨狂‥‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨U梨梨梨梨姉梨梨梨梨梨梨梨梨梨マ‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨環朕姉梨梨梨梨梨梨梨梨梨梨梨梨梨朕‥
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂鍋鍋鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨狂
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂狂狂マ狂梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂ママママママママ狂梨梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママママママ狂狂梨梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂ママママママママママママ狂狂狂梨梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂マママママママママママ狂狂鍋梨梨梨梨梨
梨梨梨梨梨梨梨梨梨梨梨梨梨梨マ狂狂狂マママママママママママ狂鍋姉梨姉姉姉梨
梨梨梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂狂鍋姉姉朕環鍋狂マママ狂鍋朕梨梨梨梨姉梨
梨梨梨梨梨梨梨梨梨梨梨狂狂狂狂鍋環姉梨梨姉朕環環鍋狂狂狂狂鍋鍋環朕朕姉梨梨
梨梨梨梨梨梨梨梨梨梨狂狂狂狂朕姉朕環鍋狂狂狂狂狂鍋鍋鍋鍋鍋鍋狂狂マ狂鍋環梨
梨梨梨梨梨梨梨梨梨狂マママ鍋環狂ママママママ狂狂鍋鍋鍋鍋鍋狂狂狂マ狂鍋鍋梨
梨梨梨梨梨梨梨梨狂狂マママ狂狂ママママママ狂鍋鍋狂狂狂狂狂狂鍋鍋姉姉環環姉
梨梨マ梨梨梨梨狂狂狂マママママママ狂狂環環環環鍋狂ママ狂狂狂鍋マ梨梨梨環朕
梨狂梨梨梨梨朕狂狂狂マママママママ姉鍋鍋梨梨朕鍋マママ狂鍋狂鍋鍋環環環環環
梨マ梨梨梨梨姉鍋狂ママママママ鍋鍋鍋マ狂狂鍋鍋狂ママママ鍋狂狂狂鍋鍋狂狂鍋


157 :●~*:03/05/02 22:12
梨鍋梨梨梨梨梨鍋狂マママママママ…ママ狂狂狂ママママママ狂鍋狂マ狂狂狂マ狂
梨梨環梨梨梨梨鍋狂狂狂ママママママママママママママママママ鍋鍋狂ママママ鍋
梨梨麻梨梨梨梨環狂狂狂狂マママママママママママママママママ鍋鍋狂ママママ鍋
梨梨行梨梨梨梨朕鍋狂狂マママママママママママママ鍋狂ママ…マ鍋鍋ママママ狂
梨梨麻梨梨梨梨朕鍋狂狂マママママ……マママママ狂ママ……ママ鍋鍋狂マママ狂
梨梨梨梨梨梨姉鍋鍋狂狂ママママママ…ママママ狂鍋ママ狂狂鍋環朕環鍋狂狂マ鍋
梨梨梨梨梨梨鍋狂狂狂ママママママママママ狂狂狂鍋鍋環狂鍋朕姉朕鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨マママママママママ狂狂狂ママママ狂狂狂鍋鍋鍋鍋鍋狂狂鍋
梨梨梨梨梨梨梨梨梨梨ママママママママ狂狂狂マ梨梨梨梨狂梨梨梨梨梨梨鍋狂鍋狂
梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂梨梨狂マママ狂狂鍋環朕朕環梨梨環マ
梨梨梨梨梨姉鍋梨梨梨梨梨梨ママママママ梨鍋環環鍋鍋鍋鍋環環朕梨梨環狂梨梨‥
梨梨梨梨梨環環梨梨梨梨梨梨マママママ梨梨狂姉梨環鍋ママ狂狂朕姉朕狂狂梨梨‥
梨梨梨梨梨環朕環梨梨梨梨梨梨梨マママ梨梨狂鍋鍋鍋鍋鍋鍋鍋環朕環鍋狂鍋梨梨‥
梨梨梨梨梨姉環環梨梨梨梨梨梨梨梨梨梨梨マ狂ママ狂狂狂鍋鍋鍋環朕鍋鍋環梨‥‥
梨梨梨梨環梨環環梨梨梨梨梨梨梨梨梨梨梨狂狂マママ狂狂鍋環環環鍋鍋梨梨マ…‥
梨梨梨梨姉梨鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨マママママ狂狂狂狂狂梨梨梨梨……
梨梨梨朕梨梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨ママママママママ狂鍋梨梨梨梨…
狂姉梨環姉梨環環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉姉鍋マ…
梨梨姉朕姉梨朕環環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨鍋…
梨梨姉姉朕姉姉環環鍋環梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨梨梨姉梨梨鍋
梨梨梨梨環梨梨姉環環鍋鍋梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨梨
梨梨梨梨朕梨姉梨環鍋鍋鍋狂狂梨梨梨梨梨梨姉梨梨梨梨梨梨梨梨梨梨梨梨梨姉梨梨


158 :●~*:03/05/02 22:57
あらら、旧板のレス止まってしまったじゃないのw
>>157
みんな気が小さいんだから、荒らしと間違われるよ

159 :●~*:03/05/02 23:15
フォントを小さくしてやっと見えた。
で、誰の顔?

160 :●~*:03/05/02 23:17
こうするとかちゅーしゃではちゃんとみられるかな?
>>156
>>157
力作だけどキモーかなぁ…

161 :●~*:03/05/02 23:18
損し?と思われ。

162 :●~*:03/05/02 23:29
>>156,157

163 :●~*:03/05/02 23:30
>>156-157
こうか?

164 :●~*:03/05/02 23:37
>>163 正解みたいです、スマソ。

165 :●~*:03/05/06 08:53
梨がたぶん勘違いしてるのでひとつ。

バッケージってのは、ひとつのフォルダに関連性のあるファイルが詰め込まれているものの総称で、
アプリケーションパッケージはそのひとつ。
フォルダにパッケージフラグが立ってればFinderは内容がどうあれパッケージとして扱う。
確か、rtfdっていう、rtfを文章、画像等に分けて、パッケージ化したフォーマットがあったはず。

だから多分>>148さんが後半で言ってるのは書類パッケージがあれば面白いんではないか、ということだと思う。


166 :75:03/05/06 12:53
>>165
パッケージ化されてるアプリって、中にバイナリファイルがある訳だ。
パッケージをダブルクリックすると、そいつが起動する仕組みだよね。

例えばね。
書類パッケージの中にデータを加工したアプリをカタログファイルの
ようなものに記述してパッケージ内に置いておく。

書類パッケージをダブルクリックしたら、指定のアプリを起動する。

「最終更新のデータ」「ユーザー◎◎が加工したデータ」「M月D日以降のデータ」とか
(メールソフトの「ルール」に近い感じで)カスタマイズ可能な複数の項目で検索する
ダイアログを出して、ファイルを特定。

確認ダイアログは必要かどうかはともかく、それでファイルを開く。

保存に関しては「別名で保存」「複製を保存」とか、ファイルを別途に新規作成する
場合も、カタログファイルに、検索に必要な項目を予め書き加えておくようにすれば
ユーザーが敢えてファイル名を考える必要もないと思う。

……なんて、妄想してみたのだけどね。

167 :●~*:03/05/12 01:29
>>166
たとえば、クォークで出力する場合に、必要な書類を一つにまとめる。
クォーク、イラストレーター、フォトショップ書類が混在していて、
ダブルクリックでクォーク書類のみ選択される(クォーク書類のみ開く)
ルールを決めたパッケージとか、DTPに特化して便利になりそう。
書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。

168 :75:03/05/12 10:12
>>167
うん。そうそう、便利だと思うんだけどね。

問題は、必ず「どういったルールでパッケージ内を検索して
対象ファイルを特定するか」というダイアログみたいなのが
パッケージ自体をダブルクリック(もしくはアプリにドラッグ&
ドロップ)した時に必要になってしまうのではないか、なんだよね。

今のように、ファイルをダブルクリックしたら対応してるアプリが
起動する、ってのと比べると見かけ上1段階手間が増える。
「そのファイルがあるフォルダを開いて、目的のファイルを見つける」と
いう作業自体もコミコミなので、実際のところは手間は増えて
ないんだけど。

先にアプリを起動しておいて「ファイル」→「開く」とかやる場合は
手間は同じだけどね。

>書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。

この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
プラグイン形式にするとか、できたらカナーリ便利だよね。

っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。


169 :167:03/05/13 03:35
>>168

> 問題は、必ず「どういったルールでパッケージ内を検索して
> 対象ファイルを特定するか」というダイアログみたいなのが
> パッケージ自体をダブルクリック(もしくはアプリにドラッグ&
> ドロップ)した時に必要になってしまうのではないか、なんだよね。

いや、ここで提示したのは最終的に相手に渡す手段としてのパッケージで。
htmlなら、index.htmみたいなのを起動させ、他の書類はそこからリンクしているだけ、
DTPなら、出力書類のみが選択されるってのを想定した。
制作段階ではパッケージしないわけ。
パッケージのメリットは不必要なファイルにユーザーが触れないことだと思う。

> >書類のリンクチェックとかもパスの部分を読んでやってくれるとなお便利。
>
> この辺は、DTP、Webサイト構築、プログラム開発のライブラリ依存関係
> MP3のプレイリスト、ビデオ編集、3D CGのレンダリング等々、チェック機構を
> 汎用的な形にして、用途に合わせてテンプレをカスタマイズするとか
> プラグイン形式にするとか、できたらカナーリ便利だよね。
>
> っつうか、そういうチェック機能つきランチャーとか誰か作っておくれよ。

さすがにそれを網羅したアプリは……
でも、それをOS標準で付けたらすごいかも。
パッケージ化の時にプラグイン形式でチェックできるようにし、付加価値を高める。

170 :75:03/05/13 09:56
>>169
ああ、なるほどね。理解しますタ。IEのWebアーカイブ形式とかも
結構、近い感じかな。

話を少しだけ戻すと……
実際、1つの制作物(俺の場合はイラストとかなんだが)フォルダの中に
データが複数あった場合、どのくらい作業をした時点で保存したか
ファイル名と修正日で、だいたい見当がつく?

最初のウチは無問題なんだけど、ファイルが何十個にもなって
子フォルダで分類しても、納期間際の土壇場になってくると
段々ワケワカラン状態に……(w
Photoshopのファイルブラウザでプレビューしながら探し回ったり
しているんだけど……俺に整頓能力が欠如しているだけ?(w

>さすがにそれを網羅したアプリは……
>でも、それをOS標準で付けたらすごいかも。
でしょ。MINEタイプを判定したり、本文検索したりできるんだから
その辺までは「あとちょっと」って感じがするけどなあ。

本文要約機能よりは役に立つと思う(w

171 :167 遅レスすまソ。:03/05/19 02:47
>>170
ううむ、それはカタログソフトでなんとかなるようなw
作業用と納品フォルダを分けるとか。
いったん納品フォルダに入れた物でも手直しする時は作業フォルダに写してからね。

作業中に名前が変わってしまった物も、後からリネームツール使って同じ名前で始まる連番にしたほうがいいと思う。
日付け順にリスト表示させると、同じ作品がかたまって、なおかつその中で新しい物が上にくる。

OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
つうわけで、標準でバックアップツールがあったわけだし、
・「元フォルダ」に作業用フォルダを設定(複数可能)し、
・「バックアップ先フォルダ」に納品用のフォルダを指定する。
・apple event でフォトショップが画像を開いていない(つまり作業終了)時にバックアップ開始。
ただし、OSXでpsdが読めるんだから、保存時はpngなりjpegにも変換してくれる。
そんなツールを標準装備してくれたらいいなあ。
な〜んて思っちゃったりなんかして。

172 :75:03/05/20 01:24
>>171
オカエリナサイ。

>ううむ、それはカタログソフトでなんとかなるようなw
扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
サムネール表示だと差異もわかりづらい。ちょっと前に幾つか導入してみたんだけど
しっくり来るカタログソフトがなかったんだよね……最新のだと具合が良いのがあるかも
しれんけど。

>OSが作業中の物はpsd、納品物はtiffやpng、jpegにした場合にフィルタリングしてくれると、助かるとも思うけど。
禿同。まさにOSの方にアプリごとにフィルタリング条件を登録できるようになっていれば
イイと思う。
実際のところパッケージフォルダでなくて、任意に指定したフォルダでも良いんだしね。

PSDとかだと「ファイル情報」とかあるけど、あれで検索できると大分違うんだけどな。
(あとは、レイヤーの枚数とかね)

173 :山崎渉:03/05/22 01:54
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

174 :167:03/05/25 02:50
>扱ってるファイルサイズが大きいので、カタログ化するにしても時間がかかるし、
>サムネール表示だと差異もわかりづらい。
つまり、「目視確認」は無理ってことか……OSXのアイコン最大表示への感想希望。

ウインドウ表示に「アイコン」てあるでしょ。それがより、拡張されたもの……
ファイルビューとしては、リスト表示、カラム表示・エクスプローラタイプ最強。
でも、75さんみたいに、ファイル名、ファイルタイプ、容量、修正日に縛られないルール付けもほしい。

ふと思ったけど、「アイコン」「リスト」「カラム」以外の表示方法がオンラインウェアのプラグインで
拡張できるようにならないだろうか。
それこそ、プレビューソフトの代替として。
アイコン表示なのに、その下に任意のファイル情報が表示できる、なんて感じで。
あと、「修正日」「ファイル表示」以外に「レイヤー情報」なんかを認識するプラグイン必須。
それとは別に、現在ファイル保存時に狭いダイアログにフォルダが表示されて、ユーザーは名前だけ決める。
そうじゃなくて、アイコン表示の画面になり、保存する座標を決められたならば、アイコン表示はもっと良い物に。

あとやっぱり、「特定フォルダのPSDを別フォルダにTIFFで抽出してまとめる」てやってくれAPPLE。
たぶん、写真屋のバッチ処理よりネイティブなので早いはず(想像)

175 ::03/06/29 13:41
あ。最近考えてた事と被るなあ。

>>165-174
「ファイルからいかに情報を集めるか」
「ファイルにいかに多くの情報を記録するか」
というのは、今後のファイルシステムが検討すべき課題だけど、
実は単にデータフォークとリソースフォークに分ければ済む話だと思う。

情報はXML(MSSQLでもいいけどさ)に保存して対応づけて、
UIがXMLに対応すれば、それらの情報表示も出来る事になるね。
検索はテキスト全文検索があればいいわけだし。

で、それらの情報を包有する「モダンファイル構成」を、
パッケージ形式で提供すれば良い。

ということだよね?


176 :あぼーん:あぼーん
あぼーん

177 :あぼーん:あぼーん
あぼーん

178 ::03/06/29 13:55
>>166
パッケージが独自のバージョン管理レイアを持つ形になるよね。

>>167
いわゆるWebアーカイブの発想よね。って下で書かれているけど。

>>168
現行のUIに呼応させるなら、
最後に使ったファイルとアプリを覚えておいてそれを呼び出す形かな。

>>169
リンクチェックの汎用化は難しいでしょう。
労力のわりに意義のある統一とは思えないなあ。
ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。

>>170
パッケージが外部アプリのコンバータを利用出来るという前提なら、
コンバートすれば出力出来るものは「キャッシュ」とみなせるよね。
足りないものは都度「コンバート」して、
速度が必要なら「キャッシュ」を使えば、メタな扱いは出来るのでは。

>>171
「作業用」パッケージを「納品」アイコンにドラッグするとかは?
個人的には右クリックが一番いいんだけど。
「キャッシュ」として考えるなら、
フィルタリングでは無く「抽出」のような気もする。
って、>>174に書いてあったね。

なんか、漏れが話せば話すほど、
UIではなくAPIの話になっていくような。。。


179 :167:03/07/01 01:34
>>175
>で、それらの情報を包有する「モダンファイル構成」を、
>パッケージ形式で提供すれば良い。

結局そうなるのかな?
パッケージ内で雑多に同時進行するファイルをOS標準の何か(って何だ)がうまく管理し、ユーザーはパッケージのみを大雑把に管理する、と。

「でもそれってもう新しいアプリケーションを開発して1ファイルにしてOKじゃ?」とも思うが、実際はファイル損傷のリスクとか、他のプロジェクトで流用するケース、DTP←→HTMLとかで、抜き出す手間を考えるとパッケージの佳さがあると思う。
Wordに埋め込まれた高解像度ビットマップ画像を抜き出したことがあるが、大変だった。

>>178
>リンクチェックの汎用化は難しいでしょう。
>労力のわりに意義のある統一とは思えないなあ。

とりあえず、「シリアルが必要」「やたら重たい」イラレを立ち上げずにリンクチェックできるソフトはあって、そこそこ重宝している。シンプルにチェックのみできるし。
……思うんだが、アプリケーションと書類の相互依存性を、現在のWINの「関連づけ」、Macの「クリエータ」がサポートしている。
同じように、書類同士の依存関係をOSがサポートしてほしいな。上のアプリが必要無いくらいに。

>ファイルのリンク管理の部分だけ情報を二重化する形なら可能かな。
妄想が入るけど、DTPアプリが共有して使うリソースフォークだったらMacは天下泰平だった……
う〜ん、しかしリソースってのはナイスなアイディアかも。

>「キャッシュ」として考えるなら、
>フィルタリングでは無く「抽出」のような気もする。
それで言い直した訳ですわ。相手には必要なデータのみ渡したいね。

180 ::03/07/01 23:24
このスレはコンセンサスまでが早くて気持ちいいな。

>>179
> 書類同士の依存関係をOSがサポートしてほしいな。

仮に二重化するなら、
「どのファイルがどのファイルに依存しているのか」をOSが別途管理。
管理するために、所定のフォーマットから「抜き出す」のは力業で対応。

参照カウンタみたいな概念があれば実は成り立つのかも。
きっとその世界では、すべてのファイルはディレクトリでもあるんだろうね。
相互参照はどうするんだ、とか一瞬思ったけれど。

真面目にやるなら、
「どのファイルの」「どの部分に」「どのような形で」
リンクしているのかをOSが汎用化した上で持たなければならない。

この「汎用化」ってのがいまいちピンとこないんだよな。
クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。


181 :あぼーん:あぼーん
あぼーん

182 :167:03/07/02 00:41
>>180
> 真面目にやるなら、
> 「どのファイルの」「どの部分に」「どのような形で」
> リンクしているのかをOSが汎用化した上で持たなければならない。
>
> この「汎用化」ってのがいまいちピンとこないんだよな。
> クリップボードの内容を別のアプリに切り貼りする事に似ているかも。
> 「OSの機能を使う」とはいっても、疲れるのは結局アプリという罠。

二重化したリンク情報は、OSが、リンクしているファイルの相関図、エリアマップみたいなものをパッケージ内の書類で提供するってのはどうだろう。
これって
> 参照カウンタみたいな概念があれば実は成り立つのかも。
で思ったんだけど。

アプリ側がOS側に申請すると他のアプリでも読み込める形式で、相関図を書く。
通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
(DTPとかのリンクってのはHTMLのスタイルシート、プログラムでの個別のスプリクトみたいなものかな)
なので、かならず頭になる書類は強弱関係で導きだされる。

>この「汎用化」ってのがいまいちピンとこないんだよな。
でも、引用されている書類の形式によって、大体用途が限られていると思うんだよね。
ビットマップを引用して、音楽に変換するような酔狂なことをしない限りは。
パッケージをポンと他人に渡せるし、後で中身を他のアプリが容易に再利用できる橋渡しとして、リンク情報だけでも十分かなあと……。

ちょっとパッケージの話からそれるけど、最低でも今までの常識では「このファイルがこのファイルを欲しがっている」ことを知る方法はあったけど、その逆はなかった。
それがレベルの低い動作でできるようになったらかなりの進歩だと思うなあ。
Finderでゴミ箱に持って行ったり、引用されているファイルをうっかりいじってしまう前に、どういったファイルが引用しているか知らせて警告してくれたり。
そうしたら、僕はなんて親切なUIだろうって思うよ。
「ウザイ」って思う人はいるだろうけど、仕事がからむとまた別。

183 :●~*:03/07/02 07:32

●梨は、おそいCPUが大好き。
●梨は、低シェアPCが大好き。
●梨は、妄想が大好き。
●梨は、コピペが大好き。
●梨は、なりすましが大好き。
●梨は、9時と13時に書込むのが大好き。


184 :167:03/07/03 00:02
>>183
Finderで、使用中のファイルを捨てれなかったり、拡張機能などをシステムフォルダに重ねるとしかるべきところへ持って行ってくれる……。
これって親切だと思う。もちろん、拡張機能を好きなところに置くこともできる。この柔軟さ。

僕が182で書いているのは「強制的に捨てられない」ていうんじゃなくて、アップルイベントとして、
「このファイルを必要としているファイルがあるか?」
という問いにMacが 0/1 で答えてくる。というのを考えているんだよ。
物を創る人にとって本当に必要といえるOSであれば、実装して欲しいファイル管理だ。

僕はずっと「OSXでこんなUI、ユーザーのアクションに応える動作をしてくれたらなあ」という意見で一貫している。

おっと、騙りか……

185 ::03/07/03 15:43
一部省略。ごめんね。

>>184
インストールパッケージの依存管理と同じ概念なのかな?

> 「強制的に捨てられない」ていうんじゃなくて、
> 「このファイルを必要としているファイルがあるか?」
> という問いにMacが 0/1 で答えてくる。

それに対してとれる行動は、
・削除を中止する。(推奨)
・強制的に削除する。
というのでいいのかな?

OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。


186 :あぼーん:あぼーん
あぼーん

187 ::03/07/03 16:14
>>182
補足じゃなくてこっちにレスすれば良かった。

> 通常、リンクした複数ファイルってのは複数に枝分かれするような状態で、必ず親子の関係がある。
・リンクされないファイルも存在する。
・リンクされているファイル同士が対等に結びついている事は無い。
という事だよね。

それでいて、
・どのような内容でリンクされているかは考慮しない。
・リンク情報は親→子、子→親の両方を参照出来るようにする。
というわけだ。

なんか、自分で書いてて「循環参照はありうる」とか思ったけど、
まあ、それは置いておくとしたら、それなりに意義があるのかも。
ハードリンクの拡張みたいな位置づけになるのかなあ。


188 :167:03/07/04 01:17
>>187
> ハードリンクの拡張みたいな位置づけになるのかなあ。

無知なんでぐぐったけど、そういう感じで。UNIX系のメリットが生かせるのかなぁ。

>>185
> インストールパッケージの依存管理と同じ概念なのかな?
>
> > 「強制的に捨てられない」ていうんじゃなくて、
> > 「このファイルを必要としているファイルがあるか?」
> > という問いにMacが 0/1 で答えてくる。
>
> それに対してとれる行動は、
> ・削除を中止する。(推奨)
> ・強制的に削除する。
> というのでいいのかな?

「保守モード」に入っている時とか、パッケージに指定したフォルダ内(上のハードリンク的リンクマップがそのパッケージ内に埋め込まれるとかして)でのみ、そのダイヤログがでることを希望するね。
で、上の二つの行動を促すボタン以外に、問題のファイルを開くボタンもあってほしいな。
WINとの差別化をするならば。
そして、「捨てる」アクションに対してだけでなく、アプリなりFinder上の操作による問い合わせにも気軽に応えて欲しい。

と、ここで思ったのは、パッケージってリソースに代わる存在なんだろうか。

> OSXでは、ロックがかかったディレクトリは開くことが出来ないのね。
> 中のファイルを見るにはコンソールを使うか検索するしかない。不便だ。
>
無理矢理コンソールを使わせる作戦なんだろう。

189 :●~*:03/07/04 07:02

     ● ● ● ● ● ● ● ● ● ● ● と
     梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 梨 こ
  な  は は は は は は は は は は は ろ
  ん  A A A A A A A A A A A で
  で  カ ラ 論 ガ 荒 9 な コ 妄 低 お  
  だ  タ リ 破 イ し 時 り ピ 想 シ そ  
  ろ  ロ ッ さ ド が と す ペ が ェ い  
  ?  グ っ れ ラ 大 1 ま が 大 ア C  
     評 て る イ 好 3 し 大 好 P P  
     論 る の ン き 時 が 好 き C U  
     が の が が B に 大 き B が が  
     大 が 大 大   書 好 B   大 大  
     好 大 好 好   込 き     好 好  
     き 好 き き   む B     き き  
     B き B B   の       B B  
       B       が            
               大            
               好            
               き            
               B            
                   

190 :●~*:03/07/04 07:06

          ┏━━━━━━━━━━━━━┓
          ┃             ┃
          ┃    他お Oパ 板  ┃
          ┃    の願 Sソ 違  ┃
          ┃  マ 住い 板コ い  ┃
          ┃  ッ 民し Bン で  ┃
          ┃  ク のま 等一 す  ┃
          ┃  マ 迷す で般 B  ┃
          ┃  ナ 惑B  板    ┃
          ┃  | で   B    ┃
          ┃  哲 す        ┃
          ┃  学 B        ┃
          ┃             ┃
          ┗━━━━━━━━━━━━━┛


191 :167:03/07/04 15:56
>189-190

激しくスレ違い。

192 :山崎 渉:03/07/15 11:24

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

193 :●~*:03/07/20 13:58
記念眞紀子

194 :●~*:03/10/03 00:29
ネタはないがあげてみるか

195 :●~*:03/10/03 02:59
梨って人自分に酔ってるね.

196 :●~*:03/10/05 10:58
オマエモナー

197 :●~*:03/10/08 19:36
↑名前忘れてますよ梨さん

198 :たかちゃん ◆aYYJ4NEyLs :04/04/02 22:31
なんか>>166-168あたりで語られていることってー
Adobe VersionCueが結構近いかな、とか思ったり。

2ちゃんのやり取りの方がAdobeのリリースより先行してるって
なんか珍しいよねー。

199 :●~*:04/04/10 17:35
>>198
旧板って結構こういうレベルの高い内容があったりして侮れないよね

97 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)