[feature] Improving the bug reporting on mobile - step by step

[karlcow]

Because of #613

We might want to think to improve a bit more on the messaging. Reminder we have a choice of type of issues. We improved the quality where people now select a type on problems. Then there is the Expected/Actual which is often empty.

Most of these empty bugs are coming from people on mobile. I guess typing is felt cumbersome. So maybe we do it slightly wrong for the mobile form and there is a way to make it even more user friendly. We could test a couple of scenarios.

Maybe it's a series of questions with possible choices for Actual/Expected. Or maybe the Actual/Expected is not relevant in the case of mobile. For example, I imagine, that you are on a site which looks obviously broken on mobile, but it's very rare that someone will

1. Go to the address bar
2. Select the URL and Copy
3. Fire another browser
4. Paste the URL
5. Check how it looks
6. Go back to the bug reporting form
7. Fill the Expected field.

I guess it's partly why we get empty bug reports.

That said on webcompat side, there might be a way to make this initial summary more editable after the fact with them being editable by the same reporter once on desktop and/or someone reviewing the bug report.

So two possible actions:

1. Better initial forms with guiding
2. Editable areas for Expected/Actual.

[karlcow]

see also #445

[karlcow]

This is probably solved by the work on https://github.com/webcompat/webcompat.com/projects/6