Opened 12 years ago
Closed 12 years ago
#24291 closed task (blessed) (invalid)
Tweaks to Image post format UI
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | high | |
| Severity: | major | Version: | 3.6 |
| Component: | Post Formats | Keywords: | has-patch |
| Focuses: | Cc: |
Description (last modified by )
The image post format UI is not friendly enough. There is too much emphasis on providing a URL or HTML, and not enough emphasis on using the WordPress media library.
We should hide the HTML behind a click, kind of like WordPress.com's toolbar-poster does.
Attachments (35)
Change History (66)
#4
@
12 years ago
Based on @markjaquith's comments in devchat today, I mocked up a refined UI. I like the idea of using an 'Add Image' button because it's in-line with other media insert UI's. It could also be recycled as 'Add Audio' or 'Add Video' in a similar fashion. Took me a little longer than I'd hoped to mock up.
If it's too late, I apologize.
First image is the initial view, second is if you click the text link, third is if you've uploaded an image:
#7
@
12 years ago
Summary of what we did, through .19.diff:
- textarea not shown by default (hidden behind a click)
- Drag and drop upload
- Bigger click target for going into Media modal.
- Image preview height constrained (300 pixels), so your content area and click-through link doesn't get buried.
- Hid the options like alignment, size, etc, that didn't have any effect anyway.
Bonus: got wp-format-FOO working on the <body> class, so you can do body.wp-format-FOO .additional-selector {} rules to target anything on the page.
#8
@
12 years ago
24291.20.diff adds drag-over styles for the drag/drop.
#9
@
12 years ago
.20 was accidentally based off .9 instead of .19. Sometimes typos do that I guess. 24291.21.diff should be based off the right patch.
There's still a problem with the body class introduced in .19 that I haven't looked into. For new posts it starts with the class wp-format- instead of wp-format-{format}. This happens even if you use wp-admin/post-new.php?format={format}
#10
@
12 years ago
Looking at 24291.23.diff, the use of get_post_format() in admin-header.php. Perhaps we can make get_post_format() return false or null when no $post or no post format support and return '' (empty string) when a post format is not set, i.e. post_format == 'standard'.
Then we can use that to add the wp-format-* body class only when needed.
#11
@
12 years ago
Is there a problem with showing wp-format-standard when there's no post or post format support?
#12
@
12 years ago
There shouldn't be a problem but better not to add the body class on all admin pages. A plugin might use it to apply some css, etc.
#14
@
12 years ago
When uploading, the files can be restricted by extension in Plupload. Files with other extensions or without an extension would fail (silently).
Adding multi_selection: false would also restrict it to allowing only one file when the select files button is used (old IE), doesn't restrict how many files can be dropped.
#15
@
12 years ago
In 24291.27.diff:
- Limit the uploader to html5 runtime as w use it for drag/drop only. That means no instance in IE < 10. Fixes problems with the position of the flash runtime "Select Files" button covering the whole screen.
- Keep only the first file if more are dropped.
#16
follow-up:
↓ 19
@
12 years ago
Would like to clean up two strings in 24291.strings.diff.
Using printf() doesn't seem like a good idea here, it's too easy to accidentally remove a placeholder when there's no space between characters. Plain HTML is more readable.
I think printf() makes more sense for conditional links, like the one in [18917].
#19
in reply to:
↑ 16
@
12 years ago
Replying to SergeyBiryukov:
Would like to clean up two strings in 24291.strings.diff.
Merged into [24232].
#20
follow-up:
↓ 24
@
12 years ago
Currently when you insert the image, you're still inserting a block of HTML with the image wrapped in a link to the image file (even though it's now potentially hidden). This also means that the_post_format_image() on the frontend does not take into account properly the "Image click-through link" field. -- I'm sure this'll get ironed out, though, as you move on.
However, would it be a crazy idea to suggest that this work more similarly to setting a featured image and remove the entire element of being able to edit the custom HTML block? Then, essentially you're just saving an attachment ID and the optional "Image click-through link" field with the post format meta data.
It seems like the average end-user is not savvy with HTML or knowing what size of an image they should be uploading. I think this would simplify things moving forward, make the UI easier to use, help to create more of a standard, and allow the theme to take more of the control.
#24
in reply to:
↑ 20
@
12 years ago
Replying to jbobich:
Currently when you insert the image, you're still inserting a block of HTML with the image wrapped in a link to the image file (even though it's now potentially hidden). This also means that
the_post_format_image()on the frontend does not take into account properly the "Image click-through link" field. -- I'm sure this'll get ironed out, though, as you move on.
However, would it be a crazy idea to suggest that this work more similarly to setting a featured image and remove the entire element of being able to edit the custom HTML block? Then, essentially you're just saving an attachment ID and the optional "Image click-through link" field with the post format meta data.
It seems like the average end-user is not savvy with HTML or knowing what size of an image they should be uploading. I think this would simplify things moving forward, make the UI easier to use, help to create more of a standard, and allow the theme to take more of the control.
see fix for inserted HTML, #24289
#25
@
12 years ago
In 24291.29.diff:
- When initializing wp.Uploader pass
nullforcontainerandbrowser. Fixes a bug where another instance of the uploader was attached to <body>. - Destroy the uploader instance if drag/drop is not supported (IE8 & 9).
- Don't select/focus the title field content on switching formats.
#28
follow-up:
↓ 30
@
12 years ago
Trying to follow the various image post format UI threads and branches, and picking this one. I think there are still some serious usability issues here.
First, it seems to me we should follow the example of the "Featured Image" field. Once an image is provided, hide the uploader / HTML field, subbing it with a "Remove image" link that take discards the preview and replaces it with the fields.
Second, it seems to me if we're going to instantly show previews for uploaded media (sans saving), we should do the same for image URL / HTML. I realize this might be a bit heavy, but with some balance tags magic / sanitizing (which is already being being addressed for this field), we can can show the output from the free form HTML field when the field loses focus.
Finally, I know it's been raised elsewhere, but I'm not sure I even get the logic behind a free form HTML field (although I *do* get allowing a URL for an image), and I tend to lean toward strongly believing this is a bad idea, while being open to someone explaining the use case.
As theme developers, the free form HTML - which tolerates embedded links that override the click through field - makes it much harder than it should be to reliably pull the raw data out of this post format for fancier / alternate presentation of the content (in addition to making basic output, as it is now, somewhat heavy when HTML is provided). More importantly, it just seems bizarre to me that - in an image post format - I can just write something like "<strong>hello world!</strong>"... which is accepted and works. Heck, why don't we just call it a "free for all" post format?
Might there be uses cases for raw HTML in an image post format (struggling as I am to think of them)? I guess. But that's why we have hooks and plug-ins.
Again - tried to read through all the threads on this subject, so forgive me if I'm covering old ground.
#30
in reply to:
↑ 28
@
12 years ago
Replying to jakemgold:
Trying to follow the various image post format UI threads and branches, and picking this one. I think there are still some serious usability issues here.
First, it seems to me we should follow the example of the "Featured Image" field. Once an image is provided, hide the uploader / HTML field, subbing it with a "Remove image" link that take discards the preview and replaces it with the fields.
great idea!
Second, it seems to me if we're going to instantly show previews for uploaded media (sans saving), we should do the same for image URL / HTML. I realize this might be a bit heavy, but with some balance tags magic / sanitizing (which is already being being addressed for this field), we can can show the output from the free form HTML field when the field loses focus.
Finally, I know it's been raised elsewhere, but I'm not sure I even get the logic behind a free form HTML field (although I *do* get allowing a URL for an image), and I tend to lean toward strongly believing this is a bad idea, while being open to someone explaining the use case.
As theme developers, the free form HTML - which tolerates embedded links that override the click through field - makes it much harder than it should be to reliably pull the raw data out of this post format for fancier / alternate presentation of the content (in addition to making basic output, as it is now, somewhat heavy when HTML is provided). More importantly, it just seems bizarre to me that - in an image post format - I can just write something like "<strong>hello world!</strong>"... which is accepted and works. Heck, why don't we just call it a "free for all" post format?
Might there be uses cases for raw HTML in an image post format (struggling as I am to think of them)? I guess. But that's why we have hooks and plug-ins.
Again - tried to read through all the threads on this subject, so forgive me if I'm covering old ground.
i agree- seems like the field should allow only an image url, and if an image is dropped only the image URL should be inserted (i tried that in #24289); captions could be a separate field. this would simplify the image format for users and developers.
Also should limit the size of the image displayed on the post screen. If it's tall, it can push everything else way way down.