Jump to content

StuartG

Level 2
  • Posts

    25
  • Joined

  • Last visited

Everything posted by StuartG

  1. @Shane D. if I might make a suggestion, you have the means here in the forum to at the very least acknowledge major issues like this. A sticky thread as soon as you become aware of something like this would reassure users that it was known about by EN. Regular updates to that thread, even if it's to say it's still under investigation would let people know it hadn't been forgotten or brushed under the carpet. You'll of course have a mix of technical knowledge on here, but posting the level of information Tech Support provided to me is genuinely helpful and may be a source of input to resolving your issue via the goodwill and enthusiasm of your users who want EN to work. It may invite further criticism from some about the time taken to fix it, but I feel transparency is key here - support tickets are 1-to-1 and don't share the knowledge wider. If you need an example of someone who does this well, look to Zapier and how they communicate their status and problems they encounter.
  2. I've been talking to EN tech support about this, and they're happy for me to post part of our discussion which explains the issue: The issue was first discovered after a Chromium depreciation which blocked our access to the CSS stylesheets. While we do release updates regularly on our Android platform, our updates did not contain any changes to our clipping functionality despite many claims that this was caused by one of our latest updates. After the Chromium depreciation, we noticed an increase in reported issues where clips were failing. In some instances, users were reporting every single clip was failing. As a temporary workaround, we released a hotfix that would clip the text of the webpage without the CSS formatting so that at the very least, the text could be viewed. This would only happen if the clip would have failed. Instead of the failed clip, a stripped version would be added. We did not have an accurate time frame on how long this would take to resolve and were expecting the worst. Since the issue was first reported we have been working diligently on getting an update out that would resolve the issue. We are currently in the process of releasing a beta version that contains what we hope to be a fix. The more detailed explanation makes much more sense to me: not a EN-initiated change which went wrong and can't be reverted, but an Android change which they're trying to work around. Being open about this is more likely to gain understanding from the community here IMHO. I've tried the beta version (8.0_beta2_4107) this morning but there's no change, but that may not be the version with the fix.
  3. If my development team gave me that answer I'd laugh at them trying to pull the wool over my eyes! Granted the clipper wasn't perfect on Android, and the 'clip failed' was annoying, but if you've got something that works with 90% accuracy 90% of the time, replacing that with something that works with 20% accuracy 100% of the time seems a strange decision. Thanks for trying to improve it but you have broken this. It's not acceptable to break something then just say "tough, we might fix it sometime in the future"
  4. Still a complete mess, still having to reclip everything on desktop. Here's a captured tweet, article web pages similar with little structure or non-text content.
  5. I've always wondered whether the clipping is actually done on Android or just the URL is sent to a server to sort it out. It is incredibly slow though, and I do get different results, e.g. articles from medium.com always only seem to clip half the page when done from my phone. It does slow everything down when you have to double check all your clips even when it is working - time for an overhaul Evernote?
×
×
  • Create New...