Frank Chimero is redesigning "in the open" and we should pay attention to it because (1) we should listen to anything Frank has to say because he's a great designer and writer and (2) working in public is awesome.
But the gut punch for me in this opening article is the way Frank pulls zero punches on the state of design writing:
Design isn't alone in its lack of quality content—the web, by and large, has become a dumping ground for garbage. Most design content has become poor quality, surface-level content marketing that does more damage than good, because it offers over-simplified, misinformed perspectives dressed up as guidance. One hardly gets the sensation of lived experience and professional acumen in the words. When the experienced don't write, grifters step in, feign expertise, and sell it.
CSS is the domain of styling, layout, and presentation. It is full of colors, sizes, and animations. But did you know that it could also control when a sound plays on a web page?
This article is about a little trick to pull that off. It’s actually a strict implementation of the HTML and CSS, so it’s not really a hack. But… let’s be honest, it’s still kind of a hack. I wouldn’t recommend necessarily using it in production, where audio should probably be controlled with native <audio> elements and/or JavaScript.
The trick
There are a few alternatives to playing sounds with CSS, but the underlying idea is the same: inserting the audio file as a hidden object/document within the web page, and displaying it whenever an action happens. Something like this:
This code uses an <embed> tag, but we could also use <object> with similar results:
<object data="path-to-audio-file.mp3"></object>
A quick note on the demo and this technique. I developed a small piano on CodePen just with HTML and CSS using this technique about a year ago. It worked great, but since then, some things have changed and the demo doesn’t work on CodePen anymore.
The biggest change was related to security. As it uses embed or object instead of audio, the imported file is subject to stricter security checks. Cross-origin access control policies (CORS) force the audio file to be on the same protocol and domain as the page it is imported into. Even putting the sound in base64 will not work anymore. Also, you (and users) may need to activate autoplay on their browser settings for this trick to work. It is often enabled behind a flag.
Another change is that browsers now only play the sounds once. I could have sworn that past browsers played the sound every time that it was shown. But that doesn’t appear to be the case anymore, which considerably limits the scope of the trick (and bares the piano demo almost useless).
The CORS issue can be worked around if you have control over the servers and files, but the disabled autoplay is a per-user thing that is out of our control.
the element changes from being rendered to not being rendered, or vice versa,
[...] the user agent must queue a task to run the following steps to (re)determine what the object element represents. [and eventually process and run it]
While it is clearer for object (the file is processed and run on render), we have this concept of “potentially active” for embed that may seem a bit more complicated. And while there are some additional conditions, it will run on initial render similarly as how it does with object.
As you can see, technically this is not a trick at all, but how all browsers should behave... although they don’t.
Browser support
As with many of these hacks and tricks, the support of this feature is not great and varies considerably from browser to browser.
It works like a charm on Opera and Chrome, which means a big percentage of the browser market. However, the support is spotty for other Chromium-based browsers. For example, Edge on Mac will play the audio correctly, while the Brave browser won't unless you have the latest version.
Safari was a non-starter, and the same can be said for Internet Explorer or Edge on Windows. Nothing close to working on any of these browsers.
Firefox will play all the sounds at once on page load, but then won’t play them after they are hidden and shown again. It will trigger a security warning in the console as the sounds attempt to be play “without user interaction,” blocking them unless the user approves the site first.
Overall, this is a fun trick with CSS but one of those “don’t do this at home” kind of things… which in software development, means this is the perfect thing to do at home. 🙂
For some organizations, mobile apps can be an important means to capturing new leads and customers, so it can be alarming when you notice your app visits are declining.
However, while there is content on how to optimize your app, otherwise known as ASO (App Store Optimization), there is little information out there on the steps required to diagnose a drop in app visits.
Although there are overlaps with traditional search, there are unique factors that play a role in app store visibility.
The aim of this blog is to give you a solid foundation when trying to investigate a drop in app store visits and then we’ll go through some quick fire opportunities to win that traffic back.
We’ll go through the process of investigating why your app traffic declined, including:
Identifying potential external factors
Identifying the type of keywords that dropped in visits
Analyzing app user engagement metrics
And we’ll go through some ways to help you win traffic back including:
Spying on your competitors
Optimizing your store listing
Investing in localisation
Investigating why your app traffic declined
Step 1. Identify potential external factors
Some industries/businesses will have certain periods of the year where traffic may drop due to external factors, such as seasonality.
Before you begin investigating a traffic drop further:
Talk to your point of contact and ask whether seasonality impacts their business, or whether there are general industry trends at play. For example, aggregator sites like SkyScanner may see a drop in app visits after the busy period at the start of the year.
Identify whether app installs actually dropped. If they didn’t, then you probably don’t need to worry about a drop in traffic too much and it could be Google’s and Apple’s algorithms better aligning the intent of search terms.
Step 2. Identify the type of keywords that dropped in visits
Like traditional search, identifying the type of keywords (branded and non-branded), as well as the individual keywords that saw the biggest drop in app store visits, will provide much needed context and help shape the direction of your investigation. For instance:
If branded terms saw the biggest drop-off in visits this could suggest:
There has been a decrease in the amount of advertising spend that builds brand/product awareness
Competitors are bidding on your branded terms
The app name/brand has changed and hasn’t been able to mop up all previous branded traffic
If non-branded terms saw the biggest drop off in visits this could suggest:
You’ve made recent optimisation changes that have had a negative impact
User engagement signals, such as app crashes, or app reviews have changed for the worse
Your competition have better optimised their app and/or provide a better user experience (particularly relevant if an app receives a majority of its traffic from a small set of keywords)
Your app has been hit by an algorithm update
If both branded and non-branded terms saw the biggest drop off in visits this could suggest:
To get data for your Android app, sign into your Google Play Console account.
Google Play Console provides a wealth of data on the performance of your android app, with particularly useful insights on user engagement metrics that influence app store ranking (more on these later).
However, keyword specific data will be limited. Google Play Console will show you the individual keywords that delivered the most downloads for your app, but the majority of keyword visits will likely be unclassified: mid to long-tail keywords that generate downloads, but don’t generate enough downloads to appear as isolated keywords. These keywords will be classified as “other”.
Your chart might look like the below. Repeat the same process for branded terms.
Above: Graph of a client’s non-branded Google Play Store app visits. The number of visits are factual, but the keywords driving visits have been changed to keep anonymity.
To get data for your IOS app
To get data on the performance of your IOS app, Apple have App Store Connect. Like Google Play Console, you’ll be able to get your hands on user engagement metrics that can influence the ranking of your app.
However, keyword data is even scarcer than Google Play Console. You’ll only be able to see the total number of impressions your app’s icon has received on the App Store. If you’ve seen a drop in visits for both your Android and IOS app, then you could use Google Play Console data as a proxy for keyword performance.
If you use an app rank tracking tool, such as TheTool, you can somewhat plug gaps in knowledge for the keywords that are potentially driving visits to your app.
Step 3. Analyze app user engagement metrics
User engagement metrics that underpin a good user experience have a strong influence on how your app ranks and both Apple and Google are open about this.
Ultimately, Apple wants to ensure IOS apps provide a good user experience, so it’s likely they use a range of additional user engagement metrics to rank an app in the App Store.
As part of your investigation, you should look into how the below user engagement metrics may have changed around the time period you saw a drop in visits to your app.
App rating
Number of ratings (newer/fresh ratings will be weighted more for Google)
Number of downloads
Installs vs uninstalls
App crashes and application not responding
You’ll be able to get data for the above metrics in Google Play Console and App Store Connect, or you may have access to this data internally.
Even if your analysis doesn’t reveal insights, metrics like app rating influences conversion and where your app ranks in the app pack SERP feature, so it’s well worth investing time in developing a strategy to improve these metrics.
When trying to identify opportunities to improve app store visibility, I always like to compare the top 5 ranking competitor apps for some priority non-branded keywords.
All you need to do is search for these keywords in Google Play and the App Store and grab the publicly available ranking factors from each app listing. You should have something like the below.
Brand
Title
Title Character length
Rating
Number of reviews
Number of installs
Description character length
COMPETITOR 1
[Competitor title]
50
4.8
2,848
50,000+
3,953
COMPETITOR 2
[Competitor title]
28
4.0
3,080
500,000+
2,441
COMPETITOR 3
[Competitor title]
16
4.0
2566
100,000+
2,059
YOUR BRAND
[Your brands title]
37
4.3
2,367
100,000+
3,951
COMPETITOR 4
[Competitor title]
7
4.1
1,140
100,000+
1,142
COMPETITOR 5
[Competitor title]
24
4.5
567
50,000+
2,647
Above: anonymized table of a client's Google Play competitors
From this, you may get some indications as to why an app ranks above you. For instance, we see “Competitor 1” not only has the best app rating, but has the longest title and description. Perhaps they better optimized their title and description?
We can also see that competitors that rank above us generally have a larger number of total reviews and installs, which aligns with both Google’s and Apple’s statements about the importance of user engagement metrics.
With the above comparison information, you can dig a little deeper, which leads us on nicely to the next section.
Optimize your app text fields
Keywords you add to text fields can have a significant impact on app store discoverability.
As part of your analysis, you should look into how your keyword optimization differs from competitors and identify any opportunities.
For Google Play, adding keywords to the below text fields can influence rankings:
Keywords in the app title (50 characters)
Keywords in the app description (4,000 characters)
Keywords in short description (80 characters)
Keywords in URL
Keywords in your app name
When it comes to the App Store, adding keywords to the below text fields can influence rankings:
Keywords in the app title (30 characters)
Using the 100 character keywords field (a dedicated 100-character field to place keywords you want to rank for)
Keywords in your app name
To better understand how your optimisation tactics hold up, I recommended comparing your app text fields to competitors.
For example, if I want to know the frequency of mentioned keywords in their app descriptions on Google Play (keywords in the description field are a ranking factor) than I’d create a table like the one below.
Keyword
COMPETITOR 1
COMPETITOR 2
COMPETITOR 3
YOUR BRAND
COMPETITOR 4
COMPETITOR 5
job
32
9
5
40
3
2
job search
12
4
10
9
10
8
employment
2
0
0
5
0
3
job tracking
2
0
0
4
0
0
employment app
7
2
0
4
2
1
employment search
4
1
1
5
0
0
job tracker
3
0
0
1
0
0
recruiter
2
0
0
1
0
0
Above: anonymized table of a client's Google Play competitors
From the above table, I can see that the number 1 ranking competitor (competitor 1) has more mentions of “job search” and “employment app” than I do.
Whilst there are many factors that decide the position at which an app ranks, I could deduce that I need to increase the frequency of said keywords in my Google Play app description to help improve ranking.
Be careful though: writing unnatural, keyword stuffed descriptions and titles will likely have an adverse effect.
Remember, as well as being optimized for machines, text fields like your app title and description are meant to be a compelling “advertisement” of your app for users..
I’d repeat this process for other text fields to uncover other keyword insights.
Step 2. Optimize your store listing
Your store listing in the home of your app on Google Play. It’s where users can learn about your app, read reviews and more. And surprisingly, not all apps take full advantage of developing an immersive store listing experience.
Whilst Google doesn't seem to directly state that fully utilizing the majority of store listing features directly impacts your apps discoverability, it’s fair to speculate that there may be some ranking consideration behind this.
At the very least, investing in your store listing could improve conversion and you can even run A/B tests to measure the impact of your changes.
You can improve the overall user experience and content found in the store listing by adding video trailers of your app, quality creative assets, your apps icon (you’ll want to make your icon stand out amongst a sea of other app icons) and more.
It makes logical sense. The better you can personalize your product for your audience, the better your results will be, so go the extra mile and localize your Google Play and App Store listings.
A drop in visits of any kind causes alarm and panic. Hopefully this blog gives you a good starting point if you ever need to investigate why an apps traffic has dropped as well as providing some quick fire opportunities to win it back.
If you’re interested in further reading on ASO, I recommend reading App Radar’s and TheTool’s guides to ASO, as well as app search discoverability tips from Google and Apple themselves.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!
from The Moz Blog https://ift.tt/2DbmY1a
via IFTTT
Building websites is programming. Writing HTML and CSS is programming. I am a programmer, and if you're here, reading CSS-Tricks, chances are you're a programmer, too.
The thing is, the details in programming layout with CSS are different, for example, than the details in programming API endpoints with Ruby. Or machine learning with Python. Or programming a browser engine with C++.
But those differences are details! A lot of details, but still... details. It's all programming.
I see programmers like this:
Where do HTML and CSS fit into this weird and cute universe? What is it to program user interface on the web?
Programming boxes, I like to say. Everything is a box, and as HTML/CSS programmers, we program boxes within the domain of the browser. Like this:
Cute. So?
So...I believe that we, both as individual programmers and together, as the web slice of the tech industry, need to arrive at a more holistic and inclusive understanding of what it means to be a programmer. This outlook not only makes tech a more welcoming place, but it makes us programmers more powerful and more adaptable.
To me – well, me in 2019 – programming is writing1 instructions for computers that other programmers, such as your future self, are able to read and maintain. As programmer, I am confident that, once I know one language well, I can learn another one2. At the end of the day, it's all made of the same stuff.
And yet...
I have been a programmer in this sense for around eight years, but up until about two years ago, I didn't see myself as one. In fact, I was actively opposed to calling myself a programmer, and in recent times I've heard the same sentiment from others. Why, exactly? Is this a reaction to the "not real programming" phenomenon? Is that still happening? What are the impacts? What were the impacts, for me and for others?
Yes, I know 'gatekeeping' – that is, the self-inflating exclusion of others from a community or identity – is a thing, and that some people are just jerks, but I think there is more to this story.
So, what's interesting to me3 about building websites this year? Talking to others who build websites4 and beginning the process of answering these burning questions.
Box programmers: Do they know things? What do they know? Let's find out!! In 2020, my goal is to learn learn Rust, a low-level programming language similar to C++. Correction: my goal is to start learning Rust – that is more than a one year undertaking. Why Rust? Keep an eye on my blog, I'll write more about this soon enough. ↩
It was hard to choose what to write about for this post! I'm interested in a lot of things, specifically unit testing CSS, my job as a Design Engineer, and exploring/sharing more about CSS algorithms.
What do you think, CSS-Tricks reader? Do you call yourself a programmer? Why, or why not? Have you experienced this "not real programming" phenomenon? How did it impact you? Feel free to write me a Twitter message or send me an email.
Eighteen years into this game, I love to reminisce back to the good ol’ days of the early to mid-2000s when there was an explosion of creativity on the web. It felt fresh and unbridled, with boundaries expected to be pushed at every turn, and they were. This was mainly down to one thing, the thing of nightmares to some, Flash! It, of course, had some big inherent flaws, but love it or hate it, certainly helped pave the way for what we expected from the open web. Sure, it was probably a more drawn-out process than we'd hoped for, but with some savage new advancements made over the last few years, I now feel that things are really starting to get proper juicy.
Several things come to mind that get me excited these days in designing and developing for the web, some widely adopted now like SVG (even though technically old) and WebGL animation, which draw some obvious parallels to the Flash era. Certainly, CSS Grid stood up and made itself known, shouting from the parapets about how the shackles of layout are now a thing of the past. Kudos to awesome people like Rachel Andrew and Jen Simmons for their serious efforts in educating us mere mortals in this area, helping make the learning curve and adoption that bit more palatable and accessible.
Looking around today you can see how advancements like Grid have helped elevate the rise of more asymmetric layouts, with design styles like Brutalism design going through a bit of a trend over the last year or so. But over time it felt as though typography might have taken the back seat a tad with all the other successes happening in pushing the web forward. Now enter variable fonts 🥳
Variable fonts have certainly piqued my interest this past year or so. Not only do they give us the obvious boost in performance with fewer https requests and smaller sizes compared to the bundles of web fonts we all inject into our pages, but we also gain more control over typography in terms of readability and accessibility. Say goodbye to cheekily adding muddy sacrificial faux bold or italic styles to our CSS!
Taking this further, I feel that variable fonts have really unlocked the door to new creative possibilities that we're only just scratching the surface of. Having the ability to interpolate between different values of the axes just screams out for animation. We have the standardized set of 5 registered axes like font-weight, font-stretch, font-style, etc. which are straight forward enough to appreciate, but when it comes to custom axes via font-variation-settings, things start getting crazy and fun. Type designers can use the interpolation in custom axes to create some really off the wall things beyond, well… text. Just check out Typearture’s fab variable font experiments to see what I mean.
A few months back I was privileged to be invited to experiment with and test Greensock's newly released GSAP 3, which I’m also most definitely excited about. It boasts a new simplified API and 50+ new features, yet is only about half the file size as the previous version. This is currently my catnip though: layering GSAP on top of variable fonts in CodePen to create some lovely kinetic typography in the DOM. This kind of magic, until now I guess, has been more attributed to WebGL, Processing and After Effects. Now, throw some GSAP plugins on top again, and you can definitely create some very cool and unique stuff. I would suggest, however, that you use this new creative power of animating variable fonts in whichever way you do it sparingly, as reflow could become an issue with jank.
I'm excited to see what people will create using variable fonts over the next year as it becomes more widely adopted. Not just limited to typographic treatments in layouts, but also in terms of animation and micro-interactions. It looks like a big undertaking for designers in creating such fonts, but credit to them. I'm sure we'll be all the more appreciative. Thanks in advance type designers!
I started this year on a new path at Knowbility — to help people and organizations create accessible content and apps. But what was exciting and helped motivate me more were two things:
WebAIM's Accessibility Analysis of One Million Page Homepages. With over 97% of sites having WCAG failure of some kind, it's a stinging indictment on our industry. There's a lot of work to be done — that means outreach and education, helping other developers incorporate accessibility into their workflows, coding pull requests with accessibility fixes, making certain components for design systems are accessible and much more.
The Supreme Court of the United States rejecting Domino's appeal. The Supreme Court leaves the Ninth Circuit federal appeals court's ruling, which means that people with disabilities who have trouble with sites or apps that are not accessible can bring claims under the Americans with Disabilities Act (ADA). This result means that organizations can't kick the proverbial can down the road for making their apps and products accessible.
In regards to the One Million Pages, I noticed that web designers and developers outside of accessibility circles discussing accessibility with a sustained focus I hadn't witnessed before.
And I would have conversations with people outside web design and development altogether about accessibility due to this court case alone. Companies and organizations were watching it very closely.
This added increased awareness from both WebAIM's report and the Domino's appeal has helped fuel the discussion, making it easier to keep the conversation going to make digital accessible to all.
I've been thinking about the question for a solid month now. What about building websites has you interested this year? The question pervaded my solitary thoughts and played in the background during my conversations. I’d love to just tell you the answer I’ve come to, but the more interesting part was my thought journey in getting there.
I jumped at the opportunity to write up my thoughts on this because in general, I am delighted to dive into a conversation about anything that gets me excited. Writing, though, is heavy with irony in my life. There are so many exciting things that I'd love to write about, but I never get asked to write about them. That is of course, until I do, and my mind goes blank.
Even when I properly sat down, cleared my desk, and got out a fresh notebook out to brainstorm and reflect... I still couldn't really come up with an answer. It worried me.
I thought that maybe my answer would be too meta. Or maybe I couldn't really notice the thing I’m interested in the most because it's already seamlessly integrated into my workflow? Nonetheless, I started by collecting thoughts by way of the insta-question-answer technique, where you rapid-fire ask yourself a bunch of questions and say the first thing that comes to mind. This is a great technique when you want to get a quick, reasonably honest answer about something. If you can go fast enough, your brain's first answer is fairly genuine and generally, the one you have, consciously or subconsciously, spent time thinking about. You also have to place an injunction on your rational brain's inherent desire to veto your real answers (what if someone sees!) and replace them with more polished ones.
Let's Play: This Year's Favorites
What's your favorite song from this year? OldTown Road. I want more black cowboys wearing yellow to exist. I didn't realize how much I wanted that to exist until I saw that performance.
What movie did you like the most? Godzilla: King of the Monsters. Obviously, even though that little girl should have died like 20 times. I know I probably should have said Avengers End Game because that movie was everything but it's Godzilla. King of the Monsters. So he has to win.
Favorite tech upgrade? Automating my lights. I was a little behind the curve on this one but it's been great.
Mobile App? Kami 2. Super fun to play.
What about building websites has interested you this year? Um...
My brain shut down. There was no answer, only silence.
I thought of the answers I shouldwant to say. That the increased focus on accessibility is encouraging. That the new edition of Ember feels pretty nice once you get over not having magic anymore. That design systems done right, paired with a framework done right, is pure productivity bliss.
Truth is, I probably could have made any of those answers work, and no one would be the wiser. After all, they are satisfying answers. Deeply satisfying. Years of passion, patience, and persistence is yielding the fruits of our labor. But none of these answers set isInteresting to true for me. So I kept thinking. Surely the answer would come to me if I let it hang around in my sub-conscious a little more.
A week came and went, but there was still nothing.
I started to become a little anxious. What did it mean? Was I burnt out? Was I just not interested in building websites anymore? Have I lost the spark? Maybe I was just not talented enough to write an article like this? Did I say "yes" to the wrong thing? As tempting as it was to crawl into bed under my covers and continue this downward spiral into the endless black hole "what does it all mean", I decided to make a strong cup of tea and lean on the skills I have developed over the last 20 plus years of building for the web.
Problem Solving Skills
We already have everything we need. There is no need for self-improvement. All these trips that we lay on ourselves—the heavy-duty fearing that we’re bad and hoping that we’re good, the identities that we so dearly cling to, the rage, the jealousy and the addictions of all kinds—never touch our basic wealth. They are like clouds that temporarily block the sun. But all the time our warmth and brilliance are right here. This is who we really are. We are one blink of an eye away from being fully awake.
This quote is from a prominent Zen Buddhist and one that I reach for when I get stuck inside myself. I remind myself that I already know the answer, I just need to use the tools I have to bring it out and let it shine. I needed to trust the process that has worked time and time again for me: slow up, write everything down, and just ship it.
Part 1) Slow Up
I had become so engrossed in the every-day mundane I was missing the inspiration. It's easy to get bogged down in lines of code, JIRA tickets, and quarterly goals, all the while explaining ad nauseum that developers should reach for semantic HTML first. I recognize the signs now and knew what I needed to do. I needed to slow down to get faster. Sounds counter-intuitive, right? But it’s the same in software engineering: slow is fast. We have proven, time and time again, that when we rush solutions we incur technical debt that we are unlikely to ever repay.
So I took some time to catch my breath and feed my creativity.
I read a book. I watched an interview with an author. I learned from a video series about a standup comedian talking about their process in creating. I sat still and listened to some cello music.
Part 2) Write Everything Down
The next part of my process is to write things down. When creative inspiration is missing, I turn to functional discipline. I have learned that they are the yin and yang of my creative process as a whole. So, I started to make lists. I listed all of the things I have shipped so far this year. I listed all of the conferences where I gave talks and the conferences where I wanted to give talks but didn't. I wrote down the things that gave me confidence this past year and the things that made me feel like an imposter. I looked at my goals from the start of the year and made a list of the things I'd done for each goal.
Then I started writing a little more, this time in paragraphs. I transcribed one of my talks and took notes on where I would do better next time. I write a review of one of my annual goals and thought a bit more deeply about what motivates and inspires me.
Part 3) Just Ship It
Then it came to me. I knew the answer.
It was nothing, but it was everything.
Nothing specifically about building websites has specifically interested me this year - but I'm still as interested as ever in building them. The answer to "what about building websites has interested you this year" is simply a resounding "Yes".
Yes, because I still love thinking about design, components, and the perfect information architecture. Yes, because as much as I swear at my code, I keep coming back to it, keep finding new things to love about it, keep feeling energized when that idea just clicks and something great happens. Yes, because despite doing this for 22 years, I still want to get up and do it again tomorrow.
And that’s when I knew that I could just ship it.
The tech of today, the tech of tomorrow
We are at a specific time and place in tech. Those of us who are building for the web have become more aware of how the tech we create effects those around us. We are starting to accept our responsibility for the lines of code that we write, and see that we cannot merely pass the buck to our supervisors and bosses to make ethical decisions. We are demanding more of ourselves, demanding more from the code we write and the systems we use, demanding more from the giants of technology who seek to abdicate responsibility for how their tech is used.
At the same time, we are figuring out how to climb the proverbial mountain together, while recapturing the fun we had back in the days we called ourselves "webmasters". We are learning to be kinder to ourselves and others. We are figuring out how to make creating for the web easier to learn and to do and we are breaking down the walls that kept far too many people out for too long.
I was watching my son while he was absorbed in lightsaber battles in virtual reality and thinking about how his childhood is so different than mine. The tech I had back then isn’t anything near the tech I have today, and the tech he has today won’t be the tech he has as an adult. What do I imagine that will look like? Even bigger than that, what do I want to help bring into existence?
The truth is, it's all interesting to me. All of it. I can't wait to see we do next and I’m so here for it.
