Closed Graham-72 closed 6 years ago
I have my initial PR (number 2198) now working in the sandbox but only by adding contrib module 'autologout' to the sandbox! I have yet to discover why this makes a difference but discovered the need for it, or something, because I found my PR worked on one of my test sites where this is installed.
Without this, there is some interaction of scripts that halts the process.
So there are now two things to do:
Thanks to the comment by @docwilmot that the view will work if it does not use ajax, the sandbox is now working to my satisfaction.
The PR sandbox works for me but I found the help text in the dialog (Remember to set the image style at the foot of this dialogue before selecting Insert.
) confusing:
@olafgrabienski Thank you for your comment. The problem I foresee, particularly for non-technical users, is that when the library is showing several images, the fields for setting image width and alignment are not always visible unless one goes to the foot ot the dialogue, and one may miss these important settings.
I think it would be possible to place these above the images which might perhaps be better.
I don't like to use the colloquial word 'click' so what should one say (rather than 'select') about using the 'Insert' button?
@Graham-72 I thought that a better option, instead of embedding the gallery in the image dialog, we could put a button that opens a new dialog with the gallery in it. I actually tried to do this, but had an issue with the galley submit button giving a POST error. Was hoping @quicksketch could help, posted in gitter, waiting a response.
@docwilmot yes that might well be better, particularly if the gallery could give some better user feedback that a particular image has been selected.
Whilst on the subject of possible improvements, I think it would be nice to include an autocomplete for anyone keying in a filename, though image files can have very unhelpful filenames.
In the light of comments received (thank you) I have made some revisions to my PR for a version which embeds the image display in the image dialog.
I am particularly keen to get some UI like this that enables a user to see and re-use images that have already been uploaded to a site, so I will continue work on this.
@Graham-72 I've had a look at the sandbox site of https://github.com/backdrop/backdrop/pull/2198 where I couldn't find any option to select an existing image in the CKEditor image dialog.
@olafgrabienski I think there are some possibilities of the image library not appearing and maybe the script needs some refinement, but when in the 'Image File URL' dialog you should see the existing images displayed below the subheading 'Select from image library' as in this screenshot:
@Graham-72 I've looked for existing images in the sandbox site but they're not there, see screenshot:
@olafgrabienski could it possibly be that your PC has not yet refreshed its copy of the filter.js script?
Thanks for the hint @Graham-72 , that was apparently the case. I've tried it in another browser and could see the existing images.
Just one first note for the moment: While I could choose from and insert one of the existing images, I was not able to use the image library pager. When I chose the next page, the link opened in a separate normal page, not within the image dialog.
@olafgrabienski thanks for the feedback. I think the paging problem will only be solved if we can get ajax working for the view.
@olafgrabienski I have made a further change to the PR, following an excellent suggestion by @docwilmot. Please have a look at the sandbox when convenient.
[cross-posted on the PR accidentally]
@Graham-72 Looking good! A few suggestions for consideration:
.library-view
is not hard-coded at 600px and we change from a grid display format, it would allow wider screens to display more images without requiring a scroll.filename contains
would be nice.@Graham-72 Great Work! Just a question: how about an additional (text)field where you can set the margin around the image?
How do you feel about using a square "scale and crop" style so all image previews are the same aspect ratio and we can get a nicely aligned rows and columns?
Unless we can show previews in the dialog, we probably shouldn't do this. A content editor might need to know the image aspect ratio when choosing an image.
If the width of .library-view is not hard-coded at 600px and we change from a grid display format, it would allow wider screens to display more images without requiring a scroll.
I dont get what this means.
@docwilmot Screenshots attached.
Current PR (width hard-coded to 600px):
Slight change (setting width to auto):
Greater change (changing view to unformatted list instead of grid and using css to display with flex, etc.):
@laryn I like the change to use a view that is an 'unformatted list' rather than a grid. But I am not keen on using a 'scale and crop' style because I like to have a true preview of the image aspect ratio.
Chacun ร son goรปt. Let me know if you want me to turn the rough into a more formal submit to your PR or if you plan to just work from what you have.
Thank you for feedback and suggestions, some of which are now included. Others require more work, e.g. to solve the Ajax problem.
I am wondering whether there should be an admin configuration setting so that the display of the library view is optional and an alternative might be an exposed filter for filename contains
as suggested by @laryn.
@Graham-72 Unfortunately I've got little time these days but here are some ideas on the fly:
Image file URL
to something that makes more clear that there is an image library?@jenlampton please have a look at the latest version of this PR and let me know what you think from a usability view?
This PR goes some way towards adding the functionality for images that Wordpress users enjoy 'out of the box' with their 'Add Media' feature.
@Graham-72 I love this. It's a huge improvement over what we have now, and a killer new feature :) I was able to use it intuitively (without reading this issue first) and figure it out.
My only thought was that maybe the form fields should be on the right and images on the left, since what I'm most excited about (as a user) was browsing the images, so I wanted to see those first.
Also, the sort order of the view should probably have the newest images at the top, rather than at the bottom.
So after the meeting today it seems this has technical approval then @Graham-72, so full speed ahead. ๐ Would appreciate really one of those exhaustive @klonos reviews next.
I would like to add to @jenlampton's comment... this is absolutely brilliant and would a kick-@ss feature to have for 1.11!! ...although I would love it even more if this was a "Media library" and not just an "Image library" ...but baby steps ๐
Comments for improvements:
add spacing between the "Image library" label and the list of images
add spacing between the align options
the help text below the "Add a caption" checkbox looks like it needs spacing too
why aren't we exposing a caption field in the image upload/select dialog when the user ticks the respective checkbox again?
make the library wrap under the settings on mobile/narrow screens
(perhaps a separate issue for this) add some shadow on the .ui-dialog-buttonpane
bit so that there is some visual clue that there's more things if the user scrolls further down. Similar to what @laryn has done for the form submit buttons in https://github.com/backdrop/backdrop-issues/issues/566#issuecomment-384853607 :
add indication of which image is selected. Perhaps a tick overlaid in the top-left/right corner of the image, and/or some border around it, and/or bolder filename text. We could aim for as much consistency as possible with what we have in /admin/structure/layouts/settings
, since it seems like a very similar UI pattern:
the number of items per row should be consistent. we should be truncating long filenames (perhaps expanding on hover, but in a way that still retains layout of the rest of the files). I really like how the respective media module library lays the images out consistently:
...if we cannot get consensus on cropping, then perhaps consider shrink-to-fit?
search/sort functionality should be available for the library items.
The "Select from library" tab should be automatically selected if the user has double-clicked an existing image (currently defaults to the "Image upload" tab)
I would like to see the button label be "Replace" if a different image is selected.
...thank you so much for working on this @Graham-72 ...and you too @docwilmot for the persistent feedback/help! Great team work ๐
@klonos thanks for your suggestions. Regarding your two 'add spacing' suggestions I would find it helpful if you could explain your problem a bit more. What screen size were you using? Was this when using the admin theme (Seven) or the site theme (Basis), or perhaps both? Is this a matter of personal preference or is there a usability issue? Thanks for any clarification you can provide. @klonos I have looked again and can see what you mean. I have it in hand.
And regarding your Media module library screenshot, which module is this?
@Graham-72 this was a stock screenshot from https://www.drupal.org/project/media
@klonos
this was a stock screenshot from https://www.drupal.org/project/media
Thank you for this information. It means I can try the D7 version and see for myself the dynamics of this UI. At first I thought it might be something just from D8 which I do not use.
I very much like your suggestion of using a similar approach to that used in template selection based on radio buttons, and I will be trying this.
@Graham-72 noted the View uses full sized images. We should use image style thumbnails. Is work still going on on this? Any help needed?
@docwilmot
We should use image style thumbnails.
I would very much like to find a way of doing this and I think we made need to revise the way the image library view is generated, because at the moment it is not treating them as images, just as files, albeit filtered by mime type, hence the thumbnails are not being created.
I have a number of other changes in the pipeline and hope to post a package of modifications to my PR soon. I will think some more about using thumbnails but would appreciate any suggestions you may have as to how to achieve this.
Progress report:
Thank you for the comments and suggestions received, and also those made at the weekly meeting on 28th June 2018. I have been working on some changes and have just updated the PR to include some amendments. Please kindly have another look at the sandbox site.
There are some features not yet included and maybe never will be until we have a more comprehensive media facility. For example: search for a file name; control of image margins.
Three things that seem to me to be important for a good immediate solution are
Changes that I have included in this latest update are
Looking good. I wonder if though we should give up on Views, at least till #3183 can be done, and just build a themed display of images. This would solve the AJAX loading issue, the filename issue, the styles issue, the adding of search and filters, even adding display settings. What you think?
give up on Views, at least till #3183 can be done
I think this might be a bit drastic! I think our main need is to be able to create the library view from thumbnail images rather than the full image file every time. Could we not create a folder of thumbnail images, perhaps on first use, and modify the existing view to use the thumbnail copy of the image?
For a large site with,say, hundreds of images, the use of AJAX and paging would become important, but perhaps better provided with a more advanced media option.
How difficult will #3183 be?
@docwilmot I agree, but it depends on what @Graham-72 said:
How difficult will #3183 be?
How difficult will #3183 be?
I responded there. It might be complex, or not, but the issue is do we want this issue held up by that one. We're almost there with this, and I'm sure we could do a themed display with FormAPI and AJAX quick time.
Could we not create a folder of thumbnail images
You mean we'd have to batch convert every image on every site to thumbnail as part of the upgrade path then create a thumbnail for every image thereafter. That would be inefficient to say the least.
Lets see what anyone else has to say about this.
The main reason for using a view is so that admins can customise it. It seems to me that if we implemented this as a view, we would:
a) be reusing parts of core. This means added features over time get automatically inherited b) be porting any required missing features from D7 contrib modules (namely file_entity) and merging them into core. These features will be used here specifically, but will also be solving other pains elsewhere...
https://github.com/backdrop/backdrop-issues/issues/2920#issuecomment-401383857 :
...there is a solution suggested there, but it requires the https://drupal.org/project/file_entity module. According to https://backdrop-ops.github.io/slides/intro-mini.html#/19 this module has already been merged in core, but I do not see any "Rendered file" option for the file formatter in views:
convert every image on every site to thumbnail
This has raised two thoughts in my mind.
Is this not going to happen one way or another if we want the library view to be based on downloading thumbnails rather than full image files? The objective is that this generation of thumbnails should only happen once.
At the moment the PR only provides for images that are in the 'inline-images' folder (or whatever has been set for this.) A typical site may contain many other images, added as specific node fields and having their own specific directory, named in the relevant field.instance config I believe. Would it not be a useful extension of the PR to provide for selection of one of the site's other image directories to be viewed in the library view? Though presumably the result of selecting and inserting such an image might have to be to copy the image to the inline-images folder? (Or is this opening a can of worms?)
Actually imagecache (image styles) does the resizing automatically. It only generates the thumbnail when you try to view it. Say you visit path-to-thumbnail.jpg
and it doesnt yet exist, it is then created. So no we wouldnt need to batch convert if we used styles.
provide for selection of one of the site's other image directories
We would need a settings page for the library then. And have the View select from allowed folders. How? I dont know yet, but I suspect more custom handlers would be needed.
Note please that I am not against having a View. Was just wondering since our View limits us now, if we could temporarily do the easy thing. I've requested to discuss the File Views image rendering part of things on Thursday, so at least we can have some clarity on how much work will need to go into that issue.
A configuration setting so that the site designer can choose whether images are scaled to fit within the library cells (as at present) or cropped and fill the whole cell as some people prefer.
Such a setting would indeed be helpful. I suggest to set the cropped image / filled cell as default though, that seems to be the standard display in Drupal / Media (see screenshot in https://github.com/backdrop/backdrop-issues/issues/3134#issuecomment-399269259) and in the Media Library of WordPress (see https://codex.wordpress.org/images/0/08/managefiles.png).
Thanks for the WP screenshot @olafgrabienski ...I don't like how one seems to need to hover over the image in order to reveal the filename, but I really like how the image name is overlaid over the image. Perhaps we would make a combination of these: the filename is shown truncated with ellipsis if too long, but when hovered on, it expands, bleeding into the image (in order to maintain thumbnail tiles dimensions at all times).
At the moment the PR only provides for images that are in the 'inline-images' folder.
I am wrong! The view is including all images in the files directory. And those in folders other than inline-images
will presumably already have thumbnails available on the server? Could we make use of these in the library?
I suggest to set the cropped image / filled cell as default
To date I have been very unenthusiastic about the cropped image / filled cell view because I think it is much more useful for a user to have a clear presentation of what the image really looks like in order to conform to the spirit of WYSIWYG. I think this could only be achieved by adding more attachment detail to the menu as done in Wordpress's Add Media selection. Screenshot:
Even there, I am not enthusiastic because the 'true' preview is not shown until the image is preselected, so it means one or more extra steps in choosing an image. I have yet to see how D7's media module handles this.
The type of user I have in mind is one working in a small office, who is not an expert in web design or Backdrop, but may well be tasked with editing and creating pages on a website, and also with producing MailChimp newsletters. MC has an image library and displays stored images in their correct proportion, though in my view has other UI challenges.
MC has an image library and displays stored images in their correct proportion
Interesting, can you provide a screenshot of the Mailchimp display?
provide a screenshot of the Mailchimp display
Here is the top part of one I occasionally have to use
This screenshot is of the grid view. One can toggle to a list view that gives file name, size tec.
The MC system stores duplicates of images when different sizes are used in campaigns and the disadvantage of this is that where different size files exist one has to toggle to the list view to see the sizes of the options. For example, the second and third omages on the first line in this screenshot represent very different files, one being 34KB the other 3.6MB.
OK, after seeing the MC screenshot, I think that it would be OK if the image tiles were the same size. What MC does to achieve this is to add equal margins above/below the full, non-cropped thumbnail (or to the left/right of the thumbnail if it is in portrait).
I am aiming to provide a simple addition to core's filter module to offer the selection of an image from those already stored in the website. I am basing this on work done by @daggerhart in response to issue #1307, published as PR 1889.
I will provide a fresh PR as a proof of concept, for team review, particularly of usability.
Update: My PR 2198 is now working and does, I believe, provide a useful addition to the Insert Image process, particularly for non-technical users.
PR by @Graham-72: https://github.com/backdrop/backdrop/pull/2198