Skip to content

Add "slim" interface for link input #1

@engram-design

Description

@engram-design

One of the goals of Hyper is to provide an excellent AX for editors adding links. This includes how the user interacts with the field, particularly when it comes to speed and visual overhead of editing link content.

Currently, we have a "block" style editor for field:

image

The benefits of this are:

  • Only showing information most commonly used to define links
    • Link Type
    • Link Url/Elements
    • Link Text
    • New Window
  • Being able to use the field layout designer to manage what fields are shown. Maybe Link Text isn't needed, or you can add your own, make some fields 1/4 or 1/2 width, etc.
  • Clearly separates links from other fields, which is important when a single field contains multiple bits of content, they'll get lost if they're not visually associated with each other
  • Settings to show the slide-out editor for other fields/attributes (you can manage what fields are initially-rendered vs hidden away)
  • Moving link blocks for multi-link fields feels similar to Matrix/etc

So, while flexible, there is a reasonable amount of "grey" on the screen, and visual space taken up. This is even more pronounced for multi-links Hyper fields, where we get the dreaded "vertical space" issue that's synonymous with large Matrix/Neo fields.

An option is to provide developers the ability to switch to a more slimline version of the field, focusing on just the essentials. A proposal for this is:

image

Which shows the 3 distinct states of a field, and also represents how a multi-link field would look. In this example, it's 3 links in a single field (just to demonstrate states). It's far more streamlined with just the link type, url/elements and settings (and move icon for multi-link fields).

The drawback of this concept is that the Link Text is hidden under the settings slide-out. I don't personally consider this a "secondary" bit of content. You'll rarely ever want to use a field with the URL as the actual text of the <a> element, so for URL type fields, you'll almost always want to input both content items together. For element-type fields, that's indeed a secondary setting, relying on the element's title for that.

You'd also lose the ability to use the field layout designer to customise the interface and adding custom fields and UI elements to the initially-rendered field. These would solely be contained in the settings slide-out.

The entire point of this is to prioritise primary content, but not compromise on a great AX that doesn't overwhelm content editors. Keen to hear people's opinions.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions