DEV Community: Jess Budd

The Year I Became a Conference Speaker (Conclusion)

Jess Budd — Wed, 26 Feb 2020 00:00:00 +0000

I recently wrote about howI came to be giving 3 conference talks in 3 weeks in 3 different states, and how the first of those talks went. This post is about the second and third talk and what I've learned through these experiences.

My Australian Speaking Tour (cont...)

Google DevFest, Melbourne

Second stop: Melbourne for Google DevFest. Although also a positive experience, it was quite different from my first talk at LaraconAU.

First of all, DevFest was a multi-track conference, so the 300+ audience was split over 3 rooms. This meant the audience for my talk was only around 50 people (more meetup sized). Whereas Laracon was a single-track conference, meaning the entire audience was in one place for each talk.

Second, the layout was the polar opposite. The room I spoke in at DevFest was bright with natural light and set up casually, with rows of couches at the front and some bar seating at the back. There was a small bar table for my laptop instead of a podium, and a projector on each side of me.

Relaxed Google DevFest set-up for my talk with couches, cushions and natural light.

In contrast, my Laracon talk was on a theatre stage with the ambient lights turned off and a spotlight on me. I wasn't able to see the audience properly to gauge responses or feedback.

My DevFest talk was also non-technical, whereas my Laracon talk was the opposite. On one hand, you would think it would be easier because no one can dispute your points when you're discussing and drawing on your personal life experience. But on the other hand, it made me really nervous in the time leading up - I kept thinking "why would anyone want to listen to me talk about myself?!"

There was a small hiccup in the beginning, in that I forgot to turn my mic on. Members of the audience let me know during my introduction. Something like this could easily have thrown me off balance (like my slide notes did at Laracon), but it didn't thankfully.

The audience was really friendly, laughing and reacting in all the right places, nodding along and giving me positive feedback throughout. This really helped, and I found my voice to be more even and I could slow down more than previously.

Giving my talk Live Life in Perpetual Beta at Google Dev Fest Melbourne.

I felt less drained after this talk then my previous talk, I think because it felt more like I had been chatting with a group of new friends than performing under a spotlight.

If you're interested, you can watch the video and check out my slides.

DDD, Adelaide

Last stop: Adelaide for their inaugural DDD.

DDD is a not-for-profit community conference run on a weekend for low cost and I was really happy to be involved in their very first one. Mostly for the bragging rights of course 😄

There were no audio or visual mishaps this time, I'm happy to report!

The room was very wide though, with 3 separate sections, so I struggled to maintain an even spread of eye contact. Particularly as I still needed to refer to my slide notes (which I really need to work on!).

Other than that though, the audience was friendly and I was happy with my talk's pace and speed. I finished about 5 minutes early so there was time for questions from the audience.

I've previously not wanted to take questions after a talk for a few reasons:

I'm a bit hard of hearing, and concerned I could have trouble hearing the questions;
I'm anxious about getting one of those attendees that just want to correct or one-up the speaker;
Worried that I would not know an answer and be proven an imposter!

But I was riding the waves of a smooth talk high, so I accepted questions - and it wasn't a disaster. Some of the questions were really good and think the audience would have benefited from the extra information. I would be happy to take questions again in a similar size and type of audience.

Presenting on Making React Applications Accessible at the inaugural DDDAdelaide

After my talk, I received a lot of positive feedback in person, on twitter and from speakers I admire.

Unfortunately, I did receive negative feedback from one person (some constructive, some less so). To be honest, it really sucked knowing that someone didn't enjoy my talk. But I also know it had to happen at some point. And recognise that uncomfortable experiences like receiving criticism can be excellent opportunities for personal growth.

So with my 3 talks, in 3 weeks, in 3 states all wrapped up, it was time to return home to Perth for some well deserved R&R!

Jess Budd

@jessbudd4

Thanks for having us Adelaide! Its been a blast! twitter.com/MingJohanson/s…

00:30 AM - 24 Nov 2019

Ming Johanson @MingJohanson
Wrapping up an amazing trip with @jessbudd4 @Amys_Kapers https://t.co/RRKM2Fcucd

0 10

What have I learned?

Getting negative feedback feels pretty rough. I knew logically it would be difficult to receive feedback that wasn't positive, but I think I underestimated how difficult it would be to not take it personally. @lara_hogan has some excellent advice on how to sort through feedback in her A List Apart book Demystifying Public Speaking. Her method of deciding what feedback to take on board and what to ignore was really helpful. (And big thanks to the @stringy for working through that exercise with me!)
Writing technical talks is a different process to writing non-technical talks. Most speakers will have a preference for one or the other, but personally I found writing and presenting a non-technical talk to be more difficult. With a technical talk, you can fact-check and be fairly confident what you're saying is correct - you're imparting objective knowledge. But with a non-technical talk, you're sharing your personal experiences and opinions. This had me doubting the value I could bring to the audience.
Double check your microphone is on. You'll often be mic'd up well in advance of starting your talk, so if there isn't a professional AV crew running all the sound, ensure you've done everything you need to. (And even if you think people can hear you fine, it's best practice to use a microphone for anyone in the room that might be hard of hearing).

What next?

I took a few months to reflect on how I felt about presenting again in the future. Now, I'm excited to announce I'll be adding "international" to my speaker bio!

Codemania in New Zealand have an amazing lineup of extremely talented people speaking at their conference in May 2020 and I'm excited to be speaking alongside them.

I hope you've enjoyed reading about my speaking journey, and if you hit me up on twitter I'd love to hear about yours!

Hiding Content Accessibly

Jess Budd — Sun, 17 Nov 2019 03:02:09 +0000

This post was originally published on jessbudd.com.

There are often situations where we need to hide content on a page, either temporarily or permanently. The method you use for hiding content can have a big impact on accessibility, so this post will discuss when to use particular techniques.

There are generally 3 scenarios where we want to hide content:

We want to hide content for everyone (including people using screen readers).
We want to hide content visually (but not from screen readers).
We want to hide content from screen readers (but not visually).

Hiding content for everyone

Common situations where you want to hide content from everyone, including sighted keyboard users and people using screen readers, are closed navigation menus, tooltip text and collapsed accordions.

The CSS styles below will prevent the element displaying visually on the page, will be ignored by screen readers, and will prevent keyboard users tabbing to the content.


.hide-for-all { display: none; }


.hide-for-all { visibility: hidden; }

The difference between display: none; and visibility: hidden; is that hidden elements are not removed from the document flow, so will retain its physical space on the page.

A common mistake when hiding content is to use opacity: 0; when the intention is to hide the content from everyone. Although this styling removes the content visually, it is still announced by screen readers and potentially focusable by the keyboard.

Hiding content visually

There are two main situations when you want to hide content visually:

When you never want the content to be visible on the page.
When you want the content to become visible when focused by the keyboard.

Never visible

There are times when the visual information in a design is not sufficient for screen readers users. A common example of this is form inputs that aren't given visual labels.

Labels are crucial for screen reader users to understand and successfully complete forms. So in a situation like this you could visually hide the label with CSS.

The most commonly accepted practice for modern browser support is using clip-rect.


.sr-only {
    position: absolute;
    height: 1px;
    width: 1px;
    clip: rect(1px, 1px, 1px, 1px);
    clip-path: inset(50%);
    margin: -1px;
    overflow: hidden;
    padding: 0;
    border: 0;
    white-space: nowrap;
}

Elements with this class will not be visible on the page or take up space in the visual flow, but will announce the contents to assistive technologies.

Visible when focused

Sometimes we want to hide an element only until it receives keyboard focus.

A perfect example of this are skip-links. A skip-link is styled with CSS to remain out of view until a user tabs to the element and is then sent back off-screen when it leaves keyboard focus. This behaviour benefits sighted keyboard users, without changing the visual design for mouse users.

We use a combination of CSS properties to position the content offscreen and the focus pseudo element to bring the position onto the page as the element by the keyboard.


/* positioned offsceen so not visible */
.skip-link a {
    position: absolute;
    left: -10000px;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
}


/* appears back on screen when focused with keyboard */
.skip-link a:focus { 
    position: static; 
    width: auto; 
    height: auto;
}

Combined approach

An alternative approach is to combine these two methods and use the
:not(:focus) and :not(:active) pseudo elements within the sr-only
class. This will remove the offscreen styling when an element is focused or active.


.sr-only:not(:focus):not(:active) {
    position: absolute;
    height: 1px;
    width: 1px;
    clip: rect(1px, 1px, 1px, 1px);
    clip-path: inset(50%);
    margin: -1px;
    overflow: hidden;
    padding: 0;
    border: 0;
    white-space: nowrap;
}

Hiding content from screen readers

It's uncommon to need content to be hidden from screen readers only, however this can be appropriate when visual content is decorative or duplicative. An example would be SVG or font icons that are accompanied by text labels.

We can hide the icons from assistive technology using aria-hidden="true". This effectively has the opposite behaviour of our sr-only class, in that it remains visually on the page while being ignored by assistive technologies.


<button>
    <span class="icon-close-menu" aria-hidden="true"></span> 
    <span class="sr-only">Close navigation menu</span>
</button>

The Year I Became a Conference Speaker (Part Two)

Jess Budd — Sun, 17 Nov 2019 01:12:46 +0000

This post was originally published on jessbudd.com.

I recently wrote about how I came to be giving 3 conference talks, in 3 weeks, in 3 different states. This is the story of my first talk.

At least it looks like I'm not freaking out

The Monday before I set off, I had a skype interview with one of the DDDAdelaide sponsors. We chatted about my upcoming speaking engagements, among other things, but something I particularly enjoyed was his reference to my "speaking tour of Australia" - which is a phrase I will now steal, thanks @encodetalent 😂

My Australian Speaking Tour

Laracon, Sydney

First stop, Sydney for LaraconAU. This was a fantastic event, and despite not being a PHP or Laravel developer, I had an overwhelmingly positive experience.

My talk was scheduled for early afternoon on the first day.

Speaker friends warned me I would be too nervous to eat lunch, so the lovely @Amys_Kapers (who was speaking an hour after me) made us both a wholesome, nutritious breakfast to keep us going until after our talks.

As it turns out, nerves don't affect my appetite 😄 so I ended up having a salad and gelato for lunch anyway, but it's always good to be prepared!

In the break before my speaking slot, the venue's AV person got me all set up with my microphone and battery pack. I was endlessly amused by the fact it was a Britney* mic, instead of a boring lapel mic.

*These are not really called Britney mics, but that is what they will forever be to me.

Me, childishly excited by my rockstar mic

People were often asking me in the lead up to this moment if I was nervous - and honestly, I wasn't anywhere near as nervous as I was expecting to be. Maybe it was because I kept telling myself nerves are just excitement, or I was keeping myself distracted, but I felt pretty good.

As I waited backstage to be introduced, I did some power posing and slow controlled breathing. I have no idea if these things really help, but figured it couldn't hurt.

And then I was called up.

Pretty quickly all those nerves I had kept at bay rose to the surface.

But I knew I had practiced and was prepared - so I told myself "I got this" and started strong, despite my voice wavering a little.

On stage before my talk, setting up my laptop

Unfortunately, a couple minutes into my talk I realised....I didn't have my speaker notes.

Instead of using the projector as a separate display, it was mirroring my laptop - which instead of showing my speaker notes, was showing my slides.

I had to stop my presentation, change the display settings, apologise and explain to the audience what was happening, and restart again with my notes.

This (in hindsight, minor) hiccup completely threw me off balance.

My voice was now wavering intensely. My mouth felt like sandpaper. I just couldn't regain my original confidence.

When my talk was finished and I walked off stage, I did not feel good about my performance. (In fact, I think my exact words to the MC when he asked me how I felt about it, were "I'll just go out the back and puke now").

If you'd asked me at that moment if I was happy with how it, the answer would not have been yes.

But later that day, many attendees came up and congratulated me on a great talk and wanted to chat about my topic. And I started seeing tweets like this one:

Andrew Feeney

@andrewfeeney

@jessbudd4 Absolutely killed it. That’s you you deliver a tech conference talk! Scribbled notes like a maniac.

04:07 AM - 31 Oct 2019

1 3

And this:

Zayn Buksh

@zaynbuksh

@jessbudd4 gave the what might be the most socially important talk of #LaraconAU. Information learned here will help me assist with student accessibility at @Sydney_Uni. Great job on your first talk Jess 🙏🏽👍🏽 @LaraconAU

04:16 AM - 31 Oct 2019

3 11

And this:

Tim MacDonald

@timacdonald87

@the_patima @michaeldyrynda @jessbudd4 @LaraconAU Easily one of my favourite talks from the day

06:21 AM - 31 Oct 2019

0 2

This positive feedback, combined with a few days distance, have me feeling pretty darn okay about my first conference talk now.

Thank you to everyone that came up and said nice things to me after my talk and everyone who posted on twitter. It really meant a lot to me ❤️

Shout out to the amazing job @michaeldyrynda and his team did on this conference and making the first time speakers feel welcome and valued.

Special thanks to the @fendersperth crew for cheering me on either in person, on twitter or in slack.

If you're interested, you can find my slides and other tweets I received here.

What have I learned?

Always check your speaker notes before you start talking 😆 It won't hurt to take an extra minute to double check everything before you start, but it will damage your confidence if you're forced to stop part way through to fix your setup!
Positive feedback means a lot to speakers. Getting up on stage in front of a crowd makes you feel pretty vulnerable. Receiving positive comments after helps make the world feel right again. If you enjoyed someone's talk, tell them or tweet them!
Other people won't notice how nervous you are. Despite hearing my own voice wavering, having to take constant drinks due to dry mouth and somewhat shaking hands, other people don't really notice. Don't make yourself more nervous thinking about how nervous you're coming across!
Giving a conference talk is a lot of work. Writing your presentation, creating your slides and practicing your delivery is significantly more time intensive than I expected. I would easily have spent 40 hours on this talk. I'm sure it will be a faster process in the future, but it's certainly not something you whip up in an afternoon.

What next?

Right now I'm prepping for and focusing on my next talk at Google Dev Fest in Melbourne this weekend.

Soon after I'll be off to Adelaide for the last leg of my speaking tour and the very first DDDAdelaide. (There's still a few tickets left!)

I'll let you know how those both go in the third and final installment!

The Year I Became a Conference Speaker (Part One)

Jess Budd — Wed, 23 Oct 2019 14:02:58 +0000

This post was originally published on jessbudd.com.

Three and a half months ago, I decided to give some public speaking a go. Today, I have 3 conference talks lined up. How did this happen??

You could say it actually all started nearly 2 years ago, when I was fortunate enough to be gifted a free ticket to attend CSSConfAU. I managed to use frequent flyer points (accumulated from years of grocery shopping to pay for flights, and split the cost of an Airbnb with two friends also attending from Perth.

At the airport, waiting for our flights home, I was gushing what an amazing experience the conference had been. And in quick succession, lamenting how I wished I could afford to attend more.

My friends then let me in on a little secret.

If I wanted to attend conferences on (very) limited funds, I could become a speaker.

As a speaker you get free entry to the event, and quite often, the conference will cover flights and accommodation for interstate speakers. What an amazing way to increase the number of conferences you can attend!

Except...

I hated public speaking. Like, afraid to speak up in meetings or in front of more than 3 people at a time, hate.

Not to mention, what would I even have to say that other people would be interested in?

So I laughed it off, and filed it away under "Things that will never happen".

But that was the moment, the seed was planted.

The Perth crew representin' at CSSConfAU 2018

The Seed Grows...

Fast forward a year and I'm co-organiser of a meetup group for front-end developers. I've MC'd our events a few times without anything too disastrous happening. And although I'm still afraid of public speaking, I've come around to the fact it's a really beneficial skill to have.

Frequently, my speaker friends would encourage me to apply to speak at events. And I would continue to deflect, because speaking at conferences is something other people do.

Until...

August 2019, JSConf Hawaiʻi released it's Call for Proposals (CFP).
(A CFP is the formal process of conferences requesting people to apply to speak at their conference.)

And this conference folks, looked amazing 😍

Not only was this well-respected event happening in a place I've always dreamed of going (HAWAI'I baby!), the CFP specifically welcomed first-time speakers! And the topics didn't even have to be JavaScript!

JSConf welcomes beginner speakers in their CFP

I was sold.

I needed to at least put my hat in the ring, right??

Call in the troops

This is when I enlisted my dream team (@Mandy_Kerr, @Amys_Kapers, @stringy and @sandysandy) to help me figure out how to make this whole CFP thing happen.

We organised a hacksesh and Mandy helped me brainstorm potential ideas using questions similar to the ones found in this post by Lucy Bain.

I then wrangled these ideas into three talk abstracts. (An abstract is a description of your talk idea, in a couple paragraphs, to sell it to the conference organisers and attendees).

By the end of the night, I had three validated talk ideas and some rough abstracts to polish up.

The next day, I took a big deep breath, drew up my courage and submitted all three of my talk ideas to JSConf.

Jess Budd

@jessbudd4

Just submitted my first ever conference proposal - eeek! Big thanks to @Mandy_Kerr @Amys_Kapers and @stringy who've been my constant inspiration/supporters and @sandysandy for her wordsmith help ❤️🤗

04:12 AM - 24 Aug 2019

0 25

In for a penny, in for a pound

So now I had these three talk proposals (and so very little chance of being accepted to my dream conference). It would be a waste not to use them again....

Friends suggested I should submit to DDDAdelaide and Google DevFest, both known for being exceptionally welcoming to beginners. Now, these are community run conferences, which means unfortunately they're not able to cover speaker flights or accommodation.

But as @Amys_Kapers always says, "That's future Jess's problem." 😅

And the chances of getting in were pretty slim anyway.

So I put in submissions for those too.

And then something crazy happened...

@Mandy_Kerr was invited to speak at LaraconAU, but had to decline due to already speaking at Web Directions at the same time... so SHE RECOMMENDED ME 😱

Laracon's organiser was willing to take a chance on a newbie - and that was it! My first ever conference talk was booked!

Jess Budd

@jessbudd4

Excited to share I'll be speaking at @LaraconAU in Sydney this October! If you're around, be sure to come say hi 😀 twitter.com/LaraconAU/stat…

07:39 AM - 10 Sep 2019

Laracon AU @LaraconAU
Next up, also joining us from Perth, and making her conference-speaking debut is UI developer and accessibility consultant, @jessbudd4 #Laracon #Wave3 https://t.co/MNi4AGbwCP

1 22

3 weeks after that, my submission to speak at Google DevFest in Melbourne was accepted.

Jess Budd

@jessbudd4

I'm speaking at #DevFest19 Melbourne this November! Will be in excellent company with @msandfor and other fantastic speakers 😍

Get your tickets and full details at buff.ly/2YBAHe0 @GDGMelbourne @yow_conf

03:18 AM - 01 Oct 2019

2 15

And a couple days later, I was selected to speak at the very first DDDAdelaide.

Jess Budd

@jessbudd4

So excited that I'll be speaking at the first ever @DDDAdelaide! Check out this amazing agenda!

Also, there's something really special knowing the developer community voted for your talk and for you to be there 🥰😊 twitter.com/DDDAdelaide/st…

09:21 AM - 04 Oct 2019

DDDAdelaide @DDDAdelaide
The agenda is LIVE 👀👀👀 https://t.co/fbEFMj828d

0 22

What have I learned?

You've got to be in it to win it. I always felt like I had nothing to say, no one would want to listen to me or take a chance on an inexperienced speaker. I was wrong.
People want to help you. I've had offers to help come up with talk ideas, write abstracts and give slide feedback from multiple people on twitter I've never even met in real life. If you show interest, people will put their hands up to help you get there.
There are lots of free speaking resources. All over the internet tech speakers are writing resources for us beginners to get into conference speaking. I highly recommend Zach Holman's speaking.io and Rachel Andrew's Getting Started in Public Speaking as starting points.
Listen when people say you can do this! This one might just be me, but I have a bad habit of assuming people are just being nice when they express confidence in my abilities. I needed to get out of my own way (and own head) to put myself out there for opportunities.

What next?

Well, now I actually have to write, practice and perform the talks 😂

I'll let you know how that goes in Part Two!

To be continued....

How I Set Up Git Aliases on Bash

Jess Budd — Tue, 13 Aug 2019 00:00:00 +0000

It was almost 2 year agos I first saw someone in a tutorial using an alias for their git commands. I thought at the time it was something I should set up, but not being incredibly comfortable with the command line, I didn't look into it much further.

What's an alias?

For those that may not have heard of aliases before, they're like shortcut commands in your terminal. You type the shortcut in place of typing the whole command.

For example instead of typing git push whenever I want to push my repo, I can assign a shortcode for that command and simply type gp (or whatever shortcut I set) to do the same thing.

Magic!

Setting up an alias

This week, thinking it was about time I set up these aliases, I went off to google. I found a bunch of posts on how to create git aliases like this one and this one, but got a little overwhelmed by the different options and as with most tutorials they assumed a fair bit of up front knowledge.

Following the most simple format example, I typed my most common git actions into the command line window I already had open for my current project.

alias gs='git status '

alias ga='git add '

alias gc='git commit -m '

alias gp='git push'

alias gb='git branch '

alias go='git checkout '

alias gm='git merge '

alias gpl='git pull'

alias gl='git log'

I then tentatively tested my shiny new aliases with a gs.

It worked! Huzzah!

I went along my merry away.

Until the next day, when I got my dev environment up again and tried to use my new aliases. They didn't work.

-bash: gs: command not found

Sad face.

Setting up an alias globally

It turns out I had only created temporary aliases that existed in that sinlge CLI window only. To create global aliases that would persist in all future windows I needed to add them to my .bash_profile.

On a mac, the .bash_profile file is located in the home username folder. This was a hidden file, so I needed to show all hidden files by pressing cmd + shft + . to find it.

So in my .bash_profile file I typed the exact same code as I'd typed the day before.

alias gs='git status '
alias ga='git add '
alias gc='git commit -m '
alias gp='git push'
alias gb='git branch '
alias go='git checkout '
alias gm='git merge '
alias gpl='git pull'
alias gl='git log'

I saved the file, closed down all my terminal windows and tested the alias in a fresh window and they worked. Yay!

Other methods

Over the next couple days (thanks to the twitterverse) I found there are possibly better ways to do this. For example Atlassian has a good article that describes how to set up your aliases through the gitconfig file.

One fender mentioned oh-my-zsh comes with git aliases built in. Another mentioned putting the git aliases in a seperate alias file and then referencing that in your .bashrc file.

I'm sure there are good reasons to choose one method over the other, but for now I'm happy with the way I've done mine as it's fine for my situation.

DEV Community: Jess Budd

The Year I Became a Conference Speaker (Conclusion)

My Australian Speaking Tour (cont...)

Google DevFest, Melbourne

DDD, Adelaide

What have I learned?

What next?

Hiding Content Accessibly

Hiding content for everyone

Hiding content visually

Never visible

Visible when focused

Combined approach

Hiding content from screen readers

Further Reading

The Year I Became a Conference Speaker (Part Two)

My Australian Speaking Tour

Laracon, Sydney

What have I learned?

What next?

The Year I Became a Conference Speaker (Part One)

Except...

The Seed Grows...

Until...

Call in the troops

In for a penny, in for a pound

And then something crazy happened...

What have I learned?

What next?

How I Set Up Git Aliases on Bash

What's an alias?

Setting up an alias

Setting up an alias globally

Other methods