There may be good reasons for a Design Czar long term, or at least a User Experience Czar, in guiding the development of the admin application. But it seems to me that this is too large a solution for the current bottleneck, and perhaps more modest solutions should be considered as well.
If the admin application were designed for skinability, which would be some work, but which I believe could be done by a non-designer with input from various designers as they attempt to write skins, would a Design Czar really be necessary? Those changes would not need to change the current appearance of the admin significantly -- only its implementation. There is knowledge out there of what work needs to be done. I know that the grappelli project has uncovered a lot of the existing obstacles to writing a skin; if they were able to contribute patches to remove those obstacles, every designer out there working on django projects would be empowered to be his/her own Czar. Which is how it should be. Cheers, Jacob Smullyan On Feb 6, 5:03 pm, Idan Gazit <i...@pixane.com> wrote: > Hey folks, > > Splitting off > fromhttp://groups.google.com/group/django-developers/browse_thread/thread..., > which has an exhaustive discussion about how django needs to treat > design work. > > In the spirit of taking action, I put together this list with Bryan > Veloso. My goal is to spark a discussion that will lead to appointing > somebody with a few clear goals. > > "Django Design Czar" > > Rationale > * Good design, like good code, is hard to produce. > * Reviewing design is outside the purview and abilities of the core > devs. > * The admin is dated, and in need of cleanup/refactoring. A good job > would involve major breaking changes, and therefore fits more in the > 2.0 timeframe -- but there's a lot of baby steps we can take to clean > up the existing admin in the meantime. > * Imposing django's sensibilities on the design process requires a > "design czar" in much the same way as we have specific core devs > "responsible" for large django subsystems. > * Both the baby-steps and the 2.0 "ground-up" redesign will, like > every other part of django, be much more likely to succeed with a > designated parent to shepherd it into existence. > * Django can take the lead in integrating designers, not just coders, > into the development model of django. > > Responsibilities > * Wearer of the "design hat." Will serve as the go-to for proposals > and tickets that involve front-end code. > * Serves as a "design arbiter" -- needs to be somebody that the core > devs trust to make design decisions in the spirit of django's > development process (relatively conservative, "does this solve a > problem", etc). > * See "Action Plan" below. > > Action Plan > > * Trivial changes, such as margin/padding corrections, should be fair > game for committing outside of the normal release schedule, in the > same vein as documentation corrections. > * For 1.3, let's set some modest design goals as part of the > development schedule. The community might not realize that submission > of "design tickets" is something we're keen on without a little > prompting. Design proposals are accepted/voted upon like other > features on the 1.3 table, but we need to help jumpstart by seeding > the list with some (modest) design proposals. > * For 1.4, design proposals are accepted/voted upon like every other > feature. Hopefully by this timeframe, the design czar has become > visible enough that django is fielding quality design proposals > without prompting. > * In the 2.x timeframe, design czar should coordinate the effort to > reimagine the admin. It will likely be a long-term branch of django > much like multi-db was, as this won't likely be an evolutionary thing. > * Hopefully we'll gain a lot of wisdom during the 1.x refactors that > we can apply towards the 2.x ground-up rewrite. > > "What are some good targets for 1.3?" > > Off the top of my head: > > * Importing some of the good work done for django-grappelli, in > particular leveraging the fact that we have jquery in the admin now. > * Applying a grid to the admin, even if we don't make significant > changes to the overall "look" -- this would set the stage for further > changes in 1.4. > * Anything which will send a signal to the community that we're > putting a Real Process in place to keep the admin state-of-the-art > (while not sacrificing Django's stability/compatibility pledges). > > Thoughts? > > -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
