A few days ago, I linked to an excellent post from Jeremy Keith where he talked about what attracted him to the Web. Chris Wilson touches on similar subjects in The Web is not Poor Man’s Native, diving into some of the Web’s advantages and disadvantages in its current state.
Too often we hear the phrase, “Designers should write code.” True, even if it’s just basic HTML and/or CSS. But what about the flipped version of that argument? Developers should design.
True as well. Even if that means a few ugly websites, web applications or projects. Here’s why.
It pushes you outside your comfort zone. That’s obvious. Stretching your design skills when you’re use to living in a text editor also puts you on the opposite side of the equation you’re part of each day. Even if what you create isn’t pretty, you’ll develop better empathy and understanding for the designers you work with daily.
Great projects – the ones filled with lovely design, delightful user experiences and clean code – spring to life from collaboration. That doesn’t happen without knowing both sides of the equation – design and development.
I’ve recently challenged myself to design more, even though I don’t consider myself a designer. It’s frustrating sometimes. When I wrote for a living, I could feel my way through a very creative activity. Even if I didn’t know why a sentence or paragraph wasn’t right, I still knew it wasn’t right. With my own designs, I don’t always have that clarity. At times, what I want to create mocks me because it’s just out of reach. That’s where I see that collaboration coming into play. Asking a more skilled designer for feedback, no matter how scary, sets me on a more productive path faster.
I may not be a designer, but I can be one for a few days here and there, and work with my colleagues to create something amazing. After all, a lot about “being” a designer means taking feedback and iterating. Developers do that with code too.
So maybe you’re not a designer, but just iterating and becoming a better developer.
Inspired by a post from Mel Choyce.
Image courtesy of Pexels.com.
Karl Groves on how you don’t have accessibility problems, you have quality problems.
A few weeks ago, a talented designer/developer colleague of mine at Automattic asked me about starting to use a screen reader to test for accessibility. I cringed a little.
Why? Because I remembered how daunting it was to learn how to use a screen reader. You turn it on, and you’re thrust into a new world. One that says things to you non-stop. 🙂 But in all seriousness, anyone can learn to use a screen reader for basic accessibility testing. You just need to recognize it has a learning curve, like anything else. Below, I share some tips I wish I knew when I started to integrate screen readers into my every day workflow.
Grab Your Flavor
WebAim has some fantastic information on screen readers and tutorials to help get you started.
- Using JAWS to Evaluate Web Accessibility
- Using NVDA to Evaluate Web Accessibility
- Using VoiceOver to Evaluate Web Accessibility
- Testing with Screen Readers: Questions and Answers
This isn’t an exhaustive list if screen readers, just the ones WebAIM has tutorials on. I use VoiceOver because I do all my development on a Mac. But I occasionally hop over to a Widows machine with NVDA.
You won’t learn how to test effectively with a screen reader the first day. Or the first week. Or the first month. Be patient. Practice. I like to think of it like distance running – you have to build up your distance base first. Once you have the base you can start to go places, and faster.
One mistake I made in the beginning was jumping into complicated web pages. If you have sophisticated interactions happening on the page, it’s hard to keep track of what’s happening there and what’s happening in the screen reader. So start with a sample page you’ve created with basic HTML and various elements. Put the standbys in place like links, buttons, form fields and such. Now, you can get an idea of what a screen reader does with standard elements.
You might be tempted to turn off your monitor, and you should do that at some point to try it. However, wait for awhile until you can handle the keyboard commands first. Then give it a shot.
Pick a Team
Like I mentioned, I use VoiceOver as my primary screen reader. You can use more than one, but if you’re new to screen readers, try to stick with one for awhile until you get comfortable. Screen readers are like programming languages: once you learn one, the rest come easier because the principles are the same.
Even though you might become proficient in screen reader use, it’s not the same as using one every day. I’m no expert, just someone who knows how to use one to evaluate a web page from a technical perspective. When I work with more seasoned screen reader users, like on the WordPress Accessibility Team, I give actual users’ opinions more weight than mine. 🙂
Good luck in your screen reading adventures!
When you take on a physical challenge, like a marathon, you have to train. You prepare your legs and mind to accomplish what you set out to do. You can’t just jump in cold and expect to do well.
Yet, as web workers, we go to work each day and dive into many new challenges without much preparation. Yes, we’ve built this type of interface or hooked up to that kind of API, but on the web, while the principles stay the same the methods change. How do we keep up and make sure we’re ready to run the race?
We have to keep our developer fitness level as high as we can. How? Well, I’ll list a handful of things that have worked for me and a few others I’d like to try soon.
Contribute to an Open Source Project
I help out the WordPress project in a few ways and love it. I’ve meet new friends and learned new things. Plus, I’ve had more practice in finding reasonable compromises to tough problems. Find a project that inspires you and get going.
Create Something Simple
I gave a talk about a workflow for testing for web accessibility with free tools at a conference recently. I wanted attendees to have access to the links and information I spoke about, so I created a simple website to house all the resources. It marked the first project I used Grunt, Sass and a few other newish front end development tools. The simplicity kept me focused on learning, not perfecting the project.
Build a Wall
When I landed a new job at Automattic recently, the company bought me a new work computer. I also needed a new personal machine since the one I had was more than six-years-old. So I bought a stock Apple 11-inch Macbook Air and refused to install any web development software on it. Except for ImageOptim, which I use to compress images before uploading them to my blog, you won’t find any dev tools. This has forced me to do more than just write code in my free time. I’m writing more here and reading more, things I wasn’t doing much of before the wall.
At a recent company meetup with Automattic, I watched many of my colleagues give flash talks. These four-minute presentations ranged from technical to silly to personal. Many of them gave me a glimpse of the hobbies my co-workers find interesting, many of which have nothing to do with technology. It made me realize that the main hobbies I have: open source projects and video games are a bit boring. So I want to try a new creative hobby to help stretch my developer fitness in new ways. Maybe the guitar – I once tried to learn to play.
How do you keep your developer fitness up?
Image courtesy of Pexels.com.
You want to make your website more accessible, but you don’t know where to start. If you have 60 seconds, I can help.
Recently, I gave a presentation on how to test for web accessibility with free tools. That was the 30 minute version, but you can also get a broad overview of a site’s accessibility quickly. It won’t tell you everything you want to know, but it will give you a baseline. Use it as you develop your site or application.
Focus on the Basics
- Install the Wave Toolbar or Chrome Extension.
- Use Wave to check your page structure using its “Outline” feature. Do you have a reasonable heading structure?
- Next, also using Wave, turn off CSS. Does your linear source order make sense?
- Again, with Wave, test for any errors. Your images should have alt attributes (icon fonts too). Your clickable elements should be links or buttons and your form elements should have labels.
- Next, test for keyboard accessibility by tabbing through your page or application. Can you get to everything with just a keyboard. Visually, can you see where you are on the page?
If you have any time left, start fixing bugs. 🙂 You’ll probably find some, and that’s okay. What you did doesn’t matter as much as what you do next.
Image courtesy of Pexels.com.
WordPress Accessibility team member Joe Dolson wrote a post on Good Coding Habits for Accessibility, based on a presentation he gave for WordCamp San Fransisco 2014.
Spam comments got you down?
Hey, don’t worry – it happens to every blogger. The Akismet service does wonders, helping combat comment spam in a big way, but there’s one specific use case where I’ve noticed it’s struggled lately: spam on WordPress image attachments.
By that, I mean the comments specifically on image posts in WordPress.
WordPress gives you the option to set comments open or closed on image attachments, and it doesn’t look like that will change. That’s awesome, especially if you have a gallery and want to have users be able to comment on individual images. But you may not care about that, and rather have users comment on the post itself. I wanted to just have all comments and pings closed on all image attachments.
John P. Bloch posted an excellent solution over on WordPress Answers. That worked great for me. I dropped the code into my site’s functionality plugin, (it will also work in your
functions.php file) and bam – comment spam reduced.
But the last part of the code wasn’t updating the database values. See it here:
global $wpdb; $wpdb->update( $wpdb->posts, array( 'comment_status' => 'closed' ), array( 'post_type' =>; 'attachments', 'comment_status' => 'open' ) );
So instead, I ran two simple SQL queries to close comments and pings on image attachments.
UPDATE wp_posts SET ping_status = replace(ping_status, 'open', 'closed') WHERE post_type = 'attachment'; UPDATE wp_posts SET comment_status = replace(comment_status, 'open', 'closed') WHERE post_type = 'attachment';
That’s worked for me so far. I wanted to share just in case it helps you solve a similar problem, and reduce your comment spam!
When I first started writing, I wrote stories for my middle-school journalism class longhand at my desk and then typed them onto a computer, editing as I went. I loved the physical act of writing that much – feeling the ink and paper blend. Beside wanting to fly jets in the Air Force when I was about six, all I ever wanted to do was to write.
So I wrote, working as a journalist, then copywriter. I loved bringing things to life with words, putting the pieces of stories together. When the journalism world evolved into something different with the rise of the web, I looked toward changing paths. I loved blogging, creating sites and building things… That’s where the coding comes in.
Writing is art. And I’m learning that coding can be art too.
Note: This post first appeared on one of my discontinued blogs – WRPG. I salvaged this good post, and shared it here.
I really need to write my first WordPress plugin. Jesse Friedman, a 10-year-old who recently attended a WordCamp, took away what he learned there and created one. Great inspiration, and good to see a young one getting involved in coding early.