{希哲17年1月21日の開発}{希哲17年1月21日の進捗}{希哲17年1月21日}{仕様化}{設定してある}{font-size: 120%}{<strong>}{強調部分}{分かりやすい文書}{学び始めた人}...=}(106)

{希哲17年1月21日16歩 K#F85E/E74C-E642}

進捗時限記録中略

知名デラング調整関連交度整理終了

新たに強調記法文字装飾記法小書き記法化学記法対応した

いったん全て出振るい手定め済み

デラング周り作業はここで一段落とし,別の作業入るデラング関連次の主要当努9日の検討通りタグ記法整備見通し


知名デラング拡充については,知名の役割誤解させかねないという懸念から消極的にすべきかもしれないと考えていたが,20日7歩極力拡充していく方針決めた

実用性観点でいえば,やはり最短知名原則有用で,知名情報詰め込んだり装飾したりということは推奨出来ない。ただ,間口を広げることを考えなければならない今のデライトには遊び必要だろう。

デラング学び始めた人知名デラング使いたくなるのは自然なことであり,そこから学べることもある。知名の役割については,分かりやすい文書整えることが本筋だ。


手定め中知名強調記法使う中景輪符強調部分文字サイズ大きくなることに気付いた

<h1> 以下の <strong>font-size: 120%設定してあることが原因だった。意図忘れたが,何かの目的でこんな細工をしたような記憶うっすらある。

直そうかと思ったが,ちょっと面白い効果でもあるので,いったん置いておき仕様化するか検討することにした。見出し太字強調使う意味無いだろうと思っていたが,意外と表現方法はあるものだと過去の自分偶然気付かされた

=}
{描写}{知名}{デライト(なんでもメモ)}{引き入れ}{デライト}{デライトの使い方}{新生デライト}{難しい質問}{超かんたん}{自由市場}...=}(57)

{引き入れについてのご質問から考えたこと K#F85E/E74C-C61D}

大変回答が遅くなってしまい申し訳ありません。色々なことを考えさせられるご質問で,デライトにとって非常に重要な宿題を頂いたように感じています。ありがとうございます。

だいぶ時間が経っているのでお考えが変わった部分もあるとは思いますが,他の方の参考にもなるように文章を残しておきます。まずは,ご質問の内容に沿って,出来るだけ端的に書けることを書いてみます。

引き入れについて

宇田川さんは、知名のみの輪郭をよく引き入れられ欄に引き入れているように見受けられます。

まず,「引き入れられ欄に引き入れる」という概念が私の中に無かったので,難しい質問でした。「引き入れる」というのは,ある輪郭の中に他の輪郭を文字通り「引き込むように入れる」,ただそれだけの極めて単純な操作で,それをする方にとっては「引き入れる」,される方にとっては「引き入れられる」ということになります。

例えば,フォルダの中にフォルダを入れる操作に相当します。ただ,多くのツールでは,データの内容とデータ同士の関連性は別々の画面に表示されます(別のウィンドウやサイドバーなど)。輪郭は,輪郭の内容と他の輪郭との関連性を一緒に表示させる仕組みを持っているのが特徴的です。これは,画面を切り替えたり視線を大きく移動することなく,内容と関連性を確認したり修正したり出来るようにする工夫です。

「輪郭をどの輪郭に引き入れたいか」というごく単純な考え方で使えるように設計したつもりでしたが,この見た目が「引き入れ欄に引き入れる」や「引き入れられ欄に引き入れる」という複雑な考え方をさせてしまっているのかもしれません。

このように、知名のみの輪郭を引き入れられ欄に輪括させるのは、主にどのような効果を狙ってのことなのか、ご教示いただけませんか。
あるいは、実際に効果があったと感じた出来事・体験をお伺いしてもよろしいでしょうか。

読み込み中...
{Aejs}{描写部}{希哲16年3月28日}{見触れ}{デライト}{違了処理整備}{出振るい}{踏み切れた}{radial-gradient()}{作れた}...=}(204)

{希哲16年3月28日の開発 K#F85E/E74C-5B9D}

KNEST 隠し実装の再開金風といった出来事中断していた昨年9月以来,初めての Aejs出振るい終えた最初微調整程度でとりあえず出振るい目指すつもりだったが,あっという間下見機能陰影付きスクロール形になり,一応の新輪郭選り手」が出来た

外観操作性ともに洗練された新輪郭選り手日々の描出がより快適になることはもちろん下見機能手定め領当て調整大幅に効率化することによりデラング整備加速するだろう。そもそも Aejs出振るい出来なかったことで前縁関して出来ること限られていたため,その障害無くなったことが大きい

新輪郭選り手

今回出振るい以前を「旧輪郭選り手」,以後を「新輪郭選り手」と仮に呼んでいる

新輪郭選り手では,@oln.bld詰め込んでいた選り手関連機能@oln.edr_dln.bld@oln.edr_knm.bld整理し,複雑な機能見通し良く管理出来るようになった。これにより,保守性もちろん全体として見触れ大きく改善した。

まず,これまで知名選り手角丸長方形で,描写選り手吹き描き合わせた眼形表示していたが,両方開いている場合は「合体選り手」として眼形になるようにした画面撮り新規描出フォーム再描出フォーム旧輪郭選り手では単独開いた場合外観変わらず調和感欠けていた画面撮り新規描出フォーム再描出フォーム挙動もより連動的になり,自然になった。

描写選り手右脇適当に付けていた取り消しボタンも,合体選り手では知名選り手描写選り手同時に閉じる機能分かりやすくなり,見た目洗練された

描出ボタン22日9歩方針まとめ目障りにならないデザイン保ちつつ初心者にも分かりやすいものに出来た

挙動面では,違了処理整備若干表示タイミングなどに出来ていたぎこちなさ解消出来た外していた選り手溶暗溶明動き付け復活させ,滑らか見えるようになった。

読み込み中...
{知番}{知名}{最短知名原則}{希哲16年2月22日}{希哲館事業}{デラング}{進捗記録}{希哲16年2月22日の開発}{希哲16年2月22日の進捗}{担わせる}...=}(159)

{希哲16年2月22日9歩 K#F85E/E74C-BABF}

進捗時限記録中略

kitetu.comサブドメイン設計についての検討終了

今後デラングのように独立して参照出来るべき献典には積極的にサブドメイン与えていくことにした(例:dlng.kitetu.com


デラング的転回同時にデラング文書dlng.kitetu.com与えることを決めたが,これを機に知番SLFS 等々の公式文書にもサブドメイン与えることを考え始めた

これまでサブドメイン追加には消極的で,例えば技術系献典tech.kitetu.com集約することを考えていた。ただ,この手の URL 設計は,運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上,階層的な整理難しいことも多々あり,変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合対策として,経験上最短原則」が最善であることは分かっていて,最近駒手にせよ各種識別子にせよ知名最短知名原則にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業要素全て kitetu.com階層下にある,ということだけは確かだ。もちろん,これとは別に,階層的な情報源もあった方がいいので,そこは tech.kitetu.com などに担わせる

献典ドメインとしての独立性統一感同時に持たせられるのだから,むしろ,ここからがドメイン名統一本領発揮になりそうだ。

2文字サブドメイン問題解決

読み込み中...
=}
{知番}{希哲16年1月31日}{輪結}{進捗記録}{希哲16年1月31日の開発}{希哲16年1月31日13歩}{普通の輪結}{使えるようにする}{輪結手段}{まとめながら}...=}(44)

{希哲16年1月31日14歩 K#F85E/E74C-B7D8}

前歩についてまとめながら角括弧知番による輪結可能性気付いたため急遽まとめ終了

多重輪括弧閲覧専用模動後景一覧輪郭ページへの輪結として機能するなら,その閲覧専用模動への輪結手段があってもいい。いま角括弧URL組み合わせ[アンカー https://example.com]対応している輪結記法[アンカー K#XXXX/XXXX] の形で使えるようにするのが自然だろう。

更に,これは閲覧専用模動では同模動普通の輪結になるのが自然なので,前歩書いた閲覧専用模動強調輪括弧表示もせずに輪符輪結化したいという場合」にも上手く対応出来る。

ここまでで若干もやもやしていた閲覧専用模動周りの仕様が大分くっきりしてきた。

{希哲16年1月24日}{進捗記録}{文字装飾記法}{<small>}{置き換えられる}{補足部区}{注意部区}{一段階目}{希哲16年1月24日4歩}{強調度}...=}(73)

{希哲16年1月24日16歩 K#F85E/E74C-1FEF}

注意記法補足記法についての再検討終了

4歩を以下のように修正した。強調度に応じて三段階となる補足記法同様

!--
小さな注意書き
--

!!--
通常の注意書き
--

!!!--
重要な注意書き
--

装体は,23日2歩下敷きに,境界線背景色無しで font-size: 0.8em 程度にした小書きのものを加える。この場合,一段階目注意部区補足部区装体的に区別出来なくなるが,そもそも小さな注意書き補足違い曖昧なものなので自然といえば自然だ。

読み込み中...
{描写}{知名}{希哲16年1月23日}{用者}{進捗記録}{認識しやすい}{兼ねている}{おまけに}{多々ある}{二段階方式}...=}(90)

{希哲16年1月23日1歩 K#F85E/E74C-27DA}

換配確認機能」についての再検討終了。なお,この検討から「下見プレビュー機能」に改称した。

下見機能は,輪郭選り手左下下見ボタンを置く形でほぼ確定か。


デラング整備進展とともに重要性増している下見機能だが,用合いをどうするかについてはまだ少し迷いがあった。

一応最有力案は,輪郭選り手左下に「確認ボタン」を置くというものだった。左上公開設定機能右上取り消しボタン使いたいので,左下置くのが自然ではある。

完了ボタン並べるという捨て切れなかったが,押し間違い多発しそうで用合いとしては難がある

今朝ふと,確認ボタンから描き出し完了ボタンへの二段階方式浮上してきた。つまり,必ず換配確認をしてから描き出し描き直しを行うことになる。

二段階方式利点には用合い単純化初心者にとっての流れ分かりやすさおまけに捌き手負荷軽減見込めるが,使い慣れた用者にとっては煩雑になり過ぎる懸念があり,採用見送った

ある程度複雑なデラング記法使う場合など換配確認をしたいこともなくはないが,確認するまでもない描き直し多々ある。また,公開設定機能導入によって気軽に描き出し描き直しが出来るようになると,役割重複してしまう。

一つ,輪郭削除確認機能を兼ねられるかとも思ったが,そもそも知名描写にして削除というのが確認作業兼ねているためこれもやはり煩わしい

やはり,換配確認選択的機能にしておくべきだろう。

これまで,完了ボタンに近い位置に置くことも考えていたため,描出流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビュー日本語表現として採用していたが,ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

{自然}

{}