Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve visibility for additional layout tabs #160

Open
MoritzLost opened this issue May 22, 2024 · 4 comments
Open

Improve visibility for additional layout tabs #160

MoritzLost opened this issue May 22, 2024 · 4 comments

Comments

@MoritzLost
Copy link
Contributor

MoritzLost commented May 22, 2024

What are you trying to do?

Any layouts tabs beyond the first tab are hidden inside the tiny ellipsis () menu:

Screenshot 2024-05-22 at 17 06 51

I already know that I'm going to be sending this screenshot to all my clients on a weekly basis if I use any additional tabs. This type of menu says Don't touch, this is not for you to authors. I know it's used in multiple places in Craft 5 (and I mostly don't like it there as well), but for layout tabs there is no precedence for using this UI element.

What's your proposed solution?

My preferred place to see these would be as tabs next to the link type dropdown. This wouldn't take up any additional space, but would clearly show that there are additional tabs, and show the tab labels without an additional click.

Maybe there could be an option to toggle between those two display types, so I can decide between accessible tabs and the more minimal UI?

Additional context

Edit: I just noticed that you get a cog icon instead of the ellipsis menu when the field is set to a single link so the drag handles are not present:

Screenshot 2024-05-22 at 17 47 00

This inconsistency should be addressed as well. I guess it's because the ellipsis menu also has the option to delete the link, if multiple links are allowed. But still, a very similar function is presented with two different icons depending on field settings.

I would argue in favour of removing the cog icon, putting tabs as visible tabs in the header as suggested above, and only use the ellipsis menu for the delete action.

@engram-design
Copy link
Member

Tabs are an interesting idea, but there's responsiveness we need to think of, which is a little work (converting to a dropdown on small devices). We'll have to copy what Craft does for tabs.

I'd certainly argue against "Don't touch, this is not for you" conveyed as the action for an ellipsis action. I've always thought of this button as "extras" or "more". Although that may be better suited to a vertical ellipsis. In any case, the Craft UI informs us this is used for extra options in the form of a dropdown, and we're aligning with that. It's used in a lot of places as you mention - some common client items like multi-site switching or breadcrumbs - so I wouldn't say this denotes something advanced.

I think having some options is a good idea though, and certainly open to it. There's something to be said for things like "Classes" or "Input Attributes" being available, but hidden away in a slide-out. Not many client content editors will interact with those (except the savvy ones). So we'll see what we can do about providing some options there.

As for the inconsistency, you're correct that there's different behaviour for a single-link field and multi-link field. This was discussed in #127 (comment)

The ellipsis is there to have any additional actions as a dropdown. It doesn't make sense to have the slide-out have that icon, and it doesn't make sense to have a dropdown for just a single item to click on "Settings" for the slide-out. That's just one extra click you don't need. I was never a massive fan of the inconsistency, but seems like everyone has an opinion on this...

@MoritzLost
Copy link
Contributor Author

@engram-design I think we have different types of clients 😅 I have a lot of clients who only use the CMS occasionally and/or where it's not their primary job to update the website. For those, any interface element that's slightly hidden or buttons with icons only might as well not be there. For example, many have never discovered the searching and filtering capabilities of Craft's element indexes, because they're hidden behind the tiny filter icon …

I think having some options is a good idea though, and certainly open to it. There's something to be said for things like "Classes" or "Input Attributes" being available, but hidden away in a slide-out. Not many client content editors will interact with those (except the savvy ones). So we'll see what we can do about providing some options there.

You're right, it depends on how important the fields inside additional tabs are. For now, I'm placing everything I definitely want editors to see in the first tab, and not really using additional tabs. The current UI will be useful for options that I need myself sometimes, but don't need editors to use regularly.

I was thinking about the URL suffix field. Not used in every link, so I don't want it taking up space in the first tab. But it's used regularly enough (e.g. to link to a specific section on a page) that I want it easily discoverable. Tabs with visible labels would be ideal for this.

If you built tabs into the layout, there could even be an option for every tab for whether to place it in the ellipsis-menu or as a visible tab. Just thinking out loud here, I realize this would be a lot more work. Just having tabs instead of the ellipsis-menu would be a huge improvement even if it's not configurable.

@engram-design
Copy link
Member

I think we have different types of clients

I'm not at all surprised, and can always appreciate another perspective or two. I know clients' technical skills vary far and wide!

I think the trick to implementing this will be for the field layout builder itself, which is what Craft does. There's no real way to say "This tab should be in a slide-out", but I'll look at some options here. Giving people the flexibility to use tabs and the slide-out is the ideal path here - I think we're in agreement on that.

I'm hesitant to just switch everything to tabs to be a major UI change in a point release, so providing an opt-in way is the only way to go at the moment.

@MoritzLost
Copy link
Contributor Author

@engram-design Fair enough 👍 I would appreciate the option to have visible tabs, or a hard-coded behaviour change would suffice (at least for me). But understand it's a lot of work and a BC break. For now, we can work around by either putting some UI element in to inform users how to access additional tabs, or just by putting all relevant fields in the first tab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants