At AnnieCannons, we teach Grid as the first tool to use in layouts. It’s designed for laying out web pages. Flexbox is useful when the space between elements is the most important thing to maintain (as in a navbar). Grid is used for everything else.

Periodically, we get a student questioning our approach. I’ve also had other developers question what I teach.

The longer and bigger question is why is everyone pushing back on Grid as the appropriate method for web page layout? Flexbox must be right because that’s what I learned in bootcamp, and that’s also what every influencer is saying, so it must be right.

The answer is complex:

• Flexbox is what was taught in bootcamp 10 years ago (because Grid was not well supported).
• Those bootcamp grads have gone on to teach bootcamps now.
• Those instructors have never upgraded their CSS skills because they are too busy chasing the latest in JavaScript.
• Those instructors figure that Flexbox is fine, because they know and understand it, and it’s a supported spec, so why bother with something that may not give an obvious and immediate benefit?
• Because they haven’t learned what Flexbox or Grid are good for, they can’t articulate the difference to their students.
• Another generation of students learn nothing but Flexbox, and so we go forward.

Unfortunately, around the cycle goes again, with developers never moving on from Flexbox because their influencers haven’t told them to do so.

In order to get Flexbox to work for a grid-like layout, one must apply either a width (wrong) or flex-basis (better!) to each cell, thus killing the “flex” in Flexbox. If you have to do this, why would you use anything but Grid?

I am the first to line up behind “keeping things simple” when teaching beginners a development world which is nothing but nuance and complexity. One of the best things we can do as educators is draw a bright line between use cases. Why do Flexbox layouts persist? Beca**use our current bootcamp instructors can’t articulate why Grid is best for grid-based layouts. ** Are you kidding me?

Hopefully I’ve outlined some easy bright lines you could share with your students. Please stop telling students that “Grid is really optional, and we don’t know the difference between the two, so just learn whatever.”

I agree with this, most of the time.

But we are driving a standards-first and trauma-informed curriculum.

AnnieCannons trains, prepares, and connects individuals who have experienced human trafficking to sustainable careers in tech.

We rebuild our students' confidence in themselves, reignite their joy of learning, and provide an environment where they may trust their community to teach them the economic skills to obtain and keep a career in a field with reasonable pay.

For those reasons, we can’t teach to the latest hottest technology. It has no track record and may not be there tomorrow. Therefore, we teach the basics: semantic HTML, foundational CSS, and vanilla JavaScript. After they learn vanilla JavaScript, we introduce them to a bit of React, plus connecting to databases and APIs (making them “full stack” for the employers who value such things).

Our students are all races, genders, and ages. We accept them as they are. As such, it is part of our values to teach accessibility from the start, integrated into their code, starting with semantic HTML.

Our students learn to start with HTML, then apply CSS, then apply JavaScript sparingly over top to provide the levels of interactivity required and no more.

We are writing this curriculum now. Our students are learning this curriculum now, and they are thriving because of it.

I arrived at AnnieCannons with the goal of creating the best bootcamp curriculum on the planet. With our small and mightly team of amazing instructors, student success managers, and career development managers, we are succeeding and growing our standards-first, trauma-informed curriculum.

Whether you’re learning how to code at a bootcamp or through academia, there are only two things you ultimately get from the experience.

First, you get an amazing network of friends who are committed to helping you early in your career.

Your institution’s alumni program offers assistance with resumes, job searching, online webinars, and an institutional name that gives you something in common with other graduates. Some programs partner with specific employers, waiting to hire graduates.

Sometimes the alumni program has a time limit on it, particularly with bootcamps. Take advantage of this. You’ll never have anyone else who can be this helpful in finding you a job.

Second, you learn how to learn technology.

Your tech education starts expiring while you’re in school! Techniques you learned early in the program may be out of date by the end. (They may also teach you dated techniques, but that’s a rant for another time.)

If you don’t keep learning and practicing your tech skills, you’ll be out of the field. Within 6 months, your education is dated enough that it will be hard to jump into the workplace. In a year, you’re completely out of date and will have a significant learning curve to jump back in.

But I’m watching video education from X provider in class – I could do this on my own without school!

True. But you don’t get the two items above, which are extremely valuable to getting into the field quickly.

Furthermore, someone curated those resources. They told you what resources had the most value. They are teaching you where to look when it’s time to learn a new skill. They are choosing resources that are (hopefully) factually based, up-to-date, and reflect current thinking in the field. Anyone can post videos on YouTube and post courses to Udemy… and they frequently do. Boasting 75 hours of learning time does not make those materials good. It just makes them long.

When people say you could learn X on your own and you don’t need school, they are correct. School offers you the structure and accountability to get it done, though. And you’ll never get the resource curation, alumni network, or practice in learning that you get at school. Consider this as you’re trying to decide how to get into the field.

The scammers are getting really good. I’ve been looking for a job for quite a while. And this shows up in my inbox today!

Dear Jen,

I'm Ashley Brian, Human resources manager at Love Classic Fashion.
We are currently seeking an innovative and dedicated graphic designer to work via a remote base that can work either part-time or full-time.

I saw your profile on Indeed.com and I was impressed by your experience.
Here at Love Classic, we are always looking to grow our teams with talented people and achieve great things together.

I think that your expertise in graphic design would help us in the project we’re working on. I’d love to tell you more about the opening position and learn a few things about you as well.

I am available anytime between 9:00am
5:00pm (EST), Monday through Friday.

Work hours or Shift: Monday to Friday, 8:30 am - 5: 30 pm.
Position Pay Range : $25 - $50/ hr
I hope you have a great day.

Looking forward to hearing from you.

Sincerely,
Ashley Brian, SHRM-SCP | Love Classic
Human Resources Manager
3760 Arlington, VA 22203

This email came from info@loveclassicjobs.store

Sounds legit, other than that graphic design thing, doesn’t it? Let’s go through how you can check on this.

a. info@loveclassicjobs.store – take the end of that email address and put it in a web browser. What do you get?

OK, well… maybe they use a different URL for job hunting?… because they get so many applications a regular email doesn’t work for them?… which is why they’re emailing me and asking me to work at a low rate?…

b. Love Classic is a clothing store with a basic website. No idea why they’d need a graphic designer. If you check their career page, there is no job listed.

c. SHRM-SCP is a HR certification, so this makes sense in the name. He/she is a Human Resources Manager. But in the first line of the email, she/he is a Human resources manager. Also, do HR managers do any recruiting these days? Maybe if the job is small enough, I guess?

d. If anyone is listed on LinkedIn, it’s a HR manager/recruiter. Put “Ashley Brian” in the search, and you turn up zero results. Zero! There are Ashley Bryans, but no Ashley Brians.

e. And did anyone else nearly miss the address line in the signature? “3760 Arlington, VA 22203” No street name. Cool cool.

For a long time, scammer emails were fairly identifiable. They didn’t write well, with lots of misspellings, odd phrasing, and strange requests.

Now with AI, scammers can sound perfectly legit. The problem is that they still might not know how a US address works, or how to check someone out on LinkedIn, or how to double-check the email address’s matching website.

What hasn’t changed is that if it sounds too good to be true, it probably is. And I assure you, no one has ever wanted to hire me for my graphic design skills. 🤣

An observation seen on Mastodon:

My responses:

Except for perhaps you and me, no one really teaches HTML. Students are told here’s the syntax, here’s p, a, span, div. Apply these elements and see how this looks. Right from the beginning, students are taught that HTML is about looks, not meaning.

Because HTML-only web pages look boring, almost immediately students are taught CSS, which (mostly) overrides the HTML look. Students conclude that HTML doesn’t matter as its look is overridden by CSS anyway.

Then when they get to JavaScript, they learn that HTML is merely a structure on which they hang their JavaScript events and such.

Prior to 2008 or so, most devs came to the web via HTML and CSS, then JavaScript. We taught separation of powers and spent more time on HTML. We taught HTML is not about the look.

After 2012, most devs came to the web through JavaScript first or almost first. Almost no time was spent on HTML and CSS because future devs learned that JS was the exciting part.

Only now after 10 years of this relentless emphasis of JavaScript are devs realizing that HTML and CSS are 2/3 of the front end and may deserve some time and attention. Only with the recent emphasis on accessibility are devs finally understanding that HTML has some useful characteristics that come for free. There’s no need to program each div with aria this or role that. And 75 layers of nested divs may be a bad thing.

Interactions on discussion boards hundreds of times a day…

Flexbox Froggy is not a good way to learn Flexbox. Yes, it asks students to recall values for properties associated with Flexbox. Yes, it gives you an adorable visual for how those properties and values impact the layout of frogs on lily pads.

Level 8, shown above, involves the flex-direction CSS property, which has a series of possible values. All of this is explained above the window for typing in the appropriate code to align the frogs to the lilypads.

Is the game fun? Absolutely! Students engage with the game quickly and easily. (Yes, also Flexbox Zombies and Flexbox Defender, which are similar games to teach Flexbox properties, with similar flaws to Flexbox Froggy.)

Do students know Flexbox once they reach level 24, the last possible level? No.

But it teaches CSS properties! That's awesome!

Teaches is a strong word.

Flexbox Froggy asks students to remember specific CSS properties and the appropriate value to solve layout problems.

Students may understand or recognize where to place these properties to achieve prescribed layouts. Levels 1-23 all tell the students which properties will solve the presented layout problem. It does not always present the possible properties, asking students to remember those properties.

Level 24, the last level of the game, is unique in that it asks students to apply any of the properties to solve the final layout problem. This is the only level where there are possible incorrect properties provided.

Why did you emphasize remember, understand, and apply?

Because these words are the basis of Bloom’s Taxonomy, a way of describing levels of learning and their depth.

Applied to the coding world, these first three levels of Bloom’s refer to concepts like:

• recalling syntax
• remembering HTML elements and attributes, CSS properties and values
• understanding what those elements, attributes, properties, and values mean, and describing their impact on some code
• filling in partially solved coding problems with appropriate lines of code to make it “work”

Sounds basic, no? That’s because it is. What if we had some other formats to truly bring learning to the students once they were introduced to the Flexbox properties and values?

• What if we asked students to solve problems without giving them the appropriate properties to use?
• What if we didn’t provide a list of values?
• What if we didn’t imply how many lines of CSS it would take to solve the problem?
• What if we gave students the wrong code and asked them to fix it to achieve the layout?

Finally, consider Flexbox’s critical parent/child (or flex-container/flex-item) relationship in HTML elements. Depending on where display: flex; is declared, that HTML element becomes the flex container. Its immediate descendents are flex items. Grandchildren and deeper descendents are unaffected. This directly impacts the styling of the page and is one of the biggest overlooked and misunderstood concepts when learning Flexbox. However, Flexbox Froggy never touches this discussion, focusing mostly on flex container properties. (Indeed, order, a property that specifically applies to children, is mixed with the parent properties. This amplifies learner confusion as this property “doesn’t work” when applied to the parent.)

Well, ok, but I totally learned Flexbox with these games

Try my CodePen which emulates Level 24 in Flexbox Froggy. Match up the colors in the appropriate layout where the comment indicates. Can you do it? If not, why?

“Uh, I’m not a CSS expert.” Mmm hmm.

What are you leading up to, Jen?

If we look at almost any “teaching resource” for learning code, you will find similar problems. Coding instructors are all over the remember, understand, and apply levels of Bloom’s Taxonomy.

Then the instructors immediately jump you to create. “Now that you know everything about Flexbox, go lay out a web page. Have fun!”

What happened to analyze and evaluate?

These are the levels where deep thinking happens. Now that you have a general idea of how a concept works, it’s time to dig in further. Do you really understand what was taught to you? Can you predict what happens if certain properties or values are applied to a layout? Can you debug incorrect code? Can you provide an explanation about why this code works – or why that code doesn’t?

This is what’s missing in today’s coding education. It is assumed students are equipped to do this work on their own. It’s assumed they know this is what comes next, and it’s assumed that they will do it.

Unfortunately, students do not know that this is what they should do next, and they don’t know how to ask these questions. The instructor must lead through these levels, increasing student independence, before turning students loose on their own creative projects.

Expect to hear more from me about this over the coming months.

If you want to hear more about how to teach well online, be sure to subscribe to my Substack newsletter that covers these topics.

In all the web design meetings I've been in over the years, I don't think I've ever heard anyone say: "How do we design this to last." It's just assumed they'll be a redesign every 2-3 years. Why? Why is that assumed?

— Gerry McGovern (@gerrymcgovern) February 15, 2021

My response:

Because techies still drive the desire to redesign the website. We believe that if you don't know the Hottest Framework Of The Moment, our careers are doomed. Marketing/content doesn't know better with the tech. Everyone is exhausted with the constant churn. https://t.co/iGO4szTP4d

— Jen Kramer (@jen4web) February 15, 2021

If we look at the technical timeline, this goes back to the start of the web. In the 1990s, HTML and browsers changed rapidly enough that we needed to redesign websites to keep up with what was new. People had no idea how to design for this medium. Netscape and Internet Explorer were completely different. Table-based layouts were new. Fonts other than Times were new. We had 216 web-safe colors and a 640x480 boat anchor-style monitor to do it all.

In the 2000s, it was a matter of integrating CSS, ripping out tables, and getting people running on content management systems. We started to integrate multimedia and social media. Internet connections got faster, so we used more images.

From 2010-2015, it was making sites responsive.

From 2015 on, it became all about the JavaScript, shortly by all about the web apps.

And now, everyone in Geekland is exhausted by how fast everything changes.

Once the tech department has turned over in 2-3 years, all institutional knowledge has been lost about the site and how it was put together. The current developers trash the current site and how horrible it is. It’s time to redo the site in another technology that the current devs know. Then they depart, new devs are hired, and the cycle begins again.

Imagine a 10-year lifetime for a website. We might change the look of the frontend a little during that time, but we won’t change the fundamental working of the system.

That means our most recent redesign would have been February 2011. Content management systems and jQuery were the thing. Node.js was 18 months old. GitHub was a few years old. Angular was just barely released. Bootstrap wasn’t yet released.

Those websites were perfectly effective, but not as slick as the stateless websites we have today. A website from 2011 would look quite dated in 2021, not just in graphic design, but in technological design.

A 5-year timeline is more realistic with the fast pace of technology. However, if employees continue to turn over in less than 5 year intervals, do we attract the best people to work in the tech department if they’re working on 4-year old technology? Do we define the “best” people as those who are up with the most cutting edge techniques, or those who know the current tech on the current website?

There’s a lot of cultural issues here that we must first resolve. Perhaps the industry is still too young to realize we’re burning ourselves out.

It’s in Squarespace, Wix, Microblog, WordPress, Drupal, Joomla, Softr, Gumroad, Teachable, Thinkific, and countless others.

It’s usually located under Design, Theme, or Advanced.

It looks like this:

It’s The Box.

Into this box, one pastes CSS.

This implies that the website owner:

• knows enough CSS to know what to do with this box

• can form a CSS selector that “works” (i.e. specific enough to the problem but not overly specific)

• knows enough CSS properties to spell out the styling that they want

• understand the cascade enough to know how to make their style work when it doesn’t

Wow. So why is there so much code in no-code site builders?

True, you don’t have to use the box. But if you use no-code tools long enough, you’ll eventually find something that you’d like to tweak just a little bit relative to what you’re able to customize with the tools.

Where does one go to learn this CSS? The professional courses are all focused on layers of command-line tools, over-powered code editors, and Git repositories. None of these things help with The Box.

Furthermore, the browser’s devtools are pretty inpenetrable to those who don’t know HTML and CSS already.

In the short term, we must teach CSS to navigate The Box. (And let’s face it, many of today’s “full stack” coders aren’t able to navigate it, either.)

In the long term, we need to improve our interfaces in some way so The Box isn’t needed.

This is a big problem to solve that no one is talking about.

I keep waiting for the day when higher ed discovers [The Long Tail] (https://www.wired.com/2004/10/tail/).

Twenty years ago, if you wanted a master’s degree, you went to whatever university was nearby. You paid in-state tuition, if applicable. You kept your job and went to school in person at night.

Today, if you want a master’s degree, you have many more choices for degrees. Many offer a 100% online option, or “zero residency.” Some have low residency – part of a class in person, or a whole class in person in a compressed timeline. The idea is that you do your residency while taking a vacation from your job, if needed. But pretty much you can go to any school you want, on any timeline you want (full time or part time) and get the degree you want.

What is the difference between a MSCS at UMass, UVA, UMN, or UCLA? Why would I pick one school over the other?

You can say it’s all about the faculty, the location, the school’s reputation, the specific courses. These elements certainly drive many choices.

But truthfully, it comes down to price. It’s a MSCS. Everyone offers one of these. They aren’t all that different. To attract students, you have to drop your price. This leads to a spiral to the bottom.

Instead, universities could be offering The Ultimate Degree In This Obscure Subject. Who offers the ultimate Digital Storytelling degree? The Web Development degree?

The usual objection has to do with faculty. But since we’re teaching under a majority-adjunct faculty model already, is this really an objection?

[Why not bring back spacer GIFs?] (https://www.joshwcomeau.com/react/modern-spacer-gif/)

Josh advocates for a new separation of concerns, based on compartmentalized technologies (buttons, lists, etc) as opposed to HTML, CSS, JavaScript.

Amusingly, the problem he describes would be fixed with some simple CSS, an understanding of the cascade and inheritance, and an hour or so figuring out how margins really work.

Just like Josh doesn’t understand CSS, not everyone understands JavaScript. It takes a lot of learning to get good at JavaScript. And shockingly, the same is true for CSS.

If you want to have CSS experts who can fix your problems, you can’t put the CSS in your JavaScript.

That’s why there’s separation of concerns, old-school style: HTML, CSS, JavaScript.

That’s why Josh’s proposed separation of concerns, based on components (button, list, media) flat out doesn’t work. This separation of concerns relies on a front-end expert who can keep up with three different and rapidly evolving technologies. It doesn’t allow for expertise in any one area.

Thus, you wind up with a JavaScript expert who doesn’t understand CSS and wonders why no one else (in his sphere) does either.

I am amused that the ultimate solution to Josh’s problem is to go with the old-school separation of concerns and talking to a CSS expert, rather than attempting to bend the web to his will using JavaScript alone.

I teach because I want to make the web a better place.

I want everyone to have a voice.

I don’t want anyone kept out by gatekeepers.

When I started in this industry, the gatekeepers were understanding files and folders, FTP, and syntax errors.

Those gatekeepers are still around, but there’s much more now: command lines; configuring the computer with more complicated technology to get around files, folders, and FTP; new kinds of syntax errors. Tech bros. Smugness. Dismissiveness of anyone not white, male, and no more than 33 years old. A belief that technology must be complicated and hurt to work.

Also: “Really? You’ve never heard of XYZ technology?” Deliver this line with a slight air of smugness and superiority. Follow that with, “I’d be happy to sit down with you and walk you through it,” again delivered in a very slightly condescending way, implying that you cannot figure out this information on your own and thank goodness there’s someone to help you.

So, time for the guide to help the other guides. Let’s build a list of teaching tips.

(As always, my world is front-end web development. These are observations made after watching conference speakers and attending workshops in my field.)

The motivation for teaching is often to get attention or get famous, show off their personal skills, gain fortune, or to try to be an early dominator in some obscure technology or another.

Notice how not one of those reasons is to help other people.

In other words, these prospective teachers want to be the hero, not a guide.

A hero is Batman. A guide is Alfred.

Where would Batman be without Alfred? Luke without Yoda? Cinderella without her fairy godmother?

The hero is the student. The student is slaying the demon of ignorance.

Your role is to help them by providing them the sword. They will take the skills you teach and wield them on a chaotic universe.

Code -> no code:

• Authenticated -> logged in
• Margin -> spacing outside
• Padding -> spacing inside
• Typography -> Fonts (use Word terminology)

It’s more than database -> collection/base/etc.

There’s a pile of 20-somethings building no-code tools without realizing that many of these problems have been solved before. We’ve all seen the movie already.

In 2005, we had a battle between WordPress and Joomla. WordPress won. They had a great user interface. They tested it carefully and made sure it was “intuitive.”

Today, no-code tools are “intuitive and easy to use” for the people who build them, or the people who are invested in learning them. They are not easy to pick up. User testing would show that these tools are still pretty uniformly horrible.

No-code isn’t getting rid of coding syntax, but keeping all of the names, labels, and requirements of coding.

You have to take it a step further. If I still have to know how to think about an application, how to build it, where the data is going, which box is the right one to apply the class, then you haven’t really solved my no-code problems.

Start with terminology. Stop thinking like a coder.