====
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
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
