Django Design Czar
Idan Gazit
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
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
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
> 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
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
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
> 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
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
> 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
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
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
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
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
>> 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
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
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
> 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
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
> 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
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
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é
∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822
je...@jeffcroft.com
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
> 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
of personal interest and passion within the "design for django"
realm. :)
Idan Gazit
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
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
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
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
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
>
> 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
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
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
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
first dibs on this position, it sounds like we have ourselves a Design
Czar. Or whatever you want to call it. Woot!
h3
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é
∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822
