ROADMAP:

PAST:

pre-1.0alpha1 todos:

X - cleanup eCard to bring it inline with the latest html in folder_listing/document_view
X - finish up the cleanup and viewification of all the needed skins
X - add code and tests to mirror tag on the image object
X - test and restrict catalog search to the current context, not site wide
X - add ecards to types that use view in listings list
X - credits bug
X - fix tests around straggler sub-arrays within the nested eCard table, so that we don't have incomplete tables in the templates

pre-1.0alpha2 todos:

X - eCards jump right to their display in browser, rather than being wrapped by base_view
X - massive template cleanups
    X - register a css stylesheet
    X - css stylesheet floating "close eCard" to the right
    X - adding "x" image for the close eCard button
    X - rip .cpt out of table structure
    X - display append message in popup
    X - More sensible thanks page
X - cleanup npo centric apis
X - additional reconciliation of eCards vs. eCards naming
X - default format for email text
X - reflect actual state of affairs in readme.txt


PRESENT:

pre-1.0beta todos:

X - place overrideable template in skins directory for the HTML rich email that's going to be sent
X - confusing comment in __init__
X - ask peers to help evaluate if the email approach technically is sane and doesn't open us up to spam vulnerabilities
X - Fix width of popup
X - in ecardssuccess.py, triple quote the html body for greater
      readability
X - don't need __init__() in browser.eCardCollectionView
X - any reason to include CookedBody in ecardcollection?
X - May want to document somewhere that they need to set their mailhost settings or they’ll get an error.
X - rip out emailing from cpy, test appropriately
X - register custom permission
X - use custom permission to protect sending of eCards
X - rename ecardsuccess
X - probably should throw in a # in Extensions/__init__.py
X - look at validation on cpy
X - don't we want to add thumbtag() to IECard interface?
X - remove the conditional on the stylesheet?
X - show description on mouseover in eCard Collection
X - Be explicit with the email subject field being sent as "first name" + " message" -- as a default value on the field
X - Change “Click on an image to send your eCard” to “Click on an image to 
X - Also, the label is not the best grammar. Change “The e-mail address to send this eCard to.” to “The recipient’s email address.”
X - The help for Image Thumbnail reads "You can then choose amongst these versions for thumbnail 
  size when editing the eCard Collection." Why is the thumbnail size not an option when you 
  create your collection to specify thumbnail size?
X - Moreover, if you go to the Edit form for the Collection, it reads, "The default eCard Collection 
  template outputs eCards as thumbnails with the dimension of 128px by 128px in rows." You never 
  get to choose a size, despite the statement above.
X - The phrase Image Caption here is a bit deceiving. I expected to 
  see the Title and Description fields (concatenated) for a photo, 
  not the text  from the Email Appended Message. Ideally, all of these 
  should show, but the Email Appended Message is definitely not a caption. :) 


FUTURE:

eCards 1.1+:

- thanks page editable by content editors, rather than integrators**
- add plone 3.0 capability**
- i18n catalog**
- captcha as a way to minimize spam**
- Bundle w/ a portlet that shows a random eCard**
- Give a more prominent close window button after send
  send an eCard.” (insert “an” and a period)
- Scrolling could be reduced if you have the sender’s information in a left hand column 
  and the recipient’s information in a right hand column.
- new eCard content type icons
- setImage, getWidth, getHeight, width/height computed items -- determine need on thumb schema field
- Can links within an eCard (internal or external) be forced to launch in a new window / tab

eCards 1.5+
- ability to override appended message
- allow for a "export" in csv format of sent eCards for internal tracking
- slimbox/lightbox popup
- allow users to determine what size of thumbnails and popup windows a slideshow will use
- getThumb in browser.py line 17.  Do we want to be testing its
  truth like that?  Maybe a cheaper alt method? (On hold awaiting inspiration)

** Higher priority items


To consider and/or prioritize:

- the Image field should have some help text stating this is the image that will display in 
  the eCard and that users should go no larger than 640x480 or whatever the maximum display size is.

- If you upload an image that is smaller than 64x64, what happens? Does PIL automatically 
  size it larger? Seems to do nothing. Should we recommend a minimum size?
  
- do something reasonable for users with Javascript disabled
