#12554 closed task (blessed) (fixed)
Change label in UI for Post Thumbnail and Page Image to "Featured Image" for both
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | UI | Keywords: | |
Focuses: | Cc: |
Description
We should change the UI label for the post thumbnail box on post and page editor screens. It's post thumbnail for posts, and page image for pages, but it's not always a thumbnail and the labeling is inconsistent. Let's call it Featured Image for both, which is consistent and removes the size implication of the 'thumbnail' label. Props to Ian Huet from WordCamp Ireland for reminding me that we talked about fixing this inconsistency and never got around to it.
Change History (13)
#2
in reply to:
↑ 1
;
follow-up:
↓ 4
@
15 years ago
Replying to TobiasBg:
Also keep in mind that the function names all include "thumbnail" now.
FWIW, the function names don't matter and shouldn't be factored into UX. (See also Network vs. multisite and *_option() versus Settings, and many other examples.)
Thanks for highlighting those changesets, I was coming here to do the same thing. I'm pretty sure "Page Image" was supposed to become "Page Thumbnail" but instances were missed in [12351].
#4
in reply to:
↑ 2
@
15 years ago
FWIW, the function names don't matter and shouldn't be factored into UX. (See also
Network vs. multisite and *_option() versus Settings, and many other examples.)
I agree in part. network vs. multisite was not in an official release yet (expect the separate WP MU). If you change thumbnail to image now, you would have to deprecate a few functions again, just because they were renamed (otherwise theme/plugin developers might go crazy).
To add on: I agree that "thumbnail" is not the best word, but a final conclusion and justification should be reached before changing anything. Might be a dev chat topic.
#5
follow-up:
↓ 10
@
15 years ago
What I mean is, when we change the label, we won't bother changing the functions.
We renamed the functions (briefly) last time is because they still hadn't progressed out of a beta release yet. Otherwise, we would very likely not rename an entire API for a change in terminology driven by UX.
#6
@
15 years ago
@TobiasBg: As @nacin said, this will only be a UI change, not a function change. If anyone has made documentation outlining post thumbnails they would have to update their materials, but I think that's better than retaining inconsistent and not-quite-accurate labels in the UI. The function names can stay the same. This would probably be a discussion topic for the UI group, rather than the dev chat, as it is a UI/UX issue only, not a code one.
#7
@
15 years ago
@jane: Thanks for the clarification. I had mistakenly assumed that this would also lead to a change in function names initially, but after chatting with nacin and due to your comment, this is clear now.
For the future however, we should not introduce too many inconsistencies between the naming of a feature and the functions involved.
#8
@
15 years ago
This is still a change that has been approved by lead devs and Matt, let's get this in.
#10
in reply to:
↑ 5
@
15 years ago
- Cc mikeschinkel@… added
Replying to nacin:
What I mean is, when we change the label, we won't bother changing the functions.
We renamed the functions (briefly) last time is because they still hadn't progressed out of a beta release yet. Otherwise, we would very likely not rename an entire API for a change in terminology driven by UX.
Just a comment about this. I agree that often it's not practical to change function names but please be aware that having names in the UI that are inconsistent with the function names that support said features can make it much more difficult for a plugin developer to figure out what's going on. For example, the featured image meta box has disappeared on a site I'm working on and it was unclear if I should not set the custom post type "supports" option to include "featured-image" instead of "thumbnail". Tracking down that answer took some time whereas if the names were consistent no such question would have occurred to me.
Something to consider... If you can't change the internal names because of conflict so be it but if you can create new function names etc. and deprecate the older ones I think there's real value there. JMTCW.
(P.S. I still haven't figured out why the metabox disappeared...)
#12
follow-up:
↓ 13
@
15 years ago
- Cc jer@… added
+1 on this for making the labels make more sense and be more usable. -1 if the plan is to disregard API usability while obsessing about UI.
IMHO the functions involved need to be overhauled completely rather than just renamed, so changing their names without reworking them isn't worth it.
They need to be synced to work more like sidebars and accept more parameters intelligently. Something like:
register_featured_image_size(array(name=>, id=>, label=>, description=>));
#13
in reply to:
↑ 12
@
15 years ago
Replying to jeremyclarke:
They need to be synced to work more like sidebars and accept more parameters intelligently. Something like:
register_featured_image_size(array(name=>, id=>, label=>, description=>));
+1
Just to remind of a few back-and-forth commits (i.e. the commit messages):
[12339], [12343], [12344], [12351]
Also keep in mind that the function names all include "thumbnail" now.