I would like that the Build number like “B1297” appears in the title at least when using the form in Early Access. In the past it was common practice to have this and it really helps when scrolling through the topic list. When it’s missing like in the automatic form titles, it will be difficult to know if a topic is current when just scrolling through many new topics
2 Likes
It’s still possible to edit the thread title after it got created through the form, that’s what I did with mine.
I know, me too, but as it is currently, there are already many where it is missing. If e.g. there was a more structured input for software versions it could be done automatically.
1 Like
Yeah, just another example for …
1 Like
@kevin , anything would be an improvement, particularly with earlyaccess. Unfortunately, Roon has, since rolling out 2.0, taken the position that any and every reported issue is due to subscriber error. I’ve given up spending time (trying) to prove a bug that is unquestionably a bug, simply because I’m guilty 'til proven innocent. Outside of early ARC testing, I can’t think of one issue I’ve ever reported that has been properly addressed. If Roon wants the Community to do much of their testing for them, they need to take us seriously. My 2 cents.
It’s a bit weird how the new issue submission form seems to prompt people to post feature requests instead
I have a few comments
- Give the user a chance to describe their issue up-front. The last thing you want is a frustrated user just trying to write down their problem and getting more frustrated being put into a “box” having to answer a bunch of questions before they get a chance to describe their issue.
- The scrolling form thing is funky. It would be better if it was one page with frame opening based upon answers rather than this scrolling this. This isn’t a choose your own adventure game. Let me see all the fields you want at the same time so I know what’s coming and where specific info is being asked so I don’t miss a chance to provide info in the right spot.
- This whole form assumes the user has the most basic understanding of your architecture. From watching the support community for many years now this a incorrect assumption. Don assume your users know the difference between a ROCK, a Nucleus, Server, Remote, Endpoint / Zone, etc. I’d rethink the whole thing from a new users perspective when they have read zero of your documentation.
- “Tell us more like your operating system” Why you ask me for the same info twice? Your form is “smart” and I just told you I am using Windows operating system. Oh you want operating system version number? That should be part of the form and works better asked on one page not this scrolling format.
- The “description of problem” should be a text box not a single line. You want people to be verbose here not think they have to tell you “it doesn’t sound right”. Also, move this higher up in the process. Having it at the end, well, see bullet one.
- Ask specifically if the problem is reproducible and the steps the user went through to create the issue.
- I expect a summary of the info being provided before submitting with a chance to edit each section. Often, seeing all that will be submitted gives the user a chance to clarify related info.
- Add a “have you had this issue before” question. It’s important to know if an issue is reoccurring. Eventually, cross-referencing a users submission history to “like” issues is a requirement of any support system. I see your moderators do this frequently and will merge support requests.
This whole thing feels like an overreaching attempt to capture information commonly missed / not provided when a user opens a community support request. However, in trying to capture this missing information, you forgot that the user’s most important reason for opening a support request is that they have a problem they want to describe to you and then get help with.
One other thing which may be helpful…
Can you let user profiles hold their set-up? This is pretty common on other forums. I can input my DAC(s), Speakers, Core type, etc. etc. This could then be pulled into the form and that’d drop the need for about 80% of the “questions”.
Thanks. I like where this is headed but it needs work and to be viewed from a “frustrated user” perspective. This form, at least it feels this way to me, is built from a “frustrated support tech” perspective.
6 Likes
Everything that makes it easier – just keep in mind that there are users with several setups (places, cores, etc.). So this should be accounted for. Also what Zones/Remotes are associated with which Core. Bonus if a user can just mark the Zone(s), select if grouped or not, when reporting playback problems.
And what I miss in general, especially for playback problems but not exclusively, are question about active streaming services (or not) in use and if the issue is with streaming only, local only, internet Radio only or across the board. Else users tend to forget that part when reporting problems. For issues exclusively with streaming services, subscription / user region might be also crucial to know.
Can you please ask if they’ve done any troubleshooting like switching everything off and on again?
1 Like
That’s our job 
2 Likes
Hey all, thank you for using the form! It’s pretty cool to see this working for real, and now we’ve got a lot of feedback to chew on.
I’ll be out of the office until late next week, so you won’t see any further updates until then, but I wanted to comment on some of the feedback and questions so far.
Our hope is that folks provide OS & build numbers in the question about your Roon Core, but we may need to add distinct fields for those and library size.
When designing a system like this, we’re always having to strike a balance between keeping it concise and user-friendly while also gathering the relevant information to provide effective support. For example, if you’re having a problem with metadata, we don’t need your OS version, home network details, etc. That’s just noise and extra paperwork.
We use Typeform behind the scenes, and they’ve got a lot of great tools we can use to avoid asking unnecessary/redundant questions. Now that we have some real-world submissions, I’m looking forward to making this way better.
I wish we could save answers between submissions, but I don’t think it’s possible with Typeform. 
If you don’t finish the form, your answers are saved for up to 15 days, but once you submit, we can’t recall those answers again.
That said, I think you’re both onto something here. I’ll do some research, maybe we can build a custom solution.
Funny you mention this, an earlier of version of the form did exactly that. 
I’m going to revisit that version because I think you’re right.
This is one of my biggest gripes with Typeform, it really wasn’t built with long-form text in mind. You can Shift + Enter to get multiple lines in that question, but it’s not obvious or natural.
Good idea – we can do that.
2 Likes
That will not work, specific question are needed. I’m not a betting man but I’d put a wager on it.
3 Likes
That’s why the form should be dynamic, and only prompt for the required info based on the nature of the report.
I look forward to seeing this being utilised, the more effort that goes in now to get this right the better.
Let’s not have too many we are planning to improve this later statements, way better to get it right now.
3 Likes
I tried the form and after a hopeful beginning I was expecting a more structured/guided form, like
- external service provider:
1.a type of external connection:
1.b speed
2 network structure
2.a ethernet speed:
2.b wifi speed
2.c wifi protocols
3 where does roon live: dropdownmenu: nulceus/nucleusPLUS/Windows/MAC/LINUX/NUC/BJOD-Rock
4 how is roon connected to network: two radiobuttons for ethernet and wifi
5 fill-in table for all your devices with 3 headers: brand+type … ethernet checkbox … wifi checkbox
6 extensions: free form
etc…
(There are many form creation libraries: in the past I used JQwidgets for dynamic forms, see for example the demo-page for what is possible here: jQuery, Javascript and HTML5 UI framework for building web and mobile apps | jQWidgets Demos
1 Like
I pushed some minor changes this afternoon:
- Description of issue now comes earlier in the form, before system details
- Improved the copy on a few questions that were causing confusion
- Simplified the form logic after selecting the affected product (not something you all can see, but very helpful for us internally
)
Next up on the list:
- Better email notifications informing folks of the next steps in the support process, self-serve resources, etc.
- Summary of answers before submission. I’m not too confident in this one because of some of Typeform’s limitations, but I need to take a closer look
Have a great weekend!
4 Likes
I’ve just tried it, I think it’s good, it helps as it clearly indicates what information is needed.
A reminder would be nice not to post screenshots with email addresses, phone numbers, etc. (Maybe could be even autodetected). It seems to happen more and more often with new users and then they need to be reminded by users and/or a mod has more work
2 Likes
