I had a long meeting with Beau, where we discussed both the specifics and the scope of the project. New things abound:

Apparently WPSoC projects are expected to be “functional” by midterm evaluations, which significantly impacts the deliverables schedule I initially laid out. This is both good and bad—it gives me more time to test and optimize during the summer, but puts pressure to at least have a functioning core by midterm evaluations. As a result, when Beau and I talked details, we tried to categorize items as “necessary” or “that would be nice but let’s leave that for later.”

My project (which needs a name!) will be a plugin rather than a core patch, since plugins rely on the hooks API, which is much more stable than the core. This is awesome in several ways: I have no qualms with less debugging, and I’m already somewhat familiar with WP plugin development. That said, if my plugin could someday serve as the basis for a big core patch, my mind would be blown.

Focus and Functionality:

I want this editor to be useful to both theme developers and the average WP user. Eventually, the average user should be able to make a theme without knowing the first thing about “those codes that run the internet”. But for those of us that do, the themes should be hacking-friendly. To cater to the theme developers, the plugin will have two major functions—to fully develop a theme, and to rapid-prototype a theme.

Rapid-prototyping will serve as a basis for full theme development, and will be my focus this summer. Rapid-prototyping takes advantage of the structure/style divide I first proposed in my GSoC application. Since the user first informs the editor of the structure of the layout, the editor can return a basic theme suited specifically to the user’s needs. The output would be similar to a static theme framework, but include CSS that specifies layout. With a traditional theme framework, the user would have to rearrange the elements to fit their layout. The rapid-prototyping section will serve as a replacement for this process.

Using other theme frameworks:

Keeping the time crunch in mind, if an existing theme framework matches or can be easily adapted to the ideas for my own theme framework (and is properly licensed, of course), I’ll try to base my work off of that. We discussed the Carrington framework as a viable foundation, but I’m not sure if it fits the model I’m trying to establish. Regardless, it’ll be a good reference, and I’ll likely use code fragments from Carrington or another theme framework (I’m looking at you, Sandbox) over the course of the summer.

Making friends with the widget admin:

Initially, I thought that the editor could double as a widget admin. After some discussion, I’ll be leaving widget admin to the WP core (there’s a pretty slick new widget admin in the pipes, and the code surrounding it was described as “painfully complex”). What the plugin will do is widgetize (and maybe semantically name) all sidebars so that widgets and content can be placed anywhere in the framework. In addition, if I have the time, the plugin will add a button on the widget admin page to allow the user to view the layout in a modal window.