Usability suggestions for image: Integrated image handling with inline image display in content

Thanks for your prompt response. The original requirements numbered are:

1. entry level users can upload images and included them as inline content (e.g. in blogs, articles, pages and possibly blocks)
2. no HTML coding should be required
3. uploaded images should be available for inclusion in Galleries
4. the functionality should be available either by just installing the image module, or preferably, as part of the core for Drupal 7- nearly every website using Drupal would have cause to show some images, and many would show a lot.
5. the image handling should be easily invoked via a standard interface/API so that rich text editors can access it.
6. technical settings and clutter should be avoided in simple dialogue boxes, but accessible via an "Advanced settings" button on the dialogue box
7. special tags should be avoided in content that is visible to users, or at the preview function should render the images included using them.
8. input filters should be enabled to display any special tags rather then this having to be located and set manually,
9. dialogue boxes and functionality needs to be browser independent.

Additional requirements:

10. Multiple images per article with flexible positioning - left, center, right
11. %sizing adjustment via single field (eg: 50% to halve image size)
12. Thumbnail option (like MediaWiki image tag)

1a) upload images: image_import or image_attach do that
> Yes, agreed

1b) include as inline content: image_filter does that
> Yes, but you need to find and edit the input format to enable this tag - something newbies would really struggle with - the tag should be enabled by default for filtered HTML

2) image_filter does that
> But you still need to know how to specify a tag, which newbies would have to learn. I haven't found mention of image_filter until you suggested it, after some extensive searching. You also reference an image by its node ID, rather than its "title", which is something newbies would also really struggle with.

3) images/contrib/image_galleries does that, when you upload the image to drupal.
If you didn't attach an image to a gallery when you uploaded it, you can edit your node, and select the gallery from the drop-down menu of image galleries.

> Yes. However, I think there should be default gallery for all images without a user selected gallery. Or a view you can filter to show "images without a gallery"

4) installing: you'll need image_filter as well, if you want to avoid html code. image/contrib/image_attach works nicely, too, out of the box, if you only want one image per node, and that at the same spot for every node you use it with.
> One image per node with no control on how it displays in the body text (thumbnail only) is not really very useful. Many typical article and blog postings would display a number of images throughout them, with text wrapping left, right or above/below.

5) how do you propose this should work? Cos the rich text editors I've seen, for drupal, SUCK.
>I suggest a dialogue box (similar to that presented by Image Assist) is required to browse and add images to inline content with the option of uploading. However, Image Assist uploads just put up the image, they don't create an image node, hence the images cannot be included in galleries, or listed via http://site/admin/content/node. Whether or not RTEs suck, they should able to invoke a standard Drupal image handling dialogue box (and functions accessible by it).

6) please roll a patch. I'll review it, if it's for a version of Image which I currently use.
>Sorry, I don't know how to do this. I work in IT but haven't coded for many years. I don't know how to code PHP.

7) what special tags in image are currently bothering you? And sorry, I don't understand the sentence "or at the preview function should render the images included using them.".
> Having looked ot [Image: ] it is useful, but beyond entry level users (and is difficult to find, install and enable). Ditto for [inline:xx] , with the added issue that page content below this tag (such as footer information) wraps up to the right of it rather than staying below it. RTEs such as TineMCE and FCKedit display these tages as text only, rather than rendering and image. So I think that clean integration of image handling with an RTE (or many) may be required to get the functionality required for entry level users and/or newbies.

8) dunno, should you roll a patch against image or drupal core's input filter? Or taxonomy?
> Don't know about the patch. Installing a feature and then having to hunt round and enable it in an input filter is really obscure. I would guess 9 out of 10 people installing the image_filter module would have a major problem finding this out and fixing it.

9) which dialogues and functionalities are currently not browser independent?
The image handling plugins (IMCE?) that work under both FCKedit and TinyMCE don't display correctly for me using Firefox, but they do with IE. The only dialogue box that displays correctly is the one invoked by BUEditor. However, BUEditor inserts an html IMG tag into the article (either need to allow this for Filtered HTML or use HTML format, and images it uploads are not treated as Drupal nodes/images, just files.

So a summary of the functionality I think is required - possibly in Drupal 7 core - is "simple image handling and display via a single module that can be easily enabled by selecting the module. Images should be accessed and catalogued via standard drupal features (filtered HTML, galleries, content display). Image handling functions (upload and/or insert into article and formatting within article; right, left, thumb, caption, size) should be available via a dialogue box popup that is available for both text entry and rich text editors (via API). This functionality would supersede and/or integrate that currently available from Image Assist, IMCE, image_filter, inline, possibly also Thickbox. The target user would be people who can blog and author text content but don't know HTML or coding.

See also http://drupal.org/node/207754 for a wider discussion on this issue.