WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 19 months ago

Last modified 19 months ago

#36574 closed enhancement (maybelater)

Redesign term pages

Reported by: ramiy Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: has-ui-feedback has-ux-feedback
Focuses: ui, administration Cc:

Description

Now that WordPress Terms are mature enough, let's redesign the term.php view to match the post.php view.

See the attached screenshots (before and after).

Attachments (3)

edit-term-old.png (94.0 KB) - added by ramiy 4 years ago.
edit-term-new.png (79.5 KB) - added by ramiy 4 years ago.
36574.1.patch (32.5 KB) - added by m1tk00 4 years ago.
in progress

Download all attachments as: .zip

Change History (23)

@ramiy
4 years ago

@ramiy
4 years ago

#1 @theMikeD
4 years ago

Like.

This ticket was mentioned in Slack in #design by ocean90. View the logs.


4 years ago

This ticket was mentioned in Slack in #core by m1tk00. View the logs.


4 years ago

@m1tk00
4 years ago

in progress

#4 @m1tk00
4 years ago

The requested functionality is in place, since this is my first contribution i will like to have some feedback from the elders. I left the extra fields displayed in table format since the "old way" has table wrapper.

I added new javascript file to handle the slug functionality.

Modified the existing sample_permalink_html functionality to work for terms too.

Should i add the same layout for new term, same as the list of terms?

This ticket was mentioned in Slack in #core by m1tk00. View the logs.


4 years ago

#6 follow-up: @karmatosed
4 years ago

  • Keywords ui-feedback ux-feedback added

If the changes suggested are edit-term-new.png I have a few things to raise.

  • There's a lot of data from the old one that seems to be missing. I totally get that it could be available through screen options or showing. But, the point is not having at the top seems to not make so much sense.
  • Terms and posts are different things. What evidence (from users for example) do we have that they should have the same interface?

#7 in reply to: ↑ 6 @theMikeD
4 years ago

Replying to karmatosed:

  • There's a lot of data from the old one that seems to be missing. I totally get that it could be available through screen options or showing. But, the point is not having at the top seems to not make so much sense.

Not sure what you mean by "a lot of data." Can you be more specific about the missing info? Name/slug/parent/description are all there.

  • Terms and posts are different things. What evidence (from users for example) do we have that they should have the same interface?

I'm not married to this specific interface either, but it is a step in the right direction. And it's tough to answer a question that has never been asked. I don't think WP does focus groups for UX does it? If they do I'd love to be involved in that.

I think UI uniformity (or at least similarity) is a laudable goal. FWIW I would love to see a rich text editor for the term description here as well, not just a simple text editor.

#8 @karmatosed
4 years ago

@theMikeD I was going by the screenshot as said here: https://core.trac.wordpress.org/attachment/ticket/36574/edit-term-new.png. If there have been changes, great can you post up another screenshot?

I don't see why we should rush into changing this particular UI to be uniform. UI uniformity makes sense if it's the same or similar thing. I am not sure this is.

#9 @theMikeD
4 years ago

Yes, thats the one. Specifically what is missing? And FTR I don't think anyone is rushing on this ticket :)

#10 @swissspidy
4 years ago

There's a lot of data from the old one that seems to be missing.

I don't see anything missing: title, slug, description, parent term are all there. There's even a delete button (see #9777) and a count being displayed.

I don't see why we should rush into changing this particular UI to be uniform. UI uniformity makes sense if it's the same or similar thing. I am not sure this is.

The UI for editing single media items is similar too, even though it's not the same thing either.

As a user, I'd welcome a move to a more similar UI when editing terms, but that's just my two cents.

#11 @SergeyBiryukov
3 years ago

There's a lot of data from the old one that seems to be missing.

edit-term-new.png looks good to me. I don't see anything missing there, except field descriptions maybe, but I think they belong more in the Help tab anyway, for consistency with other screens.

Last edited 3 years ago by SergeyBiryukov (previous) (diff)

#12 @swissspidy
3 years ago

  • Milestone changed from Awaiting Review to Future Release

Related: #39835.

Moving this to Future Release for consideration.

#13 follow-up: @joyously
3 years ago

Just a user opinion: I don't like the suggested change because it looks too similar to Posts. A category is very different from a Post, and should look different. With the new editor, they will look even more different, and that is a good thing. It's easy to get lost if all screens look similar.

#14 in reply to: ↑ 13 @ghovens
2 years ago

Replying to joyously:

Just a user opinion: I don't like the suggested change because it looks too similar to Posts. A category is very different from a Post, and should look different. With the new editor, they will look even more different, and that is a good thing. It's easy to get lost if all screens look similar.

That would be my first thought too, but after thinking about it a bit more I think it would be good to make it more similar to edit Posts. The reason being that it makes it more clear that Category is a real page on your site and not just a way to structure large amount of posts.

Kind regards,

Gijs

This ticket was mentioned in Slack in #design by boemedia. View the logs.


19 months ago

#16 follow-up: @boemedia
19 months ago

  • Keywords has-ui-feedback has-ux-feedback added; ui-feedback ux-feedback removed

We discussed this ticket in todays triage and we agreed that the new screen looks more confusing than the old one, if looked at it from a user perspective. We don't see a need to align this screen with the post.php.

Another thing to keep in mind is, that from an a11y perspective, at least the old screen has properly associated <label> elements (Name, Description, etc). The new design has none. (thanks to @afercia for pointing that out). Therefore, the design team advices not to make the change.

#17 in reply to: ↑ 16 @ramiy
19 months ago

Replying to boemedia:

Another thing to keep in mind is, that from an a11y perspective, at least the old screen has properly associated <label> elements (Name, Description, etc). The new design has none. (thanks to @afercia for pointing that out). Therefore, the design team advices not to make the change.

From an a11y perspective the <label> tags have screen-reader-only classes.

#18 @pento
19 months ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Going to close this as maybelater: the term screen will presumably be revisited at some point during the Gutenberg project, but I suspect it will be significantly further down the line.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


19 months ago

#20 @johnjamesjacoby
19 months ago

We don't see a need to align this screen with the post.php

With Gutenberg merged into WordPress, this is no longer how post.php looks.

The nice thing about graduating this screen to look and feel more like what is proposed, is that it implies using the meta-box API to register and manage the individual term-meta and term-relationships, neither of which have their own UI at present, and must be totally reinvented every time.

The bad thing about that is the silent not-silent charge to deprecate the meta-box API without officially saying so, even though it's used all through-out WordPress admin and by thousands of plugins.

the term screen will presumably be revisited at some point during the Gutenberg project, but I suspect it will be significantly further down the line

This implies that the future of Gutenberg is more than just a content or a visual site editor; that its actual intent is to be the single interface to interact with all aspects of WordPress. Is that accurate?

Perhaps more importantly, does this mean there is another feature freeze on all screens until that's decided?

Last edited 19 months ago by johnjamesjacoby (previous) (diff)
Note: See TracTickets for help on using tickets.