{希哲16年1月19日}{デラングの文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}...=}(94)

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

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{一日一文}{デライト}{デライト市場戦略}{}{希哲15年5月の一日一文}{あれ}{システム設計}{Notion 一強}{Notion の流行}{対 Notion 戦略}...=}(59)

{デライトの対 Notion 戦略 K#F85E/E74C-4A71}

デライト市場戦略では現在,対 Notion 戦略最重要視している。

もっとも,“個人知識管理サービス”あるいは“高機能メモサービス”に分類されるようなサービスがいま対 Notion 戦略を最重要視していないとしたら,それはそれで問題だろう。それほど Notion の勢いは他を圧倒している。

では,個人知識管理サービス市場はこのまま Notion 一強に落ち着くのだろうか。私はそれも違うと思っている。Notion の勢いを上手く利用して,台頭してくる“次”が十分にありうる。その位置に誰がつくか。これこそ,今この分野で行なわれている最も重要競争だ。


昨年,本格的な市場調査を始めてから間もなく,デライトでは対 Roam Research 戦略中核とするようになった。Roam Research階層構造ネットワーク構造統合しようとしている点でデライトに似ているように思えた。

その後,Roam Research がやや伸び悩みがちになってしまい,代わりに Notion急速人気を集めるようになった。

実は,当初デライト市場戦略では Notion をほぼ完全に無視していた。多機能主義的な Notion に対して,「最小高機能主義」を志向するデライトは全くの別物に見えたからだ。お互い,全く違うところを目指しているのだから,競争することもあるまいと思っていた。

しかし,これまで話題性に乏しかった個人知識管理サービスという分野で,Notion の流行利用しない手はない。そこで,Notion とデライトの違いを上手く使って売り込む戦略を考えるようになった。


Notion に対する熱狂はそう長くは持たない,と私が考えている主な理由に,Notion の「」がある。

Notion は自分だけの型を作れるサービスだ。それが楽しいという人も多いし,そこで躓く人も多い。自分の思い描いていたように情報管理出来る……Notion が実現したこの「」が,実は個人知識管理という観点からは落とし穴になる。

(なぜ落とし穴になるのか,というのは一日一文で語り尽くせることではないので,なぜに型が無いのか,なぜシステム設計難しいのか,といったことから各々考えてみて欲しい)

それに多くの人が気付く時は必ず来ると思っているが,それがいつになるのかは分からない。早くとも数年はかかるかもしれない。結局,そんなことは自分で実践してみて,にぶつからなければ分からないことだからだ。

ただ指をくわえて待っているわけにもいかないので,デライト山積する課題を片付けながらその時を待ちたい。

{一日一文}{デライト}{柔品開発}{第三次宣伝攻勢}{第二次宣伝攻勢}{第一次宣伝攻勢}{宣伝攻勢}{開発}{14ヶ月}{半年以上}...=}(60)

{デライト第三次宣伝攻勢開始に思うこと K#F85E/E74C-69D3}

今日24日デライトは「第三次宣伝攻勢」を開始した。簡単に言えば,3度目積極的な宣伝活動を始めたということであり,裏を返せば,デライトには積極的に宣伝活動をしていない時期があるということだ。

デライトは,昨年2月13日に一応の正式離立リリースを果した。ただ,品質上の問題が多々あったため,しばらくの間はほとんど宣伝しなかった。

本格的な宣伝活動を開始したのは,半年以上経った9月8日だった。それも16日にはいったん停止した。これが「第一次宣伝攻勢」だ。「第二次宣伝攻勢」はその約一ヶ月後,10月20日から今年1月29日まで続いた。

つまり,正式離立から14ヶ月余りのうち,積極的な宣伝活動をしていた時期は,合わせて4ヶ月にも満たない。これは改めて計算してみて自分で驚いた短さだ。もう半年くらいにはなると思っていた。それだけ濃い日々だったのだろう。


デライト宣伝にこうした緩急があるのは,その時に最善時間配分を考えた結果だ。限られた時間有効に使おうと思えば,「時間対効果最大化」を常に意識する必要がある。

当然ながら,私は開発経営デライトに関する全てのことを自分でしているので,宣伝活動だけに時間を使うわけにはいかない。ひたすら宣伝して人を集めたはいいが肝心の製品に十分な魅力が無い,というのでは意味も無い。

これは宣伝に限ったことではない。デライトには問題山積している。あってしかるべき機能は色々欠けている,不具合はあちこちにある,文書もろくに更新していない……だが,全てを最初から整えられる人間はいない。限られた時間の中で,優先順位を付けて一つずつ片付けていくしかない。

そして,時間対効果の最大化を考えると,宣伝にもある程度「溜め」が必要であることに気付く。同じだけの時間を使うのであれば,より品質の良い状態で製品を知ってもらった方が良いわけだ。

ひっそり開発を進め,ある程度品質自信が出来たところで宣伝攻勢をかける。その反応次第でまた開発中心の時期に入り,課題が概ね解決出来たところで宣伝攻勢をかける……最初からこういう計画だったわけではないが,結果的にこの繰り返しデライト自体は順調に来ている。一定の合理性はあったということなのだろう。

柔品ソフトウェア開発における風林火山といったところか。

{山積}

{}