The post Some Articles About Accessibility I’ve Saved Recently IV appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
- The perfect link — Rian Rietveld defines them: “When you click on them, they take you somewhere else.” Not much code in here (we’ve got that), just a lot of practical accessibility advice. For example, the
alttext for a linked image can allude to the fact that it is a link. Just an image: “A cherry tree in full bloom.” Link: “Wikipedia on cherry blossoms.”
- Google Announces Seismic Change to Docs — George Joeckel covers the unfolding news that Google Docs is going to be rendered in
<canvas>, which feels like a massive WTF moment when it comes to accessibility. At one point, the vibe was that there would be a separate product for people with screen reader needs. Separate but equal isn’t a good situation. Looks like the
<canvas>based rendering stuff is on hold for now, so community feedback FTW?
- Don’t use custom CSS mouse cursors — Eric Bailey:
I believe that letting CSS load a custom cursor was a mistake.
- Web Designers Grapple With Downside to Flashy Animation: Motion Sickness — Katie Deighton covers the idea that things like preference toggles and
prefers-reduced-motionexists (although not by name). Always interesting to see a topic like this makes its way to a major publication like The Wall Street Journal.
prefers-reduced-motionand browser defaults — Speaking of
prefers-reduced-motion, Bruce Lawson on the paragraph-of-the-year:
Yes, it was a meeting request from Marketing to discuss a new product page with animations that are triggered on scroll. Much as a priest grasps his crucifix when facing a vampire, I immediately reached for Intersection Observer to avoid the browser grinding to a halt when watching to see if something is scrolled into view. And, like an exoricst sprinkling holy water on a demon, I also cleansed the code with a prefers-reduced-motion media query.
- Using CSS to Enforce Accessibility — Adrian Roselli covers this great tactic where you don’t get the proper CSS styling unless you’ve also implemented the appropriate accessibility attributes (e.g.
[role="region"][aria-labelledby][tabindex]for a scrolling table). This is a powerful idea and happens to showcase the power of CSS nicely in a way that styling solutions that avoid using selectors don’t benefit from.
- Accessibility testing with Storybook — Varun Vachhar covers how you can run Axe over your component library even as you code. Accessibility issues, like color contrast problems, are bugs. Might as well give yourself the same tooling opportunities to fix them at the same time you’d fix any other bug.
- Making A Strong Case For Accessibility — Todd Libby covers how you can fight for accessibility at work. Attempt 1.) Ethical. Attempt 2.) Financial. Attempt 3.) Legal. 4.) Humanization. Attempt 5.) Don’t ask, just do it.
- Your Image Is Probably Not Decorative — Eric Bailey covers that most images with an empty
alt="", no space) probably should have had one, and that when and alt description isn’t available, there are other options (e.g. make it available as an inline image (
spacer.gif) even if it isn’t one otherwise,
<title>in SVG, etc.).
- Writing great alt text: Emotion matters — Annnnd speaking of
alt, Jake Archibald learns from a 2011 Léonie Watson article:
The relevant parts of an image aren’t limited to the cold hard facts.
- Creating An Accessible Dialog From Scratch — Kitty Giraudel takes on the final boss in accessibility.
The post Some Articles About Accessibility I’ve Saved Recently III appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
And maybe an optional follow-up if you’re up for it.
Automattic, the makers of Jetpack and many other WordPress-y things, have sponsored my site (me = Chris Coyier; site = CSS-Tricks) for quite a while. I use Jetpack myself, and I’m always trying to tell people about its features and benefits.
Yet I get the sense that there is a decent amount of hesitancy (or even general negative feelings) toward Jetpack. I want to hone in on that and understand it better. This will be useful for me in my attempt to be a good sponsoree, and useful for Automattic to improve Jetpack.
- “Good news about display: contents and Chrome” — Rachel Andrew notes that the accessibility danger of using
display: contents;is fixed in Chrome. The problem was that, say you had a parent div that is laid out as a grid and inside you have a
<li>elements, and you wanted the
<li>elements to participate on that same parent grid. We have subgrid, but it’s not really the same thing. What you want is just to pretend like the
<ul>isn’t there at all and that the
<li>elements can hang out on the grid like anything else. The problem was that if you did that, you wiped out the accessible semantics of the list. But no more!
- “Grid, content re-ordering, and accessibility” — Speaking of grids and accessibility, here’s Rachel again teaching us (through this slide deck) how it’s all-too-easy to really diverge the source order and display order of content with modern layout techniques. At the moment, the solution is essentially not to do that, but the future might hold a way for browsers to update tab order to be visually sensible when you do dramatically alter the layout.
- “The most useful accessibility testing tools and techniques” — Atrem Sapegin lists out some good ones, like eslint-plugin-jsx-a11y, storybook-addon-a11y, cypress-axe, Contrast app, Spectrum browser extension, and… using your tab key (lolz).
- ButtonBuddy — Tool from Stephanie Eckles that helps generate CSS for buttons. But the real point of it is to give you colors as custom properties that satisfy color contrast guidelines.
- “Are your Anchor Links Accessible?” — Amber Wilson goes through five iterations of an anchor link in/by a header before landing on a good one and, even then, there are questions to tackle.
- “Don’t put pointer-events: none on form labels” — I’m a little shocked that anyone would do this at all, but it turns out it comes from Material Design’s “floating label” pattern. I think that pattern is so silly. It doesn’t actually save any space because you need the space where you float the label to anyway. Gosh.
- “Accessible Text Labels For All” — Sara Soueidan tests real accessibility software and how it presents common interactive elements. For example, a “read more” link isn’t very useful (read more what?), and “add to cart” isn’t very useful alone (add what to cart?). You can add, for example, product names to those “add to cart” buttons, but don’t do it in the middle of the button as that can break things. Add the extra text at the end.
The post Some Articles About Accessibility I’ve Saved Recently appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
I’ve been a manager for many years at companies of different scale. Through these experiences, I’ve done my share of learning, and made some mistakes along that way that were important lessons for me. I want to share those with you.
But before diving in, I want to mention a strong caveat that my advice may be unique to my situation because I’m white and a woman in tech. My experiences may be relevant to that point of view, but your mileage may vary.
Another huge caveat: I’m sharing mistakes I’ve made so far in the interest of helping others, but I’m sure I’m not done making mistakes, either. I don’t have it all figured it out, I’m still on this journey.
Mistake 1: Thinking people give feedback the way they want to receive it
Feedback is one of the most important tools you have as a manager, but it can also be incredibly disruptive with poor execution. One of the hardest things I’ve had to learn is that humans aren’t pure functions: you can put a form input in front of them one day and get one result, then again another day and get an entirely different result.
The same is true of how people give and receive feedback: someone may give you feedback in a particular way, but they prefer to receive much differently when it comes to themselves.
How do you get around this? Asking helps. I’ve started doing an exercise with my team where I ask the group as a whole how they would like to get feedback. Not only does it open up ideas, but it also helps that each individual has to think for themselves how they prefer to receive feedback. Normalizing this type of vulnerability and self-reflection can help us all feel like partners, instead of some top-down edict.
Another thing that’s helped? Asking folks directly in a one-on-one meeting if they have feedback for me as a manager, and following up with an anonymous survey. Again, it makes things feel less one-sided and provides everyone the opportunity to say things that they might not want to say directly to my face, which I know can be tough.
And lastly, if something comes up, addressing it immediately can be helpful. There’s nothing worse than your manager having an issue with something you did and only finding out about it three months later, especially if it’s tied to a performance review that you could have impacted had they been transparent earlier.
The truth is that even my advice here is imperfect. Feedback is tough. Being honest and improving together as a team is awkward. It’s incredibly worth it, though. That’s where the real growth is. That said, no two people are alike, no two groups are alike, and you may have to use your best judgement given the situation at hand.
Mistake 2: Trying to do everything yourself as a manager is the best way to help
Years ago, I managed a woman who was bright, talented, capable, and an all around pleasure. She was sort of new to the industry and could come across as timid, so I did my best to be a poop umbrella for her, fighting battles behind the scenes to set her up for success. She was on a steady track to land a senior role. Even after I decided to leave the company, I let the next manager know this person is track for a senior position in the next few months.
Then I moved to another city. Years later, I met up with the woman and was shocked to learn she never got the position.
Here’s what I learned: her promotion wasn’t the same high priority for the capable hands I left her in as it was for me. The team was challenged with a million other things that took center stage to the extent that her promotion fell off the radar. But even more than that, what became very clear to me was that all of that “protection” I thought I had set up for her didn’t really serve her well for the long haul. For example, I didn’t teach her how to advocate for herself or how to navigate the system. I vowed never to make that mistake again.
This is tough! If you’re strong and care about your team as people, it can feel very unnatural to teach someone to advocate instead of moving things out of their way themselves. And the point is not to throw that person into the fire. The point is to care. Are you teaching the things they need to learn? Are they really growing under you? Feeling like you’re protecting someone at all costs also lead to your own ego trip, too, which threatens progress.
Try to think through what skills someone needs to succeed without you. Teach those things incrementally. Sure, this is easy advice to say, but it’s really hard to do in the thick of things. Spend some time with it, and think through ways you can inject that learning into everyday work and interactions.
Mistake 3: Communicating something one time is enough
No one likes to feel like they’re repeating themselves. It’s annoying to say someone more than once, and it’s annoying to hear something over and again. But if you have a big enough group and there’s enough going on, things are going to slip through the cracks, so repetition becomes an important tool to make things stick. The trick is to say the same things, but in different ways.
There was a time last year when I asked my team to do something and none of them did it. What happened there? Given that it’s a team of highly efficient, strong collaborators, do you think they just all table-flipped and didn’t take action? Not a chance. I was the one who wasn’t clear. In fact, you can probably guess that if a whole group of people don’t understand or take action, the chance is that you, the manager are the common denominator for why something is blocked. Not only did I not repeat myself enough to be clear, I didn’t align anyone with the why of the purpose of the task. It’s pretty easy to forget or not prioritize doing something if you have no clue why you’re doing it. Repeat yourself and align the group with the importance of the task and you’ll likely have a better result.
Think of all the ways we have to communicate these days: chats, emails, video meetings, texts, document comments, and so much more. And because some people communicate better in one medium than another, using all of the platforms have in various mediums becomes a strategy for repetition without nagging.
I’ve found that what work best is allowing everyone to own the information themselves. For example, if your team practices career laddering, each person they read the ladders aloud in a one-on-one and then talk you through their responses to each item. That way, you’re not lecturing — they are owning where they are and what the next steps are as you guide them along.
Mistake 4: You have to have everything together all the time
Some folks think that management looks like a steel fortress of preparedness and authority. I’m not so sure about that.
If something goes wrong, are you more likely to tell the manager acts as though they have everything together all the time, or the manager owns their mistakes? The truth is that your team needs to know you’re human. You can’t fix problems if you don’t know about them, and no one will tell you about them unless you make space for that.
One time, the night before a big release, someone on the team pushed a change that created thousands upon thousands of calls to a service that, in turn, thought it was the target of a DDoS attack, which then shut down our access. Here’s a moment when a lot of folks could have panicked and blamed one another. Instead, we giggled wildly, jumped into chat and on calls, fixed it, and kept going.
I couldn’t have been more proud of the team that day. Their response was wonderful. And it makes all the difference in how we work together, recover, and iterate.
You’re the manager. You have to be show your vulnerability first. You can try this by admitting you’re having a bad day, that you don’t understand something, or made a mistake.
Being a manager is tough. Your mistakes impact people. I’ve made all of the mistakes above and more. I feel that it’s critical to share and learn from one another, so when we encounter pitfalls, we don’t feel alone and know a path forward.
You can support CSS-Tricks by being an MVP Supporter.
- The React Hooks Announcement In Retrospect: 2 Years Later — Ryan Carniato considers hooks to be the most significant turning point in front end in the past five years, but he also says hooks have muddied the waters as well.
- Mediator Component in React — Robin Wieruch’s article made me think just how un-opinionated React is and how architecturally on-your-own you are. It’s tough to find the right abstractions.
- No One Ever Got Fired for Choosing React — Jake Lazaroff’s article is a good balance to the above. Sometimes you pick a library like React because it solves problems you’re likely to run into and lets you get to work.
- A React “if component — I kinda like how JSX does conditional rendering, but hey, a lightweight abstraction like this might just float your boat.
- State of the React Ecosystem in 2021 — Hooks are big. State management is all over the place, and state machines are growing in popularity. webpack is still the main bundler. Everyone is holding their breath about Suspense… so suspenseful.
- Blitz.js — “The Fullstack React Framework” — interesting to see a framework built on top of another framework (Next.js).
- Introducing Zero-Bundle-Size React Server Components — Feels like it will be a big deal, but will shine brightest when frameworks and hosts zero-in on offerings around it. I’m sure Vercel and Netlify are all 👀.
The post Some React Blog Posts I’ve Bookmarked and Read Lately appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
- Font-size: An Unexpectedly Complex CSS Property — From Manish Goregaokar in 2017. Of many oddities, I found the one where
font: medium monospacerenders at 13px where
font: medium sans-serifrenders at 16px particularly weird.
- The good line-height — Since CSS supports unitless
line-height, you probably shouldn’t be setting a hard number anyway.
- Time to Say Goodbye to Google Fonts — Simon Wicki doesn’t mean don’t use them, they mean self-host them. Browsers are starting to isolate cache on a per-domain basis so that old argument that you buy speed because “users probably already have it cached” doesn’t hold up. I expected to hear about stuff like having more control over font loading, but this is just about the cache.
- My Favorite Typefaces of 2020 — John Boardley’s picks for the past year. Have you seen these “color fonts”? They are so cool. Check out LiebeHeide, it looks like real pen-on-paper.
- How to avoid layout shifts caused by web fonts — We’ve got CLS (Cumulative Layout Shift) now and it’s such an important performance metric that will soon start affecting SEO. And because we have CSS control over font loading via
font-display, that means if we set things up such that font loading shifts the page, that’s bad. I like Simon Hearne’s suggestion that we tweak both our custom font and fallback font to match perfectly. I think perfect fallback fonts are one of the best CSS tricks.
- How to pick a Typeface for User Interface and App Design? — Oliver Schöndorfer makes the case for “functional text” which is everything that isn’t body text (e.g. paragraphs of text) or display text (e.g. headers). “Clarity is key.”
The post Some Typography Blog Posts I’ve Bookmarked and Read Lately appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
- Back/forward cache — I always assumed browsers just do fancy stuff with the back/forward buttons and us developers had very little control. Philip Walton tells us it’s critical that we understand “what makes pages eligible (and ineligible) for bfcache to maximize their cache-hit rates.” For example, if you use the
unloadevent, the page is instantly disqualified from the cache.
- Big picture performance analysis using Lighthouse Parade — Lighthouse only tests one page of your site. Lighthouse Parade tests all the URLs of a site, and aggregates the results.
- Beyond fast with new performance features — Jake Archibald gets into the CSS
content-visibilityproperty (and a few other things) and how it can lead to incredible performance boosts (you use it to tell the browser that it’s straight-up OK not to render things). Right this minute,
content-visiblitymakes me nervous as it has issues with scrollbar jankiness and accessiblity problems. I found it a smidge confusing at first glance, and Tim Kadlec has reservations.
- Image Decode & Visual Timings — Image performance isn’t only about the size of the image. Different formats take different amounts of time to decode and render. GIF never wins.
- How to increase CSS-in-JS performance by 175x — The trick, readers, is shipping CSS. You can still use CSS-in-JS as you author, and have the build process create the CSS. They call that “Zero-Runtime” like Linaria.
- Testing Performance — Kelly Sutton: “The best approach that I have found to preventing performance regressions is to employ qualitative assessments of the code.” Performance is such an unwieldy beast, that only in production will you truly know what happens.
- Front-End Performance Checklist 2021 — If you’re going to get serious about performance this year, you’d do well to dig into Vitaly’s guide.
- We rendered a million web pages to find out what makes the web slow — HTTP/2 is a huge indicator of good performance.
The post Some Performance Blog Posts I’ve Bookmarked and Read Lately appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
We’re sliding into the roaring twenties of the twenty-first century (cue Jazz music 🎷). It’s important that you and I, as responsible people, follow the tradition of looking back on the past year and reflect on the things that went right and wrong in the hopes of becoming the best version of ourselves in the year ahead.
I never do New Year’s resolutions, except for when I was ten years old and wanted to open a local self-run detective agency by the end of the following year (Scooby Doo was in vogue those days.) But I do reflect on the past this time of year, perhaps as an instinctive response.
Over the years, I’ve improved as a web developer, on my own terms and on my own pace, while learning, unlearning, interpreting and executing what the web technology offers. This post is a reflection of my personal experiences from 2019 and the years before that. I’ll share things I’ve learned that might make us all better web developers heading into 2020. Personal experiences aren’t universal, of course, but it’s sometimes neat to get a look into the things other people are processing and learn vicariously through them.
So here we go.
I spent a lot of time in other people’s code
It was unavoidable because my very first professional project involved updating and upgrading an old application. It was only after some time that I realized I gained wisdom from navigating through code written by others, and also, I developed the guts to voluntarily read others’ code and really pay attention to what it’s doing.
It’s not unlike practicing good listening skills. Reading and understanding code written by someone else requires active attention and fighting the temptation to either zone out or inject your own opinion.
What you can try: GitHub is a great place to see a lot of projects. There are so many open source projects out there and they’re all readily available to look at and digest. I think many of us have experienced times when we simply grab a project or a tool without really getting under the hood and understanding what it’s actually doing or how it fits into our own work. Taking the time up front is an excellent way to not only learn new things, but to make better decisions in our day-to-day work as well. Don’t understand something? Open an issue in the repo and ask away!
I’d be remiss not to mention CodePen here. Not only can you search for just about any pattern, feature, or function, but it also offers collections of Pens and even topics, both of which are excellent for seeing how different people tackle similar ideas.
I tried new web standards even if I thought I’d never use them
It’s just my curiosity, but I think it has made me feel more comfortable in learning something new. That might be variable fonts, serverless, JAMstack,
prefers-reduced-motion , and subgrid, among many others. Geez, we’ve seen a lot of new things in the last year or two, haven’t we?
What you can try: I think you’re already ahead of this by following sites like CSS-Tricks. There are many technical blogs and writers out there who share with their readers what’s new. Check out the list of people who have contributed to this blog — many of them have personal sites where they’re frequently sharing new things. A Book Apart is also a great resource for standards, especially for those of you who might enjoy a break from the screen. You can find so many gems there, from Expressive Web Design to The New CSS Layout.
I created an archive of my favorite code snippets
There were times when I’d think that I’d remember the oh-so-simple syntax of new code I tried… but it turns out simple things are easier to forget. So I decided to keep them neatly in a digital folder, like in the good ol’ times. This has allowed me to go back and reference code when questions or ideas pop up. Otherwise, I’d have to go back and research all over again.
What you can try: I personally don’t use tools, just save them in a file. That said, Gist is always a nice place to keep snippets. And, hey, CodePen lets you create your own collections as well!
Another idea is to leverage your browser’s bookmarks. Save links liberally. Organize them into logical groupings so they’re easy to find later.
I created an archive of my notes, flow diagrams, and other stuff I scribble on paper
I have a standard paper notepad at my office that I use to jot down everything from ideas for a project I’m working on, layout sketches and notes from things I read. It’s also the place where I often start work, much like the way Chris writes “pseudo code” heading into a code editor.
I have a habit of working out the visual aspects of a web application, and often, even the source code on paper. So, I keep those papers safe for when I might have to refer back. It has helped me out in a pinch.
What you can try: I would be a hypocrite if I recommend any of the online note taking tools, because I’ve never found them convenient, ironically. There are lots of physical notebook options out there. Moleskine is a popular one. Sarah Drasner recommended one when she wrote her own post on learning how to learn.
I recognized when someone’s teaching and I need to be a student
I used to have a bad habit: if someone’s explaining something about code that I might already be familiar with, I would process and interpret what they were saying based on my own personal experiences, way before I learned what they had to say first.
It could be a millennial thing or it could be an industry thing, but I’ve always found that people package everything as something that’s being shared, that somehow I’m sitting in a round table with them and we are dissecting things over a box of pizza. 🍕
I appreciate that people make their content inclusive because we’re all adults here. But it also has stopped me from genuinely learning what they were trying to teach. I skimmed through useful information, but never really cared about the context. On my worst days, I missed the point completely, all because my brain’s resources were divided trying to learn and analyze at the same time.
Active listening and learning has provided a bunch of benefits for me this past year. For example:
- I hear what people are saying more clearly.
- I retain what people share with me more easily.
- It makes the people I’m interacting with feel at ease with me.
- It opens my mind to new ideas and possibilities I may not have considered.
What you can try: When you want to learn from something, whether it’s an article, a tweet, a podcast episode, a documentation or something else, save it and use it. I learned to grow out of my bad habit this year and have found this to be my flow for learning and retaining from others:
- I learn something.
- I save it for later (in my archive!).
- I try it out when I have the time.
- I play around with it more and try improving on it, if needed.
- I eat my pizza.
I trusted my own judgement more
This might sound like the exact opposite of what I just said about active listening, but it’s more of a counter-balance to being overly reliant on others. Active listening doesn’t mean we can’t have our own opinions or even continue holding onto them. It simply means we hear and retain information that can inform our own opinions.
A good professional opinion could be such a blessing, but good or bad, the moment I found myself giving too much weight to other people’s opinions, like I’d read a blog post on someone’s development environment and think I have to do the same thing, or worse, that the way I do things is wrong, that’s a terrible feeling (hello Imposter Syndrome) and who needs more stress?
What you can try: Instead of automatically believing that anything you read is the golden standard, try putting up a little guard. In other words, instead of thinking, “This is how I should be doing it,” perhaps say, “Oh, so this is how this person does that.”
I started seeking others’ experiences that validates my own
I feel happy when I read or hear fellow web developers share their work experiences and find something that resonates with me on a personal level:
- “I know! I couldn’t set it up the first time, too!”
- “Yes, that framework made things slower for me, too!”
- “No way! I tried to center a floating element, too!”
Seeing that I’m not the only one who makes mistakes or struggles in certain areas makes me feel okay for where my skills are at instead of seeing myself as an unskilled developer who’s prone to mistakes. Chris recently shared his thought process working with flexbox elements — that’s exactly the sort of thing I think we can all relate to.
What you can try: We all bear some responsibility here. Let’s make people feel good when asking questions, even if they seem obvious to us. Share your own mistakes and struggles. The web is a vast and constantly evolving space and we’re all starting from different places.
I made myself the only one who decides what to make on my off-work coding marathons
Like all of you, my learning curve involves coding during my non-working hours. It could be just a new code I’m trying out or a full on side-project.
Seeing others share their side projects inspires me… at least that’s what I want them to do. That hasn’t always been the case. They used to make me think I wasn’t doing enough. Not enough GitHub repos. Not enough open source contributions. Not enough self-imposed challenges. Not enough WordPress plugins. And, sorry Chris, not enough CodePen demos.
With experience, however, I’ve realized there’s only one human soul that can optimally select what I should be working on, based on my skills, my preferences, my necessities and my circadian rhythm – the ghost under my bed.
Once I understood that, every single awesome and crazy side project people share online truly inspires me — or at least makes me smile, which is even better.
I stopped drinking coffee
This is not up for discussion, my dear reader. 😀
What you can try: Masala Chai.
I started prioritizing my health
Here’s a very silly story. I sprained my wrists thrice in a month. I think it was a voodoo spell. The point is: it was getting harder for me to work.
I was a bit embarrassed to tell people I couldn’t work because I was injured, so I continued like nothing happened. Each time, the sprain would eventually go away because of the ointment I applied at home, but would return soon enough because I wasn’t properly resting it. At one point, the pain spread to my arms and I’d to immediately take my hands away from the keyboard and rest them on my lap. It scared me.
The next day, I started wearing a wrist cast (well, two) and informed my colleagues and technical director that I needed to take it slow.
I know this story sounds like a very simple and obvious thing — and it was a very simple thing indeed. But I learned an important lesson: Health comes first.
Our job description doesn’t come with health warning stickers, but there are consequences in reality.
What you can try: Take care of your health first. Physical or mental, chronic or acute, mild or severe, internal or external, when your health problems go away, it improves the quality of your life, personally and professionally. If you’re lucky enough to have good health insurance, use it. Schedule an annual physical exam. Listen to your body when it says it’s hungry, thirsty, or simply needs a rest.
I know, easier said than done. But it’s important nonetheless and something worth striving for.
I’ve started sharing my knowledge with others
Not in a way you might assume. I know the consensus is that we learn when we teach but I haven’t personally experienced that. I don’t learn while I teach. Instead, what I’ve done is focus on how someone I’m teaching could or should learn a particular thing.
- “Start with the basics.”
- “Read the documentation.”
- “Try the demo then proceed to so and so.”
These are some of the statements I found myself repeating to those I’ve mentored.
Those same sentences echo back to me when I’ve to learn something new. When I teach, I pay attention to how it’s learned. And learning is the one skill that never goes out of date, especially in our line of work.
What you can try: I think you’ll probably have to wait a while before you could do this if you’re just starting out as a web developer, but if you’re even somewhat experienced and meet a wide-eyed newbie, don’t miss your chance to teach. Don’t be part of the dark matter. You can teach in a variety of ways, from blogging to making demos. That said, I’ve found real life person-to-person teachable moments to be the most effective.
I realized I can’t read a code once and understand it all. So I use comments.
Here’s my comment about comments: Take them seriously.
Sometimes I can’t even decipher the code that I’ve typed with my two bare hands.
Condensation is a key element of programming languages in addition to something that causes rain. We don’t write, “add one more sheep to the herd.” Instead, we write,
i++. Expecting myself to remember and understand everything in one glance simply isn’t practical.
Using well-thought comments cuts back the time it takes me to know what’s happening in the code. This is why I’ve consciously paid attention to using comments this past year. There’s no cost to using them, so go nuts!
What you can try: Take time to go through your code and leave some useful comments each time you’ve coded a module or a feature that works, especially before moving onto what’s next.
I’m not taking working code for granted
I was told
margin:auto would center an element. I was told to add
return(0) to an
onclick event handler. I was also told to use GUID for foreign keys.
I didn’t ask why or how those things worked at the time. I simply did as they said.
I, now, however, know how they work and why I had to use those code.
When I know the basics of a piece of code, it helps me to use the same code or the same logic in scenarios other than the one I learned about it in.
What you can try: Make a quick mental, physical, or digital reminder when you come across a code that you want to know more about. Then remember to go through that list first in your free time. Don’t be afraid to ask someone why code is used a certain way.
I try to mimic extroverted web developers
* takes a deep breath *
I’m an introvert.
My introversion is not so bad that people feel uncomfortable around me. I mean, everybody likes talking to introverts because they mostly listen, right?
Although most of my work is typing in front of a computer I inevitably have to meet people, like clients, users and team members.
Communication is important. And not just the bare minimum.
When you develop a really good relationship with who you work with, your workplace becomes fun. When you develop a good relationship with your users, your work becomes successful; and when you develop a good relationship with your clients, you get more work.
I found there’s no way around it: I had to talk from time to time. I had to put myself out there.
I look at my fellow web developers who are more extroverted for communication pointers. They talk beyond about work. They give their suggestions. They encourage feedback.
They drink coffee. And I try to practice that.
What you can try: If you’re an extrovert, I’ve got nothing for you. If you’re an introvert, all I can say is try. And keep trying. And that’s all you ever need to do. We can’t change our personalities, but with some practice and time we’ll learn to manage them better. In fact, it might be worth getting a better understanding of your personality type. Susan Cain’s book Quiet is an interesting (and dense) take on introversion.
I take breaks
I hate this to be true, but I turn into a Shaman soon after I start coding. An unwilling Shaman who gets possessed. The spirit that takes over me likes to only code. It doesn’t like to eat, sleep, talk to people or check Instagram. It’s a very mean spirit.
That’s why I exorcise it regularly to not cloister myself from the world. I pay attention to someone calling me. I leave the desk for tea breaks. I let my laptop’s battery die so I won’t go near it during vacation. I even have a hobby.
I don’t know if taking breaks has improved my performance or not, because I don’t think the mean spirit lacks in performance. I just think it’s good for me to not be always possessed.
What you can try: For those of you with 9-5 job, I would recommend tea breaks at 11AM and 4PM (wow, that came out very specific) And for when you work at home, I suppose you’ll have more things to do, so choose for yourself when you want the break. I like to watch TV, that would be like my ideal break time.
And… that’s it. That’s all the spookiness I could fit into this post. I shared as much of my experience as I could, as well as suggestions you might find helpful. Hope you take something good from it. This might be my final post of the year, so I don’t want to miss this chance to wish you LOTS of good luck as you go into 2020. 🍀
The post How I’ve Improved as a Web Developer (and a Person) in 2019 appeared first on CSS-Tricks.
In a sense, it’s just an app for keeping documents in one place: little notes, to-do lists, basic spreadsheets, etc. I like the native macOS Notes app just fine. It’s quick and easy, it’s desktop and mobile, it syncs… but there are enough limitations that I wanted something better. Plus, I wanted something team-based and web-friendly (shared URLs!) and Notion hits those nails on the head.
Here’s a bunch of ways to use Notion as well as some scattered random notes and ideas about it.
Workspaces are your teams
The word “workspace” almost makes it seem like you could or should use them as your top-level organization structure within a team. Like different projects would use different workspaces. But I’d say: don’t do that. Workspaces are teams, even if it’s a party of you and only you.
Pricing is billed by workspace. Team members are organized by workspace. Search is scoped by workspace. Switching workspaces isn’t too difficult, but it’s not lightning fast, either. I’d say it’s worth honoring those walls and keeping workspaces to a minimum. It’s almost like Slack. It’s easy to get Too-Many-Slack’d, so best to avoid getting Too-Many-Notion’d.
We have a weekly all-hands meeting at CodePen where we lay out what we’ve done and what we’re going to do. It’s nice to have that as a document so it can include links, notes, comments, embeds, etc.
Those notes don’t disappear next week — we archive them as a historical record of everything we do.
Publishing and advertising schedules
I like looking at a spreadsheet-like document to see upcoming CSS-
Tricks articles with their statuses:
But that same exact document can be viewed as a calendar as well, if that’s easier to look at:
There can be all sorts of views for the same table of content, which is a terrific feature:
This might be the easiest selling point for Notion. I’m sure a lot of companies have a whole bunch of documents that get into how the company works, including employee databases, coding guidelines, deployment procedures, dashboards to other software, etc. Sometimes that works as a wiki, but I’ve never seen a lovely setup for this kind of thing. Notion works fantastically as a collaborative knowledge base.
I can make a document public, and even open it to public comments with the flip of a switch.
Another super fun thing in Notion is applying a header image and emoji, which gives each document a lot of personality. It’s done in a way that can’t really be screwed up and made into a gross-looking document. Here’s an example where I’ve customized the page header — and look at the public URL!
I’ve also used that for job postings:
It’s also great for things like public accessibility audits where people can be sent to a public page to see what kinds of things are being worked on with the ability to comment on items.
Quick, collaborative documents
Any document can be shared. I can create a quick document and share it with a particular person easily. That could be a private document shared only with team members, or with someone totally outside the team. Or I can make the document publicly visible to all.
I use Notion to create pages to present possibilities with potential sponsorship partners, then morph that into a document to keep track of everything we’re doing together.
We use a show calendar for ShopTalk episodes. Each show added to the calendar automatically creates a page that we use as collaborative show notes with our guests.
It’s worth noting that a Notion account is required to edit a document. So anyone that’s invited will have to register and be logged in. Plus, you’ll need to share it with the correct email address so that person can associate their account with that address.
Blog post drafts
I’ve been trying to keep all my blog post drafts in Notion. That way, they can easily be shared individually and I can browse all the collected ideas at once.
Exporting posts come out as Markdown too, and that’s great for blog post drafts because it translates nicely:
Private sub-team documents
Being able to share documents with specific people is great. For example, we have a Founder’s Meetings section on CodePen:
There are probably a million more things
Notion is simply documents with interesting blocks. Simple, but brilliant. For me, it can replace and consolidate things like Trello and other kanban tools, lightweight project management platforms, GitHub issues (if you don’t need the public-ness), wikis, Google Docs and Spreadsheets, and even simple one-off public websites.
Here’s a website dedicated to other people’s interesting Notion pages.
What I want from Notion
I’d love to see Notion’s web app links open in their desktop app instead of the web. I prefer the app because I have plenty of browser tabs open as it is. It’s gotta be possible to do this with a browser extension. There used to be “Paws” for Trello and there was a browser extension that would open Trello links in that app, so there is prior precedent out there.
I’d also like Notion to explore a tabs feature. I constantly need more than one document open at a time and right now the only way to do that is with multiple windows. There is some back-and-forth arrow action that’s possible, but it would be interesting to see native tabs or native window splitting somehow.
I’d love to see some performance upgrades too. It’s not terribly bad, but working in Notion is so ubiquitous and important in my day-to-day that I’d love for it to feel more instantaneous than it currently does.
The post How I’ve Been Using Notion Personally and Professionally appeared first on CSS-Tricks.