{希哲館事業}{新生デライト}{範枠}{希哲16年2月24日}{『希哲日記』}{読む}{展開する}{導入したかった}{良い思い付き}{本当は}...=}(69)

{希哲16年2月24日の日記 K#F85E/E74C-D547}

{出振るい}{進捗記録}{分かる}{希哲16年2月15日24歩}{希哲16年2月9日の開発}{確信が持てなかった}{領当て}{ずらせない}{他要素}{空間的に}...=}(122)

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

進捗時限記録中略前後

デライト装体調整昨日7歩に関する整理終了

見出し段落よりも横幅両端0.5remずつ広げ区切り線<hr>段落よりも0.5remずつ狭めることにした見出しと区切り線装体・幅調整後

当初見出し下線区切り線見分けやすくするために,区切り線両端1emずつ狭める形にしかけたが,試しに出振るいしてみたこの形が想像以上しっくり来たので,基本方針として採用してしまうことにした。

文書構造視覚的にぐっと把握しやすくなった


段落に対して僅かに字上げするような見出し装体昔から気に入っていて,現状でも「はじめに」などのデライト文書<h2>1em<h3>0.5em字上げされている長らく更新していないため描写内見出しとは全体的に乖離している)月庭でどうしていたか忘れたが,特に理由がなければ似たような装体採用していたはずだ。

やはり,見出し直感的に把握しやすいのが大きな利点だが,描写内見出し採用出来なかった理由として,無駄な余白生じやすいという領当て上の問題大きかった。特に,諸場対応から強く意識するようになった幅狭領当てでは小さくない問題だった。

今回実験意外だったのは,全ての描写内見出し0.5remずらすだけでも十分な視覚効果得られたことだった。これなら,他の装体そのままに,見出し装体マージン削るだけで一応実現出来る。

そのうち領当て上の問題起きたとしても,幅狭領当てでは0.25emにするとか区切り線だけ調整するとか,調整やりよういくらでもあるので,基本方針としては問題ないだろう。


これだけ見出し分かりやすくなれば,区切り線短くする必要はないかとも考えたが,これはこれであった方がメリハリが付いて良い従来の他要素同じ長さだと,やはり直感的に区切りの大きさ把握しにくい

新装体なら,見出し見比べるまでもなく,見出し未満小さな区切りであることが分かる

空間的に見出しずらせない場合の備えにもなる。


昨日眠気が強い時間帯思い付いたのでこの新装体良さ確信が持てなかったが,認知機能低下している時に分かりやすい思ったのだから,分かりやすさに関しても間違いないだろう。

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

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

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

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

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

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


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

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

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

{dg_nxt()}{dg_prv()}{デラング}{進捗記録}{廃止}{前次記法}{パンくず記法}{自動取得機能}{取得する}{早い段階}...=}(58)

{希哲16年1月25日12歩 K#F85E/E74C-B0DB}

進捗時限記録中略

ふと思い付いて時間的な前後関係表現する前後記法」についてまとめた直感性既存記法との整合性考えると以下のような形になりそうだ。

前 <|> 後
前 <|
|> 後

デルンには早い段階自動的にこのような輪郭取得する機能があり,月庭では表示させていた時期もあった。前景輪時印組み合わせ絞り込む方法だったが,描き手意図反映しにくく実行コスト高かったので開発中無効化し,以来その時期の名残り交度だけが残っている状態だったDG_T::prv(), DG_T::nxt()dg_prv()dg_nxt() など)

パンくず記法同様,これもデラング解決すべき問題なのだろう。この方向問題なければ自動取得機能完全に廃止削除してもよさそうだ。また思わぬ収穫だった。

{進捗記録}{手定め}{デライト}{希哲15年10月23日の開発}{捌き手間}{石狩リージョン}{初期費用}{上位プラン}{使っていない2台}{3台}...=}(49)

{希哲15年10月23日6歩 K#F85E/E74C-2BF0}

捌き手整理方針検討終了

いま3台あるウェブ捌きの内,まず使っていない2台解約することにした。それぞれ月庭Mastodon で使っていたものだが,デライト完全集約以後はたまに手定めに使う程度になっていた。

KNEST 隠しによるスケールアウト再利用することを考え維持してきたが,手定め時間がかかることが予想され,最近のデライト高速化感触としてはスケールアップ出来るところまではスケールアップ対応した方がいいという考えになってきている。

現在出場用に使っている捌き手デライト用のウェブ捌き丁度良い性能であるため,新しく上位プラン契約した捌き手出場を移し,空いたところでウェブ捌きを移す方向で考える。空いた以前のウェブ捌きも解約する。

昔と違いさくらの VPS では初期費用無料になっており,昔契約したウェブ捌き性能の割に価格高いものが2台あるため,この整理維持費をほとんど変えずにデライトウェブ捌き出場捌きをそれぞれ上位プランスケールアップ出来る。

リージョンはこれまで適当にしていたが,最終的に残る現出場捌き石狩リージョンなので,最初捌き手間通信効率のため石狩リージョンで揃えておき,徐々に分散させていくことにした。

=}
{月庭}

{}