{開発}{開発記録}{右側}{}{}{デライト}{希哲17年1月4日の副日記}{比較的深刻}{復元出来ない}{それ以外}(246)

{希哲17年1月4日の開発 K#F85E/E74C-6436}

いったん出振るい終え他自我内検索用合い改良兼自我ページ整備一段落した

開発時間確保しにくい時期だったことや交度整理時間をかけたことで12月22日着手してから日数かかったが,総合的に満足出来る結果となった。

特に実装時期予測すら出来なかった自我ページ整備出来たことが大きい。これで新生デライト像完全なものになった。自我ページ整備自体作業時間正味2日間程度で,時間対効果非常に高かった

今後はまず新生全知検索整備り,輪郭整備兼文書整備並行させ新生デライトの成立目指すことになる。

実装について

12月19日の検討通り他自我内検索時に自我アイコン並べ自我ページではこれをプロフィール風見せることにした整備後1整備後2

見ただけではまずやり方分からなかった他自我内検索整合的かつ直感的に行えるようになり,自我知番による検索結果過ぎず一見意味の分からない自我ページ整備前一応プロフィールページらしくなった。

自我ページは,デライトにおける自己表現入り口となる部分であり,初めてデライト触れたまず覗いてみる部分でもあるので,直感的に理解出来るようになったことは大きな進歩言える最低限の又情報設定したので多少の SEO 効果望めるあとは風船輪郭出来ればデライトプロフィールページとしては無駄なく十分なものになるだろう。

読み込み中...
{デラング}{軽量標記言語}{進捗記録}{}{}{HTML の要素}{記号}{@}{与える}{進捗}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

{CSS}{高い}{消え入る}{垢抜けない}{L字型}{Markdown の見出し記法}{二本線}{使っていた}{見出し装体素案}{見出し装体}(31)

{見出しについて思い出したこと K#F85E/E74C-0235}

余談ですが,L字型見出しスタイルは昔希哲館のサイト使っていたことがあったのを,おかげで思い出しました

というより,L字型自体は CSS見出し的なものを装飾するのに,昔から(とりあえずこれでみたいな感じで)よく使われているパターンなので,自然に試したのだと思います。 さんのアイデア面白いのはそれを複数本にするというところだと思うのですが,最初の第1階層がデザインとして野暮ったい上につまらない(昔の CSS 解説サイトみたい)のが個人的には痛いです。この第1階層は実際に使ってみても想像以上にダサい代物であるということは黒歴史として後世に伝えていきたいです。

それが階層の表現であることに気付く前に,とりあえず折り曲げてみた感じに見えてしまうというか……。デザインにおけるダサさというのは,要は「削れるものをとりあえずくっつけている」感じなのです。「いるかそれ?」と思われたら負けで,それが垢抜けない印象になるわけです。その意味では,むしろ「(見本のように)並べてみないと良さが分からないデザイン」になっていると思います。

ちなみに,その案に一貫性があるとすれば下層に行くに従って左線の数が増えていくことになりますが,この方式は階層的に小さい見出しが不必要な目立ち方をする上に気持ち悪いことになるのは目に見えているな,と思ってにしたのが見出し装体素案です。


経験上,見出しはとにかく目立つ要素で,下手に凝ろうとするとデザイン的な事故になる可能性高いので,「引き算」が重要と感じています。

その帰結が,文字下線だけで階層を表現する,という現在のスタイルです。初見では目立たない単なる区切り線ですが,二本線が次第に消え入るような一貫した表現で,階層を判別する必要十分な機能を持たせています。おまけに,デライトでも導入予定の Markdown の見出し記法にも一致しています。自分でいうのも何ですが,これ以上の案を出す,というのは結構難しいデザインの課題だと思います。

ただ,デザインというのは感覚でするものでも好き嫌いでするものでもないので,納得出来ないことをどんどん投げつけてくれる さんとのこういう議論言語化のために非常に有意義だとも感じています。

{進捗記録}{最善}{知番}{初期}{進捗}{拡張子}{譜類添付機能}{台録}{デライト開発}{場筋}(102)

{希哲15年12月19日1歩 K#F85E/E74C-00D9}

分割格納方式への移行作業前に,知番譜類における拡張子扱いについて検討して終了

従来通り無接尾子知番譜台許容することにした。

これまでの自我台録/kn/K#F85E/には無接尾子譜台いくつかあるが,譜類添付機能合わせ,これを全て拡張子付き練名することを考えていた

そもそも知番譜類は,知番譜類名にしてデルン上管理する譜類管理手法として始まり,デライト開発本格化してからこの経験を元に拡張子毎添付譜類という概念固まった

当初一貫性観点からむしろ無拡張子基本考えていたため,初期知番譜類には無拡張子実体拡張子付き疎輪結置いているものがある。ただこれは煩雑な上に,Windows 仮想機上手く扱えない問題があったため次第にやらなくなった。以後,普通に拡張子付けることが多くなった

いっそのこと,全て拡張子付きにして譜類添付機能との整合を取るかと考えたわけだが,全ての譜類適当な拡張子があるわけではなく,必ず指定するとなると煩雑化恐れがある。適当な拡張子がなければ .unk のような特殊な拡張子を使う,台録なら .d 接尾子を使うなど仕様複雑化する。

仮に無拡張子知番譜台空けたところで,その使い道があまり無いという問題もある。本来輪郭情報を置くのが適当なところだが,エクスポート機能等では閲覧編集都合から .oln を使うことを決めている分割格納方式採用したことで利便性いずれにせよ知機駒手補うしかなくなっているので,実体場筋利便性持たせる必要もなくなった。

譜類添付機能エクスポート機能はあくまでも知番譜台応用として,無理に統合せず一定相互運用性確保しておくに留めるのが最善結論付けた

ただ,拡張子用の疎輪結だけは問題なので普通の拡張子付き練名しておくことにした。

{『希哲日記』}{デライト広告}{}{日記}{日本語}{初期}{デライト}{デライト市場戦略}{用者}{知能増幅メモサービス}(126)

{希哲15年9月1日の日記 K#F85E/E74C-7706}

実装作業もそれなりに捗ったが,頭の整理もだいぶ進んだ一日だった。幸先が良い

組計整理み,当面組計見通しはさらに改善気持ちにも落ち着きが出てきた。

デライト市場戦略にも大きな進展が見られ,より一貫性が高まった。

なんとなく対 Facebook 戦略について考えていると,用者数30億人に迫る Facebook勝つのに50億人100億人目指すのはあまり賢くないな,という思い沸き起こってきた。

大きな風船量的大国には小さな弾丸質的大国ぶつけるしかない,というのはジパング計画考えてきたことだが,デライトに関しては,量より質という考え方徹底出来ず,まだ爆発的流行による成功という可能性捨て切れずにいた。

超高効率経営があり,安定拡大戦略があり,書き手読み手能力大きく依存する文字献典重視し,日本日本語重視し……と,全体として量より質志向すべき環境整っていた。現に,いまデライト運営なのは,異常なまでに知的好奇心旺盛リテラシー高い日本人用者しか寄り付いていないからだ。国内外から無闇に用者をかき集めていたら,いまごろ破綻している。

輪郭一覧にあるデライト広告も,どちらかといえば一見よりも描き手向けになっている。初期配置を決めてから何度再検討はしたが,ほとんど動かしようがなく,結果的にこうなっている。輪郭そのものに対して広告を付けると,単純描き手読み手双方にとっての快適性損うという問題もあるが,扇情的内容が増えれば増えるほど収益が上がる構造になり,信頼性モラル低下きかねない。

これだけの条件揃っていながら,まだ揺らぎがあった。問題は,こんな広告十分な収益を上げることが可能なのか,確証が掴めていないことだった。これについては先月実証され,最近では,全知検索使い込んでくれる重用者をいかに増やしていくか,という意識が高まっていた。これが最後のピースだった。

ここからは,デライト市場戦略でも,量より質広さより深さという考え方徹底していくことにした。デライト知能増幅メモサービスとしての完成度高めていけば,用者必ず後から付いてくる日本語圏限界に達する時には,世界中の人が日本語ばざるをえないだろう。

2日振り返り日記3日加筆修正

{使い方}{進捗記録}{十分}{}{}{知名}{描写}{進捗}{デライト}{CSS}(161)

{希哲15年6月21日9歩 K#F85E/E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

読み込み中...
{進捗記録}{進捗}{風船輪郭}{時印更新}{希哲15年3月10日の開発}{吹き描き外}{希哲15年3月10日の進捗時限}{希哲15年3月10日の進捗}{希哲15年3月10日}{中景輪符}(33)

{希哲15年3月10日8歩 K#F85E/E74C-1ADE}

7歩で考えた時印更新に関連して,自己輪括による風船輪郭実装について検討。どちらも,埋もれがちな輪郭浮上させる機能という共通点がある。

通常の引き入れ引き外し一貫性を持たせ,中景輪符吹き描き外ドロップすることでも解除出来るようにする。

さらに,風船輪郭に関しては吊るし輪郭が無い状態でも引き外しボタンを表示するようにする。

風船輪郭中景部境界線二重にするつもりだが,プライバシー問題も若干感じるため,この機能に関しては自輪郭検索のみで有効なものとし,他の利用者からは普通の輪郭に見えるようにする。

{進捗記録}{知番}{初期実装}{進捗}{描写部}{輪符}{希哲15年3月6日の開発}{輪符要素整理}{a.knm}{a.ikon}(35)

{希哲15年3月6日8歩 K#F85E/E74C-3B23}

デライト文書構造最適化事象関連のスクリプト整理,細かい不具合修正

途中で終了。

ここで文書構造最適化合流させることにした。スクリプト保守性に大きく関わるため,まずは中景輪符整理で整えた中景輪符以外の輪符要素整理に入る。

ここは初期実装から試行錯誤連続で,かなり混乱しており一貫性も無い。そのせいでスクリプト複雑化してしまっている。

描写部a.oln から展開される a.ikon構造化されておらず,単純に文字列として輪符が入っている。

前後景部spn.ikon はもっとひどくa.knm 内に知番を突っ込んでいる。

{一貫性}

{}