Jump to content

KakiShibu

Level 2
  • Content Count

    40
  • Joined

  • Last visited

Everything posted by KakiShibu

  1. Macクライアントは、Snow Leopardのときはどうしたらこんなに遅くなるのか不思議なくらい遅いかった。 特に、  ・ノートの切替  ・ノートブックの切替(特に数千個のノートを含むノートブックへの切替は30秒以上かかることも多々ある)  ・タグの選択 こういう切替が本当に尋常じゃないくらい遅かった。 ところが、Lionにバージョンアップした途端、まーまー普通に切り替わるようになった。 Snow LeopardパーティションからLionのEvernoteを起動してみました。 すると、初期同期が始まって、何時間もかかりそうなので中止。 そこで、Lionパーティションの ./Library/Application Support/Evernote/data をシンボリックリンクしてみる。 Evernoteを再起動したら、ノート総数が5905個となって一応成功したようだが、 そこからアクティビティー表示で、Evernoteと同期中・ノートの変更内容を計算中...となって、時間が相当かかりそう。 ./Library/Application Support/Evernoteをシンボリックリンクしたほうがよかったのかな? と思って、やってみたら、Evernoteを起動すると、ファイルが無効というパネルが出て、すぐに終了してしまった。 再度、./Library/Application Support/Evernote/dataをシンボリックリンクした。 その状態で、数千個サイズのノートブックの切り替えてみると、やはり、30秒から1分くらいかかる。 つまり、Snow Leopard絡みのバグということが分かる。 Snow Leopard自体にも問題があるのかもしれない。 とりあえず、LionではSnow Leopardのような異常な遅延が起きないので、Lionにバージョンアップして良かった。 ただし、日本語入力による遅延・文字化けは、相変わらずで、これは何とか改善してほしい。 もう1年半以上直っていないので、そろそろ何とかしてほしいですね。 これはOSの問題ではなくて、Evernoteのバグなのは明らかなので。
  2. 更新日でソートを基本にするか?、作成日でソートが基本か? どっちにしても、 並べ替えたときに、一覧に表示していたそのノートが一覧から見えなくなってしまうのが、一番のバグですね。 何千個もノートが入っていると大変です。 並べ替える1つの理由は、そのノートの前後のノートも見たいからです。 このバグのために、並べ替えを多用できない。 たまに更新日でソートすることがありますが、このバグが嫌になって、並べ替えをしたくなくなってしまいます。 これ以外にもスクロール制御には機能不足・バグが多々あって、使い心地を悪くしていますね。 どんな新機能よりも、こういう基本機能を充実させるのが先決でしょう。
  3. リンクのみあるいはそれを含んだ前後の文字を選択して、 リンクを含んだ文字をペースト(上書き)すると、 その位置の右側にあった文字(行末までの文字)が一緒に消えてしまいます。 さらに、Command+Zで元の状態に戻らない、というバグも併発しているので、より深刻で致命的です。 -------- よくあるケースは、ノートのリンクを書き込んだノートをコピーして、中身を書き換えるとき、 その中に含まれるノートのリンクを別のノートへのリンクに書き換えるときです。 今回調べてみたら、通常のリンクでも同様です。 今まで気付かなかったのは、普通のURLリンクを別のURLリンクに書き換えることは滅多にないからです。 ノートのリンク機能が追加されて、これを頻繁に利用していますが、 上記のようなノートのコピーとの組み合わせで使用することがよくあるので、 このバグに気づきました。 もちろんEvernote Web(Firefox)では全く問題なくペーストできるので、明らかに、Macクライアントのバグです。 早急に修正してください。 --------------------- 例えば、   あいうえお[リンク]かきくけこ という行がノートに書いてあるときに、 (1) [リンク]を選択してコピーして、そのままペーストすると、     あいうえお[リンク] のように、行末までの文字が消えてしまう。 別のリンクをコピーしておいてペーストしても同様ですが、テストしやすいと言う意味で同じものをペーストしてみたわけです。 (2) 「[リンク]かき」 のように文字を含めてコピーした場合、  (2-1)[リンク]かきの部分にペーストすると、     あいうえお[リンク]かき  のように、行末までの文字が消えてしまう。  (2-2)[リンク]の部分を選択してペーストすると、     あいうえお[リンク]かき  のようにやはり、行末までの文字が消えてしまう。  (2-3)[リンク]の前半部分を選択して、ペーストすると、   あいうえお[リンク]かき[ンク]かきくけこ  のように、これだけは正しくペーストできますが、こういう使い方は普通はしないので、無意味。 (3)「えお[リンク] 」をコピーしたもの、「えお[リンク]かき」をコピーしたものも全く同様 つまり、リンクを含んでいるペーストボードのデータをペーストするとこの不具合が起きると言うことです。 (4)もう一つのバグは、このような、行末までの文字が消えてしまった後、元に戻そうと思って、Command+Zを入力すると、例えば、(2-1)のケースで言えば、     あいうえおくけこ のように、元のリンクが消えてしまいまい、元に戻せなくなってしまいます。 文字「かき」の部分が元に戻らないのも不思議ですね。 これは間違ってペーストしてしまった場合に救えないということなので、致命的です。 少なくとも元に戻るように修正してください。 Evernote for Mac Version 2.2.1〜3.0.0 Beta 2
  4. (要望) 1年以上もの間放置し続けているこのような致命的なバグを最優先で修正願います。 要望と言うより、自ら、気付いてとっくの昔に修正しておくべきバグなので、 新機能を追加する前に、こういう基本的で重大なバグの修正を優先すべきであるということを肝に銘じてほしい。 もはや失われたデータは事実上修正できませんが、 少なくとも、ローカル側の作成日とサーバー側の作成日の値が異なる場合は、 ローカル側の作成日値を使って、サーバー側の作成日に上書きするというルーチンを加えることが必要です。 そうすれば、今後クリーンインストールをしても、悪影響を及ぼすことは最低限防げるようになるからです。 (バグの内容) ノートの内容やノート名を変更すると、「同期ステータス」に●マークが付く。 あるいは、更新日を手動で変更しても、「同期ステータス」に●マークが付く。 ところが、作成日を手動で変更しても、「同期ステータス」に●マークが付かない。ここが致命的なバグ。 明らかに、作成日の動作はインプリメント漏れです。 (バグの甚大な影響) これはEvernoteが日本語化された時点から(それ以前も含めて?)のバグです。 そのうち修正されると思っていましたが、1年以上経っても修正されません。 全く気付いていないのか、単に後回しになっているだけなのでしょうか? 1年以上もの間放置しておいていいようなレベルのバグではないと思う。 更新日を手動で変更するニーズは普通ありませんが、作成日を手動で変更している人は多いので、 意図しないインプリメントとは言え、この逆であればよかったのに。 この影響は以下のように甚大です。 Macクライアントをメインに使って、Evernote Webはごくたまにしか使わない人が多いと思いますが、 そのために、通常は、このバグに気付かない。 Macクライアントでの表面上は、生成日のみの変更・同期をした状態なのか、ノートの中身も変更した後で同期したのかは、区別がつきません。 このため、通常は、このバグによる影響は表面化しない。 表面化しないだけで、実は、甚大な影響の種がどんどん蓄積している。 OS Xのクリーンインストール、あるいは、Evernote for Macのクリーンインストール(ノートデータをサーバーからダウンロードし直し)をすると、 このバグの甚大な影響に気付かされます。 私は今回、Lionにバージョンアップする際にクリーンインストールしましたが、以下のような2つノートブックで 200個以上のノートで作成日が元に戻ってしまいました。   ・ノートブック「A」(335個)の中の105個のノート(作成日が2011.6.11〜7.12に戻っていた)   ・ノートブック「B」(273個)の中の117個のノート(作成日が2011.6.8〜7.6に戻っていた) このノートブックは、すべて生成日を変更したと分かっていたために気付きましたが、 その他、20個以上あるノートブックは、どこに元に戻ってしまったノートがあるのか、5000個以上もあるノートすべてをチェックするのは不可能なので、 もはや、修正不能です。気付いたときに直すしかない。 まったく、こんなバグを放置してきたことに真摯に反省をして欲しい。 作成日を変更するケースでは、最初に、ノートの内容やタイトルなどを変更し、同期もして、 最後に作成日のみ変更して同期、ということが多くあります。 最後の同期の時に、たまたま(運良く)、ノートの内容やタイトルも変更していれば、変更した生成日も含めて正しく、サーバーデータが更新されますが、 作成日のみを変更した場合は、同期ボタンを押して、同期しているように見えても、実際には、サーバー側の作成日は更新されない。 Macクライアントのアクティビティ表示には通常と変わらない同期動作状況が表示されるので、作成日の変更がサーバーに反映されていると安心して(だまされて)しまう。 その意味では、何も変更されていない場合は、   「データの変化なし」 のような表示がされるべきでしょう。
  5. ベータ版のときは「再度’xxx’をコピー」メニューを実行しても、別のノートを指定した場合は特に何も変化なかったのですが、 Version 2.2.0 RCではうまく行くようになっています。
  6. 一度コピーしたあと、続けて同じノートブックにコピーする場合が多いと思います。 だから、「ノートブックにコピー」メニューを選んで、子メニューを表示した時に、 前回選んだノートブックを反転表示して、 この子メニューに一々移動しなくても、 「ノートブックにコピー」メニューをもう一度クリックすれば、 同じノートブックにコピー出来るようにしてほしい。
  7. (1)「ノートブックにコピー」の「オプション」メニューを先頭に配置してほしい 現状は、「オプション」メニューが一番下にあるため、ノートブックが何十個も作ってある時、 非常に操作しにくいので、これを先頭(一番上)にしてください。 (2)「ノートブックにコピー」の子メニューの上から2番目に現在使用中のノートブックを配置してほしい ノートのコピーは、大抵の場合は、同じノートブックに追加したいのが普通なので、 現在使用中のノートブックを(1)項のオプションのすぐ下の2番目にしてください。 元々の位置にも重複して子メニューがあってもいいと思います。 上記のようにすれば、一番機動力が良くなりますので、そのように改善してください。
  8. 簡単に言えば、内容を修正すると並び順が勝手に入れ替わってしまう、という不具合です。 同じノートブックにコピーした時に気づきましたが、 同じノートのコピーを複数一ヶ所に入れた場合にも同様の不具合が起きます。 「ノートブックにコピー」で同じノートブックにコピーした場合、 作成日の降順/昇順にしてあるのに(私の場合は新しい順)、  ・一方の内容やタイトルを修正すると、リストの並び順が入れ替わってしまう。  ・さらに、もう一方の内容やタイトルを修正すると、また、並び順が入れ替わってしまう。  ・この繰り返し。つまり、新しい方(私の場合は上にある方)を修正すると、並び順が入れ替わってしまう。 タイトルを修正する場合は、文字を入力して、リターンキーを押すと、順番が入れ替わる。 内容の方は、ひらがなを入力してリターンキーで確定すると順番が入れ替わる時もあればなぜかそうならない時もあるが、 Command+Sで保存すれば、確実に順番が入れ替わる。あるいは、リストをクリックすると入れ替わる。 最初、この現象に気づかず、追加した方を修正して、次に、元のノートを修正しようと思って、リスト上の下側のノートをクリックして(元のノートが下側だと思い込んでいるので)修正した後で、なにかおかしいと気づくのですが、しばらく何が起きたか理解できず、実は、追加した方だけを修正していたので、何で? 、と思って、混乱してしまいました。本当に、このバグを知らないと、混乱します。 コピーしない場合でも、昔から、複数のノートの作成日(日時分を含めて)を全く同じにすると、順番がどうなるかは不定ですが、 内部では秒数で区別しているようなので、以前から作成日に秒数も表示・変更できるようにすればいいのにと思っていました。 この点も改良してください。 と言うのも、秒数まで記録しておきたいことがあるからです。 ところが、「ノートブックにコピー」で作成したノートは、秒数まですべてが一致しているので、 区別がつかなくて、このようなおかしな動作になってしまうのでしょう。たぶん。 つまり、秒数まですべて一致した時に、並び順を規定するアルゴリズムが間違っているのだと思いますが、 このケースではどうすればいいのかは難しい問題ですね。 追加日時を導入したとしても、ミリ秒単位で区別しようとしても、結局、順番を自分が思うように決めることはできないでしょう。 つまり、作成日が全く同じケースでは、間違ったアルゴリズムで並べ替えるのではなく、 ノートをドラッグ移動する方法で並び順を意図的に変更できるようにする、それしかないですね。 例えば、タイトル順の場合であっても、タイトルが全く同じと言うケースも似たような問題が起きると思います。 以上よろしくお願いします。
  9. Macクライアントのver2.2.0 RC (06/09/2011) build 152864が出ましたが、 不具合報告したのが6/5なのでまだ伝わってないのかもしれせんが、 6/5に指摘した3つの不具合は、RC版でも修正されていません。 全然テストしてないとしか考えられません。 ちょっと使ってみれば、すぐに分かると思うんですけど、 これでRC版というのはちょっと普通では考えられません。 このまま正式ver2.2.0としてリリースすることはないとは思いますけど、この状態でRC版が承認されたことを見ると、 このまま正式ver2.2.0としてリリースしてしまう確率が高いのではないかと心配してしまいます。 そのようなことがないように、米国サイドの開発者に速やかに伝えてください。
  10. Evernote for Mac バージョン 2.2 Beta 3 (151504)で、戻る/進むボタンがやっと(要望から1年以上)追加されました。 正式版(ver2.3以降)では以下の機能を追加してください。 (1) 3本指スワイプ 3本指スワイプをすることが、戻る/進む機能の目的なので、 3本指スワイプができない戻る/進む機能はあり得ません。 正式版では追加されるとは思いますが、念の為。 (2) 履歴は挿入モードにしてほしい これはあらゆるソフト(特にブラウザー)で昔からある致命的な欠陥ですが、 履歴の中で移動している間はいいのですが、履歴の途中から分岐すると、それ以降の履歴が捨てられてしまうことです。 この使い難さを誰もが感じているはずですが、対応しているソフトは見たことがない。 これは七不思議の1つですね。 従来の仕様は、履歴本来の意味をはき違えています。 Webブラウザーでも、どんな経路でページを辿ってきたかということにはほとんど意味はない。 4つ5つくらいの狭い範囲の経路には意味がある場合もありますが、何十個ものサイトページの閲覧経路にはほとんど意味はない。 捨ててもいい履歴というものは無いと言うことです。 間接インデックス方式?を使えば、何の問題もなく、簡単に効率良く、挿入方式の履歴を実現できるはずです。 ぜひ、そういう機能を実現してください。
  11. Macクライアント(2.2 Beta 3)でバグがいろいろありますが、正式版では直っているといいですね。 ・ボタンをプレスした時に出るプルダウンの履歴を選んでも、正しく移動できない。  特に、異なるノートブック間の移動がおかしい。 ・ノートの名前を変更しても昔の名前のまま履歴に残っていて、見づらい。  削除したノートも履歴に残ってしまうが、ゴミ箱には移動しないのが一貫性がない。  ゴミ箱から削除するまでは、ゴミ箱に切り替えるのも便利かもしれない。 ・履歴に同じノートが複数(ひどい時は10個くらい)並んでしまうことが多々あり、操作しづらい。  バージョン管理を想定?しているにしても、ちょっと使いにくいですね。
  12. Evernote for Mac バージョン 2.2 Beta 3 (151504)で、戻る/進むボタンがやっと(要望から1年以上)追加されました。 まだベータ版なので、とりあえず追加したと言う感じで、 ノートのリンク機能も含めて、共通する問題があるので、このまま正式版になるのはまずいので、要望します。 そして、ノートブック切替遅延の問題(viewtopic.php?f=55&t=26752)をいっしょに解決しなければいけません。 (1)検索、ノートのリンク、戻る/進むボタンでの切替でリスト表示がスクロールされない ノートのリンクをクリックした時に、そのノートがリスト表示で見える位置に自動スクロールされないと意味がない。 検索では、この前までのバージョンでは見える位置にスクロールされていましたが、 今回のバージョン(2.2 Beta 3)になって、スクロールされなくなって使い難くなってしまいました。 同じリスト表示ルーチンを使用しているからだと思いますが、ノートのリンクや戻る/進む機能を組み込む際に、間違ったのでしょう。 特に、検索した時は、検索したノートの前後のノートを確認したい場合があるので、検索して見つかったノートを選択状態にしたままで、検索ワードを消去すると、2.2 Beta 3以前のバージョンでは、そのノートが見える状態のままで前後のノートを確認できたので良かったのですが、今回の不具合によって、検索ワードを消去すると、表示位置が先頭に変わってしまい、検索したノートがリストから見えなくなってしまいます。 ノートの数が何百、何千個もあるノートブックの場合は、延々スクロールしなければならず、何のために検索したのか分かりません。 (2)ノート切替・ノートブック切替の異常な遅さ Macクライアントで、これが解決しないと、戻る/進む機能もノートのリンク機能も役に立ちません。 Evernote Webの方が切替えが速いというのは、実に、変な話です。 普通は、ネットからデータを読み込むより、ローカルデータを読み込む方がはるかに速いはずですが、 現状のMacクライアントはその常識が成り立たない。
  13. Macクライアントの「ノートのリンク機能」ですが、 異なるノートブック間のノート切替で適切なノートブックが選択されず全ノートブックになってしまう。 全ノートブックが数千個のノートを含む場合は、切替遅延問題も絡んで延々1分以上待たされて イライラして精神衛生上よろしくありません。 戻る/進むボタン(ver2.2 Beta 3)では正常なので、それと同じにすればいいだけなので、 修正よろしくお願いします。
  14. Evernote Webは普通に速い。 一方、Macクライアントは、どうしたらこんなに遅くなるのか不思議なくらい遅い。  ・新規ノートの追加(5秒〜10秒くらいかかる)  ・ノートの切替  ・ノートブックの切替(特に数千個のノートを含むノートブックへの切替は30秒以上かかることも多々ある)  ・タグの選択 こういう切替が本当に尋常じゃないくらい遅い。 Evernote for Mac(バージョン2.1)で数千ノートの検索が速くなったようですが、あまり実感が無いのは(Evernote Webの検索の方が速い)、上記の切替の遅さがあまりにもひどいので、検索だけ速くなったとしても、あまり印象が薄いのでしょうね。 早く、64bit版にしてほしいですね。そうすれば、少しは速くなりそうなので。 数千ノートを超える場合(私は4000を超えている)の動作がEvernote Web並に速くならないと、Macクライアントは実用レベルとは到底言えません。 64bit版にすることも含めて、日本語入力の遅延問題も1年以上解決しませんがそれも含めて、Macクライアント版は、一から作り直すくらいのつもりでやらないと、駄目じゃないかと思いますね。 ノートブックに含まれる全てのノートデータを読み込むまで、何も操作できないというのは、あまりにも作りが悪い。 前にも要望しましたが、最近1ヶ月以内の変更/作成したデータだけを優先的に読み出したら、 編集がすぐに開始できるようにしてもらいたい。 Evernote Webが出来ていることを、クライアント版でできないはずはないので、 早急に対応してほしい。
  15. Macクライアントで、ノートを削除するとき、最近のバージョンで、動作がおかしくなっています。 すぐに直ると思っていたのですが、一向に直らないので、気づいているとは思いますが、とりあえず要望します。 バージョン2、3個前(ベータ版も含めて)からおかしくなった。 Macクライアントで、リスト表示で、あるノートAを選んで、削除ボタンを押すと、 従来は、リストからノートAがすぐに消えたのですが、 最近のバージョンになってから、  リストの選択状態(灰色背景)の位置がノートAの1つ上のノートに切り替わったまま(ノートAもリストから消えずに残ったまま)、  数秒〜長い時で5秒以上そのままになってから、  やっとノートAがリストから消える、 というような動作になって、非常に違和感を覚えます。 従来通りの動作に戻してください。
  16. 私は作成日順に並べて、新しい日付の方が上に来るようにしています。 たぶん、大抵の人はそうでしょう。 毎日チェックしたいノートでも、ノートを次々に作って行くと、 どんどん下の方に移動して、見えなくなってしまいます。 そこで、作成日を毎日「今日」に自動更新するような設定が出来るようにしてほしい。 ノート毎に設定できるようにするということです。 それと関連することですが、 作成日が変更できるのは便利で、未来の日付を設定して予定にしたりしていますが、 オリジナルの作成日が分からなくなってしまうのが悩みです。 オリジナルの作成日も簡単に確認できるような機能も追加してください。 また、作成日をオリジナルの作成日に戻す、という機能があれば完璧です。 作業中は作成日を変更して、作業が終わったら、オリジナルの作成日に戻す、という使い方が出来るからです。 また、未来の作成日を作っていると属性に   「明日以前」、「1週間後以前」とか「1ヶ月後以前」 というのがほしくなります。 「今日以前」では、明日の予定とか一週間後までの予定のノートを見ることができないからです。 特に、予定の場合は、明日とか一週間以内のものが見えると予定が確認しやすくなります。 「今日以降」と言う設定は現在も可能ですが、今日以前のノートも含めて見たいというのが普通です。 それから、未来を含めた全てのノートを表示していると、未来の予定が何十個もあると、今日のノートをスクロールして見つけるのが大変で非効率です。そこで、今日ボタンというのを追加して、それを押すと、今日のノートのところへ自動的にスクロールできるようにしてほしい。 よろしくお願いします。
  17. アクティビティログのデータ構造が、 の繰り返しという単純な構造であることが原因、と推測しましたが、比較不足でした。大変失礼しました。 その後、もう少しよく調べてみたところ、 Win版、Mac版で採取したアクティビティログには大きな違い(一貫性の無さ)があることが分かりました。 Mac内のローカルファイルはファイル名がタイトルそのものではないので見つけるのが大変なので、 ノートのエクスポート(enex形式)で比較しました。 HTML形式のエクスポートやローカルファイルでも違いはないようなので、 enex形式のエクスポートファイルをCodaで読み込んで比較しました。 ----------------------------------------------------------- [Mac版で採取したアクティビティログ]:   サイズ:    2.2MB    タグ : 21943個  症状:     ・英字モードでの入力は正常     ・ひらがなモードでの入力で15秒の遅延(時々誤入力)    というWebクリップでよく起きる現象(日本語入力のみで5秒以上の遅延や誤入力)のやや重い症状     ・1行(1つのdivタグの範囲)やその一部を選択してCommand+C(あるいはプルダウンメニュー)で      コピーしようとすると、1分23秒の無応答になり、復帰する。 ------------- [Win版で採取したアクティビティログ]:   サイズ:    2.3MB    タグ : 1個  症状:     ・英字モードでもひらがなモードでも、8分以上の異常遅延     ・1行やその一部を選択してコピーしても、特に問題ない。 ----------------------------------------------------------- つまり、これではっきりしたのは、  ・Mac版で採取したアクティビティログとWin版で採取したアクティビティログには、   1行ずつ タグで分割するか・全く分割しないか、  というHTMLタグ構造に明らかな違い(仕様の一貫性の無さ)がある。  ・Windows版では、どちらのタグ構造でも特に問題なく正常に動作する。  ・Mac版では、このデータ構造の違いで、症状が大きく変化する。  ・(症状1) 1つの巨大な タグの中に文字を入力すると、8分以上の異常遅延が起きる。 ・(症状2) 1行ずつ2万個以上の タグに分割されたものは、15秒以上の比較的軽い遅延や誤入力が起きる。      これは通常のWebクリップの症状に近い。  ・(症状3) 逆に、部分的なコピー動作は、文字入力遅延の軽いタグ構造の方が1分以上の遅延が起きる。  ・もちろん、Coda上で文字を入力したり、部分的なコピー動作をしても、全く問題ない。 結局、2.3MBのほとんど全てが1つの の内部にあるため、メモリの確保などに無理がかかっているのかもしれません。 私のMacはメモリ2GBなので、大きくはありませんが、この程度で問題になるとは思えません。 1つの タグが普通に小さくて数が少ないと5秒以上の遅延が起きて(Webクリップ)、1つが小さくても2万個も タグあると15秒以上の遅延が起き、部分的なコピー動作も1分以上かかり、1つの タグが2MB以上の巨大な場合は、8分以上の異常遅延になる、ということです。 小サイズの タグでも遅延が起きること自体、Mac版の作りには問題がありますが、そういう作りになっているため、 巨大サイズの タグでは異常遅延が起きても不思議ではない、と考えられます。
  18. やはり、sugai様のMacでも遅延は起きているんですね。 『2.1MBのテキストファイルでテキストが数秒遅れて入力、全選択しようとするとレインボーカーソルが発生』 というのは、軽めの症状ですね。 それに比べると、アクティビティログの遅延は、今まで私が経験した中では断トツです。 確かに、普通の「応答なし」は本当に1時間経っても応答なしのままという場合がほとんどなので、 区別がつかないのですが、 今回のアクティビティログの「応答なし」はCPU使用率が90%越えとなって、無限ループに近い状態にありますが、 確実に有限の時間(8分以上)で復帰します。そこが、普通の「応答なし」との違いです。 ですが、現実的には、8分も待つほど気が長い人はいないので、 強制終了してしまうので、この違いに気づいている人がいないのも仕方ないでしょう。 なぜアクティビティログの場合がこれほど異常な遅延が起きるのかを考えてみると、 アクティビティログのデータ構造が、     の繰り返しという単純な構造であることが原因と考えられます。 つまり、 タグを解釈するルーチンが2万個以上のタグを解釈するときに、そのルーチンが多重に呼び出されることで、 無限ループのような、待機状態の連続となって、それで、8分以上の遅延を生んでいる、と考えられます。 ノートのサムネールを作成するというDEBUG用の処理がおそらくこのような タグを解釈しているのでしょう。普通のWebクリップにも タグが重層的に含まれる場合がありますが、2万個も タグを含むWebページは普通はないので、それなりの遅延が起きているのでしょう。結局、DEBUGメッセージを出すような処理を外し忘れているのが、このバグの原因と思われるので、 表面的に言えば、DEBUGメッセージを出さないように修正すれば、遅延が起きなくなるでしょう、たぶん。 米国サイトのフォーラム(英語)を検索してみると、DEBUGメッセージは、かなり以前から出ているので、 Mac版の開発者たちは、DEBUGメッセージを出していることを全く気にしていないようにも見えますが、 少なくとも、常識的に言って、正式リリース版としては普通はあり得ないことです。 仮に、本当に出力すべきメッセージなら、DEBUGという表記を削除すべきですね。
  19. (1)Evernote  Evernote Mac 2.0 Beta 2 (115692)〜2.0 (116546) (2)環境  MacOSX 10.6.5  Macmini Core 2 Duo 2GHz, 2GB 667 MHz DDR2 SDRAM (3) 不具合現象の概要と要望 「(致命的な不具合) 文字入力・日本語入力・かな入力の数々の不具合は我慢の限界に達しています」 では、日本語入力での5秒以上の遅延でしたが(Mac版ver2.0 Beta 2、正式ver2.0でも未解決) 、 それをはるかに超える8分以上もの異常遅延(固定現象)に遭遇しました。 しかも、今回のケースでは、英字モードの入力でさえ発生します。 Win版Evernote4.1.0では、このような遅延は起きない。 日本語入力遅延も含めて、 Mac版Evernoteには文字入力による異常な遅延という爆弾(バグ)が複数あるのは明らかです。 Webクリップの場合、HTML構造は一定しませんが、 アクティビティログは、Evernote自身が作成している単純な構造のデータなので、そこでこのような異常遅延が起きるのは問題外ですが、このバグを直す上では都合がいいかもしれません。 これは、単に「アクティビティログ」だけの問題ではなく、Webクリップも含めた根本的な問題です。 5秒でも許せない遅延ですが、8分以上の遅延は、もはや、使用に耐えない。 これを放置しておくのは、Evernote社にとっても我々ユーザーにとっても多大な不利益につながるので、 日本語入力の遅延も含めて、大至急、この不具合を解決してください。 これは、米国サイドが直すのを待っているしかない、というようなレベルではないので、 ホットラインを通じて米国サイドに改善を緊急要請してください。 sugai様など日本人スタッフご自身で先ずはMacで現象を確認していただけませんか? Win版で問題ないことも含めて。 よろしくお願いします。 (4) 現象の詳細 「(要望)膨大なノートデータが既にある場合の再インストール等におけるローカルデータの再ダウンロードの問題点と要望 」で説明したWin版のバージョンアップ時に気づいた現象です。 「Evernote for Windows 4.1.0.3365 (115466) Public」のインストールが何度やっともうまく行かず、 結局、Cディスク容量不足だろうとやっと気づき、ローカルファイルの保存先をEディスクに変えて、 インストールとローカルファイル(約3000個のノート・サイズ約2.5GB)の再ダウンロードが4時間かかって完了しました。 その時のアクティビティログ(なんとサイズが4.1MB)を「Copy to Clipboard」でコピーして、新規ノートにペーストしました。 アクティビティログを採取したのは今回が初めてです。 比較テスト用に以下のような5つのノートを作成しました。   ノートW#1(4.1MB):     Win版4.1.0でアクティビティログを全選択し「Copy to Clipboard」、新規ノートにペースト。   ノートW#1-1(955KB):     Win版4.1.0でアクティビティログの最初の約4分の1を「Copy to Clipboard」、新規ノートにペースト。     これは正常。   ノートW#1-2(2.3MB):     Win版4.1.0でアクティビティログの最初の約4分の2を「Copy to Clipboard」、新規ノートにペースト。   ノートW#1-3(3.2MB):     Win版4.1.0でアクティビティログの最初の約4分の3を「Copy to Clipboard」、新規ノートにペースト。   ノートM#1(2.2MB):     Mac版2.0Beta2でアクティビティログを全選択し「クリップボードにコピー」、新規ノートにペースト。 (4-1) 最初の気づき  ノートW#1をMac版ver2.0 Beta 2で開いて、ノート内部に文字を入力したところ、レインボー風車が回り出し、  何分経っても入力した文字も現れないので、Evernoteを強制終了しました。  日本語入力遅延の極端な例なのかどうかを確かめるため、英字モードで「e」を打ち込んでみても、  やはり同様の現象で、強制終了しました。 (4-2)結論 いろいろ試してみた結果、  ・アクティビティログのサイズが955KBでは問題なく、   サイズ955KB〜2.3MBの間のどこかに異常遅延するかしないかの境界がある。  ・Win版Evernote(ver4)は正常で、Mac版(ver2)は明らかに異常遅延が起きる。  ・Webクリップに日本語を入力したときの遅延(5秒〜10秒以上)に比べても、明らかに遅延が長い(8分以上)。  ・遅延時間はノートサイズ(ログサイズ)の2乗より若干長めに比例して加速度的に増大して行く。    ■ノートW#1-1(955KB) : 遅延時間 なし    ■ノートW#1-2(2.3MB) : 遅延時間 8〜9分16秒    ■ノートW#1-3(3.2MB) : 遅延時間 18分30秒    ■ノートW#1(4.1MB)  : 遅延時間 32分  ・Webクリップで遅延が起きるのは日本語入力だけですが、   アクティビティログでの遅延は英字モードでも起きるので、   今回のバグは、日本語入力システムとは無関係です。   プルダウンメニューの「ペースト」やCommand+Vでも全く同様の遅延が起きるからです。  ・レインボー風車が回り遅延している間に、     ・EvernoteのCPU使用率が6%前後から一気に90%以上に跳ね上がる。     ・アクティビティログにはこの間何も追加表示がない。     ・Evernoteは「無応答」という表示になる(強制終了パネルなどで)。  ・これだけ処理が中断した後のためだと思うが、入力した文字が現れるとすぐに同期が始まる。  ・Mac版Evernoteで採取したアクティビティログ(2.2MB: ノートM#1)と   Win版Evernoteで採取したアクティビティログ(2.3MB: ノートW#1-2)を比較すると、   サイズはほぼ同じなのに、   後者の方が遅延時間が圧倒的に長い(前者: 遅延2分30秒・同期1分20秒程度、後者: 遅延8分・同期1分程度)。   Win版とMac版の文字コードの違いなのか?  ・遅延の起きるときに2文字打ち込んでも(たとえで「ff」)、遅延後に表示されるのは1文字のみ。   つまり、1文字打ち込んだ瞬間に遅延が起きて2文字目の入力は廃棄されるということ。  ・Mac版のアクティビティログで、     ・「DEBUG」という表記のメッセージがあるのが怪しい。       Beta版はともかくとして、正規版でこのようなメッセージがあること、       つまりは、何らかの余計な処理をしていることはまずい。     ・「DEBUG」メッセージの中の [ENQuotaUsageLevelIndicator] 、[ENNoteThumbnailManager]       というカテゴリーが怪しい。     ・特に、ノートのサムネールを作成するというのが一番怪しい。      どんなサムネールかは分からないが、ノート用と書いてあるので、      このサムネールを作成することが異常な遅延を生んでいる可能性が高い。      ログサイズのほぼ2乗に比例して遅延時間が増大することから考えても、ここに原因がありそうです。 (4-3) 比較テスト 遅延の起きるときと起きないときのアクティビティログの出方を確かめる。 (テスト3-1) 遅延の起きないケース、ノートW#1-1(955KB)で文字を一文字入力し、直後に同期ボタンを押したときのログをMacとWinで比較  ログの表示形式が全く違うので非常に見にくい。  もう少し統一した方がいい。  (テスト3-1-1) Version: Evernote Mac 2.0 Beta 2 (115692)および、Version: Evernote Mac 2.0 (116546)で: 2010-12-17 00:29:40 0xa125a0 [ENQuotaUsageLevelIndicator] DEBUG: -[ENQuotaUsageLevelIndicator generateCachedImages]: 0x16952c60 2010-12-17 00:29:40 0x196dba10 [ENSyncEngine] INFO: Contacting Evernote server... 2010-12-17 00:29:40 0xac4eb0 [ENNoteThumbnailManager] DEBUG: Generating thumbnail for note: 'ノートW#1-1(955KB)' 2010-12-17 00:29:40 0xac4eb0 [ENNoteThumbnailManager] DEBUG: guid: 47311487-5532-4d9f-826f-dd05308b61c5 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: current update count: 116740 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Updating local user info from server 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Upload used from server: 241780003 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Nothing to pull down from server. 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Uploading changes... 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Sending tag changes... 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Sending search changes... 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Sending notebook changes... 2010-12-17 00:29:41 0x196dba10 [ENSyncEngine] INFO: Sending note changes... 2010-12-17 00:29:42 0x196dba10 [ENSyncEngine] INFO: Syncing note 'ノートW#1-1(955KB)' [47311487-5532-4d9f-826f-dd05308b61c5] 2010-12-17 00:30:10 0xa125a0 [ENQuotaUsageLevelIndicator] DEBUG: -[ENQuotaUsageLevelIndicator generateCachedImages]: 0x16952c60 2010-12-17 00:30:10 0x196dba10 [ENSyncEngine] DEBUG: skipped 51 never-synced trashed notes                          ←これはゴミ箱(61個のノート)の中のデータだろう。 2010-12-17 00:30:10 0x196dba10 [ENSyncEngine] INFO: Sending linked notebook changes... 2010-12-17 00:30:10 0x196dba10 [ENSyncEngine] INFO: Syncing content of linked notebooks... 2010-12-17 00:30:10 0x196dba10 [ENSyncEngine] INFO: Sync complete.  (テスト3-1-2) Evernote for Windows 4.1.0.3365 (115466) Publicで: 00:40:04 [2184] 0% Connecting to http://www.evernote.com 00:40:04 [2184] 0% * loaded updateCount: 116742 00:40:04 [2184] 0% Client is up to date with the server, updateCount=116742 00:40:04 [2184] 0% * saved updateCount: 116742 00:40:05 [2184] 0% Updating server items 00:40:05 [2184] 0% Updating server note "ノートW#1-1(955KB)" 00:40:05 [2184] 0% * guid={47311487-5532-4d9f-826f-dd05308b61c5} 00:42:12 [2184] 0% * updateCount: 116742 --> 116743 00:42:12 [2184] 100% * saved updateCount: 116743 00:42:13 [2184] 100% Session terminated normally, elapsed time: 2m 9s 00:42:13 [2184] 100% * sent: 974KB, received: 494B 00:42:13 [2184] 100% * 2m 8s (99%) spent in EDAM RPC 00:42:13 [2184] 0% Connecting to http://www.evernote.com 00:42:13 [2184] 0% * loaded updateCount: 116743 00:42:14 [2184] 0% Client is up to date with the server, updateCount=116743 00:42:14 [2184] 0% * saved updateCount: 116743 00:42:15 [2184] 0% Session terminated normally, elapsed time: 1s 00:42:15 [2184] 0% * sent: 228B, received: 138B 00:42:15 [2184] 0% * 1s (70%) spent in EDAM RPC  (テスト3-2) ノートW#1-2(2.3MB)で英字モードにして       「ggg」をキー入力し9分以上の遅延が起きたときのアクティビティログの出方   キーを打ち込んでから遅延が起きている間は、アクティビティログには何も表示されない。   打ち込んだ文字も表示されない。   そして、9分16秒後に、打ち込んだ3文字ではなく1文字「g」だけが現れ、文字カレットが点滅を始め、   以下の4行だけが表示された。 2010-12-17 14:42:47 0xa12570 [ENQuotaUsageLevelIndicator] DEBUG: -[ENQuotaUsageLevelIndicator generateCachedImages]: 0xac5740 2010-12-17 14:42:48 0xdd7e60 [ENNoteThumbnailManager] DEBUG: Generating thumbnail for note: 'ノートW#1-2(2.3MB)' 2010-12-17 14:42:48 0xdd7e60 [ENNoteThumbnailManager] DEBUG: guid: 96c93517-e369-4730-addd-cff46d264b41 2010-12-17 14:42:49 0x268d9520 [ENSyncEngine] INFO: Contacting Evernote server...       ←pm2:42:47 先ずは「g」が表示されたときにここまで表示した。        この4行の表記は、(テスト3-1-1) で同期ボタンを押したときにも最初に出るメッセージですが、        最初の3行、特に、ノートのサムネールを作成、というDEBUGメッセージは、         同期ボタンを押す前にすでに実行していたと考えれば、辻褄が合う。        遅延の起きない場合でも、キー入力してからバックグラウンドでこのサムネール作成が実行され        ていると思われる。        メッセージが出るのは、同期ボタンを押したことを契機としているだけでしょう。        そして、遅延が起きたときは、バックグラウンド実行に渡すところで戻ってこれなくなっている        のだろうと考えられます。        結局、遅延の無いようなサイズの小さいログの場合でも、実際には、わずかな遅延が起きている        可能性もあるかもしれない。        遅延がノートサイズのほぼ2乗に比例して増大することから考えても、        ノートのサムネールの作成がノートサイズが大きくなればなるほど時間がかかると考える        と辻褄が合う。 2010-12-17 14:42:49 0x268d9520 [ENSyncEngine] INFO: current update count: 117056 2010-12-17 14:42:49 0x268d9520 [ENSyncEngine] INFO: Updating local user info from server 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Upload used from server: 242181957 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Nothing to pull down from server. 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Uploading changes... 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Sending tag changes... 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Sending search changes... 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Sending notebook changes... 2010-12-17 14:42:50 0x268d9520 [ENSyncEngine] INFO: Sending note changes...       ←pm2:42:50 同期が自動的に始まって次にここまで表示された。 2010-12-17 14:42:55 0x268d9520 [ENSyncEngine] INFO: Syncing note 'ノートW#1-2(2.3MB)' [96c93517-e369-4730-addd-cff46d264b41]       ←pm2:42:57 ここまで表示された。 2010-12-17 14:43:45 0xa12570 [ENQuotaUsageLevelIndicator] DEBUG: -[ENQuotaUsageLevelIndicator generateCachedImages]: 0xac5740 2010-12-17 14:43:45 0x268d9520 [ENSyncEngine] DEBUG: skipped 52 never-synced trashed notes 2010-12-17 14:43:45 0x268d9520 [ENSyncEngine] INFO: Sending linked notebook changes... 2010-12-17 14:43:45 0x268d9520 [ENSyncEngine] INFO: Syncing content of linked notebooks... 2010-12-17 14:43:45 0x268d9520 [ENSyncEngine] INFO: Sync complete.       ←pm2:43:44 ここまで表示され同期完了。 (5)その他 Macでは、プルダウンメニューでは、「ヘルプ----アクティビティログ...」ですが、 実際のウィンドウ上部に「活動記録」というべたな直訳になっていておかしい。 「クリップボードにコピー」ボタンも実際の動作が分かりにくいので、ちょっと長くなってしまいますが    『ヘッダー付きでクリップボードにコピー』、あるいは、短くして、    『ヘッダー付きコピー』 とした方が分かりやすい。右クリックメニューの「コピー」と区別するためです。
  20. (1)Evernote   Evernote for Win ver4.0〜ver4.1.0   その他のEvernoteも (2) 要望 Evernoteを初めてインストールする場合を除いて、 MacやWindowsで既に膨大なデータを作成してある状態、 つまり、Evernoteサーバー(クラウド)上に膨大なデータが保存されているときに、 ローカルデータを初期化してEvernoteを再インストールしたり、 あるいは、別のシステムにEvernoteを新規インストールする場合に、 (2-1) ローカルデータ(特にexb形式のデータ本体)の保存に必要な容量、   つまり、サーバー上にあるデータの全容量(サイズ値)を最初に提示してほしい。   ローカルディスク容量が不足しているようなら、ローカルファイルの保存先指定を変更するように促す。   また、「今月の使用量」の表示の中に、全容量の表示を加えてほしい。 (2-2) ローカルデータの効率的な仕様(インストール時)    ・ノートの本文データのダウンロードは後回しにして、     とりあえず、ノート名や作成日・ノート個数等だけを取り込む。    ・作成日時/修正日時/開いた日時が例えば1ヶ月以内のものを再優先でダウンロード(同期)し、     残りはバックグラウンドで実行することで(バックグラウンド同期)、     すぐに(長くても5分以内に)普通に使用できるような状態にする。     1ヶ月以内のデータ量と実際のダウンロード速度から計算して、     5分以上かかりそうなら、5分経過時点でダウンロードを中断して、後はバックグラウンド同期に回す。    ・バックグラウンドで同期しているときは同期ボタンは回転させずに、同期ボタンを押せるようにしておく。     同期ボタンを押した場合は、      バックグラウンド同期を中断し、      作成日時/修正日時/開いた日時が一日以内のものを再優先で同期し、      それが終わってからバックグラウンド同期を再開する。     バックグラウンド同期が終わっていないノートを選択したときは、それを再優先でダウンロードする。    ・予測終了日時を表示する(残時間、データ全容量/進行容量の表示も)。    ・データが増えれば増えるほど、膨大なデータのほとんどは滅多にアクセスしないので、     一気にローカルデータを再構成する必要もないので、パソコンが起動している間に、     ゆっくりとバックグラウンドでダウンロードすれば十分です。    ・これらを実現するために、     最近1日以内および1ヶ月以内にアクセスしたノートのリストをサーバー側に残しておいて、     効率的に実行できるようにするような仕組みが必要でしょう。  つまり、ローカルの全データの再構成(初期同期)と、最近使用したノートの同期とを  同列に扱う必要はないということです。  最近使用したノートを最速で使用できる状態に持って行くこと、それが再優先事項です。  特に、iPhoneなどのような小規模なシステムでは、この点がより重要でしょう。 (2-3) アンインストール方法をわかりやすくしてほしい   ヘルプメニューにアンインストールメニューがあって、適切な説明がすぐに読めて、そのまま実行できること。   「Revo Uninstaller」などのソフトのインストールURLを示し、   インストール済なら、それをそこから実行できるようにする。 (2-4) 今後の全面的な仕様変更(ローカルデータの容量制限) MacやWindowsでアクセスする場合は、今のところデータ量も大したことがないので、 全データをローカルに保持して、それをサーバと全て同期していますが、 今後、それも不可能なくらいデータ量が増え続けたときに、今の方式では対応できなくなる日も近い。 iPhoneなどの小規模システムを含めて、MacやWindowsであっても、 いったんサーバーにデータを保存した後は、 ローカルデータの容量を、例えば1GBに限定して設定できるようにしておいて、 それを超えてノートを追加、アクセスするときには、最近アクセスしていないデータを開放して、 必要なデータを代わりにダウンロードすればいい。 そういう融通性のあるシステムにしたほうがいい。 必要最低限のローカルデータに限定するということです。 ほとんどアクセスしないデータをローカルに置いておく必要性はないからです。 そうすれば、再インストールを含めて、効率のいいシステムにできるはず。 全ての機器のローカルストレージに全データを入れて持ち歩くことにほとんど意味はない。 必要な範囲のデータだけをオフラインでも使用できさえすれば十分だし、それが現実的です。 将来1TB,100PBとノートデータが肥大化して行ったときに、 その全データをローカルストレージに入れておくのは非現実的だからです。 (3)問題となった状況 通常はMac版を使用し、WindewsマシンにもWin版をインストールしてあります。 大量のデータをMac版で追加して、 Windowsはほとんど使わないのでWindows側のローカルデータは更新されないままでいるという状態です。 こういうケースで、久々にWin版をバージョンアップしたり、同期したときに発生した実例です。 簡単に言えば、WindowsのCディスクの容量不足(ローカルデータの既定値がCディスクのため)のときに、 延々と何時間も同期動作が続いた後で同期失敗となってしまったのですが、問題点は以下の通りです。 Cディスクの残容量が2GB前後という微妙な状況で、Evernoteのローカルデータ(exb形式)が急激に増えてその値を超えていたということです。  (問題点1) 何が原因で同期失敗したかというメッセージが出ない。       そのため、無駄な時間(4時間〜10時間以上も)が浪費されてしまう。  (問題点2) そもそも、サーバー上に保存されているデータ容量を最初に提示しないまま同期動作が進んでしまう。  (問題点3) 同期作業の予測時間が出ないこと。       そのため、正常に同期が進んでいるのかが分からず不安になって、強制終了してしまうこともある。       数分程度で終わるならいざ知らず、何時間もかかる状況では残時間表示は必須。      できれば終了予測日時も表示するのが理想。  (問題点4) ノート総数3000、データサイズ2.5GB程度のデータ量でも、ローカルファイルとして全てダウンロードするのに4時間(Win版ver4.1.0)〜10時間以上(Win版ver3.5)もかかってしまい(低速なADSLではありますが)、その間に通常の作業ができない。この程度のデータサイズでさえ既に破綻をきたしているが、無限にサイズが増えて行ったときに、再インストールや別のシステムに新規インストールするときを想像すると、実用性を欠いている。  (問題点5) アンインストール方法(「Revo Uninstaller」というソフトを使うことなど)がどこに書いてあるか分からず、探すのに無用な時間がかかってしまった。
  21. sugai様へ、 了解しました。 どうしても文章が長くなりがちで、 できるだけ結論(要点)を先に書くようにしているのですが、 今回はちょっと読みにくかったかもしれません。 今後は読みやすい文章を書くように心がけたいと思います。 それでは、今回の件、よろしくお願いします。
  22. このようにEvernoteの社員が言っているように、「ノートへのリンク」機能は今後の開発リストに確実に入っています。 このTOPICは不毛な言い合いが続いてクローズされてしまったようですが、 その中に、そんな機能がないとは思わなかった、という書き込みがありましたが、 それはアメリカ人でも日本人でもEvernoteのユーザーなら誰でもそう思っているはずです。 単なる「ノートへのリンク」機能(一方通行の参照)は、 各ノートのスクロール位置を記憶する機能と同じで、 本来あるのが当然の機能です。 サポートが遅れたことをバネにして、さすがEvernoteと言われるようなもっと進化した形で実現してほしい、 というのが私の要望の主旨です。 そういう意味で、一方通行のノート参照ではなく、 相互参照(任意のスクロール位置の表示も含めて)で、しかも、シオリ機能も兼ねていれば、 不便さを我慢していたユーザーも許してくれるでしょう。 現実の本の栞(しおり)は、挟んだどっちのページなのかさえ分からないので、 私は、ポストイットに矢印を書き込んで、どの行まで読んだのかを分かるようにしておくことがあります。 そういうことがEvernoteでも簡単にできるようになれば最高です。 Evernoteの「シオリ」機能にもう一つ希望するのは、 1つの「シオリ」で2つの場所を交互に移動することです。 TVで2つの番組を交互に切り替えるための「リコール」ボタンがありますが(メーカーによる)、 これが意外に便利です。CMの間だけ別の番組を見ていて、戻すという感じで使う時ですね。 最近は2画面同時表示のTVもあるので、Evernoteにも別ウィンドウ表示機能があると言われそうですが、 考え方としては、MacのSpacesに近いものです。 例えば、ある作業をしているときのタグ選択を含めた使用環境があって、 それとは別の仕事用に表示したい環境があって、その相手から電話が来たら、 すぐに切り替えられるように、「シオリ」で操作環境を切り替えるといった使い方も出来るようにしたいということです。 ノートブックがいくつも増えると、それも切り替えて、 タグを見つけて、 ノートを選んで、 スクロールして、 というような煩わしい一連の作業をしなくても、一発で切り替えたい訳です。 このように、ただの「ノートへのリンク」機能(一方通行の参照)だけで十分というようなケースは当然として、 もっと先にあるEvernoteらしさを発展させる機能に期待しています。 この辺も含めて、伝えてください。sugai様、よろしくお願いします。
  23. 「ノートの相互参照」という言い方は、   「ファイルとそのショートカット(エイリアス)」(アンカータグ的な参照も含めて)の相互参照機能 という意味ととらえられますが、狭い意味ではその通りです。 私の要望は、大雑把に言えば、「ノートの相互参照」+「シオリ」ですね。 「ノートの相互参照」用のタグはノート内部に貼り付け、 「シオリ」は外部から常に見える、 という違いです。 どちらも同じ形状としてインプリメントすれば、シームレスに使えるはずです。 つまり、相互参照とシオリ機能の合体したようなものです。 (1) 1つのノートの中に、複数の「相互参照タグ」を入れておけば、目次のような使い方が出来ます。 それが、相互参照という意味だと思います。使い方次第ですね。 (2) 1つの関連するノートたちを見ているケースだけではないので、相互参照だけでは不十分です。 話題Aのノートをいくつか見たり、別の話題Bのノートを見たり、というようなケースでは、 素早く切り替えて行くためには、外部に常に表示している「シオリ」も必要です。 従来のタグ機能のように、ウィンドウ左の部分に、「シオリ」が並んでいるというイメージです。 「シオリ」同士は、 お互いに無関係(相互参照ではない)ということが多いでしょうが、 関係する場合(相互参照や内部参照)もある、ということです。 「シオリ」は基本的に一方通行です。 その「シオリ」の実体(相互参照タグ)が貼り付けてあるノートに(スクロール位置も含めて)移動するための鍵です。 単純に、「ノートの相互参照」という言い方をすると誤解される可能性が高いので、 言葉で説明するのはなかなか難しいですね。 こんな感じでお分かりいただけたでしょうか?
  24. (1)Evernote Mac版Version 1.11.0 (09/08/2010) build 99371 など全てのEvernote (2) 要望 ノートが1000個、1万個、1億個と増えて行くと、たとえタグで整理してあっても、それだけでは不十分です。 ノート同士をリンクして、簡単に移動(参照)できるようにしたいと思うことが多くなります。 昔のノートに書いてあったことと関連することを別のノートに書いているときなどに、 昔のノートを一々探し出して、別ウィンドウに出して、というようなことをするのが時間の無駄で、 ノートがどんどん増えて行くとそんな昔のノートを検索して見つけるのも大変です。 1つのタグの中に100個とかあれば、スクロールするのも大変だし、 検索しても、同じような内容のものが多数並んでいることもあるので、検索と言えども万能ではない。 何日にも渡って何回も同じ作業をするときに、毎回、スクロールしたり、検索するのは時間の無駄以外の何ものでもない。 「古典的しおり機能」は、 ウィンドウの横に複数のしおりが並んでいて、それをクリックするとそのデータを表示する、 というような感じになると思いますが、ノートが無限に増えて行くEvernoteでは、そういうインプリメントは役に立たない。 しおりの数も無限に増えて行くからです。 しおりの数を制限するのも意味がない。 (仕様案) Evernoteしおり機能(相互リンク的しおり)の仕様は以下のようになるでしょう。 結局、アンカータグの応用で実現できるはずです。   [しおり]    [しおりリンク]] という2つのオブジェクトをノートに貼り付ける。 (a)ショートカット相当の使い方 各ノートをファイルと見なせば、ノートのショートカット(Macのエイリアス)があれば便利だと前から思っていましたが、それもこの [しおり]と [しおりリンク]]で代用できます。 [しおり]をノートの先頭に貼り付けておけば、 [しおりリンク]]がショートカット(エイリアス)と同じことになるからです。 (双方向の移動 ノート内の好きな位置(文章の途中)に [しおり]を置けるようにして、 そのしおりを参照するための [しおりリンク]] を別のノート(あるいは同じノートでも)の好きな位置にいくつでも置けるようにする。 「しおり」には、 [しおりリンク]] を置いたノートへの逆リンク(複数個)が付いていて、双方向に移動できる。 そうすれば、どのノートに貼り付けてあったかと言う全てのリンクも分かるので、この機能は必須です。 例えば、[仕様案f■■■■]] というしおりリンク(別のノートにあるのが普通)をクリックすると、(f)のところのしおりに飛ぶと言うことです。 そして、(f)にあるしおりをクリックすると、ここ(このしおりリンクの位置)に戻って来れる。 通常のHTMLのアンカータグは一方通行ですが、双方向に行き来できるのがこの「相互リンク的しおり」の便利な点ですね。 不特定な人が使うブラウザーでは一方通行で十分ですが、Evernoteは個人使用なので、双方向の移動が意味を持つ。 そこが、ブラウザーとEvenoteの根本的な違いですね。 ブラウザーでも双方向のアンカータグがあればそれはそれで便利ですけど…。 [しおり]は戻るボタンも兼ねているということです。 元の位置に戻ることも出来るし、選択すれば、別のノートにも移動できる。 また、 [しおり]自体を別ノートに移動(カット・ペースト)することはできるようにして、コピーは認めない。 コピーすると、それはしおりリンクになるということですね。 ©しおり一覧 [しおり]を2個3個と追加して行くと、しおり一覧に並ぶようにして、その一覧からドラッグすると、 [しおりリンク]]を貼り付けることが出来る。 [しおりリンク]]自体をコピー・ペーストできるのは当然です。 [しおり]を貼り付けたノートをゴミ箱に入れたときは、しおりリンクは半透明化して、 そのノートを完全に削除したときは、 [しおりリンク]]が残っている意味はないので、全ての [しおりリンク]]は自動的に削除される。 (d)しおり一覧の分類 しおりには、一時的な作業用に付加しておくという使い方と、 恒久的な相互リンクとし付加しておきたいという場合があります。 しおり一覧も、この2つに分けてあると使いやすいでしょう。 (e)しおりの履歴(古典的しおり) 最近使用した [しおりリンク]]は10個くらいまではノートの外に、  「最近使用したしおりリンク一覧(履歴)」 としていつでも簡単にクリックできるようにしておくと実用的です。 履歴と言うよりも、自分で好きな位置に並べ替えれるようにすると使いやすいですね。 (f) [仕様案f■■■■] しおり、しおりリンクには、ぱっと見の区別が出来るように、とりあえず色と文字を付けれるようにしたい。 特に、一時的な作業用で使うときに必要です。   [あ■■■■]、[あ■■■■]]   [A■■■■]、[A■■■■]] みたいな感じでしょうか。長いタイトルを全部常に表示しておくのは逆に見にくくなるからです。 逆に、恒久的な相互リンクとして使う場合は、もう少し分かりやすい説明を書いておくことになるでしょう。 しおりの名前を変更すれば、当然、しおりリンクの名前も自動的に変更され、逆も可能にする。 しおりリンクの上にマウスを乗せるとノートのタイトルを表示できるようにする。 (g)表示モード しおりやしおりリンクを付けたノートを分かりやすく一覧できる表示モードも必要でしょう。 あるいは、検索機能の中でしおりやしおりリンクを検索できるようにすると言う感じでもいいでしょう。
  25. (1)Evernote Mac版Version 1.11.0 (09/08/2010) build 99371 (Win版Version 4でも全く同じ) (2)環境   MacOSX 10.6.4  Macmini Core 2 Duo 2GHz, 2GB 667 MHz DDR2 SDRAM (3) 現象・要望 同じノートをメインウィンドウと別ウィンドウで表示している場合に問題が発生します。 1つのノートが長くて、スクロール位置を変えたところを確認しつつ、例えば、文頭に文章を書きたいときに、 同じノートを別ウィンドウで表示しておけばできそうですが、現状のインプリメントには大きな問題があります。 メインウィンドウ側で保存をしたり自動同期が起きると、 別ウィンドウ側は、一緒に更新されると同時にスクロール位置が先頭に移動してしまう。 さらに、文字カーソルの位置を記憶していないことも問題です。 別ウィンドウの文字カーソル(文字カレット)を文末に表示しておいて、スクロール位置も文末の状態にしておいて、 メインウィンドウ側で保存を実行すると、 別ウィンドウのスクロール位置が文頭に移動すると同時に、文字カーソルも文頭に移動してしまう。 これでは、別ウィンドウで出している意味がなくなってしまいます。 たとえば、Coda1.7では、 同じファイルを分割表示して、それぞれスクロール位置が違っても、 一方で、行を追加したり、削除すると、もう一方の表示は変化が最低限にとどめられています。 当然、保存をしても、双方のスクロール位置が変化することはありません。 ただし、表示している行数を超えるような量を一気に削除すると、スクロール位置が初期化されて文頭に移動してしまうというバグがまだあります。 たとえば、Fraise3.7.3では、 同一ウィンドウでの分割機能と別ウィンドウに表示する機能(Evernoteと同様)の両方がサポートされています。 いずれの場合でも、40行くらい一気に削除しても、行番号表示が少しおかしい以外は、表示位置をできる限り維持しています。 もっと大量に削除しても、文頭に移動してしまうようなことは起きない。 分割機能(別ウィンドウも分割機能の一種)としてはこのくらいできないようでは落第ですけどね。 削除した行数だけずれて行きますが、これももう少し正確に計算すれば、表示位置をもっと正確に維持できるはずです。 やはりこのくらいできないと駄目ですね。 通常は、1行とか数行の変更をすることが多いので、Codaのバグもまだ許せる範囲でしょう。 このように、同一ウィンドウ内で分割する、あるいは、別ウィンドウに分割する場合でも、 表示位置をできるだけ維持するのは基本だと思うので、Evernoteでもそのように改善してください。
×
×
  • Create New...