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?
On Thu, Feb 4, 2010 at 8:35 AM, tezro <tezro...@gmail.com> wrote: > Hi everybody.
> 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.
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?
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.
All due respect to Wilson (he's a great designer, a good friend, and he and I have talked on several occasions about the Django admin interface), I have to agree that the Django admin interface is dated and has some UI issues that could use work. I can also confirm that Wilson himself says this, and won't be offended by anyone else saying so. Wilson is one of the very best designers I've ever had the pleasure of working with, but he's not immune to the same "God that thing I made five years ago kind of sucks by today's standards" feeling we all have.
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:
> On Thu, Feb 4, 2010 at 8:35 AM, tezro <tezro...@gmail.com> wrote: > > Hi everybody.
> > 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.
> 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?
> 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.
> 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.
Yes, in this particular instance it serves to highlight the visual hierarchy, i.e. the container for the content is a child of (and therefore indented from) the header.
The admin site still looks great considering it's age, I have noticed that it doesn't scale very well at wider resolutions though. Perhaps the best way to get something like this included in trunk would be to create an external project like django-grappelli[1] or django-mobileadmin[2] and bring up the issue again when you think that the project is ready for consideration. I'm not involved with contributing to Django so take what I've just said with a pinch of salt.
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).
As one of many talented and respected designers in the Django community, and also as a good friend of Wilson Miner, I'd like to say for the record that the attitude I've seen from the core devs about an admin redesign/overhaul is incredibly frustrating. Whenever someone proposes redesigning the admin interface, it's always met with a "well you could, and of course we would consider it, but really we wouldn't" kind of response, citing one of two reasons -- both of which are, frankly, BS:
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:
> On Thu, Feb 4, 2010 at 8:35 AM, tezro <tezro...@gmail.com> wrote: > > Hi everybody.
> > 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.
> 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?
> 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.
On Fri, Feb 5, 2010 at 5:37 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: > All due respect to Wilson (he's a great designer, a good friend, and > he and I have talked on several occasions about the Django admin > interface), I have to agree that the Django admin interface is dated > and has some UI issues that could use work. I can also confirm that > Wilson himself says this, and won't be offended by anyone else saying > so. Wilson is one of the very best designers I've ever had the > pleasure of working with, but he's not immune to the same "God that > thing I made five years ago kind of sucks by today's standards" > feeling we all have.
> 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.
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.
>> 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.
> Yes, in this particular instance it serves to highlight the visual > hierarchy, i.e. the container for the content is a child of (and therefore > indented from) the header. > The admin site still looks great considering it's age, I have noticed that > it doesn't scale very well at wider resolutions though. > Perhaps the best way to get something like this included in trunk would be > to create an external project like django-grappelli[1] or > django-mobileadmin[2] and bring up the issue again when you think that the > project is ready for consideration. I'm not involved with contributing to > Django so take what I've just said with a pinch of salt.
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 :-)
<freakboy3...@gmail.com> wrote: > On Fri, Feb 5, 2010 at 5:37 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: >> All due respect to Wilson (he's a great designer, a good friend, and >> he and I have talked on several occasions about the Django admin >> interface), I have to agree that the Django admin interface is dated >> and has some UI issues that could use work. I can also confirm that >> Wilson himself says this, and won't be offended by anyone else saying >> so. Wilson is one of the very best designers I've ever had the >> pleasure of working with, but he's not immune to the same "God that >> thing I made five years ago kind of sucks by today's standards" >> feeling we all have.
>> 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.
> 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.
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.
> * 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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@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
> 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.
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.
We don't do a "contest" for any other code, and I'm not sure why we would for design. Frankly, that seems ridiculous to me. I'm glad you guys are receptive to change, but a contest? Seriously? What is this, American Idol?
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: > > On Fri, Feb 5, 2010 at 5:37 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: > >> All due respect to Wilson (he's a great designer, a good friend, and > >> he and I have talked on several occasions about the Django admin > >> interface), I have to agree that the Django admin interface is dated > >> and has some UI issues that could use work. I can also confirm that > >> Wilson himself says this, and won't be offended by anyone else saying > >> so. Wilson is one of the very best designers I've ever had the > >> pleasure of working with, but he's not immune to the same "God that > >> thing I made five years ago kind of sucks by today's standards" > >> feeling we all have.
> >> 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.
> > 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.
> 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://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
To expound, it seems like you guys are thinking of a re-skinning. I'm not talking about a re-skinning. I'm talking about a complete re- thinking of the admin interface. By 1.2? Not a chance. By 1.3? Maybe. But I wouldn't count on it. I'm talking about bringing the admin to 2010, just like you all brought the models API current after .96. Seriously, what if the models API hadn't changed in five years? Do you think it would be a small project to bring it current? Of course not. It would be huge. This is a serious undertaking, and the idea of doing a "contest" feels like you think it's a commodity. This is a serious project for serious designers, not a g'damn reality TV show.
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: > > On Fri, Feb 5, 2010 at 5:37 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: > >> All due respect to Wilson (he's a great designer, a good friend, and > >> he and I have talked on several occasions about the Django admin > >> interface), I have to agree that the Django admin interface is dated > >> and has some UI issues that could use work. I can also confirm that > >> Wilson himself says this, and won't be offended by anyone else saying > >> so. Wilson is one of the very best designers I've ever had the > >> pleasure of working with, but he's not immune to the same "God that > >> thing I made five years ago kind of sucks by today's standards" > >> feeling we all have.
> >> 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.
> > 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.
> 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://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
> 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.
On Saturday 06 February 2010 09:07:33 j...@jeffcroft.com wrote:
> To expound, it seems like you guys are thinking of a re-skinning. > I'm not talking about a re-skinning. I'm talking about a complete > re- thinking of the admin interface. By 1.2? Not a chance. By 1.3? > Maybe. But I wouldn't count on it. I'm talking about bringing the > admin to 2010, just like you all brought the models API current > after .96. Seriously, what if the models API hadn't changed in > five years? Do you think it would be a small project to bring it > current? Of course not. It would be huge. This is a serious > undertaking, and the idea of doing a "contest" feels like you > think it's a commodity. This is a serious project for serious > designers, not a g'damn reality TV show.
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
jannis (leidel) asked me to join this thread in order to add some comments.
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 ...
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:
> On Saturday 06 February 2010 09:07:33 j...@jeffcroft.com wrote:
> > To expound, it seems like you guys are thinking of a re-skinning. > > I'm not talking about a re-skinning. I'm talking about a complete > > re- thinking of the admin interface. By 1.2? Not a chance. By 1.3? > > Maybe. But I wouldn't count on it. I'm talking about bringing the > > admin to 2010, just like you all brought the models API current > > after .96. Seriously, what if the models API hadn't changed in > > five years? Do you think it would be a small project to bring it > > current? Of course not. It would be huge. This is a serious > > undertaking, and the idea of doing a "contest" feels like you > > think it's a commodity. This is a serious project for serious > > designers, not a g'damn reality TV show.
> 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
On Sat, Feb 6, 2010 at 6:02 AM, Russell Keith-Magee
<freakboy3...@gmail.com> 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.
On 6 February 2010 15:38, patrickk <patr...@vonautomatisch.at> wrote:
> 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.
It seems to me that we really have two issues here to tackle. Both are being discussed separately or together in this thread but I see them very differently.
So just as a food for thought:
Firstly is the case of the current admin's look and feel becoming dated. Like most projects it could be improved in numerous ways - from small changes to a complete overhaul. I think it would be dangerous to change it too much as there are a large number of apps that reply on the layout. So we at least need a fallback to the current layout if possible.
The second and perhaps more important issue is highlighted well by Patrickk. It would be good if the interface was easier to skin, modify or just plain replace. I guess like everything else from database backends to email backends the ideal solution would make it easier to have your own 'admin backend'. This could then start a whole new surge of admin style variations that could be similar in some ways to pluggable apps - these could then be added to trunk over time if it makes sense, again in a similar way to pluggable apps.
> None of Django's core developers are designers, nor can they necessarily execute someone else's creative vision.
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.
On Sat, Feb 6, 2010 at 1:38 PM, j...@jeffcroft.com <j...@jeffcroft.com> wrote: >> None of Django's core developers are designers, nor can they necessarily execute someone else's creative vision.
> 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.
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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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
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).
> 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!
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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 ;).
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
> 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-developers@googlegroups.com. > > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.
> 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 ;).
> 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
There has been a recent discussion on the Django Development mailing list about the role of designers in the Django community. I think that this is an interesting discussion that can come from this, and I would like to explain my thoughts on the issue.
This discussion came up in the context of redesigning the Django Admin, which everyone knows and loves. The UI is growing a bit out-dated, and there was talk of working to clean it up. This then turned into a discussion about how design proposals and improvements aren't taken as seriously as they should be by the community. I think there are a number of reasons that this happens, and I would like to take a look at them. My purpose here is to start a discussion about how to better integrate designers into the community, because they are a vital part of making our world more beautiful and efficient.
I don't trust myself to judge your work =======================================
The normal process for changes that go into Django is that a proposal is sent to the mailing list. There is a discussion that happens around them, and then if the code is produced, and it works, it gets committed. For design changes, I don't reply to these messages, because I don't have the skills or knowledge to judge the work. I think that a lot of people on these lists are in the same boat.
When someone sends a proposal to the list, and it doesn't get any replies, that feels like rejection. This happens more than it should, but it isn't anyones job to respond to these messages and say "sorry, I'm not qualified to critique your work". This happens with code proposals too, but I think it may happen more with design. This leads to designers forsaking the mailing list, and this problem perpetuates itself, by not drawing designers into the community.
Design is not special, except when it is ========================================
Part of the problem that seems to have come forward is that there is a feeling that design is "special". That it should be treated somehow differently in the process. As we know from history, even with all good intentions, different is never equal. So I think that we should work to fit design into the current scheme of how things work, instead of trying to adopt new ways of dealing with it.
When I look at the current Core Developers of Django, I don't see many people who are designers. As I said above, that fact that very few of the current core developers are well versed in the design realm, really hurts inclusion of design changes. This creates a lot more friction in the process of getting design changes into the code base.
I don't know if this idea is crazy, but should we have the concept of a "core designer". These would be people that the community trusts and knows have good taste, that would be an obvious person to make these design choices. I think that there is a problem when I have a design change for Django, and I really don't know who to talk to. There is an obvious authority (BDFL) for code changes, but I don't know if Adrian and Jacob are really the correct people to making these judgment calls on design?
I realize that this is open source, and "core designers" would be the same as developers, just people who care about the direction of the projects design. However, I think that having more design oriented people in the community in a more direct fashion would make it more obvious that design changes are welcomed and seriously considered.
I don't know how far we need to go down the path of making this explicit. However, most of the documentation about contributing is explicit about "code". This is another of those lines, where I don't know if it makes sense to be explicit about design, having a "design" section in the contributing documentation, or if the implicit knowledge of core designers will make it obvious that we mean design changes there too.
The actual process ==================
I don't want to talk about the actual design process, because well, I really don't know how it works. I think that once we integrate designers into the community better, the process for design will naturally fall out better.
Conclusion ==========
I would like to point out that Django has some of the best designers of any open source community out there. I am lucky to work with a number of them on a daily basis, and I really think that they make our community special. So thank you guys for sticking with us.
This is a place where I could see Django leading the way in how to integrate design into the open source development process. Let's make a grand experiment, and see how it works out.
Let me get straight to the point, since I seem to suffer from chronic "tl;dr" syndrome as of late.
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
On Feb 6, 11:52 am, Eric Holscher <eric.holsc...@gmail.com> wrote:
> There has been a recent discussion on the Django Development mailing list > about the role of designers in the Django community. I think that this is an > interesting discussion that can come from this, and I would like to explain > my thoughts on the issue.
> This discussion came up in the context of redesigning the Django Admin, > which everyone knows and loves. The UI is growing a bit out-dated, and there > was talk of working to clean it up. This then turned into a discussion about > how design proposals and improvements aren't taken as seriously as they > should be by the community. I think there are a number of reasons that this > happens, and I would like to take a look at them. My purpose here is to > start a discussion about how to better integrate designers into the > community, because they are a vital part of making our world more beautiful > and efficient.
> I don't trust myself to judge your work > =======================================
> The normal process for changes that go into Django is that a proposal is > sent to the mailing list. There is a discussion that happens around them, > and then if the code is produced, and it works, it gets committed. For > design changes, I don't reply to these messages, because I don't have the > skills or knowledge to judge the work. I think that a lot of people on these > lists are in the same boat.
> When someone sends a proposal to the list, and it doesn't get any replies, > that feels like rejection. This happens more than it should, but it isn't > anyones job to respond to these messages and say "sorry, I'm not qualified > to critique your work". This happens with code proposals too, but I think it > may happen more with design. This leads to designers forsaking the mailing > list, and this problem perpetuates itself, by not drawing designers into the > community.
> Design is not special, except when it is > ========================================
> Part of the problem that seems to have come forward is that there is a > feeling that design is "special". That it should be treated somehow > differently in the process. As we know from history, even with all good > intentions, different is never equal. So I think that we should work to fit > design into the current scheme of how things work, instead of trying to > adopt new ways of dealing with it.
> When I look at the current Core Developers of Django, I don't see many > people who are designers. As I said above, that fact that very few of the > current core developers are well versed in the design realm, really hurts > inclusion of design changes. This creates a lot more friction in the process > of getting design changes into the code base.
> I don't know if this idea is crazy, but should we have the concept of a > "core designer". These would be people that the community trusts and knows > have good taste, that would be an obvious person to make these design > choices. I think that there is a problem when I have a design change for > Django, and I really don't know who to talk to. There is an obvious > authority (BDFL) for code changes, but I don't know if Adrian and Jacob are > really the correct people to making these judgment calls on design?
> I realize that this is open source, and "core designers" would be the same > as developers, just people who care about the direction of the projects > design. However, I think that having more design oriented people in the > community in a more direct fashion would make it more obvious that design > changes are welcomed and seriously considered.
> I don't know how far we need to go down the path of making this explicit. > However, most of the documentation about contributing is explicit about > "code". This is another of those lines, where I don't know if it makes sense > to be explicit about design, having a "design" section in the contributing > documentation, or if the implicit knowledge of core designers will make it > obvious > that we mean design changes there too.
> The actual process > ==================
> I don't want to talk about the actual design process, because well, I really > don't know how it works. I think that once we integrate designers into the > community better, the process for design will naturally fall out better.
> Conclusion > ==========
> I would like to point out that Django has some of the best designers of any > open source community out there. I am lucky to work with a number of them on > a daily basis, and I really think that they make our community special. So > thank you guys for sticking with us.
> This is a place where I could see Django leading the way in how to integrate > design into the open source development process. Let's make a grand > experiment, and see how it works out.
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
On Feb 6, 10:20 pm, Bryan Veloso <br...@revyver.com> wrote:
> Let me get straight to the point, since I seem to suffer from chronic > "tl;dr" syndrome as of late.
> 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
> On Feb 6, 11:52 am, Eric Holscher <eric.holsc...@gmail.com> wrote:
> > I went ahead and replied to this on my blog[0]. I'll copy it here for > > completeness.
> > There has been a recent discussion on the Django Development mailing list > > about the role of designers in the Django community. I think that this is an > > interesting discussion that can come from this, and I would like to explain > > my thoughts on the issue.
> > This discussion came up in the context of redesigning the Django Admin, > > which everyone knows and loves. The UI is growing a bit out-dated, and there > > was talk of working to clean it up. This then turned into a discussion about > > how design proposals and improvements aren't taken as seriously as they > > should be by the community. I think there are a number of reasons that this > > happens, and I would like to take a look at them. My purpose here is to > > start a discussion about how to better integrate designers into the > > community, because they are a vital part of making our world more beautiful > > and efficient.
> > I don't trust myself to judge your work > > =======================================
> > The normal process for changes that go into Django is that a proposal is > > sent to the mailing list. There is a discussion that happens around them, > > and then if the code is produced, and it works, it gets committed. For > > design changes, I don't reply to these messages, because I don't have the > > skills or knowledge to judge the work. I think that a lot of people on these > > lists are in the same boat.
> > When someone sends a proposal to the list, and it doesn't get any replies, > > that feels like rejection. This happens more than it should, but it isn't > > anyones job to respond to these messages and say "sorry, I'm not qualified > > to critique your work". This happens with code proposals too, but I think it > > may happen more with design. This leads to designers forsaking the mailing > > list, and this problem perpetuates itself, by not drawing designers into the > > community.
> > Design is not special, except when it is > > ========================================
> > Part of the problem that seems to have come forward is that there is a > > feeling that design is "special". That it should be treated somehow > > differently in the process. As we know from history, even with all good > > intentions, different is never equal. So I think that we should work to fit > > design into the current scheme of how things work, instead of trying to > > adopt new ways of dealing with it.
> > When I look at the current Core Developers of Django, I don't see many > > people who are designers. As I said above, that fact that very few of the > > current core developers are well versed in the design realm, really hurts > > inclusion of design changes. This creates a lot more friction in the process > > of getting design changes into the code base.
> > I don't know if this idea is crazy, but should we have the concept of a > > "core designer". These would be people that the community trusts and knows > > have good taste, that would be an obvious person to make these design > > choices. I think that there is a problem when I have a design change for > > Django, and I really don't know who to talk to. There is an obvious > > authority (BDFL) for code changes, but I don't know if Adrian and Jacob are > > really the correct people to making these judgment calls on design?
> > I realize that this is open source, and "core designers" would be the same > > as developers, just people who care about the direction of the projects > > design. However, I think that having more design oriented people in the > > community in a more direct fashion would make it more obvious that design > > changes are welcomed and seriously considered.
> > I don't know how far we need to go down the path of making this explicit. > > However, most of the documentation about contributing is explicit about > > "code". This is another of those lines, where I don't know if it makes sense > > to be explicit about design, having a "design" section in the contributing > > documentation, or if the implicit knowledge of core designers will make it > > obvious > > that we mean design changes there too.
> > The actual process > > ==================
> > I don't want to talk about the actual design process, because well, I really > > don't know how it works. I think that once we integrate designers into the > > community better, the process for design will naturally fall out better.
> > Conclusion > > ==========
> > I would like to point out that Django has some of the best designers of any > > open source community out there. I am lucky to work with a number of them on > > a daily basis, and I really think that they make our community special. So > > thank you guys for sticking with us.
> > This is a place where I could see Django leading the way in how to integrate > > design into the open source development process. Let's make a grand > > experiment, and see how it works out.
