Things That Don’t Go Together Except in This Coding Blog: Animals, Bridesmaid Dresses, and A Trip to the Grocery Store
Let’s play ball!
One thing I learned in class today was an analogy about functions. When you run a function, the function does something. If the function is my partner in a game of catch, the function throws a ball. The function always does something. If I don’t do anything with the ball, it’s going to be a rather useless and boring game of catch. If I use a return statement, that’s like me catching the ball. Now that I’ve caught it, I can do something else with it; we can continue our game (program).
Should all your dresses be celadon?
If you’ve ever been in a wedding, you may know that some brides are understanding and flexible, and request that their bridesmaids simply get dresses in the same color. For my sister, she considered celadon, which was a pretty jade-ish color that some bridal boutique used for their bridesmaid dresses. Having all the dresses the same color is like using the double equals sign (==). The double equals sign compares to see if two values are the same.
The triple equals sign (===), however, is like requiring all your bridesmaids to wear the same dress in the same color. The triple equals sign compares two values to see if they are first the same type (e.g., boolean, string, number), and then compares their values. And, like bridesmaids dresses, I suggest using the former as a default. There may be a bride with 3+ girlfriends who happen to all look good in the same dress style, but it’s not likely. There are reasons to use === instead of ==, but unless you need them to be exactly the same, you might save yourself some hassle by using ==.
How do you determine the value of a cat?
If var foo = 10 + “20”, foo is 1020. Var foo = 10 + “20” takes 10 as a number and 20 as a string. Strings cannot be added numerically, so it’s just going to return 1020 as a string. Also, Foo is my cat. And I’m not sure how to determine the value of him, but he’s awesome.
There’s gotta be a bird joke in here somewhere
In 5th grade, we would team up to try to guess the meanings of vocabulary words. My friend and I decided that “propaganda” meant “a very proper goose”. With “ternary operator”, I was really hoping to come up with some tern reference. But alas, I’m not that creative today.
A ternary operator is a not-so-easily-readable way to write a conditional statement with only one “if” and an “else”. It’s shorter than writing out if statements or using switch statements. However, it does not read easily:
number % 2 === 0 ? `even: ${number}` : `odd: ${number}`
It’s not very intuitive. I found if helpful to read (or say out loud) what the code is trying to say. The question mark is key. It’s asking, “Does the number [a variable], when divided by two, have a remainder of zero?” Then the section in the inside the first set of backticks, before the colon, is saying “If so, do me!” and the section in the second set of backticks, after to colon is say, “If not, do me!” I am sure that using language like this to consistently describe what the code “says” will help me learn to code more efficiently.
Why I avoid H-E-B gas pumps
Living in Austin for more than a dozen years, H-E-B has grown on me (but Wegmans will always be my one true grocery store love). However, I avoid their gas pumps. Why? Because they ask me a gazillion questions that are entirely unnecessary for me to perform my intended task at the gas pump — getting gas. My goodness, I never want an additive, a car wash, and very rarely a receipt (which honestly, they could just ask at the end, because if I need it, that’s when I need it, and if I don’t, I’ll leave without being bothered by another stupid question).
Gas pumps and websites have a lot in common.
Like the gas pump, one thing that makes websites user-friendly is doing what you need to do with the least number of clicks possible. I realize this is contrary to the goal of advertisers, and companies want you to spend time on their site. However, “time” should not be measured in useless clicks. If I need to go 10 clicks to sign in, it’s likely I’ll avoid your website like I avoid H-E-B gas stations.
More generally, a user-friendly website is simple. Fewer clicks is one way to make it simple. Another is to design it so that the website tells you what to do without you having to think about it. My dad complains about gas pumps (and websites) for not doing this. He knows what a gas pump does. He’s been using them for longer than personal computers have existed. When he needs to read the instructions on how to use the pump, that’s not user friendly. One way to do this- design a website (or pump) to tell you what to do without you having to think about it — is location. We expect log-in links to be in the upper right, like we expect the cheapest gas button to be on the left.
The location issue also follows another rule of user-friendly websites (and gas pumps!): consistency. Consistency applies not only across types of websites (like the login button in the upper right), but also (and maybe even more importantly) across the pages of the website or within a page. Consistency across stores is the reason my mother didn’t shop at Wegmans (and why I regret all the lost opportunities of my youth — oh, how I miss Wegmans). She complained that each store was set up differently. I’ll admit, though, that I feel the same way — the recent re-arrangement of my local Walgreens (it was unlike any Walgreens I’ve ever been in) was so disorienting that it literally made me a bit dizzy. If the design of the website is inconsistent, across pages or from what the user has experienced with other websites, it becomes frustrating pretty quickly (and I’d bet the correlation is proportional to age).
These things — consistency and simplicity — go beyond just being “user friendly”. Or, maybe being user-friendly is one way to make your website more accessible. Either way you frame it, by being consistent and simply, many people can interact with your website: those with learning (esp reading) disabilities, cognitive impairments, language impairments, etc. may benefit from consistency and simplicity. One doesn’t need to know how to read to use YouTube, for example (or to make a purchase on Amazon, for that matter).
Accessibility for the visually impaired can be enhanced by a few simple strategies. Using semantic HTML tags (e.g., “nav”, “form”, and “article” vs “div” or “span”) help people with visual impairments, because a screen reader will read the tag, guiding the individual through the website. Similarly, using alt to provide a description of images helps those with screen readers know what is on your website. I imagine there are others who also benefit from these, but I’m not sure who those groups are, yet.
So, y’all like tables?
At the end of one of my first master’s classes, our professor (both a bit long in the tooth and an odd duck), sat on the table and asks us all, “So, y’all like tables?” Given this was completely out of context (we were packing our bags) and he was sitting on a table, most of us took him to mean the four-legged things with smooth surfaces for writing and eating. What he really meant was the tables in the research articles you read will be really helpful for understanding the article. My work has frequently required me to read and create tables. I am a fan. However, I have only practiced using HTML tables, and not used them for a project. I believe if I had taken up coding back in HS, I would’ve been the table master.
Oddly, I feel really strongly about a lot of things, but not HTML-5 elements… yet. I’m sure I will. It’s a bit gauche, but I’m a fan of a div. Obviously, I don’t want divs to be my standard. I understand that more specific elements are helpful to others — I just made a case for their use in enhancing accessibility, and I also know other developers can more easily read my code. But for now, they’re just so flexible. Also, maybe I do love forms.
Back to the grocery store
Some of the same things I mentioned earlier about making a website user-friendly apply to my CSS and JS files, too. The biggest factor that I think makes my CSS and JS easy for others to read is consistency. Here are some ways I’m consistent in writing CSS and JS:
Top-to-bottom. Yes, the order may make a difference in the function of CSS and JS (they are, after all “cascading” style sheets), but I’m talking about ordering the contents from top to bottom and big to small. For example, in my CSS, the very first thing is the body (or the element that encompases everything else; big). Following that, the elements are listed from top to bottom of the page — with the top nav rules first and the bottom nav listed last. I also work from large to small. If there is a div with three buttons, each button with a link, I’ll style them in that order on my CSS page: div, button, a.
Indentation. Perhaps this comes from writing research articles and other APA style papers, but I take indentation pretty seriously. Anything I create has consistent indentation (I love bullet points almost as much as I love tables, and those only work if they’re used consistently). My CSS and JS both use consistent indentation. Come to think of it, after reading a Reddit post about the use of tabs vs spaces, I meant to go into VS Code and see if I could set my own tabs. Ahhh… something to do in my free time this evening.
Spacing. With CSS it has been easy, and with JS it has been a little more difficult, but I’m trying to be consistent with the amount of spaces between lines, across sections of my file. For example, as I’m creating practice files, I’m using one space between a set of variables and the subsequent function they’re related to, then another space after the function to before I call that function. Then, I’m using two spaces before the next problem. It’s the little things that keep me sane.