Would it be possible to include a link to report issues in the survey (or ask a follow up question “Have you reported the issue on github” )? A few issues have been reported in the survey, but they haven’t been reported before or we lack of logs, which makes debugging and therefore fixing them really hard.
it is a bit hard is that Desktop and Mobile are mixed together in the “issues” section, e.g. I had data losses on Desktop but never on mobile, same with memory usage, it is irrelevant on mobile. I’d love to see 2 sections there;
I’m so used to the scale where larger number means better, that I almost filled the values wrongly
Added a field where the respondent can share a link to any GH issues reported
Differentiated with two different fields issues experienced in Desktop versus Mobile.
I didn’t invert the 1-5 scale for issues on the basis that doing that would make it a little bit tricky to compare future results against what we already collected, but lmk if you feel strongly about it and I will change them.
PTAL at the survey here and feel free to amend / add questions as you see fit
For whoever has syncing problems, looks like you are using the release version of desktop, which does not propagate info (the feature has been introduced later, so it will show as No info). In any case, contact me here on status directly (and anonymously if you wish) and we can have a look, it’d be helpful to see if there’s an actual problem or just a matter of versioning, thanks!
I recommend another way of visualizing the time spent in the other app vs status as the pie chart is hard to read with the data set up as is.
Perhaps some sort of point system where the time spent in status vs other app is a scale of 1 to 10 further weighted by the respondent’s engagement with Status in the first question and second question (whichever is more frequent counts), i.e. if hourly x1.2, if daily x1, etc. Then summarize the points, calculate percentage from theoretical maximum excluding the 0.2 bonus on the “hourly” and you get a kind of “preference” score. Where the answer for the distribution vs the other app is missing, count 10 points to Status if the answer in the Q before it was “Only used status”, and count 0 points to Status if the answer was anything but.
Here is my attempt at this. I hid some columns in my copy of the data to make it clearer and the functions are hacked up in an external google script. In this version, we get 75% preference for Status over anything else, which seems realistic to me given the number of answers we got and accounting for the fact that only those really interested in providing data will have participated in the survey, and are thus considered more enthusiastic and, by extension, Status power users. Of course, the calculations and factors would need to be further tweaked, but personally I’d find this preference score more revealing and useful than the current chart for this particular data.
Is there anything in the app that you think should be fixed as a priority?
The Desktop app stops receiving messages if I leave it running for a long time (putting laptop to sleep, resuming, etc). It is very slow to switch chat rooms, making me wonder if it noticed the click or not. Web links are hard to click on.
Rather than incentivizing feedback, having the team show the improvements based on these polls should provide an intrinsic motivation for people to give feedback.
I’m mainly concerned around the “Have you reported any of these above issues on Github”. Almost 90% of people didn’t, which means these errors are being lost and/or we don’t see the scale/severity of them. I’m guilty of doing this, because the friction of starting a new issue (esp. when I’m on my phone).
Maybe we can have a “10 most common Status issues on GH” doc/site/discuss post, where people can simply open the GH link and a post? Open to other ideas/suggestions for us to better capture feedback. cc @hester@igor
A single scale rating in the app; hidden somewhere under About. So we can have continuous reporting without GH overhead. In a way an Instabug replacement. These would still need to be collected somewhere and somehow imported into GitHub. I’m sure there’s a way to automate this, it’s a matter of priorities.
Also @igor has raised this a few times. Lack of and utility of logs is insufficient to even resolve reported issues. This is on the Core backlog.
+1 to figuring out what to do with the feedback before gathering any more. Based on the recent discussions in this thread, I think it makes sense to hold off on this week’s survey in favour of making a plan about whether there’s a better option to report issues in the app.
Let me know what works best for you all in terms of gathering feedback, and how I can help!
My plan with Igor was to send out this survey to check in on feedback aligned with each new mobile release. According to my calendar that’s coming up soon. With Igor now being gone, I’m not sure that this still makes sense, but lmk if you’d like me to run the survey again to get some more feedback. Cheers!