I need a vary basic functionality to display story titles from an external feed as a list.
Each user have their own "profile page" which is a custom content type created with CCK. The content type has a Blog Feed URL field. I would like to parse 10 newest items from the feed and display them on the profile page without saving them into nodes. The perfect way actually would be - having aggregation of the items into nodes optional. This way users could choose if they want their content to be aggregated here, or just shown as links on their profile pages to their own content on their sites.

Views 2 is currently being updated for Drupal 6 compatibility, but it needs major help in order to be ready for the Drupal 6's approximate release date! We're short on people and short on time, so here's the bottom line. Without your assistance and contributions, there will be no Views for Drupal 6 within any useful timeframe. If we don't have Views 2 ready for the D6 release date, the vast majority of casual users might not even bother to download and try Drupal 6. That would be bad, so you need to get involved in helping to complete Views 2 so this scenario doesn't happen!

So many people have said they are going to improve forums and then we never hear from them again. I finally had enough of waiting for someone else to do it and I'm taking up the job myself. I started working on it yesterday, basing my code on flatforum. This module is intended to replace flatforum, which I think has reached the end of life.

Copied from http://factoryjoe.pbwiki.com/FeedbackForDrupal6 so people can comment and act on it.

Please help turn the @TODOs into into tickets and patches!

Installation

• It's awesome that Drupal defaults to install.php if you haven't previously setup the site. That's a much better experience than having to know that you have to hit install.php first. Then again, it also means that you could be intercepted; unlikely but still something to consider.

Web Application Form Design
http://www.lukew.com/resources/articles/web_forms.html

Web Form Design in the Wild, Part I
http://www.uie.com/articles/forms-fairmont-hotel/

Web Form Design in the Wild, Part 2
http://www.uie.com/articles/form_design_wild/

I facilitated a session at the Bay Area Drupal Camp (BADCamp). About 40-50 people had a good discussion around the usability in Drupal.

I recommend the discussion format for similar sessions because the biggest need is getting people involved. There are success stories around specific UI redesigns, such as projects on Drupal.org and the administration front page introduced in Drupal 5. However, the overall usability process and vision is still taking shape.

As mentioned on the other paper A Data API for Drupal. Here is a paper that shows how this could be accomplished with some OOP bits implementing the Active Records Pattern. While keeping the interface procedural.

We all know that Dupal will not go full OOP. But some OOP code could help us do things not possible with procedural code. Such as lazy loading of nested objects and 'on demand' database fields processing.

There's growing interest in the Drupal community in the prospect of renewing our core data handling APIs. Doing so will increase consistency and efficiency and ease barriers. It will also be a key step in enabling transactional web services.

In Drupal 6 we took some impressive first steps. What should we tackle for Drupal 7?

The attached paper, written by Nedjo Rogers and Henrique Recidive and sponsored by CivicSpace, aims to carry this discussion forward and map out both some conceptual space and concrete development tasks.

I have completed the translation to Spanish of the Private message v5.x-1.8 module and related files and modules (privatemsg.info, mail_edit.module, mail_edit.info).

The current es.po translation file included with the module is quite old and inaccurate, which generates plenty of confusion when used.

I've been thinking about some modules recently and about how to get the data they need. Looking at a general trend of "monolithic module" -> "individual CCK fields + helper modules + glue code" I'm curious how those "helper modules" can get the metadata they need to know how to interact with the CCK fields.

More specifically, we have the image module and then lots of helper modules image publisher which know how to interact the the image module because it's node type and data structures are set in stone.