Not a single one has gotten a response as to whether they’re going to be fixed or replaced on two, I’ve been told they won’t be fixed (TOC notes and macOS links). Meanwhile I have filed a dozen support requests for broken/missing features that are hindering me from getting my paying job done. EverNote-the-company is excited about “new things” coming next year. But this was a massive undertaking (based on my understanding of the tech debt), so it has ended up being more work than was anticipated. So I don't blame users who are frustrated. I understand that asking customers to sit around and wait is hard. But I can say that development iterations are greatly reduced in speed and I think I'm excited to see what comes in the next year. Again, Ian acknowledged in his recent blog post that the launches did not go as well as we hoped. Moving to Electron allowed that over trying to hobble along with the existing state of the applications. As Ian noted in his recent blog post, our goal was to start developing new functionality quicker, a top complaint from users. The decision to go Electron was made after careful consideration of all options. But we were in a place where having the native apps was slowing us down. Not to mention the enormous tech debt and having to make sure to support existing customers, APIs, etc.Įven when making the decision for Electron, everybody agreed native is superior. Trying to align those to have a unified launch experience/date was nigh impossible. 5 disparate development cycles requiring 5 separate QA cycles. Going to Electron allows you to reduce the development effort significantly, which was where Evernote struggled the most. You still have 5 separate code bases with 5 separate development teams coding in multiple languages. There were 5 products (Mac, Windows, iOS, Android, Web) and 5 product managers with 5 separate design teams.īUT, having a unified design does nothing towards the development of the actual product. I completely agree and this was something Evernote was severely lacking in. Unless they know of a way to work with Electron that I haven’t seen, I don’t know how the product will ever perform as smooth and precise as it did on my Mac with the legacy app. I love Evernote and have been a paying customer for almost a decade. I’ve seen it across all but the simplest of Electron apps. I am not surprised by the issues that have resulted. I am simply dumbfounded by their choice here, and have been since it was announced. A UI and UX team & their design principles can be shared across dev units within an organization. You can EASILY share UI guidelines that are built across all different platforms, and do so just as efficiently. In most instances, these frameworks such as Electron require so much extra code to account for the differences in each platform your compiling an app for, they typically defeat their purpose, when you get to an app the size of Evernote. Your app also becomes handcuffed to if/when the platform adds compatible ways to include new OS features well after their available natively. This notion that the only way to build a unified experience is through a third-party Web/JavaScript app compiler (Electron), which adds considerable bloat, and will never run as performant as an app built natively, is just absurd. In light of a recent Evernote blog post on the state of the product, I felt compelled to share my thoughts as a developer for 20+ years.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |