Dev Talks: Native Access Startup Journey and Next steps

Hey VP.

I agree that at this stage Native Access should get you going with our products. You should be able to update when updates are available, install or uninstall products when you need/don't need them, and be able to close it.

The reason we run an NTK Daemon service is exactly so you could close Native Access when you've queued up your installations. Open, filter, queue up, close. This isn't in place yet, but we're already working towards it. The download queue migration into the NTK Daemon is one part of this vision, barring other things we need to be doing to assist that, like stabilizing the Daemon, revisiting how we react to errors, considering desktop notifications, have Native Access be able to close without quitting, etc., all to the level of being able to turn your device off then on and have the NTK Daemon carry on downloading after it starts up again, starting from where it left off.

With the NTK Daemon running as a separate service, it opens up a lot more possibilities than if we want it bundled with the GUI. Not only will it slow down development and increase the workload, but it just adds way too many restrictions too. We also want both these services to be as lightweight as possible. If things are getting out of hand size-wise, let us know so we can take a look to address that.

Regarding your locate suggestion: agree. We're revisiting the existing locate functionality right after download queue migration is done, with Locate All following suit once locate is stable. Regarding the ability to scan: we were thinking along the lines of "select a folder to scan" and for us to browse what products we found in that directory as the ideal way to go about Locate All. We'll revisit the UX near this quarter's end or the next one. We believe strongly in the feature, but it's been deprioritized in favor of storing everything.

Thanks, hope the information was insightful :D

It's a tough balance to make. While Native Access was working on revisiting the way they handled the state (3.0.0), they addressed a TON of bugs that the live version had. We could've chosen to address, for example, the massive performance issues the GUI was facing and ship those off, but the way we needed to address those performance issues in the live version would be vastly different from the in-progress version.

So what do we do:

• Ship the fix on live, then revisit it in the reworked version, which would need to import the updated live version anyway, creating extra work to migrate the live version and then readdress the prior fix differently in the new version, which totals to triple the work and thus extending the ship date even further but faster shipping of live fixes

or

• Plug the fix in the new version only, delaying the ship date of the fix but making it robustly integrated in the new version.

It's a tough call to make, cause shipping faster is always the more preferred solution, from a business standpoint and a user standpoint. The first way is something we call Tech Debt: an implementation we will need to spend a lot more time addressing later than if we were to do it properly now. We try to mitigate the amount of tech debt we need to make, but in some cases that's just not possible.

An example where we did do this was with the recent hotfixes in 3.2.1 and 3.2.2. We needed to patch the update flow so users wouldn't get locked out when we deprecated Mac OS X 10.14, if the users were on that operating system, but we should really look more closely at our update structure. Tech debt doesn't normally create issues. It's like a pipe leak. You could tape it up to block the leak, but it's just patches it. Better to just fix the pipe, but that takes more time/costs more money.

I completely understand you here. I admit that we were prioritizing startup too much over installation success, but our goal is to stabilize the service, and many users couldn't get into Native Access to begin with. Startup plays a key role in activating your products as well, so it's definitely something we've addressed consciously in the meantime.

We've been doing a ton of research since October, and tackling a bunch of issues in the download manager, but there's still a lot of research we need to do to stabilize it even further. All of this is work in progress, and in most if not all cases is just something we cannot ship in batches even if we wanted to. We're also working on the installers at the same time, so it's really all hands on deck here. I apologize that we have to ask for patience here.

We definitely feel like we'd be helping users stay focused if they were to be able to browse in a dedicated space. Native Access has the potential to do that, to keep you in the workspace. I'd love to hear your thoughts on what frustrations you have throughout your music-making journey. Maybe Native Access could help in some way!