Benevolent Dicta^H^H^H Designer for Life
Idan Gazit
And lo, the core team spake amongst themselves, crying: "Who shall
take up the mantle of designer among us? Wilson departed many moons
ago for the land of Rdio, and the people cry out for one to provide
succour to those who want a more beautiful Django, and yea, a Django
that listens to their needs."
-- The book of Django, 22:4
====
Recently, I was approached by the core team about joining them to help
address design issues within Django. I'm excited to announce that I've
accepted!
I've long felt that one of Django's greatest assets was Wilson's
involvement early in the development of Django. It led to a sensible
separation between the concerns of python and frontend developers, a
template language that is (warts and all) a pleasure to use, and an
admin interface which was light-years ahead of its time.
In the same way that good documentation and tests emit a pleasing
smell for passing developers, these features make Django pleasing for
designers because they broadcast a message: "your needs are
anticipated; your kind is welcome here."
Sadly, Wilson is super-busy, and Django hasn't had an in-house
designer advocate in a while. From now on, that's me! I'm here to
shepherd efforts touching on UI/UX issues with Django, solicit
feedback, engage designers, and break up bikeshedding whenever it
stands in the way of Getting Things Done.
High-Level Goals
================
1. Figuring out how to best hear the needs of designers in our
community, and advocating for solutions which address those needs
inside Django.
2. Figuring out how to attract a community of design-oriented
contributors to Django.
Right now, contributing to Django is really about contributing _code_
to Django; everything from the tools to the process are geared towards
the sensibilities of developers. I'd like to find a system that will
facilitate the collection of feedback from the community of designers
using Django.
Furthermore, there's no reason why we can't foster a vibrant community
of designer contributors alongside the existing code contributors.
This is an opportunity for Django to lead the way in showing that the
efforts of designers are welcome (and sorely needed) in the open-
source world.
Some Practical Tasks
====================
The Admin
---------
The most obvious user-facing aspect of Django is the admin. It is
getting long in the tooth, and I've been witness to several fruitless
attempts to initiate a refactor.
The truth is that the admin is a relatively large chunk of code which
(in the main) "just works". Simply ignoring it while starting a
ground-up rewrite is a recipe for two failures. Incremental
improvements and bugfixes are the way forward on this. A fresh coat of
paint for the admin could count as an incremental, though cosmetic,
improvement.
That being said, it's time to start considering what a rethought admin
might look like -- less in terms of visual look'n'feel, more in terms
of what audience the admin serves, what use-cases it should try to
address, and how best to serve that audience and those use-cases. I
have some thoughts on the matter (which I'll share in a separate
thread), but this is an opportunity to get UI and UX contributors to
the table. Whether and how to rewrite the admin is a decision we can
only make after we have a good idea of where we want to go.
To that end, I'll be setting up some tools for collecting feedback
over the next few days, and will announce them here. Learning from
existing efforts in this space (Grappelli and django-admin-tools
spring to mind) is a pretty good place to start.
Finally, I'm skepctical that a "newadmin" can be realistically
completed in the 1.4 timespan. With the exception of incremental
improvements, the newadmin process is a long-term thing, which means
we need to think about how it can be developed without interfering
with Django's release cycle.
Forms
-----
Another topic ripe for some love is Django's forms API; it is an area
where the bright line between Python and frontend code gets blurry.
Form widgets are a good example of this: their HTML is hardcoded in a
Python file, replacing them requires writing more Python, and they
default to XHTML-style tags, causing conflicts for sites with non-
XHTML DOCTYPEs.
I'd like to make this a goal for 1.4; there are already some great
developments in this space:
*
http://groups.google.com/group/django-developers/browse_thread/thread/7cc4279367c0a3f0
* https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas
Endnote
=======
This is a beginning; obviously the list of issues I haven't written
about eclipses those above. Take this opportunity to get your
wishlists in order.
If you've got a relevant project that I've neglected to mention, don't
get upset. Keep an eye on the -dev mailinglist for announcement of
resources we'll be using to track existing code and new ideas.
Finally, if you know of somebody that might be interested in
contributing to Django in a design capacity, please spread the word!
Cheers,
Idan
Jacob Kaplan-Moss
Thanks for the intro, Idan!
I thought I'd just fill in a few things from my point of view and give
a bit of background to this:
It turned out that quite a group of core devs ended up coming to PyCon
a couple weeks ago so we ended up having an impromptu lunch and
meeting. One of the topics that came up was the role of design and
designers within the Django community. We talked about the fact
there's been some frustration lately over our general lack of motion
on UI/UX issues. Adrian pointed out that one of Django's long-standing
principles has been that design is fundamentally something that
doesn't work the same was as open source: many eyes may make for
shallow bugs, but many hands make for shitty design. So from the very
beginning we treated design differently and let one person, Wilson, be
in charge.
Of course, Wilson had to go and join a startup* that got successful.
Stupid success. But we all pretty agreed that we still think the model
of having a design BDFL to vest authority on UI/UX issues was a good
model. So we talked about people to fill that role, and Idan was the
unanimous choice. He's been contributing to Django for a while now,
and most of the core developers have worked with him closely in some
capacity or another and all have great things to say about him, his
work, and his aesthetic. Most importantly, Idan is great at listening
to input and criticism, so we feel strongly that he'll be able to take
the design input from the community, digest it, and produce great
work.
I know that generally we try not to operate in a top-down manner --
and most of our other workflow changes over the last few years have
been to *divest* individuals of too much power -- so this may come
across as a bit weird to some. Fair enough: it's a bit weird to me,
too: I wish we could treat design no different than code. But for
whatever reason we've seen time and time again that
design-by-committee doesn't work, so we're going to keep doing things
this way.
So welcome, Idan, and best of luck. I'm really excited to see what happens next!
Jacob
* Rdio, which everyone should use because it's awesome.
varikin
Wim Feijen
Those are two great topics, congratulations to you and to us :) and
good luck!
Wim
Raphael Passini Diniz
--
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.
--
Atenciosamente Raphael Passini Diniz