Public

Think before you npm install

instead of doing it automatically every time, let’s take the time to pause and consider whether we really need to.

The important bit is that they hinder deep learning of CSS. This is not to say that every developer needs to have intimate knowledge of CSS when launching a personal project, but that major businesses need to invest in hiring front-end designers that specialize in this area. Many self-proclaimed full-stack developers don’t know how to write good and/or modern CSS. Hiring and promotion evaluations require developers to show deep skill in a variety of languages, but CSS is not often included. For many engineering teams, design is just a flourish, and a developer with rudimentary skill in CSS is good enough as long as they can tack on a framework that takes care of most of the heavy lifting. That heavy lifting, unfortunately, doesn’t account for the human time and care needed for things like accessibility. The joke for many designers is that it’s incredibly easy to see what kind of site uses something like Bootstrap because no effort was put into customizing it.

There are surely plenty of people of marginalized gender experience in all programming spaces, but they don’t have as much opportunity to surface new ideas. CSS is only allowed some slight breathing room simply because other programmers don’t even consider it to be part of web development. The distinction is even clearer when you consider the differences between front-end and backend salaries. CSS having any validity in the field while maintaining its feminine image is a threat to the notion that programming is a masculine exercise.

CSS being a feminine language isn’t a bad thing. Quite the contrary, I’d argue that all programming is feminine as it was pioneered by women (who were then pushed out by men). And while the web development community is still very much governed by men, a larger portion of the top voices in the front-end space are more feminine-identifying than in other areas. Consequently, these same voices are the ones that are brigaded with hate after daring to disagree with dominant ideas.

We need to identify exploitation. While there are some gleeful Full Stack Developers, many are computer scientists given too many responsibilities, and over things for which they are not willing or qualified to be held accountable.We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.We need to revisit the separation of concerns principle. We simply can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.Most of all, we need to educate people who don’t code at all just how many different things different types of code can do, and how different each is to understand and write. Hopefully, this way, more of us will be writing the kind of code that suits us best, and not spending our time anxious and demoralized because we don’t know what we’re doing, or we simply have too much on our plate. That’s not to say that if you do take to JS, CSS, HTML, SQL, and C# you shouldn’t be writing all of them if you‘d like to and you have enough time!

I believe the root of the problem is using the name Design Token for experimental approaches while a group aims to define what it means to be a Design Token. These other formats do not follow the specification in small and large ways and are therefore not accurate in describing Design Tokens as we expect them to be used in the community universally. Rebranding these novel approaches as something else for future features (as Figma has done) would make the expectations and responsibilities of Design Tokens more understandable to the community moving forward.

unnecessary rework of both design and code is nearly guaranteed, and the monetary costs are high. The Dev Ops Research & Assessment Group calculates that for a medium-sized business at a medium level of technical performance, upwards of 37.8M is lost to unnecessary rework each year.

Forrester Research quantified how much cheaper it is to find and fix problems earlier in the build process, with costs 30 times higher if fixes happen after work ships.

starting with a Double Diamond design process, then shifting to the build phase with iterative engineering sprints:In No Handoff, discovery, and development phases happen in iterations with the involvement of an interdisciplinary team:Discovery is not conducted solely by the UX and Design team, nor compressed into a single sprint. It takes place in cycles as the team tests the prototype with users and gains more insights.Definition is when decisions are made on what to prioritize, and what to work on next. Basing these decisions on the latest rounds of feedback further reduces risk.During Develop/Deliver stages, both design and functionality emerge side by side, informing one another. In this way, designers avoid specifying needlessly expensive directions or components or designing things in detail that don’t have value or won't be built. Engineers avoid building functionality ahead of validated business needs, and also avoid unnecessary rework due to unexpected redesigns.

This iterative process clearly reduces risk, but other benefits are more surprising.Teams develop a shared vocabulary, tooling, and cadence, closing the gap between engineering and product.The voice of the end user is elevated; design and function co-emerge based on real usability needs. Traditional project handoff precludes the possibility of continuous listening, while the No Handoff Method is built around it.Designers are working directly on the product design, not on throwaway artifacts.Onboarding is happening continuously with end users during frequent testing phases. This further reduces the risk of users (or other stakeholders) unexpectedly rejecting the end results.Iteration and frequent user testing can give Marketing and Sales teams invaluable insights in advance of releases.An atmosphere of trust is built as developers and designers become comfortable openly sharing work earlier in the ideation phase without fear of reprisal for mistakes or imperfections.Leadership and end-users trust that they are being heard, too, because they see and experience the results of their feedback in future iterations.Trust allows teams to develop a culture of learning, continuously improving the product.

Design decisions have to be informed by technical implementations and its limitations. There is no universal language around design patterns and their interaction design either. And not every design detail can be implemented in an accessible and performant way. This is why beautiful mock-ups turn into painfully slow and inaccessible monsters.

In Ettie Bailey-King’s article “Disability is not a dirty word“, she reminds us that it’s okay to say the word “disability” because disabled peoples’ lives aren’t tragedies. There’s nothing to sugar-coat with euphemisms like “special needs.”

People are disabled by structures. A wheelchair user is disabled by design choices, like buildings without ramps. The problem is social systems, not people’s bodies. Disability is a mismatch between a person and the environment they’re in.

Disability is a spectrum and may be permanent, temporary or situational: From Microsoft Inclusive design Disability is the largest minority group there is and it’s the only one that we can enter at any time.

Disability is not a monolith and there is no singular disabled experience. Some areas of intersectionality with disability include: Race Gender identity Sexual orientation Size Socioeconomic status The experiences of a Black disabled person will vary from those of a trans disabled person or a poor disabled person in meaningful ways. Disability also intersects with every aspect of someone’s life: Employment School Family Community Mass incarceration

aid accessibility efforts, we can incorporate inclusive design. Inclusive design principals seek to create solutions that are usable by a wide range of people. There’s a saying in the disability community: Nothing about us without us. This means that our design process must include disabled people. We need to hire disabled people to create and build solutions. We need to pay disabled people for their feedback on how our solutions can work better for them.

Disability is never a barrier. Design is.

design happens in a thousand little ways every day by non-designers. When folks choose the order of items on their restaurant menu, or make the newsletter for their community theater, or rearrange their living room to flow more naturally, they’re thinking about a system and enacting improvements to it. These are just people, though — they’re not necessarily academics nor are they necessarily not, but despite the lack of training in or even awareness of design thinking and discipline, they’re doing design.

Just create a lot of options and then pick the best one. But why is that so hard? Because for each of those two steps we need to be in a different mood.

We have to step outside convention and disrupt our normal way of thinking.

Knowledge is the raw material for ideas.

shut the censor up: Focus on quantity! For example, make it a game to come up with 100 stupid ideas in 10 minutes. Then we simply don’t have time to judge. And this opens the floodgates for our crazy creative mind.

Ideas are attracted to laughter.

I have no doubt that AI can and will harm people… today, tomorrow, and well into the future. However, I also believe that we can acknowledge that and, with an eye towards accessibility (and, more broadly, inclusion), make thoughtful, considerate, intentional changes in our approaches to AI that will reduce harm over time as well. Today, tomorrow, and well into the future.

The questions I wished I had asked myself back then are: What are the risks of making a change? What are the risks of not doing so? How might you mitigate those risks? What’s a small, experimental step you can take, right now? Not tomorrow or next week, but this hour, this minute?

And: how do you want to be in your work? This is different from what you want to do. How do you want to show up, to be present, to experience the work? What needs to change (in you, or in your environment) for that to be possible?

I have to remember that my health is more important than my job. And the pain that you’re used to is still a pain you should run away from. A pain to be extracted. A pain to quit.

Nvidia Should Sell GeForce.