{メモサービス}{最悪}{}{}{}{}{デライトは早過ぎた}{一日一文}{希哲17年5月の一日一文}{早過ぎた技術}(267)

{デライトは早過ぎた K#F85E/E74C-505B}

まただいぶ間をあけてしまった一日一文だが,少しゆとり出来てきたのでぼちぼち再開したい継続性について考えてしまういつまでも再開出来ないので,停止したり再開したりは今後も繰り返しながらあまり気負わずやっていく


半年ほど前から,デライト市場戦略にも大きな変化生じている個人知識管理サービス市場での競争よりも SNS 市場での競争という意識の変化だ。

当初から次世代個人知識管理サービス高機能メモサービスとしての売り込み考えてきたデライトだが,2年以上市場活動通して,“時期尚早”の拭えなくなってきていた

デライト従来の個人知識管理サービスとは桁違い情報扱える」という趣旨発言をしたところ,その意図全く理解出来なかった一部界隈から怒られるという,今となっては笑い話のような出来事N10K 騒動もあったが,最近Notion小さな流行にも考えさせられることが多かった

綺麗仕組み作り楽しい評判Notion は,個人知識管理においてはどちらかというと初心者向けツールだ。

よく,「勉強が出来る人ノート意外と汚い」などと言われるが,個人差はあれど,その傾向があることに不思議はない優れた記録術というのは,自分にとって必要な情報的確かつ効率的に記録して取り出せる技術であって,それは他人から見て綺麗なものではないことが多いそれどころか自分の理性反するものであったりもする。

読み込み中...
{開発}{開発記録}{}{希哲17年2月23日の副日記}{上手く動かない}{完璧に近い}{固定可能部分}{固定検索窓}{.foc}{共通化出来た}(98)

{希哲17年2月23日の開発 K#F85E/E74C-8E7D}

全知検索窓固定機能実装一段落させた10歩出振るい手定め済み

ここまでの調整基本的な挙動満足出来るものになっていたため,吊るし輪郭新規描出フォームへの輪結加え仕上げとした。概ね1月15日18歩検討通りだが,当時の案よりも小振りにすることで幅狭領当てかどうかや吊るし輪郭有無によらず装体共通化出来た吊るし輪郭無い場合上矢印グレーアウトさせつつ,ページ最上部への移動という機能残すことで無駄余白にしないようにした。結果として当初想定よりも交度用合い両面単純かつ安定感のあるものになった。

予定通り幅狭領当てでは入力欄への捕活追加輪結類隠すようにした。#sch:focus-within でも使えばかと思ったが,輪結への捕活拾ってしまい上手く動かないためスクリプト.foc付けるようにした。

固定機能実装当初iOS Safari固定時捕活固定検索窓一瞬隠れる問題悩まされたが,このあたり挙動iOS Safari 特有問題として有名らしく,固定検索窓のある他のサイトでも同じなので,こういう視覚効果なのだと思うことにした。他にも,ページ最上部上スクロールすると全知検索窓固定可能部分浮き上がるなど妙な挙動があり,最初捕活スクロール関係独自仕様由来する不具合かと思った

それ以外全体としてほとんど完璧に近い感触になっている。


ほかダークテーマ装体調整2歩不具合修正3歩

{開発}{開発記録}{最悪}{最大}{}{十分}{知番}{サービス}{希哲16年7月}{希哲16年6月}(238)

{希哲16年9月18日の開発 K#F85E/E74C-5BA7}

新生全知検索整備

最初の中間出振るい成功これにより全知検索応答速度柔軟性交度品質大きく向上した出振るい作業円滑に進み,手溢れ無く全体として大成功だった。

輪郭情報取得改良

まず,期待通り輪郭情報取得方式改良により応答速度大きく向上した体感的にもこの種のサービスとしてはという程度から,はっきり速い言える程度になり,快適度数段上がった感覚がある

これまでのデライト高速化施策の中でも最大級の効果感じるが,これはボトルネック解消によるところが大きい6月Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果大きさ比べて本番環境での効果かなり小さい感じるようになっていた。考えられるボトルネックは,相振り出場間の通信回数多過ぎる輪郭情報取得処理だった。

これまでページ表示される輪郭情報の取得は,相振りから大体流れ行っていた

  1. 輪郭隠しにない吊るし輪郭があれば輪郭情報取得するdg_oln()
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
  2. 輪郭一覧輪郭情報取得するdg_fnd() か,吊るし輪郭初期状態dg_fg()dg_bg()
  3. 各輪郭自我情報前後景輪情報個別に取得する
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
読み込み中...
{開発}{開発記録}{文字}{知名}{描写}{複製輪郭}{デライト}{描写下見機能}{描写部}{希哲16年5月18日}(117)

{希哲16年5月18日の開発 K#F85E/E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

読み込み中...
{先入観}{}{知名}{描写}{デライト}{デライト(なんでもメモ)}{引き入れ}{デライトの使い方}{新生デライト}{難しい質問}(57)

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

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

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

引き入れについて

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

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

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

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

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

読み込み中...
{進捗記録}{}{}{}{全角}{}{}{見出し要素}{描写}{記号}(248)

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

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。
読み込み中...
{デラング}{進捗記録}{進捗}{描写下見機能}{希哲16年2月2日}{まとまりそう}{設計の中心}{留めたい}{加えていく}{開いて欲しい}(96)

{希哲16年2月2日12歩 K#F85E/E74C-6AB3}

進捗時限記録中略

コンマ駒手について考えたついでに,描写選り手についての再確認再検討終了

現状開閉式選り手は,やはり気に入っている部分でもあり維持するしかなさそうだ。閲覧編集にはそれぞれ最適な用合いがある。

そして,この描写選り手はやはり <textarea>近い単純なものが良いWYSIWYG 選り手多機能化すればするほど挙動好き嫌いも出てくるし,多様な入力環境対応出来ない場合も出てくる。高い実装コストの割に失うもの大きい

そもそもデラングのような軽標記言語役割普文読み書きしやすくすることであり,そこはデラング頼っていい

換配後編集支援部品単位編集という考え方出来てから基本的にはこの方針だが,最近下見機能も含めて輪郭選り手全体像はっきりしてきたこともあり,現状単なる <textarea>描写選り手加えるべき機能見えてきた

中途半端になる懸念から,全く機能加えないという選択肢もあった。ただ,これは問題の方が大きくなりそうだ。例えば,無番輪符書いてから下見完了して輪郭小窓調整するというのは,現実的に考える煩雑過ぎる。やはり,その場で輪郭小窓開いて欲しい

ただ,昔から考えてきた輪符折り畳みといった機能加えない。こういった部分は,せいぜい色付け輪結化留めたい。このあたりは部品単位編集との使い分け考えながら,あくまでも単純性保守性損なわない範囲で,デラング編集支援としての機能加えていくことにした。

部品単位編集も含めて,デラング設計の中心据えることで上手くまとまりそうだ。ここでもデラング整備大きな意味を持ってくる。

{単純}

{}