Jump to content
Due to limited holiday staffing, chat will be unavailable from Thursday, July 2 at 5:30 PM (CDT) to Monday, July 13 at 8 AM (CDT). This will allow us to reply to your email requests as quickly as possible. Thank you for understanding. ×

MikhailV

Level 2
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

2 Neutral

About MikhailV

Recent Profile Visitors

762 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. 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 .
×
×
  • Create New...