This has been changed intentionally. See spec
http://specs.openoffice.org/appwide/SmartTags/Smart_Tags_Specification.odt. 
Hyperlinks in Writer now work via Ctrl+click (also not the tip appearing over a
hyperlink).

Closed.

Me in the role of the user that isn't able to cope with changes ... oeps :-[
Apologies.

On Mac OS X , ask to use CTRL + click is a mess.

Users will tell us a link is made to be clicked...

Reopening.

I think this change is nonse. The section 1.4 in the specs is seriously broken.

We can't change the paradigm of clicking to the link!

add me on CC

Adding Lutz Hoeger on CC.

I too think that it is a great usability error if a link doesn't work with a
simple click. It is no good idea to introduce such serious changes in a subpoint
in a spec about "smart tags".

*** Issue 80004 has been marked as a duplicate of this issue. ***

This is like the option "[don't] show inactive menu items" disappeared all again...

I agree it was no good idea to implement this important change as a by-product
of an other specification (smart tags).
See issue 79438 for some more observations

FL-> UFI: We did that change within the smarttag cws to get a consistent
handling of smart tags and hyperlinks in documents. Furthermore this change for
hyperlinks was already planned due to security related issues.

I will prepare a separate specification for this change to improve communication
of this change. Spec. will include a competitive analysis.

We have implemented this because of the following reasons:
- adapt to handling for Smart tags in Writer
- ease of use: it is more easy now to edit a hyperlink; the "HYP/SEL" in the
status bar is anything else than intuitive
- Writer is a Word processor, not a browser. Edit functions are more desired
than browsing features.
- References are not affected
- security issues
- last but not least: competitive analysis, as FL already mentioned.

So please do not blame a change of "traditional" values we make as nonsense.

MRU->FL: but what we could think about is, that in a TOC normally not external
links are available, so maybe it's worth to think about keeping the old behavior
in TOC's. Though the competitive analysis will point in a different direction...

Adding myself to cc.

yes, in my opinion, links in read only mode (and read only sections like ToCs)
should work with a single click.

ToCs are inserted in a read-only section by default, but this protection against
changes can be removed by an option in the Index dialog. So it would work some
times and some not. But as I said in #79438# I also think that this is an option.

Hyperlinks to other documents in Developer Snapshot Build SRC680_m223, require
CTRL+Click in Writer, but not in Calc. Does this mean that when the tabs in OOo
are implemented we will have to CTRL+Click in one tab, and  just Click in the
next tab? What an innovative mess it would be!

I have uploaded a first version of the spec. Have to look at some more products
and discuss this with FME:
http://specs.openoffice.org/appwide/hyperlinks/Behavior_of_Hyperlinks_in_OOo_Documents.odt

-> fl: thanks. Where can we go for a Q&A on this specs?

I would like to convey to you some ideas and feelings as an OOo non-IT
specialized user, and after trying the Developer Snapshot Build SRC680_m223 and
reading the first version of the hyperlinks spec document
(http://specs.openoffice.org/appwide/hyperlinks/Behavior_of_Hyperlinks_in_OOo_Documents.odt)

1. Ease of use and security when editing documents.
1.1. When I edit a document, I am concentrated in the subject I am writing on,
and I do not want to be disturbed by the variegated behaviour of the program: if
I want to go somewhere within OOo or out of it, I want to do that with the least
effort and without having to think what kind of link I am facing to in order to
determine how I have to adapt myself to the program (instead of the other way)
through CTRLs, clicks and +s; otherwise, I would be distracted from my main task
as a user.
  It should not matter the kind of link I click; I only want to be assured that
if I click a link, I will go where the link tells me, no matter if it is a
footnote, a reference, a TOC, a weblink, and so on. I think, in other words,
that the best would be: what you click is what you get (WYCWYG; or what you get
is what you click, WYGWYC; doesn't matter).
1.2. The browsers have just contributed with this (to use pjanik's expression)
paradigm. I do not see why we should deprive ourselves of this advantage. Would
it not be OK if people thought that OOo is as easy to use as a browser? Browsing
and just clicking is precisely what I need to be able to concentrate on my task
as user (behalve of course in case I am a typist), without being disturbed as I
mentioned above. In other words, to be concentrated on editing the content of my
document, I need to be able to browse.

2. The behaviour of hyperlinks in the different modules of MS Office.
  MS Office is, in this case, not a good reference at all.  It is, on the
contrary, simply a good example of what it is to be avoided. It looks like MS
Office has not been able to completely strip itself of the legacy of the old
Word Perfect: CTRL+some key, ALT+some key, CTRL+click, and so on, now even
aggravated with the fact that the result changes according to the MS module! I 
think that these pairs (CTRL+.., etc.) are OK only as alternative shortcuts.

3. Informative tag above the hyperlinks
When I was introduced a hyperlink in my document, the tag appeared only after I
had clicked four or five times on the hyperlink. I was disconcerted, until I
realised I was in the presence of a hyperlink; so concentrated I was on the
editing of my document, that I had not thought I had to use CTRL+click instead
of simply and automatically pressing my forefinger. The tag came as in slow
motion when I was already beginning to simply use the Windows explorer to go
directly to the referred file. But if the tag had appeared quickly, I think I
would have found it a hindrance.

I would briefly conclude: give me WYGWYC (or WYCWYG), no WYGWYCTR-click.

fl: 8)

I have read the specs completely. Twice. I do not believe some parts...

1. Macromedia/Adobe DreamWeaver

   You forgot to add that they do not even *show* hyperlink as hyperlink in edit mode - I only see plain 
HTML there... Then we could also add that vi, Emacs DO NOT show hyperlinks as hyperlinks in edit 
mode thus we also DO NOT want to show hyperlinks as hyperlinks in edit mode as well!

   So this subsection doesn't make sense.

2. For part 2. I think we need a simple table: rows will contain what to do for: "edit hyperlink", "follow 
hyperlink" and columns: Writer, Writer (help), Writer (contents), Writer (readonly sections), Writer 
(readonly document) and the same for Calc and other apps.

  I have this table in my mind now. And believe me, it will be terrible...

Right now, I finally feel what lead to the change of behavior. Now I also think it is needed. But it has to 
be done:

- once
- for everything
- be consistent across OOo

I have this in mind:

- left click follows the link *everywhere*, *everytime*

- tooltip shows the link target and tip to edit the link (if editable - thus not for RO docs, not for RO 
sections, not in help, ...). If the link/section/document is not editable, only the target of the link should 
be in the tip.

- Ctrl-click edits the link, if allowed

- Context menu contains "Edit link"

[ - for 2.4 we will add a "security" - I call it "obscurity" option to swap the above mentioned behavior, 
thus with this obscurity option checked, clicking the link will edit it and Ctrl-clicking will follow it ]

What do you think?

mh, md: I consider this as a real problem, for *2.3*.

I want to pick out one other point: The Spec claims that the "user is
concentrated on editing documents not on browsing". It is strange, though, that
the Shift+F5 magic was implemented because the user was concentrated on reading,
not on editing, and hence needed always the very beginning of the document to be
shown. (Maybe because he than can easily access the chapter he wants by a simple
click on the corresponding line in the table of contents?)

Let's think about our users for real, and not for excuse: They are used to links
in both, browsers and OOo, but they maybe are not always aware about the HYP/SEL
switch. So, something needs to be done to make editing (selecting) of links
easier. But I don't see any good reason why we should change both, the features
for selecting and browsing, if changing the features for selecting only would do
the job - and with less spillover effects, on the top of everything.

You can deduce from the fact that additional "magic" is about to be implemented,
that changing the basic behavior of a link, that is: to work as a link, was not
the best idea ever. Why making the program guess whether a user wants a link to
work as a link or to be edited, if we can have a consistent and easy to
understand solution, that even doesn't upset our regular customers? Why making
links behave not only different from what they used to behave, but even
different from module to module and from editable to non-editable sections?

I agree with Pavel: Stick to the current (≤ 2.2.1) behavior for browsing (HYP),
introduce Ctrl+Click (and/or context menu) for what used to be SEL.

Hi,

Since others jumped in already after my question from 15:18:20, now I will also
ask my other reg. the specs questions in this issue.
I hope they can contribute to a right decission.

Sect. 1
About the argument "Ease of use when editing documents."
When www.thislink.org is a link in a Writer document and the text (click, type)
is changed to www.thatlink.org, it will still point to thislink.org. 
So this ease of use is that the left mouse button can be used direct to set the
cursor in the link (it is not necessary to use the key board ;-) or the control
at the status bar).
But couldn't "Ease of use when editing" be a nasty trap here? At the least, care
must be taken of the details when explaining this.

Sect. 2.1.1
Smart tags -  how do they behave in MsWord (competitive analyses)?
Are it the small tags that come up after for example pasting some rich content?
In the smart tag-specs, I don't see a picture of how this looks like.
(sect. 1 of that specs - "Mouse over shows a bubble help to guide the user to
click Ctrl+left click to show the smart tag context menu.")
I ask this, because I've no idea what is the use of Ctrl-Click on smart tags, in
stead of just Click. (Haven't been able yet to try).

Sect. 2.1.2
Foot notes. Here is choosen not to change the current behaviour. 
Is this because editing a footnote number is not relevant? 
And also because the way Word does it, is no improvement?

Thanks - Cor

I agree with pjanik, especially
 - a left click on the hyperlink should follow the link
 - the behavior must be the same in the whole application

Some comments on the spec:
(1) The spec refers to issue 22133, however it doesn't solve that issue, because
that issue is about a context menu for hyperlinks, which is not addressed in the
spec yet.

(2) The suggestion to expand the context menu in the way it is described in
issue 22133 is a much better way to solve the problem of hyp/sel switch. A
context menu has the great advantage that is can be reached without mouse. OOo
claims to be usable with keyboard only. Such context menu would follow this aim,
because not only editing but also following would be possible with keyboard.

(3) Those, coming from Microsoft Office, know the context menu and will have no
problem using hyperlinks in OOo.

(4) The current way to edit a hyperlink is to use the _Insert_ menu. That is
very bad UI design. The context menu is a well known way to edit things.

(5) (section 1.2.2, 1.2.3) In Word 2007 you must not use crtl-click but you can
configure the behavior. My suggestion is, to introduce such option in OOo too,
with default to "click follows link" and "ctrl-click edits link". In
environments, where it is a security problem, the admin can change it and
instruct his users, why a hyperlink are not working like it does commonly.

Current spec describes what has been implemented for 2.3. Target of this issue
is 2.4 and need further discussion with the iTeam. iTeam will be complete end of
August due to vacation.

I'd like to add one more comment to mru's fine list of arguments (Jul 25)
regarding the other applications: Calc and Impress handle hyperlinks as fields,
therefore the text is not selectable, therefore there is no need to
differentiate between 'execute link' and 'select text'.

As side effect of reading comments in this issue, I think we can sometimes
improve on the way we communicate, what, when and how we say/write things.
That can lead to better understanding, better choises for the product.
I'll see if I can have some exchange of ideas on this in Barcelona. And maybe
open a separate issue later on ;-)

This behavior is definitely not intended for non-document documents such as
DicOOo (see issue #81065). The document will not work like a wizard anymore and
users will  be asking why is that. Note that wizards will never use those smart
gadgets.
The feature should be at least switchable: if there are smart tags in the
document, turn this on, if there is no such thing, turn it silently off.

"Additional comments from mru Wed Jul 25 13:17:41 +0000 2007 
....
So please do not blame a change of "traditional" values we make as nonsense."

I appreciate when developing breaks with antiquated values that actually do not
make any sense.
But is the funcionality of a link as everybody it knows really antiquated?

We are all forced to learn every day for to be able to manage daily
requirements. A lot of the learning time we spend concerns not a real "content"
or "stuff" but only knowing how to handle programs and appliances without
creating really important knowledge. "Traditions" are not only old-fashioned
things but also facilitations. I think you would not like it if you'd have to
inform you every time you take your car what are the acually meaning of red and
green on traffic lights or if you should use the right or left side of the street.

Cheers, Claudia

I think the specs ignore the accessibility problems: people with disabilities
could have problems with clicking and using the keyboard at the same time. Is
there a keyboard shortcut for using the hyperlink? I could not find it in OOo
2.3 (dev).

Due to this unexpected change I stumbled over being unable to install
dictionaries. In terms of Windows conformity a link is clickable to activate
(not ctrl-clickable in this sense)

I am displeased with this change and suggest to revert back at least in the
Windows arena which clearly defines a link is clickable!

   

It is very strange, though, that the newly-implemented link to the extensions
repository (issue 78209) in the extension manager works with a single click, not
with Ctrl+click.

This change leads to inconsistencies in the user interface. Replacing the link
handling paradigm (i.e. "click") was an error in the first place. We should
return ASAP to the pre-2.3 behaviour (and maybe use Ctrl+click for SEL instead).

At a minimum, there should be an options to turn off the CTRL+click feature.

About the spec:
1.2.2 is inadequate. Actually, Default behaviour is what was explained, but 
there is an option to change it. And when you choose "click to follow", ctrl-
click does not edit. It should not IMO, since then you MUST know how the option 
is set to act when in doubt. Editing should be given another shortcut, or use 
context menu.

My 2 cents.

I happen to think it's a very good change. When I'm editing a document, I want
to edit the content. I've answered more than one forum question by users who
weren't able to figure out how to change the text of a hyperlink and then didn't
like the answer they were given. 

The focus to me in editing a document is on content. I don't need to be jumping
links (except to test them) when I'm editing. However, in read-only I should be
able to use the links, just like the document's audience would. And if the
change was made for security reasons, I'm all for learning to live with it --
nevertheless, users should be given the option to take that security risk and
change hyperlink behavior to jump around if they want to.

Issue #83402# will make the current ctrl-click behavior configurable for OOo
2.4. Ctrl-click behavior for Calc, Draw, Impress will be introduced and
finalized for Writer using this issue in OOo 3.0 time frame. Therefore set
target of this issue to 3.0.

It has already been suggested in issue 22133 to make an hyperlink editable via
its context menu.

Removed keyword "accessibility", because this is not an accessibility issue.
Behavior could be configured and context menu offers "Open Hyperlink" to follow
link beside the Ctrl-Click behavior. Changed target to OOo 3.x. Most important
seems to overwork the context menu and to offer edit, remove, open Hyperlink on
top of the menu.