Dev Talks: Native Access Startup Journey and Next steps
Comments
-
I wasn't at the company when the decision was made to pursue dark mode exclusive, but I'll be honest, when I joined as a developer, it was a nice change for me. However, due to the desire to get Native Access v. 2 rolled out faster, we sacrificed the option for themeing as it would slow down the designers and developers, alongside quality assurance needing to test our features/ui for multiple iterations. It added to the scope so we slowed it down.
That being said, we made a conscious decision to develop with themeing in mind for the future, making our colors swappable. The only problem is that the concern still remained, and there's some issues in our infrastructure that need to be resolved first, like how client preferences are loaded up when you get to "Loading Products". This means that if you have Light Mode on, you'd get a flashing experience.
We have a proof of concept ready for this feature, and are making the necessary infrastructure changes (which help other parts of our app as well). When that's done and dev time comes available, we'll slot Light Mode in after. We've learned a lot about light mode and understand its value. We're looking at Q3 to begin work. Maybe next quarter's DevTalk will contain a clearer timeline then. We ask for a bit more patience here, and thank you for voicing your concern here.
1 -
We're working on addressing bugs that require users to go back to NA1 to overcome them. As mentioned in my first DevTalks on NA1 vs. NA2, they are two products, but with a different tech infrastructure behind it, and NA2 was not released very stably. We're still working on addressing bugs that require NA1 to circumvent on NA2 before we move everyone over (on devices that support NA2, Mac OS X 10.15+ and Windows 10+). This is why we never put a notification in NA1. However, we've reached full parity as of 3.2.0, so all features are at or beyond the level of NA1 in NA2 right now, so it's just the bugs now.
We'll make a more formal announcement on how that process will go and how it will be executed when we're confident in the position we're in, and we'll be sure to be mindful of people's workspaces in doing so.
1 -
Reading about themeing NA, I'd like to propose something:
Make it user customizable. Maybe not necessarily in-app, but externally via a CSS or JSON file. This way, people can - if they want and are capable of - modify and tweak it how they want.
0 -
@Vocalpoint I couldn't agree with your post more re Telemetry, NTKDaemon etc. and especially the possible privacy implications, which I would like more transparency about and a straight answer.
0 -
Do linux users get support from Native Instruments any time soon, or are we forgotten?
0 -
@Pekka Rajala welcome to the forums.
No support. This is not really the right place to post about that. Somewhere theres a thread or two about Linux though. Just do a search for Linux.
0 -
I'm not entirely sure what Product Portal did a while ago, but we definitely will try to make it possible to close the app and no longer less the app process run, while the NTK Daemon downloads in the background.
I think I've gotten enough requests to talk about why we need it to run, so I might do a deep dive into it in the future. TL;DR:
- Subscription products need their statuses as up to date as possible
- Product activations are kept up to date in real time, meaning if you were to connect a device, it would activate in the background.
- End goal of Native Access being able to close after downloads are queued up comfortable
- Detection of hard drives, whether ours or yours, and being able to activate our products
- Keeping options open for other opportunities it unlocks
Regarding "Hide", it's not a unique request. Not only on this discussion, but also in our feedback channels. I'll plan it in at some point and keep you posted in the next DevTalks.
Thank you for your in depth feedback. We are confident with our shifts forward, but always appreciate criticism nonetheless.
1 -
Hey, thanks for raising these questions:
- We're aiming to increase the speed of installs. We have no plans at this stage to support offline installers. We've even gotten rid of some installers for a handful of products to increase the speed at which they can install and update, as well as reduce the size of our products. We see a lot more benefit aiming for this solution. But it's not fully out of the question yet.
- Yes, you can disable usage data tracking in the Preferences panel. We still have diagnostics in place to collect data on our features, but this does not include any personal data and is completely user agnostic and in compliance with GDPR regulations.
- You're welcome! As of today, the NTK Daemon in our dev environment supports uninstall for MacOS content products. We're missing windows functionality and diagnostics, so we're not ready to release just yet, but we're getting close and I'm excited!
- Though likely not slated for this year, we're looking at how we could provide product backversioning. We understand the value of having your environments locked in a certain environment or to help diagnose, so this would be the way we go about it as opposed to giving access to installers.
- Yes, agreed. We're continuously working on addressing these. Startup has become more stable, though we have a few things left to address.
- We're very much going to implement light mode with the option for the user to use system settings/light/dark modes and toggle between them, hopefully by end of Q3.
0 -
This sounds fun! Maybe at some point! Think our existing color theme setup is flexible enough to be able to do this, but for now, just light and dark, and once the state of Native Access is stable enough to warrant a fun feature like this, we could look at this!
1 -
I can assure you the NTK Daemon does not install or download anything that you did not explicitly tell it to through Native Access. The only things we upload are usage data if you've opted in, and diagnostic data to track our features, the latter which is completely user agnostic. We do not track your DAW, nor your device environment.
To your point about documentation, I'll raise this topic to see what we could do here, as to me it sounds like a pretty fair desire, but considering we're dealing with product activations, how in-depth we can go into some of the feature set.
At some point I could do a deep dive into the topic of Native Access, maybe as a separate DevTalk. Seems like there are a lot of concerns, and I'd love to alleviate those, and clarify our needs to keep the NTK Daemon running in the background. See my previous comment where I address it in TL;DR in the meantime.
0 -
Hello @Hayo_NI
Thankyou for your response. I should have numbered my questions.
- I don't see an answer to my 1st question (first paragraph)
- "We still have diagnostics in place to collect data on our features,"
1/ Does this happen in NA1 or is it new in NA2?
2/ Can we opt out of that?
3/ Can we access this data to see actually what gets sent to you?
- Thankyou for the uninstallers. Great news there.
- Im not sure I understand what you plan to implement with your back versioning. My point is, as long as it doesn't hold up legitimate paid users from using your products when theres an issue, I'd be happy with that. I'm not for you just willy nilly handing out installers for obvious reasons! (EDITED this bullet point to make things clearer)
- Good job on the planned flexibility for light and dark, and better, preferably customization. This is going to make everybody happy I think and you can't go wrong with that.
0 -
Appreciate your update AND the fact that I realize you guys are talking about product activations - not exactly something you want to divulge too much information on. That's not the issue for me.
In an increasingly paranoid and privacy centric world we live in - all software needs to be more transparent on data collected - even if you believe it's benign. There are some out there who do not even want diagnostic data sent back to the mothership - whether you like it or not.
And let's face it - the whole NA2 install process says exactly nothing about what will be installed, what will be collected, what will be left running in the background and so on. I should be able to see this going in and then make a decision on exactly what I want to share etc.
I know we do not have a choice whatsoever when it comes to having to use NA2 - without it we cannot activate anything, but it would be nice to get some sort of basic info panel that says what the install is going to do to our systems. As it stands now - NA2 simply flashes a few screens and presumably does something to our systems with zero knowledge from the user.
It's a small thing but I think more people would be fine with what this thing installs if they knew what was coming.
VP
0 -
Thanks for this. This all sounds great. Even just the ability to hide products (either if unused or uninstalled) would be great for tidying things up. But the ability to completely uninstall would be a nice touch and I'm sure you'll get there at some point. Removing subs from "available" is great actually - I just accidentally happened to install some plugins from my cancelled sub before this was implemented (which put them in demo mode.) This means that won't happen now, so thanks for a useful update. Good luck with the other issues and priorities too :)
1 -
To address @Vocalpoint and @Jojo123 's privacy concerns, I want to make a few things clear.
We have a Marketing Consent form, for which we get users to opt in to tracking your data so we can send personalized marketing information. We haven't integrated any services for this yet in Native Access to add to this personalized experience, but this consent is for our entire Soundwide ecosystem. You are by default opted out until this popup shows up and you explicitly give consent. This is completely different from our diagnostics systems.
Additionally, we have usage data tracking that you can opt out of as well in the preferences. Being opted in would provide more information to our diagnostics services, like geography or device info, so we can get as much information relevant to an issue occurring, but we never tie it to a specific user, rather a specific instance. This does not filter into any of our products and is purely for the health of Native Access. By opting out, you give us less information to work with, but we can still monitor the health of Native Access, such as each individual startup attempt from A to B.
Regarding our diagnostics, it's not user data, therefore we're not obligated to share this information. It's data pertaining to Native Access, and therefore we are allowed to prevent opt outs to more accurately monitor the product. As we comply with GDPR and other privacy legislation, we're able to do this at our own discretion. But on a personal note: while having a user tied to each event could be great, it doesn't really do much for the actual issue. "John Doe experiencing problems with downloading Kontakt 7" is no different from "An issue occurred with an attempt at downloading Kontakt 7", and so for every feature/event/flow, we refer to the latter. It's anonymous, even if you've opted in to usage data, and reflects an attempt at an action, us tracking the health of it, and us being able to identify/address/contextualize issues that are occurring on our platform. Having people opted out makes this process difficult to do well.
Native Access tells you exactly what is being downloaded or installed on your device. I know my word doesn't solidify confidence, but Native Access exists so you have control over what the NTK Daemon installs. If you feel we could do better at being transparent here, we're open to feedback, so let us know!
0 -
"Native Access tells you exactly what is being downloaded or installed on your device. I know my word doesn't solidify confidence, but Native Access exists so you have control over what the NTK Daemon installs. If you feel we could do better at being transparent here, we're open to feedback, so let us know!"
For me - it's all about transparency when INSTALLING Native Access in the first place - not once it is already up and running. And yes I am aware of the Usage Data Tracking options - once you are IN Native Access - but that is still after the fact.
I would love to see a much tidier (and properly branded) installer overall - so when a user double clicks on the NA installer for the very first time OR during an update (which could be made silent if the user chooses) NA2 comes up with a pleasing panel or two telling the user what it does, what exactly is going to be installed (Dependancies both for Win and Mac) and most importantly what services will be resident on my DAW when the install completes.
You could also include a toggle or two to allow us to opt into (or out of) Usage Data or any other options that are relevant during setup like file paths etc.
Right now - this installer sometimes looks like a piece of malware with no real branding, DOS windows opening and closing in rapid succession and not even so much as a notification that the install is complete. I just did 3.3.1 last night and could not tell if it was installed or not.
For what appears to be a vital cog in the NI product wheel - this installer could benefit from a refresh and some general TLC to make it look like it belongs in the NI universe.
VP
1
Categories
- All Categories
- 19 Welcome
- 1.3K Hangout
- 59 NI News
- 706 Tech Talks
- 3.6K Native Access
- 15.2K Komplete
- 1.8K Komplete General
- 4K Komplete Kontrol
- 5.2K Kontakt
- 1.5K Reaktor
- 354 Battery 4
- 783 Guitar Rig & FX
- 403 Massive X & Synths
- 1.1K Other Software & Hardware
- 5.2K Maschine
- 6.7K Traktor
- 6.7K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators