Service Desk "Field help" hidden by default behind information icon in new look

[Zoe Glynn]

We have configured our Request Type forms to provide important contextual information to requesters in the form of "Field help" contents, since this field 

However, they new style portal hides this content behind an information icon that people have to click in order to view. (It's not even present as elements in the DOM until they click!)

This is seriously cramping our style, as requests arrive without proper steps having been followed.

I am actually quite surprised at the lack of chatter about this, so I'm hoping I've just missed a really easy new configuration somewhere, or I'm just not using the expected nomenclature in my searches.

Here's an example screenshot of the UI element I'm talking about, in the JIRA service desk support docs (https://confluence.atlassian.com/get-started-with-jira-service-desk/create-service-desk-request-types-917968307.html):

And here's what we currently see:

Does anyone have any suggestions for how to get back the old, always-visible presentation?

[Andy Heinzer]

Hi Zoe,

While I have not found a means to revert the display changes in the customer portal yet, those description fields should still be appearing on the page.

However the difference I can see about this is that those descriptions do not appear until either the field itself has been selected to enter some text/value or unless the user clicks the info icon directly.

But I can understand how this change to the customer portal might in turn be effecting the field input by users.  If previously all these descriptions/instructions were visible directly on the page, and now these appear hidden by default perhaps there are more customers not actually reading these sections.   This wouldn't be a problem if the fields on your request type were listed as required, at least then the user has to click the field itself and enter some value before they could proceed, but I understand if that change isn't desired as it has other possible consequences to the workflow that your team is following here.

I too am surprised by the lack of other posts and lack of bug/feature requests made about this change.   In my search I was not able to find any other reports made about this specific problem, but I am interested to see if perhaps making the field required in the request type is a valid work-around for you in this case.

Please let me know.
Andy

[Zoe Glynn]

Thanks for taking the time to comment, Andy.

We have managed to improve the quality of requests we receive by marking certain fields as required.

I would still be excited to see a return (or option) to present field help statically.

Reverting to optional fields would be nice, so we're not forcing placeholder input.

Even more important for our use case is that when all guidance information is laid out at once, the comprehension of requestors is much improved. They can quickly scan to understand the scope and nature of preparation required, or if this is the appropriate request for them to make at all, given their circumstance.

Thanks again.