Jump to content


Level 2
  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About MikhailV

Recent Profile Visitors

734 profile views
  1. Seems this topic is being addressed in at least two Android Product Feedback threads as well. Here is my initial post to one... ...and my subsequent post to another...
  2. See... Having just scanned THIS topic I'm now posting to, I see indications that Android-OS/API constraints might be at least part of what inhibits Evernote from providing a store-to-SD-card option for offline note content (e.g., Offline Notebooks, containing ALL content for notes in those notebooks). If that is the case, perhaps Evernote should coordinate w/Google on this issue.
  3. Agreed. See also... I've read that Evernote previously interacted w/Android in a manner that allowed storage of offline notebooks on a device's SD card. If Evernote developers can (still) enable storage of offline folders to SD card on current Android OS/platforms via Android APIs, and if concerns about data security are part of Evernote's reason to exclude that capability (as one of the posters to the "Request: Add external SD card support" topic has observed or inferred), consider that Android allows for user-initiated encryption of an SD card inserted in an Android device. As an alternative or supplement, consider implementing a compromise solution that allows offline storage of SOME content from all -- or a user-specified selection of -- Notebooks, even if the location is limited to the device's fixed internal storage. For instance, allow offline storage of note body text and metadata WITHOUT attached/embedded content such as document files and images. This appears to be similar to what Evernote's "Settings in Evernote for Android" article... https://help.evernote.com/hc/en-us/articles/208313348 ...CLAIMS is available as an option, even though (at least in the current Evernote for Android version) it is not. [I just received confirmation from an Evernote representative that the article should be modified to remove reference to this claimed but (currently) absent feature.]
  4. I've already Liked and/or responded with very brief agreement to / elaboration on a couple of previous posts to this topic. Now, I have a few observations to add. I hope they represent (at least mostly) new/augmented info that is both relevant to this topic and will refine -- at least a bit -- the understanding of the parameters of EN's current behavior in connection with it. I have copied the entire contents of this topic from my browser to (you guessed it) an EN note, and performed a few text-within-Note searches for obvious precedents. Naturally, one of the positive byproducts of a future and effective response by EN (the company) to this concern would be avoiding the need to review (what is now) over 260k characters in over 47k words across 16 pages comprising 300+ discrete posts to see what specific info pertaining to this topic has already been discussed. I apologize in advance for any inadvertent repetition that any forum browsers find counterproductive. For EN note contexts (e.g., subjects, authors/promulgators,...) where I've decided that the value of visual identifiers via EN thumbnails warrants finding/scaling/cropping relevant images (e.g., EN icon/logo), I've recently developed a standardized approach based on a 300x300 pixel size and confinement of key image content to a central horizontal range. I add such visually-identifying thumbnails to the beginnings of applicable notes as a de facto visual note header. I adopted these practices after seeing how many pixels EN devoted to thumbnail display within (Windows) desktop, Web, and iOS apps, based on my hardware and configurations...and on how EN seemed to alter thumbnail display behavior based on the aspect ratio of the image within the note it selects as a thumbnail and on the nature of the other contents of the subject notes. (At this time, I don't intend to elaborate further -- I don't want to spend more time and lengthen this post even further without good reason.) It appears to me that I experience no EN thumbnail display context where pixel dimensions exceeding 300 could provide value in terms of additional visual information actually displayed in the thumbnail. Furthermore, I'm unwilling to expand thumbnail-candidate image dimensions to pixel counts potentially orders of magnitude beyond their maximum thumbnail display size simply to contort even further my workflow to EN's thumbnail selection limitations. I don't believe such additional image expansion would be in the interests of EN and its users either, since it would consume further space on EN's servers with data that represent "empty calories" useful only to compensate for EN's thumbnail-selection shortcomings. Based on my current note contents and note-creation patterns, EN desktop selects such inserted images as the thumbnail most of the time -- often enough for this practice to be worthwhile for me based on EN's current shortcomings in this department. FYI, my current iOS hardware consists of an iPhone 6 Plus and iPad Air 2. I tend to use "Snippet" view across all platforms. 1) My first observation seems to relate to a post from "icebox" on 09 Dec 2014 - 01:15 AM. I will start by discussing it in the context of the EN desktop app running on Windows. My recent EN usage patterns have included a subset of Web content selections for copying into EN that included extensive avatar imagery. In my case, such selections have more often resulted in a thumbnail display of an actual photo rather than the "'unknown' face" icebox refers to, but I believe the principle is the same. EN selects a thumbnail that has no relationship to the previously-discussed "largest smallest" algorithm in the context of the size of the images as displayed on the browser's native Web page view or in the corresponding content within an EN note. I'm not a programmer, but I'll speculate on what the EN program is doing -- perhaps it is evaluating image size based on underlying code (HTML? XML?) that (at least in some cases) reflects something other than the actual display size of the images on the source Web page and EN note body...or, in icebox's case, whether the image is displayed at all in the EN note body. Perhaps the source info EN responds to in connection with thumbnail selection is "original" image size as coded in the subject Web page or the linked URL, rather than to display size within the context relevant to the EN user. When images representing photos of actual people are involved, this behavior by EN does more than obscure relevant visual identifying info; it results in the "misleading" that "JMichael" refers to in his/her post from 10 June 2014 - 01:41 AM. I'm confident that many of us are faced with the decision of whether or to what extent to invest time and energy to re-conform at least some of our notes -- and perhaps also sacrifice some secondary goals for their content -- in order to try to compel EN to perform the thumbnail selection we desire. For me, preliminary visual cues to note content/context are important, so I'm one of those people. In my experience with pages such as those that cause this problem, there can be compelling reasons to retain the images, related links, and/or surrounding content (relying on the avatars for visual context) that causes inappropriate behavior by EN's thumbnail selection algorithm. My approach with such cases thus far has generally been to see if EN will select -- as the thumbnail -- the image I inserted that conforms to my current, aforementioned "note header" standard. If not, I'm usually not willing to waste my time trying to minimize collateral damage by systematically but "blindly" deleting secondary avatar images one-by-one in hopes that EN will eventually choose a thumbnail that doesn't constitute patently misleading information. (Such an approach would appear to be comparable to what "Evernote Support" recommended a user apply as documented in the post string attributed to "Lawlitta", "Evernote Employee", "Posted 25 June 2015 - 09:40 AM".) Instead, I'll either tolerate the misleading thumbnail or wipe out all the secondary avatar images in one fell swoop. 2) EN's thumbnail-selection shortcomings further confound my productivity due to the inconsistency I've observed in their application (or at least resultant behavior) across platforms. For the types of content I introduced in "1)', above, I've observed multiple instances where my addition of an image conforming to my aforementioned "note header" standard has caused EN desktop to choose it as a thumbnail, while the same note -- synced to my iOS devices -- has continued to select a misleading image that should not "trump" my header image based on EN's purported algorithm. As I mentioned above, I'm not a programmer; I don't know to what extent this behavior relates to programming code differences between the versions of EN I have installed on different platforms, and to what extent it relates to some difference in the way the note data itself is constituted on each of these different platforms. Either way, it exacerbates the negative impact of EN's thumbnail-selection shortcomings on my EN experience. Strangely, in these particular instances, I've observed the (inappropriate) thumbnail images on my iOS devices to be displayed with a vertically-biased aspect ratio ("portrait shape") and corresponding symmetrical vertical crop; on the desktop, I've become accustomed to circumstances in which EN will crop square images in note bodies when applying them as thumbnails, but only via a horizontally-biased aspect ratio ("landscape shape") and corresponding symmetrical horizontal crop. Like countless other posters to this topic, I acknowledge and appreciate EN's value to me, both in words here and through my continued patronage as a Premium subscriber. Thanks to EN -- the company and its representatives, both past and current -- for developing and supporting this product/service. Like many other posters (I suspect), I continue to use EN despite its weakness regarding thumbnail selection. However, I also preemptively assert that the information I've provided above does not constitute a solution to this problem, not even a partial one, not even an acceptable workaround. Any official EN representatives reviewing this information should not construe it as such. (I doubt any users not officially representing EN who review this post will deem it as such.) It should only be construed as yet another elaboration on / clarification of the problem; like many other posters, I can only hope the cumulative weight of posts to this topic will ultimately convince EN to substantially improve thumbnail selection, and to do so across all of the platforms/interfaces it supports. This is not just an issue of absence of explicit user choice regarding thumbnail selection, although I agree with the numerous other posters who believe this absence substantially reduces EN's effectiveness for their workflows. EN's avoidance of a substantive response to this issue over the past four (4) years has also resulted in a continuation of app behavior relating to thumbnail selection and display that is -- on the whole, and across supported platforms -- much less consistent and simple to infer/predict than the post from "emerick" timestamped 01 July 2011 - 02:42 PM seems to suggest. Even a solution as simple as applying the fist image in the note body as the thumbnail (perhaps subject to minimum constraints in pixel dimensions) -- either optionally (as the default selection or otherwise) or compulsorily -- would vastly improve my EN experience. This is substantively identical to or at least generally consistent with input from JMichael (Posted 16 July 2011 - 10:48 PM & 01 July 2012 - 05:41 AM), radiantlf (Posted 30 October 2011 - 12:51 AM), Designology (Posted 07 December 2011 - 12:32 AM), Gimpster (Posted 11 January 2012 - 10:56 PM), Richard Beddard (Posted 21 February 2012 - 11:38 AM), Mike Wood (Posted 30 June 2012 - 10:45 PM), chriszygmont (Posted 18 October 2012 - 02:44 AM), 2vet (Posted 26 December 2012 - 08:38 AM), siamesekitten (Posted 03 March 2013 - 10:53 PM), gdw35 (Posted 02 April 2013 - 01:17 PM), Jared (Posted 02 May 2013 - 04:12, 04:15 & 04:18 PM), StephenF (Posted 27 May 2013 - 02:17 AM), Kip Ingram (Posted 08 June 2013 - 04:41 PM), ideaprison (Posted 29 October 2013 - 09:41 AM), csjDK (Posted 16 June 2014 - 01:29 PM), Esben Sæderup (Posted 21 June 2014 - 01:35 PM), Spectrablue (Posted 13 October 2014 - 01:37 PM), mptpro (Posted 28 November 2014 - 01:15 AM), and TotheMoonAlice (Posted 23 June 2015 - 01:18 PM).
  5. I, too, would obtain substantial additional value from Evernote if its iOS app allowed me to (at least) view both date and time stamps for notes from days before the current one. One benefit for me would include the ability to identify the time on a given date that I made an observation, participated in an event, and/or conducted an activity associated w/an Evernote note I created. Another would be having time of day as one category of metadata available to me while "manually" searching (through visual inspection of my Notes list during scrolling). Entering/modifying "Created" and/or "Updated" dates and times would also be useful to me from time to time, although viewing the time values would be much more valuable to me. It is reasonable to expect that Evernote has multiple reasons to simplify their iOS implementation of their app relative to their desktop versions. However, I believe that they should no longer sacrifice both time-stamp metadata viewing and date/time-stamp metadata entering/modifying functionality to serve their simplification goals.
  6. I, too, would appreciate the ability to (optionally) search for Unicode characters (in addition to underscore, "_") outside general classes L and N within note titles and/or bodies. (My very limited ad hoc testing suggests such characters can be explicitly searched on when they appear in Tags.) One way this would serve me (and perhaps others) is by providing "search value" to the appending of a non-letter/number character as an abbreviated, symbolic modifier for a class of terms of repeated interest to me. This would allow for personalized classification with appended strings as short as 1 character, conceptually analogous to the pervasive use of pictographic icons in computer operating systems introduced about 3 decades ago. I acknowledge that such systems don't (as far as I know) provide for visual-based search based on icon appearance to find associated information (e.g., apps), and that system icons of this type are too free-form in appearance for such computer-mediated (rather than human-vision-based) searching to do much good anyway. However, Unicode-character-based symbology -- while not based on accepted languages -- can be much more rigorously and systematically applied, and is obviously potentially amenable to supporting computer-mediated, text-based searching. 'robe070's hashtag ("#") example is only one of many possible uses of this approach, albeit probably the most straightforward one given its ubiquity in Twitter. To illustrate, consider Unicode v7. I've inferred from trial and error that -- naturally -- not all of the ~27,000 characters I've imported from the applicable Unicode database into a Google Sheet will be accepted and properly displayed within the title, body, AND tag(s) of Evernote notes and across multiple Evernote platforms/interfaces. Still, consider that only ~18,000 of the aforementioned 27,000 characters are (generally) classed as L or N -- that leaves ~9,000 characters, or ~1/3 of the entire database -- outside those general classes. The "abbreviated, symbolic modifier" method I previously described might be esoteric, and I admit that only a tiny proportion of such characters (including "#") are explicitly accessible via typical physical and (QWERTY-based) touch keyboards. Still, I suspect that 'robe070', 'thebeefman', and I are far from the only three Evernote users who'd tangibly benefit from Evernote modifying their search methodology to allow explicit searches on at least some of those ~9,000 characters. Regarding the references in this topic to "Lucene"...I'm not even close to a software developer / programmer. However, to the extent I understood my recent quick scan of the Apache Lucene Project's documentation, it appears to me that this omission of all non-L/N characters except "_" relates to EN's particular implementation of Lucene, not the inherent nature of Lucene itself. If anyone more knowledgeable about that particular subject disagrees, please let me know. Finally, I've seen reference elsewhere to EN's beta-testing of a natural-language-type search process in its Mac client. If this is something that EN intends to ultimately pursue for Windows desktop, Web, and perhaps iOS clients as well, I recommend that its final implementation accommodate/append broader capabilities in explicit searching for non-L/N characters, even if that particular feature might be considered far from "natural".
  7. Omg! So much pain and suffering Ultimate suicide by evernote ...unless you're a Windows user, in which case the world (of Evernote note thumbnails) remains a profoundly disorienting place .
  8. Please consider enhancing the feature set for the PDF viewer applied to PDF files embedded in Evernote notes as viewed and interacted with from the Windows desktop Evernote application. For example, consider the dynamic content from the following Web page (courtesy of DPReview)...http://www.dpreview.com/lensreviews/nikon_18-55_3p5-5p6_vr_n15/3 ...for which the directly-relevant source code is... <p> <script type="text/javascript"> LensReviewWidget({ lensReviewId: "7", focalLength: 18, aperture: 3.5 }) </script> </p> Here is a "start" page I subsequently found for the aforementioned widget (again, courtesy of DPReview)...http://www.dpreview.com/lensreviews/widget/Fullscreen.ashx ... and here is the completed associated source code... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>dpreview.com - Lens Review - Fullscreen</title> <script src="swfobject.js" type="text/javascript"></script> </head> <body style="background-color:#000;padding:0px;margin:0px;height:100%;"> <div id="div_lensWidget" style="top:20px;bottom:20px;left:20px;right:20px;position:absolute;"> <div style="position:relative;top:50%;bottom:50%;margin-left:auto;margin-right:auto;text-align:center;width:420px;padding:10px;background:#111111;border:solid 1px #222222;font-size:10px;color:#cccccc;">The lens review widget is loading.<br/>If it does not load, please ensure you have <a href="http://www.adobe.com/products/flashplayer/">flash player version 9 (or later) installed</a>.</div> <noscript> <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0" width="100%" height="100%" id="swf_lensWidget" align="middle"> <param name="allowScriptAccess" value="always" /> <param name="allowFullScreen" value="true" /> <param name="wmode" value="window" /> <param name="FlashVars" value="stack=horizontal&reviews=&vis=&fl=&av=&config=LensReviewConfiguration.xml?1&fullscreen=true&lock=" /> <param name="movie" value="http://a.img-dpreview.com/lensreviews/widget/LensVisualiser.swf?9" /> <param name="quality" value="high" /> <param name="bgcolor" value="#000000" /> <embed src="http://a.img-dpreview.com/lensreviews/widget/LensVisualiser.swf?9" FlashVars="stack=horizontal&reviews=&vis=&fl=&av=&config=LensReviewConfiguration.xml?1&fullscreen=true&lock=" quality="high" bgcolor="#ffffff" width="100%" height="100%" name="swf_lensWidget" align="middle" wmode="window" allowScriptAccess="always" allowFullScreen="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /> </object> </noscript> </div> <script type="text/javascript"> var fo_lensWidget = new SWFObject("http://a.img-dpreview.com/lensreviews/widget/LensVisualiser.swf?9", "swf_lensWidget", "100%", "100%", "9", "#000000"); fo_lensWidget.addParam("allowScriptAccess", "always"); fo_lensWidget.addParam("quality", "high"); fo_lensWidget.addParam("scale", "noscale"); fo_lensWidget.addParam("play", "true"); fo_lensWidget.addParam("loop", "true"); fo_lensWidget.addParam("wmode", "window"); fo_lensWidget.addParam("name", "swf_lensWidget"); fo_lensWidget.addParam("FlashVars", "stack=horizontal&reviews=&vis=&fl=&av=&config=LensReviewConfiguration.xml?1&fullscreen=true&lock="); fo_lensWidget.useExpressInstall('/lensreviews/widget/expressinstall.swf');fo_lensWidget.write("div_lensWidget"); </script> </body> </html> I generated a PDF file for my personal reference from the aforementioned implementation of this widget. I used Adobe Acrobat Pro XI -- specifically, that application's add-on to Microsoft Internet Explorer (IE) 11 -- to do this. I used that add-on's "Select" feature to limit the PDF conversion to that widget. I've attached the resulting PDF file as 'DPReview_Nikon_Nikkor_AFSDX18-55mm3.5-5.6GVR_TestResults_Studio.pdf'. The file -- as I view it in Acrobat Pro XI -- appears to show all of the "baseline" content I see in the widget as I view it in IE 11. Furthermore, all of the dynamic responses to user input (via mouse hovering, single-clicking, etc. in this case) available when interacting with the widget in IE 11 appear to be available from the aforementioned PDF file as viewed in Acrobat Pro XI. The same is true for Acrobat Reader XI. In order to allow myself access to this dynamic content from the Acrobat apps, I needed to allow connection from the apps to both the widget host site (http://www.dpreview.com) and the Flash-serving site (http://fpdownload2.macromedia.com). The apearance of the corresponding Security Warning Windows are shown in attachments 'Acrobat_Reader_XI_ContentFromWebWidget_SecurityWarning_reWebURL_2014-07-23.pdf' and 'Acrobat_Reader_XI_ContentFromWebWidget_SecurityWarning_reMacromediaSite_2014-07-23.pdf', respectively. I subsequently embedded 'DPReview_Nikon_Nikkor_AFSDX18-55mm3.5-5.6GVR_TestResults_Studio.pdf' in an Evernote note from Evernote for Windows (desktop) v5.4.1.3962. I did so by using the [paper clip] button from the Evernote Button Bar. Not only is the aforementioned, user-driven dynamic content not supported in the inline PDF viewer; no widget content (dynamic or static) is shown at all. Only the Web page's default black background is visible where the widget should appear. I've attached a note containing only the aforementioned PDF file as a PDF printout ('Evernote_DPReview_Nikon_Nikkor_AFSDX18-55mm3.5-5.6GVR_TestResults_Studio.pdf'). I recognize that I could enable the "Always show PDF documents as attachments" selection in the 'Note' tab of the 'Options' tabbed dialog box accessed from the 'Tools' menu. I also assume that I'll never be able to view the Flash driven content through a PDF file on my iOS device whether I attempt to do so via the corresponding Evernote note or the "native" PDF file (e.g., via Adobe Reader for iOS). On that platform, the issue of application-level support for accessing and displaying the relevant content and accepting associated user input will presumably always be moot due to Apple's commitment to exclude Flash support on iOS. However, it would be more effective to access the PDF content from within the note via the inline viewer, even if the best Evernote could be expected to do to enable this among the two platforms I regularly use is to incorporate applicable PDF-related feature support in the Windows (desktop) app. DPReview_Nikon_Nikkor_AFSDX18-55mm3.5-5.6GVR_TestResults_Studio.pdf Acrobat_Reader_XI_ContentFromWebWidget_SecurityWarning_reWebURL_2014-07-23.pdf Acrobat_Reader_XI_ContentFromWebWidget_SecurityWarning_reMacromediaSite_2014-07-23.pdf Evernote_DPReview_Nikon_Nikkor_AFSDX18-55mm3.5-5.6GVR_TestResults_Studio.pdf
  9. Please consider enhancing textual formatting options available through the user interface. I acknowledge that one of the benefits and charms of Evernote is its relatively simple, uncluttered interface and small system footprint, and you've already incorporated the many of the options typically made directly available to users in popular textual/character-oriented applications available in a Windows environment such as MS Office and Windows apps. However, I have recently encountered situations where such additional features as overlining (basically the opposite -- position-wise -- of underlining), modification of vertical-centric paragraph formatting (e.g., inter-paragraph spacing), and column formatting would have been useful. Yes, overlining is an obscure and esoteric text (character-based) formatting option, but note that it is supported in open-source office suites LibreOffice (see attached JPEG file) and OpenOffice, and that it is part of W3C's CSS standard... 2.1. Text Decoration Lines: the ‘text-decoration-line’ property Name: text-decoration-line Value: none | [ underline || overline || line-through || blink ] Regarding vertical-centric paragraph formatting, there are times I copy a series of Web text excerpts into an Evernote note and find that a peculiar paragraph-spacing value has insinuated its way into the note, forcing itself on all subsequent note text. The same has been true for multi-column formatting. I have not (yet) felt deprived due to my not being able to apply my own inter-paragraph spacing settings or to generate multiple columns, I have found myself performing custom selections within the note to identify where unaffected regions are that I can "patch in" later in the note where the aforementioned imported formatting hs been forced onto all subsequent content. For these formatting issues where my primary interest is to back out of formats imposed by imported text, an alternative solution might be to make the "Simplify Formatting" -- which currently appears applicable only to the entire note -- applicable also to the user's selection of one region within the note. Thx for your consideration.
  • Create New...