Recently, a feature was added so that when viewing a backlog item, basically anywhere you click will suddenly change that field to an edit field.
For example, when trying to highlight something (for emphasis in a meeting, or to copy), it suddenly changes the field into an edit box and you have to find the text again.
Or if you just click accidentally, the field will change.
This is incredibly annoying.
by: Daniel C. | over a year ago | User Interface
Comments
Yes, and... add a generic Undo feature to back out accidental edits/deletes resulting from this change to edit behavior.
Yes - I can no longer easily highlight text to copy it elsewhere. For most fields this is a great feature, but for some it makes tasks difficult. Perhaps you could allow us to disable the feature for specific fields, or for some fields you first have to click on the little pencil icon in the upper right corner that appears when you hover over the field?
Thank you for your idea. This kind of feedback is very important and guides our decisions when evaluating new features. "Click to edit" is one of those features driven by such feedback.
I agree that the description field is hard to highlight due to the jarring transition between view and edit mode. We are currently working on a solution for that problem. I will update you when we get it resolved.
For some of the other concerns regarding how easy it is to make changes (even the accidental ones), there are a few tricks that may help. When in edit mode, any time you want to discard a change (for example, you typed C, instead of Ctrl+C), you can hit Esc to revert your changes back. Additionally, if you already left the field and the change was saved, you can use Ctrl+Z to undo your edits.
Overall, we feel that the benefit of not having to open another popup to edit an item greatly outweighs the lesser experience when highlighting text.
"Overall, we feel that the benefit of not having to open another popup to edit an item greatly outweighs the lesser experience when highlighting text."
I have to disagree with that. Editing an item is not something you do alot. Highlighting description text or just accidentally clicking anywhere on the form is something that happens A LOT more. Please optimize for the most used scenarios.
Maybe instead of default editing large text fields, have an edit link or button to do the in-place edit. The way it is right now is causing too much trouble just for clicking in the descriptions.
Agreed with the commenters here. By allowing a single click anywhere in the description field to enable the editor, this negates the more often used and simple function of copying information quickly and easily from a recorded defect into a test case, a conversation, an email, etc.
A suggestion would be to make the pencil marker the only way to activate the editor. In other words as has been said already, enable editing with a dedicated button or link of some sort.
I also agree with the other comments. For us it is hard to separate if a change in the history causes in an actual change of the story or just, because someone accidentally clicked in the Story description field.
So it is quite hard to find new changes, because filtering for "Change Date" is not helpful anymore.
One of the big problems I see with this feature is we're seeing more changes get overwritten because of it.
the main culprit I see causing this is as follows. If a user opens a story and is viewing it and leaves that story open...
Then from my machine I go in and make an edit and save my changes (either the old way or the new way)...
Then the other user happens to click into the details area and makes a change of some sort, then clicks out of the details area. The System then overwrites my changes with the older cached info he had in his browser window...
I think the best way to fix this is to make sure the System refreshes the field as it get's opened in an edit mode. So in the above example IF the user clicked into the details area on a cached story in their browser, AS it goes into edit mode the system should retrieve the latest info for that field before the user can edit it.
Now when he makes a change he's changing the most recent version and saving the most recent version plus his changes...
Thanks.
We've been having the same issues on my teams. I know we would appreciate the ability to configure which fields are capable of inline editing. It's useful for smaller fields like estimates that you would never highlight and copy anyway but for larger fields like Description it's really terrible. Even the title field is somewhat unwieldy. Either having the ability to toggle inline editing or locking it down so you have to take an action to use it (like the pencil icon suggested above) would make this "feature" far more useful.
Totally agree with Michael G. My team is finding it annoying not to be able to select text in a description or to click a link there.
The inline editing feature is cool mostly though!
One of the big problems I see with this feature is we're seeing more changes get overwritten because of it.
The main culprit I see causing this is as follows. If a user opens a story and is viewing it and leaves that story open...
Then from my machine, I go in and make an edit and save my changes (either the old way or the new way)...
Then the other user happens to click on the details area and makes a change of some sort, then clicks out of the details area. The System then overwrites my changes with the older cached info he had in his browser window...
Fully agreed with Lorisel.
Our organization is constantly seeing more changes overwritten because of this, specifically when another user has a workitem open for viewing, and I make an edit and "save" my changes.
This implementation is causing frequent problems, and has room for improvement.
100% agree with comments above. My team is also experiencing MISCOMMUNICATION because of accidents editing descriptions aren't caught until QA feedback is provided, then the Product Owner notices their updates have been overwritten. This is a BIG cost issue that might seem minor and correctable with an "undo" but ONLY if the person even KNOWS something was updated. Most times they do not because it's by accident. I would prefer, as mentioned before, an "edit" link for large text fields - this keeps the single click ease, but is more explicit.
I also hate this functionality. Do you have an estimate date for solving this issue?
VersionOne support just informed me that there's no ETA for restricting inline editing. This is very problematic.
Inline editing is my favorite feature in VersionOne and I haven't had the issues others have mentioned with copying text or accidental changes. Maybe there is a happy medium? I really don't want to go back to opening the Edit window each time I need to update a workitem.
one of the best features in the tool...
Brandon, it's awesome if you're the only one working in a story. But when it comes to larger groups, all team member trying to read and others trying to edit, at some some point readers will end end messing up the things that other are editing.
I don't think anyone here is advocating for removing the feature. It is useful but I think the implementation could use a little refining.
Naren, totally agree
I advocate removing it, or at least being able to turn it off on a per user basis. I like to copy lines out of tickets, but as soon as I click, boom, edit mode when I just wanted a snippet, and now my cursor isn't even where I wanted to copy in the first place.
Sebastian, I hear you and understand. Yep, might be good to be able to turn it off, but by user? by team? globally? How do you make this happen effectively?
The new feature is causing a lot of trouble in our project, too.
We are working in Version One across a large team involving different companies. Some people in the team are responsible for writing user stories, others have to review or add some other descriptions, some have to estimate, some have to put attachments on it etc.
In the past it helped a lot to sort backlog items by change date because you knew that you have to update an estimation or a description if the story has been changed recently. Of course we also talk to each other but sometimes there are changes someone doesn't to tell you about since they seem minor or are just forgotten. However, you know that you discussed the story on a certain day and there was a change afterwards, so you can recheck if everything still fits.
In addition, sorting like this helped to evaluate if the story reflects the current state or is outdated and needs an update. The creation date doesn't help here since e.g. the original story was created in 2015 but has been adjusted last month. Makes a huge difference (at least for us) :)
Today, sorting by change date is useless. One click in the wrong field - because you wanted to highlight something in a discussion - and the change date is modified. Also hitting ESC doesn't always help.
The third problem we are also facing is that changes are overwritten or not saved.
For us it is then a mess to see if something changed in the content or if it is just an accident or to find the change we made but can't see in the story. We have to investigate the stories in order to know - compare the historical versions to see if there is a difference. That costs a looooot of time.
I also agree that editing in a separate window was not very comfortable. The inline editing feature is not bad as such - however, its consequences with the current implementation are.
My proposal: put an icon button next to the editable fields which triggers the edit mode and then save/cancel to finalize your task. Then users don't have to work in a separate window and your users are in control how they want to work and what they want to do with an item.
Thank you all for your feedback. We have been reading it carefully and I would like to give you an update.
As promised, the originally described issue where the user was not able to highlight and copy text from the rich text (e.g. Description) fields was resolved in the Summer 2017 release by replacing the rich text component with another one that does not have a jarring transition between view and edit mode. Highlighting and copying now works as intended.
Some of the commenters pointed out that the fields would sometimes inadvertently get saved, even when no edit was made and the user simply clicked in and out of a field. This issue was resolved in our Summer 2017 Point Release #1 (17.2.1.152), which was released on 8/12. Release notes can be found here: https://community.versionone.com/Release-Notes-and-Downloads/Point_Release_Notes_by_Product/Lifecycle_Point_Release_Notes/2017/Summer_2017/Summer_2017_Point_Release_%231_-_Build_17.2.1.152
With these two issues fixed, this idea is being closed. Should you have additional comments and feedback, please feel free to create a new idea with those specific issues.
As always, thank you for your ideas and comments.