Jump to content

Ian Small

Evernote Staff*
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Ian Small

  1. Hi all - I just realized we did not follow up in this channel as I had committed earlier about the most recent Safari Web Clipper release, although it's probably hard to miss with the big banner at the top of the screen. Nonetheless, here is the relevant announcement: A continuing thank you for your patience ian
  2. @hksmith I think it's safe to say we'd neither want you dead, nor in the water, nor any combination of both. As @DTLow pointed out above, we are expressly acknowledging that our modern web experience does not yet have all the functionality we'd like it to have, and all the functionality it needs in order for it to meet a reasonable bar for all of you. Things like reminders are an excellent example of the gap. Lack of support for nested tags is another. Missing features like this that are key to some folks' workflows are one of the reasons - but not the only one, I should caveat - that we've not yet formally made the modern web experience our GA release and become more enthusiastic about promoting people off older versions of our web client. That being said, the majority of our web users find the upsides of this newest version worth some of those compromises. It's our job over time to maximize the upside and minimize the compromises. To get there, we still have work to do at many levels in the code, including UX, functionality and plumbing. You've seen some of that in the investments we've been making in the new editor (which you can all experience now), in the new search implementation (watch here if you haven't encountered it yet), and in other areas as well. And with the new search implementation, you've seen us not just improve search, but also close the gap around creating and accessing saved searches - one of the gaps mentioned in the list that @DTLow highlighted in his post. As to your specific ask, we've already looked at various different ways to bring reminders into this experience. We're still discussing how and when to do so. But one way or another, we'll get there. Back to lurking ian
  3. Experts say: Yes, the refinement suggestions supplied in the menu are based on the current search scope. At the beginning, the scope is "All Notes". From that point forward, as you build a search iteratively, the search won't (at least, should not! 🙂 official allowance for product-feature-not-in-GA-yet) suggest something that isn't contained in the current scope. To @Jason Goldsmith's question, if you used the tag portland as your first scope refinement (however you enter it, by pulling it off the search menu or typing tag:portland), the suggestions provided should only be those that make sense in that context. To his point, he'd get food, tourism, accommodation, history, and transportation suggested as tag refinements. (He might not get all of them at the start because of space limitations, but as he started to type, they'd narrow in and get suggested.) . He wouldn't get sunshine as a suggested tag, on the assumption that it's unlikely that there would be a note tagged with portland *and* sunshine (herewith a formal apology to all insulted portlandians for that needless cheapshot; my excuse is that it's late on a Friday night). On the other hand, if he'd started his search scope with honolulu, sunshine might get suggested as a tag refinement. To a couple of @jefito's questions: First, at 4:54 (after the initial typo for tag:succlent is corrected to tag:succulent), you can see we provide the same filtering suggestions that we do if you'd typed "succulent" or "succ" and clicked on the tag in the drop down. Second, the focus for this design and implementation has been on providing a more powerful search capability and demystifying the search interface for the largest cross-section of users we can target. We wanted to avoid disempowering our super-pro users, so we made sure that the advanced search syntax still works. And where it made sense, we tied the advanced search syntax back into the interactive mode. What we haven't done (at least at this stage) is try to wire some of the suggestion and auto-completion capabilities into the middle of entering advanced search terms - so, as you pointed out, couldn't we have either offered to auto-complete tag:succ into tag:succulent or auto-correct tag:succlent into tag:succulent? Answer, yes, of course; but at this point that's not where we've invested the engineering effort. For better or worse, that's been a conscious decision and how we've tried to accommodate both worlds right now at this point in redesigning and improving search. We need to see how this design plays in the real world to figure out where we should next invest energy. We do have some further work already queued in the hopper to fully finish what we view as the first full phase of this work, but it requires more heavy lifting in the back-end before we can wire it all up, so it's waiting on a much longer pole. In the meantime, we want to make sure what we have is working well, make sure we continue to tune it, observe performance in the wild and tune/improve as needed, and learn at scale in the real world to determine the next most impactful place for us to focus our search-related energies. All in all, search occupies about 1/3 of May's time across her part of the product function portfolio. So it's a big, ongoing deal for us and for her. Back to lurking for real this time ian
  4. Stacey - If I understand your question correctly, I think the answer is "yes". If you look carefully at this part of the video: https://youtu.be/_ZJqSR_MWmw?t=218 you can see the option to save as a shortcut as well in the dialog box allowing us to save the search. If that's not what you mean, please ask again! Back to lurking... ian
  5. Hi Everyone - Following up on on my post from Thursday night... We snuck in another build/review cycle over the weekend when our QA team, who have been continuing to validate our candidate releases over the past days, found a bug that merited our holding the release. As of this moment, Apple has approved that most recent build and we have released it to the App Store. As you may know, it takes a while for builds released to the App Store to propagate through to global availability, so we anticipate that it will be visible to all of you by Tuesday morning, likely at this URL: https://apps.apple.com/us/app/evernote-web-clipper/id1481669779?ls=1&mt=12 If you are a Safari web clipper user, our marketing and customer support teams will attempt to reach you directly to inform you of the release. And there will be follow up communications tomorrow detailing the complete list of the features in (and not yet in) this first, reduced-functionality release of our Safari 13-compatible Web Clipper. I apologize again for our taking this long to get to this first release. We will be continuing to push on our end, working to fill in the remaining gaps and fix any bugs we discover until we once again have a full implementation of the Web Clipper in Safari. More info on those subsequent releases to follow in this channel when we have something useful to say. ian
  6. Hi Everyone - Following up on on my post from Tuesday... As you may have guessed by now, our first submission to the App Store was bounced back to us by Apple, as they identified a number of (non-bug) issues they wanted us to fix before they would approve it. We have fixed those issues, and have submitted an updated build for their review as of a few hours ago. This set of posts from me has been pretty extreme in terms of transparency with where we are in the process, but I think in the circumstances this is the right way for us to communicate with you. As before, I have to point out that the review process for App Store submissions is a bit of a black box, both in terms of how long it takes and whether a submission will get through successfully, but we are hopeful that this build will meet with Apple's approval. Finally, we will post again once this first version of the Safari 13-compatible Web Clipper is available in the App Store, including a complete list of the features in (and not yet in) this release. And we will follow up with additional posts as we proceed forward into the subsequent releases that fill in the gaps and fix any bugs we discover until we once again have a full implementation of the Web Clipper in Safari. ian
  7. Hi Everyone - I’m following up on my post from Friday. A few hours ago, we submitted an initial, reduced-functionality release of our Safari 13-compatible Web Clipper into Apple’s review process. As some of you may know, the review process for App Store submissions can be a bit of a black box, both in terms of how long it takes and whether a submission will get through successfully. However, given how long it’s taken to get to this point, I thought it was appropriate to let you know that we are making concrete progress towards having an initial Safari 13-compatible release of our Web Clipper in your hands. As I have said previously, this first release will have reduced functionality. In particular, while most of the Clipper’s core functionality is included in this release (e.g. all clipping formats, screenshot and annotate capabilities, support for notebook selection, tagging and remarks, as well as PDF clipping), there are a number of features that have not made it into this build. Any one of these may be core to your particular workflow, and may result in this initial, reduced-functionality release not living up to your expectations. To that end, we have not stopped working. Our intent is to fast-follow this initial release with subsequent releases that fill in the gaps and fix any bugs we discover until we once again have a full implementation of the Web Clipper in Safari. We will, of course, post again once this first version of the Safari 13-compatible Web Clipper is available in the App Store, including a complete list of the features in (and not yet in) this release. And we will follow up with additional posts as we proceed forward into the subsequent releases. ian
  8. Hi Everyone - I’m following up on my post from ten days ago. In that post, I had indicated that we were trying to get an initial, reduced-functionality release of a Safari 13-compatible Web Clipper into your hands this week, but that there was still significant work remaining. Today is Friday of that week, and clearly we have not met our goal. We have a working build, but it is not yet release-quality. We are continuing to work on bugs, on stability and on CPU utilization issues in order to converge on something releasable. We will be working through the weekend. I’m sorry that it is taking this long. As explained in my original post, it is not as simple as recompiling, and we are encountering more challenges than we expected. We will provide another update next week. ian
  9. I'm sorry that we were not able to get a fixed/compatible version of Penultimate fixed prior to the GM release of iPadOS. The process for us to fix the iPadOS incompatibilities proved trickier than it should have been. A new release of Penultimate that is compatible with iPadOS was submitted into the App Store review process a few hours ago. As some of you may know, the review process for App Store submissions can be a bit of a black box, both in terms of how long it takes and whether a submission will get through successfully. But I thought it was appropriate to let you know that (fingers crossed) we are making progress towards rectifying the problem. We will, of course, post again once an updated version of Penultimate is in the store. ian
  10. Hi Everyone - First, I want to apologize that we're all here. Because you’re rightfully complaining about something that should never have happened. I take ownership of it. This year for us has been all about making very hard decisions around competing priorities, and on this one, we erred. We had expected that Apple would release Safari along with macOS Catalina later in October. When Apple released Safari on Sept 20th, we were surprised, we weren’t ready, and we ended up leaving you out in the cold. Even with the release date being pulled in, that shouldn't have happened. Apologies aren't worth much compared to actions, but know that you have my apology for this. Prior to the 20th, we had thought we were on track. Part of our engineering work was focussed on the changes Apple had made in their plugin architecture. But another part of the engineering work was focussed on re-plumbing a large chunk of the web clipper internals to match other work we are doing across all of the clients in support of improved reliability and sync. Because of the way the engineering work had been structured, when Safari 13 came out, we didn't have a releasable set of code that we could quickly bundle up and get into the catalog. Instead, we have had to re-order the work to get to something releasable, with the goal of getting you all back on a path to a fully-functional Web Clipper in Safari as soon as possible. So as has been suggested above, we will be first releasing a reduced version of the Web Clipper for Safari to deliver you core pieces of the functionality you are currently missing. That first release will not be a complete replacement of all the functionality that works in Safari 12 today. We will fast-follow that initial release with subsequent releases that fill in the gaps until we once again have a full implementation of the Web Clipper in Safari. Our goal is to have that initial release into your hands next week, but I should underscore that we still have real work to do to get to a sufficiently stable build that we are comfortable releasing. As you are all probably aware, there is an entire rollover of Apple’s software platforms taking place in a 45-day period at the moment. That's been challenging to manage. If I could go back to do it all over again, we would have been ready with the Safari Web Clipper. Which means there are lessons for us to learn in balancing priorities. I apologize again that we didn't get it right. We are taking all the actions at our disposal, including literally working around the clock to get the software you need back in front of you again. ian
  11. Shortest response to all speculation above: we have been investing for the last several months in replacing the plumbing in client apps, including in the modern web experience. When we are done (we aren't, yet) this will mean a common codebase shared across all the clients for cloud-client functionality such as sync, which should help us both isolate and stamp out bugs as well as driving more consistent behaviour across any user's Evernote experience that spans multiple devices. None of the previews put out to date incorporate any of this work, which is foundational to implementing the local data store for desktop and mobile clients that we all know and love. We plan to shoot a Behind the Scenes video that talks about the new plumbing, but the architect we need for that is ... ahem ... busy right now, or else you would have seen it before this one! Side by side installations on desktop machines of the beta and of a current production release will have distinct local data stores; you will be able to use both at the same time (I do that, right now). Back to lurking ian
  12. Thanks for the feedback. I suspect a part of the vertical spacing on mobile is driven by a desire for each item in the list to be easily selectable, and the reality that some people (like me) have relatively - um - broader fingers than others. (Otherwise known as the "fat finger problem".) . That being said, completely understand the underlying impact on information density and will make sure that the point gets raised and considered. Re the grey, I'm assuming you are reacting to what you saw in the video, not to an actual build or similar screen you saw somewhere. I say this because the relative contrast that gets picked up and displayed when we make printouts, stick them on a surface, and then shoot them again with an HD camera is not all that representative of what it actually looks like on a mobile screen. (Limitations of the quick-and-dirty production process for the Behind the Scenes videos.) . If you're reacting to a screen in your current mobile app that you think is representative of the contrast problem, please let us know which screen it is so we can assess if it's similar to what we are currently building! Thanks.
  13. Unfortunately, it's an architectural problem due to constraints in the underlying infrastructure, not a simple matter of adding a setting. One of the things we are working on this year is reworking a significant part of the infrastructure to give us more reliability, more scalability and - what matters in this case - more flexibility. Once we have that flexibility, we will start to explore what to do with it. -- ian
  14. My philosophy is pretty simple: get Evernote back on the path of developing and shipping quality software, use that as a foundation for accelerating customer-focussed innovation, and thereby put the company onto a sustainable growth trajectory - a trifecta that is ultimately the best combination of things that we can do for our users. All of our community knows that each of those is an undertaking - which makes it easy for me to be transparent with you all about the effort involved, and to involve you all in the process we're going through this year via the Behind the Scenes videos. As I said in January's blog post, we're going to make the product we all know and depend on more worthy of our ongoing affection, although I recognize that in navigating this process we're almost unavoidably going to disappoint some folks based on the places we focus and the choices we make. Our commitment to early beta testing, along with early disclosure of our direction through the videos, is helping us course correct and identify unanticipated challenges as early as possible in the process. Finally, the company continues to be on sound financial footing, getting even sounder this year. We're a private company, so it's relatively easy to throw a bunch of fud around concerning our financials, but two key facts speak for themselves: First, since the statement quoted above that Chris made in 2016, we haven't raised any venture funding. And second, we're still here. A rational interpretation of those easily confirmable facts, coupled with the observation in the New York Times article that I expect us to be profitable on an annual basis for the first time this year, would be that over that time we've been successful in managing our burn rate against cash reserves, and that we're now growing up into profitability. While I know that it's sometimes more entertaining to spin more elaborate theories, it really doesn't need to be - and more importantly, it isn't - any more complicated than that. I continue to appreciate the patience of every one of our users while we work to create a better Evernote, the Evernote that they deserve in return for their commitment. Back to lurking now.
  15. @RavBoy... always lurking. But also not inclined to make commitments until I know we are going to deliver on them. Trying to get us into the underpromise and overdeliver habit, which is harder than you might think! Right now we are 100% focussed on trying to make the existing Evernote we have work better, by stamping out bugs, unifying the codebase, and making the Evernote experience more coherent and more consistent across devices. Hence the focus of pretty much all the Behind the Scenes videos so far. That being said, let me take your specific question under advisement.
  16. Good catch, we should have said "Undo" instead of command Z. So it is the Undo equivalent. Sorry for the confusion.
  17. Fair feedback. As we go forward, we will try to do better at being explicit at messaging some of this. There are some challenges to this, of course: Sometimes, it's the feedback we get in the preview or beta that tells us what features need to be prioritized and implemented (either from our punch list, or features which were on the bubble, or revisions/extensions/modifications to what we've already shipped). We learn through the preview and beta process; there are multiple concrete examples of this happening already with the new note editor. We all use different parts of Evernote so generally warning people off a preview or beta version because there are missing capabilities ("there are missing capabilities so use the current version") is hard to do, and misleading - because for user A there may be no missing capabilities at all, and for user B there may be huge gaps. User A gets warned away and misses out on an improved version. User B doesn't try it and give us feedback we may need. In running the preview or beta programs, in an audience the scale of Evernote's, we have an (understandably) large range in software knowledge amongst our user base. Putting a bounding box around a preview or beta in language everybody understands can be challenging. For instance, during the editor preview, we had no shortage of feedback about non-editor issues. And finally, if we have a robust, bug-free implementation that may still be missing some key features, from the standpoint of a new user - it is "complete". Because they are not missing the capability they never used. For obvious reasons, we'd like to get those new users on to the newer versions. None of this takes away from some underlying truths in your feedback. Independent of this thread, we have already been thinking about ways we can improve our beta and preview programs, because we know we have work to do to improve in this area. Thanks! ian
  18. Hi all - First, Shane's question relates to the new "checklist" feature which was demonstrated in the second Behind the Scenes video on the new note editor. (Hint: if you haven't seen that video, go watch it now, none of this thread will make sense otherwise! I'll wait until you're done.) Internally, everyone at Evernote can participate in testing by "dogfooding" new builds, so we've all had access to the checklist feature for a while now as our development and design teams work out the kinks in that and other parts of the new Note Editor. So for Shane, it was a reasonable followup question to ask me about one of the features we demonstrated in an earlier BTS video - a feature which created a lot of response from the community. Second, to try to help sort out the apparent confusion around "betas": The Evernote web beta - what I tend to refer to in the videos as the "modern web experience" - is broadly available to any Evernote user and has been in place for about a year now. We still label this build beta because we do not view it yet as feature complete - there are a few key features missing before we would consider it our GA web experience. Nonetheless, as you've seen in a number of the videos, the Evernote web beta is what we are using as the basis for our forward-looking web work. A preview release of the new note editor has been available by invitation only (and under NDA, which is why you haven't heard about it broadly outside of the relevant Behind the Scenes video) to a relatively small audience for the last several months. Over that period, we've been collecting feedback and modifying our implementation in response to that feedback, working on bugs, and converging on performance levels that we are happy with, all while continuing to work through the feature punch list which we believe (based on the feedback we have received to date) will constitute a complete version. At this point, the new note editor has been released as an optional beta to a small % of users who are using our modern web experience (the Evernote web beta). So, as some posts have commented above (and shown screenshots), if you are using the Evernote web beta, you may have access to the note editor beta in the bottom right corner of the window. Early versions of the new note editor have also been bundled into preview releases of an early Windows client, released to a very small number of users by invitation only (and also under NDA). At this point, there is no other way to get access to the new note editor. We are not looking for individuals to sign up to the note editor beta at this point. We have transitioned from small numbers of individual users invited one-by-one to the preview into small percentages of the entire Evernote web user population being given access to the beta. We still have a lot of work to go for the new note editor to be ready for broad release; we appreciate your patience while we continue to work on bugs, performance, and remaining functionality. Third, you can expect *more* betas, not less. One of the things I've been pretty consistent about in our communications is that we're adopting a posture of testing everything we're working on - from very early stages where we test design mockups with individual users, through to very early prototype builds that we test under NDA on an invitation-only basis (thanks to all of you who have been participating and helping in one or more of those), through to phased beta rollouts to larger segments of our audience - all of which happens before we go GA on a particular component. We have restructured the way in which we do development at Evernote so that multiple subsections within the product can be driven independently, which in turn means that we can beta different "parts" of the product independently. Our ability to beta subsections of any build independently of the rest is something that you will see more of in the future. It's part of what we need to be able to do in order for Evernote to return to innovation at speed. Fourth, with respect to tags, my Spidey-sense detects the beginning of a small-scale twister as members of the community, with the best of intentions, take two sentences I said in a video and start to extrapolate what they could possibly mean. If there is an actual twister, it's always wise to take cover. But at the same time, we should probably try to avoid creating man-made twisters when it's not really necessary. In order to attempt to defuse this twister mid-formation, let me re-emphasize what I said on the video: (1) tagging is super important to a big chunk of our users (2) tagging is supported in wildly varying ways across different devices (just try Android vs. iOS, if you don't believe me) and (3) we'd like to take the best of tagging from across various devices and make a more consistent, coherent tagging interface across all devices in the Evernote family. What I specifically didn't say: that we were somehow going to rework the theory of tags. No. Not happening. Fifth, one more observation that I suspect is generally applicable beyond this particular thread: if I say that one of the things we're going to focus on in an *upcoming* episode of Behind the Scenes is topic X, and that episode hasn't aired yet, it's probably a safe bet that whatever you can see in a production version of Evernote you have downloaded today regarding topic X is probably *not* representative of what we're going to talk about. After all, we wouldn't need a Behind the Scenes video series for that... we'd just point you at the software. Hope all that is helpful. I'm going to go back to lurking now, and to lighting off fireworks. To those of you reading this from the US, happy holidays! ian
  19. Hi everyone - Dropping back out of lurking mode to provide some additional insight and to reflect on some of the threads above…. There is lots of valuable feedback in this discussion - thank you! I’m sorry if we have disappointed some of you with a perceived lack of responsiveness in the comment threads on these videos. As you would probably expect, our top priority is listening for input and watching for new insights that emerge from these forums and also from all the other community and social mechanisms through which these videos are distributed. During initial design, we focus on talking to and learning from individual users. When we move into preview releases, we engage one-on-one with tens and hundreds of users. As we ramp tests to thousands, tens of thousands and ultimately into millions of users, we start looking increasingly to quantitative data to inform how successful we are being because the conversation doesn't scale otherwise. That’s just the simple mechanics of how things need to work at the scale of Evernote. Concretely, the new note editor has been out in preview release with select Evernote web users for the last 75 days, ramping from a few hundred users trialing very early builds to now thousands of users kicking the tires in a larger-scale (but still early) beta. In the private discussion attached to that original preview program, the conversation around some of the same topics raised here has been intense, resulting not just in bug fixes but also in changes in design and implementation that we are still continuing to work on as I type this. Understandably, we have focussed our energy on going back and forth with and supporting users who are evaluating this build for us in the wild. (Some of you on this discussion are also involved in the private preview program discussion; thank you for your feedback and contributions there!) This is not to say that we don’t value your responses to these videos. As I said above, we read every one to look for new insights and observations. In general, I think that the early response to the first few Behind the Scenes videos has proven that our decision to start communicating with the community through this video mechanism has been a good one. However, I recognize that as we increase this style of communication out to you, it naturally bumps up your expectation of our ability to be able to engage both interactively and on a lot of fronts at the same time. We’ll do our best to engage as we are able, but our priorities internally are clear: First and foremost, we need to focus on shipping quality software that delivers the more coherent and consistent Evernote experience that I blogged about earlier this year. We are still relatively early in that process; we have a long way to go. When we are able to engage, we try to prioritize interactions that inform us of how to refine the software in flight, or to identify and eliminate bugs. That means we won’t necessarily be able to circle around to catch everyone up across all the different communication channels and all the threads. Apologies. And finally, I want to get us out of the habit of making promises we don’t meet. I am not a fan of making commitments we're not 100% sure we can deliver on. So unfortunately that means most of your questions about additional feature X, anticipated delivery date Y, and what about Z - no matter how reasonable! - are likely going to go unanswered until we can back up an answer with facts, or better yet, software. I truly appreciate your ongoing patience with us while we focus as much energy as we are able to muster on building a better Evernote for you. We are trying to test everything we are doing early and often. And we continue to listen to the feedback from those tests and to evolve in response to that feedback. Finally, for those of you who have stuck with this post this far… we know tags are super important to a significant percentage of our user base. (As an aside, we’re trying to improve support for them on Evernote implementations where tags are currently and inexplicably somewhat second-class citizens.). Tags in the modern Evernote web environment aren’t hidden behind a click. They have always been shown at the bottom of the note editor screen (a particularly observant s2sailor noticed this in the video - full points!), which is different than where they are on the Windows build or on the Mac build. There are advantages to this, and as has been observed in this thread, there are also clearly some disadvantages as well. This continues to be a source of ongoing discussion internally. Going back to lurking now. And probably shooting another video in my copious spare time... ian
  20. I really will go back to lurking soon, but while we're at it... To your (1), I will observe that one of the things we showed in the video was the ability for to type the first few letters of a tag or a notebook, have that tag or notebook be automatically suggested, and add it as a filter (eg. "Mexico" was a tag). I understand that incremental search may not be up your alley, but I suspect that for most users, auto-matching what you are typing to possible tag names, notebook names, space names, recent searches, etc. is faster, more interactive, and likely more effective than needing to type or pick "tag:" or "notebook:" first, followed by auto-matching and picking. Our goal is to design for the breadth of the constituency (both paying and non-paying, although we pay the most attention to paying users and those who are likely to become paying users). I completely understand your mileage on a given design approach may vary. To your (2), obviously this is a super power user capability. We have been looking at various options around what the default search logic is, and we have contemplated what full boolean logic would take. One of the things you'll find about me is that I don't make promises that I don't know that I'm going to deliver on. In this area, while we have been and are looking at it, no promises at this point. Thanks for investing the time to respond. -- ian
  21. At a high level: web, mac, windows all roughly the same. Android, iOS roughly the same. Math left as an exercise to the reader... -- ian
  22. Hey gang - There is some useful feedback in this thread which I have read with interest. Thank you! There are also a lot of concerns raised, whether it be feedback to the specific content we showed, or all sorts of interpolations and extrapolations built off what we showed (and in some cases, what we didn't). I don't have time to respond to every possible angle raised in this thread, but here are a few quick responses: 1. Roughly 12% of Evernote usage is on web sessions. 2. No one ever said anything about making Evernote a web-only experience. Just because we demo a set of improvements to search on web (which is the least adequate search experience, btw) doesn't mean this is the only thing we are working on. In a series of videos that may well have a lot of episodes by the time we're done (depending on the response we get, I guess), we judged it to be a reasonably approachable initial subject for a first video. Why? It's relatively easy to understand. It's visual. 3. Following up on #2 above, we are NOT planning on eliminating Windows and Mac versions of Evernote with local stores, nor Android and iOS versions with local stores, etc. Being able to use Evernote whether online or offline is a major feature/benefit and in a million years that's not going away. Of course, having a local store would be even better if sync was fully robust. Working on that. 4. Having the kind of interactive search capability we outline here doesn't mean we're taking away your power search capabilities. It means we're trying to find ways to (a) more quickly get to the content you're looking for *without* needing to know quite as much of the search instruction arcana (b) give more people more powerful search tools (c) get there in fewer keystrokes. I'm sure we'll get some things wrong along the way, but we're trying to have our cake (improved UX, improved relevancy, more interactive search tools) and eat it too (powerful command line syntax) on this front. 5. As I said in the first video in this series, some of what we choose to show in this series won't relate to a problem you in particular are facing. Hopefully some of it will. I recognize it's frustrating if the first video we drop doesn't relate to your top pain point, but you can rest assured that there are others amongst our millions of users who do. Otherwise we wouldn't be working on it. We can only do one topic at a time. 6. One of the reasons we prototype a lot of new stuff on the web first is because it's absolutely the fastest way for us to design/test/validate/deploy something new to a limited set of customers in order to get a feedback loop going about a particular design direction. As I said in the very first video, we are trying to test - with users, live in the wild - as much of what we are working on as we can prior to release. If seeing what we're working on in a web setting disturbs you simply because we are showing a concept in a web build, I'm guessing that for your own peace of mind, you should probably stop watching much of the Behind the Scenes series of videos. 7. If you *do* get invited to participate in a Preview release of some kind, as part of that we will point out to you that Preview is definitionally pre-Alpha. Which means more than "it's buggy". It means it's not even close to feature complete. It's not performant. It's so early there isn't a proper name for it. But if there's enough in there for us to get directional feedback early in the process, we will do our best to put it in front of some users, live and in the wild. Because the earlier we get feedback, the better chance we have of being ultimately on target. All we will ask of you is not to pre-judge the eventual release of something by its Preview release, a release that may come months before we lock down direction, functionality or performance. Previews usually come along with non-disclosure requests, too, because they're so early. Which is one reason you (appropriately) don't hear a lot about them. I'll return to lurking now (and get back to my day job, which ultimately is where I have the best chance of generating value for you all). Thanks for watching, and for caring. I recognize that the last part - that you care - comes through in every comment. ian
×
×
  • Create New...