Selecting the description field does not enable editing automatically when the field is populated

[tinakurian]

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.

[nimishamukherjee]

@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.

[tinakurian]

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.

[sunilmalagi]

@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.

[Veethika]

@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.

[tinakurian]

@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.

[Veethika]

@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.

[tinakurian]

@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

Editing work item description - Jira

Adding comment - Jira

[Veethika]

@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:

1. We could look at a single click editing activation for the information fields. this would involve few calls on the UI side as well - the fields should get highlighted in the same way on hover. It would also not be right to place the edit icon outside the field input area like we have now.
2. What about situations where there is text truncation in fields? We need to take decisions on the editing behavior for bot quick preview and detail view as we don't want to encourage users to spend a lot of time on the quick preview.
3. The comment section editing flow and visual feedback need to be taken care of, it appears similar to other fields as of now and would create the anticipation for a similar behavior for the user.

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.

[Veethika]

Unassigning myself and Sunil as we're not actively working on this issue.
Track progress on #3999

[Veethika]

@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.

[joshuawilson]

@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.

[tinakurian]

@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.

[joshuawilson]

I agree there are a lot of inconsistencies.

[nimishamukherjee]

@openshiftio/uxd-team as mentioned by @Veethika we will wait for #3999

[christianvogt]

Consistency needs to be evaluated as a whole across the app with UXD.

[serenamarie125]

Assigning @Veethika as she is working on #3999, which will likely solve this.

[serenamarie125]

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.

[joshuawilson]

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.