#she's going to learn how to code beyond css and html WATCH OUT | Explore Tumblr posts and blogs

suzanneshannon · 4 years ago

Text

Want to get better at code? Teach someone CSS.

A friend of mine recently asked me to teach her to code. She was an absolute beginner, having no idea what coding really involves. I decided to start where I started: HTML and CSS. Using CodePen, we started forking Pens and altering them. Soon, a learning path started to unravel.

The aim of this article is not to teach basic CSS to those who already know it but rather to highlight the things that inspired a newcomer and hopefully inspire you to pass on some knowledge to others if the opportunity arises. It felt good to help someone out and, in turn, I learned some really valuable lessons that have changed the way I think about my code. Win win!

So, here we go: five lessons I learned from teaching someone CSS.

Lesson 1: Don’t start from scratch

When I starting coding for the web 12 years ago, I began with layout — positioning with floats, margins, padding and position declarations. It might seem outdated these days, but still, this is where I went right away with my new coding buddy.

It didn’t go that well.

As you might guess, starting with something like, “Here is how to position an empty box in the middle of the screen,” was a mistake. How uninspiring! And even though I was impressed with my own ability to demonstrate how Flexbox can position an element in the center of the screen (more on that later), I was immediately faced with lots of additional, non-positional questions.

“So how do you change the colors?”

“Can it change shape when hovered over?”

“What fonts can you use on the web?”

I thought we were weeks away from all that.

So, my plans of teaching the 12-column grid went out the window and we pulled up Chris’ named color chart alongside a couple of forked Pens and started playing around. First off, we changed the colors of Cassidy Williams Netflix/Netlify logo. Wow! Instant hit.

<a class="container" href="https://netlify.com" target="_blank"> <div class="logo"> <div class="uno"></div> <div class="dos"></div> <div class="tres"></div> </div> <div class="name">Prettier</div> </a>

Then a few simple tweaks to the CSS:

body { background: #F9F2DB; color: #092935; font-size: 50px; }   a { color: #092935; }   .logo .uno, .dos, .tres { background: #C61561; } .logo .dos { box-shadow: 0 0 20px #F9F2DB; } .logo::before { background: #F9F2DB; }   .name { letter-spacing: 8px; }

Within minutes, my friend was hooked! There was no boring positioning to worry about, just a clear example of how a few simple lines of code can change something so familiar into something entirely different.

Then it kicked in that you can change the color of anything! We loaded up a couple of well known sites in the browser and changed the colors of some text and backgrounds with DevTools, all in a couple of minutes. Mission accomplished! My friend was hooked.

Lesson learned: Don’t worry about trying to build something from scratch. Have a play with what’s already out there!

Lesson 2: Comments

This isn’t where I had planned to go with my planned class, but the question of why some parts of CSS start with /* and end with */ came up, so we went with it.

This one really had me thinking about my own work. I really do not comment my code enough. Watching a new coder comment everything (and I mean everything) reminded me just how helpful comments are, not only for yourself, but also to a wider team, or even future you. (Sarah Drasner has a great talk on this topic).

And here is the thing: until then, I thought I was commenting pretty diligently. However, watching someone else do it made me realize how many times I look at a piece of code (particularly JavaScript) and wish I had put a line or two in there to remind myself what I was doing. A ten-second task might have saved me five (or perhaps even more) minutes down the road. That adds up and is now something I am working on.

Lesson learned: Comment more.

Lesson 3: Positioning

We started with some basic HTML, and honestly, I saw my friend’s eyes glazing over almost immediately. It just looks so dull when you can’t see it doing anything right away (unlike editing pre-written CSS). However, we stuck with it, and got results.

Take my word for it, don’t start by positioning empty <div> elements with 1-pixel borders around them. You’ll lose your audience very quickly. Put a picture of a dog in there — or baby Yoda or a pizza — just as long as it’s anything other than an empty element.

We then turned to Flexbox. We actually found CSS Grid a bit too much at the start. We looked briefly at CSS Grid, but when reading lots of articles about it, it’s clear that many assume the reader already has familiarity with CSS, Flexbox in particular. My friend decided to start with Flexbox.

An admission on my part: I am so used to using UI frameworks (especially Bootstrap) that I very rarely position anything in Flexbox by writing the CSS myself. I know how it works and (most of) the declarations, but I still very rarely write it out myself, even in situations where it would be relatively easy. Teaching made me think about my reliance on UI frameworks as a whole. Yes, they are undoubtedly amazing and save us tons of time on projects, but I recalled using Bootstrap on a recent project that was essentially two pages and probably didn’t need it!

Lesson learned: If the project is something small with a minimal number of elements to position, then consider ditching the framework and code from scratch! The end result will be lightweight, fast, and way more satisfying!

Lesson 4: Typography

I love typography. I’ve been lucky enough to work with great designers over the past few years and that has really helped me dial in on the nuances of type. It’s amazing how changes to things like line-height and letter-spacing can really help lift a design from average to amazing. This was something I was keen to impress upon my eager new student. Well, I needn’t have bothered, as the only thing of interest (initially) was changing the fonts and then, crucially for me, the sheer number of fonts available for us to use. The choices are almost limitless and the services and foundries offering web fonts have exploded in the past few years to a point where anything is possible, at speed with little impact on load times.

But here is the thing about designers (and front-end developers like myself): we can be a bit narrow-minded in our font choices. Designs tend to stick to the same fonts from the same services (Roboto and Open Sans anyone?) because we know they are easy to implement and that they work. Exploring fonts with someone new to the trade forced me to look beyond the old staples and try a few new things. I’m now looking for new pairings that work together and dialing in on how they work on screen and impact the whole look and feel of a design. In short, teaching someone else about type has improved my own journey with type, which was probably stuck in something like 2017.

Lesson learned: Keep up to date with type.

Lesson 5. :hover makes everything fun

Things were going OK up to this point, but as you can probably imagine, things were still pretty static. Without really planning, we stumbling into adding a hover effect on on an element and it was an instant hook, just like it was changing colors for the first time!

Hovers add interaction and easily impress, which makes them great for a newcomer to play around with. Scaling objects, changing a box from square to round, hiding content — these are the types of thing that can all be done so easily that hovers are an ideal way for a new coder to get instant results. And here’s the thing: “‘playing” around like this opens other doors. “What if I just do this?” is something many us rarely get to ask ourselves in our day-to-day jobs. With defined designs to work from, there is often little chance to play and equally less chance to experiment.

CodePen Embed Fallback

So, here is the final lesson: Make time to play. Just by being asked, “How do you make this thing do that?” has forced me to learn new things, see what’s new in CSS, and see what I can take back into my day-to-day work. Experimenting (or better yet, playing) has made me a better designer, and I’ll be doing more.

CodePen Embed Fallback

Lesson learned: Make time to play.

Conclusion

If my time teaching CSS to a newbie has taught me anything, it’s that I rarely write code from scratch anymore. Code snippets and autocomplete save me hours, but it’s those same conveniences that let me forget about some really basic stuff. Stuff I should know. By teaching someone else, even if just for 15 minutes now and then, my coding has generally improved and my eyes are open to new ideas and techniques that I may not have otherwise considered.

And as for my friend? Well, she was so taken by CSS in our short time together that she is now doing an online course that includes HTML, which doesn’t seem so dull now that she knows what it is capable of doing!

The post Want to get better at code? Teach someone CSS. appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Want to get better at code? Teach someone CSS. published first on https://deskbysnafu.tumblr.com/

0 notes

statrano · 6 years ago

Text

Root Robotics–Great Way to Extend Hour of Code

Now that you’ve engaged your students with awesome Hour of Code fun, I’m thrilled to introduce the incredible Root Robotics for going far beyond the hour! Root’s a versatile, engaging robotics and coding program that grows with students from pre-K up through grade 12. Root comes to us from our friends at Sunburst Digital – who provide engaging STEAM and SafeSchools programs for schools.

This holiday season, you can enter to win a $100 credit applied to a purchase of Root or ANY OTHER STEAM solution from Sunburst here! Sunburst wants to hear about the innovative ways you’ve engaged your students with Hour of Code – share a few lines about your activities, and you’ll be entered to win! Learn more and fill out your entry form here.

Created by learning and robotics experts at Harvard University, Root is a hexagonal-shaped robot that climbs whiteboards and traverses tables. Learners can program Root to move, turn, draw, erase, scan colors, play music, light up, sense touches, feel bumps, detect magnetic surfaces, perceive light, and respond to sensors in a phone or tablet.

Root’s design enables whole class instruction and project-based learning in groups. In addition to exciting, easy-to-implement lessons that teachers can deliver on the classroom whiteboard, each Root comes with a foldable whiteboard mat, perfect for groups to use anywhere.

The projects and teaching materials included with the system enable educators to embed computational thinking across the curriculum, including math and ELA.

Root is the ideal student coding companion, from early learning with engaging graphical coding, through block coding and then text coding for advanced students. The sky’s the limit with Root! Learn more about Root and enter to win a $100 credit to apply to Root or any other Sunburst STEAM solution here! Here’s a perfect video to give you a little more feeling for what Root can do! It’s a bit over eight minutes but worth every second!

youtube

You can’t watch this video and not get excited about Root!

***

If you’re looking for other awesome resources for your students, check out a few of my favorites from the Sunburst catalog below. You can apply your $100 credit to any of these awesome tools. Please reach out to them here if you want to learn more!

StudioWeb (NEW VERSION)

Coding Curriculum & Certifications (Grades 6-12)

An all-new version of StudioWeb has just been released – and we’re excited for the Sunburst community to now have access to this incredible program. With StudioWeb, your students will build job-ready web design and development coding skills. The curriculum includes text-based coding with JavaScript, Python, HTML, CSS, PHP, SQL. No prior coding experience is required for students, and teacher guidance makes implementation easy. StudioWeb also provides comprehensive progress tracking, auto grading, and district level reports. Self-paced learning ensures success of all students, with open-ended and flexible lesson plans.

Visit Website | Courses | Certification | Testimonials | Overview (PDF)

Wonder Workshop

Coding & Robotics Solutions (Grades K-12)

Wonder Workshop is a combined hardware/software solution especially designed for key elements of hands-on, sensory play and experimentation. Students can experiment with design thinking across subjects while building coding skills to program a robot with their own avatar. Wonder Workshop’s middle school solution is an incredibly clever robot named CUE and includes emotive artificial intelligence systems, enhanced sensor capabilities, and more.

Visit Website | Case Studies | Teacher Resources | Packages

Kano

Digital Fluency and Creative Technology Curriculum (Grades 3-8)

Kano demystifies how technology works. Kano knows that a steady stream of innovative instructional resources (hardware, software, and curriculum) are needed to ensure that students have the kind of foundational knowledge that endures. Students build their own Raspberry-Pi-based computers, light displays, and motion sensors and create art, games, music, and more with code, guided along every step of the way. Teachers receive full curriculum support.

Visit Website | Case Study | Teacher Resources | Overview (PDF)

SAM Labs

Coding & IoT Curriculum (Grades 4-12)

SAM Labs provides everything you need to deliver the most engaging STEAM learning experience for your classroom, STEAM lab, or makerspace. Teachers and students love creating projects with SAM Labs, integrating coding across many subjects including biology, life sciences, math, and more. SAM Labs kits seamlessly connect software and hardware with lesson plans, enabling students to be creative in building engineering projects with sensors. Turn the Internet of Things (IoT) into an accessible, experimental, interactive and fun experience for learners of all abilities.

Visit Website | Sample Projects | Sample Lesson (PDF) | Overview (PDF)

One more Sunburst program I’m particularly excited about is Sunburst Safe Schools Solutions

Sunburst has launched a new portfolio of programs focused on Safe Schools and social-emotional learning (SEL) as a complement to their STEAM suite––really supporting those NGSS standards and 21st-century skills around collaboration and communication. They offer best-in-class programs available that cover grades K-12, including:

social-emotional learning

early intervention for school threats

building positive school environments

classroom behavioral management

They are looking for early innovators to support the launch of these programs. Please let them know if you are interested in learning more or visit the SafeSchools website.

–this is a sponsored post but opinions are my own. I don’t share webtools on Ask a Tech Teacher that I don’t believe are great for teachers and students.

Jacqui Murray has been teaching K-18 technology for 30 years. She is the editor/author of over a hundred tech ed resources including a K-8 technology curriculum, K-8 keyboard curriculum, K-8 Digital Citizenship curriculum. She is an adjunct professor in tech ed, Master Teacher, webmaster for four blogs, an Amazon Vine Voice reviewer, CAEP reviewer, CSTA presentation reviewer, freelance journalist on tech ed topics, contributor to NEA Today and TeachHUB, and author of the tech thrillers, To Hunt a Sub and Twenty-four Days. You can find her resources at Structured Learning.

Root Robotics–Great Way to Extend Hour of Code published first on https://seminarsacademy.tumblr.com/

0 notes

corpasa · 6 years ago

Text

Root Robotics–Great Way to Extend Hour of Code

The projects and teaching materials included with the system enable educators to embed computational thinking across the curriculum, including math and ELA.

youtube

You can’t watch this video and not get excited about Root!

***

StudioWeb (NEW VERSION)

Coding Curriculum & Certifications (Grades 6-12)

Visit Website | Courses | Certification | Testimonials | Overview (PDF)

Wonder Workshop

Coding & Robotics Solutions (Grades K-12)

Visit Website | Case Studies | Teacher Resources | Packages

Kano

Digital Fluency and Creative Technology Curriculum (Grades 3-8)

Visit Website | Case Study | Teacher Resources | Overview (PDF)

SAM Labs

Coding & IoT Curriculum (Grades 4-12)

Visit Website | Sample Projects | Sample Lesson (PDF) | Overview (PDF)

One more Sunburst program I’m particularly excited about is Sunburst Safe Schools Solutions

social-emotional learning

early intervention for school threats

building positive school environments

classroom behavioral management

They are looking for early innovators to support the launch of these programs. Please let them know if you are interested in learning more or visit the SafeSchools website.

–this is a sponsored post but opinions are my own. I don’t share webtools on Ask a Tech Teacher that I don’t believe are great for teachers and students.

Root Robotics–Great Way to Extend Hour of Code published first on https://medium.com/@DLBusinessNow

0 notes

endevia · 6 years ago

Text

Root Robotics–Great Way to Extend Hour of Code

The projects and teaching materials included with the system enable educators to embed computational thinking across the curriculum, including math and ELA.

youtube

You can’t watch this video and not get excited about Root!

***

StudioWeb (NEW VERSION)

Coding Curriculum & Certifications (Grades 6-12)

Visit Website | Courses | Certification | Testimonials | Overview (PDF)

Wonder Workshop

Coding & Robotics Solutions (Grades K-12)

Visit Website | Case Studies | Teacher Resources | Packages

Kano

Digital Fluency and Creative Technology Curriculum (Grades 3-8)

Visit Website | Case Study | Teacher Resources | Overview (PDF)

SAM Labs

Coding & IoT Curriculum (Grades 4-12)

Visit Website | Sample Projects | Sample Lesson (PDF) | Overview (PDF)

One more Sunburst program I’m particularly excited about is Sunburst Safe Schools Solutions

social-emotional learning

early intervention for school threats

building positive school environments

classroom behavioral management

They are looking for early innovators to support the launch of these programs. Please let them know if you are interested in learning more or visit the SafeSchools website.

–this is a sponsored post but opinions are my own. I don’t share webtools on Ask a Tech Teacher that I don’t believe are great for teachers and students.

Root Robotics–Great Way to Extend Hour of Code published first on https://medium.com/@greatpricecourse

0 notes

evnoweb · 6 years ago

Text

Root Robotics–Great Way to Extend Hour of Code

The projects and teaching materials included with the system enable educators to embed computational thinking across the curriculum, including math and ELA.

youtube

You can’t watch this video and not get excited about Root!

***

StudioWeb (NEW VERSION)

Coding Curriculum & Certifications (Grades 6-12)

Visit Website | Courses | Certification | Testimonials | Overview (PDF)

Wonder Workshop

Coding & Robotics Solutions (Grades K-12)

Visit Website | Case Studies | Teacher Resources | Packages

Kano

Digital Fluency and Creative Technology Curriculum (Grades 3-8)

Visit Website | Case Study | Teacher Resources | Overview (PDF)

SAM Labs

Coding & IoT Curriculum (Grades 4-12)

Visit Website | Sample Projects | Sample Lesson (PDF) | Overview (PDF)

One more Sunburst program I’m particularly excited about is Sunburst Safe Schools Solutions

social-emotional learning

early intervention for school threats

building positive school environments

classroom behavioral management

They are looking for early innovators to support the launch of these programs. Please let them know if you are interested in learning more or visit the SafeSchools website.

–this is a sponsored post but opinions are my own. I don’t share webtools on Ask a Tech Teacher that I don’t believe are great for teachers and students.

Root Robotics–Great Way to Extend Hour of Code published first on https://medium.com/@DigitalDLCourse

0 notes

mariaaklnthony · 7 years ago

Text

My Accessibility Journey: What I’ve Learned So Far

Last year I gave a talk about CSS and accessibility at the stahlstadt.js meetup in Linz, Austria. Afterward, an attendee asked why I was interested in accessibility: Did I or someone in my life have a disability?

I’m used to answering this question—to which the answer is no—because I get it all the time. A lot of people seem to assume that a personal connection is the only reason someone would care about accessibility.

This is a problem. For the web to be truly accessible, everyone who makes websites needs to care about accessibility. We tend to use our own abilities as a baseline when we’re designing and building websites. Instead, we need to keep in mind our diverse users and their diverse abilities to make sure we’re creating inclusive products that aren’t just designed for a specific range of people.

Another reason we all should think about accessibility is that it makes us better at our jobs. In 2016 I took part in 10k Apart, a competition held by Microsoft and An Event Apart. The objective was to build a compelling web experience that worked without JavaScript and could be delivered in 10 kB. On top of that, the site had to be accessible. At the time, I knew about some accessibility basics like using semantic HTML, providing descriptions for images, and hiding content visually. But there was still a lot to learn.

As I dug deeper, I realized that there was far more to accessibility than I had ever imagined, and that making accessible sites basically means doing a great job as a developer (or as a designer, project manager, or writer).

Accessibility is exciting

Web accessibility is not about a certain technology. It’s not about writing the most sophisticated code or finding the most clever solution to a problem; it’s about users and whether they’re able to use our products.

The focus on users is the main reason why I’m specializing in accessibility rather than solely in animation, performance, JavaScript frameworks, or WebVR. Focusing on users means I have to keep up with pretty much every web discipline, because users will load a page, deal with markup in some way, use a design, read text, control a JavaScript component, see animation, walk through a process, and navigate. What all those things have in common is that they’re performed by someone in front of a device. What makes them exciting is that we don’t know which device it will be, or which operating system or browser. We also don’t know how our app or site will be used, who will use it, how fast their internet connection will be, or how powerful their device will be.

Making accessible sites forces you to engage with all of these variables—and pushes you, in the process, to do a great job as a developer. For me, making accessible sites means making fast, resilient sites with great UX that are fun and easy to use even in conditions that aren’t ideal.

I know, that sounds daunting. The good news, though, is that I’ve spent the last year focusing on some of those things, and I’ve learned several important lessons that I’m happy to share.

1. Accessibility is a broad concept

Many people, like me pre-2016, think making your site accessible is synonymous with making it accessible to people who use screen readers. That’s certainly hugely important, but it’s only one part of the puzzle. Accessibility means access for everyone:

If your site takes ten seconds to load on a mobile connection, it’s not accessible.

If your site is only optimized for one browser, it’s not accessible.

If the content on your site is difficult to understand, your site isn’t accessible.

It doesn’t matter who’s using your website or when, where, and how they’re doing it. What matters is that they’re able to do it.

The belief that you have to learn new software or maybe even hardware to get started with accessibility is a barrier for many developers. At some point you will have to learn how to use a screen reader if you really want to get everything right, but there’s a lot more to do before that. We can make a lot of improvements that help everyone, including people with visual impairments, by simply following best practices.

2. There are permanent, temporary, and situational impairments

Who benefits from a keyboard-accessible site? Only a small percentage of users, some might argue. Aaron Gustafson pointed me to the Microsoft design toolkit, which helped me broaden my perspective. People with permanent impairments are not the only ones who benefit from accessibility. There are also people with temporary and situational impairments who’d be happy to have an alternative way of navigating. For example, someone with a broken arm, someone who recently got their forearm tattooed, or a parent who’s holding their kid in one arm while having to check something online. When you watch a developer operate their editor, it sometimes feels like they don’t even know they have a mouse. Why not give users the opportunity to use your website in a similar way?

As you think about the range of people who could benefit from accessibility improvements, the group of beneficiaries tends to grow much bigger. As Derek Featherstone has said, “When something works for everyone, it works better for everyone.”

3. The first step is to make accessibility a requirement

I’ve been asked many times whether it’s worth the effort to fix accessibility, how much it costs, and how to convince bosses and colleagues. My answer to those questions is that you can improve things significantly without even having to use new tools, spend extra money, or ask anyone’s permission.

The first step is to make accessibility a requirement—if not on paper, then at least in your head. For example, if you’re looking for a slider component, pick one that’s accessible. If you’re working on a design, make sure color contrasts are high enough. If you’re writing copy, use language that is easy to understand.

We ask ourselves many questions when we make design and development decisions: Is the code clean? Does the site look nice? Is the UX great? Is it fast enough? Is it well-documented?

As a first step, add one more question to your list: Is it accessible?

4. Making accessible sites is a team sport

Another reason why making websites accessible sounds scary to some developers is that there is a belief that we’re the only ones responsible for getting it right.

In fact, as Dennis Lembree reminds us, “Nearly everyone in the organization is responsible for accessibility at some level.”

It’s a developer’s job to create an accessible site from a coding perspective, but there are many things that have to be taken care of both before and after that. Designs must be intuitive, interactions clear and helpful, copy understandable and readable. Relevant personas and use cases have to be defined, and tests must be carried out accordingly. Most importantly, leadership and teams have to see accessibility as a core principle and requirement, which brings me to the next point: communication.

5. Communication is key

After talking to a variety of people at meetups and conferences, I think one of the reasons accessibility often doesn’t get the place it deserves is that not everyone knows what it means. Many times you don’t even have to convince your team, but rather just explain what accessibility is. If you want to get people on board, it matters how you approach them.

The first step here is to listen. Talk to your colleagues and ask why they make certain design, development, or management decisions. Try to find out if they don’t approach things in an accessible way because they don’t want to, they’re not allowed to, or they just never thought of it. You’ll have better results if they don’t feel bad, so don’t try to guilt anyone into anything. Just listen. As soon as you know why they do things the way they do, you’ll know how to address your concerns.

Highlight the benefits beyond accessibility

You can talk about accessibility without mentioning it. For example, talk about typography and ideal character counts per line and how beautiful text is with the perfect combination of font size and line height. Demonstrate how better performance impacts conversion rates and how focusing on accessibility can promote out-of-the-box thinking that improves usability in general.

Challenge your colleagues

Some people like challenges. At a meetup, a designer who specializes in accessibility once said that one of the main reasons she loves designing with constraints in mind is that it demands a lot more of her than going the easy way. Ask your colleagues, Can we hit a speed index below 1000? Do you think you can design that component in such a way that it’s keyboard-accessible? My Nokia 3310 has a browser—wouldn’t it be cool if we could make our next website work on that thing as well?

Help people empathize

In his talk “Every Day Website Accessibility,” Scott O’Hara points out that it can be hard for someone to empathize if they are unaware of what they should be empathizing with. Sometimes people just don’t know that certain implementations might be problematic for others. You can help them by explaining how people who are blind or who can’t use a mouse, use the web. Even better, show videos of how people navigate the web without a mouse. Empathy prompts are also a great of way of illustrating different circumstances under which people are surfing the web.

6. Talk about accessibility before a projects kicks off

It’s of course a good thing if you’re fixing accessibility issues on a site that’s already in production, but that has its limitations. At some point, changes may be so complicated and costly that someone will argue that it’s not worth the effort. If your whole team cares about accessibility from the very beginning, before a box is drawn or a line of code is written, it’s much easier, effective, and cost-efficient to make an accessible product.

7. A solid knowledge of HTML solves a lot of problems

It’s impressive to see how JavaScript and the way we use it has changed in recent years. It has become incredibly powerful and more important than ever for web development. At the same time, it seems HTML has become less important. There is an ongoing discussion about CSS in JavaScript and whether it’s more efficient and cleaner than normal CSS from a development perspective. What we should talk about instead is the excessive use of <div> and <span> elements at the expense of other elements. It makes a huge difference whether we use a link or a <div> with an onclick handler. There’s also a difference between links and buttons when it comes to accessibility. Form items need <label> elements, and a sound document outline is essential. Those are just a few examples of absolute basics that some of us forgot or never learned. Semantic HTML is one of the cornerstones of accessible web development. Even if we write everything in JavaScript, HTML is what is finally rendered in the user’s browser.

(Re)learning HTML and using it consciously prevents and fixes many accessibility issues.

8. JavaScript is not the enemy, and sometimes JavaScript even improves accessibility

I’m one of those people who believes that most websites should be accessible even when JavaScript fails to execute. That doesn’t mean that I hate JavaScript; of course not—it pays part of my rent. JavaScript is not the enemy, but it’s important that we use it carefully because it’s very easy to change the user experience for the worse otherwise.

Not that long ago, I didn’t know that JavaScript could improve accessibility. We can leverage its power to make our websites more accessible for keyboard users. We can do things like trapping focus in a modal window, adding key controls to custom components, or showing and hiding content in an accessible manner.

There are many impressive and creative CSS-only implementations of common widgets, but they’re often less accessible and provide worse UX than their JavaScript equivalents. In a post about building a fully accessible help tooltip, Sara Soueidan explains why JavaScript is important for accessibility. “Every single no-JS solution came with a very bad downside that negatively affected the user experience,” she writes.

9. It’s a good time to know vanilla CSS and JavaScript

For a long time, we’ve been reliant on libraries, frameworks, grid systems, and polyfills because we demanded more of browsers than they were able to give us. Naturally, we got used to many of those tools, but from time to time we should take a step back and question if we really still need them. There were many problems that Bootstrap and jQuery solved for us, but do those problems still exist, or is it just easier for us to write $() instead of document.querySelector()?

jQuery is still relevant, but browser inconsistencies aren’t as bad as they used to be. CSS Grid Layout is supported in all major desktop browsers, and thanks to progressive enhancement we can still provide experiences for legacy browsers. We can do feature detection natively with feature queries, testing has gotten much easier, and caniuse and MDN help us understand what browsers are capable of. Many people use frameworks and libraries without knowing what problems those tools are solving. To decide whether it makes sense to add the extra weight to your site, you need a solid understanding of HTML, CSS, and JavaScript. Instead of increasing the page weight for older browsers, it’s often better to progressively enhance an experience. Progressively enhancing our websites—and reducing the number of requests, kilobytes, and dependencies—makes them faster and more robust, and thus more accessible.

10. Keep learning about accessibility and share your knowledge

I’m really thankful that I’ve learned all this in the past few months. Previously, I was a very passive part of the web community for a very long time. Ever since I started to participate online, attend and organize events, and write about web-related topics, especially accessibility, things have changed significantly for me and I’ve grown both personally and professionally.

Understanding the importance of access and inclusion, viewing things from different perspectives, and challenging my decisions has helped me become a better developer.

Knowing how things should be done is great, but it’s just the first step. Truly caring, implementing, and most importantly sharing your knowledge is what makes an impact.

Share your knowledge

Don’t be afraid to share what you’ve learned. Write articles, talk at meetups, and give in-house workshops. The distinct culture of sharing knowledge is one of the most important and beautiful things about our industry.

Go to conferences and meetups

Attending conferences and meetups is very valuable because you get to meet many different people from whom you can learn. There are several dedicated accessibility events and many conferences that feature at least one accessibility talk.

Organize meetups

Dennis Deacon describes his decision to start and run an accessibility meetup as a life-changing experience. Meetups are very important and valuable for the community, but organizing a meetup doesn’t just bring value to attendees and speakers. As an organizer, you get to meet all these people and learn from them. By listening and by understanding how they see and approach things, and what’s important to them, you are able to broaden your horizons. You grow as a person, but you also get to meet other professionals, agencies, and companies from which you may also benefit professionally.

Invite experts to your meetup or conference

If you’re a meetup or conference organizer, you can have a massive impact on the role accessibility plays in our community. Invite accessibility experts to your event and give the topic a forum for discussion.

Follow accessibility experts on Twitter

Follow experts on Twitter to learn what they’re working on, what bothers them, and what they think about recent developments in inclusive web development and design in general. I’ve learned a lot from the following people: Aaron Gustafson, Adrian Roselli, Carie Fisher, Deborah Edwards-Onoro, Heydon Pickering, Hugo Giraudel, Jo Spelbrink, Karl Groves, Léonie Watson, Marco Zehe, Marcy Sutton, Rob Dodson, Scott O’Hara, Scott Vinkle, and Steve Faulkner.

11. Simply get started

You don’t have to go all-in from the very beginning. If you improve just one thing, you’re already doing a great job in bringing us closer to a better web. Just get started and keep working.

There are a lot of resources out there, and trying to find out how and where to start can get quite overwhelming. I’ve gathered a few sites and books that helped me; hopefully they will help you as well. The following lists are by no means exhaustive.

Video series

This free Udacity course is a great way to get started.

Rob Dodson covers many different accessibility topics in his video series A11ycasts (a11y is short for accessibility—the number eleven stands for the number of letters omitted).

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

“A Developer’s Guide to Better Accessibility” (article)

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

“Building a Culture of Accessibility: Leadership Roles” (article)

“The Web Should Just Work for Everyone” (article)

“A Very Good Time to Understand CSS Layout” (article)

“JavaScript Is Not an Enemy of Accessibility!” (article)

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

#My Accessibility Journey: What I’ve Learned So Far

0 notes

pattersondonaldblk5 · 7 years ago

Text

My Accessibility Journey: What I’ve Learned So Far

Accessibility is exciting

I know, that sounds daunting. The good news, though, is that I’ve spent the last year focusing on some of those things, and I’ve learned several important lessons that I’m happy to share.

1. Accessibility is a broad concept

If your site takes ten seconds to load on a mobile connection, it’s not accessible.

If your site is only optimized for one browser, it’s not accessible.

If the content on your site is difficult to understand, your site isn’t accessible.

It doesn’t matter who’s using your website or when, where, and how they’re doing it. What matters is that they’re able to do it.

2. There are permanent, temporary, and situational impairments

3. The first step is to make accessibility a requirement

We ask ourselves many questions when we make design and development decisions: Is the code clean? Does the site look nice? Is the UX great? Is it fast enough? Is it well-documented?

As a first step, add one more question to your list: Is it accessible?

4. Making accessible sites is a team sport

Another reason why making websites accessible sounds scary to some developers is that there is a belief that we’re the only ones responsible for getting it right.

In fact, as Dennis Lembree reminds us, “Nearly everyone in the organization is responsible for accessibility at some level.”

5. Communication is key

Highlight the benefits beyond accessibility

Challenge your colleagues

Help people empathize

6. Talk about accessibility before a projects kicks off

7. A solid knowledge of HTML solves a lot of problems

(Re)learning HTML and using it consciously prevents and fixes many accessibility issues.

8. JavaScript is not the enemy, and sometimes JavaScript even improves accessibility

9. It’s a good time to know vanilla CSS and JavaScript

10. Keep learning about accessibility and share your knowledge

Understanding the importance of access and inclusion, viewing things from different perspectives, and challenging my decisions has helped me become a better developer.

Knowing how things should be done is great, but it’s just the first step. Truly caring, implementing, and most importantly sharing your knowledge is what makes an impact.

Share your knowledge

Go to conferences and meetups

Organize meetups

Invite experts to your meetup or conference

Follow accessibility experts on Twitter

11. Simply get started

You don’t have to go all-in from the very beginning. If you improve just one thing, you’re already doing a great job in bringing us closer to a better web. Just get started and keep working.

Video series

This free Udacity course is a great way to get started.

Rob Dodson covers many different accessibility topics in his video series A11ycasts (a11y is short for accessibility—the number eleven stands for the number of letters omitted).

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

“A Developer’s Guide to Better Accessibility” (article)

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

“Building a Culture of Accessibility: Leadership Roles” (article)

“The Web Should Just Work for Everyone” (article)

“A Very Good Time to Understand CSS Layout” (article)

“JavaScript Is Not an Enemy of Accessibility!” (article)

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

#My Accessibility Journey: What I’ve Learned So Far

0 notes

dustinwootenne · 7 years ago

Text

My Accessibility Journey: What I’ve Learned So Far

Accessibility is exciting

I know, that sounds daunting. The good news, though, is that I’ve spent the last year focusing on some of those things, and I’ve learned several important lessons that I’m happy to share.

1. Accessibility is a broad concept

If your site takes ten seconds to load on a mobile connection, it’s not accessible.

If your site is only optimized for one browser, it’s not accessible.

If the content on your site is difficult to understand, your site isn’t accessible.

It doesn’t matter who’s using your website or when, where, and how they’re doing it. What matters is that they’re able to do it.

2. There are permanent, temporary, and situational impairments

3. The first step is to make accessibility a requirement

We ask ourselves many questions when we make design and development decisions: Is the code clean? Does the site look nice? Is the UX great? Is it fast enough? Is it well-documented?

As a first step, add one more question to your list: Is it accessible?

4. Making accessible sites is a team sport

Another reason why making websites accessible sounds scary to some developers is that there is a belief that we’re the only ones responsible for getting it right.

In fact, as Dennis Lembree reminds us, “Nearly everyone in the organization is responsible for accessibility at some level.”

5. Communication is key

Highlight the benefits beyond accessibility

Challenge your colleagues

Help people empathize

6. Talk about accessibility before a projects kicks off

7. A solid knowledge of HTML solves a lot of problems

(Re)learning HTML and using it consciously prevents and fixes many accessibility issues.

8. JavaScript is not the enemy, and sometimes JavaScript even improves accessibility

9. It’s a good time to know vanilla CSS and JavaScript

10. Keep learning about accessibility and share your knowledge

Understanding the importance of access and inclusion, viewing things from different perspectives, and challenging my decisions has helped me become a better developer.

Knowing how things should be done is great, but it’s just the first step. Truly caring, implementing, and most importantly sharing your knowledge is what makes an impact.

Share your knowledge

Go to conferences and meetups

Organize meetups

Invite experts to your meetup or conference

Follow accessibility experts on Twitter

11. Simply get started

You don’t have to go all-in from the very beginning. If you improve just one thing, you’re already doing a great job in bringing us closer to a better web. Just get started and keep working.

Video series

This free Udacity course is a great way to get started.

Rob Dodson covers many different accessibility topics in his video series A11ycasts (a11y is short for accessibility—the number eleven stands for the number of letters omitted).

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

“A Developer’s Guide to Better Accessibility” (article)

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

“Building a Culture of Accessibility: Leadership Roles” (article)

“The Web Should Just Work for Everyone” (article)

“A Very Good Time to Understand CSS Layout” (article)

“JavaScript Is Not an Enemy of Accessibility!” (article)

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

#My Accessibility Journey: What I’ve Learned So Far

0 notes

jeanshesallenberger · 7 years ago

Text

My Accessibility Journey: What I’ve Learned So Far

Accessibility is exciting

I know, that sounds daunting. The good news, though, is that I’ve spent the last year focusing on some of those things, and I’ve learned several important lessons that I’m happy to share.

1. Accessibility is a broad concept

If your site takes ten seconds to load on a mobile connection, it’s not accessible.

If your site is only optimized for one browser, it’s not accessible.

If the content on your site is difficult to understand, your site isn’t accessible.

It doesn’t matter who’s using your website or when, where, and how they’re doing it. What matters is that they’re able to do it.

2. There are permanent, temporary, and situational impairments

3. The first step is to make accessibility a requirement

We ask ourselves many questions when we make design and development decisions: Is the code clean? Does the site look nice? Is the UX great? Is it fast enough? Is it well-documented?

As a first step, add one more question to your list: Is it accessible?

4. Making accessible sites is a team sport

Another reason why making websites accessible sounds scary to some developers is that there is a belief that we’re the only ones responsible for getting it right.

In fact, as Dennis Lembree reminds us, “Nearly everyone in the organization is responsible for accessibility at some level.”

5. Communication is key

Highlight the benefits beyond accessibility

Challenge your colleagues

Help people empathize

6. Talk about accessibility before a projects kicks off

7. A solid knowledge of HTML solves a lot of problems

(Re)learning HTML and using it consciously prevents and fixes many accessibility issues.

8. JavaScript is not the enemy, and sometimes JavaScript even improves accessibility

9. It’s a good time to know vanilla CSS and JavaScript

10. Keep learning about accessibility and share your knowledge

Understanding the importance of access and inclusion, viewing things from different perspectives, and challenging my decisions has helped me become a better developer.

Knowing how things should be done is great, but it’s just the first step. Truly caring, implementing, and most importantly sharing your knowledge is what makes an impact.

Share your knowledge

Go to conferences and meetups

Organize meetups

Invite experts to your meetup or conference

Follow accessibility experts on Twitter

11. Simply get started

You don’t have to go all-in from the very beginning. If you improve just one thing, you’re already doing a great job in bringing us closer to a better web. Just get started and keep working.

Video series

This free Udacity course is a great way to get started.

Rob Dodson covers many different accessibility topics in his video series A11ycasts (a11y is short for accessibility—the number eleven stands for the number of letters omitted).

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

“A Developer’s Guide to Better Accessibility” (article)

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

“Building a Culture of Accessibility: Leadership Roles” (article)

“The Web Should Just Work for Everyone” (article)

“A Very Good Time to Understand CSS Layout” (article)

“JavaScript Is Not an Enemy of Accessibility!” (article)

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

#My Accessibility Journey: What I’ve Learned So Far

0 notes

robertrluc85 · 7 years ago

Text

Mobile-first updates from SMX East

As every SEO knows, the rise of mobile searches has prompted Google to prioritize mobile signals in determining search results. To that end, the search giant is in the slow-going process of rolling out its mobile-first index, which is expected to be fully implemented sometime next year.

In the meantime, getting sites ready is a high-priority item on SEOs’ to-do lists, which is why the topic was addressed at this week’s SMX East conference in a panel discussion titled, “SEO For Google’s Mobile-First Index & Mobile-Friendly World.” The speakers included Leslie To, director of SEO for 3Q Digital; Ashley Berman Hale, director of SEO at Local SEO Guide; and Gary Illyes, webmaster trends analyst for Google.

Today’s post will cover the key points presented in this panel.

Leslie To: Is it the year of mobile yet?

Leslie To breaks down the process of preparing for the mobile-first index into two major categories:

Configuration-agnostic auditing

Configuration-based auditing

Configuration-based auditing would involve those things you need to do that are specific to your mobile configuration (whether that’s a mobile subdomain, dynamic serving or responsive web design).

Configuration-agnostic auditing, on the other hand, involves items you need to address regardless of your mobile configuration, and this is what To covered first.

Configuration-agnostic auditing

Let’s start with a summary look at what matters regardless of mobile configuration:

Tips:

Use HTML for rich media and video content, and use the video element to download and decode the content.

Avoid interstitials. If you want to promote your app or email list, use banners rather than full-screen overlays or interstitials. Users don’t like them, and neither does Google.

Consistently test your global navigation and mine internal search data to refine that navigation (based on what you see users aren’t finding). Further, remember that mega menus don’t always work well on mobile. Simply put, don’t overwhelm users with menu options when you have limited screen real estate.

Do allow content and media to scale to fill device screen size, as that provides a good user experience. To help with this, stay away from absolute declarations in your CSS.

Do allow all font sizes to scale, and use 16px as your base font size. Don’t require users to zoom to read, interact with or consume content. No one likes to do that.

Make your tap targets at least 48 pixels wide to make them easy to hit. In addition, space your tap targets 32 pixels (or more) apart. Don’t require users to zoom to tap buttons, links or form fields.

Allow common gesture features on your e-commerce site, especially pinch/double-tap to zoom. Don’t use low-resolution images that become pixelated when you zoom.

Configure internal site search to make content easier to find, and actively harvest site search queries to learn more about what users are looking for on your site so that you can make navigation, layout and content improvements over time.

Enable contextual keyboards that change based on required input types. Using one standard keyboard layout for all input can be difficult for users to deal with. Don’t assume the limitations of physical keywords. For example, if you’re looking for someone to enter a domain name or email address, have a “key” that they can tap to enter “.com” — these types of contextual features will save them time.

Make it easy for users to convert, whether it’s via a form fill, a phone call or your shopping cart. Enable click-to-call by wrapping phone numbers with telephone schema. Don’t require more than three clicks to complete a conversion.

Implement all the basics of page speed. This means things like enabling gzip compression, leveraging browser caching and getting server response time under 2oo milliseconds.

Don’t use render-blocking JavaScript, especially for external scripts. Don’t use inline CSS attributes and/or a large CSS file.

Don’t make the language on your site too complex. Readability is a big concern (and not just for mobile sites). To give you some perspective, here is a look at how well US adults read:

Leverage readability indexes, such as:

Flesch reading ease

Flesch-Kincaid grade level

Gunning Fog index

SMOG Readability formula

You can get readability measurements for your content within Microsoft Word. There are two paths to navigate to it, shown below:

Configuration-dependent auditing: Mobile subdomains

If you’re using a mobile subdomain, you will need to implement bidirectional linking, with a rel=alternate tag on your desktop pointing to your mobile site, and a rel=canonical tag pointing from your mobile site back to your desktop site. These are sometimes called switchboard tags.

A common question that many people ask is whether or not Google will want publishers to reverse the direction of those tags with the advent of the mobile-first index. To date, Google’s answer to that has been no, that this is not necessary. They will simply assume the reverse. From Google’s perspective, if they tried to get everyone to switch them, a certain amount of chaos would be likely to result.

Do minimize cross-linking, so that your default links in the mobile experience should be to other pages in the mobile experience. But you should also provide the alternative desktop experience for users who want it. One benefit is that you can monitor clicks and, if there are lots of them, it may indicate problems in your mobile experience that you need to debug.

Do say no to blanket redirects, and try to make them all one-to-one. If you have no corresponding mobile content, leave users on the desktop page.

Configuration dependent auditing: Dynamic serving

For those using dynamic serving, you will need to implement the Vary HTTP header. This will help prevent problems with users being served the wrong versions of your pages due to ISP-caching. Without this header, ISP caching may cause mobile users to get your desktop page, and vice versa.

Watch out for, and avoid, unintended content differentiation between desktop and mobile because both sites are maintained differently.

Configuration dependent auditing: Responsive

With responsive sites, make sure you’re not blocking CSS or JavaScript files from being crawled. Check for the Meta viewport tag, as it gives directions on dimensions and scaling:

Width-device-width: matches content to the physical width of the device.

Initial-scale: initial zoom when visiting a page.

User-scale: allows for zooming (values are “yes” and “no”).

Use a comma to separate attributes so that older browsers can parse different attributes.

Do make sure that images and videos are also responsive, but don’t allow video to scale beyond the viewport size.

Last but not least, don’t base breakpoints on specific devices. Leverage Google Analytics’ Device Report to determine whether your breakpoints are properly serving your customers most of the time.

View Leslie To’s full presentation here:

Ashley Berman Hale: Mobile Friendly IRL, Beyond Best Practices

Ashley’s focus is on how you deal with the problem if you can’t get the budget or approval to proceed with making a site mobile-friendly.

When trying to get buy-in from stakeholders, Berman Hale suggests leaning on Google documentation and sharing relevant case studies. She also suggests showing desktop vs. mobile traffic over time — even in industries that are slow in moving to mobile, your analytics data is highly likely to show a strong trend in favor of mobile over time. Related to this is the idea of looking at competitor sites in SEMrush and showing their mobile traffic over time.

For some businesses, the issue may be that they only have a small budget. If that’s your situation, consider starting small. For example, you can break down your mobile friendliness action items into more manageable parts, including:

by site section.

by product.

by customer.

by element.

Another practical tip is to focus on getting people on board one at a time. These kinds of approaches can help you build momentum in a positive way.

In other cases, the challenge might be that the code is a hot mess, and everyone is afraid to touch anything. The incremental approach can work well here, too. For example, you can:

compress your images.

figure out how to strip some CSS.

implement AMP on just a few elements.

Or perhaps your role is such that you only have control over the content on the site, and not the coding side of things. You can still make a difference. You can accomplish this by thoroughly understanding the intent of people who are reading your content on mobile and making it easy for them to find what they want.

This starts with upfront research, including your keyword research. Use this to help you understand the likely user intents, and then form your content around those concepts. Structure your content to make it easy to find, and create snackable, modular elements. In addition, modify your metadata and markup to communicate what users will get by engaging with your content.

You may have people in your business who care only about brick-and-mortar sales. But local search is typically a huge driver for that, and local search often is mobile search.

The key to unraveling this is learning how to track the progression from local searches to your site and business. Setting this up can help you get what you need to show people that local (and mobile) is critical to your business.

Or, if you’re in the right business, you may be able to call in legal. Your industry may have accessibility requirements, and a solid mobile experience may simply be something that you’re required to do.

Lastly, you should always pick your battles and “choose what hill to die on.” Make sure you are making steady progress over time; the path to maximum mobile-friendliness is definitely a marathon, and not a sprint.

View Ashley Berman Hale’s full presentation here:

Gary Illyes: Google’s perspective

Illyes explains that, traditionally, the Google index is based on crawls of desktop content. However, the problem Google has had is that on many sites, the desktop site would have more content on its pages than the corresponding mobile pages. This was leading to problems in search because Google would return pages to mobile users based on the content they found on the desktop pages, but the users would then get served the mobile page and the content wasn’t there.

This created frustration with the quality of Google’s results, and this ended up driving the idea of switching to a mobile-first index. What this means is that Google will crawl mobile sites and base their search index off of the content they find from that crawl.

Illyes’ message on this is: “Don’t freak out.” Google is approaching this very carefully, and they don’t yet know when a full mobile-first index will go into effect. They started experimenting with it two years ago, and it did not go well at all.

Currently, they have moved a small number of sites into a mobile-first index, and they have been monitoring those to make sure they’re not being hurt in terms of traffic and ranking as a result.

Eric’s note: Google has to be very careful about these types of changes. While they may be desirable at some level, searchers often have pretty specific things they want and need, including specific brands, and if they’ve been artificially demoted, this will also result in user frustration. This is the same reason that things like HTTPS and page speed are such weak ranking factors.

Illyes next notes that if your site is responsive, you’re good to go! But many of the sites that have other mobile configurations are not good to go.

Common issues with mobile sites are:

Some of the content and links from the desktop site may not be present.

Rel=annotations may not be there (e.g., hreflang).

Structured data may be missing.

Some of the media and images may be missing.

Illyes then shared the example of one site that did not move over their hreflang tags, and they lost 50 percent of their traffic. This is exactly the type of thing that Google wants to avoid.

Here are the things you should do to prepare for the mobile-first index:

If your site is responsive, you’re already ready to go.

Make sure your mobile pages have all the same videos and images as your matching desktop pages.

Make sure your mobile site has all the content and all the links that show up on the matching desktop pages.

Make sure to implement hreflang tags on the mobile pages.

Make sure to carry over the structured data from your desktop pages.

Last, but not least, don’t panic!

Some opinions expressed in this article may be those of a guest author and not necessarily Search Engine Land. Staff authors are listed here.

About The Author

Go to Source Author: Eric Enge

For more SEO, PPC & online marketing news visit https://news.scott.services

The post Mobile-first updates from SMX East appeared first on Scott.Services Online Marketing News.

from NewsScottServices via News Scott Services on Inoreader https://news.scott.services/mobile-first-updates-from-smx-east/ from News Scott Services SEO News https://newsscottservices.tumblr.com/post/166903510363

0 notes

topicprinter · 7 years ago

Link

Hi r/startups! This is a 3,000 word blog post I wrote on early stage marketing. I've formatted it for Reddit below, but there's a much better reading experience (with images) available on Medium.Since I began working on my startup I’ve read a lot of articles and books about creating something from nothing. They usually have excellent advice, but are light on the details of how you actually go about creating a product startup. The focus is often on challenges that are quite far down the startup journey, covering exciting sounding topics like ‘scaling’, ‘hiring’, and ‘building culture.’But the reality is that these things will feel like distant problems in the first 12–18 months. As a founder, you will have different challenges to deal with right now like I did: researching your idea, building an MVP with outsourced contractors, finding a technical co-founder, getting initial traffic to your website, settling on a pricing model, evaluating customer feedback, and making hard decisions about when to pivot. This is the third post in a series of five. Read the first two: Discovering and vetting your startup idea and Outsourcing your startup’s MVP.You’ve discovered an idea and built a Minimum Viable Product. Now you need to launch it, get it in front of your target audience, have them sign up, and give you feedback so you can throw away a bunch of code and no doubt ‘pivot…!’ This was the stage I was at with Dovetail in September 2016. I’ll go through the strategies I used to drive traffic to our website and how I measured what was effective.First things first: choosing a nameWhen choosing a name, use an existing, pronounceable word — even if the obvious domain names are taken — instead of making up a new word because its .com is available. Resist the temptation to create something that sounds like it’s straight out of Rick & Morty. The name you choose is very important because that (plus a logo and some colour) forms your entire brand early on. In general, you your name to to be short, unique, and something that’s not easily mispronounced. Naming things is hard.People love the name Dovetail but they’re concerned “it’s taken already.” There are plenty of other companies, agencies, and organisations called Dovetail. As long as these companies are not in the same industry as you, you needn’t worry too much. Dovetail happens to be a woodworking joint, a non-profit mental health organisation in Queensland, and a co-working space management app. The only practical problem you’ll face is that you have to compete with these in search rankings. However, the world is a big place, and people usually know to simply add ‘research’ to the end of their query if they can’t find us when searching ‘Dovetail’ on its own. Obviously don’t pick a name that is a copy, or close to a copy, of a competitor in the same space as you. You might find a copyright infringement notice in your letterbox earlier than you expected.You should be looking at available domains while brainstorming a name. Prepare for disappointment and compromise. Unfortunately for us, dovetail.com and dovetail.io were already taken. I initially compromised on getdovetail.io, before recently moving us to dovetailapp.com which is slightly better. Novelty domain names like del.icio.us were cool a few years ago but it turns out people tend to forget where the dots go. As a former designer on Delicious, I can attest to the trouble that domain caused, hence why the company began to use delicious.com instead.The takeaway here is that naming is hard.Let’s ship a thing to the internet!For the initial launch I built a responsive splash page in HTML & CSS and deployed that. I also asked a freelance illustrator if she could create some illustrations for the website. Custom illustrations might seem like an odd thing to spend money on at this stage, but first impressions are crucial. Even if you’re just making a splash page, it has to look fantastic, because everything potential customers see is a representation of your brand. Brand-building starts from day one.The website reiterated our value proposition (Improve your product with simple, contextual research) and included a summary of the features:Run market or customer research via SMS or emailGet in-the-moment responses from participantsAnalyse your data and centralise all insightsShare what you learned with your team and stakeholdersThere was a form to ‘request an invite’ which took a name, company, and email address. To same time I used a hack: the form response was submitted to a hidden, embedded Google Form connected to a spreadsheet.I set up a custom domain for our Medium blog, wrote this introduction post, and shared it on Twitter, Facebook, and LinkedIn. There wasn’t a lot interest, but after a few days, I got a flurry of sign ups from high quality companies. It turns out Dovetail was mentioned in an email newsletter for researchers. I emailed everyone who signed up, thanked them, and asked them a simple question:What do you hope to use Dovetail for?This question gave me more knowledge about them, their company, and their use case. It also tested whether they understood the product based on the marketing lingo I used on the splash page.At the same time I was preparing the product for its first users. The app had an admin interface which allowed me to send invites. I started sending invites in batches in October. I was very stressed. I had low confidence in the stability of the product, in part because I didn’t understand the code well, and I knew the outsourced developers I used were not going to win any prizes for code quality. In the end it took me three months before the anxiety subsided and I felt comfortable with the stability of the app.Letting people sign up themselvesUntil late December, the only way to sign up was to request an invite. We’re not a consumer app and there’s no need to ‘reserve your username’ so the reason for this approach was not to stir up excitement and demand. Instead, the reasons are boring:The product didn’t have a self-serve sign up flow with email confirmation, password reset, and so on. I don’t think we even had the ability to send transactional emails to new users.These first people were high quality leads. They hadn’t come from AdWords; instead they were word-of-mouth. I wanted to personally onboard them to make a great first impression. Even if the product was an MVP, our customer support was not.The code was unproven beyond my own testing with friends. I needed to send out a batch of invites, watch the logs, fix bugs, and repeat before I felt confident to allow anyone to sign up without my hand-holding.If you sign up for Dovetail now, you’ll notice that you can’t proceed without confirming your email address. Whether you have email confirmation in your onboarding flow is a subject of much debate. You can make your own decision, but I’ll offer some of the reasons why we have it in Dovetail:Like Atlassian’s sign up flow (which I talked about in my first post), having some friction on the marketing site helps to weed out low quality leads who would never purchase anyway.Dovetail allows users to send SMS messages and emails in bulk. Verifying email on sign up helps prevent people using our service to spam others.Email verification is a standard pattern for SaaS products now, so the funnel drop-off is negligible. After removing fake email addresses, our email confirmation step only accounts for a ~2% drop-off.At first, users saw a sample data set that showed a ‘finished’ study in Dovetail. After looking through the analytics and talking with customers, I found that almost everyone created another study called ‘test study’ and added themselves as a participant. Of course! Researchers wanted to see what the experience was like for participants on the other side. I modified the sample data to be an active study called ‘Sample study’, with the researcher entered as a participant. The study emailed them questions that said “This is what a question looks like for participants.” I productised what users were already doing, and retention improved.Another behaviour I noticed is people preferring to change the sample study rather than creating a new one. Even if there is little real friction in actually doing so, the perceived friction in creating a ‘new thing’ is quite high.The takeaway here is to ship a first version of your onboarding and observe user behaviour to make continual improvements. You won’t get it right the first time. Our onboarding experience still has problems, and we’ll get around to working on it later this year.Marketing channelsQuora, StackExchange, and RedditA lot of our quality traffic has come from Quora. My strategy was to search for a problem that our product solved (e.g. “what tools exist for diary studies”), find the Quora question, and post an answer. I linked to our product and included a disclaimer that I was the founder. This strategy has worked very well. Quora questions are high on Google search ranking. Our potential customers have Googled a problem, clicked on the Quora link, seen my answer, and visited our site.To a lesser degree, posting in Research, Design, and UX StackExchange sites and subreddits has sent a few page views our way, but I don’t go out of my way to submit to these sites since that’s not really where our audience is.Content marketingIntercom, Invision, and Hubspot have demonstrated that content marketing can be an effective way to drive traffic to your product. It’s free if you write the content yourself, lasts forever, and helps to boost your search ranking. Good content marketing can establish your brand as a reputable source of knowledge.My first attempt involved writing a few blog posts about diary studies on Medium. Our Medium blog used to be on a subdomain (blog.getdovetail.io), and I read somewhere that it’s better for SEO to have posts on your main domain instead. I copied the research posts from Medium over to a new section on our website called ‘Guides’, and wrote a couple more. Our blog is now focused on product news and non-research posts like this, while research content lives on our main site.I wasn’t sure how the guides I wrote would perform, but they seem to be doing well. After a few weeks they appeared in the top 5 results for searches like ‘diary studies’, ‘qualitative vs quantitative data’ and ‘participant recruitment.’ Bounce rates and session duration look good, and sign ups increased as a result of traffic to the guides.SEOI configured Google Search Console early on to measure our search ranking. I don’t know much about SEO, but I do believe a lot of the time it simply comes down to relevant, quality content. Google even have a section in their help documentation that says the same thing:“Provide high-quality content on your pages, especially your homepage. This is the single most important thing to do. If your pages contain useful information, their content will attract many visitors and entice webmasters to link to your site.”Other factors to consider are site performance and mobile experience.I highly recommend making quick-win performance improvements like loading JS asynchronously, minifying assets, and using sprites or inline SVGs for images. PageSpeed Insights is great for seeing what Google’s verdict is on your performance. It’s a checklist of things to do, so just make sure you do all of them (some may be harder than others) and it’ll help your search ranking, especially on mobile.Speaking about mobile, both our website and product are responsive because quite frankly, there’s no excuse for websites not to have mobile support in 2017. At the very least your marketing website needs to be responsive, then you’ll either have a responsive product, a mobile site, or native apps for your app. There are pros & cons for each, but that’s the subject for another blog post!Paid advertising with Facebook and AdWordsI have some experience with Facebook Ads and Google AdWords from a few years ago, but mostly I don’t know what I’m doing.Earlier this year I set up ad campaigns on both platforms with identical budgets. Our hypothesis was that Google would out-perform Facebook because people search for solutions to problems on Google, and we were building a solution to a problem! We’re very lucky that researchers (like developers, designers, and other ‘tech’ people) actively look to improve the way they work. A lot of people don’t do this, and are quite happy to put up with whatever they currently use for all eternity. I’m sure you have some friends or family that fit this description.If, like me, you don’t know what you’re doing when creating online ads for your startup, there are a few terms you should understand:Impressions. This is the number of people who have seen your ad.Click-through rate. This is the percentage of people who, after seeing your ad, click on it and visit your website. It’s usually quite low; around 1 to 2%.Sign up rate. This is the percentage of people who sign up on your website. It’s usually around 5%, and if it’s higher than this, you’re doing quite well.Conversion rate. Assuming you have a free plan or trial period, this is the percentage of people who actually hand over some money, or ‘convert’ into a paying customer. This number varies wildly between companies and products.Acquisition cost. This is how much you spent to acquire a single paying customer.Average lifetime value. This is how much money you expect to get, in total, from each customer. Your lifetime value should be greater than your acquisition cost otherwise you’re losing money when trying to acquire customers. (This may be okay if you’re building a social network or a ride-hailing service where the race to a critical mass of users is important. We’re not.)With these five key metrics, we can map out a typical scenario.With AdWords and Facebook, you can pay per impression, click, or conversion. There are pros and cons to each which I won’t go into here. Let’s say you choose to pay per impression. You get 10,000 impressions on your search ad, and a 2% click-through rate. Google or Facebook have charged you $300. Along with understanding why these companies are so wealthy, you now know that 200 people have visited your website from the ad. On your website, your sign up rate is 5%. So 10 of those people sign up for an account. Out of those 10 people, 2 of them decide to convert, making your conversion rate 20%. So you have spent $300 to acquire two paying customers. $150 per customer. Now, let’s say you charge them $50 per month. Each customer has to stick around for 3 months for you to break even. Any more than that and you’ll turn a profit, however of course this is not factoring in any company expenses.You then realise how great content marketing is.Product Hunt and other aggregator sitesFrom day one people would sign up, take screenshots, and list Dovetail on aggregator sites like nicelydone.club, sansfrancis.co, and hypershoot.com. Mostly the creators of these sites. We got a few sign ups from these sites, but mostly these they’ve been of little value.I had high expectations for Product Hunt but was disappointed. The audience is mostly designers, developers, and other startup founders who are looking for trendy software to use themselves or as inspiration.If you’re not building a chatbot, Slack add-on, or a design prototyping tool, then don’t bother with Product Hunt. B2B products in a specific market don’t do well there. Product Hunt is a waste of your time if you are not building for this audience. Instead, find out where your audience hangs out and go there. In our case, that’s Quora, Twitter, Medium, and email newsletters.Internal referrals through team invitesLastly, another strategy we employ is in-product invitations. We needed to build ‘teams’ anyway in order to become a collaborative product. A nice side effect is user growth from researchers inviting the rest of their team. One person at a company might refer 5 or 6 of their colleagues.Because our pricing model is not based on the number of collaborators you have (more on that in a later blog post), there is hardly any friction when inviting teammates.However, in saying that, the product today doesn’t do enough to incentivise users to invite their colleagues at opportune moments. The feature is kind of tucked away in team settings. So there’s work to do there.Measuring marketing successAs an early stage startup, you will spend a lot of time experimenting with different marketing strategies until you find reliable ‘marketing channels’ that deliver high quality users at an acquisition cost less than their lifetime value. Marketing channels differ between industries and products. Beauty and clothing startups might have a lot of success on Instagram, but your highly technical data warehouse solution probably doesn’t lend itself to hipster, filtered photos.When you experiment, you need to measure. Measuring different marketing strategies is the only way to find channels that work for you. With Dovetail, I made sure our analytics story was solid from the beginning. We use Mixpanel primarily for in-product behavioural analytics, and Google Analytics for page view and demographic data. I also learned that it’s a great idea to also install a Facebook Pixel on your site even if you’re not planning on marketing via Facebook yet. It can start building a custom audience of website visitors which is great for remarketing later on.With Mixpanel specifically, you will most likely need to do some work to connect the JavaScript library with your backend so you can link anonymous users browsing the website to the actual user ID in the database when they sign up. This means you can track someone’s journey from the website all the way into the product. Mixpanel then has some neat features that help you figure out the ‘aha!’ moments that cause people to convert.Don’t leave analytics instrumentation too late. Add it as part of your regular development so you can start collecting data and learning from it straight away. With Google Analytics connected to AdWords, you can see what ads are generating paying customers. Likewise with Facebook. Optimise for conversion rather than clicks or impressions since that’s closer to revenue.In summaryChoose a pronounceable name. Make your website fast and mobile-friendly. Iterate on your sign up flow. Add analytics from day one. Go where your audience is. Forget about Product Hunt. Experiment with marketing channels. Measure what works and double down on that.Original post on Medium

#/r/startups #reddit

0 notes