Hello and welcome to the Plone ideas list! 

The first list, labelled "Ideas" is our main list.  Below it is a second list with ideas we're still tweaking.  Feel free to talk to us about any of these, but bear in mind we have a better idea of what would be expected for the ideas we've finished.

Ideas

• AJAXIFY PloneFormGen form editing. There are some great AJAXy form builders out there that provide drag-and-drop field placement, quick editing, and reordering without leaving the form. It would be a dream to add that sort of front-end editing to PloneFormGen's validation and action capabilities.
  Background: PloneFormGen is a popular Plone add-on product that allows a web form to appear as a folder containing field and action content items. This leverages the user's experience in managing content to manage forms, but the interface is cumbersome to experienced form builders. Plone 3+ has a great framework (KSS) for connecting CSS and JavaScript that would make this project good, clean fun. [Steve McMahon]

• The "Big Green Button".  Plone needs a fairly hefty server, terminal access and long-running processes to be used.  Martin Aspeli has suggested a "Big Green Button" which exports all the content of a plone site as a VERY basic PHP application.  There would be a basic theme, broadly like a Plone 3 site with an empty skin product installed, and no write access at all.  This would be a one-way operation, the site admin keeps plone running on a local computer and re-exports every time he has made a change.  Storing content in a MySQL database might be a good idea as a search function would be useful.  Anything that is available to anonymous users in a stock Plone instance could be considered to be in scope for this but at it's core it's a button in the back-end that exports a cheap-and-dirty-hosting friendly version of your plone site.  [MatthewWilkes]

  I would like to propose a different task. Instead of reinventing the well, we should build upon entransit. The goal for entransit is *not* spit out PHP, but structured metadata. Right at this moment we are looking at using JSON to represent the metadata on the filesystem. Then, on top of that a good task would be to consume this JSON into a database and (additionally) have a PHP (or Java, or ASP.NET) app that consumes the data either from raw JSON or from a database. I would volunteer for mentoring this task. [Sidnei da Silva]  

  As long as the data's in JSON, why not just a simple backend and a javascript engine to format? Using something like gNius? OK, for performance reasons, this *may* be a horrible idea. But ti sounds like a lot of fun! [derek_richardson] 

  Would http://triplify.org/Overview help with this or could be integrated? 

• Buildout builder: Buildout is the new standard for deployment of Plone. However, it is configured via arcane text files that are not approachable for less technical administrators and system integrators. The buildout builder will be a web-based graphical user interface that allows one to specify the configuration of a Plone deployment and then receive a buildout configuration file that can be used to deploy that configuration with a few simple commands. This will make deploying complex Plone configurations much more approachable a process for the textually-deterred. The buildout builder is a 2008 Plone Strategic Planning Summit initiative. The buildout builder can be envisioned in different ways that are increasingly complex and thus allows a student to have varying levels of potential achievement, making it appropriate for both newer and more experienced developers. More thoughts on the buildout builder.  [derek_richardson]

• WSGI auth. Repoze makes hooking Plone up with other apps possible, but there are plenty of rough edges left. For one, there are currently not PAS plugins that implement the correct semantics to use a WSGI auth middleware to handle authentication (e.g, AuthKit, Barrel) or to use a WSGI session manager (e.g., flup, Beaker). It would make it easier to set up Plone in a mixed app environment if such plugins did exist, because this would ease single sign-on. [MattBowen]

  This could be done at Zope or Repoze level, to be reused by all Zope-based platforms. I understand Grok and Vudo too have user management on their roadmap and would be interested. We would have the same semantics and protocols from one system to another, and maintain the same codebase. [Kamon Ayeva]

    This may have already been achieved at pycon 2008 : see this blog post from mcdonc. On the other hand, it may not be done yet, just made a
    whole lot easier. [derek_richardson]

• Portlet management improvements: There are a few things we want to change with the way portlets work. I know how to do each one of these, but lack time. This includes:
  • The ability to mark an individual portlet assignment as "shown in subfolder" or not. This is a more usable and flexible way of doing the portlet blacklisting we have now.
  • Have a global portlet category "shown on all pages". This is different (conceptually and in terms of flexibility) to having a portlet at the root of the site (which to most people means "on the front page"), and would be managed via a dedicated control panel page.
  • Add some JavaScript to make it possible to "roll up" portlets.
  • Add functionality to the dashboard to create content in specific locations (e.g. user Joe always adds news items to the /press folder, and can do so via his dashboard), and a standard portlet to show  "my content" with useful metadata. [optilude]
• Document attachments engine: Limi has a wonderful design for a way to handle the "attach an image / file / Flash move / whatever" to a page. This involves a special kind of portlet that is associated with a given page and managed from within Kupu. A Kupu drawer lets you upload an image which then gets created as an instance of the attachment portlet. The portlet has two rendering modes - "real" where it renders its content and whatever widgetry around it, and "edit mode" where it is rendered as a placeholder image. The image can be moved around in Kupu to get the desired layout. Upon rendering the page, a transform is invoked so that the portlet can render its content in the right place. This is actually quite easy to do (at least if I explain it a bit better), and would mean that any page using Kupu would be able to support this kind of functionality - death to RichDocument! :-) [optilude]
  
• Better search for East Asian languages. Plone's out-of-the-box search gives very poor results for CJK (Chinese, Japanese and Korean) languages. This severely undermines the claim on the top page of plone.org that "Plone handles Chinese (and) Japanese." CJK languages have no spaces between words, so a special algorithm called a splitter is required to break text up into words.  In order to get acceptable search results Plone site managers have to install plug-ins such as CJKSplitter; this is not straightforward for new users. Furthermore, the best splitter, CJKSplitter, does not cover all Japanese characters, and is no longer maintained. The aim would be to deliver (1) a better word-splitter, (2) an add-on product that users could simply install to enable CJK search on their site, and (3) suggestions about how Plone's standard search could be improved to handle more languages.[Terada & Hotta]
• Rich GUI batch mode: Create a view (or series of views) where content operations such as copying, moving, deleting, publishing and editing standard metadata can be done in batch, using a rich GUI. I suggest we use ExtJS's excellent Grid and Tree controls for this, to enable moving with drag-and-drop, batch editing in a grid and so on. Limi can produce some mockups for the UI, and this can be done as a standalone product that we can later include with the core if it turns out to be useful.  [optilude]
  
• Cachefu modernization. Cachefu has a lot of old cruft. If we assume plone 3.1+ support only, lots of backward compatible lines of code can be removed. Monkeypatching can partially be replaced with traversal adapters. Lovely has code for specialised caching for zope3 templates. Etc. [reinout] 
• Kupu improvements: Various suggestions: make kupu use Zope3 interfaces instead of having hardwired configuration for specific content types. Improve drawers to allow server side code to drive a drawer through Ajax. Move kupu javascript code into an iframe to avoid conflicts with 3rd party javascript libraries. [Duncan]
• Improve ResourceRegistries: Improve RR and integrate it with the Zope 3 way of doing things, like z3c.resourcelibrary. I have several things in mind which can be built upon depending on how fast each part is done, so the scope is very flexible. My dream would be that RR is only a UI layer on a new and way more flexible underpinning similar to RedirectionTool, which is only a small layer upon plone.redirector. [fschulze]
• UberSelectionWidget [optilude]: Plone needs a rich selection widget that can handle very large vocabularies. Work is already in progress here, but there is much that remains. This will require some Python skills, but is mainly about jQuery and KSS.
  
  • Auto-completion functionality (useful e.g. as an improved keyword widget)
  • Completion of the "column" browse mode
  • Better support for multi-selection
  • General UI and usability improvements
    
  • An Archetypes widget wrapper so that the same widget can be used in Archetypes forms
• Improved text transforms Plone has a text transform engine that can be used for all sorts of purposes, including filtering HTML tags. There are many different types of text that could be entered into CMS systems, especially technically specialist systems. This includes:
  • Syntax Highlighting. It would be great to have a product that could provide syntax highlighting to blocks of code within a site. This would be tasty for all the code examples on plone.org and a great general feature. I'm not sure what an appropriate implementation would be, but I've noticed that the Trac project has gone with http://pygments.org as their default syntax highlighter, and it definitely seems full featured. Would be extra nice to have this available to Kupu. [Liam Staskawicz]
    • Do you mean something like  http://docs.neuroinf.de/API/Zpydoc/PloneSilverCity.PloneSilverCity/zpydocumentable_src ? I did this using http://silvercity.sourceforge.net/  via PloneSilverCity from Andy McKay which would need to be ported to Plone 3 if we want that. [Raphael Ritz]
      
    • I guess I wasn't too clear, but I was thinking something that is not a separate product, but a built-in feature that can highlight <code style="python"></code> tags that are in standard Plone content (actual tag names obviously up for debate).  This would be very convenient for snippets in how-tos, tutorials, and blog posts etc., while a separate product like the one linked above seems more suitable when you want to do reference doc or other content that will be ONLY syntax highlighted.  [Liam]
      
  • TeX text support: ZWiki (Gawdsaveus) has a great feature that allows TeX expressions to be rendered as images and then show in the text when displayed to users.  This is a real win for universities and other people wanting to display complex mathematics in their content.  It would be great if this was possible in normal Plone pages.  [MatthewWilkes]
    • Alternatively, we could consider recommending http://www.math.union.edu/~dpvc/jsmath/welcome.html  or something similar which IMHO is better than the image based approaches. [Raphael Ritz]

• Atom Publishing Protocol (APP) : Atom Publishing Protocol is a IETF standard for creating, editing, and deleting web resources over HTTP. Although primarily motivated by the desire to remotely edit blogs, there are a myriad of developing applications. A good intro is this article from the IBM DeveloperWorks. The official standard is here. The Plone SoC project would be enabling the APP for a set of content for which it makes sense (there's some area for scope negotiation here). Users would then be able to use APP clients for manipulating these resource. Twelve existing clients took part in an interoperability test in April 2007 (results), indicating some level of client support available now. Interesting questions: How does this affect Quills, a leading Plone blogging product? Quills supports remote blogging using the MetaWeblog API, a protocol that predates APP. I bet APP support would be welcomed by the Quills team. How does this affect WebDAV? APP lacks some of the frills of WebDAV. On the other hand, it's easier to implement. It's been a tough time getting interoperable WebDAV into Plone core. Maybe APP, with its simplicity, is a good alternative? APP is also, along with Atom, the basis of GData. Thus, it makes sense to implement APP support first and then build on it for GData (another source of scope negotiation for the SoC). You might look at amplee or FlatAtomPub for inspiration. [derek_richardson]
• Porting apidoc to Zope2/Plone, (and possibly merging with DocFinderTab) [Lennart Regebro]
  http://regebro.wordpress.com/2008/02/17/what-would-you-want-from-a-component-introspector-debugging-tool/
  Part of PSPS #7850
  
• An object introspector as a debugger help [Lennart Regebro]
  http://regebro.wordpress.com/2008/02/17/what-would-you-want-from-a-component-introspector-debugging-tool/
  Part of PSPS #7850
  

Ideas we're working on

• Basic Social Networking Functionality. Adding basic social networking functionality to Plone should be not too hard using existing components. "Basic" can mean simply having users with richer profiles and relationships between them (eventually workflowed). This could be implemented using membrane and plone.app.relations. Additionally some invite mechanism or other ways of finding contacts (e.g.Facebook, Twitter, ...) could be added. Details on how to implement it best should of course first be discussed with some Plone Gods ;-) [ChristianScholz] 

  • Add Plaxo to that list of 'ways of finding contacts'. That would open the doors to even more sources of data, like Windows Live Contacts, Gmail and Yahoo!.

    • We could also port some of the work done by the DiSo project using WordPress to Plone (in resuable way). See http://code.google.com/p/diso and http://code.google.com/p/diso/source/browse/wordpress for the code. [Kamon Ayeva]
      

• Microformats as Input and Output. Microformats are useful for output as explained here, and also for input. For example: you go to a newfangled microformat-enabled Plone site, or some other site that has events encoded in hCalendar. There, you select part of the page containing the event, and paste into a special input box in Plone. Plone then parses that hCalendar and creates an Event object. Or, instead of copying the hCalendar snippet from a page you use a hCalendar generator like http://interactive.usc.edu/_mt/hcal/ [Sidnei da Silva]

• UI-Improvement setting criteria in collections:

  Setting the relative date criterion in collections is not intuitive. This and maybe some other templates could be improved. [Jan Ulrich Hasecke]

  • Think there had been some talk of overhauling search and collections. Largely unifying/improving the UI, providing saved searches, integrating ifPeople search extensions/products. [foedecide]

• plone.classification : or similiar. Rework Plone's existing keyword mechanism with a modern tagging/classification/folksomony system [foedecide]
• Faceted Search UI: building on the rich metadata, classification, and keyword/tags already available in Plone (and search/classification/folksonomy projects), develop a dynamic faceted-search/browsing interface along the lines of Elastic Lists (i.e., an AJAX version of Flamenco).   [fpaulj] 

• Google GData : Implement Googles GData protocol into the core of Plone. This I think would touch upon several other projects such as Vice, RESTful projects and the import/export story. Also/alternative Atom Publishing Protocol. [foedecide]
  
• Theme demo site and product : Create a product for showcasing plone themes and create themes.plone.org.  Along the lines of http://themes.wordpress.net/  or the many Joomla! theme viewer sites. [foedecide]
  
• XML editor widget. Integrate the Bitflux XML editor as a widget. This would enable Plone to store and manipulate XML documents (like DocBook articles or books) similar to other content types [H. Turgut Uyar]