I use Django for about a year, do websites for about 5 years, am kind
of experienced in web, interface and techdesign, used lots of CMS or
other site management tools (99% is a piece of crab). And I'm writing
here because although Django admin default look is successive, I think
it has lots of interface related misconceptions and element related
eye-unfriendly problems.
Question is: I can modify templates, css, not so sure about images
that fit well enough, but mainly I can position all the given elements
to date and CSS them as if I was doing and redesigning it for myself.
Is it realy needed and could be implemented to trunk, or everybody
just uses it as is notwithstanding some dirt?
As the most obvious thing - here's the margin/padding problem on the
left/right side of the page. One of a hundreds...
http://farm5.static.flickr.com/4022/4329186446_212477b9e4_o.png
Thnaks ahead.
Design opinions are always welcome, and I'm not going to claim that
Django's admin is perfect. However, please keep in mind that Django's
admin site was originally designed by Wilson Miner, who has quite a
reputation in design circles (as a point of reference - Apple's
website is in his portfolio). I'm sure Wilson would do some things
differently if he redesigned Django's admin site today, but claiming
that the original design has "lots of misconceptions" and
"eye-unfriendly problems" is slightly overstating the situation.
> Question is: I can modify templates, css, not so sure about images
> that fit well enough, but mainly I can position all the given elements
> to date and CSS them as if I was doing and redesigning it for myself.
> Is it realy needed and could be implemented to trunk, or everybody
> just uses it as is notwithstanding some dirt?
>
> As the most obvious thing - here's the margin/padding problem on the
> left/right side of the page. One of a hundreds...
> http://farm5.static.flickr.com/4022/4329186446_212477b9e4_o.png
I'm not necessarily convinced that the margin padding "problem" you
identified is inherently a problem - variations in horizontal
alignment can serve a useful design purpose.
However, that doesn't mean we're going to reject all your proposals,
or that horizontal alignment like you describe couldn't form an
important part of a larger design. Design proposals are always
welcome. If you think you can improve on the visual design of Django's
admin, put together a proposal, and we'll consider it. It doesn't
matter if your proposal takes the form of mockups, or a set of
CSS/markup replacements - as long as we can see and understand the
changes you want to make.
Yours
Russ Magee %-)
As a designer who has been closely associated with the Django project
for over four years, I gotta say: the feeling that no one but Wilson
can contribute to an admin interface redux is a major frustration.
I've talked about it with other great designers who love Django,
including Nathan Borror and Bryan Veloso, and I think I can speak for
all of us when I say we feel as though it's really not worth our time
to propose an update for the admin interface, because if it doesn't
come from Wilson, it won't be taken seriously by the core team.
Every time an update to the admin interface comes up, I hear one of
two arguments against it from core devs, and both of them are, quite
frankly, inaccurate:
1. "Wilson is the admin interface's designer, and he'll update it when
he deems it necessary." -- No, he won't. He's a busy, busy man working
on paying projects and from my discussions with him, I don't believe
he has time for this (although I do believe he would *like* to do it).
2. "The interface was designed by Wilson F'ing Miner of Apple.com fame
and therefore it can not possibly have any UI issues." -- Wilson
himself will be the first person to tell you this isn't true. There
are UI issues. The look is dated. A lot of the template and javascript
code sucks. It was a great piece of interaction design in 2005, but
that was five years ago. Nothing on the web from five years ago is
still awesome by today's standards. Nothing.
The Django admin needs an update, and I think it's high time the core
devs start making other talented designers feel as though if they put
the effort in, their contributions will be seriously considered for
inclusion in Django.
Jeff
On Feb 3, 5:44 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
>I'm not necessarily convinced that the margin padding "problem" you
> As the most obvious thing - here's the margin/padding problem on the
> left/right side of the page. One of a hundreds...
> http://farm5.static.flickr.com/4022/4329186446_212477b9e4_o.png
identified is inherently a problem - variations in horizontal
alignment can serve a useful design purpose.
1. "Wilson Miner is the designer of the Django admin interface, and
he'll redesign it when he deems it necessary." -- First, the idea that
Wilson somehow "owns" the Django admin's design is offensive. It's an
open source project and anyone should be able to contribute and have
their efforts taken seriously. Second, Wilson isn't going to redesign
it. I've talked to him about it several times and while I know he'd
like to, I really don't think he's going to find the time -- if he
was, he would have by know. Because he thinks it needs it. Which leads
me to the second reason...
2. "The Django admin interface was designed by Wilson F'ing Miner of
Apple.com fame, and therefore is immune from ever have any design
problems." -- Look, Wilson is a great designer. Really great. One of
the very best I've ever worked with. But he's not perfect. The Django
admin does, indeed, have a handful of serious interaction design
issues. What's more, in the five years that have passed since Wilson
designed it, IxD has come a long way, and there are many useful new
concepts that could apply to the Django admin interface. When Wilson
designed the admin interface, it was a great piece of interaction
design. But it's been five years, and I don't know about you, but
*nothing* I did five years ago is still awesome. And like I said, I've
discussed it with Wilson on several occasions, and I can confirm that
he definitely agrees there are issues and that it could use and
overhaul and an update. If the core devs refuse to listen to anyone
else who says it has issues, then please, at least listen to Wilson.
I've talked with several designers in the Django community at various
times (among them Nathan Borror and Bryan Veloso), and I think I can
speak for all of us when I say that there's a general feeling that
it's not worth our time to put any effort into a Django admin design
overhaul, because it won't be taken seriously if it doesn't come from
Wilson.
And that sucks.
Jeff
On Feb 3, 5:44 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
I'm sorry if I gave that impression. My comments were intended that
while the admin can certainly be improved, but it isn't "fundamentally
flawed" as the OP seemed to imply, and we will hold a very high
standard to anyone proposing design changes. It was also intended to
point out that "OMFG, the design elements aren't all left aligned"
isn't necessarily an indication of bad design.
> Every time an update to the admin interface comes up, I hear one of
> two arguments against it from core devs, and both of them are, quite
> frankly, inaccurate:
>
> 1. "Wilson is the admin interface's designer, and he'll update it when
> he deems it necessary." -- No, he won't. He's a busy, busy man working
> on paying projects and from my discussions with him, I don't believe
> he has time for this (although I do believe he would *like* to do it).
I completely agree. Unless Wilson is specifically offering a new
design -- and not in an abstract, "oh yeah, I'll do that" kind of way
-- we should make way for someone else.
> 2. "The interface was designed by Wilson F'ing Miner of Apple.com fame
> and therefore it can not possibly have any UI issues." -- Wilson
> himself will be the first person to tell you this isn't true. There
> are UI issues. The look is dated. A lot of the template and javascript
> code sucks. It was a great piece of interaction design in 2005, but
> that was five years ago. Nothing on the web from five years ago is
> still awesome by today's standards. Nothing.
Again, completely agreed.
> The Django admin needs an update, and I think it's high time the core
> devs start making other talented designers feel as though if they put
> the effort in, their contributions will be seriously considered for
> inclusion in Django.
Ok - let me put my cards on the table:
* I'm a member of the core, and I would *love* to see a comprehensive
design refresh of the admin.
* Wilson is *not* the only person that can do the job. Wilson is
certainly welcome to propose a design change, but I think this is a
perfect opportunity for Django to shine the spotlight on the design
talent of others in our community.
* However, the work needs to be done by someone that knows what they
are doing. Wilson's work isn't perfect or irreplaceable by a long
shot, but it does set a high bar. We're not going to change designs
just so we can wash the Wilson out of it.
* This isn't an exercise we're going to repeat every 3 months just
because we can. If we do a design refresh now, I would expect that we
won't do another one for another couple of years.
So, to I'd like to make a proposal. Lets have a competition for a
redesign of the admin + databrowse. We accept proposals to anyone that
wants to make them, and the winner gets their code as the new admin
interface in trunk.
I'm open to suggestions on how to best run the competition; e.g.
* Time frames? It would be nice to put this into 1.2, but I'm not
sure that gives us enough time to do the job properly.
* Do we need to write a formal design brief, or do we just say
"everything the admin currently does, but better"?
* Do we need to do this in phases - e.g., phase one for design
proposals, and then phase two for best execution of the design
proposal we pick?
* Who judges? I'm predisposed to say that the winner should be picked
in the same way that we do feature voting for releases -- binding
votes by the core team, but with input from anyone else that wants to
offer an opinion.
If this works out well, it might turn in to a model we can reuse. The
DSF has some plans that will require some design work. Semi-regular
design competitions might be one way to draw attention to the awesome
design talent in our community.
Comments welcome - from other members of the core and the BDFLs in particular.
Yours,
Russ Magee %-)
I'll try not to feel a-salt-ed... </rimshot> :-)
I was only peripherally aware of Grapelli; from an initial inspection,
it looks good. If this design competition gets off the ground,
Grapelli looks like it might be a great pret-a-porter competition
entry.
It's also a great indication of the separation between views and
templates that Django enforces. Django core's design recalcitrance be
damned - designers *should* be able to contribute media+template packs
that override or enhance Django admin's default look and feel, in the
same way that developers can write and maintain contrib apps external
to the core. If this isn't something that can be done transparently,
then that's a bug that we need to fix.
> Sorry to completely hijack this thread but would django-mobileadmin be
> considered for inclusion to trunk (during the 1.3 timeline)? iPhones and
> other mobile devices are getting pretty prolific and I love having the
> mobile admin site available when I login from my iPhone (which happens
> surprisingly often).
I don't know about mobileadmin specifically, but having good support
for identifying mobile devices sounds like a good addition to contrib.
If we can back that up with a mobile support in the admin, all the
better. Sounds like proposals for 1.3 are already starting :-)
Yours,
Russ Magee %-)
Agree completely.
>> 2. "The interface was designed by Wilson F'ing Miner of Apple.com fame
>> and therefore it can not possibly have any UI issues." -- Wilson
>> himself will be the first person to tell you this isn't true. There
>> are UI issues. The look is dated. A lot of the template and javascript
>> code sucks. It was a great piece of interaction design in 2005, but
>> that was five years ago. Nothing on the web from five years ago is
>> still awesome by today's standards. Nothing.
>
> Again, completely agreed.
>
Ditto (although I still believe the admin has aged exceptionally well).
>> The Django admin needs an update, and I think it's high time the core
>> devs start making other talented designers feel as though if they put
>> the effort in, their contributions will be seriously considered for
>> inclusion in Django.
>
I honestly don't know where this impression comes from. Either I've
missed a long string of messages on this mailing list, or there's
something else going on? There have been many improvements to the
admin-ui over the past releases including, but no limited to:
* admin actions
* list editable
* the GSOC admin-ui work
* readonly fields
While none of these are the comprehensive reform that is being
discussed here, it's should be clear that improvements are always
welcome, but for something large, like a compete refactor, it's going
to be the kind of thing where someone needs to do almost all of the
work themselves. None of Django's core developers are designers, nor
can they necessarily execute someone else's creative vision.
> Ok - let me put my cards on the table:
>
> * I'm a member of the core, and I would *love* to see a comprehensive
> design refresh of the admin.
>
> * Wilson is *not* the only person that can do the job. Wilson is
> certainly welcome to propose a design change, but I think this is a
> perfect opportunity for Django to shine the spotlight on the design
> talent of others in our community.
>
> * However, the work needs to be done by someone that knows what they
> are doing. Wilson's work isn't perfect or irreplaceable by a long
> shot, but it does set a high bar. We're not going to change designs
> just so we can wash the Wilson out of it.
>
> * This isn't an exercise we're going to repeat every 3 months just
> because we can. If we do a design refresh now, I would expect that we
> won't do another one for another couple of years.
>
> So, to I'd like to make a proposal. Lets have a competition for a
> redesign of the admin + databrowse. We accept proposals to anyone that
> wants to make them, and the winner gets their code as the new admin
> interface in trunk.
>
Can we please ignore databrowse, not a single patch has touched that
since 1.0. I don't know what it's future is, but I question whether
anyone gives a damn (and if they do it's certainly not in the way that
people care about the admin).
> I'm open to suggestions on how to best run the competition; e.g.
>
> * Time frames? It would be nice to put this into 1.2, but I'm not
> sure that gives us enough time to do the job properly.
>
No way in hell for 1.2. Even if I thought it was possibly in that
timeframe (which I don't), we had feature voting, it passed, we had a
timeperiod for people to write patches for new features, it passed.
Unless you can argue that a new UI is a "bufix" (it's not), it would
be procedurally absurd for this to land in 1.2.
> * Do we need to write a formal design brief, or do we just say
> "everything the admin currently does, but better"?
>
Everything the admin does, *and* should be ready for the next
generation of admin features (those nifty select inlines, etc.).
Consider that the current templates have had those "Add another <x>"
links commented out for the last 5 years until Jannis landed some of
the admin-ui work, the same standard should be held to any new
potential design, it should be clearly ready for features we know we
want to land (the rest of admin-ui for example).
> * Do we need to do this in phases - e.g., phase one for design
> proposals, and then phase two for best execution of the design
> proposal we pick?
>
That seems reasonable to me, but I'll add the stipulation that any
design proposal must include a commitment to do the implementation,
and must include all of the admin's pages.
> * Who judges? I'm predisposed to say that the winner should be picked
> in the same way that we do feature voting for releases -- binding
> votes by the core team, but with input from anyone else that wants to
> offer an opinion.
>
That seems ok with me, I am slightly concerned about the mismatch
between the voters and the implementors in this case, but I seem no
reasonable alternative.
> If this works out well, it might turn in to a model we can reuse. The
> DSF has some plans that will require some design work. Semi-regular
> design competitions might be one way to draw attention to the awesome
> design talent in our community.
>
> Comments welcome - from other members of the core and the BDFLs in particular.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
>
>
My one question is, just how many designs do we expect? This would be
a fair body of work to take on, I hardly expect a large swath of
people to have the time, skills, and motivation necessary to complete
this task. So let's just put out a call, before the 1.3 voting
process (i.e. from now until then) we want to see your new admin
designs, be they mockups, photoshops, or full HTML/CSS, and see what
falls out (after all despite this entire thread I've seen no concrete
offers from anyone).
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
Why? Not all designers can do cross browser xhtml/css (html5?) or even
django's template language, let alone the admin's unique template
environment.
I'm sure there are a number of CSS gurus in the community who can then
take over, and if there isn't, I'm certain the Django Foundation could
afford to hire one for a reasonable price. I think requiring
implementation would reduce the quality of the submissions.
If there is a competition (which I hope there is!), it would be good
if the submissions were to a clear set of requirements; eg a graphical
design in illustrator/inkscape format of:
* Base template (branding, header, footer, layout etc)
* Login box
* Home page (list of apps and models)
* Change list
* Change detail
* Random content, elements (change password, delete confirmation,
object history, invalid setup, 404 etc)
If backwards compatibility is required, add to that a list of elements
required for each page, based on the existing templates. But then
again, any radically new design can live alongside the old admin for a
time, to allow people to keep their customisations.
Cheers,
Will
On Feb 5, 10:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Sat, Feb 6, 2010 at 1:02 AM, Russell Keith-Magee
>
>
>
>
>
> <freakboy3...@gmail.com> wrote:
> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.
Jeff
On Feb 5, 10:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Sat, Feb 6, 2010 at 1:02 AM, Russell Keith-Magee
>
>
>
>
>
> <freakboy3...@gmail.com> wrote:
> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.
> Sorry to completely hijack this thread but would django-mobileadmin be considered for inclusion to trunk (during the 1.3 timeline)? iPhones and other mobile devices are getting pretty prolific and I love having the mobile admin site available when I login from my iPhone (which happens surprisingly often).
Just quick note, mobileadmin certainly needs an overhaul itself and probably could be slimmed down after we added a few more hooks to override templates in 1.2.X. It's mostly just a another skin for the admin, optimized for mobiles devices.
Jannis
The original thread seemed to be about re-skinning at most ('refining
Django admin look'). The choice about whether it goes in is largely
down to a matter of taste and aesthetics, which is why our normal
procedures with tickets and feature voting really wouldn't work - for
an aesthetics 'bug' you can have multiple 'fixes' which are all
'correct'. To avoid pointless debate, a contest seems like a good
idea. Personally, even a re-skinning brings with it potential design
problems for existing installations, so I'd have to be convinced the
re-skinning was a big enough improvement to make up for that - I agree
with Russell that this definitely isn't something we should be doing
every few months, or even every year.
If it's a complete re-thinking of the admin interface, it's obviously
a much bigger undertaking, and brings with it huge implications in
terms of backwards compatibility. Even if just the templates were to
be re-worked, we have to consider all the people who have custom admin
templates that assume the current block layout etc. A bigger re-
thinking of the admin would involve even more changes to code.
The models API change that occurred after 0.96 also occurred before
1.0. There have been very few breaking changes to it since then (have
there been any in that department?).
Like Alex, I must have missed a lot of messages to this list if a
major re-thinking of the admin like this has been repeatedly proposed
and dismissed. And it's kind of difficult to assess what is currently
an extremely vague proposal.
Luke
--
"Whom have I in heaven but You?
And there is none upon earth that I desire besides You." Psalm 73:25
Luke Plant || http://lukeplant.me.uk/
we´ve been doing grappelli (http://code.google.com/p/django-grappelli/
wiki/screenshots) for a while now. grappelli initially should be a
"skin" for the admin-interface. while working on it, we´ve had issues
skinning the interface and maybe it´s helpful to point out some of the
main problems.
currently (from what I´m seeing) there are new features planned (or
already integrated) with the admin-interface. that´s nice. but (IMHO)
the HTML/CSS needs to be refactored as well. I´m not talking about
colors are fonts, I´m talking about some kind of html-css-framework
for the admin-interface. so, here´s our proposal:
http://vonautomatisch.at/grappelli/ (sorry for the strange navigation)
PLEASE NOTE THAT THIS IS JUST A DRAFT AND SOME THINGS ARE BROKEN. we
´ve already been integrating most of this with the next version of
grappelli (the above site is about 2 months old and there´s already
been some changes). therefore, we´ve stopped developing the above
site ...
the most important change is probably the introduction of an overall
grid, see:
http://www.vonautomatisch.at/grappelli/basic-document-structures/grid-based-on-blueprint/
http://www.vonautomatisch.at/grappelli/forms-in-container-grid/basic-form-elements-in-container-grid/
moreover, we´ve tried to refactor all javascripts with jquery, see:
http://code.google.com/p/django-grappelli/source/browse/#svn/branches/haineault/media/jquery/grappelli/src
(done by maxime haineault)
as already discussed with jannis, what I´d like to see with the admin-
interface is a solid and comprehensible structure as well as coherent
styles. based on this, different "skins" are easily possible.
I don´t wanna be to detailed right now, but there´s too much hardcoded
stuff with the current admin-interface and the admin index page could
benefit from some changes as well.
here´s an (outdated) list of issues:
http://code.google.com/p/django-grappelli/wiki/djangoissues
let me add a note about the "contest": if it comes down to skinning
the admin-interface, a contest is not needed from my point of view. if
(one day), it´s easy to "skin" the admin-interface, different skins
will evolve (e.g., grappelli). I think that it´s important to create
the prerequisites for skinning first.
regards,
patrick
On 6 Feb., 13:18, Luke Plant <L.Plant...@cantab.net> wrote:
> * Do we need to do this in phases - e.g., phase one for design
> proposals, and then phase two for best execution of the design
> proposal we pick?
>
> * Who judges? I'm predisposed to say that the winner should be picked
> in the same way that we do feature voting for releases -- binding
> votes by the core team, but with input from anyone else that wants to
> offer an opinion.
>
> If this works out well, it might turn in to a model we can reuse. The
> DSF has some plans that will require some design work. Semi-regular
> design competitions might be one way to draw attention to the awesome
> design talent in our community.
>
Not that anybody wants to hear my opinion but...
This contest idea is ridiculous! The admin is a core feature of Django
and is responsible for a lot of the initial buzz surrounding Django;
I'd be willing to wager that an awful lot of people came to Django
because they wanted to try out the admin. The admin is beginning to
show its age though and a thoughtful redesign is due, a
99designs-style competition does not lend itself to thoughtful design.
No disrespect intended but as Russell pointed out himself, the core
developers are not designers and I doubt they would be sufficiently
competent to judge a *design* competition.
Jeff Croft, Bryan Veloso and Nathan Borror sounds like a pretty
amazing team to do a overhaul of the admin (I know they haven't
offered, I'm just saying). If these guys are genuinely interested in
doing the work then it would be a shame if a core dev didn't come
forward and tell them that they are behind the idea and give them the
help they need to get started.
Dave
let me add a note about the "contest": if it comes down to skinning
the admin-interface, a contest is not needed from my point of view. if
(one day), it´s easy to "skin" the admin-interface, different skins
will evolve (e.g., grappelli). I think that it´s important to create
the prerequisites for skinning first.
I will not participate in any sort of "contest" because it devalues
design, and I think you'll find that most serious designers will say
the same thing. Good design is not a commodity. Good interaction
design requires a great deal of research, and problem solving, just as
good programming does. Any I *certainly* won't participate in any
contest whose judges plainly admit they aren't designers and have no
qualifications for judging design, but want to do so anyway.
> And it's kind of difficult to assess what is currently an extremely vague proposal.
You didn't miss any messages. There is no proposal. I think you may be
missing the point of my message. It wasn't about the original post. It
wasn't about the fact that the admin needs to be redesigned (even
though it does). It was about a feeling that designers in this
community have that their input is not welcome. There is no proposal
from me because I've felt like a proposal from me wouldn't be taken
seriously. I suspect there isn't a proposal from others for the same
reason. THAT was the point of my original message.
I'm not going to disagree with you there, and I regret endorsing the
idea originally, the design of the admin should be handled by the same
process as any other part of the development. It'd be like us having
a contest to see who has the best idea for multiple database support.
>> And it's kind of difficult to assess what is currently an extremely vague proposal.
>
> You didn't miss any messages. There is no proposal. I think you may be
> missing the point of my message. It wasn't about the original post. It
> wasn't about the fact that the admin needs to be redesigned (even
> though it does). It was about a feeling that designers in this
> community have that their input is not welcome. There is no proposal
> from me because I've felt like a proposal from me wouldn't be taken
> seriously. I suspect there isn't a proposal from others for the same
> reason. THAT was the point of my original message.
>
That feeling is unfortunately, however I also don't know where it
comes from. It seems to me the "It's Wilson's admin" thought process
comes from the fact that no one else has volunteered/started to
workon/proposed a new interface a new one, and apparently this is
because of the perception that only Wilson could redesign the admin.
Nasty cycle we've got there ;)
Now that, hopefully, that perception is dispelled, unless there are
concrete proposals (or proposals for proposals) I don't think there's
much left here!
> --
> 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.
>
>
Alex
But If I ever were to put together a proposal for the design of the
admin interface, I would propose not just changing the visual
aesthetic. I'd propose starting over, from the group-up, and re-
thinking the entire way the admin interface works and how people
interact with it. As Luke said, this would entail a great deal of
backwards-compatibility issues. I have no disillusions about that --
it's why I laughed off the suggestion this could land in 1.2 or 1.3.
If the core developers take is "sorry, we can't do anything that
complex, ever, because we are too concerned about backwards
compatibility," then just say so, and I'll stop worrying about Django
iteself and consider getting a team together to create the admin
interface I want as a standalone app (although I admit, the thought of
going to all that work with no chance of it ever being considered for
core is a depressing one).
Thank you, sir. I think you've nailed it. :)
We're stepping pretty far into the realm of hypothetical, but as long
as we're here, I'll dive right in: Yes, backwards compatibility is an
issue, but it's impossible to say how hard of an issue it is without
seeing some sort of kernel of a proposal. Further, at some point we
will violently break backwards compatibility, Django 2.0. As you've
said, a new design would be an exceptionally large body of work,
certainly likely to take at least one release cycle, possibly more.
There's also no reason it couldn't live external to Django for a time,
and then be merged into Django for Django 2.0 when we can break that
backwards compatibility. There are, of course ways to mitigate
backwards compatibility issues were this merged into trunk today, but
it's really impossible to say with any accuracy without a vaguely
specific proposal ;).
On Feb 6, 11:08 am, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Sat, Feb 6, 2010 at 2:02 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote:
> > Let me also just say, on the topic of Grapelli: I think Grapelli is a
> > really great re-skinning of the current admin interface, with a few
> > IxD improvements. It's really nicely done, and in my opinion is a
> > significant improvement over what we have now.
>
> > But If I ever were to put together a proposal for the design of the
> > admin interface, I would propose not just changing the visual
> > aesthetic. I'd propose starting over, from the group-up, and re-
> > thinking the entire way the admin interface works and how people
> > interact with it. As Luke said, this would entail a great deal of
> > backwards-compatibility issues. I have no disillusions about that --
> > it's why I laughed off the suggestion this could land in 1.2 or 1.3.
> > If the core developers take is "sorry, we can't do anything that
> > complex, ever, because we are too concerned about backwards
> > compatibility," then just say so, and I'll stop worrying about Django
> > iteself and consider getting a team together to create the admin
> > interface I want as a standalone app (although I admit, the thought of
> > going to all that work with no chance of it ever being considered for
> > core is a depressing one).
>
> > --
> > 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 athttp://groups.google.com/group/django-developers?hl=en.
1) I'm all for a re-thinking of the admin, and I agree that a
rethinking would be better placed with a 2.0-release because of the
aforementioned backwards-compatabilitiy issues. Baby steps are better
than no steps.
2) On that note, I am completely for tweaking and "cleaning" the
current admin to make it easier to skin and just tweak in general.
Compartmentalizing CSS for widgets, or even just restructuring it to
2010 standards without any changes to the front-end look would be
leaps and bounds ahead of where we are now.
3) I like Eric's proposal. Hell, I'm willing to step up and be that
guy. It makes me wonder if there was somebody that had a design hat
much in the vein that Maclom/RKM/Alex have their ORM hats if people
would be more willing and enthusiastic about submitting proposals and
bugs.
I think three is enough for now. We've gotten this far through the
thread with a lot of heads nodding, so let's start thinking about how
to take action.
Cheers,
Bryan
Won't waste time echoing the sentiments above in many words. Contest
stupid. Ground-up rework in 2.0 (maybe). Refactor & clean up existing
stuff in the meantime. Design czar(s) needed to chaperone this work
into existence.
I don't think that I'm qualified to submit myself for a "djesign czar"
position, but "design in Django" is something I'd really like to
champion in some capacity. I certainly contribute more design than
code to django's community -- and I'm truly grateful that I have a
means of contributing/giving back to the community that isn't just
code.
Whoever/whatever solution is settled on, I think a key goal of the
czar will be to impose django's sensibilities on the design process --
"trusted, conservative tastemakers." I'd hate to see a nascent "design
group" experiment in django flame out early. Design is hard, just like
code, and it deserves the same rigorous consideration as any patch.
-I
1. I'm not in favor of redesigns for redesigns' sake; yes, the current
admin UI has been around for a while, but if we rework it, we
should rework it because there are actual issues with it which need
to be resolved. A good first step would be to identify any such
issues and get ideas for solutions.
2. A design contest is (sorry, Russ!) a really bad idea. We don't hold
contests to design APIs, so we shouldn't hold contests to design
user interfaces.
3. The idea of having one or two folks who really know design and UX
shepherding this stuff ("design czar") is the best approach. They
do need to be people who know Django as well, and AFAICT Bryan fits
that description quite nicely.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
I don't think anyone would be in favor of that, so people can probably
stop trotting it out there. No one is talking about redesigning "just
because" or "redesigning every few months," like Russ mentioned.
I seem to have inadvertently kicked over an ants nest here.
I promise that the competition proposal wasn't intended to offend or
devalue the efforts of anyone in the design community. If I have done
so, I apologize. Please believe that what I wrote as an honest attempt
to find a way to get designers involved in Django's development
process. I seem to have missed the mark. Mea culpa.
With that, I'll take my comments to the other thread that has emerged.
Yours,
Russ Magee %-)
Apparently, I'm not talking about redesigning. Even not about changing
colors and images - they perfectly fit for a base instance of the
framework. I'm talking about some UI fixes that I suppose should be
done in any open source project if there are more than one person to
wish.
I think as soon as I have time, I'll bring it all together (the CSS
stuff at least) and show it all as a PNG image for everyone to discuss
the difference. Again, it could be not obvious for everyone and
considered as unimportant. And I'm ready.
Andrew.
I know that. No big deal, dude. :)