I have trouble finding my stance on this one. In some respects, I want design to be treated like everything else in Django. But I also know, from experience, that design-by-commitee is almost never good design. This, in my opinion, is why visual and interaction design has never been a strength of open source software -- the "everyone gets a say" thing just doesn't seem to work for design. Can you name a single open source project that has really spectacular interaction and visual design? I can't think of one (though they probably exist, they're definitely not the norm). Django has always been pretty good, design- wise, but that's becauseweve always had a "design czar," even if we didn't call it that (Wilson). And since that design czar kind of stepped away from the project, I think we can all agree Django hasn't improved much, if at all, from an IxD standpoint.
It's really hard to reconcile the open source mentality with the fact that design-by-commitee never works well. I'm not sure how to go about it, really. The "design czar" idea isn't perfect, but at least it's attempt to find a way to achieve both open source community and good design work -- and to date, it's worked fairly well for Django. Back when our design czar was active, Django was widely considered to have a solid understanding of interaction design in the places it made use of it (the website, the admin, etc.) We've always had a design czar, Alex, so if you want to treat this the same way we always have, then we still need one (or some). On Feb 6, 4:56 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Sat, Feb 6, 2010 at 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > I'm opposed to this. Firstly, unless I've missed something whoever > gets the position, would definitionally get it before they've done > anything! This is completely antithetical to the spirit of open > source, meritocracy. Why should design be treated any different from > other changes to Django? Changes to the design of the admin should be > handled in the same way as any changes, for a large change someone > writes up a proposal, starts work, asks for review, finalizes, and it > gets committed. That being said there is no reason a designer > couldn't have a commit bit, Wilson certainly does, but they'd have to > earn it the same way anyone else does. We don't need a formalized > process to get input from designers we trust, I ask for review from > tons of people who have no formal standing in the Django community > when I have questions that pertain to their area of expertise. > > In conclusion, there is 0 reason design needs to be treated different > from a procedural perspective. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me -- 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.
