Improve usability and extensibility of Link Editor

[bwaidelich]

Description

The Link Editor is one of the most crucial editor in a CMS. Ours is currently very straightforward but IMO it lacks some important features.

Missing features (IMO)

• It's not easy to find the correct target page for a site with many pages
• Cross-Site links are not transparent/possible
• It's not (easily) possible to link to an anchor of the current page

In general there are some UX issues with the current implementation in my opinion:

UX issues

Creating Links 1

• The node URL underneath each item in the result is pretty useless (even without the "/neos/preview" part it was usually too long to be helpful)
• By default assets just appear in the results which is rather confusing and not so easy to extend upon (see below)

Creating Links 2

• There is no (easy) way to know what node is linked – especially in large sites there might be duplicates in the title.
• There is no way to jump to the target page from here
• The preview URL is not helpful here either

Editing Links

"Dear editor, this is how we internally store page links. Deal with it" :)

No easy extensibility

Lastly, it's currently not a trivial task at all to extend the current Link Editor. It has been done by @dimaip for example but there is no API.

[bwaidelich]

I would suggest to make "link types" an explicit (and extensible) concept. This would allow us to provide (or reuse) a dedicated editor for each type:

Also folks could extend/limit the allowed link types to be used, for example to provide an easy way to link to product pages.

BTW: It's probably still useful to have a "search bar" immediately available for the "power users" and maybe that can be extended to provide support for special syntaxes like the search bar in Slack for example

[Sebobo]

Your scribble is basically the good old TYPO3 linkeditor ;)

But I agree, it would help make things clearer.

I think the biggest gain would be to "translate" the linkurl and suggestions to something human readable and give more space. Because that would also help in the inspector etc.

I'm not super into the tabs somehow.

[bwaidelich]

Your scribble is basically the good old TYPO3 linkeditor ;)

Yep, that's what I had in the back of my head :) Though the TYPO3 link editor is a little too low-levely IMO (CSS-Class, Link Parameters) and the "link type" API inofficial IIRC.

I'm not super into the tabs somehow

Yep, that's why I just created a mockup. I don't even want to try to come up with a good UI for this. But it should be a different editor per link type IMO

[lorenzulrich]

Maybe you meant this Discuss post: https://discuss.neos.io/t/initiative-improve-search-results-in-reference-editor/4622/2

[bwaidelich]

Maybe you meant this Discuss post

Yes, I think that was it. Thanks for linking!

[mficzel]

I like the concept but not the tabs. They also could lead to conceptually errors as tabs lie in the inspector usually allow to fill values on multiple tabs which is no valid usecase.

It makes sense to specify what to link first (with default to nodes) and then show optimized controls. That would probably mean a select box or radios buttons for the protocol (http://, node://, mailto://, resource:).

On the long run the protocol list could be made extensible but for that the linkingService would have to be extended first.

[bwaidelich]

I like the concept but not the tabs

I agree. In the mockups above the tabs should just represent multiple exclusive contexts

It makes sense to specify what to link first

Yes, that's true. Tabs didn't really communicate that. It's probably more like a 2-step wizard (if more than one link type is allowed)

[bweinzierl]

I think the most pressing issue is the inability to link nodes form another site (without using absolute links). That is a big issue for every site that uses neos in a multi domain context. Basically this is currently not really possible without cluttering the database with static links. It can be configured for all inspector editors like this, but not for the CKEditor Link Editor:

Neos:
  Neos:
    userInterface:
      inspector:
        editors:
          Neos.Neos/Inspector/Editors/ReferenceEditor:
            editorOptions:
              startingPoint: '/sites'

And a big +1 for the extensible concept of link types. It would be great if we could keep the configuration options relatively in sync (as far as possible) with the options of the Reference Editor

[Benjamin-K]

It can be configured for all inspector editors like this, but not for the CKEditor Link Editor

@bweinzierl: Actually I think that this is not the case. You can set the startingPoint for links in the CKEditor in the NodeType definition like this:

'Vendor.Package:NodeType':
  properties:
    text:
      ui:
        inline:
          editorOptions:
            linking:
              startingPoint: '/sites'

However, it is not (yet) possible to use ClientEval there, I already opened an issue for that.

[bwaidelich]

FYI: https://github.com/sitegeist/Sitegeist.Archaeopteryx implements a great deal of features in a separate package

[lorenzulrich]

Wow, that's absolutely great!

[creative-resort]

Is Archaeopteryx a candidate for v8.0?

@grebaldi

[iseries]

Archaeopteryx looks really cool!

[mficzel]

If someone is willing to do the work of moving Archeaopteryx we @sitegeist would be fine with that. Was always the plan in the long run. There are some changes that we would recommend still. It would require solid fe-skills, I can only support but am no fe-dev.

https://github.com/sitegeist/Sitegeist.Archaeopteryx/issues

[markusguenther]

Hmm, interesting. Can not promise but will look into it.

[mhsdesign]

https://discuss.neos.io/t/rfc-move-sitegeist-archaeopteryx-link-editor-to-the-core/6024