Jump to content

mz123

Level 2
  • Content Count

    94
  • Joined

  • Last visited

  • Days Won

    1

mz123 last won the day on December 17 2016

mz123 had the most liked content!

Community Reputation

29 Good

1 Follower

About mz123

Profile Information

  • Subscription
    PREMIUM

Recent Profile Visitors

3,598 profile views
  1. A similar issue, where an entire screenshot is blurry / low-resolution, has been occurring in the Windows Chrome Web Clipper for over 2 years now.
  2. You're welcome. I can see from my experience and others' that eventually something in Evernote's approach changed from "no old APKs" to "here you go, an old APK". I didn't expect a gracious reply and thank you - appreciate it. Note that I agree that a quick bugfix may be a big ask. I was advocating merely that Evernote make the old APK available immediately, via an update where the old APK is re-packaged with new version number. I don't think that's a big ask at all. Here's to better software coding, either way!
  3. Some counterpoints to your response: I suspect you were slower to ask for help. I asked for help, and over a week went by before I received a reply like you did. I suffered with the bug for 2 weeks in disbelief that it was taking so long for Evernote to act, then waited another week after contacting support before this solution was offered. The path to get to this workaround was painful. I was first offered no solution ("we're working on a fix"). After repeatedly asking for a previous version's APK or a refund, I was eventually offered links to a third-party APK download site by an Evernote employee! I understand software development too. Reverting to a previously released version immediately was (and still is!) the best solution. After all, support is offering exactly that to users. Within hours of discovering this bug and understanding its impact, Evernote could have simply re-released the previous APK as the next update. They still can, and should. They can then work on implementing a bug fix into the next release version at their leisure. I understand that new release development requires testing, etc. However, a re-release is not the same. Reverting code to a previous version is technically simple, and requires no additional development or testing. It's simply like an undo-change. Put another way, it's like simply delaying a release further, or pulling an unauthorized release. It doesn't require business analysis, QA, or dev ops, in more than a trivial way. There is no excuse for Evernote eliminating a mission-critical feature from what is arguably their most important platform, for an entire month (and counting). I don't care how much they innovate their software, or how much that innovation will be delayed by doing what I described above. If one can't search, the app is nearly useless to a large portion of users. New features and rapid development are nice, but they are not so nice as to allow the software to become useless to users for a month. So, I quite disagree with your post.
  4. With a bug this serious, Evernote should have rolled back code in its entirety to the previous version 1 hour after discovering the bug, in my opinion. If one uses Evernote as it was intended, designed, and marketed, it's simply unusable without a functioning search. One can't use a second brain if one has no idea how to find anything in it.
  5. Most will tell you not to install apps from third party sites, as they may contain malware. Evernote should make a downgrade (or an upgrade with the old code) available. There really is not excuse for this. Evernote made a video where they talked about customer focus. Letting this issue continue for so long without any resolution is very anti-customer.
  6. How can Evernote not fix this hours after it's discovered? This sort of problem is so fundamental, they should do a code rollback to the previous version. In the meantime they're releasing dark mode improvements?! Evernote: why?!
  7. OK, I wasn't aware of the nuance here, and in sum it's really odd. For starters, typing evernote:///view/... does not create a link that's clickable, whereas www.evernote.com/shard/ does. Android, and its apps, don't know what to do with a classic EN link in general. But.... I found that your approach works for me too, in the way you described. However, it's not going to work in most apps, and never works unless I first "prep" the link in Evernote. For example: If I copy the link out of an Evernote note in Android, it works as you described, but only in some apps. I can't paste that link into Google Keep for example, or a Google Doc. It works in my calendar app though. If I instead simply grab the URL directly from Evernote Windows "evernote:///view/...", without first pasting it into a different Evernote note, and share it somehow (in Google Keep, in Remember the Milk as text, or in a calendar event), it isn't even recognized as a link in Android, and it's not clickable. If I paste that text into Chrome Android, it simply searches for it in Google. Interestingly, if I paste the text of the URL into Remember the Milk Android, but in the URL field, it somehow now recognizes it as clickable and sends it to the Evernote App. My most common use case is actually #3. I never realized that a link might work out of the URL field, but not out of a note field. All other links are clickable out of a note field just fine. It seems the Android OS doesn't make evernote:/// links clickable, but Remember the Milk figures it out. I strongly suspect that's due to their behind-the-scenes integration with Evernote, which I actually did not use or even enable. I suspect many, if not all apps don't recognize links of the form evernote:/// - perhaps #1 works in some apps, such as our calendar apps, because some apps simply paste links without bothering to somehow validating them first. In other words, Keep, Docs, and other apps look at the clipboard and say "here's a link that's not actually a link, so I'll just paste the text part". Our calendar apps simply paste what's there, and it turns out the links are valid for the Evernote app. It would be great if you could validate the above to ensure things aren't different between our phones. Bottom-line: on my phone (and I suspect on yours too), Android and most apps don't know how to deal with evernote:/// and do not treat those as valid links. Some apps are the exception. On the other hand, www.evernote.com/shard is obviously a web link, and will be handled that way and intercepted by the installed Evernote app, providing a more consistent experience. So, standard links always work on Android, wherever you put them. Classic links only work if you first copy them out of the Evernote app within the phone (or within Remember the Milk's URL field, likely due to those companies' integration partnership).
  8. One note here... before I found the workarounds, I saw the button. However, to get the button requires me to be logged in with the browser. I'm almost never logged in there.
  9. Several problems (see higher in this thread for details): It doesn't in all cases. It used to never do so with the Windows app installed. It shouldn't today, with the Windows app installed.
  10. Now sure what you mean by #2 and #3. I mean links created when I select "Copy Internal Link", which look like this: https://www.evernote.com/shard/s3/nl/... By the way DTLow, I'm rehashing stuff here. Everything is spelled out in great detail in this thread: the problem, various workarounds, and disadvantages of the workarounds.
  11. The reason this topic is here, is that a Windows-specific function stopped working: the ability to open standard Evernote links in EN for Windows Desktop, rather than in a browser. Others suggested workarounds: Disable the new Evernote for Web and return to the previous version, or Use classic note links instead I use the first workaround, which works for now. Of course, as the old version of the web interface likely won't be around forever, I hope Evernote fixes this shortcoming before removing the legacy web interface. Here, I was pointing out that the second workaround doesn't work for me. It works fine on Windows, but fails on mobile. One of the core benefits of links is to enable sharing across platforms. The core problem is that Evernote Windows doesn't open its own links.
  12. I use Android. I don't know much about iOS. It doesn't work for me. So, I guess if Evernote classic goes away, I would be stuck with links that don't work on Android, at least if I want to link to Evernote notes from other apps.
  13. That may be the case for me too, but only in the Evernote app. Other apps don't know how to deal with the links.
  14. I disagree that this view. The problem with classic links, is that they only work in the desktop app. If I try to view them on my phone, for example, they fail. The previous behavior was best: open the link in the Desktop app if it's installed / available, and use the web otherwise. On mobile, use the mobile app if it's installed, and use the web otherwise. That makes complete sense, since presumably the reason I installed the desktop and mobile apps is that I want them to handle everything Evernote for me. Additionally, it's a standard behavior for apps in general, for links and files. "Hey, I'm an app that can handle this kind of file, or this kind of link, so I'll open it rather than send it to the browser". It's true of other mobile apps when viewing web links to services provided by that app (Google Maps, LinkedIn, Trello, etc.), and also for Windows with default files and protocols (tel: links, file: links, etc.) Evernote should be no different.
×
×
  • Create New...