What can I do for Mozilla?
81–85 of 85 posts
Re: What can I do for Mozilla?
#82Re: What can I do for Mozilla?
#83If you select PHP, you get "So you like your variable names to include dollar signs? That's cool, everyone misses Perl once in a while." Making smartass remarks about their language of choice is not a great way to initiate a relationship with a developer.
Re: What can I do for Mozilla?
#84Earlier quoted context omitted.
The remaining quotes: C++: "So you like long compile times and incomprehensible error messages? That's cool, we do too" Java: "So you're a believer in AbstractMethodFactoryBeans? That's cool, we all have our vices" Python: "So you enjoy the paradigm of backtrace-driven development? That's cool, everyone gets a bit tired of static typing once in a while" C: "So you think OOP is for hipsters? That's cool, we all get no…
The author of the site works on Rust ;)
Re: What can I do for Mozilla?
#85Earlier quoted context omitted.
I started writing a response about my experience as a designer at Mozilla and it got really long and I turned it into a blog post called "Code talks and designers don't speak the language." Thanks for inspiring me to come out of blog hibernation. http://skinnywhitegirl.com/blog/code-talks-and-designers-don...
Good blog post. Concerning point 3: "Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works…
You're implying a value judgement that code is an objective discipline and design in a subjective discipline. There are aspects of visual design that are subjective. However, UX is a testable, repeatable, objective discipline that is informed by the work of cognitive science.
Yes coders have arguments... with coders. They have inside baseball arguments. It's entirely different than a designer having an argument with a coder. Often, the designer has to teach the coder the principles of design in order to even engage in a logical, productive discussion.
The overriding point I was making is that the tools like github are designed for code, not design. Our tooling inherently advantages code. It's a pain in the ass to even insert an inline image into a comment. Github isn't built for evaluating mockups and wireframes. Designers do our best to bootstrap into the tool, yes. But it's not our tool.