Ian Small

@Claudiofpiga Thanks for the video - it helps me see (and understand) exactly what you're talking about. I suspect the issue is the relatively small size of the "note name" target as it appears in this view. (Targets on touchscreens need to be relatively larger because of fingers are less precise pointing devices than mouse- or trackpad-driven pointers.) But I agree that there should be a way to get to the note in some way from this view. Not sure whether this is easily achieved or not, but happy to look into it. Back to lurking ian

Strictly speaking, one can add the task to any note you like through the Tasks drawer (not just to the catch all note). Leaving that aside, I understand that if one is sitting in Evernote and wants to create a task with supporting context, the fact that you effectively accomplish that by creating or going to a note rather than by creating a task is not what naturally springs to mind first. The way I look at it is that there are roughly three key flows: I'm making a task with self-contained context (eg. a one-liner like "Follow up with Mary about release status"). With Tasks v1, we do this pretty well from multiple starting points within the app (although we have lots of ideas for making it even better) I'm creating note content and want to create a related task (eg. I'm making meeting notes and am creating tasks as I go). With Tasks v1, this is incredibly smooth and easy. I'm making a task and it has related note content that I need to write down all at the same time. This flow is a little awkward in Tasks v1 and gets to your point above. People coming from dedicated task managers tend quite naturally to think of flows 1 and 3, and discount the value of flow 2. Our first goal, though, is making things better for people who already use Evernote for their to do's. (Why? Because they are our first users for tasks, and also because we know that with Tasks v1 we do not yet have the full suite of functionality that dedicated users of task management apps are likely to expect, like recurring tasks, sub-tasks, the list goes on.) For our first audience, flows 1 and 2 hit closer to home. I am not discounting the value of flow 3, just explaining how we've ended up where we have. It's clear that we need to come up with a way to achieve this reverse flow (flow 3) with more finesse than we have. I don't think the answer for Evernote is to put a small-scale note box in the task (thereby creating yet another place for note content to live, another mini note-editor, another search target, another ..) Instead, it's to somehow simplify and streamline this particular flow. I think it's going to take some thought and I suspect it involves revisiting the affordances through which you create tasks from the Tasks drawer along with the design and modality of the Tasks drawer itself. We know we've not got that 100% right for a number of reasons even for flows 1 and 2, so that doesn't bother me. Bottom line: I hear you. I don't think it's a massively low-hanging piece of fruit just waiting to be plucked, but I think puzzling it out is a worthwhile use of our time. We will noodle on it as we keep learning about what's working and what's not, and as we think holistically about the evolution of the design. For Tasks, we're just at v1, after all. 🙂 Back to lurking and noodling, ian PS. I'm not surprised your wife was unimpressed. Honestly, she's in the right.

We are aware of this limitation we introduced – needing to pick the template before entering the title – and we will resolve it. The backstory of why this undesirable side effect happened is entirely too technically arcane for me to try to relate, so I'll skip over that part. The most important thing to relate is that we recognize the problem, a fix is in progress and is scheduled for one of the next few releases. For clarity and to try to avoid initial disappointment, at this point we know for sure that the fix will not make the next release (apologies). Back to lurking, ian

It's probably useful to observe that we fully understand the use case for sub-tasks, so you don't need to convince us of why sub-tasks would be useful. And I think it's also fair to say that the way for us to make sub-tasks work is to make task hierarchies (including sub-tasks) really work properly, not to glue some other set of artifacts together to kind of make sub-tasks work. Like most things, doing that well and making it easy to use is not simple. In the meantime (however long that meantime may end up being - I don't actually know the answer to that right now considering the copious punch list of potential improvements and enhancements to our Tasks v1 implementation that are competing for our attention), it is both inspirational and useful to us to see how folks come up with ways to use the rest of the structure of the note and the existing capabilities of Tasks to provide some sort of crude interim solution. Thanks for sharing with us. Back to lurking ian

We ask for the activity log because it provides us a way to understand in detail what the app was doing when you experienced a problem. All the geektalk that's included in it lets us understand what parts of the code were executing and whether the app was encountering problems internally, all of which are useful clues to help us isolate an underlying issue. Yes, activity logs can contain some private information - which is why we explicitly point that out. You are more than welcome to review the activity log before you send it out to see if you are comfortable with it, or to delete note names etc. I should observe that if you delete whole lines or sections from the activity log, you're probably rendering it useless for us - because we won't be able to follow the execution of the app through the missing lines or gaps. Ultimately, without activity logs to analyze alongside user reports, it is usually virtually impossible for us to diagnose technical issues that users are encountering. At the same time, not all issues require activity logs. If you are contacting us to ask about a UX/design problem, rather than some sort of unexpected, inconsistent or faulty behaviour in the app itself, then a series of well-chosen screenshots can probably serve to illustrate your point. You may want to blur out parts of those screenshots if they contain private information. But in these cases, the old saying "a picture is worth a thousand words" is 100% true. Send us pictures of what you're talking about, highlighting the issue you're facing, and we might be able to either help you through the problem, or at least say that what you're experiencing isn't expected - and that to diagnose the problem further, we'll need an activity log. To this latter point, I'm completely sure that the original comment up top has a real and meaningful set of feedback in it, but I'm not actually sure what's being talked about. A couple of pictures comparing the version-that-works-as-expected with the version-that-doesn't would go a long way. Back to lurking ian

Yes, because of the cloud services and client re-architecture work completed over the last two years, we are able to render and manage the tasks independent of the notes that they live in - so we can deliver experiences like the Due Date view, and so we can manipulate tasks without having to be in the editor for the note that those tasks live in. That's the magic of the design: you can get a pure task-centric view in the Tasks drawer AND you can look at your tasks in the context of any surrounding content in the note editor. If all you are working on is a to do list, then the Tasks drawer might be sufficient for you. If all you are working on are project- or meeting-centric action items, the notes editor view might be sufficient for you. But, after a boatload of testing, the ability to go back and forth between the Tasks drawer and the note editor and between their very different interaction models, and the ability to leverage the full power of formatted notes to create context for tasks is what we have designed for. We are just at the beginning. Feedback during our private beta confirmed many things we already had on our roadmap, helping us prioritize at least a year's worth of work; the feedback we're seeing in this early access forum is continuing to both reinforce and add to that list, even as we start to knock out some of the highest priority items. We will continue to invest in making both views/interaction models more powerful over time. All the things and all the views you might want to manage/control/manipulate in the task-centric drawer. All the ways you might want to improve in how tasks are laid out, manipulated, formatted and managed in the note editor. In addition, we'll be working on other creation and access paths for tasks. And we'll be making the idea of what a task is yet more powerful. But the basic choice we've made that all tasks live in notes *somewhere* (whether you choose to work with them through the note editor or not) is pretty fundamental at this point. We think it still has a huge amount of unexplored running room. Still lurking ian

There is no such thing as a task as a "separate entity". All tasks exist in notes. You can create tasks direct from + icon at the top right of the Tasks drawer, but these aren't standalone tasks. They end up in a full-fledged note as well (including a "default task note" we'll create called (in English) "Things to do" for all your tasks that don't have anywhere else to live). But your default task note is a full-fledged note like any other - you can go edit it to your heart's content in the editor. Back to lurking ian

You don't mention which device you are on. If you're on the Mac or Windows apps, open the note to edit it, select the lines of text and either click on "Insert Task" from the + menu or click Cmd-T/Alt-T depending on your device type. Multiple lines of text will be instantly converted to tasks. The "Insert Task" trick should work on the web browser as well.

1) I would be legitimately interested in understanding what others think the difference between these two things are. To me (admittedly, not having read the entirety of this 11-year-long forum discussion because I think the general drift is right there in the discussion thread title), they seem at first blush to be the same. Note: I think this is a question solely about notebooks, not about tags. 2) When we get on the other side of this huge lift we are in the middle of, I look forward to moving on to dealing with issues like putting this 11-year-long forum discussion to bed. Not next week, not next month, but certainly not taking another 11 years to get there... That's the kind of thing we're trying to free ourselves up to do - provide functionality improvements that are made impossible by the knots our current infrastructure and app layer has us tied up in. But right now it's one thing at a time, and this first thing we're tackling is proving to be a difficult beast to tame. Apparently, there's something to that thing they used to say on the Bugs Bunny / Road Runner Show: "Watch that first step... it's a big one." Back to lurking ian

Quickie clarifications for those following along... Yes, per @jefito, Conduit is common *plumbing* on the client-side. Conduit has no relation to the UX. Every Evernote client built on Conduit could have a different UX and Conduit wouldn't mind. Users might mind, and we would definitely mind, but Conduit wouldn't. That's basically the whole point. Where Conduit figures in is anywhere that information flows between client and cloud - whether that information is content moving back and forth or a service call of some kind. We expect all of that information to flow through Conduit (on the client side). The goal of conduit is to have common functionality behave in consistent and predictable ways across all of our clients. Sync is the easiest function to understand this with: we'd like all clients to sync a recently modified note (whether that's sync up or sync down) in a consistent way (allowing of course for variances in whether or not that particular note is supposed to be synced to that device). To the concern that @CalS raises about local data stores, part of Conduit's job is to interface to the appropriate technology that forms the local data store (which, unsurprisingly, is a pretty different technology layer on a browser, mobile device or on a PC). That, along with the different memory / CPU / power profiles of the different devices on which our clients run, drives the need for per-device optimization that we talk about in the video, that makes Conduit such a beast to get right. And finally, Conduit, in and of itself, does not close the door to device-specific customizations or integrations. To the extent that device-specific functionality needs to get to the cloud, it will have to go through Conduit at some point. But the functionality that fits that description is usually travelling a well-trodden (ie. pre-existing) path on its way to the cloud, rather than having to carve its own unique API pathway. As @CalS says, yes, there are so many questions. But I do not have time to answer them all (nor, quite honestly, have we actually converged on some of the answers yet - if only because hard experience teaches one not to constrain oneself to an answer before you actually need it). Hopefully the elaborations above provide some clarity. Back to lurking, ian

Hello everyone... Just popping in on this discussion, if only because I don't really want @VisionCasting to carry out his friendly "threat". First of all, I'm sorry that this issue has been outstanding for so long. Second, I want to assure you that many things that may seem on the surface to be easy fixes can in fact be far from it. Sometimes, when we're not very responsive, it's simply because we have no good way to actually accomplish the fix, not because we think it's a bad idea. This is one such area. The way in which Evernote implemented sharing notes some years back was not, shall we say, as elegant an approach as one might wish for. There are numerous long-standing problems that result directly from the constraints of that design. This is one. Problems searching shared notes is another. The list goes on. The way to fix this is not to hack on top of a hack on top of a hack. It is to fundamentally redesign and reimplement the way in which notes are shared deep within the Evernote architecture, and to migrate all existing shared notes to that architecture. Doing that puts us on a path to fix all sorts of different problems, including performance issues with the current design which can get progressively worse as more notes are shared with you. We are going to focus on fixing the root cause of the problem. It's a non-trivial undertaking, as you might expect. But by going down that path, we will be much better placed to work on all the symptoms, as well as be able to move forward to new functionality in this area on a much better foundation. At some point in the coming months, I expect we'll have a Behind the Scenes video that details what we've done in this regard. In the meantime, I apologize for how long it's taken, and assure you that we are working on the root cause for this and related problems. Back to lurking, ian

Thanks for your request @s2sailor. Reminders are a hot topic across a number of different forum threads and social media conversations related to our efforts to converge the UX. Thread tone ranges from the productive ("what are you going to do with reminders?") to the understandably impatient ("why haven't you implemented reminders yet?") all the way to imminent doom ("oh no! they're going to take reminders away!"). In response to your constructive question - thank you! - let me provide the following update: 1. Reminders are used by a relatively small cross-section of our user population (about 1%, believe it or not). That's why it's not the first thing we've focussed on. 2. We believe reminders are important. Partially because some of those 1% are our most engaged users, but also because reminders is functionality that helps you do more than simply remember things, by asking Evernote to surface something back to you at a relevant time, they help you accomplishing something. And we think that is important. A better design for reminders might get more than 1% of users taking advantage of it. 3. Finally, as they are implemented today, reminders are one of the most divergently designed functional elements of Evernote across all the devices we support - both from a UX and a functionality standpoint. Reminders are implemented, displayed, and controlled very differently across Windows, Mac, Android, iOS and the Web. Part of our journey this year has been about trying to converge the UX across all our devices, so that Evernote users can expect to access a common set of functionality in a predictable and coherent way across all the devices on which they use us. Obviously, we are applying this as a design principle, not as a design constraint - mobile phones have built-in cameras, and so we need to expose functionality on mobile devices for which there is a less-than-obvious corollary on a desktop system. The same applies to OS-specific capabilities (eg. Siri, Android widgets, etc.). But as much as possible, we'd like to make common features - like reminders - work the same way with the same UX and the same functionality across all devices. The reason we haven't shown anything about reminders yet is because we haven't yet decided how exactly to do that, both for the functionality that already exists and in terms of future-proofing against where we'd like to take reminders in the long run. When we have a design for reminders that we think satisfies all the criteria we have for it, we'll be more than happy to put it in front of you. Given the timelines we are on, it's hard to predict at this point whether that will be via a video or through an actual beta release. And a quick word of reassurance to anyone focussed on the imminent doom scenario: No, we're not taking reminders away. We're just trying to get them right. Back to lurking ian

Just to follow up on this, when Shane refers to "rules for contests", he's referring to laws. For all sorts of reasons, most of which are due to people or companies using some form of "pretend" contest to take advantage of consumers in the past, most countries have developed a fairly detailed set of laws and regulations that apply to any entity trying to run a "contest" open to their residents. If you are a company like Evernote that does business globally, you have to pay attention to each country's laws if you are going to run a contest open to residents of that country. As you can probably imagine, the combinatoric impact of 30 or 40 different sets of laws can make running a truly "global" contest both hugely complex and quite expensive. And choosing to run a contest (however lightweight) in those countries *without* complying with local laws exposes us to significant risk - because one unhappy resident of that country can file a complaint with their local consumer protection agency, and then we're off having to respond to that, provide appropriate make-good/restitution, etc. It's unfortunate that these laws apply to a situation like this - where we're encouraging people to share their work with others, and offering some free swag as a "prize" - but there's enough in there to trip the local definition of a contest in most countries. For something relatively lightweight like this dashboard contest, it just doesn't make sense to try to comply with so many sets of laws. Instead, we restrict *winners* to the US and live by the laws in this country. Otherwise it would take months of planning to be able to do something like this. I recognize that rubs some people the wrong way. I'm glad most people see through that and understand the goal here was to get forum participants to share experiences with each other, and as a result we had numerous folks who live outside the US sharing their dashboards regardless of not being able to "win" a prize. But at least between Shane's explanation and this one, please know it's not that we're not interested in you, it's not that we don't care about usage outside the US, and it's not the cost of shipping swag around the world to a winner on the other side of it that causes us to say "US Residents only". Back to lurking, ian

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

@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

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

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

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

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

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

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

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

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

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

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.