(42)
{希哲14年10月17日の開発}{希哲14年10月17日の進捗時限}{希哲14年10月17日の進捗}{希哲14年10月17日}{装体}{ドラッグイメージ}{進捗記録}{進捗時限記録}{進捗時限}{知名}=}(13)

デライト用合い改良

途中で終了。

ドラッグイメージ装体を見直し。知名がある時に知番を表示しているのは余計か。

2020-10-17 18:11
=}
{希哲14年10月2日の日記}{左寄せ}{希哲14年10月2日}{デライト用合い改良}{領当て}{text-align}{右寄せ}{知名}{知番}{Flexbox}=}(15)
{希哲14年9月16日の開発}{使いにくい}{整備不足}{パスワード再設定}{流入元}{登録者}{デライト用合い改良}{入門者目線}{希哲14年9月16日の進捗時限}{希哲14年9月16日の進捗}=}(106)

急遽当面の作業方針を見直し,短期集中生活前倒しで今日から始め,入門者目線でのデライト用合い改良傾注することを決めて終了。

新規利用者登録順調に増えているにもかかわらず,一度も描き出ししない登録者や,描き出ししても知名描写空欄のまま一つだけ,というような不思議な登録者が多いことが気になっていたが,13時過ぎ,あるツイートを見つけて理由が分かった。想定以上に諸場から登録してくれる人が多いらしい。

現状,デライトタッチ操作はかなり等閑状態であり,初見ではまず十分に使えない。

デルンがもともと個人機主要な対象にしていたこと,個人知識管理サービス市場調査スマホアプリ不満を抱える用者が多い(つまり主要な環境ではない)と気付いたこと,「使い方」や主要な流入元@Dlt_jp では個人機向けの説明だけにしていたことなどで,大半の登録者個人機で使うことを想定して来たのだろう,という完全思い込みがあった。

しかし,すでにデライトは市場戦略から宣伝手法まで多数派向けに舵を切っており,当然ながらスマートフォン等からの流入を想定しておくべきだった。この不整合は見落しだった。時間節約のため握接状況は最低限の指標把握しており,握接録分析不足痛感した。

かといって個人機での用合い完璧なわけでもなく,入門者目線で見るとあちこちに落とし穴がある。いずれにせよ総見直しが必要になる。

8年以上ものあいだの経験で,開発者自身が個人知識管理熟達していることはデライト長所だと思っていたが,これが驕りになっていた気もする。なまじ使えている人間がいるせいで「分かりにくい」とは言えても「使いにくい」と言えない雰囲気を作ってしまっていたかもしれない。

急遽当面の作業方針を見直し,アイコンの設定,パスワード再設定までは実装するつもりで作業中だった利用者設定中断諸場用合いも含めたデライト用合い改良最優先で取り組むことにした。幸い,引き入れボタンの活用で諸場用合い全体像は出来ている。ボタン式引き入れ方式実装を終えれば,細かい調整がほとんどだろう。

18日から始める予定だった3日間短期集中生活を今日から前倒しで始め,この期間で入門者目線障害になる用合い上の問題を全て取り除くことを目指す

使い方」など文書整備不足もあるが,いずれにせよ画面撮りなどを考えれば用合いから着手する以外にない。

この間,デライト宣伝一時停止することにした。注意書きした上での宣伝も考えたが効果は疑わしく,この短期間なら用合い改良集中した方がいいだろう。

手痛い気付きではあったが,ぼんやりしていた最後の壁正体が掴めたのは大収穫だった。これを乗り越えればデライトの成功はすぐそこだ。

2020-09-16 20:27
2020-09-16 18:24
{希哲14年7月30日の開発}{希哲14年7月30日の進捗時限}{希哲14年7月30日の進捗}{希哲14年7月30日}{輪郭名}{使い方}{描き出し}{進捗記録}{進捗時限記録}{進捗時限}=}(18)

使い方」を少し見直して終了。

入門者向けの説明としては輪郭法用語を詰め込み過ぎているのが気になる。

知番は最重要概念であり K# や KNo といった表記の意味を理解するのにも重要なので仕方ないとして,知名は「輪郭名」で十分だろう。

吹き出し」も,一見して複雑過ぎて普通の吹き出しではないが「吹き描き」というのも分かりにくい。ここでは「描き出し」で十分だろう。

2020-07-30 15:09
2020-07-30 15:09
=}
{吹き描き}{右吹き描き}{希哲14年7月18日の開発}{あれ}{逆さ右吹き描き}{逆さ左吹き描き}{上下反転}{左吹き描き}{左右吹き描き}{用合い設計}=}(73)

朝から前後景輪一覧領当てについて本格的な検討を始め,およそ6歩分かけて昼過ぎには概ね方向性が定まった。これで,デライト用合い設計にも死角がほぼ無くなった。

まず,6月30日の開発で検討していた,吹き描き前後景部の所定件数越えを「...」で表現し,そこから一覧に飛ばすという案は,一旦白紙とすることにした。一覧ではなく,知名だけざっと確認したいという場合が考えられるためだ。動的にただ追加するのではなく,所定件数以内で表示範囲を切り替えていく,というのであれば領当てを壊すこともない。

輪郭一覧ページ付け動的追加を検討してきたが,かえって重くなったりする懸念もあるため,いったん画面遷移で実現することにした。表示は一覧の左上と右下に ...上下矢印,ページ番号を組み合わせる形を検討。現状,録落ちボタンを使っているため紛らわしいが,これはすでに利用者情報ページに移動することを決めていたため無視していい。細かいことは実装しながら試行錯誤していく。

前景一覧については,4月14日7歩考案した逆さ吹き描き踏襲するが,最上部だけでなく一覧の各吹き描きも逆さにしてみることにした。

引き入れボタン引き外しボタン実装する上で,引き入れ状態をどう表現するかという問題もあったが,これも一応の目処が付いた。結局,くぐった輪郭と輪括関係にない輪郭線点線に変え,中景部と上にくる前後景部白煙色を入れ替えるとそれなりに見えることが分かった。この時,全て白煙色にしてしまうとぼやけ過ぎて視点が定まらないため,注目させるべき前後景部のみ白にする。これに加え,ボタンの状態が変わっていれば十分区別出来る。

他の案として,左右反転も脳裏をよぎったが,やはりこれは自他の区別に使うべきとして廃案。横にずらすなども,横幅に余裕のないスマートフォン等の端末を考えれば普遍性が無い。吹き描きはその輪郭を認識するために必要な情報が凝縮されているため,何らかの省略表示を取ることも出来ない。というわけで,表示位置・表示形式は変えず,輪郭線色彩ボタンの3要素に特徴を持たせることで輪括関係を表現するのが最良という結論になった。

引き入れボタン引き外しボタンは現状ですでに表示されている =} 形のボタン活用し,可能な限り単純性を保つ。

ついでに,輪郭をくぐった状態での検索挙動についても整理。現在,吹き描き内部の検索窓は全体検索になっているが,これは本来輪括関係のあるものに限定して検索するのが直感にかなっている。そこで,くぐっていない状態で最上部に表示されている検索窓をくぐった状態でも表示し,そこを全体検索として使い分けることにした。画面遷移時にページ内輪結で隠せば,必要な時だけ出てくるように出来る。最初は検索窓を画面に2つ表示するのは美しくない気がしたが,かといってチェックボックス検索語の特殊記法を導入するのが美しいとも思えない。これが一番直感には適っているだろう。

ここで,自他の区別に使うことを想定していた左右吹き描きもその方針確定した。

これを機に,4種の吹き描きに厳密用語を与えておくことにした。現状の左眼形を「左吹き描き」とし,左右反転させたものを「右吹き描き」,両者を併せて「左右吹き描き」と呼ぶ。さらにこれを上下反転させたものを「逆さ左吹き描き」「逆さ右吹き描き」と呼び,併せて「逆さ吹き描き」と呼ぶことにした。

2020-07-18 19:31
2020-07-18 15:06
{希哲14年7月16日の開発}{希哲14年7月16日の進捗時限}{希哲14年7月16日の進捗}{希哲14年7月16日}{手定め}{選り手}{描写欄}{溶暗}{不具合修正}{Aejs}=}(32)

知名変更時の不具合修正続き。

いったん終了。

一通り手定めし,問題ないように見える。かなり無駄の多かった Aejs 間の通信を大きく整理したので,保守性向上

ついでに,ずっと気になっていた描き直し時の挙動も大きく改善した。

これまで,描写欄保存すると一瞬で選り手が消え,一瞬描写ソースが見えた後で正しい表示に更新されていた。これも Aejs未整理原因だったが,今回,選り手が溶暗してすぐに正しい表示で更新されるようになったため,描き直し時のごちゃごちゃした違和感が無くなった。

2020-07-16 19:32
2020-07-16 19:25
=}
{希哲14年7月16日の開発}{希哲14年7月16日の進捗時限}{希哲14年7月16日の進捗}{希哲14年7月16日}{描写記法}{不具合修正}{進捗記録}{進捗時限記録}{進捗時限}{知名}=}(17)

描写のある状態で知名を変更すると描写記法を除いて更新されてしまうというひどい不具合を発見。

原因理解したので修正に入る。

途中で終了。

2020-07-16 19:23
2020-07-16 17:23
=}
{あれ}{メール配信}{攻撃動機}{暗証語忘れ対策}{希哲14年7月16日2歩}{暗証語}{暗証語忘れ}{希哲14年7月15日}{新ダブルクリック方式}{本文}=}(57)

細々とした不具合修正装体調整,これまで単独で更新出来なかった知名欄新ダブルクリック方式対応などがよく捗り,全体的にデライト洗練された。

また,これまでスクリプト不具合で再編集時に知名として混入してしまっていた代置語「あれ」逆手に取り無名輪郭検索や間もなく実装予定の本文抜き出し表示の抑止活用することを考え始める。

また,描出公開原則採用してから間もなく懸念するようになった暗証語忘れ対策についても再検討し,結論として,相応の個人情報保護体制が整うまでは注意喚起に留めることにした。

デライト宣伝再開の前に,暗証語忘れをした時のため,任意メールアドレス登録出来るようにするつもりだったが,これもいくら任意とはいえ用者が増えてくれば重要情報蓄積しかねず,サービスへの攻撃動機を高めることになる。当然,メール配信手続き実装保守にかかる手間暇現状では馬鹿にならない。それに足を引っ張られデライト収益化失敗しては元も子もない。

その他方法も一般的なものから絵鍵を利用するものまで検討したが,どれも費用対効果は疑わしい。描出公開原則によって折角身軽運用可能になっているのに,中途半端になってしまう。

そもそも,全ての輪郭公開されている以上,仮に暗証語忘れをしても再編集などの操作が出来なくなるくらいのことで,情報共有可能な状態で残っている。

用者には最低限録入り状態での暗証語再設定機能を提供して,体制が整うまでは暗証語忘れに気を付けてもらい,万が一忘れてしまった場合は新規利用者登録しなおして,新しい利用者番号で以前の輪郭再利用することを推奨する,という方針を固めた。

また一つ,重荷を減らせた。

2020-07-16 16:09
2020-07-15 10:30
{希哲14年7月15日}{希哲14年7月15日のツイスト}{輪郭名}{知名}{ツイスト}{「描写」}=}(6)

輪郭名知名)の変更も描写欄と同じ感覚で出来るようになっているはずです。

2020-07-15 23:07
=}
{希哲14年7月15日の開発}{希哲14年7月15日の進捗時限}{希哲14年7月15日の進捗}{希哲14年7月15日}{新ダブルクリック方式}{知名欄}{新規描出フォーム}{進捗記録}{進捗時限記録}{進捗時限}=}(14)

知名変更を描写編集と同じ挙動にする作業。

とりあえず,何とか変更出来るようにはして終了。

ついでに,新規描出フォームでも知名欄新ダブルクリック方式に対応。考えてみれば,これまで知名だけを入れて描出するのに不便だった。

2020-07-15 22:47
2020-07-15 21:55
=}
1