Re: Redesign of djangoproject.com?
No premade templates. I On Wednesday, May 2, 2012 at 3:14 AM, Daniel Sokolowski wrote: > Being realistic here we must acknowledge that likely the majority of us are > great programmers but not great designers – none of the design proposed did > it for me – they were not bad but they weren’t great, and I want epic, I want > sexy and I want eye candy. > > So I say this: it is no shame to use a pre-existing, pre-made template. > > I have used http://themeforest.net/?ref=danols successfully in the past - yes > it includes my referral link - an added benefit is we can get through the > mock up and conversion phases very quickly. Some designs that caught my eye > --- please note these are fluid designs hence table and smartphone ready, > resize your browser window to see what I mean. > > http://themeforest.net/item/spectrum-responsive-business-site-template/full_screen_preview/2035034 > http://themeforest.net/item/doctype-claquette-responsive-video-html-template/full_screen_preview/2085780 > http://themeforest.net/item/valera-responsive-html-template/full_screen_preview/2194402 > > > > However > From: Dana Woodman (mailto:woodman.d...@gmail.com) > Sent: Saturday, April 28, 2012 3:22 AM > To: django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com) > Subject: Redesign of djangoproject.com (http://djangoproject.com)? > > > > So now that Django is being moved to Git/Github (which is awesome!), maybe it > would be a good time to think about a revamped home page for the project ala > djangoproject.com (http://djangoproject.com)? > > Obviously this is no small undertaking and would be potentially contentions > as to what would be the proper path, but I feel (and I don't think I'm alone) > that djangoproject.com (http://djangoproject.com) could use a bit of a > facelift. > > I have some idea of my own as to how this could be accomplished and I'm sure > there are a ton of others out there with great ideas as well. Maybe we could > open up some discussion on this idea? > > Forgive me if this has been proposed before as I'm new to the group! > > Cheers, > Dana > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/g8ngEnVG_EsJ. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > Daniel Sokolowski > Web Engineer > Danols Web Engineering > http://webdesign.danols.com/ > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Redesign of djangoproject.com?
Lovely to see fresh talent and energy applied to a long-stalled issue. :) I think Giovanni's proposal has a strong, simple page structure, and it does a good job of IA for our varied audience. Putting on my BDesignerFL hat, let's use that as a starting point. Let's set aside the issue of restyling docs for now; we can't run in all directions at once. Homepage Structure === News The major element elided from the proposal is some display of news. The current homepage shows the most recent four entries; I think one is sufficient for the homepage, but it does need to be somewhere on the page. Header nav There is no header nav in the proposal. I'd like to have some minimal list of primary nav links, like the ones at the top-left of the page fat-footer. On the homepage, they can appear very de-emphasized, I like the spare look of the masthead and I don't want to break that by boxing it in with a visual bar from above. Header actions ~~~ While I like the "quick start" mechanic, those buttons require some love: * There's no obvious "get django" or "download" call-to-action. "Quick start" is good but we're burying the download information in there. * The quick start drawer doesn't make mention of the other ways you can get Django, for example downloading a tarball or a link to github. * There's no quick display of our most recent released version. It belongs somewhere at the level of these buttons. My proposal is a button layout like: [ Get Django 1.4 v ] [ Quick Start v ] [ Documentation ] The get-django button can show a drawer like quick start, but show the three common routes (pip, tarball, github) and supply a link to a page with more details if need be. Who's Using Django ~~~ I don't know if we'll have case studies. If not, an attractive display of some logos wouldn't go badly. If we do, then we can fade out the other logos upon click and show a bit of teaser text about the company with a link to "read more…" Footer ~ I like the structure. Need to give some thought to the six large elements and make sure they're the best choices for what to show there. Responsive Structure A requirement for the new dp.com is that it be responsive or adaptive. I'm not going to get hung up on the technicalities—something which looks and works well on a variety of common screen geometries. The proposed page layout would linearize well for smaller screens, which is excellent. Non-homepage templates === I'm not sure what other pages we have in our current site, ignoring trac for now. I suspect that we'll need one or two templates for non-home pages. Look & Graphic Design = I don't want to get off course with the IA work. Color and design stuff can wait until we're feeling that the structure is mostly baked. If you have ideas and you want to get them down, I'd recommend you make something like style tiles (http://styletil.es/). Thanks all for your brains on this matter. I am excited to see this underway, and I can't wait to see what comes next. :) -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Admin Revamp - Any updates?
On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: > Increasing the flexibility for development and integration is more > important than trying to 2nd guess where we are going to be in 5 years > time. Fair enough, but that sort of flexibility is available now. Nothing is preventing you from starting your 3rd-party admin app today. The issue is Django's officially-blessed, officially-documented admin. I'm not sure it's better to have admin in contrib (or contrib at all, but that's a separate ball of wax). I have a feeling that this issue will probably be addressed once again now that we're on github. All the same, if there's going to be an official django admin, I'd like it to give some thought to the issues I've raised. I have no problem (read: would love) to draw upon existing solutions for an admin revamp, but right now I don't have a fitness function to guide my decisions, and I think that is necessary. Not a spec, just an attempt to step back and think about what the admin should do. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Admin Revamp - Any updates?
As I wrote, I'd like to have a clear idea of what a new admin will accomplish before starting to bolt on enhancements, even great enhancements like grappelli. The admin was an impressively future-proof design, given that it is still so useful years after it was designed. We should aim to make an admin that will be relevant and useful five years from now; we can't design for that without a couple of clear, simple goals. Grappelli may or may not align with those goals. -I On Saturday, April 28, 2012 at 12:55 AM, Daniel Sokolowski wrote: > On that note, why can't the fruits of Grappelli be used as a starting point? > > -Original Message- > From: h3 > Sent: Friday, April 27, 2012 4:01 PM > To: Django developers > Subject: Re: Django Admin Revamp - Any updates? > > I don't know the status of this project, but my guess is that you > shouldn't hold your breath for it. > > Fortunately, there is Grappelli: > https://github.com/sehmaschine/django-grappelli > > We are currently working on making it compatible with django 1.4 (see > the "grappelli_2_4" branch) > > Alternatively the branch on my fork works pretty well with 1.4: > https://github.com/h3/django-grappelli/tree/grappelli_2_4 > > Cheers > > On Apr 26, 7:06 pm, Victor Hooi http://gmail.com)> > wrote: > > Hi, > > > > Is there any news on the Django Admin rewrite front? > > > > I remember around a year ago, there was quite a bit of talk on revamping > > the Django admin UI - I think Idan Gazit was heading that, right? > > > > Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, > > 1.6, 1.7 etc? > > > > Cheers, > > Victor > > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > Daniel Sokolowski > Web Engineer > Danols Web Engineering > http://webdesign.danols.com/ > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Admin Revamp - Any updates?
Hey all, Yeah, you aren't missing anything — originally I wanted to wait for the formrendering stuff, but that never panned out, and then I got busy. Grappelli is lovely. Without knocking it at all, I think that the next version of the admin should be as forward-looking as the last version, which means rethinking what the admin does, not just how it looks. Unfortunately, I haven't stepped up to champion this beyond idle thoughts. As noted, "don't hold your breath" would be wise. Even if we did jump in on an admin rewrite tomorrow, the fruits of that labour won't be one release in the making. The transition would probably resemble newforms, with "newadmin" appearing alongside "admin" in one release, then admin deprecated to "oldadmin" for one release, and finally disappearing after that. We wouldn't even release "newadmin" as a thing until we had something functional and mostly stable. I don't see much point in speculating when that might happen. -I On Friday, April 27, 2012 at 11:01 PM, h3 wrote: > I don't know the status of this project, but my guess is that you > shouldn't hold your breath for it. > > Fortunately, there is Grappelli: > https://github.com/sehmaschine/django-grappelli > > We are currently working on making it compatible with django 1.4 (see > the "grappelli_2_4" branch) > > Alternatively the branch on my fork works pretty well with 1.4: > https://github.com/h3/django-grappelli/tree/grappelli_2_4 > > Cheers > > On Apr 26, 7:06 pm, Victor Hooi http://gmail.com)> > wrote: > > Hi, > > > > Is there any news on the Django Admin rewrite front? > > > > I remember around a year ago, there was quite a bit of talk on revamping > > the Django admin UI - I think Idan Gazit was heading that, right? > > > > Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, > > 1.6, 1.7 etc? > > > > Cheers, > > Victor > > > > > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Jquery library update in django 1.4
As we're already past feature freeze, changing the bundled copy of jQuery would require that there be a show stopping bug or some truly exceptional benefit. Absent both of these, updates like this will have to wait for the 1.5 cycle. I On Feb 29, 2012, at 9:42, Ric wrote: > hi, is it possibile to upgrade the jquery library in admin to the > lastest version with the now django 1.4? > > for what i've seen there is just one little bug when you use the > select all checkbox in admin changelist, all other javascript works > out of the box > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: start using less (and bootstrap!)
The next major revision of the admin will definitely use either less or sass, because it is uncivilized to work without such lovely tools nowadays. I'm less certain about bootstrap. It has some pros and cons: Pros: * widely used (and thus widely understood) * We won't need to invent our own style guide for the new admin. If you're developing a plugin or an extension and you're using the bootstrap styles, your thing willl mesh nicely with the rest of the admin. * less.js has the distinct advantage of being easier to develop for than sass for our purposes.If we go with a less.js solution (like bootstrap), we might not need to require that all edits to admin "source" stylesheets (less/scss) come with the recompiled CSS. This lowers the barrier to contribution significantly, at the cost of a bit of site performance as less gets compiled client-side. That being said, the admin isn't supposed to be used as a a high-traffic site (or shouldn't be, I can't say how people abuse it). Cons: * less has no equivalent to compass, which is chock full of reusable stuff. * I'm already having a bit of a negative reaction to the ubiquity of the bootstrap "look" on the web. That being said, it's relatively easy to alter some styles, but then we make the job of 3rd party admin extenders harder, because they must deviate from the default bootstrap style to fit into the admin. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/QxpHySYhgDgJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Cleaning up manage.py and import paths
This is fantastically clear and sensible. +1. I can't count the hours I've lost either chasing PYTHONPATH issues or helping nontechnical people work around them so they could deploy their newly-minted thing. I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/2ZtSAWg--NMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Browser Support
So, a while back, I announced that Django is dropping support for IE6 in the admin. What I _didn't_ specify is what browsers are supported. I'm currently composing a bit for the 1.4 release notes about admin browser support, and wanted to explicitly list what we consider to be supported: YUI's A-Grade, minus IE6. Link: http://yuilibrary.com/yui/docs/tutorials/gbs/ Any objections? I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/UGdit_CXNvMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC form-rendering] Weekly Check-in
W00t, poking through the source.
On Saturday, August 20, 2011 at 4:59 PM, Gregor Müllegger wrote:
> So after the exams, vacation and a short illness have I completed a week of
> productive work.
>
> All the parts that were discussed in detail on the mailing list a while back
> are implemented. The new rendering API is completely in place and well tested.
> I've manly added more documentation in the last week on how to create custom
> form layouts, the new template tags and the template based widgets.
>
> Also work on the admin has started to dog-food the new form API, but this is
> still far from finished yet. Add and change forms use the template based
> rendering but that hasn't brought any real benefits yet. But it should be
> possible to further refactor it to make some of the
> django.contrib.admin.helpers.* classes superfluously.
>
> I found some use cases that are not yet possible with the form rendering
> template tags. The biggest issue is that it's not possible to exchange field
> labels with translated text. Currently there is no way of storing a translated
> string in the templates as variable, like {% trans "foo" as var %}
>
> --
> Servus,
> Gregor Müllegger
>
> --
> 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
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
Hey Victor, So far, only small steps -- my time hasn't provided for any thing "major" yet. :) My twitter will be a good place, as will this list. Right now, my head is mainly in helping out with a couple of specific issues (formrendering, admin sorting). There are some plans underway to provide better places to get involved/contribbute if you're into that sort of thing, as well as tracking progress of contributions that aren't easily quantifiable like code. Cheers! -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Kw09rJtoc8UJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Form Rendering API Proposal
On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote: > > What is the "significant wart" ? > The formconfig tag is a little bit "magical"; there's no other example in the template langauge of something explicitly affecting state in the same fashion. Even things like the "with" tag are self-bounding. Granted, formconfig is scoped to the form block, but stil. Feels a little bit dirty to me. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/vCnVG34vyVQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Form Rendering API Proposal
At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about
his work on a revised form rendering API:
http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
I sat down with Gregor, Jannis, Russell, Alex, Ericflo, Andrew Godwin, and
many other fine minds at the sprints to think about his proposal and help
refine it. At the risk of starting a bikeshedding war, I'd like to share the
results of the sprints and get some feedback on our proposed approach.
I'm very pleased with the resulting API. It has one significant wart, but
having chewed on the alternatives, I think there is consensus that this API
represents a good compromise between purity and practical considerations.
# Goals
The existing rendering facilities for forms aren't bad, but they suffer from
the following drawbacks:
1. All-or-nothing: if you'd like to customize one small part of form
rendering, you have to go the whole hog and write out a ton of boilerplate.
2. "Frontend developers need not apply": large parts of form rendering
happen in Python. If a frontend dev wants to customize certain aspects of
form.as_p's output, they've got to bust out the python.
3. Prevents modularity and code re-use: with large bits of markup locked
inside .py files, it's difficult for designers to share reusable form
patterns.
4. DOCTYPE lock-in: designers are forced to use the XML style of tags,
breaking validation of other doctypes when forms are present.
The new form rendering API addresses these drawbacks, and as such, has the
following desirable properties:
1. No backwards-incompatible changes: the new API coexists peacefully with
the old one, allowing for a smooth transition and deprecation of the old
formrendering API.
2. Simple beginner usage: if all you're comfortable using is {{ form.as_p
}}, the new API retains a similarly brief approach.
3. Vastly better customizability: the new API provides an expressive and
flexible means for specifying how forms should be rendered, and allows you
to override just the parts that need changing.
4. Significant improvements to the rendering of form rows with multiple
fields (for example, first and last name, or credit card and expiration).
5. Dogfooding: the new API does have some new tags, but a lot of the
internals and examples for customization are just using the existing
template system. This provides a lot of flexibility, but it also means that
the new API should feel familiar to existing developers.
6. Modularity: it will be possible to produce reusable libraries of form
rendering templates.
# The anatomy of form rendering templates
Forms are composed of three logical units:
1. A template which represents the form itself, including some form-specific
configuration.
2. A template which represents a given "row" in a form. A row is an abstract
concept, and doesn't have to represent a horizontal slice of anything (but
usually does). The existing form rendering API produces rows in the shape of
's, 's, and 's. In the new form rendering API, Django supplies
the formrow templates for all three of these row "types", but users can
easily add new ones of these to create a formrow based on 's, for
example.
3. A template which represents a given widget in the form. These are the
widgets which are currently provided by the framework, but supplied as
templates instead of being buried in widgets.py.
# Examples.
I've prepared example templates for each of these; check out
https://github.com/idangazit/formrendering after reading the following
tutorial. These represent a good starting point for developing the form
templates distributed with Django.
# API Usage Tutorial
The new API introduces the following template tags:
- form
- formconfig
- formrow
- formfield
For the following examples, "myform" is a form instance present in the
template's context.
# {% form %}
The new form rendering API introduces a {% form %} tag:
{% form myform %} {# equivalent to the following line #}
{% form myform using "forms/layouts/table.html" %}
{% form myform using "forms/layouts/p.html" %}
{% form myform using "forms/layouts/ul.html" %}
In its simplest incarnation, it works like the existing form.as_XX methods.
Users select a row type by means of the optional using argument. Django will
need to supply the existing row types (table, p, ul) to ease the transition.
Users can specify their own form templates using the same syntax:
{% form myform using "fancy_div.html" %}
{% form myotherform using "fancy_div.html" %}
Like the include tag, form can pass context into its child template:
{% form myform using "myform.html" with greeting="Hi!" %}
{% form myform using "myform.html" with greeting="Hi!" only %}
The form tag can also load a configuration inline, as follows:
{% form myform using %}
... layout goes here ...
{% endform %}
The template contents that go inside a form block are identical to th
Re: Django Error Display Page
The technical 500 page does display a lot of information, but debugging a failure is all about information. #11834 is helpful (dims django frames) without getting in the way (hiding things). For now, this is a good example of a helpful change with minimal negative impact. I'm sure the 500 page could be better, but I'd need to see a concrete proposal outlining the problems and how the improvements address these problems. Right now this feels like a case of fixing what ain't broken. I On Wednesday, June 8, 2011 at 6:10 PM, Graham King wrote: > This ticket might be a part of what you're looking for: > https://code.djangoproject.com/ticket/11834 > It proposes to dim the django parts of the stacktrace, so the code > which most likely caused the error stands out better, which is > certainly something I'd love to see. > > There's some similar ideas discussed here: > https://groups.google.com/group/django-developers/browse_frm/thread/bd43e2e040a17784/?hl=de&pli=1 > > On 8 June 2011 03:50, Mateusz Harasymczuk (mailto:m...@harasymczuk.pl)> wrote: > > Hi, > > I have been thinking about this for quite a long time. > > Can you make an error display page less verbose? > > I mean not to exclude those useful information, but to initially fold (hide) > > them. > > Fold those items: > > - Python path at the top yellow background. > > - (Hide or fold) django traceback entries > > When I have a problem I have to scroll down (passing django calls) few pages > > until I am able to find which MY action caused an error. > > I know looking at django callback may be useful, but in my case, hardly > > ever, and probably for newcommers also. > > I am imagining this like that: > > At the top of the error page, there are tabs. > > Summary, Traceback, Request, Settings, and copy-paste view (feedback view). > > Summary tab, contains this yellow background information with PYTHON_PATH > > initially folded, and traceback filtered out to include only information > > from project not calls from django itself. > > Traceback, request and settings tabs as it is right now, but separated for > > easy of view. > > copy-paste (feedback) - a standardize view for easy of copy-and-paste to the > > Internet message boards, groups and so on... > > It would need a template refactor and some more js involved, should not be a > > hard thing to do. > > I read that there is a plan to redesign an error page, but since then, those > > modifications should do the job. > > What do you think? > > -- > > Matt Harasymczuk > > http://www.matt.harasymczuk.pl > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK. > > To post to this group, send email to django-developers@googlegroups.com > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deprecation policy for IE6
OK, by the power vested in me, I declare the admin unshackled from the need to support IE6. Reception and dancing shall follow. On Thursday, June 9, 2011 at 2:22 PM, Carl Meyer wrote: > On 06/09/2011 05:32 AM, Idan Gazit wrote: > > I'm looking at admin tickets, and I realize that some defined policy > > for when we can safely start to break IE6 would be very helpful. > > > > I'd like to simply declare that going forward, the admin need not > > work perfectly in IE6. That leaves our support footprint for the > > Admin at "modern browsers" + IE>7. > > > > * contrib.admin is contrib, and thus not covered by Django's > > deprecation policy > > > > * This isn't a change which affects any other frontend product built > > with Django. The only audience this affects is users of the admin. I > > think it's reasonable to require administrative users to have IE7 if > > all they have is IE. > > > > The admin is already using the HTML5 doctype (see > > https://groups.google.com/d/topic/django-developers/wJ9dnUDHUVI/ for > > background), but not any of the new HTML5 elements. > > > > This change would mainly open up the ability to use PNGs and remove > > hacks and workarounds from admin CSS/HTML > > > > Any objections? > > Hearty +1 from me, for purely pragmatic reasons. In 2011, IE6 support is > simply an unreasonable burden to place on volunteer front-end > development work, IMHO. It's hard enough getting front-end work done > without tripling (quadrupling? more?) the pain factor like that. In my > mind, asking front-end developers to support IE6 is roughly similar to > asking Python devs to support Python 1.5, perhaps not in terms of usage, > but in terms of the additional development pain. > > I think it needs to be stated clearly that the effective choice is > between maintaining IE6 support and making major improvements to the > admin. If someone wants to argue that admin IE6 support should be > maintained for another release, they should acknowledge that the > implication is that there probably won't be significant upgrades to the > admin UI for at least that long. > > If there are Django deployments whose administrators really can't use > any browser other than IE6, Django 1.3 will be around as long as they > need it. It's not a reasonable tradeoff for that (frankly somewhat > ridiculous - IE6 is how many years old now?) edge case to continue to > hold the rest of the community hostage. > > Carl > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Deprecation policy for IE6
I'm looking at admin tickets, and I realize that some defined policy for when we can safely start to break IE6 would be very helpful. I'd like to simply declare that going forward, the admin need not work perfectly in IE6. That leaves our support footprint for the Admin at "modern browsers" + IE>7. * contrib.admin is contrib, and thus not covered by Django's deprecation policy * This isn't a change which affects any other frontend product built with Django. The only audience this affects is users of the admin. I think it's reasonable to require administrative users to have IE7 if all they have is IE. The admin is already using the HTML5 doctype (see https://groups.google.com/d/topic/django-developers/wJ9dnUDHUVI/ for background), but not any of the new HTML5 elements. This change would mainly open up the ability to use PNGs and remove hacks and workarounds from admin CSS/HTML Any objections? I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sorting UX question
Jannis and I are sprinting on this; we'd like to take a 2nd look at potential behaviors after a long conversation yesterday. The current solution works, but I think there's still a lot of room for user confusion. Plan is to look again at existing sorting implementations (on various apps/platforms) and maybe actually develop the nicer UI promosed earlier in #11834. I On Thursday, June 9, 2011 at 1:45 AM, Luke Plant wrote: > In the new admin sorting UI, which now supports sorting on multiple > fields, the behaviour can be described by the following two rules: > > 1. If you click on a header, it is made the primary sort field > (with others moved down the list as necessary). > > 2. If you click on a header that was already part of the sorting, > the sort order for that field is reversed. > > Item 1. is behaviour we agreed on, and item 2. is too, kind of, but the > latter is the one I'm interested in tweaking. > > Currently, this means that if, for example, you do: > > 1) Click 'first name' header > 2) Click 'last name' header > 3) Click 'first name' header > > you build up the following sort: > > 1) Sort by first name ascending > > 2) Sort by last name ascending, then > first name ascending > > 3) Sort by first name *descending*, then > last name ascending > > It is this last step that might need improving. Is it confusing that you > end up with first name *descending*? > > We could change the 2nd rule to: > > 2. If you click on a header that was already the primary sort field, > the sort order for that field is reversed. > > I think this might be more intuitive. Comments? > > Luke > > -- > "Where a person wishes to attract, they should always be ignorant." > (Jane Austen) > > Luke Plant || http://lukeplant.me.uk/ > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Adding UI and UX fields to Trac
UI: "The sorting icon is ugly." UX: "Sorting is confusing." That being said, I agree that most people won't be able to make the distinction. I'd say that we should just add a single boolean flag. I don't want to call it "Design" so as not to confuse people with DDN tickets. "UI/UX"? "DesignHelp"? I'd be happy with any of these. Again, my practical goal is to having something I can use to filter trac, and a visible signal to non-code contributors that we desire their involvement. -I On Wednesday, June 8, 2011 at 8:34 AM, Julien Phalip wrote: > On Jun 8, 12:25 am, Luke Plant http://cantab.net)> > wrote: > > On 07/06/11 11:32, Idan Gazit wrote: > > > I'd like to propose adding two flags to Trac, "UI" and "UX". > > So would it be better to have just "UI/UX"? > > I totally agree that Trac needs something specific for this, as it's a > shame we have to remove admin-related tickets from the contrib.admin > component. > > I also agree with Luke that having two different fields could be > confusing. UX encompasses UI so both are not completely orthogonal > from each other. How about a single "User experience" flag? Or maybe > something more explicitly targeted to the end goal, like a "Needs > designer's talents" flag? > > Julien > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal: Adding UI and UX fields to Trac
Greetings, Earthlings. I'd like to propose adding two flags to Trac, "UI" and "UX". The impetus for adding these new fields is twofold: I'd like some hooks that I can use to keep track of tickets related to design issues, but more importantly this will allow me to say "Designers: here's where you can help." I've considered other approaches (besides adding new boolean fields), they all have issues: * New components: orthogonal to the flags. If there is a UI bug in the admin, the component is still the Admin. Changing the component to "UI" would be discarding relevant information. * New type: also orthogonal. UI feature vs. UI enhancement. * Keywords: doesn't do any harm, but suffers from balkanization (everybody comes up with their own keyword). Also reports with "keyword contains 'UI'" find any ticket with 'UI" anywhere in the keywords string, like "login_required". -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: remove "Change" links on admin index page
On Tuesday, May 24, 2011 9:48:43 AM UTC+3, Anshuman Aggarwal wrote: > > However, as in all deprecation, I would suggest that we start with a > global setting that allows these links to be hidden on an installation > by installation basis and the default made to true for now. > -1, if only because we shouldn't add settings that are truly necessary. I don't think this case warrants Yet Another Setting. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: remove "Change" links on admin index page
I agree that it's redundant and unnecessary, but absent a particular *need* to remove it, I'd say leave it until the admin gets an overall refresh. While having two links may be marginally confusing for new users, _removing_ an existing bit of functionality is akin to a breaking change, IMO. It's not that we shouldn't do it, just that we should treat it with due gravity. If we're going to break user expectations, let's do it as part of improving the admin. The index page isn't suffering from a lack of whitespace. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ANN: Django 1.3 released
Three cheers for the release team! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Benevolent Dicta^H^H^H Designer for Life
And lo, the core team spake amongst themselves, crying: "Who shall take up the mantle of designer among us? Wilson departed many moons ago for the land of Rdio, and the people cry out for one to provide succour to those who want a more beautiful Django, and yea, a Django that listens to their needs." -- The book of Django, 22:4 Recently, I was approached by the core team about joining them to help address design issues within Django. I'm excited to announce that I've accepted! I've long felt that one of Django's greatest assets was Wilson's involvement early in the development of Django. It led to a sensible separation between the concerns of python and frontend developers, a template language that is (warts and all) a pleasure to use, and an admin interface which was light-years ahead of its time. In the same way that good documentation and tests emit a pleasing smell for passing developers, these features make Django pleasing for designers because they broadcast a message: "your needs are anticipated; your kind is welcome here." Sadly, Wilson is super-busy, and Django hasn't had an in-house designer advocate in a while. From now on, that's me! I'm here to shepherd efforts touching on UI/UX issues with Django, solicit feedback, engage designers, and break up bikeshedding whenever it stands in the way of Getting Things Done. High-Level Goals 1. Figuring out how to best hear the needs of designers in our community, and advocating for solutions which address those needs inside Django. 2. Figuring out how to attract a community of design-oriented contributors to Django. Right now, contributing to Django is really about contributing _code_ to Django; everything from the tools to the process are geared towards the sensibilities of developers. I'd like to find a system that will facilitate the collection of feedback from the community of designers using Django. Furthermore, there's no reason why we can't foster a vibrant community of designer contributors alongside the existing code contributors. This is an opportunity for Django to lead the way in showing that the efforts of designers are welcome (and sorely needed) in the open- source world. Some Practical Tasks The Admin - The most obvious user-facing aspect of Django is the admin. It is getting long in the tooth, and I've been witness to several fruitless attempts to initiate a refactor. The truth is that the admin is a relatively large chunk of code which (in the main) "just works". Simply ignoring it while starting a ground-up rewrite is a recipe for two failures. Incremental improvements and bugfixes are the way forward on this. A fresh coat of paint for the admin could count as an incremental, though cosmetic, improvement. That being said, it's time to start considering what a rethought admin might look like -- less in terms of visual look'n'feel, more in terms of what audience the admin serves, what use-cases it should try to address, and how best to serve that audience and those use-cases. I have some thoughts on the matter (which I'll share in a separate thread), but this is an opportunity to get UI and UX contributors to the table. Whether and how to rewrite the admin is a decision we can only make after we have a good idea of where we want to go. To that end, I'll be setting up some tools for collecting feedback over the next few days, and will announce them here. Learning from existing efforts in this space (Grappelli and django-admin-tools spring to mind) is a pretty good place to start. Finally, I'm skepctical that a "newadmin" can be realistically completed in the 1.4 timespan. With the exception of incremental improvements, the newadmin process is a long-term thing, which means we need to think about how it can be developed without interfering with Django's release cycle. Forms - Another topic ripe for some love is Django's forms API; it is an area where the bright line between Python and frontend code gets blurry. Form widgets are a good example of this: their HTML is hardcoded in a Python file, replacing them requires writing more Python, and they default to XHTML-style tags, causing conflicts for sites with non- XHTML DOCTYPEs. I'd like to make this a goal for 1.4; there are already some great developments in this space: * http://groups.google.com/group/django-developers/browse_thread/thread/7cc4279367c0a3f0 * https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas Endnote === This is a beginning; obviously the list of issues I haven't written about eclipses those above. Take this opportunity to get your wishlists in order. If you've got a relevant project that I've neglected to mention, don't get upset. Keep an eye on the -dev mailinglist for announcement of resources we'll be using to track existing code and new ideas. Finally, if you know of somebody that might be interested in contributing to Django in a design capacity, ple
Re: Proposal: Revised form rendering
Russ/Carl:
Finally got a chance to catch up on the thread, and found Carl penned
a (lovely, much more detailed) version of what I had in mind.
In the end, forms is a repository of unusually common fail because
designers must figure out Python and a lot of how django works in
order to customize forms. One of django's strongest assets is the
separation-of-roles philosophy, and this is a common use-case where
that philosophy is not implemented.
As a general design goal, improving forms should be about moving
Django towards a state where designers do not need to write python in
order to customize how forms render.
A big +1 on the template approach.
-I
On Jul 12, 10:24 pm, Carl Meyer wrote:
> Hi Russ,
>
> First of all, thanks very much for this proposal! Form rendering has
> been a major pain point for us (thus the existence of
> django-form-utils), and improving it is tops on my 1.3 wishlist. I
> will also be at DjangoCon and eager to sprint in this area.
>
> Django has a really good template system. With template inheritance,
> includes, and overrides, it allows the designer I work with a
> remarkable amount of flexibility in producing exactly the HTML he
> wants, without repeating himself. He's not a programmer (and thus
> doesn't follow django-developers), but he works full-time with the
> Django template system and loves it. His (frequent) complaints to me
> about Django form rendering are always the same: "Why is this markup
> generated deep inside Python code, and why can't I override a template
> to fix it? I thought we'd moved on from PHP!"
>
> I think it's possible to solve the problems you're aiming at here
> without so much new Python machinery, just by delegating more to
> templates (as Eric and Danny have already mentioned briefly). HTML is
> the native language of web designers, and I'm firmly convinced that
> the less we hide their HTML behind Django-specific abstractions, the
> more usable the system will be.
>
> I'll first outline in brief what I think a fully template-oriented
> approach might look like, address some possible concerns with it, and
> follow that with some specific comments on your proposal.
>
> A fully template-based approach to form rendering
> =
>
> You have a form object in your template. You render it using a simple
> "render_form" filter:
>
> {{ form|render_form }}
>
> "render_form" just renders a default form rendering template (at some
> sensible template path, the bikeshed could be painted
> "django/forms/default.html" or some such), with the form object itself
> passed into the context.
>
> This template just does the usual iterating over form fields, and the
> default one provided by Django could mimic form.as_table(). That
> default template could of course be overridden for any given project,
> and the "render_form" filter also accepts as argument an alternative
> template to use for a particular form:
>
> {{ form|render_form:"path/to/my/form_template.html" }}
>
> So far, this approach is workable in current Django. This is what
> django-form-utils does, and what we do in all our projects.
>
> The next step is to have the default widgets render themselves using
> templates found at a standard path
> (e.g. "django/forms/widgets/textinput.html"). This template would be
> passed the boundfield and widget, and so would have access to all the
> information it needs to render itself correctly.
>
> There would also be a "render_field" template filter, that would
> optionally accept an arbitrary widget template path:
>
> {{ form.fieldname|render_field:"path/to/my/widget_template.html" }}
>
> Normally this would only be used inside a form rendering template, but
> if you wanted to skip the "render_form" filter and render your form
> directly using this filter repeatedly (or inside a loop), that's
> possible too.
>
> All of the problems you identified as targets are now trivially
> solvable, just by giving the designer direct access to the template
> system, without all kinds of magical abstractions in between. Form
> layouts can be fully controlled in templates. Widget markup can be
> fully controlled in templates (and of course can validate to whatever
> doctype you want it to, without any special machinery for that).
>
> The last target you identified, allowing widget-related JS to be
> rendered in a block at the bottom of the template, can be solved
> simply with another filter and set of templates:
>
> {{ form|render_form_js }}
>
> Which would look for templates such as
> "django/forms/widgets/js/textinput.html" for each widget in the form,
> rendering nothing for a widget if that template doesn't exist. This
> filter could also optionally accept a path to a template containing
> form-wide JS. These templates would probably just contain script tags,
> either linking to an external JS file or containing inline JS. (IMO,
> collating these into a single script tag is out of scope and better
> handled by a dedicated sol
Re: Proposal: Revised form rendering
What a fantastic proposal. I have some concerns, but I'm not sure if
any of them have to do with my misunderstanding.
1. The {% load %} mechanism can get ugly, fast. What if I am rendering
multiple different forms on the same page? {% load %} {% form %} {%
load %} {% form %} feels mildly unclean to me. The only alternative
that comes to (my) mind is specifying an alternate renderer in the {%
form %} tag, but that will add yet another argument to a tag that
already has an unwieldy list of (possible) arguments.
2. The {% load %} mechanism is overloaded with two orthogonal
functions: doctype selection and custom rendering. If I write a
reusable widget that need some custom rendering fanciness, then the
logic for rendering the widget goes in one place (the widget class,
based on the doctype kwarg) but I have to provide several custom
renderers, one for each doctype. Seems inconsistent to me. I like the
idea of widgets being responsible for the widget and chrome being
responsible for everything else, but feel like the two concerns might
need to be represented individually. Doctype doesn't change throughout
the document, but renderers might.
3. Related to #2, what is the behavior of a Widget if I ask it for a
doctype it doesn't support?
I need to think about the renderer/chrome bits some more, will weigh
in again in the morning with a clear head.
-I
On Jul 11, 6:36 pm, Russell Keith-Magee
wrote:
> Hi all,
>
> I'd like to propose a few extensions to Django's form library for 1.3.
> I'm still working on some fine details, but before I get too far, I'd
> like to field opinions so that I can:
>
> * Discover any edge cases I've missed in my analysis
> * Field any criticisms from people with more design/frontend
> experience than myself
> * Determine any related problems that we have the opportunity to
> solve at the same time
> * Find out if there is anyone in the community who is interested in
> helping out.
>
> Apologies in advance for the length, but there's a lot of detail to cover.
>
> With this proposal, I'd like to address three problems:
>
> 1. The layout problem. Django's forms can be rendered "as_ul",
> "as_table" or "as_p", and that's it. These layout schemes can be
> overridden and customized if you know what you're doing, but it's not
> easy to do so. Furthermore, visual layout concerns aren't separated
> from data processing concerns. You need to write (and install) a form
> subclass to implement your own form layout. Although it's good
> app-writing practice to ensure that forms can be easily substituted,
> it's not an enforced or universal practice.
>
> 2. The widget problem. This is a variant on the previous point. A
> designer that wants to use a specialized calendar widget for a date
> field needs to modify form code. This is a complexity that shouldn't
> exist; a designer should be able to specify the widget library that
> needs to be used (with all it's required rendering requirements,
> javascript triggers etc) without modifying views and form processing
> code.
>
> 3. The DOCTYPE problem. Most importantly, there is the closing slash
> problem, but the introduction of HTML5 also means that there are
> richer input types like that aren't available in
> HTML4 or XHTML1. Django currently outputs XHTML1 unconditionally, and
> has no support for the new HTML5 input types.
>
> To solve these three problems, I'd like to propose that we add (and
> promote) the use of a new approach to form rendering, based around the
> use of a new {% form %} template tag. This proposal has some
> similarities to a proposal made by in the 1.2 feature phase [1] -- but
> that proposal was only aiming to solve the doctype issue.
>
> [1]http://groups.google.com/group/django-developers/browse_thread/thread...
>
> So: What I'm proposing is that we introduce a new template tag: {% form %}.
>
> How does this solve the three problems?
>
> Layout
> --
>
> The simplest approach for rendering a form would become:
>
> {% form myform %}
>
> This would effectively implement the as_table rendering strategy, just
> as {{ myform }} does right now.
>
> If we want a different rendering, we exploit the fact that {% load
> %}ing a template library will override any template tags that are
> redefined. {% form %} would be defined as part of the default template
> tag library, implementing the 'as_table' strategy. However, if we load
> a library that also defines the {% form %} tag, that definition will
> override the base definition. If we want to use a custom rendering
> style, we can get that by simply loading a different renderer that
> implements that style:
>
> {% load custom_renderer %}
> {% form myform %}
>
> Django would ship with {% form %} implementations of the 'as_p' and
> 'as_ul' strategies, so getting 'as_p' rendering would mean:
>
> {% load xhtml_p_forms %}
> {% form myform %}
>
> {% form %} is just a template tag, but the default implementation
> would be designed in such a way that it could be easily subclas
Re: Trac workflow assistance (commiter feedback needed)
FWIW, I spoke with Alex the other week about turning piano-man into a more finished product. So long as core guarantees that they'll at least take a look at whatever is made, I'm +1 on rolling our own, and am willing to champion this project. I think having something we can easily shape to meet our process needs will be a Good Thing. A good ticket tracker helps devs paw through the pile of tickets and keep kicking the ball forward with a minimum of effort. Reducing the overhead on core will make those people's lives more pleasant (and free up their time for dealing with, you know, code.) Another benefit: one of the complaints I (anecdotally) hear all the time is that it is hard to contribute to django. Part of that is the high bar we set for contribution, and the (necessary) process we impose in order to prevent oopses, but I posit that a significant part of the feeling stems from people confusing a lack of activity on their ticket with a lack of activity. Making it easier for devs to update tickets will help, and providing some kind of dashboard on project stats will give us something to point to next time somebody throws their toys out of the pram because their pony isn't being seen to. I'll be in Berlin, and plan to sprint on piano-man there. Plan: 1. Figure out a handful of "most useful" tricks that trac doesn't accomplish, and adding those to piano-man. I particularly like the idea of baking in some behaviors like timed ticket death and other things that prevent a buildup of detritus and cut down on ticket gardening chores. 2. Put up a test instance with a dump of data from trac. 3. Kick the tires and see if it engenders interest. If people think it's awesome, we'll keep going. :) -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Where are 2.0 ideas/fixes being tracked?
I'm looking at http://code.djangoproject.com/ticket/12359, and (with some guidance from Alex_Gaynor), think that there's really two fixes here: a short term, backwards-compatible fix which removes the forced help_text appendage, and a long-term, backwards-incompatible fix which adds a help_text layer to widgets so they can carry around presentational help_text in addition to the field help_text which we already have. The short term fix is managed via trac, and I'll spare the details here as it's not really my question. The question is: where do we track these "only in 2.0" improvements? I looked in trac for a 2.0 version target, but there isn't one. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
Hey Wilson, I'm sure I'm not the only one who is delighted that you have some cycles to spare for Django. :) As this thread was about practical matters, I'd say the next step is deciding on a few things that we want to get done. Up at the top, I suggested setting out a few modest goals for 1.3 as a good place to start, with the assumption that by 1.4 the process would be self- perpetuating. 1. Do you have any such modest ideas that you'd like to see tackled as a means of jumpstarting design work within django? 2. Is there a particular process you think will be best for fielding these ideas from the community? If we use trac to field/keep track of these requests like every other, do we create a new component? A new component in trac doesn't sit well with me -- what would we name it? "Designer Needs?" What I'm trying to get at is that designers needs are not all visual, and our needs tend to cut across component lines. Take the following three examples: * Joe wants to improve an aspect of the admin's usability. How do we see Joe's ticket as a design request separately from bugs in how the admin gathers data to render the recent changes list (which is not design-related)? * Amy is exasperated from expressing simple display logic in a rat's nest of endifnotequals tags. She has an idea for a "smart if" tag, and lodges an enhancement ticket under the component "Template system". How do we identify her ticket as being design-motivated? * Ben is a technically-minded designer who has some good ideas for improving django's treatment of static media. He goes to file a ticket, but is unable to choose a good component. He sees a component labeled "Visual Design," but doesn't choose it because while his request represents the needs of designers, there's nothing visual about it. To be clear: I don't think design tickets need to be treated in any special manner, just easily identifiable in some way. I'm sure there's more to be worked out but my brain isn't really there at the moment. More when it gets back on track. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
On Feb 7, 11:58 pm, "j...@jeffcroft.com" wrote: > You're right, Idan. Sorry if I steered it off-track! I sent Wilson a > message asking him to check out this thread. Awesome, thanks! > I think we first need to make sure we ARE going forward with this > whole "design czar" idea. Neither Alex nor Russ sounded particularly > keen on the idea (saying basically, "what's wrong with our existing > process?"), so I think we've got to have buy-in on the whole idea > before we can go about figuring out how to pick a person or team. Correct, hence my call for more core devs to chime in. I understand a default position of skepticism from Alex/Russ. It doesn't sound like anybody tried to approach this subject with the requisite amount of professional rigor, or maybe it was one of those things that stayed low on the priority list because nobody demonstrated sufficient critical mass/interest. I suspect that now might be the right time to give some attention to this part of the framework. Part of allaying the concerns of the core devs is demonstrating that we care enough about this to not lose interest when a core dev says "meh". I'm not advocating harassing the devs, but I do think that doing a little speculative homework and coming up with a rough plan will go a long way towards demonstrating that this isn't a fickle flight of fancy, but something we really think deserves consideration. I'm hoping that Alex/Russ will warm to the idea once a little meat is hanging on the bones of the thing. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
Just to steer the discussion back to practical matters:
1. This thread isn't about what stuff we want to do in the admin, or
whether grappelli is great. How to improve the admin or any other
aspect of Django which has design issues is a great discussion! It
just isn't *this* discussion.
2. *This* discussion is about how to bootstrap a design czar/team
within Django. Russ is on-target when he says that the next step is
getting in touch with Wilson and sussing him out on the strategy. I
could look up his email and just ping him ("Hi, you don't know me,
yada yada") but perhaps somebody with a more direct relationship
(Jeff?) could alert Wilson to this thread and ask him to weigh in.
3. What we haven't yet come to a consensus on how to bootstrap a
design czar/team if Wilson is out. I'll be pleasantly surprised if he
indicates his availability, but assuming that he doesn't have the time
or the desire, where do we start in selecting a design czar? Justin
Lilly's proposal to let a small team of prominent Django designers
select/elect a czar is fine by me.
Aside: "One vision" / Czar-vs-team:
Getting different people on the same wavelength is difficult. I'm
still +0 on single design czar because in my experience, an arbiter is
needed to "just make the call." Over time, a loose group of people
that trust each other and can share power responsibly may emerge --
much like how the Django core devs are now. But picking a group of
people to both adapt Django's development philosophy to the realm of
design and having them all implement it the same way sounds overly
ambitious to me. IMO, let's start with one person and see how it goes.
It is easier for all of the team to share a vision if the team selects
for it over time, just like how devs are given a commit bit if they
demonstrate compatibility with Django's dev process (and implicitly,
the philosophy).
Also, trust is an important aspect of the core dev team. I'd assume
that after a few months of working with the core designer, the dev
team would be more inclined to trust their judgment about who would be
a good fit for inclusion into the core design team.
4. More core dev opinions
We've heard from a couple of prominent devs, but I'd love to hear more
core devs chime in on the matter. Adding this design czar to the
roster of core devs is as much about the other core devs as it is
about this new position.
-I
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
On Feb 7, 6:06 am, Justin Lilly wrote: > I, for > one, am willing to trust their judgement on someone who can lead this > design-czar selection process, if Wilson doesn't come out and name his > successor, as it were. Something that hasn't been explicitly said yet: I *don't* think that the design czar necessarily needs to be a rockstar designer. Their job is not to design everything singlehandedly. Their job is to shepherd the design process within django core. Being well-versed in design is obviously a must, but I posit that familiarity with the community, core devs, and Django's development practices are more important for this role than being an A-list designer. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
Responses inline. On Feb 7, 2:26 am, "j...@jeffcroft.com" wrote: > 1. I wouldn't say "Wilson is out of the picture" without talking to > him first. Amen. I was under the impression that he's definitively out of the picture. If he can be lured back to the community, awesome. > 2. Is there value in having more than one "design czar?" As in, would > it be better to have a small team handling this rather than one > person? I thought about this yesterday as well. I am +0 on "single czar" for several reasons: * Design by committee almost invariably sucks / deadlocks. * The design czar is an arbiter, not a panel. Part of his/her job is to listen to the community and make decisions so as to prevent the design process from stalling. Note the "listen to the community" part -- I imagine that a few django-oriented designers will want to step up and have a hand in steering Django's design sensibilities. It's not up to the czar to write everything / design everything by themselves, but rather to foster this community of django designers. > 3. On the topic of Wilson: let's be clear that none of this is his > fault. He did a spectacular job on the admin interface, and never > formally received a "design czar" like position in the community that > I know of. He's busy like many of us, and he hasn't let us down at > all, in my opinion. Again, wasn't my intention to imply anything bad about Wilson. He's an amazing designer who created some very original things in Django, without somebody handing him a roadmap. On the contrary, I'm saying that the talents he brought to django are currently missing, and Django would do well to have somebody try to fill those shoes. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
A small addendum: One way to think about the design czar is someone representing designers' needs in Django proper. Arguably, we already had somebody in this role -- Wilson -- and now we have a fantastic template language and an admin which is still ahead of its time in many ways. We wouldn't have had either without a talented designer at the table. It sounds like Wilson is out of the picture, and thus vacated his de facto role as design czar. It might make more sense to think of this in terms of finding Wilson's successor than about starting something new. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django Design Czar
Hey folks, Splitting off from http://groups.google.com/group/django-developers/browse_thread/thread/ca4f26d616921753, which has an exhaustive discussion about how django needs to treat design work. In the spirit of taking action, I put together this list with Bryan Veloso. My goal is to spark a discussion that will lead to appointing somebody with a few clear goals. "Django Design Czar" Rationale * Good design, like good code, is hard to produce. * Reviewing design is outside the purview and abilities of the core devs. * The admin is dated, and in need of cleanup/refactoring. A good job would involve major breaking changes, and therefore fits more in the 2.0 timeframe -- but there's a lot of baby steps we can take to clean up the existing admin in the meantime. * Imposing django's sensibilities on the design process requires a "design czar" in much the same way as we have specific core devs "responsible" for large django subsystems. * Both the baby-steps and the 2.0 "ground-up" redesign will, like every other part of django, be much more likely to succeed with a designated parent to shepherd it into existence. * Django can take the lead in integrating designers, not just coders, into the development model of django. Responsibilities * Wearer of the "design hat." Will serve as the go-to for proposals and tickets that involve front-end code. * Serves as a "design arbiter" -- needs to be somebody that the core devs trust to make design decisions in the spirit of django's development process (relatively conservative, "does this solve a problem", etc). * See "Action Plan" below. Action Plan * Trivial changes, such as margin/padding corrections, should be fair game for committing outside of the normal release schedule, in the same vein as documentation corrections. * For 1.3, let's set some modest design goals as part of the development schedule. The community might not realize that submission of "design tickets" is something we're keen on without a little prompting. Design proposals are accepted/voted upon like other features on the 1.3 table, but we need to help jumpstart by seeding the list with some (modest) design proposals. * For 1.4, design proposals are accepted/voted upon like every other feature. Hopefully by this timeframe, the design czar has become visible enough that django is fielding quality design proposals without prompting. * In the 2.x timeframe, design czar should coordinate the effort to reimagine the admin. It will likely be a long-term branch of django much like multi-db was, as this won't likely be an evolutionary thing. * Hopefully we'll gain a lot of wisdom during the 1.x refactors that we can apply towards the 2.x ground-up rewrite. "What are some good targets for 1.3?" Off the top of my head: * Importing some of the good work done for django-grappelli, in particular leveraging the fact that we have jquery in the admin now. * Applying a grid to the admin, even if we don't make significant changes to the overall "look" -- this would set the stage for further changes in 1.4. * Anything which will send a signal to the community that we're putting a Real Process in place to keep the admin state-of-the-art (while not sacrificing Django's stability/compatibility pledges). Thoughts? -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Refining Django admin look proposal
Hey folks, 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 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 wrote: > > > > > I went ahead and replied to this on my blog[0]. I'll copy it here for > > completeness. > > > [0]:http://ericholscher.com/blog/2010/feb/6/role-designers-django-community/ > > > 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 > > inclu
Re: 1.2 Proposal: django debug toolbar in contrib
On Aug 18, 12:35 am, Dave Jeffery wrote: > (Sticking my nose in where it isn't wanted...) The toolbar looks really > great but it feels a bit over-designed and too heavy for a functional > interface which will sit atop of existing websites. I'm especially referring > to the typography, the uppercase serif lettering seems inappropriate for > this type of interface. Point well taken. I just get tired of being tuned into the "All Helvetica... all the time" channel and wanted something different. Serif is the new black. :) But if we're aiming to match existing styling then Helvetica or its bastard stepchildren are indeed appropriate. -I --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
On Aug 17, 4:28 pm, Jacob Kaplan-Moss wrote: > I'd say a similar ethos should be expressed in the debug toolbar branding. > If you wanted to be extra special, some UI similarity between the > error pages and the debug toolbar would probably be a good idea. Fair 'nuff. I'll squash the last remaining bugs and take a peek at the debug page CSS. -I --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
Oh, forgot to include the screencast: http://s3.pixane.com.s3.amazonaws.com/ddt-ui-refresh.mov -I --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
I've been working on prettyfication of the DDT. Github: http://github.com/idangazit/django-debug-toolbar/tree/idan-ui-rf. It's a reasonably complete reskinning of the existing DDT. There are still a couple of outstanding issues but the redesign is largely finished. I didn't use the admin color palette because A) it's fugly and B) I think making the DDT consistent with an optional-and-completely- separate-contrib-tool is synthetic and meaningless. End users of the admin are not the people who will be using DDT, and developers are not the core audience for the admin. I'd argue that they're separate enough, but I'm not religious about it. I also have some ideas for enhancement, but having read this thread I'm hesitant to develop if they will jeopardize inclusion in contrib. For example, syntax highlighting of templates (might introduce a dependency on pygments) and some tasteful animation of panels (would require jQuery). I'm keeping tabs on what to work on at http://github.com/idangazit/django-debug-toolbar/issues. After prettyfication I'll take a look at tests and docs. Generally, I think an attractive-looking debug toolbar is fodder for a thousand "django is teh awesum" blog posts. There are few "human- facing" parts of django that are screenshot-able, we should make the ones we have look amazing. Advice on how to proceed appreciated. -Idan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
