Last modified: 2014-06-25 17:34:15 UTC
We have an imho fundamentally broken model for inserting links. I don't know why we show the Link tool in the toolbar when there is no selected text because it's pretty much impossible. The tool is optimised for adding a link to existing text (or typing the label out first, which is unnatural for anyone who hasn't acquired it as a habit due to this bug), and for changing the link target. A few use cases: * Add link in list - Add item item (press return after the last item or create new list) - User has a page or url he wants to link to - Press "Link" tool - Type target page name or url - User wants to insert link with that label, or (more likely in case of an external link) have the label be something that is not the link target. * Add link while typing text * Update mistake in text (e.g. text mentioning "born in the US" or "born in 1955" and the link and label of US/1955 should be another country or year). I think the frequency at which one needs to only update the link label or link target are significantly lower, but the other cases are certainly not edge cases. Here's a recording of me painfully trying to insert a link: http://cl.ly/3s460Q442L3S To this day I have not once been able to insert a link without running into a bug that would've discouraged me as a user. I thought I filed these as separate bugs at some point but I can't find them. Issues encountered in the video: 1) Inserting a plain external link and then typing its label causes an exception (a pawn appears; see video). 2) The link inspector seems to lack an intuitive way to apply the change. During the video you can see me at various points being confused and eventually pressing "Back" (or pressing Enter) to apply the change. Especially when inserting a new link or changing an internal link to an external link (albeit by accident) it's counter-intuitive to not see anything in the page or to continue seeing a red link when I've already selected the value from the dropdown menu. I think when the user selects the value from the dropdown menu, that's when we can apply the change (but keep the inspector open). An interface component like this one that has no "Save" button and implies automatic saving should either make sure the object being changed has no visual impact or make sure it is applied live (And not suddenly when clicking away / blurring the inspector) 3) Adding a label (or rather, due to the lack of an input for the label, being forced to change the implied label) is unusable due to lack of text selection within the boundaries of the link (see video). 4) After the link is inserted, the link text is selected in the surface (the link target in the inspector, which is still open, is also selected). It's not clear whether typing will replace the label or the link target (see video).
Regarding the pawn, that also ate the first character (see "bc" instead of "abc" appear in the recording).
Created attachment 15744 [details] Example video showing that issues are caused by having a link immediately preceding the new list item
(In reply to James Forrester from comment #2) > Created attachment 15744 [details] > Example video showing that issues are caused by having a link immediately > preceding the new list item This video does not follow the same steps. The link existing in the previous list item is irrelevant. You're pressing enter and clicking stuff in between which is what makes it save and work. Those are reflexes as result of hitting these bugs in the past presumably. Here's the proof: http://cl.ly/2P2h473b2A20
I've filed the pawn bug as bug 67088.
The link inspector has long been our most concentrated area of bugs. UX changes are coming in response to user testing, and many bug fixes are on their way as well - more are needed obviously. 1. There is no universal link creation process, as every application differs here, but I believe we are not totally off base in our initial design. As usually, we have to solve this problem with the most difficult constraints imaginable. Users are meant to be able to successfully navigate through a 3x3 matrix of options: link existing text, change linked text, create new link text; link to an internal page, a fragment on the existing page or an external page; produce an explicitly labeled link, an automatically labeled link or an unlabeled (external) link. We need to map out all the use cases and come up with a process that covers this matrix elegantly. 2. User testing has confirmed that, even though pressing enter, escape and clicking away all serve to apply and close, users want a button, and the back button doesn't make sense to them. The new design will do away with the back button. It will move the remove button to the bottom left and drop the confusing icon in favor of a destructive button labeled "Remove". On the bottom right will be a primary button labeled "Done", which will behave the same as pressing enter, escape or clicking away. 3. We need to use the transaction staging system to update the selected content dynamically as you type, making the link appear to be internal, external, red, auto-numbered, auto-labeled, etc. 4. The bug you experienced needs to be addressed, and I will see if it is resolved (or can be resolved) by my context and window refactoring work. The whole system has suffered from having a narrow entry point with too many poorly mapped forks in the road producing unreliable results with any given path at any given time.
Better followed-up in specific bugs and proposed UX changes, as discussed.
