Linking in ILIAS Editor

1 Requirements

We had some discussions during ELBA-developments. If a user want to set a link to an external website (xln)-Button, then there is no Wysiwyg solution.
Here the discussions (in green):

• Verlinkung Seiteneditor WYSIWYG
  • siehe AR, 17 May 2011: http://www.youtube.com/watch?v=MxFz7pdI8-c
  • AK, 17 May 2011: Das war auch schon mehrmals Thema. Hier noch einmal die Probleme: Es gibt in ILIAS mehrer Arten von Links. Interne, externe und Wiki-Links. Diese werden in der Präsentation alle gleich dargestellt. In einer Editor-WYSIWYG Ansicht ist also weder die Art noch das Ziel erkennbar. Man muß auf den Link klicken um diese Information zu haben. Im Film wird recht deutlich,wie die Usability leidet. Normalerweise sieht man sofort Ziel und Typ und kann dies sofort(!) ändern. Gerade bei Standard-Wiki-Links muß man nur den Text ändern und hat sofort eine andere Seite verlinkt. Im Film muß man 1. Zunächst oben den richtigen Knopf finden (das ist durchaus eine Hürde) 2. Die Eingabefelder füllen 3. evt. ein zweites Einabefeld ansteuern und 4. OK betätigen. Gewonnen hat man wenig, es wird blau dargestellt und interessante Information "versteckt".
  • AR 27 May 2011: Das Argument 1 (Finden des richtigen Buttons) gilt auch im heutigen Modus. Die Frage stellt sich am Ende, was man höher gewichten möchte: (a) Die Erwartungshaltung der heutigen User, sich nicht mit "Code" beschäftigen zu müssen und die damit verbundene, mögliche Abschreckwirkung oder (b) die potentiell schnellere Handhabung bei einer Link-Änderung - vorausgesetzt man weiss, wie es funktioniert. Mit einer Lösung à la Google Docs ist man vermutlich mind. gleich schnell unterwegs und ist dennoch über Art und Ziel informiert (ein Klick darauf genügt, siehe Screenshot "Google Docs Verlinkung"). Zudem kann man blau markierte Links in einem längeren Textblock besser erkennen. Eingaben mit http://... würden automatisch mit der URL verlinkt werden. Das ELBA-Team favorisiert klar Version (a). Ich (AR) meine, dass man sogar alle drei Linkarten in einem Button zusammenfassen könnte.
    • Falls Variante (a) nicht umsetzbar: Beim Klick auf den Button XLN sollen die Buchstaben "http://" bereits vorausgewählt sein (Vorteil: URL in der Zwischenablage kann direkt eingefügt werden) - oder der Cursor soll hinter das letzte Slash-Zeichen gesetzt sein (Vorteil: man kann die URL direkt reinschreiben).
    • Variante (c) --> Variante (a) wird umgesetzt und man kann es gleich wie beim "Bold, Italic und Underline" dem ILIAS-Administrator überlassen, ob er die klassische oder neue Sicht will
  • AK 16 Nov 2011: Leider ist die Google Docs Variante mit dieser Art Overlays innerhalb des TinyMCEs nicht einfach umzusetzen, evt. sogar unmöglich.

2 Status

• Scheduled for: not scheduled yet (was 4.4)
• Funding: Partly funded by Advisory Council
• Development: Feature is to be developed by Leifos

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: lauener@ilub.unibe.ch

4 Discussion

HJL (12.3.12): Please discuss in JF the two positions (Alex` and our arguments are in the ELBA-discussion above.)
 
1a. Do you also that a solution like the linking principle of "Google-Docs" should be our aim. (and: @ Alex: Did you found a solution?)
2b. Or do you think that we should not change the actual code-solution?
 
 
 
If you decide that you do not want to change the actual linking-behavior then we suggest that the wording in "http://" should be selected if a user click the "xln"-link.
If you think that a "Google-Docs"-solution could be possible, maybe it could be also a good idea that System-Admin must decide which behavior (Wysiwyg-principle or Code-principle) his platform uses. (same question for him like the decision: str-buttons or b-buttons ?)

JF 2 May 2012: We think that a Google-Docs-like solution would be a good way to provide WYSIWYG, to keep usability and to have a quick way of letting the user know what link is behind the current cursor position.

Alex 2 May 2012: I would like to make this a probable 4.4 improvement, since the current code may need some basic changes to make this possible.

ILIAS_LM, 2013-03-18:
Oh, nice topic! This is my wishlist now...
 
A very simple/slim solution would be nice:
One single button for all links: Internal, external and even mail adresses, as it it is possible in some CMS.
Like someone mentioned in the page comments: One should always be able to choose "open in a new window" or "open in the same window", no matter, if external or internal.
 
And if this is technically possible:
ILIAS should be able to check, if it is an internal link. So if the domain changes there will be no problems.
 
Btw: As a simple user I don't care if the code behind is "str" or "b". I only want to understand the buttons. So if there's written "bold/fett", "italic/kursiv" and "underline/unterstrichen" I do understand quickly and am happy. The same with xln and iln: No one wants to have to think about their meanings. A simple user wants a known link icon or the word "link". What a developer exactely does with it isn't important for the user. S/he doesn't care at all, believe me. ;-) «Don't make me think!»

Reto Schürch – 18.10.13: Please also integrate the possibility to open a link (external and internal) in a new window or tab.

Matthias Kunkel, 18 Oct 2013: Postponed and unscheduled due to missing funding.

Alex Killing, 11 Feb 2014: In the meantime another wysiwyg editor gets more and more attention: CKEditor
Google Trends, TinyMCE vs. CKEditor
E.g. their support for widgets CKEditor Widget Demo could be very valuale for media or link editing.

ILIAS_LM 2014-04-09
@Alex Killing:
If you would switch from TinyMCE to CKEditor > Would every editor in every object type be switched? And the ILIAS editor also?

Alex Killing, 11 Feb 2014: @ILIAS_LM, all places where the ILIAS page editor is used would be switched. Not the places where the "standalone TinyMCE" is used for HTML editing. First step should be a "Machbarkeitsstudie" for a possible replacement of Tiny with CKEditor (within the ILIAS page editor). I already offered this to one institution.

Alex Killing, 11 Feb 2014: @JourFixe: My preference would be to create a dedicated FW page for the CKEditor topic and to look for funding for a "feasability study" (not sure if this is the correct english term).

Matthias Kunkel, 13 April 2014: I have added a new wiki page « Suggestions for an Improved ILIAS Page Editor (outdated) » and added a link to this page.

Matthias Kunkel, Alexander Killing, 13 June 2014: Due to the dependency to a possible CKEditor migration, we postpone this topic to 4.6 earliest.

5 Implementation