Hey people
ive just posted a wishlist for the image in core, that walkah were talking bout at the drupalcon barcelona.
i thought it would be a good idea to share this - so we can figure out what we want in this "imageincoreoneandforall" :)
link to the original post at my blog: http://morten.dk/node/174
flickr screens: http://flickr.com/photos/mortendk/tags/drupalimagesincorewishlist/
its still a working draft so spelling errors missing stuff etc ... ;)
Dear Walkah - the wishlist for images in core
original post http://morten.dk/node/174/
Dear Walkah - This christmas i wish for world peace, that my beers always is served cold, more metal in the airways and a kick ass image handler for Drupal.
A user perspective of image handling in Drupal.
One manager to rull them all.
The different approaches that each module have have today are very diffucult for the users to work with (and even som geeks) we got the
image is added to a node and cannot be reused on the site again but its posible to cached in different sizes (cck & image cache),
singe file (IMCE) works as a centralised storidge manager, but not possible to create ned sizes with cache
attached to the node (image attach), predefined sizes
the user image & avatars
Let us stop the madness. one image manager for image inside drupal, if you add a picture to you cck widget it goes into the manager, if you ad an image to a user profile it goes into the manager if its added through tinymce well it goes into the manager.
So when you have to find that picture again you know where the image is.
The manager can be called as popup window, a ajaxy thickbox thingie, or an expandable div inside the page, and add the images to drupal.
A user can access and work with all images that have been uploaded, and dont have to take into account if its an user picture, a cck image or an attached image, or any other kind of image, its just an image.
add, replace & remove images into drupal
Where would we like to work with the images...
- cck widget
• The user can replace an image thats already added to the manager (or replace it with a new)
• If theres more than one image we can change the order of the images.
• Title & alt is inheritet from the original file, the user can overwrite em at each cck adding
• If the user wants to add a new image it can upload directly as we do now im the image widget or open the manager an add it through here.
-
text area: wysiwyg & text
The user can add an image from the manager or replace it with another image.
The user can select the different imagecached presets that have been set in drupal or create a new variation of the image.
crop resize etc, image magick stuff - and then save it and add it to the manager. (yai photoshop built in javasctipt & xhtml ...mmm) -
profile image (avatars)
•When a user adds an image to his profile its store in the manager the image is stored in the manager (folder defined in the settings as usual?)
• If the user have permissions he could have acces to a predifened collection of avatars.
• permissions for how many images a user may add to the avatar folder?
• if the user removes the refrence to the file should it be deletede or only removed
4.terms
Why oooh why dont we have en easy way to add images to terms - again add image to term from the manager and voila
with the use of image cache. we could have a nice page with an image for each term
(like übercart: http://www.ubercart.org/files/screenshots/product_catalog.jpg)
- gallery
A gallery would be a taxonomy term
a gallery can have a special selected image as identifier for the gallery (add a image to a term se above)
a gallery can have a desciption
An image can be added to more than one gallery
each image posibility to hook up with drupal functionality: comments, send to a frient, add to favorites, vote, add term, whatever...
add weight to each image in the gallery to change the order of the images in the given gallery
the gallery can have each image sorted by date, title etc
All these functions must be accessible from the gallery control panel (lets make it easy for the people man)
[GALLERY control panel]
- block
Add an image to a block do it direcly through the image manager - or should that be done inside a html field instead?
Upload & import images
Browser upload:
- upload 1. image at a time through the manager.
- flickr like import of multible images
http://flickr.com/photos/upload/
http://swfupload.mammon.se/
FTP upload & structures in the image folder
when a user is working with a lot of images its gonna be a real pain to upload them one by one.
Lets say the user have 50 different galleries that is store as folders on the harddrive an she wants em all online fast n easy...
upload all the folders to files/images/
and then go to the import image folder option and upload each of the folders as image gallerys
if a folder haves images thats not importet they can be importet again
</photogeek example>
[Screen of import images]
Folders with images can be importet an each image & folder is registret into drupal and used as an gallery.
This gives the user a way to download all the images again at a sane level instead that all the images are in one folder (and the user can actually again export the image if he decides to not use drupal anymore)
To have all the images in one folder is a real pain, and unless theres a really good reason for that we should try to work in a way a user would store the data (and so the quickly can add images from iPhoto, lightroom, etc)
Metadata import
When a file is importet lets use the metadata and add those to the terms for the image
exif import (adds as terms)
iptc import
filestructure for the images
Local based images:
images/
images/foo
images/foo/bar
images/bar
images/bar/foo
images/mortendk/barcelona2007
images/mortendk/brussels2006
images/mortendk/sanfran2007
images/adminGroup/foo
images/adminGroup/foo/bar
external disk amazons S3
have no idea at this moment how it works etc
but again the users should then just add the images through the manager
Manager: edit / properties / delete / information bout each image
property editor:
add default title & alt tags to the image
add terms to the image (might be importet from iptc/exif data)
lets the user add new terms for the image
checks the permissions for the image
whos my daddy: before you wanna do crazy stuff with an image it would be nice to know where its used at (delete?)
which gallerys are the images a part of
Normally you would only remove an image from a page element
if you wants to remove it 1. you must have the permissions 2. go into the manager an remove
Lets have an easy way to remove 4321 files
[MANGER Props]
[MANGER delete]
[MANGER info]
access to imagefiles
We want to give special users the right to download original image (think - shop etc)
foo.jpg - paying customer
foo.jpg cached 1024 * special users
foo.jpg cached 300 * 300 all registred users
Filter in textareas?
Maybe it would be wise to have a filter so instead of using
in a textarea we can use [img cacheprofile="foo"] instead?
then add a ref to the original image so we know wheres the image is used .
If we delete the original image, the image will no longer be shown.
theming
control the imagecache elements directly from the theme / template.php
control siziing from cck through the display options
Its importent that the themer can controle the image cache driectly from the templates - a scenatio could be that it were usefull to have 1 image size for block-leftbar.tpl and another for block-right.tpl
links
http://flickr.com/photos/upload/
http://swfupload.mammon.se/
http://www.ubercart.org/files/screenshots/product_catalog.jpg
modules:
am
images
imce
tinymce
imagecahce
cck
imagefield
so Walkah - when will it be done ;)
/morten.dk
noget med ILD

Comments
This was preivously
This was preivously dependent on this: http://drupal.org/node/115267 which is now in Drupal 6. In that case I don't think it'd be impossible to do in contrib would it?
A bit overwhelming
Morten, I think about everything imaginable with images is covered in this...
Well, in the end most of it should be possible.
One would need to structure it now and weigh for priority: urgent, important, and nice to have.
Do you know if there is already a team that started working on the subject? For this is no small issue.
Life is a process
Life is a journey, not a destination
Pictures Module
I believe pictures module is the future of image handling in Drupal. Check it out and decide: http://drupal.org/project/pictures
Here we go
This is incredible.
Finally it gets done. I've also seen another group, Wysiwyg, who tackle another of the major flaws ...
So much looking forward!
Life is a process
Life is a journey, not a destination
:(
Doesn't to work on a fresh 5.1 install. I get a fatal error on the settings page, and I can't upload an image.
But it's a dev version at the moment. It still looks promising anyway ^_^
In 5.2 it works
Well, I got it to work. But still - I did not understand it at first, and lost patience...
@elv: I found a page that is espacially ridicolous in its waste of space in admin Menu:
The "create content type" page. There is absolutely no need for that form to be that long.
In our recent discussion, we concentrated on content entry forms - which is correct, because
this is the most important - the users see it.
But in "pure" backend forms, discussion might be much easier because there is no main body
text field. It would be easy and make sense to group things horizontally.
When we start out, we also have got to investigate, why and how things are rendered now.
Because there is some logic behind it, that should not be forgotten. Main Objective in my opinion
could be: the forms fields should come out rendered grouped. To me the main body and title field is one group.
The autocollapse options in the bottom of the page are another group, which might make sense to be subdivided (as wordpress does it).
Have a look into the html code (of content entry form, now again) that comes out: the entire
form is inside a div called node-form. Inside that, there are two second-level-divs: "standard" and "admin".
Inside these, every item is single. For theming, it would be enough, if the options that are still inside "standard" get an own div. And what must be not forgotten: depending ond modules installed (e.g. pathauto), more options fields are added. If we design, there must be space left for them.
In e.g. the create/options window for content types, things are worse: there are three sections bluntly called "fieldset". If they would at least come with a class, or an id - here we would go. But I'm sure, if we can make our points and the benefits clear to developers, this can easily (or at least with only reasonable effort) be implemented.
Apart from this, have you read this handbook-page by Angie Byron:
http://drupal.org/node/36602
I think it's very importand for us. I'm gonna translate it to german and publish it
on the german page. I think it can help greatly interact in a productive way with developers.
What do you think?
Life is a process
Life is a journey, not a destination
Confused...
How did we go from image handling to input forms?
Michelle
See my Drupal articles and tutorials or come check out life in the Coulee Region.
You're right
Right, I'm i the wrong Thread. I'll fix that.
Life is a process
Life is a journey, not a destination