Community
Participate
Working Groups
Currently if the task editor extension is enabled, existing JIRA issues are displayed with the description displayed in the source editor. The description should be displayed in preview mode instead for existing JIRAs, so that markup displays properly. This has the advantage of proper display, however it does add an extra step to edit a description. Users would have to click on the preview to switch it. Perhaps attempts to type in the preview should automatically switch it to edit mode.
*** Bug 263674 has been marked as a duplicate of this bug. ***
+1 It would be great in TRAC-based configuration too. My suggestion: 1. make it (default description view mode) configurable on the task-repository level 2. always use plain text edit box for new tickets created from mylyn level 3. as I suppose you always have plain text representation of a description (as its the HTML-rendered preview that needs to be separately loaded). So clicking an "edit" button could work instantaneously.
In the first place, the default should be preview mode, since this is the case e.g. for Bugzilla. If the description is editable, the button to switch mode is visible, otherwise not. IMHO, changing the default to preview is a simple change and would help both JIRA and Trac users. Could we get this for 3.1?
My main concern is the workflow. Since Trac and JIRA descriptions have been editable as a default in all previous versions having a small toolbar button may not be easy enough to discover and more difficult to use than the current implementation. David, do you think it's feasible to show the preview by default and make the description editable once it is clicked?
(In reply to comment #4) > David, do you think it's feasible to show the preview by default and make the > description editable once it is clicked? Yes, in fact that was something that I was thinking about for the New Comment preview.... it's easy to click for preview and then forget that it's in preview mode. A single click for New Comment and Description might not be desirable, since the user might by attempting to select text for a copy/paste. Perhaps a key listener that flips to editable when someone starts typing.
(In reply to comment #4) > My main concern is the workflow. Since Trac and JIRA descriptions have been > editable as a default in all previous versions [...] Fair point, but probably nobody complained about this because the old HTML preview mode was too slow to be used as default. In general, I tend to change descriptions and comments in JIRA and Trac in rare cases. And e.g. in Bugzilla it is not possible at all -- how often did you miss that? But if David finds a better way I fine with it. Just want to suggest a quick solution.
Steffen, please this one for 3.2
David, would you be interested in investigating an implementation for this feature?
Thomas, could you take a pass at this to determine if this is feasible (time box it with some reasonalbe amount)?
sure
Well, I do not see why this wouldn't work in principle, and it should be a rather small fix. However I am more concerened about how to actually trigger the switch itself. # Seems typing is problematic since I would have to ignore at least copying actions, but allow probably all other keys and key combinations? (so something like if keyPressed != Strg-C showEditor ) # We could also use the mouseUp event and only trigger the switch if the text selection length is 0, meaning one could mark and copy, but a single click would switch. I could live with the second approach, but there might be users doing the click and then shift-cursor approach for selection, which wont work anymore. The first solution seems more like a no go, since we would also have to check where the cursor was with his selection, which might get tricky from html to text. I do agree that finding the preview button might not be discoverable enough for new users, and especially since preview is the default then, they would rather look for an edit button than to untoggle a "read-only" button. Bottom-line: if preview on default, I think we need to do some detection when to switch, but not sure what the best rule there is, if anybody has better suggestions than the two above, please tell :)
I think that any click or tab into the editor should switch it. For the copy case, it makes a lot of sense to copy the wiki markup instead of the rendered text. Should we try it this way and then determine when it should switch later as this is just a policy change, not a real functional change?
The tricky part is to get the user interaction right so it doesn't feel awkward or the behavior is not unexpected, e.g. when the user clicks in the read-only viewer it would be nice if the cursor was at exactly the same position in the editor. I think switching should happen on any focus event. We may need to do some experimentation to figure out what works best when the mouse is dragged to select etc. It could make sense to toggle to preview mode in that case. I would not enable the preview button by default but add an on hover border or some indication that it is not a true preview mode. Once the user explicitly toggles to preview the preview mode should stick.
Created attachment 144163 [details] patch v1 A first try. It will have a non-sticky preview per default, and will change to the editorView once the user clicks in, and change back to the preview on focus lost. If the user presses the preview button in the toolbar, it will become a stickypreview as long as this button is pressed. I think the user experience is somewhat ok like this. Note: as long as there is no mapping of the models (preview and source) in regards of caret position, this patch just assumes they are equal. If there is a lot of markup, the caret will just hop to the wrong position. Solving that is out of scope for this bug though.
Created attachment 144164 [details] mylyn/context/zip
That's a good start. It would be nice if we could get rid of the border and the extra whitespace when the bug is intially opened. I find that it looks much better and separates the new comment field nicely from the description. This would be similar to the Bugzilla 3.4 web interface where some fields such as Assigned To are shown read-only initially and only editable when clicked. One thing I noticed is that the viewer did not have a context menu when in edit mode.
Created attachment 144335 [details] patch v2 This patch has the part in control of wether there is a togglePreview (previous patch also applied it to other editors, e.g. new comments). Also it removes additional whitespaces, but that means on focus (edit) there might be just a single line. Resizing on click does not seem to be desireable, as it is not a smooth process, the editor will loose focus and screw up the whole auto-toggling as well. I think we might have to live with the default size, it seems better than a reflow on click. I added the missing menu bug (preview in general had no context menu, the new feature just made it more obvious). I tried the no border thing, and though I could not make it work in a good way, I saw that it looks quite weird to me. I think having the border is better, since that is what people expect if something is editable in the task editor. I will attach another patch without the height packing.
Created attachment 144336 [details] mylyn/context/zip
Created attachment 144338 [details] patch v2.1 promised patch with the description height untouched... I think we should rather go with this one, since having the field to small is just annoying while editing
Created attachment 144339 [details] mylyn/context/zip
Cool stuff. I have applied the patch to gather some feedback. The only weirdness I noticed is that the presentation does not change to edit mode if you navigate to the description by keyboard but I couldn't figure out right away how to make that work properly. David, Mik, others, what are your thoughts on the automatic presentation switching?
We might have to use a traverse event for the keyboard switch...but guess the whole editor gets skipped since it can't take focus in preview mode
I would actually want it in new comments as well...if people have mixed feelings of the feature (be in in description only or all preview-enabled writeable richtexts), we could think of making it a third toolbar option (or making the one action a triple state action) to have editor, toggle preview and sticky preview. A Task Editor preference than could set the initial desired mode.
I like this mode a lot. The weirdness that I found is if you want to copy some text, it allows you to highlight in preview mode, but releasing the mouse causes a switch to edit mode and the text is no longer highlighted.
Created attachment 144578 [details] patch v3 Shawn, good point. Tricky to solve though. Here is one suggestion: setting the selection on the widget to switch to. I think this might be the ultimate solution, but as long as there is no mapping between preview and source, it is just totally weird.
Created attachment 144579 [details] mylyn/context/zip
Created attachment 144582 [details] patch v4 ...the other suggestion would be disabling selection while toggling...the user has to click, realizes while dragging it doesn work, release, click and drag again to select in the source. Another solution would be that the dragging itself would not trigger a toggle, but that means there is focus but preview, which is inconsistent. We could automatically past the selected stuff in the clipboard and then switch, but not sure how to let the user know that just happened
Created attachment 144583 [details] mylyn/context/zip
Is it not possible to toggle the widget and forward the event to the editor widget?
Does not seem to work, the click itself does not get "transferred". Also we would have the same problem, without a correct mapping between the two models, it would be weird, since you start dragging at one spot, and the slection would start most probably at a different position.
This is the JIRA connector. I wonder whether this will be also available for Trac.
It will work on all repositories having an editable description and a preview mode.
IHMO, this preview mode should be only used for the description, not for the comments. Or at least that should be configurable.
Initially it looks good however there are a couple of issues: * upon opening the task editor there's no way to know by looking at it that it's in preview mode ** previously the preview button would always be in a toggled state when in preview mode * I'd like to be able to highlight text in preview mode without having it switch to edit mode It makes sense to me that the switch to edit mode should be intentional, not magic. I'm not sure what the best solution is. I don't like how clicking in the preview makes it editable straight away. Having the preview button toggled would both show that the editor is in preview, and would provide an obvious means to switch it into edit mode.
* I do not think we can switch on the preview mode on default, seems like a regression since the user then needs two clicks to edit. Not really sure what harm is done wether the user knows he sees preview or source - if he cannot spot a difference, there might not even be markup used and thus he shouldnt be bothered. But we might have to make it obvious, not sure what the right UI for that would be though. * You can always make the preview sticky by clicking the preview toolbar and then be able to select text, nothing changed there.
Since we have dropped the approach to make the description have a read-only look and feel when the editor is first opened I think we should consider David's proposal and simply put activate the preview mode. It seems that for most tasks editing the description will be infrequent so requiring an additional click seems acceptable.
I would provide to extra options per repository: 1. Show Task Description in Preview mode (initially): true/false 2. Show Comments in Preview mode (initially): true/false So every user could decide what is the default and must click on the preview button to change to the non-default mode. Possibly, a task could keep the last state of both options between activations, but I am not sure whether this is too much features.
But if the togglePreviewMode is actually linked to the preview button pressed, how would one have a sticky preview and being able to copy past from that? Or would the preview button trigger a sticky preview, this the default, and the new editor would be the togglePreview?
Unless we can't reach an agreement on the preview mode I would like to avoid adding preferences: http://wiki.eclipse.org/Mylyn/UI_Design#Avoid_Preferences (In reply to comment #38) > But if the togglePreviewMode is actually linked to the preview button pressed, > how would one have a sticky preview and being able to copy past from that? Or > would the preview button trigger a sticky preview, this the default, and the new > editor would be the togglePreview? I would suggest to simply put description into preview mode by default and not make anything sticky. We could consider auto-switching the presentation to preview when the focus is lost in the editor but that might be too confusing or annoying. (In reply to comment #34) > It makes sense to me that the switch to edit mode should be intentional, not > magic. I'm not sure what the best solution is. I don't like how clicking in > the preview makes it editable straight away. Having the preview button toggled > would both show that the editor is in preview, and would provide an obvious > means to switch it into edit mode. Agreed. The only thing I am worried about is that it won't be obvious to many users how to switch into editor mode. I have seen multiple reports of users who missed the toolbar buttons entirely (particularly when the editor has a horizontal scroll bar).
I agree with Steffen here. I think it is very important that users will easily be able to edit the description (and that easy access is not provided with the toolbar in my opinion). That's why we came up with the toggle presentation, if the preview is shown on default. Problem is a lot of tasks (like bugs) will have the description hardly ever changing, so having it in preview and making it a bit more difficult to edit might be OK. Other tasks however will require the description to change a lot (using the description as a whiteboard), thus having this additionial click will not be desireable for those tasks. Similar argument, this time against the automated switch, is copying from the description. It sounded to me that you, David, like to copy formatted text from there. Most of the time when I copy something, I rather like the source. I should not vote or decide here though, since I basically implemented it as I would like it, so I am totally biased :)
Created attachment 144893 [details] patch v2.2 This is a fix for patch v2.1 Thanks to Steffen a bug was discovered for repositories with a read only description (creating a previewEditor for them as well, hiding incoming changes). This patch fixes that issue, as well as propagates incoming-changes decoration to all initialized source editors. It has no changes of patches 3 or higher in it.
Created attachment 144894 [details] mylyn/context/zip
Created attachment 145048 [details] patch v5 Thanks for investigating the bug Thomas. I have created a new patch that has your fix and also toggles the preview icon when the editor switches modes. The preview now requires a double click to switch into edit mode to make it easier to select text. Everyone, please bootstrap on the new code and provide some feedback if the new behavior is any better.
Created attachment 145049 [details] mylyn/context/zip
One big problem with that approach Steffen is, that right now it also applies to new tasks, having me click around like a maniac in a new unsubmitted task until I realized it is preview and I remembered the doubleclick :) But that should be an easy thing to fix.
Created attachment 145156 [details] patch v5.1 This adds a check so new unsubmitted tasks are not in preview mode on default
Thanks Thomas. Patch v5.1 applied.
I bootstrapped on this and find the double-click to make editable very awkward. I didn't discover it on my own either, as I haven't previously encountered another UI that uses that idiom. If we go with this I think that we have to try with the single-click to edit approach. Several web apps, such as Google Calendar, use this idiom. I haven't seen it in Eclipse, but I think it's worth trying.
We have already tried single click (see previous comments). Mik, you can change the click count in RichTextEditor.enableAutoTogglePreview() to see if single click works better for you.
Please note, that at least in Linux: - single-click means to set the cursor - double-click means to select a complete word - triple-click means to select a whole line I am used to this behaviour and use it quite frequently. So I guess I would find your click to edit feature rather annoying. How about a keyboard shortcut to toggle this quickly? Sorry for that late feedback.
> I am used to this behaviour and use it quite frequently. So I guess I would find > your click to edit feature rather annoying. The automatic preview does not break that. You simply need to put the view explicitly into preview mode if you want to use double click in preview which is consistent with the current behavior. > How about a keyboard shortcut to toggle this quickly? Yes, we could consider a keyboard shortcut as well but I think that in addition we'll need an affordance that is more intuitive and easier to discover.
I just tried this with a task repository that doesn't have comments and the description is edited frequently and I thought something was broken since I was unable to edit when I clicked in the field. I didn't realize that you had to double click to edit. Is there some affordance that we can add to inform the user to double click or use the button on the section? I feel that many users will think that the field is not editable.
Installed the latest dev build. Here's my feedback: # I like having JIRA descriptions in preview mode # A couple of unexpected things about the way it works ## double-click to edit is odd. Standard double-click behaviour on mac is to select the word under the mouse. My double-click Command-C to copy the word under the mouse didn't behave as expected. ## Once in edit mode (after a double-click) it switches back to preview mode if Eclipse loses focus. This is strange and frustrating, especially when other apps try to grab focus while I'm typing. (eg: when starting another Eclipse instance, the other instance tries to grab focus multiple times as it starts up) After using it for a day I'm -1 on double-click-to-edit and +1 on preview mode as default for existing JIRAs.
Thanks for the feedback. I have changed the switching to preview mode back to single click. It is now delayed by the OS specific double click interval. In case any text is selected the switch will not happen. I have triggered a new dev build. Please let me know how the new behavior is working out.
(In reply to comment #54) > I have triggered a new dev build. Please let me know how the new behavior is > working out. Great, I can't wait to try it out. I'm not seeing a new build here: http://download.eclipse.org/tools/mylyn/update/dev/e3.4/ Am I missing something?
Thanks for letting me know. The build failed. I have triggered a new one which should be available from the dev site now.
(In reply to comment #54) > Thanks for the feedback. I have changed the switching to preview mode back to > single click. It is now delayed by the OS specific double click interval. In > case any text is selected the switch will not happen. Much better. I can now select text for copy/paste, which is great. I'm also in the habit of selecting text while reading, which now works as expected too. In other apps and in Eclipse when text is selected I can normally clear the selection with a single click. In the task editor this causes it to go into edit mode which I is unexpected and counterintuitive. Perhaps single clicking should only cause a switch to edit mode when there is no current selection (or a selection of 0-length).
I do agree that this is much improved over what it was, but there are still some weird interactions as David pointed out. However, the more "cases" that we added (i.e. single click with selection doesn't switch), the harder it gets to explain and use the tool.
Still a couple of things that should be sorted out: * switching focus to another app causes the description to go into preview mode * single-clicking a hyperlink in the description switches it to edit mode
(In reply to comment #59) > Still a couple of things that should be sorted out: > * switching focus to another app causes the description to go into preview mode That is intentional but I can see how that could be surprising. What is the behavior that you would expect? > * single-clicking a hyperlink in the description switches it to edit mode That's an interesting case. The only solution I can think of would be to ask the hyperlink presenter to detect hyperlinks at the clicked location and ignore the event in case there are any but that would require reflection to gain access to the presenter. Would that work for WikiText?
(In reply to comment #60) > That is intentional but I can see how that could be surprising. What is the > behavior that you would expect? Here's what I did: # switched to edit mode in order to change the description # typed some stuff # switched to another app to copy some text # switched back to Mylyn, expecting to be able to paste into description area -- but it had gone back to preview mode I would prefer for the description to remain in edit mode after switching it from preview to edit. (Mylyn is trying to be too smart) > The only solution I can think of would be to ask > the hyperlink presenter to detect hyperlinks at the clicked location and ignore > the event in case there are any but that would require reflection to gain > access to the presenter. Would that work for WikiText? Agreed, this is tricky. Asking the hyperlink presenter might be a good solution. It'll probably work for WikiText, though further investigation will be needed to confirm.
I get the feeling that different people have different use cases needing different behaviour - and that smart behaviour for one person is weird behaviour for the other. One thought would be not to automatically change the presentation, but make the selection persistent. Whenever the user selects "preview", next time he opens the task, the preview mode will still be enabled. There could be a wikitext option for the default presentation for editable descriptions. As for the current solution: I do find the delay a bit weird, and I found myself double clicking (and wondering about that this is still needed) lately - until I realized that there is this delay now. So I am not too happy about that - if I click into a textfield and it is editable, I expect a cursor to show up immediately.
Notes from today's call: * Replace preview button by edit button * Disable auto toggling to preview mode on focus loss
I have committed another round of changes. The edit icon may need some refinement and the maximize icon get scaled which has to be addressed as well. Let me know how you like the new behavior. A new build is underway.
Created attachment 148035 [details] rounded borders on windows
h3. UI review from weekly call * Working very well overall * Would be nice if we could avoid toggling editing after a range selection is made
Thanks for getting this done Thomas and everyone for the great discussion! As far as I can remember we haven't had a bug with 66 comments in a while. I'll mark this bug as resolved and have collected the remaining nits on bug 290469. Please check that I haven't forgotten anything.
*** Bug 294292 has been marked as a duplicate of this bug. ***
