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).
One way to think about the design czar is someone representing designers' needs in Django proper. Arguably, we already had somebody in this role -- Wilson -- and now we have a fantastic template language and an admin which is still ahead of its time in many ways. We wouldn't have had either without a talented designer at the table.
It sounds like Wilson is out of the picture, and thus vacated his de facto role as design czar. It might make more sense to think of this in terms of finding Wilson's successor than about starting something new.
First off, I'm generally on board with everything you've said here. Only three points/questions I'd like to make:
1. I wouldn't say "Wilson is out of the picture" without talking to him first. I know he's a busy man and my impression is that he doesn't have time for this right now, but I'm certainly not going to speak for him on that matter. Hopefully he'll speak up and let us know (I do know he's been following this discussion, at least casually). I totally agree that what we're really talking about now is find his successor, but let's not start doing so without confirming with him that he doesn't still want this position -- in my opinion, he should have first dibs on it if he wants it.
2. Is there value in having more than one "design czar?" As in, would it be better to have a small team handling this rather than one person? I'm not sure I know the answer, but I do worry that any one person sets us up for the situation we're in with Wilson -- where someone is the "leader", but doesn't really have the time or resources to do that job (either temporarily or permanently). I'm not sure what my own opinion is one this one, yet, but I thought I'd rase the question. Clearly we don't need a ton of people, but maybe a few?
3. On the topic of Wilson: let's be clear that none of this is his fault. He did a spectacular job on the admin interface, and never formally received a "design czar" like position in the community that I know of. He's busy like many of us, and he hasn't let us down at all, in my opinion.
Jeff
On Feb 6, 2:49 pm, Idan Gazit <i...@pixane.com> wrote:
> One way to think about the design czar is someone representing > designers' needs in Django proper. Arguably, we already had somebody > in this role -- Wilson -- and now we have a fantastic template > language and an admin which is still ahead of its time in many ways. > We wouldn't have had either without a talented designer at the table.
> It sounds like Wilson is out of the picture, and thus vacated his de > facto role as design czar. It might make more sense to think of this > in terms of finding Wilson's successor than about starting something > new.
> 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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://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
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:
> > 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@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
gets the position, would definitionally get it before they've done anything!
To respond to just this bit: you're right, but the reason whoever gets this position has done nothing to date is that they weren't "allowed" to. Wilson was the owner of the design, and no one else could contribute to it (at least not in any significant way). Not until the past 48 hours has the idea of anyone but Wilson working on the design stuff in Django been a serious possibility.
You can't hold the fact that someone hasn't done anything against them if there's nothing they possibly could have done.
On Feb 6, 4:56 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@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
On Sat, Feb 6, 2010 at 7:09 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: > 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.
I feel the same tension. You can't write unit tests for design, and the idea of having designers each working on different pieces of code until they earn the crown will probably just lead to differing opinions and an incoherent result.
Survivor: Design? Nah, everybody ends up pissed at each other for voting off their friend, and nobody wins the $1M.
Swords at dawn, then. ;-)
More seriously, +1 for design progress, but I have no idea how to get there from here. :-/
On Sat, Feb 6, 2010 at 6:26 PM, j...@jeffcroft.com <j...@jeffcroft.com>wrote:
> First off, I'm generally on board with everything you've said here. > Only three points/questions I'd like to make:
> 1. I wouldn't say "Wilson is out of the picture" without talking to > him first. I know he's a busy man and my impression is that he doesn't > have time for this right now, but I'm certainly not going to speak for > him on that matter. Hopefully he'll speak up and let us know (I do > know he's been following this discussion, at least casually). I > totally agree that what we're really talking about now is find his > successor, but let's not start doing so without confirming with him > that he doesn't still want this position -- in my opinion, he should > have first dibs on it if he wants it.
Totally agreed. I think that Wilson's input will be very valuable in this process. He is the one who was around and knows the development process at World Online that allowed the current admin and templates to be formed. I am really curious what exactly that is.
I don't want him to feel like we're pushing him out in any way. He has a brilliant designer, and his input is totally appreciated. I think that he is already implicitly part of this team of core designers, being a core dev and a designer, if he has the time. (I like this terminology, "core designer", since it doesn't imply one person, and everyone immediately knows what it means).
> 2. Is there value in having more than one "design czar?" As in, would > it be better to have a small team handling this rather than one > person? I'm not sure I know the answer, but I do worry that any one > person sets us up for the situation we're in with Wilson -- where > someone is the "leader", but doesn't really have the time or resources > to do that job (either temporarily or permanently). I'm not sure what > my own opinion is one this one, yet, but I thought I'd rase the > question. Clearly we don't need a ton of people, but maybe a few?
> 3. On the topic of Wilson: let's be clear that none of this is his > fault. He did a spectacular job on the admin interface, and never > formally received a "design czar" like position in the community that > I know of. He's busy like many of us, and he hasn't let us down at > all, in my opinion.
Totally agreed. Like in my original post, this is open source. Nobody is required to do anything. He has given us so much work that I am grateful for, and Django is in a better place because.
It's more of a social signal that we really do care about design, and actually have the people who can step up and do something about it. Wilson was that person in the beginning, being the defacto person who deals with design decision for the project. I agree he was never appointed, but that is how things worked. If we are trying to establish process, or ideas about how to perform a similar role, then the only thing that we have to look at is how it was previously done.
Luckily we have an excellent model of how things worked previously, and they seemed to work pretty damn well. So hopefully we can emulate that going forward, and produce similarly awesome results.
> 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
First off, there are designers who have contributed great amounts of stuff to the Django community. Nathan Borror has his Basic Apps (which interestingly is a designer contributing code, because that's what he can contribute easily). The Grapelli team has that project which represents a large amount of open source code in the design realm around the project. There are countless others that have put in the time, and helped out around here. It's not like we're going to take in some random designer, these are people that we know and trust.
I agree that this should be treated in the same way as development, is that not what we're proposing? We have the same role for a designer on the core team as for a developer. This seems like we are doing the same thing? It's not like the Czar/Core designer person will be able to just make commits to the code base whenever they want with no oversight. They will be just like a normal committer, people will be able to veto things and everything else. It just means that we have people who really know what they are talking about with design to make those decisions.
A similar idea is when Simon asked for feedback on the security issues with Django's signing infrastructure. We don't have experts on the team to make those calls, so we need to bring in people who are knowledge in that area. If there was someone in the community who has contributed a lot, and knew a ton about security, it would seem like a no brainer to make them a committer, with a Czar-like power over security issues. I am merely proposing we do the same thing with design.
Just to hit on another point that might have been missed by Alex's -0/1 is that we don't have someone to pick the positions.
When evaluating meritocracy, we've traditionally had someone who was able to do the selection. Some number of Jacob / Simon / Adrian / other commiter has effectively vetted all current core commiters. The entire *point* of this, is that we don't have someone who can properly do the selection. The only person who can fill this role is Wilson. Outside of that, I think it would make sense for a vote among people who feel they have a stake in the design side of things and can fairly suggest someone get to vote that person in, with BDFL blessing. The names that come to mind are those that have popped up here and there. Jeff, Idan, Nathan, Bryan, the Grapelli team, etc. I, for one, am willing to trust their judgement on someone who can lead this design-czar selection process, if Wilson doesn't come out and name his successor, as it were.
-justin
(the above with the usual caveats recognizing Wilson's contribution & role)
On Feb 7, 2:26 am, "j...@jeffcroft.com" <j...@jeffcroft.com> wrote:
> 1. I wouldn't say "Wilson is out of the picture" without talking to > him first.
Amen. I was under the impression that he's definitively out of the picture. If he can be lured back to the community, awesome.
> 2. Is there value in having more than one "design czar?" As in, would > it be better to have a small team handling this rather than one > person?
I thought about this yesterday as well. I am +0 on "single czar" for several reasons:
* Design by committee almost invariably sucks / deadlocks. * The design czar is an arbiter, not a panel. Part of his/her job is to listen to the community and make decisions so as to prevent the design process from stalling. Note the "listen to the community" part -- I imagine that a few django-oriented designers will want to step up and have a hand in steering Django's design sensibilities. It's not up to the czar to write everything / design everything by themselves, but rather to foster this community of django designers.
> 3. On the topic of Wilson: let's be clear that none of this is his > fault. He did a spectacular job on the admin interface, and never > formally received a "design czar" like position in the community that > I know of. He's busy like many of us, and he hasn't let us down at > all, in my opinion.
Again, wasn't my intention to imply anything bad about Wilson. He's an amazing designer who created some very original things in Django, without somebody handing him a roadmap. On the contrary, I'm saying that the talents he brought to django are currently missing, and Django would do well to have somebody try to fill those shoes.
On Feb 7, 6:06 am, Justin Lilly <jus...@justinlilly.com> wrote:
> I, for > one, am willing to trust their judgement on someone who can lead this > design-czar selection process, if Wilson doesn't come out and name his > successor, as it were.
Something that hasn't been explicitly said yet:
I *don't* think that the design czar necessarily needs to be a rockstar designer. Their job is not to design everything singlehandedly. Their job is to shepherd the design process within django core.
Being well-versed in design is obviously a must, but I posit that familiarity with the community, core devs, and Django's development practices are more important for this role than being an A-list designer.
let me just add one (more) point to this discussion (I´ve already stressed this issue at the other thread).
IMO, when talking about the admin-interface, we´re talking about different "construction zones": – the whole structure and user experience with the admin-interface as mentioned by jeff and others (long-term) – HTML/CSS (quite short-term, this can be changed with baby-steps) – JS-refactoring (already in the making - but, unfortunately, decoupled from refactoring the HTML/CSS) – python-changes, some smaller (like removing hardcoded stuff) and some bigger (if we want to re-discuss the admin index page, for example) – look & feel (probably the least important issue since skins will evolve once skinning is easily possible)
considering these zones, I guess I´m following jeffs proposal for a team (with, maybe, a team-leader), because no "design czar" I know is really good with all the mentioned topics.
just my 2 cents.
regards, patrick
On 7 Feb., 08:17, Idan Gazit <i...@pixane.com> wrote:
> On Feb 7, 6:06 am, Justin Lilly <jus...@justinlilly.com> wrote:
> > I, for > > one, am willing to trust their judgement on someone who can lead this > > design-czar selection process, if Wilson doesn't come out and name his > > successor, as it were.
> Something that hasn't been explicitly said yet:
> I *don't* think that the design czar necessarily needs to be a > rockstar designer. Their job is not to design everything > singlehandedly. Their job is to shepherd the design process within > django core.
> Being well-versed in design is obviously a must, but I posit that > familiarity with the community, core devs, and Django's development > practices are more important for this role than being an A-list > designer.
On Sun, Feb 7, 2010 at 9:11 AM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: >> I'm opposed to this. Firstly, unless I've missed something whoever > gets the position, would definitionally get it before they've done > anything!
> To respond to just this bit: you're right, but the reason whoever gets > this position has done nothing to date is that they weren't "allowed" > to. Wilson was the owner of the design, and no one else could > contribute to it (at least not in any significant way). Not until the > past 48 hours has the idea of anyone but Wilson working on the design > stuff in Django been a serious possibility.
> You can't hold the fact that someone hasn't done anything against them > if there's nothing they possibly could have done.
This certainly wasn't my understanding of the situation. It was my understanding that anyone was welcome to contribute, and designs would be judged on merit. This is certainly the sentiment expressed in the FAQ and contribution guide.
If this has been poorly communicated, then we have something we need to address. Suggestions are welcome. If it's been contradicted by someone else in the core, I'd be interested in hearing how and where -- if only so that I can get on the same page (or at least work out which page others are on).
So what about the "Design Czar"? In practical terms, what is being called a "Design Czar" is really just another name for "active member of the core team with design credentials".
The fact that there is only one member of the core team with design credentials (i.e., Wilson) is certainly a weakness in Django's core team. Having a single point of failure is never a good thing. The stagnation of Django's visual/UX design, and the perception that "none but Wilson may contribute" can probably be traced back to this single point of failure.
As other have said, this isn't a statement of blame -- Wilson is a volunteer like everyone else, and I'm grateful for all the work he has done in the past. If he can spare time to help out now and in the future, thats great; if he can't, that's a loss for Django, but it's not a failing on Wilson's part. I only mean to point out that if the only person in the core team with design credentials isn't both willing and able to be an active member of the community, then we need to address this limitation in our core team.
Now, I completely agree that "design by committee" doesn't work, but I don't accept that the consequence of this is that Django's design/UX core team must be a single person. There must be some middle ground where a design leader can defer certain design and implementation decisions to lieutenants that he trusts.
(Please correct me if I'm wrong on this point. I am the first to admit that I'm not a visual/UX designer, so if I'm missing or misunderstanding some crucial aspect of the design process, let me know.)
If the design task can be split amongst many people, then I see no reason that Django's existing process for adopting new core developers can't be applied to adopting new visual/UX designers -- that is:
* any designer who want to help contribute to Django is welcome to make a proposal (backed by mockups, CSS, JavaScript, or whatever is needed)
* those proposal can be reviewed by the design/UX core team (which, initially, is Wilson)
* good proposals will be accepted and committed to trunk
* when Wilson feels that he can trust the design decisions of a particular contributor, that committer will be invited into the core team.
The only catch to this is if Wilson isn't in a position to bootstrap this process. In that case, we have a separate problem -- how to bootstrap a new design/UX core team. However, this is a moot discussion until we know the state of Wilson's current and likely future commitment.
So -- at this point, we really need some feedback from Wilson himself. Wilson - if you're out reading, now would be a very good time :-)
Django needs someone who will start and get the admin job done, but some decisions must be made before by the community. For example: whether to use CSS reset or not? If, which one? While refactoring some admin pieces we reduced number of CSS files to one. Would you accept such solution? Why it's been split in the first place? Perhaps there's a good reason for that? How far do you want to go with accessibility/ usability stuff (i.e. what are the priorities)? All that needs proper discussion with anyone interested.
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:
> 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).
> First off, there are designers who have contributed great amounts of > stuff to the Django community. Nathan Borror has his Basic Apps (which > interestingly is a designer contributing code, because that's what he > can contribute easily).
Exactly. Christian Metts comes to mind, as well, for a designer who has contributed a lot to the Django community (typogrify, compressor, inlines, etc.)
> * Design by committee almost invariably sucks / deadlocks.
Right, but I don't necessarily think that means we have to have a singer design leader (whatever you want to call him/her) in the Django community. Good design requires a singular vision, but there's no reason that vision can't be shared by a handful of people. It's when there are several different visions competing with one another that things go terribly wrong -- usually you end up with a watered down, half ass version of all of them, instead of fully realizing any particular vision.
> I *don't* think that the design czar necessarily needs to be a > rockstar designer. Their job is not to design everything > singlehandedly. Their job is to shepherd the design process within > django core.
Absolutely agree.
> considering these zones, I guess I´m following jeffs proposal for a > team (with, maybe, a team-leader), because no "design czar" I know is > really good with all the mentioned topics.
Well, like Idan said, I wouldn't expect a "design czar" or team of design czars to be able to contribute in all those "zones." The point of the design czar, as we're discussing it now, is not to make every design-related change themselves, but rather to shepherd them.
Also, let's keep in mind that the admin interface isn't the only area of Django where interaction design is needed. The other *huge* one I see is the Django website itself.
> This certainly wasn't my understanding of the situation. It was my > understanding that anyone was welcome to contribute, and designs would > be judged on merit. This is certainly the sentiment expressed in the > FAQ and contribution guide.
The problem with this is that no active member of the core team is *qualified* to judge designed based on merit.
> If it's been contradicted by someone else in the core, I'd be > interested in hearing how and where -- if only so that I can > get on the same page (or at least work out which page others are on).
I've seen several instances on the lists where you and other members of the core team have responded to design-related suggestions and questions with, effectively, "That's Wilson's thing." I've also gotten this response in person from people at DjangoCon and from the time I've spent in Lawrence, as well as in IM conversations with members of the core team. This implies that no one but Wilson is welcome to make changes, and/or that if you want to get anything done, design-wise, you're going to have to talk to Wilson. Which, since he's MIA, is pretty difficult for most people. I'm lucky enough to be friends with Wilson, so I *have* talked to him about this stuff many times, but those conversations aren't ever "on the record," so to speak -- no other member of the core team is around to hear them.
We've absolutely moved past the point in this discussion where designers feel unwelcome. The fact that we're still talking about this means you are, in fact, interested in finding a way to make use of designers' suggestions in Django core. I thank all of you for that.
> So what about the "Design Czar"? In practical terms, what is being > called a "Design Czar" is really just another name for "active member > of the core team with design credentials".
Yes, I think so. Really, I think it's pretty much what we already have in Wilson, except that he's inactive.
> The stagnation of Django's visual/UX design, and the perception that "none > but Wilson may contribute" can probably be traced back to this single > point of failure.
Agreed.
> Now, I completely agree that "design by committee" doesn't work, but I > don't accept that the consequence of this is that Django's design/UX > core team must be a single person. There must be some middle ground > where a design leader can defer certain design and implementation > decisions to lieutenants that he trusts.
Absolutely. Like I said, my opinion is that there needs to be a single vision, not a single designer.
> any designer who want to help contribute to Django is welcome to > make a proposal (backed by mockups, CSS, JavaScript, or whatever is > needed)
Serious question from someone who's never contributed to Django: what does a "proposal" entail? I'd be all for putting in writing my thoughts on what is currently wrong with the admin interface from an interaction design perspective, and how I'd like to see it work, but I'm not sure I'm willing to put the hours in that would be needed to do, as you say, mockups, CSS, JS, etc. That may mean I'm not committed enough to this to contribute to Django, and if so, that's fine. I'm just curious what exactly is needed for my thoughts to qualify as a "proposal," and therefore be taken seriously. When people make proposals for other contributions, do they write code first, or do they first tell the core team what they're *going* to do, get some degree of interest/buy-in, and *then* go write the code? How much upfront work is necessary before you've got a "proposal?" I write proposals for potential clients all the time, but I'd never include a mockup in them.
> Django needs someone who will start and get the admin job done, but > some decisions must be made before by the community. For example: > whether to use CSS reset or not? If, which one?
I completely disagree that a technology question like "will we use a CSS reset" should be put *before* the interaction design of Django's admin interface. Interaction design has absolutely nothing to do with CSS, and can be done entirely independent of the technology that will or won't eventually be used to implement it. Technology decisions should be made in support of the design, not the other way around.
Also, I'll say again: this discussion shouldn't really just be able the admin interface -- it should be more broad, talking about who can lead *anything* interaction design-related in the Django community.
> 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?
I say design leadership is still needed, because this isn't just about the admin interface, and because it's not just about skinnability, either. Some of us have ideas for an overarching, sweeping, re- thinking of the admin interface. There seems to be a misconception here that we're talking about the admin interface's *look*. I'm not. I'm talking about its *design*.
Grappelli has done a great job of skinning the admin interface. But we're talking about something much greater than that, here (or at least I am).
> unless I've missed something whoever gets the position, would definitionally get it before they've done anything!
I strongly suggest you should take a look at grappelli ... some people *are* doing things ;)
> In conclusion, there is 0 reason design needs to be treated different from a procedural perspective.
Design is not unlike code, it gets better with a democratic process and iterations. But the comparison stops there. The rest is not procedural at all. The only thing you might call procedural is the prototyping process. The rest is only a feedback loop.
That said I'm not fond of the term "Design Czar" in the sense that it put somebody in a place where he was power over others on something as personal as taste. And even then, the line can be blurred because an interface (web or application) can have a beautiful design and be totally unusable or it can also be really usable and have an horrible design.
Achieving both on the web is no small feat with the plethora of devices, screen sizes, browsers etc.. Your design must be good looking but not too trendy if you want it to last more than a year.
For some people design is more important than accessibility and it might cause some friction since both are related to a very personal experience. The kind of friction that generates mile long threads over whether or not pale text over black a background is considered bad practice. UI design is almost a science, but in which there is such things as feelings and emotions.
That said I fear that a "Design Czar" will only do more harm than good on the Django community. I think what the Django admin app really needs is some kind of Interface Design and Accessibility Committee that would consist of one or more lead designers and a team of accessibility geeks.
Then you put them all in a small room with a plastic spoon and lock the door.
Seriously, yes design is important, but it's also ephemeral. What looks good today will look old and clunky tomorrow.
On the flip side, accessibility is something that evolve but big lines does not changes much. It's also something that is far more subtle than design. It's not something the average developer/ designer is keen to work on without any issues being raised by the end user.
So in that regard, I think the Django team should concentrate on giving a generic and accessible interface rather than a "tasteful" interface. In order to be generic and accessible it's necessary start with a clean and semantically meaningful markup and unobtrusive JavaScript that degrades well.
Once you have that you can change the design every year if you want to. Not that I would suggest to, but programmers must realize that designs and trends have a much shorter life cycle than code and thus can hardly be "threated like code", but accessibility can.
Or let me put it the other way around: Would you like a framework with the most awesome design you ever saw, but you just can't change it much without pain and accessibly is only "OK" .. or a framework that is really generic and accessible with an OK design but that you can customize easily ?
> > 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@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
> Also, I'll say again: this discussion shouldn't really just be able > the admin interface -- it should be more broad, talking about who can > lead *anything* interaction design-related in the Django community.
> > 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?
> I say design leadership is still needed, because this isn't just about > the admin interface, and because it's not just about skinnability, > either. Some of us have ideas for an overarching, sweeping, re- > thinking of the admin interface. There seems to be a misconception > here that we're talking about the admin interface's *look*. I'm not. > I'm talking about its *design*.
> Grappelli has done a great job of skinning the admin interface. But > we're talking about something much greater than that, here (or at > least I am).
You are indeed, but the admin UI is still the center of it. (As for the django website -- I would argue that's really a different matter than developing django itself, and seems to deserve a separate discussion.) I'm guess I'm concerned about small matters that could be addressed more or less immediately getting stalled while a grandiose vision gets sorted out. Rethinking the admin UX would certainly take some leadership, but it would also take considerable buy-in from the devs and the community to actually fly, and take a long time -- and in the meantime, we've got the admin we have now, which regardless is going to need incremental improvement. By all means argue for Py3K-ing (or Perl6-ing :) ) the admin, but closer to hand, it needs a different kind of help.
Grappelli is in a crisis of its own because it breaks on django-trunk rather badly; its devs are trying to decide whether they have to fork the admin as a way forward, when really they would rather just skin it. The admin right now can't be skinned in a stable way, which isn't AFAICT because its design makes some assumptions that painfully restrict how it can be skinned -- it is a matter of implementation details: how the javascript is hard-coded, and that sort of thing. (This hugely affects me personally, which is why I'm sticking my neck out and writing about it.)
Jeff, you've pointed out that having a design czar is more or less the status quo, except that it hasn't worked in the long term. I question that in the future it would work in the long term any better. Transferring ownership of the position when a czar gets busy with life isn't going to be that straightforward. Finding a way for designers to contribute without a czar being needed strikes me as a better approach. If the admin were truly themeable, that would be the case; the need for a singular czar goes away when you don't have a singular design.
Upon re-reading your last post more carefully, Jeff, I realize that you actually more-or-less agree with at least portions of what I said. Sorry to kick up dust unnecessarily! My main concern is that the "look" of the current admin is too hard to modify with the current implementation, and I think that has important consequences, even if there are deeper issues involved.
On Feb 7, 1:37 pm, jsmullyan <jsmull...@gmail.com> wrote:
> On Feb 7, 12:52 pm, "j...@jeffcroft.com" <j...@jeffcroft.com> wrote:
> > Also, I'll say again: this discussion shouldn't really just be able > > the admin interface -- it should be more broad, talking about who can > > lead *anything* interaction design-related in the Django community.
> > > 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?
> > I say design leadership is still needed, because this isn't just about > > the admin interface, and because it's not just about skinnability, > > either. Some of us have ideas for an overarching, sweeping, re- > > thinking of the admin interface. There seems to be a misconception > > here that we're talking about the admin interface's *look*. I'm not. > > I'm talking about its *design*.
> > Grappelli has done a great job of skinning the admin interface. But > > we're talking about something much greater than that, here (or at > > least I am).
> You are indeed, but the admin UI is still the center of it. (As for > the django website -- I would argue that's really a different matter > than developing django itself, and seems to deserve a separate > discussion.) I'm guess I'm concerned about small matters that could > be addressed more or less immediately getting stalled while a > grandiose vision gets sorted out. Rethinking the admin UX would > certainly take some leadership, but it would also take considerable > buy-in from the devs and the community to actually fly, and take a > long time -- and in the meantime, we've got the admin we have now, > which regardless is going to need incremental improvement. By all > means argue for Py3K-ing (or Perl6-ing :) ) the admin, but closer to > hand, it needs a different kind of help.
> Grappelli is in a crisis of its own because it breaks on django-trunk > rather badly; its devs are trying to decide whether they have to fork > the admin as a way forward, when really they would rather just skin > it. The admin right now can't be skinned in a stable way, which isn't > AFAICT because its design makes some assumptions that painfully > restrict how it can be skinned -- it is a matter of implementation > details: how the javascript is hard-coded, and that sort of thing. > (This hugely affects me personally, which is why I'm sticking my neck > out and writing about it.)
> Jeff, you've pointed out that having a design czar is more or less the > status quo, except that it hasn't worked in the long term. I question > that in the future it would work in the long term any better. > Transferring ownership of the position when a czar gets busy with life > isn't going to be that straightforward. Finding a way for designers > to contribute without a czar being needed strikes me as a better > approach. If the admin were truly themeable, that would be the case; > the need for a singular czar goes away when you don't have a singular > design.
> Grappelli has done a great job of skinning the admin interface.
It depends which version you check. We are currently in the decision of breaking appart from the Django admin and create a standalone app or stick with it[0]..
We have started to be a lot more than a "skin". We are currently in the process of merging two branches, one in which all the HTML have been refactored with a grid system and semantically clean widgets implementation with my branch, in which I rewrote all the JavaScript style using jQuery UI.
When this will be done, there will not be much of the original admin front end code left, if at all.
As now we tried to stabilize to existing functionalities. But all this work will hopefully lead to a way more flexible, accessible and themable admin interface.
The only difference is that we loose some dead weight by dropping support of old browsers, which allowed us to work more efficiently and quickly.
> > First off, there are designers who have contributed great amounts of > > stuff to the Django community. Nathan Borror has his Basic Apps (which > > interestingly is a designer contributing code, because that's what he > > can contribute easily).
> Exactly. Christian Metts comes to mind, as well, for a designer who > has contributed a lot to the Django community (typogrify, compressor, > inlines, etc.)
> > * Design by committee almost invariably sucks / deadlocks.
> Right, but I don't necessarily think that means we have to have a > singer design leader (whatever you want to call him/her) in the Django > community. Good design requires a singular vision, but there's no > reason that vision can't be shared by a handful of people. It's when > there are several different visions competing with one another that > things go terribly wrong -- usually you end up with a watered down, > half ass version of all of them, instead of fully realizing any > particular vision.
> > I *don't* think that the design czar necessarily needs to be a > > rockstar designer. Their job is not to design everything > > singlehandedly. Their job is to shepherd the design process within > > django core.
> Absolutely agree.
> > considering these zones, I guess I´m following jeffs proposal for a > > team (with, maybe, a team-leader), because no "design czar" I know is > > really good with all the mentioned topics.
> Well, like Idan said, I wouldn't expect a "design czar" or team of > design czars to be able to contribute in all those "zones." The point > of the design czar, as we're discussing it now, is not to make every > design-related change themselves, but rather to shepherd them.
> Also, let's keep in mind that the admin interface isn't the only area > of Django where interaction design is needed. The other *huge* one I > see is the Django website itself.
> > This certainly wasn't my understanding of the situation. It was my > > understanding that anyone was welcome to contribute, and designs would > > be judged on merit. This is certainly the sentiment expressed in the > > FAQ and contribution guide.
> The problem with this is that no active member of the core team is > *qualified* to judge designed based on merit.
> > If it's been contradicted by someone else in the core, I'd be > > interested in hearing how and where -- if only so that I can > > get on the same page (or at least work out which page others are on).
> I've seen several instances on the lists where you and other members > of the core team have responded to design-related suggestions and > questions with, effectively, "That's Wilson's thing." I've also gotten > this response in person from people at DjangoCon and from the time > I've spent in Lawrence, as well as in IM conversations with members of > the core team. This implies that no one but Wilson is welcome to make > changes, and/or that if you want to get anything done, design-wise, > you're going to have to talk to Wilson. Which, since he's MIA, is > pretty difficult for most people. I'm lucky enough to be friends with > Wilson, so I *have* talked to him about this stuff many times, but > those conversations aren't ever "on the record," so to speak -- no > other member of the core team is around to hear them.
> We've absolutely moved past the point in this discussion where > designers feel unwelcome. The fact that we're still talking about this > means you are, in fact, interested in finding a way to make use of > designers' suggestions in Django core. I thank all of you for that.
> > So what about the "Design Czar"? In practical terms, what is being > > called a "Design Czar" is really just another name for "active member > > of the core team with design credentials".
> Yes, I think so. Really, I think it's pretty much what we already have > in Wilson, except that he's inactive.
> > The stagnation of Django's visual/UX design, and the perception that "none > > but Wilson may contribute" can probably be traced back to this single > > point of failure.
> Agreed.
> > Now, I completely agree that "design by committee" doesn't work, but I > > don't accept that the consequence of this is that Django's design/UX > > core team must be a single person. There must be some middle ground > > where a design leader can defer certain design and implementation > > decisions to lieutenants that he trusts.
> Absolutely. Like I said, my opinion is that there needs to be a single > vision, not a single designer.
> > any designer who want to help contribute to Django is welcome to > > make a proposal (backed by mockups, CSS, JavaScript, or whatever is > > needed)
> Serious question from someone who's never contributed to Django: what > does a "proposal" entail? I'd be all for putting in writing my > thoughts on what is currently wrong with the admin interface from an > interaction design perspective, and how I'd like to see it work, but > I'm not sure I'm willing to put the hours in that would be needed to > do, as you say, mockups, CSS, JS, etc. That may mean I'm not committed > enough to this to contribute to Django, and if so, that's fine. I'm > just curious what exactly is needed for my thoughts to qualify as a > "proposal," and therefore be taken seriously. When people make > proposals for other contributions, do they write code first, or do > they first tell the core team what they're *going* to do, get some > degree of interest/buy-in, and *then* go write the code? How much > upfront work is necessary before you've got a "proposal?" I write > proposals for potential clients all the time, but I'd never include a > mockup in them.
> > Django needs someone who will start and get the admin job done, but > > some decisions must be made before by the community. For example: > > whether to use CSS reset or not? If, which one?
> I completely disagree that a technology question like "will we use a > CSS reset" should be put *before* the interaction design of Django's > admin interface. Interaction design has absolutely nothing to do with > CSS, and can be done entirely independent of the technology that will > or won't eventually be used to implement it. Technology decisions > should be made in support of the design, not the other way around.
> Also, I'll say again: this discussion shouldn't really just be able > the admin interface -- it should be more broad, talking about who can > lead *anything* interaction design-related in the Django community.
> > 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?
> I say design leadership is still needed, because this isn't just about > the admin interface, and because it's not just about skinnability, > either. Some of us have ideas for an overarching, sweeping, re- > thinking of the admin interface. There seems to be a misconception > here that we're talking about the admin interface's *look*. I'm not. > I'm talking about its *design*.
> Grappelli has done a great job of skinning the admin interface. But > we're talking about something much greater than that, here (or at > least I am).
This post is flawed because it artificially separates accessibility from design, and it treats design as if it only has to do with aesthetics. Design encapsulates accessibility, and and good interaction designer will put accessibility high on his/her list of priorities.
On Feb 7, 10:34 am, h3 <hainea...@gmail.com> wrote:
> > unless I've missed something whoever gets the position, would definitionally get it before they've done anything!
> I strongly suggest you should take a look at grappelli ... some people > *are* doing things ;)
> > In conclusion, there is 0 reason design needs to be treated different from a procedural perspective.
> Design is not unlike code, it gets better with a democratic process > and iterations. But the comparison stops there. > The rest is not procedural at all. The only thing you might call > procedural is the prototyping process. The rest is > only a feedback loop.
> That said I'm not fond of the term "Design Czar" in the sense that it > put somebody in a place where he was power > over others on something as personal as taste. And even then, the line > can be blurred because an interface (web or > application) can have a beautiful design and be totally unusable or it > can also be really usable and have an horrible > design.
> Achieving both on the web is no small feat with the plethora of > devices, screen sizes, browsers etc.. Your > design must be good looking but not too trendy if you want it to last > more than a year.
> For some people design is more important than accessibility and it > might cause some friction since both are related > to a very personal experience. The kind of friction that generates > mile long threads over whether or not pale text over > black a background is considered bad practice. UI design is almost a > science, but in which there is such things as > feelings and emotions.
> That said I fear that a "Design Czar" will only do more harm than good > on the Django community. I think what the > Django admin app really needs is some kind of Interface Design and > Accessibility Committee that would consist > of one or more lead designers and a team of accessibility geeks.
> Then you put them all in a small room with a plastic spoon and lock > the door.
> Seriously, yes design is important, but it's also ephemeral. What > looks good today will look old and clunky tomorrow.
> On the flip side, accessibility is something that evolve but big lines > does not changes much. It's also something that is > far more subtle than design. It's not something the average developer/ > designer is keen to work on without any issues > being raised by the end user.
> So in that regard, I think the Django team should concentrate on > giving a generic and accessible interface rather than a > "tasteful" interface. In order to be generic and accessible it's > necessary start with a clean and semantically meaningful > markup and unobtrusive JavaScript that degrades well.
> Once you have that you can change the design every year if you want > to. Not that I would suggest to, but programmers > must realize that designs and trends have a much shorter life cycle > than code and thus can hardly be "threated like code", > but accessibility can.
> Or let me put it the other way around: Would you like a framework with > the most awesome design you ever saw, but you just > can't change it much without pain and accessibly is only "OK" .. or a > framework that is really generic and accessible with an OK > design but that you can customize easily ?
> > > 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-developers@googlegroups.com. > > > To unsubscribe from this group, send email to django-developers+unsubscribe@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 are indeed, but the admin UI is still the center of it. (As for > the django website -- I would argue that's really a different matter > than developing django itself, and seems to deserve a separate > discussion.)
Well, our current "design czar" (Wilson) was tasked with the responsibility of the design for the Django website, so I assumed any new design czar or czars would be, as well. But perhaps not. I would say that *someone* needs to be in charge of that design, though, whether it's the same person or team that is handling the admin interface or not.
> I'm guess I'm concerned about small matters that could > be addressed more or less immediately getting stalled while a > grandiose vision gets sorted out. Rethinking the admin UX would > certainly take some leadership, but it would also take considerable > buy-in from the devs and the community to actually fly, and take a > long time -- and in the meantime, we've got the admin we have now, > which regardless is going to need incremental improvement.
Fair enough. I would certainly welcome incremental improvements to the existing admin, and I even have a few to suggest, but I don't think I'm passionate enough about that project to try to get too involved, myself. But certainly, it could use some attention, and I would think any "design czar" would be tasked with overseeing that process, as well.
> Grappelli is in a crisis of its own because it breaks on django-trunk > rather badly; its devs are trying to decide whether they have to fork > the admin as a way forward, when really they would rather just skin > it. The admin right now can't be skinned in a stable way, which isn't > AFAICT because its design makes some assumptions that painfully > restrict how it can be skinned -- it is a matter of implementation > details: how the javascript is hard-coded, and that sort of thing. > (This hugely affects me personally, which is why I'm sticking my neck > out and writing about it.)
Makes sense. Skinning the admin is also something that I'm not personally too invested in (I don't really have any need to skin it, and the existing "skin" doesn't offend my aesthetic sensibilities), but I agree that it *should* be architected to be easy to skin, nonetheless. My personal passion is more in the vein of making the admin interface more usable, more humane, more capable, and more extensible -- not more pretty. But, if someone else wanted to tackle making it more skinnable, I would be +1 for that, even though I don't need it (or want to work on it) myself.
> Jeff, you've pointed out that having a design czar is more or less the > status quo, except that it hasn't worked in the long term.
Actually, that's not what I said. I think our existing "design czar" (Wilson) worked out extremely well for Django until he became inactive.
> I question > that in the future it would work in the long term any better. > Transferring ownership of the position when a czar gets busy with life > isn't going to be that straightforward. Finding a way for designers > to contribute without a czar being needed strikes me as a better > approach. If the admin were truly themeable, that would be the case; > the need for a singular czar goes away when you don't have a singular > design.
You may be right that we don't need a "czar." I don't know where I stand on that, yet. But I disagree that if the admin were "themeable," all our design needs would be taken care of. Making it skinnable only allows people to enhance its aesthetics, and what I think is ultimately needed (in the long term) is a complete re-thinking of how the admin interface works, how applications can extend it for their needs, and how it can be more humane towards its users. None of this is solved by making it themeable (but again, I still think making it themeable is a good idea).
> Upon re-reading your last post more carefully, Jeff, I realize that > you actually more-or-less agree with at least portions of what I > said. Sorry to kick up dust unnecessarily! My main concern is that > the "look" of the current admin is too hard to modify with the current > implementation, and I think that has important consequences, even if > there are deeper issues involved.
> On Feb 7, 1:37 pm, jsmullyan <jsmull...@gmail.com> wrote:
> > On Feb 7, 12:52 pm, "j...@jeffcroft.com" <j...@jeffcroft.com> wrote:
> > > Also, I'll say again: this discussion shouldn't really just be able > > > the admin interface -- it should be more broad, talking about who can > > > lead *anything* interaction design-related in the Django community.
> > > > 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?
> > > I say design leadership is still needed, because this isn't just about > > > the admin interface, and because it's not just about skinnability, > > > either. Some of us have ideas for an overarching, sweeping, re- > > > thinking of the admin interface. There seems to be a misconception > > > here that we're talking about the admin interface's *look*. I'm not. > > > I'm talking about its *design*.
> > > Grappelli has done a great job of skinning the admin interface. But > > > we're talking about something much greater than that, here (or at > > > least I am).
> > You are indeed, but the admin UI is still the center of it. (As for > > the django website -- I would argue that's really a different matter > > than developing django itself, and seems to deserve a separate > > discussion.) I'm guess I'm concerned about small matters that could > > be addressed more or less immediately getting stalled while a > > grandiose vision gets sorted out. Rethinking the admin UX would > > certainly take some leadership, but it would also take considerable > > buy-in from the devs and the community to actually fly, and take a > > long time -- and in the meantime, we've got the admin we have now, > > which regardless is going to need incremental improvement. By all > > means argue for Py3K-ing (or Perl6-ing :) ) the admin, but closer to > > hand, it needs a different kind of help.
> > Grappelli is in a crisis of its own because it breaks on django-trunk > > rather badly; its devs are trying to decide whether they have to fork > > the admin as a way forward, when really they would rather just skin > > it. The admin right now can't be skinned in a stable way, which isn't > > AFAICT because its design makes some assumptions that painfully > > restrict how it can be skinned -- it is a matter of implementation > > details: how the javascript is hard-coded, and that sort of thing. > > (This hugely affects me personally, which is why I'm sticking my neck > > out and writing about it.)
> > Jeff, you've pointed out that having a design czar is more or less the > > status quo, except that it hasn't worked in the long term. I question > > that in the future it would work in the long term any better. > > Transferring ownership of the position when a czar gets busy with life > > isn't going to be that straightforward. Finding a way for designers > > to contribute without a czar being needed strikes me as a better > > approach. If the admin were truly themeable, that would be the case; > > the need for a singular czar goes away when you don't have a singular > > design.
Just to steer the discussion back to practical matters:
1. This thread isn't about what stuff we want to do in the admin, or whether grappelli is great. How to improve the admin or any other aspect of Django which has design issues is a great discussion! It just isn't *this* discussion.
2. *This* discussion is about how to bootstrap a design czar/team within Django. Russ is on-target when he says that the next step is getting in touch with Wilson and sussing him out on the strategy. I could look up his email and just ping him ("Hi, you don't know me, yada yada") but perhaps somebody with a more direct relationship (Jeff?) could alert Wilson to this thread and ask him to weigh in.
3. What we haven't yet come to a consensus on how to bootstrap a design czar/team if Wilson is out. I'll be pleasantly surprised if he indicates his availability, but assuming that he doesn't have the time or the desire, where do we start in selecting a design czar? Justin Lilly's proposal to let a small team of prominent Django designers select/elect a czar is fine by me.
Aside: "One vision" / Czar-vs-team:
Getting different people on the same wavelength is difficult. I'm still +0 on single design czar because in my experience, an arbiter is needed to "just make the call." Over time, a loose group of people that trust each other and can share power responsibly may emerge -- much like how the Django core devs are now. But picking a group of people to both adapt Django's development philosophy to the realm of design and having them all implement it the same way sounds overly ambitious to me. IMO, let's start with one person and see how it goes. It is easier for all of the team to share a vision if the team selects for it over time, just like how devs are given a commit bit if they demonstrate compatibility with Django's dev process (and implicitly, the philosophy).
Also, trust is an important aspect of the core dev team. I'd assume that after a few months of working with the core designer, the dev team would be more inclined to trust their judgment about who would be a good fit for inclusion into the core design team.
4. More core dev opinions
We've heard from a couple of prominent devs, but I'd love to hear more core devs chime in on the matter. Adding this design czar to the roster of core devs is as much about the other core devs as it is about this new position.
