Django Design Czar

203 views
Skip to first unread message

Idan Gazit

unread,
Feb 6, 2010, 5:03:29 PM2/6/10
to Django developers
Hey folks,

Splitting off from http://groups.google.com/group/django-developers/browse_thread/thread/ca4f26d616921753,
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

Idan Gazit

unread,
Feb 6, 2010, 5:49:29 PM2/6/10
to Django developers
A small addendum:

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.

-I

je...@jeffcroft.com

unread,
Feb 6, 2010, 7:26:08 PM2/6/10
to Django developers
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

Alex Gaynor

unread,
Feb 6, 2010, 7:56:17 PM2/6/10
to django-d...@googlegroups.com
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@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

je...@jeffcroft.com

unread,
Feb 6, 2010, 8:09:50 PM2/6/10
to Django developers
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...,

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

je...@jeffcroft.com

unread,
Feb 6, 2010, 8:11:40 PM2/6/10
to Django developers
> 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.

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...,

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

Jeremy Dunck

unread,
Feb 6, 2010, 8:27:20 PM2/6/10
to django-d...@googlegroups.com
On Sat, Feb 6, 2010 at 7:09 PM, je...@jeffcroft.com <je...@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. :-/

Eric Holscher

unread,
Feb 6, 2010, 8:53:25 PM2/6/10
to django-d...@googlegroups.com
On Sat, Feb 6, 2010 at 6:26 PM, je...@jeffcroft.com <je...@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.

Cheers,
Eric

Eric Holscher

unread,
Feb 6, 2010, 9:14:53 PM2/6/10
to Django developers
>
> 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.

Cheers,
Eric

Justin Lilly

unread,
Feb 6, 2010, 11:06:25 PM2/6/10
to django-d...@googlegroups.com
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)

Idan Gazit

unread,
Feb 7, 2010, 2:04:10 AM2/7/10
to Django developers
Responses inline.

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.

-I

Idan Gazit

unread,
Feb 7, 2010, 2:17:39 AM2/7/10
to Django developers

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.

-I

patrickk

unread,
Feb 7, 2010, 6:53:10 AM2/7/10
to Django developers
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

Russell Keith-Magee

unread,
Feb 7, 2010, 8:18:12 AM2/7/10
to django-d...@googlegroups.com
On Sun, Feb 7, 2010 at 9:11 AM, je...@jeffcroft.com <je...@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 :-)

Yours,
Russ Magee %-)

Robert Pogorzelski

unread,
Feb 7, 2010, 3:48:58 AM2/7/10
to Django developers
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.

Robert

jsmullyan

unread,
Feb 7, 2010, 10:28:36 AM2/7/10
to Django developers
There may be good reasons for a Design Czar long term, or at least a
User Experience Czar, in guiding the development of the admin
application. But it seems to me that this is too large a solution for
the current bottleneck, and perhaps more modest solutions should be
considered as well.

If the admin application were designed for skinability, which would be
some work, but which I believe could be done by a non-designer with
input from various designers as they attempt to write skins, would a
Design Czar really be necessary? Those changes would not need to
change the current appearance of the admin significantly -- only its
implementation.

There is knowledge out there of what work needs to be done. I know
that the grappelli project has uncovered a lot of the existing
obstacles to writing a skin; if they were able to contribute patches
to remove those obstacles, every designer out there working on django
projects would be empowered to be his/her own Czar. Which is how it
should be.

Cheers,

Jacob Smullyan

On Feb 6, 5:03 pm, Idan Gazit <i...@pixane.com> wrote:
> Hey folks,
>
> Splitting off fromhttp://groups.google.com/group/django-developers/browse_thread/thread...,

je...@jeffcroft.com

unread,
Feb 7, 2010, 12:52:50 PM2/7/10
to Django developers
Several responses:

> 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).

h3

unread,
Feb 7, 2010, 1:34:58 PM2/7/10
to Django developers
> 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 ?

Regards,


--

Maxime Haineault
Consultant Web / Associé

∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822

On Feb 6, 7: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...,

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

jsmullyan

unread,
Feb 7, 2010, 1:37:44 PM2/7/10
to Django developers
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.

My two cents,

Jacob S.

jsmullyan

unread,
Feb 7, 2010, 1:41:27 PM2/7/10
to Django developers
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.

h3

unread,
Feb 7, 2010, 1:51:52 PM2/7/10
to Django developers
> 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.

[0] http://groups.google.com/group/django-grappelli/browse_thread/thread/cf5a1ebfdf4d0370

regards,

--

Maxime Haineault
Consultant Web / Associé

je...@jeffcroft.com

unread,
Feb 7, 2010, 2:04:10 PM2/7/10
to Django developers
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.

je...@jeffcroft.com

unread,
Feb 7, 2010, 2:17:53 PM2/7/10
to Django developers
> 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).

je...@jeffcroft.com

unread,
Feb 7, 2010, 2:18:33 PM2/7/10
to Django developers
Yep, I think we are mostly in agreement, we just have different areas
of personal interest and passion within the "design for django"
realm. :)

Idan Gazit

unread,
Feb 7, 2010, 4:10:40 PM2/7/10
to Django developers
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.

-I

je...@jeffcroft.com

unread,
Feb 7, 2010, 4:58:27 PM2/7/10
to Django developers
You're right, Idan. Sorry if I steered it off-track! I sent Wilson a
message asking him to check out this thread.

> 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.

I think we first need to make sure we ARE going forward with this
whole "design czar" idea. Neither Alex nor Russ sounded particularly
keen on the idea (saying basically, "what's wrong with our existing
process?"), so I think we've got to have buy-in on the whole idea
before we can go about figuring out how to pick a person or team.

> 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).

I think you're probably right, here.

Idan Gazit

unread,
Feb 7, 2010, 5:25:03 PM2/7/10
to Django developers

On Feb 7, 11:58 pm, "j...@jeffcroft.com" <j...@jeffcroft.com> wrote:
> You're right, Idan. Sorry if I steered it off-track! I sent Wilson a
> message asking him to check out this thread.

Awesome, thanks!

> I think we first need to make sure we ARE going forward with this
> whole "design czar" idea. Neither Alex nor Russ sounded particularly
> keen on the idea (saying basically, "what's wrong with our existing
> process?"), so I think we've got to have buy-in on the whole idea
> before we can go about figuring out how to pick a person or team.

Correct, hence my call for more core devs to chime in.

I understand a default position of skepticism from Alex/Russ. It
doesn't sound like anybody tried to approach this subject with the
requisite amount of professional rigor, or maybe it was one of those
things that stayed low on the priority list because nobody
demonstrated sufficient critical mass/interest. I suspect that now
might be the right time to give some attention to this part of the
framework. Part of allaying the concerns of the core devs is
demonstrating that we care enough about this to not lose interest when
a core dev says "meh".

I'm not advocating harassing the devs, but I do think that doing a
little speculative homework and coming up with a rough plan will go a
long way towards demonstrating that this isn't a fickle flight of
fancy, but something we really think deserves consideration. I'm
hoping that Alex/Russ will warm to the idea once a little meat is
hanging on the bones of the thing.

-I

Robert Coup

unread,
Feb 7, 2010, 5:49:06 PM2/7/10
to django-d...@googlegroups.com
I think it's important to be clear here - I envisage a design czar to
act like a code committer:
- encourage, review, and shepherd work to completion
- assess different approaches to problems, and decide if necessary
- get minor improvements and fixes make into trunk
- make sure there's work happening with each release
- do some of it

But more importantly, they need to have an overall view:
- answering the "do we even *want* to do this?" questions for design
- advocating for design within the community and core team
- overseeing the design and usability of the website, docs, branding,
and anything else
- making designers feel valued, and figuring out better ways for them
to contribute
- looking at how we could make Django easier for designers via code -
eg. improving the templating system, HTML5 vs XHTML vs HTML4,
accessibility, mobile UIs, establishing conventions for CSS. These are
often *coding* issues which need a design advocate or need designers
views.

I think this distinguishes between a "core designer" (aka. they do all
the design work) from a "design czar" (or czars, over time), who make
sure the design process happens in Django.

Rob :)

Tai Lee

unread,
Feb 7, 2010, 6:16:34 PM2/7/10
to Django developers
It feels like a catch 22 situation. We need someone to champion and
shepherd design changes into trunk, but we can't assign such a role to
somebody who hasn't met the criteria that each core committer must
meet. To quote the Django documentation, any design czar or core
designer should have "a long history of contributions to Django's
codebase, a solid track record of being polite and helpful on the
mailing lists, and a proven desire to dedicate serious time to
Django's development."

At the same time, everybody agrees that design by committee simply
does not work.

But what's stopping people from re-designing the admin outside of
django as a standalone app (e.g. grapelli), at least to begin with,
and if/when they run into issues that can only be solved by improving
or changing Django internals, raise proposals to make those changes?

If/when such an application has gained enough momentum and has
demonstrated that the people involved are committed to it, invite them
to roll those changes into Django trunk, or invite them to suggest
changes that can be made to Django internals that will further aid
design changes, or offer them a design czar position independent of
their standalone app, so that they might encourage others to
contribute design changes to Django?

I agree that the design czar need not necessarily be a rock star
designer who needs to re-design everything himself (or herself). But
he or she must have a firm grasp on interface design and be familiar
with and to the Django community. I've not noticed many people who fit
the bill on the mailing lists, but from the recent discussions it
seems to me that Jeff Croft has the interface design experience, is
active in the design community and counts as his peers several other
great designers, is familiar with and to the Django community, and has
been passionate in exposing these issues and trying to improve Django
and make designers more welcome and able to contribute.

He'd get my vote as a champion of these issues, and I think he'd do a
good job of reviewing design contributions, suggesting changes to
Django internals that will help increase design contributions,
encouraging good interface design rather than bike shed aesthetic
contributions, without needing to do the design work himself (which he
has indicated he might not be inclined to do).

Cheers.
Tai.

Russell Keith-Magee

unread,
Feb 7, 2010, 9:49:02 PM2/7/10
to django-d...@googlegroups.com
On Mon, Feb 8, 2010 at 6:25 AM, Idan Gazit <id...@pixane.com> wrote:
>
> On Feb 7, 11:58 pm, "j...@jeffcroft.com" <j...@jeffcroft.com> wrote:
>> You're right, Idan. Sorry if I steered it off-track! I sent Wilson a
>> message asking him to check out this thread.
>
> Awesome, thanks!
>
>> I think we first need to make sure we ARE going forward with this
>> whole "design czar" idea. Neither Alex nor Russ sounded particularly
>> keen on the idea (saying basically, "what's wrong with our existing
>> process?"), so I think we've got to have buy-in on the whole idea
>> before we can go about figuring out how to pick a person or team.
>
> Correct, hence my call for more core devs to chime in.

My point was that I don't think there is anything fundamentally
different between what we have now, and what is being proposed. We
already have a design czar -- Wilson -- we just haven't called him
that historically.

The problem is that he hasn't been particularly active recently. If
Wilson isn't willing or able to put in the time necessary to discharge
his duties, then we need to find someone new for the role. Preferably,
we would gain a couple of someones (in whatever reporting/authority
arrangement works in a design context) in order to avoid this problem
arising again.

> I understand a default position of skepticism from Alex/Russ. It
> doesn't sound like anybody tried to approach this subject with the
> requisite amount of professional rigor, or maybe it was one of those
> things that stayed low on the priority list because nobody
> demonstrated sufficient critical mass/interest. I  suspect that now
> might be the right time to give some attention to this part of the
> framework. Part of allaying the concerns of the core devs is
> demonstrating that we care enough about this to not lose interest when
> a core dev says "meh".

It's important to understand the source of the "meh".

I don't think the admin visual/UX staleness problem is "meh" at all. I
agree (and I don't think you'd get any disagreement from anyone in the
core) that the visual/UX aspects of admin would benefit from some
love. At a superficial level, there's lots of room for improvement in
the CSS and JavaScript code base (to give both a visual refresh, and a
technical cleanup). At a deeper level, there is plenty of room for
improvement in the UX of the admin itself.

The "meh" is for the suggestion that we simply *appoint* a new design
czar. Despite the best of intentions of the individuals involved,
Django has a history of this approach failing. Our SVN attic is full
of examples of people that offered to help out, were given commit
access, and then disappeared (in the case of branches like
schema-evolution-ng, almost immediately after they got commit access).
The outcome that I want to avoid at all costs is going through the
process of choosing and appointing a new Czar, and then having that
new Czar fail to fill the gap that we have.

Again, this isn't a statement of blame -- I'm sure the people involved
had the best of intentions, and fully intended to follow through, but
life got in the way of what is, ultimately, a volunteer project. It's
simply a statement of a reality that needs to be taken into account.

As Alex pointed out, the strength of the existing process is that it
is meritocratic. However, that merit is more than just a measure of
technical capability. It's also a measure of a demonstrated ability to
commit the time necessary over the long term. Our existing process
works really well -- as long as there is someone active at the helm.
The issue is that we don't have such a person (at present), and the
existing process doesn't bootstrap itself. If it turns out we need a
new design Czar, I want to make sure we don't lose sight of the goals
and strengths of the existing process.

Yours,
Russ Magee %-)

je...@jeffcroft.com

unread,
Feb 7, 2010, 11:13:19 PM2/7/10
to Django developers
I agree with you completely, Russ, and I have reason to believe
someone worthy will be at the helm. Stay tuned. :)

On Feb 7, 6:49 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:

je...@jeffcroft.com

unread,
Feb 7, 2010, 11:17:08 PM2/7/10
to Django developers
Thanks for the nod, Tai. I'd have to put some consideration into
whether or not I wanted to accept the responsibility if it were
offered to me, but I certainly appreciate the "nomination!" :)

Just to quickly respond to this:

> But what's stopping people from re-designing the admin outside of
> django as a standalone app (e.g. grapelli), at least to begin with,
> and if/when they run into issues that can only be solved by improving
> or changing Django internals, raise proposals to make those changes?

I think the main problem with this is that many of the best designers
in our community don't feel as though they're capable of building such
an app. To use myself as an example, I certainly feel comfortable
building a lot of things in Django, but I don't think I'd be able to
build something as complex as the admin app, especially one that would
meet the stringent code expectations our core team would (rightfully)
have.

My point is that whatever process we have for including designers as
contributors shouldn't require them to also be programmers -- because
usually, they're not.

Wilson

unread,
Feb 8, 2010, 1:13:09 AM2/8/10
to Django developers
I just discovered this thread today while I was on my way out of town
so I haven't had a chance to formulate a proper response. I'll try to
do that later, but for now I'll just jump in quickly and say that I
think it would be great to have somebody coordinating design
contributions and advocating for their implementation. While I (still)
don't have time to do a lot of the heavy lifting, I'm open to the idea
of taking a more active role along those lines, with a long term goal
of either distributing the responsibility or setting up a system of
succession. If my commit bit and existing relationships can help get
things off the ground, I'm happy to give it a shot and do what I can.

Cheers,
Wilson

je...@jeffcroft.com

unread,
Feb 8, 2010, 1:34:34 AM2/8/10
to Django developers
So, unless anyone disagrees with the idea that Wilson should have
first dibs on this position, it sounds like we have ourselves a Design
Czar. Or whatever you want to call it. Woot!

h3

unread,
Feb 8, 2010, 8:49:27 AM2/8/10
to Django developers
Good to see you guys are progressing.

I've red lots of interesting and valid input, but from what I can see
there is tearing decisions ahead and whoever
will take the design lead will be invariably limited by the current
state of the admin.

If you want to achieve something like we are doing with grappelli,
namely refactoring the dom/layout/design and the JavaScript,
you'll have no other choice than to break backward compatibility.
That's not just a "new feature", that's a deep refactoring.

For that reason I think it would make sense to use the same strategy
than with forms, using a ephemeral namespace (something
like newadmin?) for the development/transition time.

Just my 2¢

--

Maxime Haineault
Consultant Web / Associé

hcarvalhoalves

unread,
Feb 8, 2010, 9:14:29 AM2/8/10
to Django developers

Just one idea: why not start promoting discussion on the design
related issues you want to fix (e.g., a better customizable admin),
and see the people who jump aboard? I'm pretty sure there are design-
inclined people working with Django, and they can come up with
complete solutions.

I think it's more reasonable to choose a "core designer" after you get
some interaction with people actually working, instead of trying to
point someone, and only then, start working. Isn't it the way
contributions happen anyway?

Just an idea.

PS: I would gladly work on improving the design of some Django parts,
and developing for others.

Russell Keith-Magee

unread,
Feb 8, 2010, 10:05:40 AM2/8/10
to django-d...@googlegroups.com
On Mon, Feb 8, 2010 at 2:34 PM, je...@jeffcroft.com <je...@jeffcroft.com> wrote:
> So, unless anyone disagrees with the idea that Wilson should have
> first dibs on this position, it sounds like we have ourselves a Design
> Czar. Or whatever you want to call it. Woot!

I, for one, welcome our new (erm... old) Design Overlord. :-)

Russ %-)

je...@jeffcroft.com

unread,
Feb 8, 2010, 1:28:48 PM2/8/10
to Django developers
Wait, does this mean we can't change designs just to wash the Wilson
out of them? :)

On Feb 8, 7:05 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote:

Idan Gazit

unread,
Feb 8, 2010, 3:57:41 PM2/8/10
to Django developers
Hey Wilson, I'm sure I'm not the only one who is delighted that you
have some cycles to spare for Django. :)

As this thread was about practical matters, I'd say the next step is
deciding on a few things that we want to get done. Up at the top, I
suggested setting out a few modest goals for 1.3 as a good place to
start, with the assumption that by 1.4 the process would be self-
perpetuating.

1. Do you have any such modest ideas that you'd like to see tackled as
a means of jumpstarting design work within django?

2. Is there a particular process you think will be best for fielding
these ideas from the community? If we use trac to field/keep track of
these requests like every other, do we create a new component?

A new component in trac doesn't sit well with me -- what would we name
it? "Designer Needs?" What I'm trying to get at is that designers
needs are not all visual, and our needs tend to cut across component
lines. Take the following three examples:

* Joe wants to improve an aspect of the admin's usability. How do we
see Joe's ticket as a design request separately from bugs in how the
admin gathers data to render the recent changes list (which is not
design-related)?

* Amy is exasperated from expressing simple display logic in a rat's
nest of endifnotequals tags. She has an idea for a "smart if" tag, and
lodges an enhancement ticket under the component "Template system".
How do we identify her ticket as being design-motivated?

* Ben is a technically-minded designer who has some good ideas for
improving django's treatment of static media. He goes to file a
ticket, but is unable to choose a good component. He sees a component
labeled "Visual Design," but doesn't choose it because while his
request represents the needs of designers, there's nothing visual
about it.

To be clear: I don't think design tickets need to be treated in any
special manner, just easily identifiable in some way.

I'm sure there's more to be worked out but my brain isn't really there
at the moment. More when it gets back on track.

-I

je...@jeffcroft.com

unread,
Feb 8, 2010, 4:42:41 PM2/8/10
to Django developers
I do totally agree with Idan that often times designers needs don't
have anything to do with design itself, and that designers may want to
contribute by telling us how the parts of the framework they touch
could be changed to make their lives easier.

One way I think design proposals/tickets need to be treated
differently than other stuff is that there shouldn't be this, "sure,
great idea, go build it and get back to us" attitude involved. The
world's best designers don't tend to also be programmers, and by
making them feel as though if they can't build it, then they're of no
use to us is to turn away potentially great input from really smart
people. A designer ought to be able to say, "It'd be really useful to
me if the 'if' tag supported basic operators, and I'd be happy to help
someone understand the needs of designers with regard to it, but I'm
not capable of building it myself," and have that be taken seriously.
To date, I don't think it has been -- usually these ideas are turned
away with an assholish "PATCHES WELCOME" and not much else.

I think the Django community needs to better respect the fact that
just because someone can't SOLVE a problem themselves doesn't mean
they're not able to IDENTIFY one.

Jeremy Dunck

unread,
Feb 8, 2010, 5:00:00 PM2/8/10
to django-d...@googlegroups.com
On Mon, Feb 8, 2010 at 3:42 PM, je...@jeffcroft.com <je...@jeffcroft.com> wrote:
...

> One way I think design proposals/tickets need to be treated
> differently than other stuff is that there shouldn't be this, "sure,
> great idea, go build it and get back to us" attitude involved.

I agree with your general point, which I interpret to mean: ideas are
useful, even without code, and designers specialize, often to the
exclusion of coding. Unfortunately, unless the person filing the
request/ticket makes it clear that their request isn't something they
can personally fulfill, it's hard to tell the difference between a
person being lazy (i.e. wishing for a pony) and a person asking for
assistance (i.e. a designer asking for a smart if tag).

It's an important distinction. At the same time, it is also important
to recognize the difference between being ignored and being in a long,
difficult to prioritize, line.

...


> I think the Django community needs to better respect the fact that
> just because someone can't SOLVE a problem themselves doesn't mean
> they're not able to IDENTIFY one.

I think "patches welcome" does presuppose that anyone with the proper
time and attention could fill their own needs, and that's generally
been a correct assumption. Open source is built on sharing code, and
sometimes it's hard to judge whether an idea is good or not without
seeing an implementation.

I guess I'd just ask that when you feel coders are being unfair just
call it when you see it. Start with the assumption that we mean well
and maybe don't see where you're coming from, like Russ with the
contest idea. :-)

All that said, developers everywhere have some amount of
not-invented-here syndrome, and they have ideas, too. Often, they'll
work on their ideas rather than look for someone else's. Since we're
all volunteer, it's not appropriate to tell people what they should or
shouldn't work on. So I think designers proposing ideas (but not
providing code) are inherently at a disadvantage.

I imagine that there's enough overlap between designers who can code a
bit and developers who can design a bit to get together and make
progress. We just have to try it and see how it goes.

Wilson

unread,
Feb 8, 2010, 5:00:34 PM2/8/10
to Django developers
In my experience, Trac (or any bug tracker) isn't a good place to deal
with design issues, at least until they've reached the point where
they're concrete and actionable specs. On the other end, I don't think
we're quite far enough along yet to be able to deal with "design
tickets" yet, but that's something that will need to be addressed as a
process evolves.

I've started a stub of a wiki page that anyone who's interested can
start to share and collect ideas that require design work or input.

http://code.djangoproject.com/wiki/DjangoDesign

As the input outgrows the wiki page, or as individual proposals become
actionable, we'll adapt from there.

Jeremy Dunck

unread,
Feb 8, 2010, 5:11:26 PM2/8/10
to django-d...@googlegroups.com
On Mon, Feb 8, 2010 at 4:00 PM, Wilson <wmi...@gmail.com> wrote:
> I've started a stub of a wiki page that anyone who's interested can
> start to share and collect ideas that require design work or input.
>
> http://code.djangoproject.com/wiki/DjangoDesign
>
> As the input outgrows the wiki page, or as individual proposals become
> actionable, we'll adapt from there.

There were a bunch of partially-done items in the admin-ui branch:
http://code.djangoproject.com/wiki/soc2009-admin-ui
http://groups.google.com/group/django-developers/browse_thread/thread/1edf77c9c8b1101d/4ecda5e4c982c7e1?pli=1

I don't have time to garden that into the wiki page, but perhaps
someone else would like to.

je...@jeffcroft.com

unread,
Feb 8, 2010, 5:25:29 PM2/8/10
to Django developers
Unfortunately, unless the person filing the
> request/ticket makes it clear that their request isn't something they
> can personally fulfill, it's hard to tell the difference between a
> person being lazy (i.e. wishing for a pony) and a person asking for
> assistance (i.e. a designer asking for a smart if tag).

I get that. At the same time, it's important to recognize that
Django's always been built around this ideas that designers and front-
end folks ought to be able to do their job (templates/html/css/etc.)
without having to know or understand Python. That was a core tenant
when Adrian and company built the thing in 2005, and I believe it
still is. It's also the way Django's biggest market (journalism) works
more often than not.

What this says to me is that designers and front-end developers *are*
part of Django's target audience. So the concept that, "sorry,
Django's a Python framework, so if you don't know Python, it's not for
you" doesn't really apply, here (though I have definitely heard it
said).

So we expect designers and front-end coders to use Django (or at least
parts of it). If they're using it on a day-to-day basis, they're bound
to have frustrations, ideas, suggestions, and thoughts about how it
could work better for them. You can blow it off as a "pony" or "being
lazy", but to them, it's just something that would make their life
easier that they don't have the know-how to implement themselves.

> I think "patches welcome" does presuppose that anyone with the proper
> time and attention could fill their own needs, and that's generally
> been a correct assumption.  Open source is built on sharing code, and
> sometimes it's hard to judge whether an idea is good or not without
> seeing an implementation.

That makes sense, but the problem is that if designers needs aren't
considered because they can't provide an implementation, and no one
else is willing to provide one for them, then the needs never get
addressed, which leads to a feeling of being ignored. It's a catch 22.
In a bit of irony, I don't know what the answer is, but I certainly am
capable of recognizing that this is a problem.

I'd also make a case that designers are really great at helping design
the APIs they'll use, and maybe they ought to be asked about the
syntax for your template tag or the output of your form field widget.
I think designers can make a lot of useful contributions that don't
involve writing code OR providing graphic design comps and mockups. I
hope developers will realize we're here and willing to contribute in
whatever way our design eye can be useful, and not just think of us as
people who make the admin pretty.

> I guess I'd just ask that when you feel coders are being unfair just
> call it when you see it.  Start with the assumption that we mean well
> and maybe don't see where you're coming from, like Russ with the
> contest idea.  :-)

Makes sense. I definitely believe thats where you guys are coming
from, now.

> All that said, developers everywhere have some amount of
> not-invented-here syndrome, and they have ideas, too.  Often, they'll
> work on their ideas rather than look for someone else's.   Since we're
> all volunteer, it's not appropriate to tell people what they should or
> shouldn't work on.  So I think designers proposing ideas (but not
> providing code) are inherently at a disadvantage.

That makes perfect sense, and I completely agree that we can't tell
people what they should or shouldn't work on. Designers probably ARE
at a disadvantage, but maybe if we have Wilson keeping track of the
needs of designers, he can help advocate to you developers for the
ones which are most-requested and most-useful. And there definitely
are a group of us designers that know and understand the entire Django
stack pretty well, and are at least able to communicate with a
developer and speak the same language. I do as much back-end work as
front-end in Django these days, and I'm excited to find an opportunity
to actually provide implementations for some of the designers needs.
I'm sure I'm not the only one.

> I imagine that there's enough overlap between designers who can code a
> bit and developers who can design a bit to get together and make
> progress.  We just have to try it and see how it goes.

Agreed. Hopefully this whole discussion has brought to light some of
the issues standing in the way of progress on design in Django and
designer's Django needs.

Jacob Kaplan-Moss

unread,
Feb 8, 2010, 7:08:28 PM2/8/10
to django-d...@googlegroups.com
On Mon, Feb 8, 2010 at 3:42 PM, je...@jeffcroft.com <je...@jeffcroft.com> wrote:
> A designer ought to be able to say, "It'd be really useful to
> me if the 'if' tag supported basic operators, and I'd be happy to help
> someone understand the needs of designers with regard to it, but I'm
> not capable of building it myself," and have that be taken seriously.

Just as a point of order, this is *exactly* what happened with the
smart if tag: I was against it, and then designers told me to STFU,
and I did.

Of course, as a general principle, Jeff's completely right that we
need to be doing a better job listening to the things designers need
from us. We did that very well early-on, and it helped Django become
better.

Jacob

Wolf Halton

unread,
Feb 8, 2010, 8:54:16 PM2/8/10
to django-d...@googlegroups.com

I would be willing to give this wiki-gardening a try. Not as a Dev, but merely an enthusiast

sent from the research lab at http://networksecuritynews.net

On Feb 8, 2010 5:11 PM, "Jeremy Dunck" <jdu...@gmail.com> wrote:

On Mon, Feb 8, 2010 at 4:00 PM, Wilson <wmi...@gmail.com> wrote:

> I've started a stub of a wiki pag...

There were a bunch of partially-done items in the admin-ui branch:
http://code.djangoproject.com/wiki/soc2009-admin-ui
http://groups.google.com/group/django-developers/browse_thread/thread/1edf77c9c8b1101d/4ecda5e4c982c7e1?pli=1

I don't have time to garden that into the wiki page, but perhaps
someone else would like to.


--
You received this message because you are subscribed to the Google Groups "Django developers" g...

andybak

unread,
Feb 8, 2010, 9:44:48 PM2/8/10
to Django developers
This is all very timely. Myself and my friend Harry Brignull (who runs
the UX blog http://www.90percentofeverything.com ) have been talking
for a while about the idea of doing some formal usability testing on
the Django admin and this might prove to be the catalyst.

I'll put together our plan and post something on this list to get some
feedback before we go ahead.

The basic plan is to test with non-technical volunteers to try and
indentify some of the areas that might not be immediately intuitive. I
plan to use a simple CRM app as the test case but I'm open to any
better suggestions. Basically a simple app that exercises most of the
interaction types in the contrib.admin

Andy
________________

ixxy.co.uk

PauloS

unread,
Feb 10, 2010, 5:41:54 AM2/10/10
to Django developers
Currently it is easy to change the template engine in a Django
project, but if you change the ORM layer you lost the whole Admin
thing, the very app that made Django so special.

If we are talking about refactoring Admin code (not only html/css
stuff), do you guys think it can be more decoupled from Django ORM?

Is it possible to design some abstraction middleware to loose the bond
between admin and Django ORM?

Regards,
--
Paulo

Richard Laager

unread,
Feb 10, 2010, 6:08:04 AM2/10/10
to django-d...@googlegroups.com
On Wed, 2010-02-10 at 02:41 -0800, PauloS wrote:
> If we are talking about refactoring Admin code (not only html/css
> stuff), do you guys think it can be more decoupled from Django ORM?

How so?

> Is it possible to design some abstraction middleware to loose the bond
> between admin and Django ORM?

To what end?

What are you trying to accomplish?

Richard

signature.asc

Russell Keith-Magee

unread,
Feb 10, 2010, 6:13:23 AM2/10/10
to django-d...@googlegroups.com

Is it possible - almost certainly. After all, you can do anything if
you write enough code.

However, it's not going to be easy. Django's Admin works by exploiting
metadata that the ORM provides. Replacing that metadata source is not
going to be a trivial activity.

If you want this, *you're* going to have to investigate what changes
are required.

Proposing that Django adopt a complex abstraction layer to keep from
using it's own internal facilities is going to be a hard sell. An
approach more likely to succeed is an abstraction layer that lets
MyFavouriteORM look like enough like Django's ORM to fool the Admin.
Such a tool wouldn't even need to live in Django's core - it could
easily live as an external project.

So - in summary: It's possibly possible. You're going to have to do
the heavy lifting to find out the details. If you can make a concrete
proposal that doesn't involve completely rearchitecting Django, we'll
consider it.

Yours,
Russ Magee %-)

step

unread,
Feb 11, 2010, 3:17:59 PM2/11/10
to Django developers

Victor Hooi

unread,
Jun 27, 2011, 3:10:47 AM6/27/11
to django-d...@googlegroups.com
heya,

Sorry to resuscitate an old thread, but I was just wondering if there was any update on this? Was somebody made the Django design czar? Or is there any word on the Django admin redesign front? (https://groups.google.com/d/topic/django-developers/yk8m1haSF1M/discussion)

As an outsider looking in, it'd be awesome to get some updates out to the community on this sort of thing =).

Whilst I agree you shouldn't just fix something for the sake of it, I think there were good arguments raised in the other thread for at least making design a priority within Django, and an area of active work/improvement.

Cheers,
Victor

Daniel Moisset

unread,
Jun 27, 2011, 6:51:33 AM6/27/11
to django-d...@googlegroups.com
On Mon, Jun 27, 2011 at 4:10 AM, Victor Hooi <victo...@gmail.com> wrote:
> heya,
> Sorry to resuscitate an old thread, but I was just wondering if there was
> any update on this? Was somebody made the Django design czar? Or is there
> any word on the Django admin redesign front?
> (https://groups.google.com/d/topic/django-developers/yk8m1haSF1M/discussion)

Yes, Idan Gazit is the BDFL (Benevelon Designer For Life)

https://groups.google.com/d/topic/django-developers/qUrDZMoihrc/discussion

Regards,
D.

Kenneth Gonsalves

unread,
Jun 28, 2011, 7:01:56 AM6/28/11
to django-d...@googlegroups.com
On Mon, 2011-06-27 at 00:10 -0700, Victor Hooi wrote:
> Was somebody made the Django design czar?

yes - Idan Gazit
--
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

Victor Hooi

unread,
Jul 1, 2011, 1:07:39 AM7/1/11
to django-d...@googlegroups.com
heya,

Aha, excellent stuff. I must have missed that thread.

Belated congrats to Idan =).

Where is the best place to find out what's happening on the design side of things in Django?

Haven't really heard much about it, Idan's blog (http://blog.gazit.me/) and Twitter (http://twitter.com/#!/idangazit), and my google-fu doesn't seem strong enough to turn anything else up.

Has there been any recent news?

Cheers,
Victor

Jacob Kaplan-Moss

unread,
Jul 1, 2011, 12:39:09 PM7/1/11
to django-d...@googlegroups.com
On Fri, Jul 1, 2011 at 12:07 AM, Victor Hooi <victo...@gmail.com> wrote:
> Has there been any recent news?

If you watch the commit timeline
(https://code.djangoproject.com/timeline) you might have seen a
handful of UI cleanups that've done in over the past few months;
Idan's contributed to those. I can't recall 'em all off the top of my
head, but one example is the multi-column sorting in the admin now on
trunk.

There's also some... stuff... going on behind the scenes I'd rather
not talk about just yet. Not because it's confidential or anything,
but because I'm superstitious and don't like talking about plans until
they're actually implemented.

Jacob

Idan Gazit

unread,
Jul 5, 2011, 4:58:13 AM7/5/11
to django-d...@googlegroups.com
Hey Victor,

So far, only small steps -- my time hasn't provided for any thing "major" yet. :)

My twitter will be a good place, as will this list. Right now, my head is mainly in helping out with a couple of specific issues (formrendering, admin sorting). There are some plans underway to provide better places to get involved/contribbute if you're into that sort of thing, as well as tracking progress of contributions that aren't easily quantifiable like code.

Cheers!

-I
Reply all
Reply to author
Forward
0 new messages