{成功観}{}{}{}{}{}{前後}{一日一文}{サービス}{希哲17年8月}(276)

{私の成功観 K#F85E/0758-C044}

長期安定体制じっくり構築するため,6月7月半ば夏休み気分過ごしていたが,8月からは気持ち切り替えてデライトの完全な成功希哲館事業の成功向けて調子を上げていきたい

そんな8月最初の一日一文題材には,私自身成功観についてが相応しいだろう。そもそも私自身がこの希哲館事業何を目指しているのか,改めてこれまで以上に明確に記しておきたい


さて,「デライトの完全な成功」というのは希哲館事業における目下最大の課題だ。

人気があるサービス必ずしも幸福なサービスではない,というネットサービス開発運営難しさ旧 Twitter騒動広く知られるようになった。もっとも非業界人にも分かりやすくなっただけで,全く問題を抱えていないサービスほぼ存在しないというのが業界実態だ。

デライトは,集客成功していない除けばあらゆる意味極めて上手く行っているサービス言えるデライトの不完全な成功。これが「デライトの完全な成功」という表現多用している理由だが,ではなぜデライト集客成功していないのだろうか。よく考えてみればそう不思議なことでもない。

多くのサービス当然ながら営利目的なので,集客第一考えるすぐに利益出なくても金の卵」である利用者数伸びれば投資集まる。その過程で,無理な資金繰りをしたり,人間関係権利関係しがらみ作ったりいわゆる技術的負債積み上げてしまったり,構想として小さくまとまってしまったりする(これが日本人一番多いそうしなければ生き残れないからだ。デライト場合幸運なことにそうしなくても生き残れてしまった集客最後回せた稀有なサービスなのだ。

デライトその完全な成功何のためにあるのかといえば,希哲館事業の成功ためだ。デライト背景としての希哲館事業については「デライトの歩み」にもざっと書いたが,日本かつてのイギリス産業革命越えるような知識産業革命起こして米中大きく凌ぐ極大国ハイパーパワー成長させ日本盟主とした自由民主主義究極形希哲民主主義によって世界中権威主義体制打倒によって万人自由平和享受出来る世界作り上げることが希哲館事業目的であり,最終的な成功だ。

これが実現出来なければ世界一の大富豪になろうが自分は「失敗者」である,というのが私が17歳頃から引きずってきた呪縛のような成功観だ。

読み込み中...
{方向}{}{}{}{}{一日一文}{サービス}{希哲17年2月}{希哲17年7月の一日一文}{時間がかかり過ぎている}(204)

{X(旧 Twitter)はなぜライトモードを捨てたかったのか K#F85E/0758-FB71}

昨日X旧 Twitterダークモード以外配色モード廃止するイーロン・マスク氏が表明し反対意見殺到するという騒動があった。結局ダークモードデフォルトにしてライトモード一応残すという方向軟化させたようだ。

デライトでは,今年2月ダークモード(ダークテーマ)対応実現したばかりなので,個人的に色々思うことがあった。前回予告した KNS についての文章時間がかかり過ぎているため,今回の一日一文つなぎとして,開発者の視点からこの騒動背景について書いてみたい


デライト元々明るい配色いわゆるライトモードのみでやってきた大きな理由一つに,イメージ問題がある白背景基本としたデザインにはやはり明るく清潔印象がある。サービスメディア紹介されるなど,イメージ戦略考えるとこれは馬鹿にできない

個人的には黒背景好きだが,この種のネットサービスではどうしてもアングラ感出てしまう背景色微かな灰色にすることも試したが,白背景比べるちょっとくすんだような,地味印象になってしまう。なるほどダークモード流行しても大手サービス多くデフォルト眩しい白背景採用している理由はこれかと思ったものだ。

今年2月満を持してダークモード対応完了し,テストがてらダークモード常用していた時期がある。最初新鮮さもあって,それこそダークモードだけでやっていけそう気がしたが,慣れてくると,眠気が強くなったり,いまいち調子が上がらないことに気付いて結局ライトモード常用する生活戻った

ライトモードダークモードも,どう感じるかは個人差環境差によるところが大きいどちらかが万能だと思ってしまうのは,単純な経験不足なのだろう。今回の騒動は,ソフトウェア開発におけるマスク氏の経験不足と,新しいロゴ象徴される偏った趣味起因する出来事とも言える

ただもう少し踏み込むと,マスク氏をこの拙速追い込んだ X切実な開発事情見えてくる

配色モード追加維持というのは,見かけよりずっとコストかかる例えば外観絡むような機能追加をしたそれぞれの配色モード問題生じていない確認する必要があるし,問題があれば個別に調整する必要があるそして,このコストは,既存のコード保守状況ければ悪いほど,変更程度多大であればあるほど高くなる

読み込み中...
{『希哲日記』}{}{日記}{}{}{}{文字}{KNS}{デライト}{それなりにいる}(157)

{希哲17年4月14日の日記 K#F85E/E74C-A703}

脳爆発おかげで検討作業では大きな収穫があったが,思考広がり過ぎたか。サイクリングそれなりに身体を動かしたにもかかわらず脳疲労感が強かった他にちょっとした幸運があり,少し気が緩んだことも影響しているかもしれない。


最近ちょくちょくKNS の経済的合理性」について考えている考えれば考えるほどKNSSNSPKMS相補的相乗的発展形であると同時に経済的合理性において唯一の解だと思えてくる

SNS経済的な問題は,「献典の質」にある。開放的にして人を集めると,どうしても粗悪な献典増えるそもそもSNS における投稿体験のための手段過ぎないことが多く献典としての情報価値が低い

日常的な挨拶から「バルス祭り」まで,情報としての意味はない出与え抱え過ぎている砂金のために土砂全部保管しているようなものだ。意味がないだけならともかく不法行為デマのようなものも誘発する構造持っているのも厄介だ。放っておけば広告主が減るし,監視を強めれば人件費が増えるかつての匿名掲示板同じ問題抱えていたが,文字という最も軽量情報でありながら維持費収益追いつかない理由だ。

他方PKMS では,知的関心献典蓄積され利用者自然と内省的になるので献典の質治安総じて良い

ただ,PKMSとにかく高コスト体質」になる。まともに開発しようとすれば,厳重な制危情報保護体制複雑な WYSIWYG 選り手自動保存編集履歴オフライン対応ゆとりのある譜類上信機能あたりは基本として,OCR人工知能くらい付いているのも当たり前なりつつあるデライトがこれらの機能上手く切り捨てられているのは,やはり KNS という根想によるところが大きいどれも SNS なら必要性が低い

しかもPKMS閉鎖的なサービスなので収益化手段限られ広告宣伝費まともにかかるEvernote にせよ Notion にせよ,SNS比べると規模的に伸び悩み状況にある。

そこで KNS たるデライト出番というわけだが,KNSKNS で「新し過ぎ理解してもらうのが難しい」という問題抱えている逆に言えば,ここさえ突破すれば SNS の次PKMS の次同時に創出出来るSNSメモ通類として使っているPKMS情報発信使いたいそれなりにいるので,突破口確実にある

これが目下デライトの闘いだ。

15日振り返り日記

{進捗記録}{十分}{}{描写}{進捗}{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{良いばら成し}{排除した}(206)

{希哲17年1月22日17歩 K#F85E/E74C-EFB2}

進捗時限記録中略

輪郭ページ改良装体調整終了

取り急ぎテンプレート整理して輪郭ページ吊るし輪郭入れていた要素<header> から <main> へ,輪郭ページ輪郭一覧<main> から <div>切り替えた前後景一覧ページでは従来通り

特に急ぎたかった部分上手く片付き残る内部的な問題のみなので,輪郭ページ改良ここで中断することにした。


閲覧専用模動実験をしていた時,輪郭ページ輪郭一覧隠す<header> だけのページになってしまうことに気付いたのが事の発端だった15日14歩

あまり意識してこなかったが,輪郭ページ概念実装大きな不一致生じていた一時凌ぎつもり後景一覧ページ輪郭ページ使うようにしたのはデライト離立補完中の希哲14年8月5日だった。当時とでは輪郭ページ捉え方輪郭充実度全く違う

予てから検索模動輪郭模動内部的な切り分け中途半端なまま進んでいない問題もあったため,抜本的な輪郭ページ改良方針まとめた17日8歩

最近の検索演心そこまで神経質ではないと言っても,<header><main>違い流石に小さくないだろう。何より気付いてしまう表現として気持ち悪いので早く解決したかった

読み込み中...
{進捗記録}{希哲16年}{進捗}{デライト}{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{希哲17年1月15日}{下がれば}{済みそう}{かからず}(118)

{希哲17年1月15日6歩 K#F85E/E74C-C29A}

進捗時限記録中略

新生デライトの要件ではなかったが,デライト最初期実装削除してからずっと保留状態にあった全知検索窓固定機能実装イメージ急速に固まったのでまとめ終了

全知検索窓では,下スクロール隠れ上スクロール現れる固定表示採用することにした。

昨日寝る前に Android 版 Chrome触ってい思いついた上スクロールツールバー現れる以前にもこの方式検討した記憶があるが,その時流してしまった昨年新規描出フォーム固定機能とともに大きく検討を進めたことがあった開発記録ので,時期的噛み合わせだろう。


いったん削除した理由その後復活させられなかった理由主に二つあった。

一つは,広告との相性問題だ。AdSense では広告固定メニューのようなものが被ることもグレーとされている。実際には悪質でなければそこまで厳しく対応されることはないだろうが,広告頼みデライトではわずかなリスクでも避けたかった

もう一つは,画面広く使いたい場合邪魔になることがあり,必ずしも便利ではなかったことだ。当然スマートフォンのような小型端末ではこの問題顕著になる

昨年検討では,広告近付いた隠すようにすることと,表示領域の高さ十分ではない場合固定機能無効にすることでこれらの問題回避する方針固め復活向けて一歩前進した。しかし,実装調整煩雑さ対して必要性高まらずここまで実作業至らなかった

今回採用を決めた方式なら,調整手間ほとんどかからず交度半分くらいで済みそうだ。無くてもそこまで困らない機能ではあるが,これくらい実装コスト下がれば優先順位上げられる

{開発記録}{}{コード埋め込み記法は一口に言って発明}{希哲17年1月13日の副日記}{普通の開発者}{GitHub 開発者よりデライト開発者の方が賢い}{言語開発者}{かくあるべき}{考案した}{一年近く前}(73)

{希哲17年1月13日の開発 K#F85E/E74C-E8CD}

{理由}

{}