This post is flawed because it artificially separates accessibility from design, and it treats design as if it only has to do with aesthetics. Design encapsulates accessibility, and and good interaction designer will put accessibility high on his/her list of priorities.
On Feb 7, 10:34 am, h3 <hainea...@gmail.com> wrote: > > unless I've missed something whoever gets the position, would > > definitionally get it before they've done anything! > > I strongly suggest you should take a look at grappelli ... some people > *are* doing things ;) > > > In conclusion, there is 0 reason design needs to be treated different from > > a procedural perspective. > > Design is not unlike code, it gets better with a democratic process > and iterations. But the comparison stops there. > The rest is not procedural at all. The only thing you might call > procedural is the prototyping process. The rest is > only a feedback loop. > > That said I'm not fond of the term "Design Czar" in the sense that it > put somebody in a place where he was power > over others on something as personal as taste. And even then, the line > can be blurred because an interface (web or > application) can have a beautiful design and be totally unusable or it > can also be really usable and have an horrible > design. > > Achieving both on the web is no small feat with the plethora of > devices, screen sizes, browsers etc.. Your > design must be good looking but not too trendy if you want it to last > more than a year. > > For some people design is more important than accessibility and it > might cause some friction since both are related > to a very personal experience. The kind of friction that generates > mile long threads over whether or not pale text over > black a background is considered bad practice. UI design is almost a > science, but in which there is such things as > feelings and emotions. > > That said I fear that a "Design Czar" will only do more harm than good > on the Django community. I think what the > Django admin app really needs is some kind of Interface Design and > Accessibility Committee that would consist > of one or more lead designers and a team of accessibility geeks. > > Then you put them all in a small room with a plastic spoon and lock > the door. > > Seriously, yes design is important, but it's also ephemeral. What > looks good today will look old and clunky tomorrow. > > On the flip side, accessibility is something that evolve but big lines > does not changes much. It's also something that is > far more subtle than design. It's not something the average developer/ > designer is keen to work on without any issues > being raised by the end user. > > So in that regard, I think the Django team should concentrate on > giving a generic and accessible interface rather than a > "tasteful" interface. In order to be generic and accessible it's > necessary start with a clean and semantically meaningful > markup and unobtrusive JavaScript that degrades well. > > Once you have that you can change the design every year if you want > to. Not that I would suggest to, but programmers > must realize that designs and trends have a much shorter life cycle > than code and thus can hardly be "threated like code", > but accessibility can. > > Or let me put it the other way around: Would you like a framework with > the most awesome design you ever saw, but you just > can't change it much without pain and accessibly is only "OK" .. or a > framework that is really generic and accessible with an OK > design but that you can customize easily ? > > Regards, > > -- > > Maxime Haineault > Consultant Web / Associé > > ∞ Motion Média > http://motion-m.ca > m...@motion-m.ca > (450) 374-4822 > > On Feb 6, 7:56 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: > > > > > On Sat, Feb 6, 2010 at 5:03 PM, Idan Gazit <i...@pixane.com> wrote: > > > Hey folks, > > > > Splitting off > > > fromhttp://groups.google.com/group/django-developers/browse_thread/thread..., > > > 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 > > > athttp://groups.google.com/group/django-developers?hl=en. > > > I'm opposed to this. Firstly, unless I've missed something whoever > > gets the position, would definitionally get it before they've done > > anything! This is completely antithetical to the spirit of open > > source, meritocracy. Why should design be treated any different from > > other changes to Django? Changes to the design of the admin should be > > handled in the same way as any changes, for a large change someone > > writes up a proposal, starts work, asks for review, finalizes, and it > > gets committed. That being said there is no reason a designer > > couldn't have a commit bit, Wilson certainly does, but they'd have to > > earn it the same way anyone else does. We don't need a formalized > > process to get input from designers we trust, I ask for review from > > tons of people who have no formal standing in the Django community > > when I have questions that pertain to their area of expertise. > > > In conclusion, there is 0 reason design needs to be treated different > > from a procedural perspective. > > > 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 -- 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.
