Styles team introduction, and introduction to the overhaul
I wanted to start by introducing the styles team:
I,
aveleh, have been acting as project manager. Basically, I get to look at the site/code and say "this could work better" and figure out what needs to be updated: the backend, the core, or the styles themselves. I get to work with the rest of the team and either ask them to make changes so that things will be easier for other users (or programmers), and I get to update core2 for the same reasons.
afuna is the team's technical manager. She hosts our dev environment, deals with bugzilla related duties, and basically does anything she can to help us focus on getting the job done. She pretends that she’s just a gofer who happens to have some technical skills, but her job is to make sure that the styles code (and coders) can interface with the site and the site database in an effective way.
av8rmike,
draigwen,
jadelennox,
liv, and
rich are stuck doing all the heavy lifting. Their job is to take the styles that were written for core1, and transform them into our new standards. This includes things from changing function names, to replacing whole bits of logic, to dealing with the fallout from CSS changes.
We’ve also had help from
jproulx who created a CSS template for us to work from and
nova who gave us wireframes for wizard layouts. In addition to giving us standards to work from, they’ve both added improvements that will quietly benefit all users. And when we’ve got all this implemented,
ysobel will be working to ensure that all of these changes are documented.
When
afuna and I talk about specific changes in the styles overhaul, we try to ensure that we’re making the experience better for all users who want to change the way their journal works.. In general, we try to keep these five different ways of interacting with the styles system in mind:
Here are some of the ways we’re working on making the experience better for each of those groups:
In the short term, you'll notice a few negatives. The most notable one will be that that some options that came with a style have been removed. This is so that those that can, are implemented in core and then easily rolled out to all styles. (Those that can't will eventually have the functionality put back in, taking advantage of other code changes.) In the long term, this will mean a lot of positives, for everyone.
I,
We’ve also had help from
When
- People who want to use the wizard to change the look of their style
- People who want to use CSS to change the look of their style
- People who want to use the advanced customization area and tutorials to change their style
- People who want to write their own styles
- People who want to write their own styles and don’t like standardizations
Here are some of the ways we’re working on making the experience better for each of those groups:
- People who want to use the wizard to change the look of their style
* A standard set of wizard options, including their placement in the wizard. This will make it easier for users to find options, no matter how many times they switch styles.
* Some new ways of interacting with the wizard, such as ticky boxes instead of yes/no dropdowns. This will make it easier to see at a glance the status of certain settings. - People who want to use CSS to change the look of their style
* A standard set of CSS, across all styles. This will make it easier to write CSS to display a header image, or hide certain comments, and have it work with any style. - People who want to use the advanced customization area and tutorials to change their style
* A standard set of function names, so that users don’t have to check which style they’re using to ensure that they can use a tutorial.
* More functions that use global variables instead of passed variables, so that users can change its desired output functionality with just one line. - People who want to write their own styles
* More functions that print information, including the standardized CSS, so that users can write less code.
* More functions that call other functions, so that when new changes are rolled out, they’ll be easily/silently implemented. - People who want to write their own styles and don’t like standardizations
* All the crazy awesome functionality you’re already used to (with some name changes).
* The ability to use core1, even though all official styles will use core2.
In the short term, you'll notice a few negatives. The most notable one will be that that some options that came with a style have been removed. This is so that those that can, are implemented in core and then easily rolled out to all styles. (Those that can't will eventually have the functionality put back in, taking advantage of other code changes.) In the long term, this will mean a lot of positives, for everyone.

no subject
no subject
Absolutely, we want user-contributed styles. We're still working on implementing features in core2, so we're starting with soliciting more stylesheet based themes first. I've got a pre-announcement up here: http://dw-styles.dreamwidth.org/4414.html and keep an eye on the community for more.
Alternatively, if you're interested in contributing code, there's a list of open styles-related bugs (sorry for the giant link) that will keep on growing. If you're not sure how to submit a patch, I think
no subject
no subject
You can see all of the official layouts/themes available to users here:
http://www.dreamwidth.org/customize/advanced/layerbrowse
Here is the info for the main core (with link to the code):
http://www.dreamwidth.org/customize/advanced/layerbrowse?id=core2
And here is a link to the simplest layout that is based on core2:
http://www.dreamwidth.org/customize/advanced/layerbrowse?id=core2base/layout
Other guides being written to help people making layouts:
http://wiki.dwscoalition.org/notes/S2_CSS
http://wiki.dwscoalition.org/notes/S2_Guide
http://wiki.dwscoalition.org/notes/S2_Cookbook
Communities that could help include
no subject