Simple Images

Events happening in the community are now at Drupal community events on www.drupal.org.
keizo's picture

Hi folks, here is a draft of my proposal minus my bio part. Would appreciate any feedback.

SUMMARY

The goal for the Simple Images project is to provide a module or collection of modules that allows anyone or their grandma to insert images into a Drupal node. There already numerous image solutions available, but none that match the simplicity of commercial services such as Blogger or the notes interface in Facebook. Simple Images will be that solution.

EXISTING IMAGE SOLUTIONS

There are three commonly used image solutions in Drupal: the Image module with Image assist, the Gallery module, and Acidfree. These are all useful modules, but often overbuilt or not practical for the simple case of laying out images in an article. Research has been done, and more will continue on these systems.

THE SIMPLE IMAGE SOLUTION

Currently the vision for Simple Images is to provide a Facebook like interface for images. It uses special tags to insert photos into content. For example, would insert an inline image. Positioning and captioning are done in a preview pane below the text box. A screen capture from Facebook can be seen at http://kzo.net/log/wp-content/uploads/2007/03/picture-7.png

Drupaler and former SOC student Kkaefer has already implemented a similar preview interface in his Upload previews module. This is an excellent step in the right direction. Simple Images would aim to continue on that path to a full-featured solution.

There is a whole number of ways to implement images and file handling. There currently seems to be a fiery debate on file handling: files and images as nodes versus a separate file system. It seems to largely be the reason there is no set image solution in Drupal Core.

Simple Images will make use of current core upload handling and make use of the Image toolkit. If the community welcomes the capability, the module could eventually be worked into Core.

Obviously there are many details yet to be worked out, but this would be finalized in the beginning stages of the project. The most important goals are listed below.

Goals:

  1. Remain simple and usable at all costs.
  2. Easy insertion of images into nodes.
  3. Provide semi-WYSIWYG (no fancy js editor) positioning and captioning.
  4. Provide a way to manage existing images.

A module meeting these goals will fill the gap left by existing modules and will address the needs of many in the Drupal community. It simplifies inserting images into nodes and would allow the average Internet user to format a nice article.

DELIVERABLES

  1. Fully functioning, tested, and usable module.
  2. Documentation on how to make use of the module.

METHOD FOR DEVELOPMENT

Development will involve a design, implementation, and revision phase.

Design will heavily involve research of existing solutions outside of the Drupal realm and discussing the implementation details of the project with the Drupal community.

Implementation will be an iterative process of coding and testing. Functionality will be added with defined goals, tested, debugged, and the process repeated. Milestone improvements will involve consulting with the mentors and Drupal community to ensure quality code.

Revision phase will primarily be the last push to get the module to a first official release. Getting from 90% functional to 100% functional is always the most difficult and will be a critical to a successful release. This will include debugging, cleaning up the code, improving the interface, usability and documentation.

TIMELINE

April 9 - May 28 Design and flesh out detailed specifications.
May 29 - July 5 Implement code for all specifications.
July 6 - August 5 Refactor code and documentation.
August 5 - August 19 Buffer period.
August 20 Project turned in to Google.
Beyond Maintenance, patches, and upgrades.

// Qualifications / Bio will be here

CONCLUSION

The Simple Images project will address a frequent complaint for an already hugely popular and powerful content management framework. I have the necessary experience, determination and motivation to build this module and would value the chance to spend my summer creating it. If you have any questions or concerns about my SOC application, or me, don't hesitate to email kzo@kzo.net. I appreciate your consideration for this great opportunity.

Comments

images

keizo's picture

earlier I was researching how to handle images. I've compiled some of the notes from various places. http://kzo.net/log/handling-images-documents-and-files-in-drupal

There is so much more then

dldege's picture

There is so much more then just images - what about videos, mp3, etc.?

I read you compilation of notes on the subject - very informative. I suggest you take a look at my proposal - http://drupal.org/node/120677. I'm totally wiling to back off from the "files as nodes" concept in favor of something else.

In fact the more I read and the more feedback I get I'm willing to concede that having files be something more then what they are now (attachments) but less then full blown nodes might be a fine solution. There will always be people in both camps but since Dries is on record as against files as nodes it makes sense to rethink it.

I'd suggest maybe working together to refine my proposal since it could address images (your proposal) and all files in a more generic way. Something like this is what I'm thinking now.

  1. A file manager that allows for files in Drupal that aren't nodes but aren't just node attachments either. Back end storage is abstracted (fileapi by dopry ?) so that physical storage of the files and serving of those files is extensible.
  2. A Drupal interface (GUI - jQuery, forms, flash, ???) for managing the above.
  3. A method for attaching files to a node from the above file store - not the current upload attach method (and/or the upload in a node edit form adds the file to the file manager behind the scenes).
  4. A specialized file node (my current proposal) that instead of having you upload the file there, lets you browse the file store, attach a single file (see #3) , and then uses the document API hooks I'm proposing to allow document extension modules to specialize the display of the file. Maybe 3 and 4 are all part of one file attachment module and a file node is still not necessary?
  5. Remove folder node from proposal and don't address file /folder hierarchy and allow that to be addressed by a separate project which is a generalized node tree module.

Dan DeGeest
Software Developer
Somewhere or Another

dldege, this is a hard

keizo's picture

dldege, this is a hard problem.

Not to mentions how many different use cases need to be considered. i.e. a video site, a document sharing site, an image gallery, simple blog, etc.

The user interface that currently exists for upload.module shouldn't be changed. Attaching files should be done in one step when creating a node like they are now. I think, like Dries wrote, there needs to be some abstraction that allows files to be stored and retrieved from any location. I would love to be able to easily use Amazon S3. A separate management interface would be cool too, but not necessary at first.

I wish had more help to offer. I'm not familiar with the core code yet and need to be doing school work right now, but I agree that our projects are or can be closely related. I will think about it more when I get the chance.

Another thing to consider

bonobo's picture

Given that you are targeting a simple, easy to use solution there is a good chance that the end users you are targeting will also be using/want a WYSIWYG editor -- so, for any solution to go prime time, it will need to play nice with WYSIWYG --

Cheers,

Bill

I agree - I certainly don't

dldege's picture

I agree - I certainly don't have it all worked out. If you don't want to tackle anything larger then this I certainly understand. I'm just going to keep the discussion going when possible.

Dan DeGeest
Software Developer
Somewhere or Another

keep it simple

drewish's picture

i think you're right to focus on images rather than a more general solution. the other media formats end up requiring some sort of a player and it hard to do it right in a way that would work for all of them.

thanks

keizo's picture

working with various file formats has been another tough problem for me as well. I don't really like flash paper, but I'm really liking the way http://scribd.com is working.

It could be made more

dldege's picture

It could be made more generalized without having to actually implement support for the other possible file (media) types. If the hooks/api are there then others could build on it. I wouldn't expect this project to implement all of them.

Dan DeGeest
Software Developer
Somewhere or Another

Another module

njivy's picture

See also the inline module.

[inline:filename.jpg] is

keizo's picture

[inline:filename.jpg] is great for admins and such, but it's still too complicated for general consumption.

Its the same workflow as

dldege's picture

Its the same workflow as your example, http://kzo.net/log/wp-content/uploads/2007/03/picture-7.png, if done right and done well.

I don't see a way other then an input filter to get to a point where images (all files :) ) can be exactly positioned in the node body content. The interface for making that happen is key.

I like your example png which I assume photo 1 and 2 are ones you are uploading. I think the same thing could happen in Drupal but also allow you to browse all previously uploaded files.

Dan DeGeest
Software Developer
Somewhere or Another

ah, after reevaluating

keizo's picture

ah, after reevaluating inline I see what you mean.

how about enhancing the existing image module?

drewish's picture

i'm very happy to see someone focusing on this issue. i've recently become a maintainer of the image module and have spent quite a bit of time trying to address some of the bigger bugs in it. personally, rather than adding yet another image module, i'd love to see you work on a set of patches for the inline and image modules. it'd be great to have your SoC project directed at making the existing image module more accessible and more useful to all users.

I tend to agree with most of

keizo's picture

I tend to agree with most of what you said. In fact today I was just reading how it's good to join forces with other projects rather than go create another one. However, the reason I am still proposing a new module is that I'm not so sure images as nodes are really a long term solution. At least from the research I've done and in my own experience using Drupal. My notes on the subject: http://kzo.net/log/handling-images-documents-and-files-in-drupal

Either way, I hope I get the chance to work on this. Definitely something I want to use.

SoC 2007

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: