{進捗記録}{}{}{}{知名}{過去}{描写}{進捗}{希哲17年1月28日の開発}{希哲17年1月28日の進捗}(158)

{希哲17年1月28日21歩 K#F85E/E74C-46A3}

進捗時限記録中略

また新生デライトの要件ではあるが,ついさっき急に実装イメージまとまってしまった輪郭複製機能実装終了出振るい手定め済み

描写欄状態新規描出フォームで,自輪郭輪符知名欄貼り付けるドロップすると輪符から知名描写複写される

複写成功する「複写完了」表示「複写失敗:自分の輪郭ではありません」「複写失敗:描写が空ではありません」違了表示付け自我知番の省略にも対応済み使い勝手非常に良好

これまで通り輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない


輪郭複製機能については,昨年5月18日の開発で「知名描写複製して新規描出フォーム移動するボタン」として実装することを考えたが,その後用合い改良経て抵抗感募っていた

輪郭直接複製するような機能やはり避けたい手軽し過ぎる誤操作濫用可能性高まる適切な手間というで,新規描出フォームへの複写というアイデア悪くなかった。ただ,現状の輪郭選り手理想的にまとまっているので,極力ボタンのような要素追加したくない思うようになった

さっきふと,「知名欄への輪符貼り付け」というについて考えていたら,これが急速にまとまってしまった過去にも何度か脳裏をよぎっただが,その時いまいち気乗りしなかった

貼り付け方式最初の懸念誤入力だった。復元ボタンだけでは心許ないので,知名であることを条件にしようとしたが,空の知名書き始めることは少なくないので中途半端だ。複製したい輪郭検索してから写し取り貼り付けという流れ考えると,知名欄いちいち空にしなければならないのは煩雑過ぎる

間もなく描写欄という条件なら全く問題ないことに気付いた誤操作懸念なくなったので,ドラッグ&ドロップにも対応することにした。

もう一つ自輪郭のみという制限付けることにした。描写内自我知番の省略Aejs対応するのが難しいという問題もあるが,濫用され著作権上手溢れ増えることが予想される他人の描写扱い慎重に,という意味でもこれくらい適切だろう。

こうしてするする実装イメージまとまり一通りの機能付けた実装難なく完了した余計な視覚要素追加せず,それでいて直感的という,理想的な輪郭複製機能あっという間に出来てしまった

{進捗記録}{記号}{進捗}{希哲16年1月23日}{AsciiDoc}{特殊な例}{生じていた}{再確定}{ボタン記法}{希哲16年1月23日の進捗時限}(55)

{希哲16年1月23日4歩 K#F85E/E74C-6C79}

キーボード記法についての再検討終了

キーボード記法に関しては,改めて [_X_] 記法中心にしていく方針再確定した。また,[_X_] + [_Y_] を一つの記法として扱うことも明確化した。


[_X_] 記法導入して一件落着かと思ったキーボード記法だが,その後,少し迷い生じていた

この記法ボタンらしく見え過ぎるせいで,ウィジェットボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかというが出てしまっていたAsciiDoc にはボタンメニュー表現出来るマクロがある)。それが可能なら,[_X_]キーボード記法とすべきではないかもしれない,という気がした

ただ,[_X_]キーボード記法一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別外観を持つウィジェットボタン抽象的表現出来る装体存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材行内埋め込み記法挿入するのが適切だろう。

そう考えると,キーボードキーに使う装体キー記号としてちゃんと機能するのは特殊な例だ。

{アプリ}{デライト}{希哲館}{遠象性}{目指している}{近象性}{引き出せる}{動物の脳}{近象的}{進化生物学}(49)

{近象的であることについて K#F85E/E74C-4C23}

近象的であることが良いというよりも,現象遠近適切利用した方が良いとは言えると思います。

進化生物学的に考えれば,動物の脳は,状況に合わせて生存最適行動を取るための情報処理を担っているはずです。要は,情報優先順位を付けて,重要度の高い情報をすぐに引き出せるように出来ています。重要な情報は近くに,瑣末な情報は遠くに置いているとも言えます。この情報遠近法を形にしたのがデライト輪郭法です。

この輪郭法は希哲社の「知機」開発プロジェクト核心ですが,一部です。

例えば,今の一般的なコンピューターUI では,何かの目的に対し,ユーザーがアプリを選んで対応します。これは十分に近象的ではなく,雑音が多すぎます。「○○がしたい」という時に,「○○を実現してくれる××を使う」のではなく,「○○を使う」と考えられるのが近象的な UI です。

具体的には,統一感の無い絵柄アイコン固有名詞ではなく,ピクトグラムのように体系化されたアイコンで,目的を直接的に表現します。コモディティ化したアプリの仕様の大枠はプラットフォームが決め,サードパーティーはその実装を競作するか,実験的なアプリの提供を行い収益を得ます。

こうした試みは無かったわけではなく,Apple も方向性としてはそれに近いことをやろうとしていますが,突き詰めればこういう形になっていくと予想しています。

CLI でも似たようなことが言えます。例えば,「ファイルを全文検索したい」という時に find と何々を組み合わせて……と考えるのは近象的ではありません。grep -r も grep が固有名詞なので近象的ではありません。理想を言えば find 'foo' と書けるべきでしょう。

知機 Unix 相互運用標準」として希哲館が策定している Synx では,同じことが交度英語fnd 'foo' と書けます。一般の Unix コマンドと区別するため kn fnd 'foo' とも書けます。

要するに,ユーザーが頭に思い描いたことと,UI の言語体系との間に距離が無いことが,工学における近象性です。この点で現在の多くの UI には課題があると感じています。

今の UI は迂遠なことが多いので主に近象性が課題になりますが,もちろん,より複雑・詳細な表現に対応する遠象性も適切に扱える必要があります。

UI が理想的な近象性を実現した時,物理的接続しなくても,十分に脳とシームレスに繋がるコンピューターが実現出来ることになります。これを「知機」と呼んでいます。デライトも含めて,それこそ私が目指していることです。

{使い方}{『希哲日記』}{日記}{サービス}{デライトの成功}{デライト}{デライト宣伝}{自我アイコン}{デライト収益模体}{あれ}(69)

{希哲15年1月4日の日記 K#F85E/E74C-6ABD}

今後の適切施策のためにも,デライト現状再確認した。

デライトは,理論技術献典など様々な面において極めて高い独自性を有し,他のサービスにない高機能性道半ばとはいえそれなりの軽常性実現し,その全ての権利権限開発者自身が完全掌握した状態にある。

まだ収益化こそ出来ていないが,収益模体完成しており,宣伝感触良好であり,諸指標堅調推移を続けている。超高効率経営運用によって財政的にも持続可能状況にあり,少なくとも私が健康である限りは潰れない。

総合的に見て,ネットサービスとしてはこの上なく恵まれた状況にあると言っていい。ただ,成功王手をかけながら詰め切れない,一番歯痒い時期でもある。

課題集客,より厳密には活動用者を増やすことの一点に絞り込める。

今日は,YouTube あたりで「描出実況」などとして,デライト具体的使い方を伝える活動を始めることも検討した。以前から頭の片隅にはあったことだが,動画編集にも時間がかかることを考えると難しかった。もう少しが出来れば時間対効果が釣り合いそうではある。

差し当たり,デライト宣伝最小限に留め,新しい宣伝材料にもなりそうな自我アイコン実装注力することにした。

{デライト}{範枠}{あれ}{PATCH 道手}{希哲14年9月24日}{希哲14年9月24日のツイスト}{描き直し}{効率上}{HTTP 道手}{ツイスト}(15)

{あれ K#F85E/5B28-6B4F}

確かに,描き直しPATCH適切ですね。範枠フレームワーク)によっては HTTP 道手メソッド)で動作を切り替えたりするので効率上の問題もありそうですが,デライトは完全に独自実装なので HTTP というよりはこちらの実装の問題が大きいかもしれません(HTTP に何らかの支援機構があるのか私も詳しくないですが)。

(1){あれ}
{適切}

{}