-
Notifications
You must be signed in to change notification settings - Fork 66
Selecting the description field does not enable editing automatically when the field is populated #4048
Comments
@tinakurian the description field mimics the Github behaviour. If the description field is empty, when you click on it, the field becomes editable. If the description field has content, you need to specifically click on Edit and then proceed. @sunilmalagi @Veethika please comment. |
Thanks @nimishamukherjee The behvaiour seems somewhat inconsistent though. Shouldn't the title function the same way in this case? Personally prefer the way the title works better. |
@tinakurian @nimishamukherjee @Veethika I agree with you Tina, the behaviour should be consistent across all the editable fields, I feel we should allow the user to edit when he/she click within any text field and if we do that, we can also consider taking out the edit icons, Veethika please confirm on the same. |
@tinakurian @sunilmalagi @nimishamukherjee It makes sense to make any input field active on clicking inside the field when it's empty. But once some data has been entered in a particular field, one should only be allowed to edit it after clicking on the edit button/icon available. And this behavior should be consistent across fields. |
@Veethika I think it could be confusing to the user to change behaviours as they interact with the tool. Personally, if i did some action the first time, as a user, i would expect it to do the same thing the second and third time. I think changing the behaviour would cause some uses frustration as they wouldn't know what happened. Although logically, this makes sense, from a users perspective it may not make immediate sense why one time the application did one thing and another time it did another. |
@tinakurian I understand it feels like it. But the behavior I mentioned above is a standard one across the majority of the products(anything that uses input fields frequently, not necessarily only ALMs or version control tools, social media is a good example to explore). When we want the user to start adding content to a field, it shouldn't be as difficult as spotting the button first and then activate the field. It comes across as very resistive. On the contrary, once something is posted, editing it shouldn't be as easy as just clicking on the field. It should require a more controlled trigger to prevent accidental changes. |
@Veethika I (respectfully) disagree :-) I think social media isn't the right comparison (different purpose, different users, different problems to safeguard against). This works for github because the design of the UI is quite different than what we have. The user expects this behaviour when interacting with the github UI. The UI we currently have created doesn't permit the user to understand how to navigate it easily with the flow you are mentioning. We are trying to combine two different experiences that don't seem to belong together. Here are a couple of examples on how Jira handles editing work item titles and descriptions. It is very easy to understand - the behaviour is consistent and most importantly expected. Jira allows for editing on focus. It is very clear, visually, that the user has entered into edit mode. When the user changes focus, it automatically saves the changes. I think what you mention is best suited for the comments section. Actually, interestingly enough, Jira implements this for comments, see gif. This makes sense, as it is a social area, so it should probably behave similar to other social platforms which users are accustomed to. Editing work item title - Jira |
@tinakurian I like how Jira is taking care of the info part. The message editing feature looks horrible(I think we do it better). Social media isn't something I wanted to draw inspiration from, but the point was that those ubiquitous interactions do inculcate a behavior pattern in the user. Let's settle on there not being any standard :) A few suggestions that I think we look at here:
There are two stories #3999 and #3998 and it would be good to see these suggestions there. You could put a comment or add a point to the verification criteria. I plan to take it up towards the end of the next sprint. |
Unassigning myself and Sunil as we're not actively working on this issue. |
@tinakurian Please add this issue as a verification criteria to #3999 and close this one. It will be easier to track everything at one place. |
@tinakurian from the beginning we have modeled much after github. Unlike Jira, this is an open to view platform. A non-user can look any content. The github model of requiring edit on any existing field makes sense for multiple reasons. Primarily, we need to validate access. Yes that can be done when the use clicks on an editable field but that is a poor approach. Our users are familiar with github, it is the only thing we support at the moment. Can we update or change how you gain edit, yes. We also need to be consistent. |
@joshuawilson Thanks for the clarification. That makes sense - i think the more important issue is consistency. It's hard to use a tool when i cannot understand or anticipate it's behaviour.. especially in seemingly similar situations. |
I agree there are a lot of inconsistencies. |
Consistency needs to be evaluated as a whole across the app with UXD. |
Based on a conversation held on 2019-Jan-04 including Dev, PM and UX, the UX team will not be providing support for planner items. |
After reviewing this, I think we can close it as the specific question was answered. With UX doing a new IA flow the consistency will come from them for the whole app. |
When editing a description which contains text, clicking within the description text field does not automatically allow for editing. The check mark icon does not automatically appear the same way it does when there is no text or similar to how the title field functions. The user is forced to click on the pencil icon in order to start editing.
The text was updated successfully, but these errors were encountered: