Waveform Dev Update/Look to the Future
-
- KVRAF
- 1790 posts since 30 Dec, 2012
Hi everyone, I know it's been a little quiet around here recently so I thought I'd let everyone know the reasons for this and what we're currently up to. Plus I'd like to open up some debate about some possible decisions we need to make.
Firstly, summer is always a bit quiet as we have holidays to take. With such a small company, going on holiday means there's no one to fill in for you so it takes a little while longer to catch up on things afterwards. We're all back in place now so it's full steam ahead.
After the summer, we're typically in frantic NAMM preparations as it's the only real time we get to go and exhibit our wares and give a really good face-to-face show with press/industry etc. With that in mind, we're now well in to Waveform 9 development. I'm determined this year to get a release out as close to NAMM as possible. This means really knuckling down in the lead-up to Christmas, getting in a feature freeze and ensuring we do as much testing and bug fixing as possible (more on that in a bit).
Firstly though, we haven't abandoned Waveform 8, we released 8.2.5 almost exactly a month ago. We're planning to release a full-public 8.3.0 very soon, we're just trying to sort out some last final issues with MIDI clock. We don't want to simply release a version for the sake of it.
For Waveform 9, we're really trying hard to add features that will improve the experience for new users to the app. This includes things like new discovery features, content (in an exciting way, not just a load of bundled loops) and improved manuals and video content.
On top of this, we're complimenting some long-standing features in an effort to make them easier to use (whilst not removing anything that you will have grown accustomed to), improving some features to provide even more power and flexibility and removing some limitations that may have seemed arbitrary or limiting in the past. On top of this, we're really focusing on stability and performance.
One of the biggest issues we have with Waveform is plugin compatibility. Almost 90% of crash reports we receive are due to a plugin crashing. We do a lot of work to ensure Waveform is as compatible as possible but we simply can't spend every second of everyday working around oddities in plugins. As we go, we're discovering more and more when we get in contact with plugin developers that things that have caused crashes were no fault of our own, we maybe just have slightly more coverage of plugins than some other hosts. (As an example, when we load a plugin we iterate all of the plugin values in order to populate some tables ready for displays and control surfaces etc. We found one very well known plugin was crashing when we looked at a very high parameter index. There's nothing wrong with doing this, we just exposed a bug that other DAWs may not trigger unless you happen to use a very uncommon automation parameter.)
To compound this, if you like to use a plugin that happens to be crash prone, Waveform will appear extremely unstable simply because that plugin is bringing it down a lot. Others who don't use that plugin may never see a crash!
Don't get me wrong, I'm not saying every crash is due to plugins, it's just we often can't do anything about plugin crashes. If we get a bug report for a crash that definitely is in our code we can often fix it very promptly. With W8 we added improved crash logging for macOS and Windows and this has massively helped us in diagnosing and fixing crashes. In fact, we received very little non-plugin related crash reports for Waveform anymore. If you do see a crash, send us a log (and the DMP file if you're on Windows) and we'll take a look as soon as we can.
With that over let me present a few things we're currently discussing which may improve the above situation.
- Dropping 32-bit support
Controversially Ableton recently announced that they're dropping support for the 32-bit version of their software [http://cdm.link/2017/10/ableton-live-going-64-bit-mean/]. Cubase has done similar for v9 and Logic Pro X has been 64-bit for years. Reading the Ableton article makes a lot of sense, less memory addressing and supporting plugins that haven't update been updated (or will even see future updates) is difficult. Making a clean break seems like a good idea.
On the other side, maintaining fewer versions of Waveform would make our development/build/testing/release cycle much simpler. This would also simplify the experience for less tech-savvy users and those new to the world of audio production. At the moment, for every plugin we have to test with 5 variations architectures of the software with 6 plugin formats. Cutting this down to 3 64-bit OSes and only 64-bit plugins would be a much more manageable task. It would also speed up our support replies as the first thing we almost always ask is "Are you using the 32 or 64-bit version".
Additionally, there are 3rd party tools available to run 32-bit plugins in a 64-bit host for those who absolutely must have them. I genuinely wonder who will miss a 32-bit version though. Who still runs the 32-bit version and why? I'd be interested to hear people's thoughts so please debate here.
- Analytics
Tied to the above stability issues it's becoming clear that we simply don't know enough about user problems. As we have a free demo period, many users don't get as far as purchasing the full version and will never let us know why. We're thinking about adding analytics so we can see:
- What OSes/architectures people are using
- What features they commonly use (this will help us target development in popular areas)
- How often users experience crashes and where exactly (this will help us build an idea of troublesome systems so we can focus testing)
Of course privacy is paramount to us and all collected data will be anonymous and there will be an opt-out and very large notification of when the service starts. There really is no better way for finding out how the app is being used and is failing on a large scale.
What are everyone's thoughts on this. Would you leave it running to help us build a better app? Or immediately turn it off?
- Public beta
As I mentioned, stability is paramount for us and the difficult thing with testing is that no matter how much private beta and internal testing we do, as soon as thousands of users load it up on millions of possible hardware/software combinations, we'll see bugs that never occurred in testing.
To this end, we're thinking of having a full-free public beta testing period of W9 throughout January. Can we get a show of hands who would be interested in this and be willing to submit bug reports etc. to ensure the most stable launch possible? Of course this also means our feature set will be divulged ahead of NAMM but if it helps make a more stable product that's a price we're willing to pay.
Does anyone think this is a bad idea?
I think that's it for now. I've tried to be as honest as possible here and welcome constructive debate.
All the best,
Dave
Firstly, summer is always a bit quiet as we have holidays to take. With such a small company, going on holiday means there's no one to fill in for you so it takes a little while longer to catch up on things afterwards. We're all back in place now so it's full steam ahead.
After the summer, we're typically in frantic NAMM preparations as it's the only real time we get to go and exhibit our wares and give a really good face-to-face show with press/industry etc. With that in mind, we're now well in to Waveform 9 development. I'm determined this year to get a release out as close to NAMM as possible. This means really knuckling down in the lead-up to Christmas, getting in a feature freeze and ensuring we do as much testing and bug fixing as possible (more on that in a bit).
Firstly though, we haven't abandoned Waveform 8, we released 8.2.5 almost exactly a month ago. We're planning to release a full-public 8.3.0 very soon, we're just trying to sort out some last final issues with MIDI clock. We don't want to simply release a version for the sake of it.
For Waveform 9, we're really trying hard to add features that will improve the experience for new users to the app. This includes things like new discovery features, content (in an exciting way, not just a load of bundled loops) and improved manuals and video content.
On top of this, we're complimenting some long-standing features in an effort to make them easier to use (whilst not removing anything that you will have grown accustomed to), improving some features to provide even more power and flexibility and removing some limitations that may have seemed arbitrary or limiting in the past. On top of this, we're really focusing on stability and performance.
One of the biggest issues we have with Waveform is plugin compatibility. Almost 90% of crash reports we receive are due to a plugin crashing. We do a lot of work to ensure Waveform is as compatible as possible but we simply can't spend every second of everyday working around oddities in plugins. As we go, we're discovering more and more when we get in contact with plugin developers that things that have caused crashes were no fault of our own, we maybe just have slightly more coverage of plugins than some other hosts. (As an example, when we load a plugin we iterate all of the plugin values in order to populate some tables ready for displays and control surfaces etc. We found one very well known plugin was crashing when we looked at a very high parameter index. There's nothing wrong with doing this, we just exposed a bug that other DAWs may not trigger unless you happen to use a very uncommon automation parameter.)
To compound this, if you like to use a plugin that happens to be crash prone, Waveform will appear extremely unstable simply because that plugin is bringing it down a lot. Others who don't use that plugin may never see a crash!
Don't get me wrong, I'm not saying every crash is due to plugins, it's just we often can't do anything about plugin crashes. If we get a bug report for a crash that definitely is in our code we can often fix it very promptly. With W8 we added improved crash logging for macOS and Windows and this has massively helped us in diagnosing and fixing crashes. In fact, we received very little non-plugin related crash reports for Waveform anymore. If you do see a crash, send us a log (and the DMP file if you're on Windows) and we'll take a look as soon as we can.
With that over let me present a few things we're currently discussing which may improve the above situation.
- Dropping 32-bit support
Controversially Ableton recently announced that they're dropping support for the 32-bit version of their software [http://cdm.link/2017/10/ableton-live-going-64-bit-mean/]. Cubase has done similar for v9 and Logic Pro X has been 64-bit for years. Reading the Ableton article makes a lot of sense, less memory addressing and supporting plugins that haven't update been updated (or will even see future updates) is difficult. Making a clean break seems like a good idea.
On the other side, maintaining fewer versions of Waveform would make our development/build/testing/release cycle much simpler. This would also simplify the experience for less tech-savvy users and those new to the world of audio production. At the moment, for every plugin we have to test with 5 variations architectures of the software with 6 plugin formats. Cutting this down to 3 64-bit OSes and only 64-bit plugins would be a much more manageable task. It would also speed up our support replies as the first thing we almost always ask is "Are you using the 32 or 64-bit version".
Additionally, there are 3rd party tools available to run 32-bit plugins in a 64-bit host for those who absolutely must have them. I genuinely wonder who will miss a 32-bit version though. Who still runs the 32-bit version and why? I'd be interested to hear people's thoughts so please debate here.
- Analytics
Tied to the above stability issues it's becoming clear that we simply don't know enough about user problems. As we have a free demo period, many users don't get as far as purchasing the full version and will never let us know why. We're thinking about adding analytics so we can see:
- What OSes/architectures people are using
- What features they commonly use (this will help us target development in popular areas)
- How often users experience crashes and where exactly (this will help us build an idea of troublesome systems so we can focus testing)
Of course privacy is paramount to us and all collected data will be anonymous and there will be an opt-out and very large notification of when the service starts. There really is no better way for finding out how the app is being used and is failing on a large scale.
What are everyone's thoughts on this. Would you leave it running to help us build a better app? Or immediately turn it off?
- Public beta
As I mentioned, stability is paramount for us and the difficult thing with testing is that no matter how much private beta and internal testing we do, as soon as thousands of users load it up on millions of possible hardware/software combinations, we'll see bugs that never occurred in testing.
To this end, we're thinking of having a full-free public beta testing period of W9 throughout January. Can we get a show of hands who would be interested in this and be willing to submit bug reports etc. to ensure the most stable launch possible? Of course this also means our feature set will be divulged ahead of NAMM but if it helps make a more stable product that's a price we're willing to pay.
Does anyone think this is a bad idea?
I think that's it for now. I've tried to be as honest as possible here and welcome constructive debate.
All the best,
Dave
-
- KVRian
- 676 posts since 3 May, 2004
Hey Dave!
Thank you for the update. We can now see you are committed with the software in the best possible way.
My 2 cents about what you have wrote:
32bit
Since i've bought Waveform this year, i've never used the 32bit version, even if i used 32 bit only plugins in the past in other DAWs. I need to adapt and move on!
Analytics
All OK to me, but adding an option for users to review what will be sent before accepting or not might be a good idea.
Public Beta
I would send it first to experienced Tracktion users as a closed beta, and open the public beta only one month before release.
Try to bring some well known artists to the game!
Keep up the good work!!
Thank you for the update. We can now see you are committed with the software in the best possible way.
My 2 cents about what you have wrote:
32bit
Since i've bought Waveform this year, i've never used the 32bit version, even if i used 32 bit only plugins in the past in other DAWs. I need to adapt and move on!
Analytics
All OK to me, but adding an option for users to review what will be sent before accepting or not might be a good idea.
Public Beta
I would send it first to experienced Tracktion users as a closed beta, and open the public beta only one month before release.
Try to bring some well known artists to the game!
Keep up the good work!!
-
- KVRAF
- 5082 posts since 27 Jul, 2004
Hi Dave,
this statement is very welcome from my side...
1. 32bit: I was recently forced to go the 64bit route because I don´t wanted to start bridging and a plugin I bought is 64bit only...
I can understand the benefit of dropping 32bit support and think it´s time to move foreward... no probs from my side here...
2. Analytics...Honestely I am not sure... as these kind of logging systems always tend to use some CPU cycles, I cannot see myself have it running in the background during daily work...
I can see such a feature included into a demo version though, as you stated that these are the people you are targeting...
3. I can only tell you that for some competitors it works very very well... Image Line and Cockos do public betas on a regulary base, it seem to be a very good way to test... furthermore, people are always curious and unpatient... public betas are a good way of satisfying curiosity
this statement is very welcome from my side...
1. 32bit: I was recently forced to go the 64bit route because I don´t wanted to start bridging and a plugin I bought is 64bit only...
I can understand the benefit of dropping 32bit support and think it´s time to move foreward... no probs from my side here...
2. Analytics...Honestely I am not sure... as these kind of logging systems always tend to use some CPU cycles, I cannot see myself have it running in the background during daily work...
I can see such a feature included into a demo version though, as you stated that these are the people you are targeting...
3. I can only tell you that for some competitors it works very very well... Image Line and Cockos do public betas on a regulary base, it seem to be a very good way to test... furthermore, people are always curious and unpatient... public betas are a good way of satisfying curiosity
-
- KVRer
- 28 posts since 12 Dec, 2016
I hope to see 8.3.0 working on Linux, with Collective at least doing what it should. 8.1 was ok, 8.2 is still not usable (Plug-in UI bug). Collective has no working version at all (silence bug). I am ready to pay for Collective performance improvements and Waveform additions in 9.x, but obviously only in case they can work at all in 8.x incarnation.
Waveform/Collective are already unconditionally "calling home" for updates. "What you think about Analytics in addition" question is a joke in such situation.
One of Tracktion strong sides was care about "low end". Dropping 32bit support cut that advantage (Win 10 32bit still exists).
Waveform/Collective are already unconditionally "calling home" for updates. "What you think about Analytics in addition" question is a joke in such situation.
One of Tracktion strong sides was care about "low end". Dropping 32bit support cut that advantage (Win 10 32bit still exists).
-
Peter Widdicombe Peter Widdicombe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=336849
- KVRian
- 1214 posts since 29 Aug, 2014
It'll be steeper for me. I've only been using 32-bit and it's VST's all along; and rely heavily on SFZ, which probably doesn't have a 64-bit version; and MTPowerDrums that might have a 64-bit replacement.
I'd have to investigate replacements for .SF2 soundfonts (and from what I gather, there are 2 different .SF2 formats out there...).
I'd have to investigate replacements for .SF2 soundfonts (and from what I gather, there are 2 different .SF2 formats out there...).
Waveform 13; Win10 desktop/8 Gig; Win11 Laptop; MPK261; VFX+disfunctional ESQ-1
-
- KVRian
- 526 posts since 7 May, 2007 from Angus,Scotland
I Have MT Powerkit working on 64bit,Peter Widdicombe wrote:It'll be steeper for me. I've only been using 32-bit and it's VST's all along; and rely heavily on SFZ, which probably doesn't have a 64-bit version; and MTPowerDrums that might have a 64-bit replacement.
I'd have to investigate replacements for .SF2 soundfonts (and from what I gather, there are 2 different .SF2 formats out there...).
There is also a 64bit free GM vst that you can point to your favorite soundfonts.
Unfortunately I can't post link to it as I have a power outage at the moment,and I can't remember what its called, but will post link later if you are interested. Cheers
http://www.synthfont.com/VSTSynthFont64Setup.exe
http://www.synthfont.com/Downloads.html
Last edited by terrynoakes on Thu Oct 12, 2017 4:26 pm, edited 1 time in total.
Windows 10 / Intel core i7 2700k @ 3.50GHz / 16GB Ram / Emu 1212m Sound Card / Ati Radeon HD5400 Series G/Card
-
- KVRAF
- 2461 posts since 9 Oct, 2008 from UK
MTPowerDrums is available in 64-bit.Peter Widdicombe wrote:It'll be steeper for me. I've only been using 32-bit and it's VST's all along; and rely heavily on SFZ, which probably doesn't have a 64-bit version; and MTPowerDrums that might have a 64-bit replacement.
I'd have to investigate replacements for .SF2 soundfonts (and from what I gather, there are 2 different .SF2 formats out there...).
I did wonder if the Raspberry Pi version could be persuaded to work on a 32-bit PC under some form of Linux, but I can't see the download for it. No time for trials at the moment thought. I've only one 64-bit PC at the moment, so my "other" music PC will have to stick with T8/W1.
[W10-64, T5/6/7/W8/9/10/11/12/13, 32(to W8)&64 all, Spike],[W7-32, T5/6/7/W8, Gina16] everything underused.
-
- KVRAF
- Topic Starter
- 1790 posts since 30 Dec, 2012
We'll we'll always give the option to turn it off but it really shouldn't take many CPU cycles. The amount of information required to send during analytics is tiny, many orders of magnitude smaller than a simple web page. This is all done on a low-priority background thread and we probably wouldn't do it during playback anyway.Trancit wrote:2. Analytics...Honestely I am not sure... as these kind of logging systems always tend to use some CPU cycles, I cannot see myself have it running in the background during daily work...
I can see such a feature included into a demo version though, as you stated that these are the people you are targeting...
-
- KVRAF
- 2417 posts since 17 Jun, 2003
Are you personally running Windows 10 32 bit?Uhotug wrote:One of Tracktion strong sides was care about "low end". Dropping 32bit support cut that advantage (Win 10 32bit still exists).
"my gosh it's a friggin hardware"
-
- KVRian
- 1134 posts since 22 Aug, 2004 from Edge City, the Low Country
- No more 32-bit version would make 'Waveform' unavailable for me!
32-bit userbase may be shrinking, but IMO it's still viable! There still are lots of people like me with older computers. (Not professionals just hobbyist.)
- Analytics: I do not allow internet connections in my DAW running environment.
- And, if you do change your mind and bring a 32-bit 'Waveform', please do consider to include 'legacy' color schemes to preserve the look and feel of Tracktion 4-6! I'm very fond of those pastel colors
(Those 'light' versions were not on par!
-
vitocorleone123 vitocorleone123 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=333504
- KVRAF
- 2504 posts since 30 Jun, 2014 from Pacific NW
As a small company, you have to look to the future or you'll become paralyzed with legacy support. A full 110% vote for dropping 32bit from Waveform going forward. HOWEVER, I think another 6-12 months of limited support for 32bit for just the current Waveform - meaning fix crashing bugs or major issues not due to plugins - may be in order IF you have the data saying there's enough 32bit users to warrant the resource allocation.
Analytics - your results may be skewed based on the userbase (see comment above about the DAW computer not being connected), but any data is better than no data... as long as the interpretation of the data keeps the likelihood of skew in mind so that you don't automatically generalize the results you get to the whole of the userbase without more data points from different sources. It's tough. I've worked for several small tech companies. I'd also encourage you to contract hire an experienced UX researcher for 6+ months to focus on 2 areas: 1) learning about your users in order to supplement the analytics (analytics can help tell you what, not but so much on the why, which is where user research comes in), and 2) usability studies in key areas of the product, including the new user experience. A lot can be done online now - though there's more hoops if you want to use your own users instead of a pre-set pool of them - with tools like usertesting.com. Finally, be as reasonably transparent as possible about what data you're collecting and include that in your privacy policy update.
Beta testing is a great tool for a small company, but then you have to allocate resource to supporting that effort, in terms of rolling them out, gathering the feedback, analyzing and prioritizing it and then implementing it - only to have people complain you didn't fix exactly what you wanted
Just try to make sure the overhead is worth the return on investment, else, scale back the frequency of beta releases.
Analytics - your results may be skewed based on the userbase (see comment above about the DAW computer not being connected), but any data is better than no data... as long as the interpretation of the data keeps the likelihood of skew in mind so that you don't automatically generalize the results you get to the whole of the userbase without more data points from different sources. It's tough. I've worked for several small tech companies. I'd also encourage you to contract hire an experienced UX researcher for 6+ months to focus on 2 areas: 1) learning about your users in order to supplement the analytics (analytics can help tell you what, not but so much on the why, which is where user research comes in), and 2) usability studies in key areas of the product, including the new user experience. A lot can be done online now - though there's more hoops if you want to use your own users instead of a pre-set pool of them - with tools like usertesting.com. Finally, be as reasonably transparent as possible about what data you're collecting and include that in your privacy policy update.
Beta testing is a great tool for a small company, but then you have to allocate resource to supporting that effort, in terms of rolling them out, gathering the feedback, analyzing and prioritizing it and then implementing it - only to have people complain you didn't fix exactly what you wanted
- KVRist
- 128 posts since 15 Jul, 2017 from Monterrey
32 bit is not needed nowadays, all processor from intel/AMD support 64 bit, linux distributions are dropping 32 bit too!
Quad Core | 16GB DDR4 | 240 GB SSD + 1 TB HDD | FLStudio ASIO | 1 GB Video | W10 x64
- KVRist
- 128 posts since 15 Jul, 2017 from Monterrey
Now if you wonder about the type of 32 bit users.
1.Users that only have a computer with a 32 bit CPU from the 2005 or older, they don't have the money to buy a newer PC, so they would no be paying the $99 for the waveform software license, they use cracked versions of tracktion/waveform, so Tracktion doesn't get benefit supporting them.
2.Users with a 64 bit CPU and 32 bit OS, they don't care about using a legacy OS architecture 32 bit when it's posible to use 64 bit OS, so they don't care about using legacy software as long as it still work, they may be using windows vista or even xp, they may have trackion version 4 or 5, so they won't care about updating to waveform 8 or 9, so who cares about them.
So i say to the users that previously asked for keeping 32 bit support, you are only a few, minority, don't be so selfish and egocentric to ask for waveform 9 32bit, if you have 64 bit CPU, update to a 64 bit os, it's so easy and your 32 bit applications still be compatible.
1.Users that only have a computer with a 32 bit CPU from the 2005 or older, they don't have the money to buy a newer PC, so they would no be paying the $99 for the waveform software license, they use cracked versions of tracktion/waveform, so Tracktion doesn't get benefit supporting them.
2.Users with a 64 bit CPU and 32 bit OS, they don't care about using a legacy OS architecture 32 bit when it's posible to use 64 bit OS, so they don't care about using legacy software as long as it still work, they may be using windows vista or even xp, they may have trackion version 4 or 5, so they won't care about updating to waveform 8 or 9, so who cares about them.
So i say to the users that previously asked for keeping 32 bit support, you are only a few, minority, don't be so selfish and egocentric to ask for waveform 9 32bit, if you have 64 bit CPU, update to a 64 bit os, it's so easy and your 32 bit applications still be compatible.
Last edited by rosesbyrosex on Thu Oct 12, 2017 11:33 pm, edited 2 times in total.
Quad Core | 16GB DDR4 | 240 GB SSD + 1 TB HDD | FLStudio ASIO | 1 GB Video | W10 x64
-
- KVRAF
- Topic Starter
- 1790 posts since 30 Dec, 2012
We'll be supporting Waveform 8 as both 32 & 64-bit versions for at least a year or two as our OEM partners distribute that.
For the people still on 32-bit OSes, can I ask why? As far as I can tell, (and rosesbyrosex confirms my hunches) almost all CPUs have had 64-bit instruction sets since ~2004 with the second issue of the Pentium 4. Waveform is certainly not designed for systems that old and we can't support them even if we did continue 32-bit support.
Is there any reason for having a 32-bit OS? Is it just that your machines came with them and you've not upgraded since? I know Vista and perhaps 7 sometimes shipped in 32-bit OEM forms but I'm fairly sure any OS in the last 5 years would have been 64-bit only.
I can't think of any reason for using a 32-bit OS if you have a choice...
For the people still on 32-bit OSes, can I ask why? As far as I can tell, (and rosesbyrosex confirms my hunches) almost all CPUs have had 64-bit instruction sets since ~2004 with the second issue of the Pentium 4. Waveform is certainly not designed for systems that old and we can't support them even if we did continue 32-bit support.
Is there any reason for having a 32-bit OS? Is it just that your machines came with them and you've not upgraded since? I know Vista and perhaps 7 sometimes shipped in 32-bit OEM forms but I'm fairly sure any OS in the last 5 years would have been 64-bit only.
I can't think of any reason for using a 32-bit OS if you have a choice...
-
- KVRAF
- Topic Starter
- 1790 posts since 30 Dec, 2012
Yes, obviously analytics isn't a golden bullet, making sense of the data is half the battle, deciding what to do about it is the other. Actually getting the data is the relatively simple part.vitocorleone123 wrote:Analytics - your results may be skewed based on the userbase (see comment above about the DAW computer not being connected), but any data is better than no data... as long as the interpretation of the data keeps the likelihood of skew in mind so that you don't automatically generalize the results you get to the whole of the userbase without more data points from different sources. It's tough. I've worked for several small tech companies. I'd also encourage you to contract hire an experienced UX researcher for 6+ months to focus on 2 areas: 1) learning about your users in order to supplement the analytics (analytics can help tell you what, not but so much on the why, which is where user research comes in), and 2) usability studies in key areas of the product, including the new user experience. A lot can be done online now - though there's more hoops if you want to use your own users instead of a pre-set pool of them - with tools like usertesting.com. Finally, be as reasonably transparent as possible about what data you're collecting and include that in your privacy policy update.
The main thing is there's lots of basic things we're asking ourselves these days that would be instantly solved by having this data. Things like:
• What's the OS distribution like?
• How long do users of the app typically spend on it (correlating this with OS would be interesting)
• How many users continue to use the app and how many abandon it (/turn off analytics
• What plugins are people using
• What plugins are the most crash prone
• Where are crashes generally coming from?
The problem is that some users are keen to get in touch with us and let know about problems and provide us with crash reports etc. However, for every one of those there are probably 20 others who just give up. We simply need a clearer picture of where the problems are with the app in real-world use.
The reality is, no amount of testing can compete with real-world data.
