New Elastic Blog: elastictheme.org

For anyone that’s interested in Elastic, the new blog is located at http://elastictheme.org. Find Elastic info there!

Filed under: Uncategorized

Weekly Update 1

I’ve been recently working on creating an editor that should allow for the user to alter the layout of a theme. I’m working with the Blueprint CSS Framework and jQuery and am currently attempting to create an intuitive UI (and in this process some sort of page-structure standard).

Things I’m working on/problems I’m rolling around in my head:

• Moving/Resizing columns within the editor: This is somewhat functional. I’ve created a few iterations on the concept, but the primary problem that I’ve run into is how to intuitively integrate width, padding, and margins in an environment where the user should not be required to know the HTML box-model. Mind you, I wasn’t planning on having each of the three independently integrated, but when using Blueprint, if you specify column spacing using padding (i.e. prepend/append) the column size will visually include that padding (if you use a background, for instance). In some instances, this may be desired. In others, users may prefer a transparent buffer between columns (i.e. margin). Finally, how do you know whether a user wants the buffer before the column or after the column (prepend/append)? I don’t want to give a user too many options, but if there is not a clear and clean implementation of margin, padding, and width, the flexibilty of the framework could suffer greatly.
• User-customizable grids: Allow the user to specify the column count, column width, and gutter widths and generate a grid accordingly. Currently, this is functional within the editor. However, I will ultimately need to compile the CSS for the theme output, and that implementation will need to be slightly different.
• Integrating all of this into theme structure: So now you’re wondering–what are you going to do with this editor? Currently I’m looking through the Sandbox code and documentation, and will (at the end of this first stage) hopefully have an output that resembles a customized Sandbox. More on that later.

Questions and comments are welcome!

Filed under: WordPress Summer of Code

Some Focus

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.

Filed under: WordPress Summer of Code

GSoC 2009: A WYSIWYG Theme Generator and Editor

My name is Daryl Koopersmith and I am proposing a WYSIWYG theme generator and editor for WordPress. By the end of the GSoC, the theme editor would be capable of altering theme structure and the location of content within themes as well as importing and exporting themes. In addition, the editor would be constructed in such a way that it would be easily extendable and would continue to grow long past the end of the summer.

By drawing a theoretical line between structural and stylistic CSS, the theme editor could drastically rearrange a theme’s structure while leaving its visual aesthetic intact. This will allow users to easily change themes to serve their own purposes, whether it be a blog, a CMS, or another application.

The overarching goals of the WYSIWYG theme generator/editor are the following:

• Provide an intuitive GUI through which anyone (regardless of skill level) could productively edit WordPress themes
• Allow users to create any layout they choose (and in doing so, provide alternatives to the sidebar-content-sidebar paradigm)
• Allow content and widgets to be assigned positions and managed visually
• Optimize theme memory footprint and provide automatic cross-browser compatibility

What follows is a justification for the creation of a WYSIWYG theme generator and editor and an outline of its potential implementation in the form of deliverables. I would be happy to discuss any questions and appreciate any feedback you have. Thank you for your time!

Best,
Daryl

Filed under: Summer of Code

Background and Justification for Use

I based my ideas off of the following thoughts and questions:

1. To what extent can a user modify a theme without programming?

• Currently, certain themes allow the user to select various parameters to customize the look of their website. What if users could visually edit the wireframe of their website and administer the positions of widgets and content?

2. How can users be encouraged to employ principles of graphic design in their themes?

• CSS frameworks (such as Blueprint [1] and YUI Grids [2]) allow designers to easily combine the principles of print design and web design through the use of grids. While grids are by no means necessary, they encourage a consistent website aesthetic and provide clarity when handling large amounts of content.

3. Can the memory print of a default theme be optimized after it has been customized?

• Customized themes often contain unused and overridden CSS and hidden DOM elements. Can these be automatically removed or avoided?

With these questions in mind, I have developed an outline for a WYSIWYG theme generator and editor. I’ve found that by placing a formal divide between structure and style in CSS a theme can easily be manipulated by the user. Since CSS and HTML are functionally linked, compiling structural CSS and HTML in tandem allows a theme to be built and optimized the fly. By treating stylistic CSS as a separate entity, the aesthetic look and feel of a website can be preserved across structural edits. This flexibility will allow the user unprecedented freedom and speed in theme design and customization.

Creating and embedding a grids-based system within the editor will provide a consistent foundation on which pages can be built. Making themes cross-browser compatible is tedious work and a headache for users of all experience levels. By embedding cross-browser functionality in the theme generator, all themes created by the editor will be inherently cross-browser compatible.

I’m seeking to make theme design within WordPress a natural process. I plan to refer to and learn from other attempts to build a theme editor, such as the now defunct Canvas, when I create my implementation. Ideally, the theme editor will become useful tool for users of all experience levels.

Filed under: Summer of Code

Implementation and Deliverables

Please Note: I will be in France between May 25 and June 11. I will have internet access, and I will be able to contribute, but not as much so as usual. In preparation for this trip, I will start work on my deliverables several weeks early. I finish my final exams on May 4th, so I will have more time than the usual student during the community bonding period and can work on my first set of deliverables (which coincidentally will not require much WordPress reference) during that time.

Deliverables will consist of major functional benchmarks:

1. A CSS library designed for positioning DOM elements (Weeks -3 – 1)

• Grids-based, but adjustable
• Calculate values within the library from three of four input values: number of columns, column width, gutter width, and website container width
• Cross-browser compatible

2. An editor that outlines block elements to create the appearance of a wireframe (Weeks 1 – 2)

3. Modify the wireframe by clicking on an element and adding a row/column adjacent to the element, or by clicking on and removing an element (Weeks 3 – 4)

• Automatically adjust affected surrounding elements’ CSS

4. Resize elements within the wireframe by dragging element borders (Weeks 3 – 4)

• Also, the ability to align elements left/right/center
• Automatically adjust affected surrounding elements’ CSS

5. Allow the user to add CSS styles (Week 5)

• Via uploaded file (which could be accessed in the editor)
• Override any user-input styles that would affect the structural CSS
• A potential future modification could allow users to directly edit structural CSS

6. Position content modules within the theme by dragging module titles into wireframe elements (Weeks 6 – 7)

• Titles would initially be found in a list of content modules (such as post content, widgets, menus, etc.)
• The main “content” module would refer to a separate PHP file that would act similarly to the common theme’s index.php and redirect to the proper files for each page type (front page, archives, etc.)

7. Allow the user to create multiple pages per theme (Week 7 )

• If the designer wants various pages to differ in style (e.g. front page and archives), the theme can refer to separate structures for specific pages.

8. Compile and save the theme (Weeks 8 – 9)

• Compile a structural CSS file that only includes the portions of the library used by the theme
• Compile a PHP file that includes the structural framework and the functions necessary to load the page content
• Set a variable that defines the template as “framework compatible”

9. Load and edit “framework compatible” themes (Weeks 9 – 10)

• Generate the wireframe from the compiled PHP file
• Generate the CSS library from the values within the compiled CSS file

10. Documentation and testing/debugging where necessary (Weeks 11 – 12)

Filed under: Summer of Code

Potential Future Expansions

I chose to create a WYSIWYG theme editor not only for its immediate use to WordPress, but its incredible potential. While creating a theme editor will likely prove to be quite the full plate, I have considered several additional functions that I hope will eventually come to fruition.

1. Include Preset Physical Elements, Layouts, and Themes

• Allow users to add complex elements (e.g. SuperFooter, Sidebar-Main-Sidebar) in a single click
• Allow users to apply preset layouts (e.g. Blog, CMS, etc.) to any theme, effectively preserving the style of the theme
• Provide users with default theme(s) on which they can base their customizations

2. A Hybrid Wireframe/Live-Website View

• A preview of the live website with the interactive wireframe superimposed on top of it.
• Allow grids to be toggled on and off.

3. GUI based CSS Style Editor

• Implementing an editor for stylistic CSS would directly complement the structurally based editor, allowing users to customize the entire visual representation of a theme without using a line of code
• This style editor could also implement a typography management tool

4. Backwards Compatibility

• Unfortunately, one caveat of an editor capable of altering theme structure is that the theme must have been compiled by the corresponding generator. Otherwise, the editor cannot make any assumptions regarding the construction of the theme or the effects that will ensue after editing its structure. That said, the theme editor could still act as a visual widget manager, and if the GUI based CSS style editor were implemented, that would remain compatible as well.

5. Markup Editor

• A markup editor could be implemented in conjunction with the GUI, and could update and be updated by changes within the GUI.
• A markup editor could also allow the user to edit the theme’s PHP files.

Filed under: Summer of Code