Kuma: Consider showing input fields by default - Signup
Whilst working on https://github.com/mdn/kuma/pull/6371 we ran into a variety of problematic scenarios because the input fields for username and email are hidden by default.
Some of this has been mitigated by ensuring that we always provide the user with a reasonable default with regards to the username i.e. it will never be empty
The entire back and forth process, trying to iron out all the possible edge cases, did make us think though, would it be unreasonable to simply display these values in editable input fields by default?
If the user is happy with the default, they check the checkbox and click the button to create their account. If they wish to amend either the username or email address, they can simply go right ahead and do it. No additional interactions required.
I would really appreciate everyone's thoughts here and especially @atopal and @malqinneh
schalkneethling
All 14 comments
Hi @schalkneethling - Wanted to confirm if this is a card meant for Alfa? If so, what user story / epic is still related to?
chinikes
on 17 Feb 2020
Hi @schalkneethling - Wanted to confirm if this is a card meant for Alfa? If so, what user story / epic is still related to?
This is an open question to Kadir and Mustafa. Depending on the outcome of the decision, this might turn into the user story. I will remove it from the Milestone for now.
schalkneethling
on 17 Feb 2020
@schalkneethling I don't see a 'UX issue' keeping the fields visible by default (on the contrary, it's actually better to keep fields visible) - especially if it's less cumbersome on engineering side.
malqinneh
on 18 Feb 2020
@schalkneethling I don't see a 'UX issue' keeping the fields visible by default (on the contrary, it's actually better to keep fields visible) - especially if it's less cumbersome on engineering side.
I totally agree. And yes, it is less engineering/less code which is almost always good :)
@atopal Thoughts? https://github.com/mdn/kuma/issues/6514#issuecomment-587501029
schalkneethling
on 18 Feb 2020
Just noticed this issue this morning, and wanted to add something that seems related that I saw at the end of last week (while I was testing my work on https://github.com/mdn/kuma/pull/6496) and just created an issue for this morning. See https://github.com/mdn/kuma/issues/6529.
escattone
on 18 Feb 2020
Just noticed this issue this morning, and add something that seems related that I saw at the end of last week (while I was testing my work on #6496) and just created an issue for this morning. See #6529.
And having looked at the scenario, I believe what is proposed in this issue makes even more sense now. See my comment on your issue here https://github.com/mdn/kuma/issues/6529#issuecomment-588092992
schalkneethling
on 19 Feb 2020
@atopal - will this solution work for you?
NOTE: going this way would likely avoid us from having to worry about #6529
tobinmori
on 19 Feb 2020
@atopal - will this solution work for you?
NOTE: going this way would likely avoid us from having to worry about #6529
And #6513 too.
peterbe
on 19 Feb 2020
closing because we figured out a simpler solution
tobinmori
on 25 Feb 2020
I don't think that's fair. The username portion is still suffering from this overly complex solution.
It if wasn't trying to hop between being a read-only form to an active form, it would greatly simplify things.
The only thing that has changed is that it used to be 2 fields, but now it's 1 which is >0 :)
peterbe
on 25 Feb 2020
@atopal Now that the piece with regards to the email field has landed, do we want to consider just showing the username as an input field? This would be as opposed to the current implementation where we show the static text and a button that reveals the input field on click.
Perhaps you want to wait and see what the instrumentation shows us about user interaction? If little to no users ever click to change their username, I guess we can then simplify it even further and not even offer the option to change the username at all during profile completion.
schalkneethling
on 26 Feb 2020
Yeah, I see little value in making this change at this point. The incoming data would certainly have an inpact on the design decision.
atopal
on 26 Feb 2020
Should we close this one @atopal?
tobinmori
on 5 Mar 2020
Yes, closing now
atopal
on 11 Mar 2020
Related issues
peterbe
路
6Comments
schalkneethling
路
5Comments
atopal
路
7Comments
caitmuenster
路
3Comments
peterbe
路
6Comments
Most helpful comment
@schalkneethling I don't see a 'UX issue' keeping the fields visible by default (on the contrary, it's actually better to keep fields visible) - especially if it's less cumbersome on engineering side.