#javascript css html my enemies | Explore Tumblr posts and blogs

guzsdaily · 2 years ago

Text

Predicting and programming: enemies for life (part 2)

Day 42 - Dec 17th, 12.023

This is the direct continuation of yesterday's post. I hope that I'm able to continue my daily journals as usual, but there's a strong possibility that one day or another I will not able to post, or need to post after midnight. Also, the entries probably will be shorter or just small updates sometimes even on weekends, but I will try to write them on the morning to be able to have time and brain to do something bigger and with better quality. And some posts I could even need to split into two if I need to stop writing one in the middle, like what's happened yesterday. There's no need to go into details, I don't want to expose my personal life nor of the people around me, I just want to inform that this end of year is not being great to my partner, so I want to be with her as much as I can to help and support her to whatever she needs to.

"A ghostly server"

Like I said in the last part, the application was complaining about not having a server, and the stranger, it was complaining about not having the development server running. This as a production build of the application, the embedded web-app were a static one, a static HTML file, why was it complaining about the server!? I tried searching around the Tauri's GitHub issues, but there was nothing about it, and creating an issue wasn't in my mind at the time because again, I am short in time and couldn't wait for a fix.

So because Tauri wasn't working, and I didn't even want to think about how to fix this problem, I switched back to CapacitorJS. This process was somewhat easy, because both of them are a "wrapper", so I just needed to move the web app part of the application from a template to another, but it was somewhat time-consuming (I'm not so accustomed to Vim and my new file explorer, so navigating was somewhat slower, and like every JavaScript project, just setting it up a template can be time-consuming). But after setting it up, Capacitor compiled, and the app was working as normal without any differences.

Framework hopping

While that was happening, when I started the project, I also wasted a lot of time choosing what framework to use. "Why?" One, JavaScript is an ecosystem that in general can be somewhat overwhelming with choices; Two, I already used SvelteKit for my last application and projects, so this time I wanted something different; Three, I wanted to try something more "native-like".

Web as Native

I started trying to use Framework7, because it has a collection of components and routing that emulates the native-app experience, and most important to me, it had the updated Material Design 3 (Material You) design; with Svelte, my primary UI framework of choice. But it didn't work that well. The routing wasn't how I liked it to be, and Framework7 is a somewhat old framework as it seems (it uses Gulp as its build system and the last commits were a month ago, the project is not that active), it stills a great project, but somewhat difficult to integrate with newer thing like Svelte 4 and Vite. After not being able to, I tried to KonstaUI with Svelte, but ended up with the same results. If you know something about this area of trying to make web apps feel like a native app, you are probably thinking something like "why you didn't use Ionic?", and the main reason is that it stills uses Material Design 2, and personally I like more how the newer version looks. Also, Ionic doesn't have official support for Svelte, and even knowing that the community package is good, I already used it in the past and wanted something new to try.

So, after probably hours, if not a day, trying that, I hopped into another idea. I found something called Beer CSS, a library that creates a Material You look and app using just CSS pretty much, so I could use any framework that I liked! Nonetheless, because it was pure JS and CSS, I thought it would be good to use Astro, so I could also take advantage of its new View Transitions feature, and could use Svelte still for the interactivity blocks. But as you can already tell if you know Astro, it's probably not the best idea to use a static site generator (SSG) as a mobile application framework, however it was working, and I was being able to create something and actually develop the application part of things and not just continue setting up new projects.

Lack of documentation

But then some cracks started to open. Beer CSS's documentation is not the greatest for me, it's mostly code examples and there's pretty much no words about customization and how the CSS words and/or how to manipulate it, and it seems that you really need to follow Material's system and hierarchy to it to work properly. I don't have time for this, and I already wasted 2 to 3 days fighting my way around all of this.

Also, while this was happening, the problem with Tauri also happened, which for some reason also made me switch from Astro to SvelteKit. Why? I don't know really, for me the problem with the server could be related to it, but of course it didn't work, and I had to switch to Capacitor like I said.

Blank screen and broken dreams

And then, another problem appeared out of nowhere, the built app with CapacitorJS started to have a total black screen when I opened it. There were no errors in the console, warnings on the screen, nothing, the app simply stopped working, and I couldn't find anything about it on the issues, and being honest, at this point I had already wasted around a week and couldn't handle it anymore. The idea of not being able to give at least something in time was storming my mind and I ended up wasting another day procrastinating, because I couldn't handle and think of solutions.

I had so many ideas for this app and now everything stopped working, I was exhausted, this was supposed to be something special for my girlfriend, and I don't want to lose the date again, even more now when she's passing difficult times in her life. I need to do and try something.

Compromises

This is where I am right now. I have less than a week to finish this project, and the app itself is way unfinished than I anticipated it would be days ago. So, what we do when this happens? Compromises, I already had in mind that I would create just some features until the date and then update over time, but now it will be just one feature and as an online website for now.

One of the features of this app is an interactive messaging page, to give complements and things like that, but for now I will try to repurpose it to some predefined messages and just express out of my heart to her using it. Do I want to be simple as that? No, but it only what I can do for now, and hopefully I will be able to add more things as time passes, I really want to do something special and specific for my girlfriend. Thankfully, porting it to a native app in the future won't be so hard, and I already have some ideas now on how to fix the past bugs that impossibilitaded me from porting it, however I will try to focus more on the features themselves for now.

Knowing my girlfriend, she will understand, but again, it's more of me to her thing in my mind.

---

Today's artists & creative things

Song: Hello, World - by Louie Zong I don't know why, writing this post just remembered me this music.

---

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) License

#daily journal #codeblr #javascript

2 notes · View notes

brandencodes · 4 years ago

Text

My First Project @ Flatiron!

Hello all! This is my first blog and it is about my first project. In this project I use fetch to grab info from a locally hosted JSON server. I am very excited for how it turned out and that I was able to create this little web page! Of course, with the help from my cohort lead and fellow students. I used a single page with CSS, HTML, and JavaScript to build this web page. So, what I have created is a game that randomly generates a team for the client, and a team for them to face off against. This is done with the first click-event and another click that will tell you if your team wins or loses. This is based off a total value of the team combined. Different characters in the game have different values, and it can be either 5, 10, or 15. There is also... yet again lol, another button, but this one will reset/empty out the teams so you can play again. I coded in a scoreboard that shows how many wins your team has versus the enemy team.

The biggest difficulty I faced while working on this projects was randomly generating a team. As well as, limiting the teams to 3 members only. I learned how to make a function that generates a random number which is very exciting! With the help from my lead, I learned to use a while loop to grab a random ninja from my fetch function. I did this by calling the function that contains my button for creating a team and the while loops it uses. Made a variable that contains an empty array for each team, and also a variable for each unordered list that each team will be placed in. Each while loop's condition is the empty array's length less than or equal to 2. This is what limited the team to 3. Then added another variable for each team that is all the characters, and in square brackets/index of the characters is the random number generator function that takes the length of the characters as its parameter. The length of the characters is 18 and the random number generator function will insert that into its equation. It returns Math.floor(Math.random() * max, and the max is this functions parameter. So what ever number it generates will be used as the index of the one character to grab from the whole list. We then .push the variable into the empty array. Now this where I know I could have used better code to make it a whole lot cleaner, but I struggled and plan on being able to learn how to shorten it up. With the help from another student, we made a list item variable for each member of each team. We then grabbed each one and made their innerHTML = their empty array at index 0, 1, and 2 .Name. This grabbed just the characters name, which after, we append the 3 that go with each team to the unordered list that they belong. I hope my code talk is not too bad to understand right now, but I will keep improving. I will also be able to look back on this post as a reference if I ever get stuck on something similar again!

1 note · View note

dodikawouk · 3 years ago

Text

The Code Must Go On: An Afghan Coding Bootcamp Becomes a Lifeline Under Taliban Rule

Four months after the Afghan government fell to the Taliban, 22-year-old Asad Asadullah had settled into a new routine.

In his hometown in Afghanistan’s northern Samangan province, the former computer science student started and ended each day glued to his laptop screen.

Since late October, Asadullah had been participating in a virtual coding bootcamp organized by Code Weekend, a volunteer-run community of Afghan tech enthusiasts, with content donated by Scrimba, a Norwegian company that offers online programming workshops.

On some days, Asadullah took a screen break for a game of pickup soccer, but generally he didn’t see his friends that much anymore. Under the Taliban regime, “old friends are getting so depressed,” he explains, and there was only so much of that he could handle. Instead, he tells me, “my life is on my computer.”

Asadullah is one of the millions of young Afghans whose lives, and plans for the future, were turned upside down when the Taliban recaptured Afghanistan last August. When the capital fell, Asadullah had two semesters of college left, and he was thinking about his post-graduation plans. He wasn’t picky about his first job; anything that let him save up some money would do. But he had bigger plans: Asadullah wanted to start his own software company and share his love of computer science by teaching university and high school students. “When I start coding, I can forget everything,” he says.

Today, those plans are on pause—and no one knows for how long. The country’s economy is in free fall, the United Nations warns of famine, and in the meantime, Afghanistan’s new rulers have offered little by way of solutions to its citizens.

In such dire circumstances, a coding bootcamp—a remnant of a brief period of techno-optimism in Afghanistan—may seem out of place. But for its participants, it offers hope of a better future—though whether such a future is still possible in Afghanistan remains to be seen.

Virtual learning

When the Taliban swept into power in August, it was unclear what their rule would mean for the Internet in Afghanistan. Would they cut off Internet access? Use social media posts—or government databases—to identify and target their former enemies? Continue to wage their own increasingly effective public affairs campaigns?

As it turned out, the Taliban did not cut off access to the Internet—at least it has not yet. Instead, for those Afghan students who can afford the Internet at home—especially women and girls, whom the regime has officially banned from secondary and higher education—online learning has become one of the primary sources of education.

Some of this is well organized, with encrypted virtual classrooms set up by international supporters, while some is entirely self-directed—learning through YouTube videos, perhaps, or playlists of TED talks. And often it falls somewhere in between, making use of free or discounted online learning platforms.

Afghan women attend a 2018 event. Photo courtesy Code Weekend.

Code Weekend’s virtual bootcamp falls into this latter category. Seventy-five participants were accepted into the cohort and are working their way through Scrimba’s Frontend Developer Career Path, a series of 13 interactive video learning modules that cover everything from HTML and CSS basics to tips on handling job interview questions about JavaScript or GitHub.

Participants can complete the modules on their own time and in their own homes, with Code Weekend volunteer mentors checking in weekly to answer questions, ensure that they stay on track, and assist with logistics as needed—including providing Internet top-up to keep participants online. According to organizers, roughly 50 members of the original cohort are active.

Ensuring Internet connectivity is just one of the logistical and financial challenges of running a bootcamp, even a virtual one, in Afghanistan. Another is contending with power outages, which become more frequent every winter. In an attempt to solve both these problems, Code Weekend has been trying to crowdfund the costs of 3G credit and backup electricity through generators and battery storage units.

But there’s another issue that worries organizers: “what the Taliban think,” says Jamshid Hashimi, the software engineer who started Code Weekend with friends seven years ago. The group doesn’t want to find out. “So far, we avoided interactions with them,” he says.

In a way, the bootcamp’s virtual, asynchronous format helps Code Weekend stay under the radar. It makes it far easier for women, whose freedom of movement has been drastically curtailed under the Taliban’s extreme interpretation of Islam, to participate without leaving their homes—or even interacting with male participants, which might also provoke the Taliban’s ire.

Zarifa Sherzoy, 19, is one of the boot camp’s female participants. A recent high school graduate, she had hoped to be taking college entrance exams and starting university classes this semester, but instead, she and her seven siblings spend most of their days at home. Between household chores, power outages, and her limited access to the Internet, she spends just an hour or two on the coding bootcamp. But still, even this has provided a new structure and meaning to her days. “After the Taliban arrived,” she recalls being “very tired at home every day thinking about how to end this.” But since the coding bootcamp started in late October, she says, while her problems haven’t disappeared, “my days are good.”

The virtual format has another added perk: it allows coders outside the Afghan capital, like Asad Asadullah, to participate.

Code Weekend Bootcamp

Jamshid Hashimi at a 2015 event. Photo courtesy Code Weekend.

When Jamshid Hashimi, then a 23-year-old software architect at the homegrown Afghan tech company Netlinks, launched Code Weekend in June 2014 to bring together Afghan programmers, he was inspired by the techno-optimism that then permeated Kabul.

A Fast Company profile on the country’s burgeoning startup scene, published in 2012, described the pervasive hopefulness this way: “Impossibly optimistic and totally obsessed, Afghanistan’s would-be tech moguls believe that computing will not only help them make money, but also secure peace in their land.”

And it was not just tech companies that were hopeful. Code Weekend was part of a slew of initiatives that aimed to spur youth innovation, entrepreneurship, and, ultimately, engagement and leadership in building a more progressive Afghanistan—some funded by international donors with this express purpose.

Other examples included the TEDxKabul program, which first came to Kabul with its “ideas worth spreading” (the TEDx tagline) in 2012, as well as other entrepreneurship-focused global franchises like Founder Institute-Kabul, which ran from 2014 to 2017. (Hashimi played a role in both of these programs, as did I, at different times.) By 2016, even Google had come to town, launching Google for Entrepreneurs’ Startup Grind, a community for aspiring startup founders.

But Code Weekend outlasted all of these initiatives, even after some of its own leadership team, including Hashimi, left Afghanistan. In the seven years since its founding, the volunteer-organized group has held around 100 in-person meetups at universities, incubators, and the offices of prominent Afghan technology companies.During the pandemic, like much of the rest of the world, it went virtual.

Attendees met to learn everything from the basics of WordPress design and JavaScript languages to data collection tools for the field. (Afghanistan’s aid-driven economy had a big appetite for surveys and employed a number of ICT workers.) They heard from local startups and engineering teams that came to introduce their new apps. They discussed books popular in the global tech community, like The Passionate Programmer (which Hashimi presented). And once, in an all-night event, open-source enthusiasts came together to stream Laracon Online, the global conference for the open-source Laravel web development framework.

Then, in 2019, after years of these mostly weekend events, Code Weekend decided to go bigger: the group launched an in-person coding bootcamp. The first cohort ran with a pilot program of 15 developers, 12 of whom graduated from the four-month program. A few, according to Hashimi, found jobs as a result of their participation.

Elyas Afghan, 24, hopes to be one of them after he completes the bootcamp. Both of his older brothers are also in the field—one works for Rapid Iteration, Hashimi’s company—and partly as a result of their influence, he says, working with computers is all he’s ever wanted to do. More specifically, he hopes to find a job working for a global tech company.

After the successful pilot, Code Weekend organizers planned for a second cohort, but the coronavirus slowed down their efforts. Then, in late August of last year, the Afghan government collapsed—but rather than ending their plans, this accelerated them.

“Lots of dreams shattered when the government fell,” recalls Hashimi, who by then had relocated to Vancouver, Canada. Like many Afghans in the diaspora, he had a deep “urge to do something.” And what he settled on, he says, was continuing to help in the way that he knew best: supporting Afghan coders. “People need hope,” he said—and since earlier events focused on tech or innovation provided it, he hoped that a coding boot camp would do the same.

Hashimi’s goal for the bootcamp is to “provide a more sustainable way for Afghan youth to learn new and market-driven skills,” he wrote in our initial email correspondence, and with those skills to “start earning an income for themselves and their families.”

For many of the bootcamp participants, all of whom share these goals, the potential for online work might be their only option. In 19-year-old Sherzoy’s family, only her father is currently employed—and what he makes is hardly enough to support her and her six siblings. After the bootcamp, she says, she hopes to “help my family and do something for my future.” She adds, “I do not want to be illiterate [uneducated].”

A Code Weekend participant works on an app at an event in 2018. Photo courtesy Code Weekend.

Thus far, however, most of the income opportunities are coming through Hashimi’s other efforts: in addition to Code Weekend, he also runs a software development company that employs or contracts with over 20 Afghan programmers, most of whom are still in Afghanistan, as well as an online freelancing platform, Yagan Kar (meaning “some work” in Dari), for Afghan freelancers.

It’s an adjustment to his original, pre-Taliban plans. Even after Hashimi left Afghanistan in 2016 for a master’s degree in the UK in innovation management, he used to spend three or four months in his home country every year, supporting the burgeoning tech community. “My dream,” he says, was “having the largest software house in Afghanistan.”

In a way, that’s still his goal. “I want to bring 1,000 jobs by 2023” from outside the country, he says, which “would help a lot of freelancers and youths and developers and also the economy.”

He says that “all Afghans want to leave,” but the reality is that the vast majority of them are ineligible for resettlement and evacuation efforts. They will remain in Afghanistan, and will need new sources of income. Hashimi sees the international tech community as a potential provider of that income, through both remote and freelance work.

But all of this will take time, and the country faces more urgent challenges.

No government has officially recognized the new regime, and as a result, the international community has frozen the country’s bank accounts as well as previously scheduled deliveries of aid money, putting its already precarious economy on the brink of collapse and much of its population at risk of starvation.

The economic challenge are exacerbated by violence, which has not stopped; the UN has documented a rise in extrajudicial reprisal killings against allies of the former government, while other violent extremist groups, like the local affiliate of the Islamic State, continue to terrorize civilians with suicide attacks.

If things finally stabilize, muses Asad Asadullah, the former computer science student and bootcamp participant, Afghan employers—including maybe even the Taliban government—could one day hire Afghan developers as well. After all, he says, the Taliban “know the importance of technology, at least at senior levels.”

With the bigger challenges facing Afghanistan, that day feels very far off—“maybe in three to four years,” Asadullah predicts.

But he is not waiting around to see. In the four days between our first interview and our last WhatsApp messages confirming details for this story, he and his family fled to Pakistan, joining the 2.6 million Afghans who live as refugees outside of their homeland.

Asadullah plans to stay in Pakistan until he can find an opportunity to go to Europe or the United States. In the meantime, he continues to order his day by when he can get online and code.

from MIT Technology Review https://ift.tt/3z97hDM via IFTTT

#MIT Technology Review

0 notes

mentalmars · 5 years ago

Photo

Past, Present, and Future of the ECHOcast - Borderlands 3 Interview

Who are you and what do you do? Hey there, my name is Scott Velasquez and I’m a programmer by trade. Most recently I was a lead programmer on Borderlands 2, Battleborn and then the Online and Social Product Owner for Borderlands 3. I will have been at Gearbox 19 years this August! How did you get started in the industry? Just after graduating with a Bachelor of Science from UAT in 2000, I landed a job at Cinematix Studios in Tempe, AZ. It was here where I finally earned the right to call myself a professional game developer working on two PS2 titles (Hirelings and Renegade Zero). I was responsible for the audio and input systems as well as the 3rd person camera systems. I was so excited working on the camera systems I had to call my college Calculus teacher and tell him I was applying the things he taught us, ha! Previously, I was big into modding Half-life, Quake and Duke Nukem 3D as well as working on my own personal projects. A friend and I wrote a Java 3D engine named Loco3D the moment 3D was added to Java. Our test data consisted of 3D models like Tie Fighters, buildings and etc. that we hand-built in a text file! Another friend and I wrote a C++ multiplayer checkers game which where we learned a lot about OpenGL and network programming at the Winsock level. In my spare time while at Cinematix I built a C++ game engine whose biggest feature at the time was being able to switch between Direct3D and OpenGL at run-time (something quite common to attempt at the time). I made my way to Gearbox after Cinematix failed to land a publisher for either PS2 game and had to close up shop. It’s been a great ride so far! I saw that you are the social product owner of Borderlands 3, what does that mean? Product Owner is a term typically associated with Agile development in a typical software company. I believe this is the first time we’ve used this role at Gearbox, but the intent was to capture the role of a person who could design and direct a group of developers to build new online and social features for BL3. I’m a generalist and customer-focused at heart so this ended up being a great fit in my mind. On any given day I could switch between the following roles: Programmer Designer Project Manager Business Strategy Customer Advocate Consumer of the Coffee Beans We drove the implementation of a number of features you are probably familiar with such as: Photo Mode Player Pinging Vault Hunter Profile on Roster UI Ask for Help Rare spawn sharing Dueling Lost loot Mail system Takedowns Twitch ECHOcast What was the inspiration for making the twitch extension? For years I was bothered watching Twitch hoping the streamer would open their scoreboard so I could see their stats in the competitive title they were streaming. Twitch visited us during Battleborn/early BL3 development and I urged them to consider building a product that allowed us to build interactions into the game to improve the quality of life for viewers and streamers. They must have heard this from other developers too as they officially announced extensions in 2017. Nobody outside of Gearbox/2K knows this, but I had actually created my Twitch developer account in 2013. We had a vision for Battleborn that included many things had the game taken off. One of which was integrated Twitch streaming and an extension. My Twitch developer account and grand ideas laid dormant until I got the nod from our Creative Director of BL3 to move forward. I asked around both the Frisco and Quebec studios to see if anybody had Twitch experience and got hooked up with my main man Michael Dube! As people joined the ECHOcast team they all offered ideas and feedback to help shape it was it is today. The objectives for the extension were to: Improve quality of life for streamers and viewers No more asking the streamer to show you their “gear/build/stats” Provide ways for streamer to foster their community and viewers a way to interact with their favorite streamer Raise the bar for video games streamed on Twitch Deliver new innovative and integrated experiences Partner with Twitch and streamers early Amplify BL3 milestones and reach new customers Earn loot before the game ships On-stream pre-order/purchase and continued updates alongside DLC and patches How does the extension “basically” work, how much planning and programming goes into it, does the game get shaped around these features or do you need to work within the parameters of the game itself? Great question. On the surface, it seems really straightforward, right? It is, but it isn’t! The extension is essentially a web app running on top of the Twitch video player. The game communicates with Twitch and our backend service running in the cloud to send data and events to the extension. The extension communicates with Twitch and our backend service when taking part in an event or linking your SHiFT account. You’re talking about three distinct areas of work consisting of three different languages (C++, Go, Javascript/HTML/CSS) and product deployments! All the while keeping into account that the game needs to run as if no extra work was added, the backend service has to handle Twitch scale and do so cost-effectively and the extension has to work on a variety of browsers and resolutions. Oh by the way, did you know that the ECHOcast extension actually runs on a Tesla? How freakin cool is that?! A lot of planning and programming went into developing the ECHOcast. We were really blazing trails for us at Gearbox and learned quite a lot along the way! We partnered with Twitch and a handful of streamers early so we could really good grasp on the technical challenges and what streamers thought about our designs. The ECHOcast was a huge team effort! For the initial release, no the game didn’t get shaped around ECHOcast. One reason was that it was unproven, but more importantly, it’s because we wanted the work put into ECHOcast to be able to happen anywhere in your Borderlands 3 adventure. In other words, we didn’t want a feature to only become available in a certain location otherwise the chances of us making an impact would have dropped tremendously. After the game launched and ECHOcast was out in the wild, people around the studio really started to take notice and they started stopping by talking to us about upcoming things where ECHOcast could be integrated. We have more big updates planned! I heard that my friend, lowlines, is helping out with the twitch extension. How did the team get established? He sure is helping! He was actually the first person I reached out to when I got the go-ahead to develop ECHOcast. We met through his Borderlands and Battleborn projects where he developed all kinds of cool stuff for the community. I’d like to think we’re pretty good friends at this point! Version 1 of the twitch extension was launched at the Borderlands 3 reveal event, how exciting was that and what did you learn from the process? First of all, it was great to finally meet you in person at the event! But man, as if revealing the game wasn’t enough we were like “let’s ship version 1 of ECHOcast and allow up to 200 streamers to stream it live AND earn rare chest loot!” That’s my kind of ambition! haha It was very exciting and very humbling to the team who almost all made it out to Los Angeles to witness first hand. The game and ECHOcast were received very well and our first trial run at scale was successful. We gathered a lot of feedback and telemetry from the reveal that allowed us to optimize the rare chest event and apply the lessons forward to the game’s release which included pinata and the badass event. Since the launch of the extension, you guys kept working on it. Version 2 added mobile compatible. What can we expect in the near future? (V3) There are some really cool and fun updates coming along and we’ll be talking about those very soon! Tune in to the next Borderlands Show on February 11 to learn more! You work with Rick, the owner of DIM, an item management tool for Destiny. Now that Borderlands 3’s inventory space has increased significantly, do think it’s possible to see an online item management tool? That’s right, Rick brought his expertise to help ECHOcast development as well. I would love to leverage more of Rick’s experience, but nothing to officially comment on at the moment. I think it is safe to say that we would like to continue pushing forward though! Like Lowlines, I think we all made a new friend in Rick as well. Thanks for the recommendation, Lowlines! I personally had a few ideas for the twitch extension: While ‘fight for your life’ mode is probably too short to interact with the community. But what if a streamer goes down a bunch of times and the community can help him/her get through it by providing a buff, like extended FFYL, health boosters, or shield boosters. I think this could also give the viewer a sense of accomplishment as they helped their favorite streamer achieving a tough goal. Ha, great minds think alike! It’s funny you should mention this was actually in our initial prototype by Mick aka Michael Dube, one of the badass game programmers helping with ECHOcast in our Quebec City studio. The ECHOcast team is world-wide! I wish I could tell you more but you’ll just have to wait and find out 😊 Would a Community Slaughter Fest work? When the streamer enters a dome, the viewers can decide which type of enemies each wave has. Streamer VS Viewers. Another great idea, we’re all on the same wavelength I think! We pitched this and I definitely think this could work. Given the schedule the game teams are working under it wasn’t something we could add in time and make sure not to break across the game. Definitely something I think we should keep in our back pocket for the future! Is there anything my readers should know that I haven’t asked you? Let’s see…well they probably already know how badass you are, so I don’t think that needs to be said I would just like to say thank you to everybody who purchased Borderlands 3 and checked out ECHOcast. We’re always open to feedback on anything we had a hand in so please feel free to tweet at me or whatever. Twitch just added a way for streamers to provide feedback about an extension so please consider using that for feedback too! PS. Send tacos, all the tacos! Do you have any advice for the folks that wanna get into the games industry? You bet! The very first step, before buying books, paying for an online course or signing up for college… Make sure you understand the high level of what it takes to make a video game. Specifically, what roles are responsible for what in the game and what skills are involved. Then think about what you’re passionate about when you take into consideration the roles learned above. Also, think about where you naturally excel…good with math? Art? etc. Once you narrow down the role you can begin to learn and practice. Build up a portfolio and record notes on what you learned and are most proud of with each personal project. Hack and build mods on existing games that offer SDKs or user-generated content. When you get to the point of interviewing, be yourself and allow your passion, experience, and ability to learn and work with others show. Don’t forget to ask your potential employer lots of questions too, you should be interviewing them as well! Good luck, I’ll be playing your games before you know it!

Continue reading on https://mentalmars.com/game-news/past-present-and-future-of-the-echocast-borderlands-3-interview/

#Borderlands 3 Interview #Borderlands 3 News

0 notes

siliconwebx · 6 years ago

Text

Simple & Boring

Simplicity is a funny adjective in web design and development. I'm sure it's a quoted goal for just about every project ever done. Nobody walks into a kickoff meeting like, "Hey team, design something complicated for me. Oh, and make sure the implementation is convoluted as well. Over-engineer that sucker, would ya?"

Of course they want simple. Everybody wants simple. We want simple designs (because simple means our customers will understand it and like it). And we want simplicity in development. Nobody dreams of going to work to spend all day wrapping their head around a complex system to fix one bug.

Still, there is plenty to talk about when it comes to simplicity. It would be very hard to argue that web development has gotten simpler over the years. As such, the word has lately been on the tongues of many web designers and developers. Let's take a meandering waltz through what other people have to say about simplicity.

Bridget Stewart recalls a frustrating battle against over-engineering in "A Simpler Web: I Concur." After being hired as an expert in UI implementation and given the task of getting a video to play on a click...

I looked under the hood and got lost in all the looping functions and the variables and couldn't figure out what the code was supposed to do. I couldn't find any HTML <video> being referenced. I couldn't see where a link or a button might be generated. I was lost.

I asked him to explain what the functions were doing so I could help figure out what could be the cause, because the browser can play video without much prodding. Instead of successfully getting me to understand what he had built, he argued with me about whether or not it was even possible to do. I tried, at first calmly, to explain to him I had done it many times before in my previous job, so I was absolutely certain it could be done. As he continued to refuse my explanation, things got heated. When I was done yelling at him (not the most professional way to conduct myself, I know), I returned to my work area and fired up a branch of the repo to implement it. 20 minutes later, I had it working.

It sounds like the main problem here is that the dude was a territorial dingus, but also his complicated approach literally stood in the way of getting work done.

Simplicity on the web often times means letting the browser do things for us. How many times have you seen a complex re-engineering of a select menu not be as usable or accessible as a <select>?

Jemery Wagner writes in Make it Boring:

Eminently usable designs and architectures result when simplicity is the default. It's why unadorned HTML works. It beautifully solves the problem of presenting documents to the screen that we don't even consider all the careful thought that went into the user agent stylesheets that provide its utterly boring presentation. We can take a lesson from this, especially during a time when more websites are consumed as web apps, and make them more resilient by adhering to semantics and native web technologies.

My guess is the rise of static site generators — and sites that find a way to get as much server-rendered as possible — is a symptom of the industry yearning for that brand of resilience.

Do less, as they say. Lyza Danger Gardner found a lot of value in this in her own job:

... we need to try to do as little as possible when we build the future web.

This isn’t a rationalization for laziness or shirking responsibility—those characteristics are arguably not ones you’d find in successful web devs. Nor it is a suggestion that we build bland, homogeneous sites and apps that sacrifice all nuance or spark to the Greater Good of total compatibility.

Instead it is an appeal for simplicity and elegance: putting commonality first, approaching differentiation carefully, and advocating for consistency in the creation and application of web standards.

Christopher T. Miller writes in "A Simpler Web":

Should we find our way to something simpler, something more accessible?

I think we can. By simplifying our sites we achieve greater reach, better performance, and more reliable conveying of the information which is at the core of any website. I think we are seeing this in the uptick of passionate conversations around user experience, but it cannot stop with the UX team. Developers need to take ownership for the complexity they add to the Web.

It's good to remember that the complexity we layer onto building websites is opt-in. We often do it for good reason, but it's possible not to. Garrett Dimon:

You can build a robust, reliable, and fully responsive web application today using only semantic HTML on the front-end. No images. No CSS. No JavaScript. It’s entirely possible. It will work in every modern browser. It will be straightforward to maintain. It may not fit the standard definition of beauty as far as web experiences go, but it will work. In many cases, it will be more usable and accessible than those built with modern front-end frameworks.

That’s not to say that this is the best approach, but it’s a good reminder that the web works by default without all of our additional layers. When we add those additional layers, things break. Or, if we neglect good markup and CSS to begin with, we start out with something that’s already broken and then spend time trying to make it work again.

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process, we create another layer of complexity that, in turn, causes its own set of issues.

— Max Böck, "On Simplicity"

Perhaps the worst reason to choose a complex solution is that it's new, and the newness makes it feel like choosing it makes you on top of technology and doing your job well. Old and boring may just what you need to do your job well.

Dan McKinley writes:

“Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

Rachel Andrew wrote that choosing established technology for the CMS she builds was a no-brainer because it's what her customers had.

You're going to hear less about old and boring technology. If you're consuming a healthy diet of tech news, you probably won't read many blog posts about old and boring technology. It's too bad really, I, for one, would enjoy that. But I get it, publications need to have fresh writing and writers are less excited about topics that have been well-trod over decades.

As David DeSandro says, "New tech gets chatter". When there is little to say, you just don't say it.

You don't hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

While we hear more about new tech, it's old tech that is more well known, including what it's bad at. If newer tech, perhaps more complicated tech, is needed because it solves a known pain point, that's great, but when it doesn't...

You are perfectly okay to stick with what works for you. The more you use something, the clearer its pain points become. Try new technologies when you're ready to address those pain points. Don't feel obligated to change your workflow because of chatter. New tech gets chatter, but that doesn't make it any better.

Adam Silver says that a boring developer is full of questions:

"Will debugging code be more difficult?", "Might performance degrade?" and "Will I be slowed down due to compile times?"

Dan Kim is also proud of being boring:

I have a confession to make — I’m not a rock star programmer. Nor am I a hacker. I don’t know ninjutsu. Nobody has ever called me a wizard.

Still, I take pride in the fact that I’m a good, solid programmer.

Complexity isn't an enemy. Complexity is valuable. If what we work on had no complexity, it would worth far less, as there would be nothing slowing down the competition. Our job is complexity. Or rather, our job is managing the level of complexity so it's valuable while still manageable.

Santi Metz has a great article digging into various aspects of this, part of which is about considering how much complicated code needs to change:

We abhor complication, but if the code never changes, it's not costing us money.

Your CMS might be extremely complicated under the hood, but if you never touch that, who cares. But if your CMS limits what you're able to do, and you spend a lot of time fighting it, that complexity matters a lot.

It's satisfying to read Sandi's analysis that it's possible to predict where code breaks, and those points are defined by complexity. "Outlier classes" (parts of a code base that cause the most problems) can be identified without even seeing the code base:

I'm not familiar with the source code for these apps, but sight unseen I feel confident making a few predictions about the outlying classes. I suspect that they:

are larger than most other classes,

are laden with conditionals, and

represent core concepts in the domain

I feel seen.

Boring is in it for the long haul.

Cap Watkins writes in "The Boring Designer":

The boring designer is trusted and valued because people know they’re in it for the product and the user. The boring designer asks questions and leans on others’ experience and expertise, creating even more trust over time. They rarely assume they know the answer.

The boring designer is capable of being one of the best leaders a team can have.

So be great. Be boring.

Be boring!

The post Simple & Boring appeared first on CSS-Tricks.

😉SiliconWebX | 🌐CSS-Tricks

#Silicon Web Design #Ahmedabad #India #Web Development #WPBeginner #Silicon URL #Web Site #Cloud Host

0 notes

banana-flavored-oatmeal · 5 years ago

Text

Want to learn web development but don’t know where to start?

So, You’re interested in learning web development and becoming a web developer? First of all, congratulations. You’ve made a great choice.

One thing I want to stress before signing off on this. You don’t need to be a HTML and CSS expert before you can start building things. You don’t have to spend months and months doing tutorial after tutorial. Don’t get stuck in the coding tutorial rut. Once you have the fundamentals down, you can learn as you build.

Depending on your background, you might be wondering where to start learning web development. If you’ve mainly been Googling around, you may feel just a bit overwhelmed by all the languages, frameworks, and learning resources out there. Well, don’t worry. You’re not alone. Google can be your best friend or your worst enemy. It just depends on how you use it.

In this blog I will not only share links to useful websites that offers free tutorials to learn about HTML, CSS and JavaScript, but also show some of my humble HTML projects and many more.

0 notes

adamstuckerma · 8 years ago

Text

How to Beat Google’s Mobile Page Speed Benchmarks – Search Engine Journal

Brad Smith

5.5K

READS

Google recently unveiled mobile page speed industry benchmarks and analyzed customer behavior to figure out how the two lined up.

Unfortunately, they didn’t.

Meaning:

Most mobile websites are slooooooooooow.

Consumers won’t wait longer than a few seconds.

That’s a problem. It means the vast majority of mobile websites are losing money, practically forcing customers to bounce and go somewhere else.

Here’s why that’s happening and what you should do about it.

Slow Page Load Speed Sabotages Your Revenue

The probability of someone bouncing from your site increases by 113 percent if it takes seven seconds to load, according to Google’s mobile page speed industry benchmarks, which were released in February.

The problem?

The average time it takes to fully load a mobile landing page is 22 seconds, according to the same report.

That’s not good. In fact, it’s awful because that trickle down effect hits your bottom line, too. Slower sites cause more bounces which then lowers conversions:

“Similarly, as the number of elements—text, titles, images—on a page goes from 400 to 6,000, the probability of conversion drops 95 percent.”

This is nothing new. Slow page speeds have long been public enemy number one for years. Over a decade ago, then-Googler Marissa Mayer confirmed that Google themselves saw a 20 percent drop in traffic with just a 0.5-second delay.

Mobile-first indexation is coming, and speed is the mobile SEO Achilles Heel. E-commerce brands lose half of their traffic if pages take three seconds or longer, which has motivated some to get up-and-running in less than a second.

The primary reason for slow loads? In a word: bloat.

Too much. The way you feel after a Thanksgiving feast.

Google’s latest industry benchmark report analyzed more than 900,000 mobile ads from 126 countries (so sample size apparently ain’t a problem). Seventy percent of pages were over 1MB and “1.49MB takes 7 seconds to load using a fast 3G connection” (which brings things back to seven seconds and the 113 percent increase in likelihood to bounce).

The solution isn’t easy. You’re not gonna like it.

In fact, you might be tempted by a shortcut. It might seem easier initially to use a mobile-friendly alternative like AMP or Facebook Instant Articles.

But that would be a mistake.

Here’s why.

The Problem With AMP & Instant Articles

The Accelerated Mobile Pages Project (AMP) is a self-described “open-source initiative” with the lofty ideal to make the web faster.

Companies who use their technology can see mobile pages load “nearly instantaneously.” It does that by minimizing the amount of resources required through optimizing and compressing notoriously ginormous files like your images.

The ideals are lofty and ambitious. And the results are admittedly good.

Wired Magazine is just one of many huge publishers to reveal glowing highlights, with a 25 percent increase in click-through rates from search results. Gizmodo’s AMP traffic is 80 percent new visitors (presumably coming via search).

Why does AMP perform so well? You don’t need Benedict Cumberbatch for that one. It’s a Google-backed project. So AMP pages tend to get, how should we say, prime mobile SERP placement.

That’s a good thing. But there are a few drawbacks.

AMP is technically more difficult to implement, for starters. Jan Dawson argues that it’s effectively making it harder to publish on the web, writing:

“Technically, these formats use standards-based elements — for example, AMP is a combination of custom HTML, custom JavaScript and caching. But the point here is the outputs from traditional online publishing platforms aren’t compatible with any of these three formats. And in order to publish to these formats directly, you need to know a lot more code than I ever did back in the mid-1990s before the first round of WYSIWYG tools for the web emerged.”

Fortunately, things are slightly easier for WordPress sites. Here’s a three-step guide to setting up AMP on a WordPress site.

There are other problems, though. Losing your branding on AMP pages is one thing. Not good but not a deal killer necessarily. Losing your mobile traffic to Google is quite another, and it’s also the crux of the issue.

AMP content isn’t technically yours anymore. This can impact things like ad revenue, where results are mixed, as seen in the following tweets from Marie Haynes that caught my eye a few months back:

Facebook’s Instant Articles work largely the same way as AMP. Similar pros and cons, too.

Pages load on super speed on the plus side, reportedly up to 10x quicker. Early results from Facebook Partners also showed a 70 percent decrease in Instant Article abandonment (with a 20 percent CTR to boot).

But the same proprietary infrastructure problems have caused many media conglomerates to hit the Pause button. According to analysis from NewsWhip and Digiday, several notable companies have pulled back on Facebook Instant Articles in the last year or so:

Boston Globe went from an incredible 100 percent to 0 percent

Business Insider posted 10 percent and now barely posts 2 percent

The New York Times has dropped to 10 percent

The Atlantic went from posting 85 percent to now only around 10 percent

Other early adopters like the BBC News, National Geographic, and The Wall Street Journal are now “barely using the platform”

Now, this isn’t a Chicken Little, “sky is falling” kinda thing. But it is a cause for concern.

Mobile-friendly platforms offer a tremendous shortcut in boosting mobile page speed. However, there are very serious drawbacks, too, like band-aids on broken arms.

A more prudent approach is to roll up your sleeves, take the long view, and fix your site from the ground-up.

Here’s how to do it.

How to Diagnose Slow Mobile Page Speed

Test My Site is the new version of Google’s old PageSpeed tool (complete with the latest and greatest, 2017 OC Housewives-style facelift).

So start there.

Point and click. This page should pop up next.

Just plug in your URL and hit Test Now.

First, you’ll see the Mobile Friendliness score. Then in the middle is the mobile speed score in question.

Ruh roh.

Let’s scroll down a bit to find out more details on that near-failing grade.

Click on that little box to bring up a detailed assessment of where your site is doing well, along with those areas that aren’t doing so well.

Google mercifully goes into the details of which individual elements are causing you the biggest problems.

Here’s another view of this mobile page speed assessment on a mobile device. Because… why not? Everyone loves a good meta joke.

OK. So the result ain’t pretty. That’s fine. Because now we know what to fix.

The next step is to dive into some of these new mobile page speed industry benchmarks and figure out how to increase them.

Buckle up. It’s about to get geeky.

How to Beat 3 Google Mobile Page Speed Benchmarks

1. Reduce Your Average Request Count

Google’s Best Practice: Fewer Than 50

Requests are literal. Someone tries to visit your website and their browser requests information from your server. The data is compiled and sent back.

The more requests, the longer it takes. Reduce the number of requests that need to be sent back-and-forth and you can greatly reduce average page loading times across the board.

First, reduce the number of files that need to be sent. Yoast cites JavaScript, CSS, and images as your three primary problems.

Minifying JavaScript and CSS kills two birds with one stone. It reduces the number of files that need to be sent back-and-forth. It reduces the overall file size, too.

The GIDNetwork will help you run a compression audit.

Gzip will turn website files into zip files for easier transfers.

WP Super Minify is a WordPress plugin that will do a lot of heavy lifting for you.

Otherwise, Yahoo’s YUI Compressor can help tackle both CSS and JavaScript compression.

Contemporary web design is 90 percent image-driven. I just made up that stat. But you get the point. Today’s websites look like hollow shells if you remove the beautiful, retina-ready images that stretch across your screen.

The problem is that images (if not handled properly) will kill loading times. Once again, Yoast recommends using CSS sprites to combine multiple images into one. SpriteMe, for example, will take background images and combine them to decrease the total number of individual images.

Content Delivery Networks (CDNs) can also help you recoup bandwidth and cut down on website requests. They host large image files for you and distribute them across their own global network of servers. MaxCDN and CloudFlare are among the most popular.

Last but certainly not least, reduce redirects you use if possible. Redirects create additional requests. So proceed with caution.

2. Decrease Average Page Weight

Google’s Best Practice: Less Than 500KB

Seventy-eight percent of shoppers want more product images, according to the Omni Channel Retail report from BigCommerce.

The problem, as we just discussed, is that images can cripple page loads. They create more requests for servers. But they put your average page weight on a bulking plan that would make those meathead bodybuilders at your gym rage with envy.

Page size should be less than 500KB according to Google. And yet a single, unoptimized, high-res image already clocks in at around 1 or 2 MB.

You could start by simply cropping the sizes of your images so each is the exact width and height for the space it’s being used. Except, of course, nobody ever does that. Manually. Every single time they upload an image.

So instead, let’s start by compressing the image file itself with something like WP Smush.it. A non-WordPress tool like Compressor.io can also reduce an image by up to 73 percent.

Let’s run a quick scenario:

Average e-commerce website conversions hover around 1-3 percent.

That number can rise as high as 5 percent. (One example, Natomounts, sees 5 percent conversion rates with ~85 percent from mobile!)

We just discovered that shoppers want more product images.

And yet, according to Radware, 45 percent of the top 100 e-commerce sites don’t compress images!

3. Decrease Average Time to First Byte

Google’s Best Practice: Under 1.3 seconds

Time to first byte (TTFB) is a measurement that shows how long a browser has to wait before receiving its first byte of data from the server.

It’s essentially a three-step process:

A visitor sends an HTTP request to your server.

Your server has to figure out how to respond. This includes gathering the data required and organizing it to be sent back.

Assuming all goes well, the request is sent back to the visitor.

TTFB is the time it takes for that complete cycle to finish.

We’ve already covered a few potential roadblocks during this journey. Too many requests, too many redirects, too many junky WordPress plugins, etc. all take its toll. A website visitor’s own network connection and speed also make an impact.

The aforementioned CDNs also help by reducing your server’s workload. They take over the burden of delivering large files so your own server can focus on delivering the rest of your site’s files and content. The best CDNs even go the extra mile. For example, reducing the physical location between the person requesting a file and the server sending it can have a huge impact.

Caching reduces TTFB by helping web browsers store your website data. Best of all, it only takes a simple plugin (like W3 Total Cache) or using a premium web host that will set up caching for you at the server-level (so no additional tools or plugins are needed).

A web host is like your server’s foundation. You can optimize images all you’d like. Use the best CDN on the market. But if you’re using slow shared hosting that splits resources, your site is going to be slow no matter how many tricks or tips or hacks you use.

Last but not least, a little sleight of hand.

Technically, removing JavaScript files from the head section and relocating them lower on an HTML document won’t reduce the overall number of requests or reduce file sizes. But it will help the important stuff — like the words on each page — to load a little quicker.

JavaScript is selfish. It wants to load all of its code before allowing anything else on the page to have a turn. Pushing it further down forces it to wait its turn until after a few images and basic content can pop up first.

Lazy loading is another common technique that won’t load (or display) an image until it’s within view. That way, page content can be loaded first. That’s helpful on long pages with tons of images (like this blog post). WPMU has a list of six lazy-loading WordPress plugins to try out.

Conclusion

Google has helpfully provided a few mobile page speed benchmarks to shoot for based on their in-depth analysis of what customers want. Unfortunately, the vast majority of websites are nowhere close to them.

Slow mobile page speed has been shown to cause users to bounce, which affects where you show up in search results, and ultimately what your website is able to generate in revenue.

Start by reducing the number of requests that happen each time someone visits your site. Then reduce file sizes along with average time to first byte.

It’ll take some heavy lifting. Definitely some dev help. But it’s your only shot at rescuing sub-par performance that’s sabotaging your bottom line.

Image Credits

Featured Image: Templune/Pixabay.com

In-Post Photo: Google.com

In-Post Photo: Facebook.com

Screenshots by Brad Smith. April 2017.

https://www.searchenginejournal.com/mobile-page-speed-benchmarks/194511/

On – 24 Apr, 2017 By Brad Smith

source https://andlocal.org/how-to-beat-googles-mobile-page-speed-benchmarks-search-engine-journal/ from ANDLOCAL http://andlocal.blogspot.com/2017/05/how-to-beat-googles-mobile-page-speed.html

0 notes

lucasparkerco · 8 years ago

Text

How to Beat Google’s Mobile Page Speed Benchmarks – Search Engine Journal

Brad Smith

5.5K

READS

Google recently unveiled mobile page speed industry benchmarks and analyzed customer behavior to figure out how the two lined up.

Unfortunately, they didn’t.

Meaning:

Most mobile websites are slooooooooooow.

Consumers won’t wait longer than a few seconds.

That’s a problem. It means the vast majority of mobile websites are losing money, practically forcing customers to bounce and go somewhere else.

Here’s why that’s happening and what you should do about it.

Slow Page Load Speed Sabotages Your Revenue

The problem?

The average time it takes to fully load a mobile landing page is 22 seconds, according to the same report.

That’s not good. In fact, it’s awful because that trickle down effect hits your bottom line, too. Slower sites cause more bounces which then lowers conversions:

“Similarly, as the number of elements—text, titles, images—on a page goes from 400 to 6,000, the probability of conversion drops 95 percent.”

The primary reason for slow loads? In a word: bloat.

Too much. The way you feel after a Thanksgiving feast.

The solution isn’t easy. You’re not gonna like it.

In fact, you might be tempted by a shortcut. It might seem easier initially to use a mobile-friendly alternative like AMP or Facebook Instant Articles.

But that would be a mistake.

Here’s why.

The Problem With AMP & Instant Articles

The Accelerated Mobile Pages Project (AMP) is a self-described “open-source initiative” with the lofty ideal to make the web faster.

The ideals are lofty and ambitious. And the results are admittedly good.

Why does AMP perform so well? You don’t need Benedict Cumberbatch for that one. It’s a Google-backed project. So AMP pages tend to get, how should we say, prime mobile SERP placement.

That’s a good thing. But there are a few drawbacks.

AMP is technically more difficult to implement, for starters. Jan Dawson argues that it’s effectively making it harder to publish on the web, writing:

Fortunately, things are slightly easier for WordPress sites. Here’s a three-step guide to setting up AMP on a WordPress site.

AMP content isn’t technically yours anymore. This can impact things like ad revenue, where results are mixed, as seen in the following tweets from Marie Haynes that caught my eye a few months back:

Facebook’s Instant Articles work largely the same way as AMP. Similar pros and cons, too.

Boston Globe went from an incredible 100 percent to 0 percent

Business Insider posted 10 percent and now barely posts 2 percent

The New York Times has dropped to 10 percent

The Atlantic went from posting 85 percent to now only around 10 percent

Other early adopters like the BBC News, National Geographic, and The Wall Street Journal are now “barely using the platform”

Now, this isn’t a Chicken Little, “sky is falling” kinda thing. But it is a cause for concern.

Mobile-friendly platforms offer a tremendous shortcut in boosting mobile page speed. However, there are very serious drawbacks, too, like band-aids on broken arms.

A more prudent approach is to roll up your sleeves, take the long view, and fix your site from the ground-up.

Here’s how to do it.

How to Diagnose Slow Mobile Page Speed

Test My Site is the new version of Google’s old PageSpeed tool (complete with the latest and greatest, 2017 OC Housewives-style facelift).

So start there.

Point and click. This page should pop up next.

Just plug in your URL and hit Test Now.

First, you’ll see the Mobile Friendliness score. Then in the middle is the mobile speed score in question.

Ruh roh.

Let’s scroll down a bit to find out more details on that near-failing grade.

Click on that little box to bring up a detailed assessment of where your site is doing well, along with those areas that aren’t doing so well.

Google mercifully goes into the details of which individual elements are causing you the biggest problems.

Here’s another view of this mobile page speed assessment on a mobile device. Because… why not? Everyone loves a good meta joke.

OK. So the result ain’t pretty. That’s fine. Because now we know what to fix.

The next step is to dive into some of these new mobile page speed industry benchmarks and figure out how to increase them.

Buckle up. It’s about to get geeky.

How to Beat 3 Google Mobile Page Speed Benchmarks

1. Reduce Your Average Request Count

Google’s Best Practice: Fewer Than 50

Requests are literal. Someone tries to visit your website and their browser requests information from your server. The data is compiled and sent back.

The more requests, the longer it takes. Reduce the number of requests that need to be sent back-and-forth and you can greatly reduce average page loading times across the board.

First, reduce the number of files that need to be sent. Yoast cites JavaScript, CSS, and images as your three primary problems.

Minifying JavaScript and CSS kills two birds with one stone. It reduces the number of files that need to be sent back-and-forth. It reduces the overall file size, too.

The GIDNetwork will help you run a compression audit.

Gzip will turn website files into zip files for easier transfers.

WP Super Minify is a WordPress plugin that will do a lot of heavy lifting for you.

Otherwise, Yahoo’s YUI Compressor can help tackle both CSS and JavaScript compression.

Last but certainly not least, reduce redirects you use if possible. Redirects create additional requests. So proceed with caution.

2. Decrease Average Page Weight

Google’s Best Practice: Less Than 500KB

Seventy-eight percent of shoppers want more product images, according to the Omni Channel Retail report from BigCommerce.

Page size should be less than 500KB according to Google. And yet a single, unoptimized, high-res image already clocks in at around 1 or 2 MB.

So instead, let’s start by compressing the image file itself with something like WP Smush.it. A non-WordPress tool like Compressor.io can also reduce an image by up to 73 percent.

Let’s run a quick scenario:

Average e-commerce website conversions hover around 1-3 percent.

That number can rise as high as 5 percent. (One example, Natomounts, sees 5 percent conversion rates with ~85 percent from mobile!)

We just discovered that shoppers want more product images.

And yet, according to Radware, 45 percent of the top 100 e-commerce sites don’t compress images!

3. Decrease Average Time to First Byte

Google’s Best Practice: Under 1.3 seconds

Time to first byte (TTFB) is a measurement that shows how long a browser has to wait before receiving its first byte of data from the server.

It’s essentially a three-step process:

A visitor sends an HTTP request to your server.

Your server has to figure out how to respond. This includes gathering the data required and organizing it to be sent back.

Assuming all goes well, the request is sent back to the visitor.

TTFB is the time it takes for that complete cycle to finish.

Last but not least, a little sleight of hand.

Conclusion

Slow mobile page speed has been shown to cause users to bounce, which affects where you show up in search results, and ultimately what your website is able to generate in revenue.

Start by reducing the number of requests that happen each time someone visits your site. Then reduce file sizes along with average time to first byte.

It’ll take some heavy lifting. Definitely some dev help. But it’s your only shot at rescuing sub-par performance that’s sabotaging your bottom line.

Image Credits

Featured Image: Templune/Pixabay.com

In-Post Photo: Google.com

In-Post Photo: Facebook.com

Screenshots by Brad Smith. April 2017.

https://www.searchenginejournal.com/mobile-page-speed-benchmarks/194511/

On – 24 Apr, 2017 By Brad Smith

from ANDLOCAL SEO Services https://andlocal.org/how-to-beat-googles-mobile-page-speed-benchmarks-search-engine-journal/ from ANDLOCAL https://andlocalorg.tumblr.com/post/160371326886

0 notes

andlocalorg · 8 years ago

Text

How to Beat Google’s Mobile Page Speed Benchmarks – Search Engine Journal

Brad Smith

5.5K

READS

Google recently unveiled mobile page speed industry benchmarks and analyzed customer behavior to figure out how the two lined up.

Unfortunately, they didn’t.

Meaning:

Most mobile websites are slooooooooooow.

Consumers won’t wait longer than a few seconds.

That’s a problem. It means the vast majority of mobile websites are losing money, practically forcing customers to bounce and go somewhere else.

Here’s why that’s happening and what you should do about it.

Slow Page Load Speed Sabotages Your Revenue

The problem?

The average time it takes to fully load a mobile landing page is 22 seconds, according to the same report.

That’s not good. In fact, it’s awful because that trickle down effect hits your bottom line, too. Slower sites cause more bounces which then lowers conversions:

“Similarly, as the number of elements—text, titles, images—on a page goes from 400 to 6,000, the probability of conversion drops 95 percent.”

The primary reason for slow loads? In a word: bloat.

Too much. The way you feel after a Thanksgiving feast.

The solution isn’t easy. You’re not gonna like it.

In fact, you might be tempted by a shortcut. It might seem easier initially to use a mobile-friendly alternative like AMP or Facebook Instant Articles.

But that would be a mistake.

Here’s why.

The Problem With AMP & Instant Articles

The Accelerated Mobile Pages Project (AMP) is a self-described “open-source initiative” with the lofty ideal to make the web faster.

The ideals are lofty and ambitious. And the results are admittedly good.

Why does AMP perform so well? You don’t need Benedict Cumberbatch for that one. It’s a Google-backed project. So AMP pages tend to get, how should we say, prime mobile SERP placement.

That’s a good thing. But there are a few drawbacks.

AMP is technically more difficult to implement, for starters. Jan Dawson argues that it’s effectively making it harder to publish on the web, writing:

Fortunately, things are slightly easier for WordPress sites. Here’s a three-step guide to setting up AMP on a WordPress site.

AMP content isn’t technically yours anymore. This can impact things like ad revenue, where results are mixed, as seen in the following tweets from Marie Haynes that caught my eye a few months back:

Facebook’s Instant Articles work largely the same way as AMP. Similar pros and cons, too.

Boston Globe went from an incredible 100 percent to 0 percent

Business Insider posted 10 percent and now barely posts 2 percent

The New York Times has dropped to 10 percent

The Atlantic went from posting 85 percent to now only around 10 percent

Other early adopters like the BBC News, National Geographic, and The Wall Street Journal are now “barely using the platform”

Now, this isn’t a Chicken Little, “sky is falling” kinda thing. But it is a cause for concern.

Mobile-friendly platforms offer a tremendous shortcut in boosting mobile page speed. However, there are very serious drawbacks, too, like band-aids on broken arms.

A more prudent approach is to roll up your sleeves, take the long view, and fix your site from the ground-up.

Here’s how to do it.

How to Diagnose Slow Mobile Page Speed

Test My Site is the new version of Google’s old PageSpeed tool (complete with the latest and greatest, 2017 OC Housewives-style facelift).

So start there.

Point and click. This page should pop up next.

Just plug in your URL and hit Test Now.

First, you’ll see the Mobile Friendliness score. Then in the middle is the mobile speed score in question.

Ruh roh.

Let’s scroll down a bit to find out more details on that near-failing grade.

Click on that little box to bring up a detailed assessment of where your site is doing well, along with those areas that aren’t doing so well.

Google mercifully goes into the details of which individual elements are causing you the biggest problems.

Here’s another view of this mobile page speed assessment on a mobile device. Because… why not? Everyone loves a good meta joke.

OK. So the result ain’t pretty. That’s fine. Because now we know what to fix.

The next step is to dive into some of these new mobile page speed industry benchmarks and figure out how to increase them.

Buckle up. It’s about to get geeky.

How to Beat 3 Google Mobile Page Speed Benchmarks

1. Reduce Your Average Request Count

Google’s Best Practice: Fewer Than 50

Requests are literal. Someone tries to visit your website and their browser requests information from your server. The data is compiled and sent back.

The more requests, the longer it takes. Reduce the number of requests that need to be sent back-and-forth and you can greatly reduce average page loading times across the board.

First, reduce the number of files that need to be sent. Yoast cites JavaScript, CSS, and images as your three primary problems.

Minifying JavaScript and CSS kills two birds with one stone. It reduces the number of files that need to be sent back-and-forth. It reduces the overall file size, too.

The GIDNetwork will help you run a compression audit.

Gzip will turn website files into zip files for easier transfers.

WP Super Minify is a WordPress plugin that will do a lot of heavy lifting for you.

Otherwise, Yahoo’s YUI Compressor can help tackle both CSS and JavaScript compression.

Last but certainly not least, reduce redirects you use if possible. Redirects create additional requests. So proceed with caution.

2. Decrease Average Page Weight

Google’s Best Practice: Less Than 500KB

Seventy-eight percent of shoppers want more product images, according to the Omni Channel Retail report from BigCommerce.

Page size should be less than 500KB according to Google. And yet a single, unoptimized, high-res image already clocks in at around 1 or 2 MB.

So instead, let’s start by compressing the image file itself with something like WP Smush.it. A non-WordPress tool like Compressor.io can also reduce an image by up to 73 percent.

Let’s run a quick scenario:

Average e-commerce website conversions hover around 1-3 percent.

That number can rise as high as 5 percent. (One example, Natomounts, sees 5 percent conversion rates with ~85 percent from mobile!)

We just discovered that shoppers want more product images.

And yet, according to Radware, 45 percent of the top 100 e-commerce sites don’t compress images!

3. Decrease Average Time to First Byte

Google’s Best Practice: Under 1.3 seconds

Time to first byte (TTFB) is a measurement that shows how long a browser has to wait before receiving its first byte of data from the server.

It’s essentially a three-step process:

A visitor sends an HTTP request to your server.

Your server has to figure out how to respond. This includes gathering the data required and organizing it to be sent back.

Assuming all goes well, the request is sent back to the visitor.

TTFB is the time it takes for that complete cycle to finish.

Last but not least, a little sleight of hand.

Conclusion

Slow mobile page speed has been shown to cause users to bounce, which affects where you show up in search results, and ultimately what your website is able to generate in revenue.

Start by reducing the number of requests that happen each time someone visits your site. Then reduce file sizes along with average time to first byte.

It’ll take some heavy lifting. Definitely some dev help. But it’s your only shot at rescuing sub-par performance that’s sabotaging your bottom line.

Image Credits

Featured Image: Templune/Pixabay.com

In-Post Photo: Google.com

In-Post Photo: Facebook.com

Screenshots by Brad Smith. April 2017.

https://www.searchenginejournal.com/mobile-page-speed-benchmarks/194511/

On – 24 Apr, 2017 By Brad Smith

from ANDLOCAL SEO Services https://andlocal.org/how-to-beat-googles-mobile-page-speed-benchmarks-search-engine-journal/

0 notes

t-baba · 8 years ago

Photo

Writing JavaScript with Accessibility in Mind

Tips on how to improve the accessibility of your JavaScript components and provide users with more and better ways to interact with your website or web app.

This article was originally published on Medium.

In my first post Writing HTML with accessibility in mind I explained why and how I got started with web accessibility. I also shared some tips on how you can improve your markup in order to make your websites more accessible. Some of these were pretty basic but nevertheless valuable. It all boils down to two of the most important unwritten rules in front-end development: Learn the basics and take enough time to plan and write HTML. Both you and your users will benefit from clean and semantic markup.

Luckily, HTML is not the only language we have to make websites, but the more complex the language, the easier things can go wrong and JavaScript can get very complex. Whilst being content that our code works, it's easy to forget about users with other input devices than a mouse or touch pad, e.g. keyboard or screen reader users. In this second article of four about web accessibility I have gathered some tips on what to consider when writing JavaScript and how to make your JavaScript components more accessible.

JavaScript Is Not the Enemy

Before you read my tips I want to point out one important thing — making an accessible site doesn't mean that you have to decide whether to use JavaScript or not. Accessibility is about making content available to as many people as possible, which also includes users with old browsers and computers, slow internet connections, strict security restrictions (e.g. no JavaScript) and so on. The experience under conditions like these, where JavaScript may not work or take too long to load, might not be ideal but is still good enough if the website is accessible and usable.

If JavaScript is executable it can even be used to improve accessibility. Sara Soueidan has written about her experiences creating a tooltip widget in Building a fully-accessible help tooltip… is harder than I thought. She explains how "every single no-JS solution came with a very bad downside that negatively affected the user experience" and why JavaScript is important for accessibility.

Marco Zehe wrote a lot more about JavaScript and accessibility in his article JavaScript is not an enemy of accessibility! I highly suggest you read his post.

But enough with the introductory talk! Let's get to it ...

Great Focus Management Is Essential

It's important to make sure that our websites are navigable by keyboard. A lot of users rely on a keyboard when they surf the web. Among them are people with motor disabilities, blind people and people who don't have hands or cannot use a mouse or track pad for whatever reason.

Navigating a site via keyboard means jumping from one focusable element to another in DOM order. This is usually accomplished by using Tab key or Shift + Tab for the reverse direction. Focusable elements are amongst others links, buttons and form elements. They can be selected with the Enter key and sometimes the Spacebar. By being focusable and selectable in different ways they come with very useful default functionalities. Therefore it just makes sense to use correct semantic elements and write HTML in a logical order.

Elements like <p>, <h2> or <div> cannot be focused by default. We often use tags like these to create custom components powered by JavaScript, which might be problematic for keyboard users.

Making non-focusable elements focusable

It's possible to make non-focusable elements focusable by adding the tabindex attribute with an integer value. If the value is set to 0 the element becomes focusable and reachable via keyboard. If the value is a negative number, the element is programatically focusable (e.g. with JavaScript), but not reachable via keyboard. You can also use a value greater than 0, but that changes the natural tab order and is considered an anti-pattern.

<h2 tabindex="0">A focusable heading</h2>

If you want to learn more about tabindex, watch the A11ycasts episode Controlling focus with tabindex by Rob Dodson.

Focusing elements with JavaScript

Even if elements are focusable, sometimes they are not in the right DOM order. To illustrate that I created a simple modal window component in HTML, CSS and JS (demo and editable Pen).

Continue reading %Writing JavaScript with Accessibility in Mind%

by Manuel Matuzovic via SitePoint http://ift.tt/2nsVnC9

#CSS3 #HTML5 Branding #HTML5 Weekly #HTMLl5 demos #Javascript Branding #Javascript Weekly #Mobile #Mo

0 notes

lesterwilliams1 · 8 years ago

Text

92% off #HTML5 Game from scratch step by step learning JavaScript – $10

Learn how to create HTML5 and JavaScript games from scratch Step by step tutorials with real HTML5 code examples

Beginner Level, – Video: 2.5 hours Other: 20 mins, 30 lectures

Average rating /5 ()

Course requirements:

a computer desire to learn

Course description:

Crash course to learn how to create an HTML5 game from scratch for beginners.

Core HTML5 training using canvas and setting a gameboard. Adding text and dynamic variables. Using event listeners to determine keyboard actions and create movement. Create a random enemy and have it move around. Interacting with game items like a power up pill. Collision detection to determine multiple reactions to object interactions on the game board. Tweaking and fine tuning game interactions for better game play.

This course is designed for anyone who wants to better understand how to create their own HTML5, within this course we show you how to make a basic HTML5 game from scratch. You can reuse and practice with the sample code in the course.

We start with a blank document, add in html and then JavaScript to create the game.

The game we create in the course is a pacman type game with a pacman character that can be moved around the screen. There are also 2 ghosts which move towards the player or away if the pacman is powered up.

We walk you through step by step with detailed explanations of code and more.

quick lessons get right to the point fully covered topics with real world examples source files downloadable to work along challenges and lessons and code samples code snippets Links to top resources to save time 30 day money back guarantee new course material added regularly trusted name in education since 2002 full HD easy to read source coding quick response support to students regular discussions

We teach you the latest techniques and tools to use in order to create html5 canvas animations and content. Everything you need to know is included in this course. Learn at your own pace, lifetime access to this course.

Full details create animations using javascript add objects to the canvas use html5 to interact between JavaScript and canvas apply Collision detection, enemy movement, game interactions and more create basic games understand concepts on html5 game creation

Full details anyone interested in learning about HTML5 game development using JavaScript and html5 canvas online web developers application developers

Reviews:

“” ()

About Instructor:

Laurence Svekis

I’m here to help you learn, achieve your dreams, come join me on this amazing adventure today Innovative technology expert with a wide range of real world experience. Providing Smart digital solutions online for both small and enterprise level businesses. “I have a passion for anything digital technology related, enjoy programming and the challenge of developing successful digital experiences. As an experienced developer, I created my first computer applications in 1990, and my first website in 1998. I enjoy sharing my knowledge with others and want to help you share in the wonderful opportunities that the internet provides.” “Learning, understanding with a strong passion for education. The internet has provided us with new opportunities to expand and share knowledge.” Want to learn more about becoming a web developer, do you want to experience the freedom that technology provides for us? Learn how to bring amazing things to life online. Technology connects us all in many ways. It opens up doors to those who embrace it and learn how to make those connections real. “My courses are designed to help you achieve your goals, learn and update skills” Background : An experienced web application developer, having worked on multiple enterprise level applications, hundreds of websites, business solutions and many unique and innovative web applications. Web application development areas of expertise include HTML, CSS, JavaScript, JQuery, Bootstrap, PHP and MySQL. Anything to do with web creation and digital experience. Passionate about everything to do with web application development, programming to online marketing with a strong focus on social media and SEO. “Understanding technology provides a means to better connect with users. It also opens so many doors. Knowledge is the key to success and I want to help you experience what technology has to offer. I’m passionate about web technologies, and look forward to sharing my knowledge and experience with you!”

Instructor Other Courses:

Learn HTML CSS creating a single page website Quick and Easy Web Design Creating websites from scratch Web Design Make a Single Page Website Carousel controls …………………………………………………………… Laurence Svekis coupons Development course coupon Udemy Development course coupon Game Development course coupon Udemy Game Development course coupon HTML5 Game from scratch step by step learning JavaScript HTML5 Game from scratch step by step learning JavaScript course coupon HTML5 Game from scratch step by step learning JavaScript coupon coupons

The post 92% off #HTML5 Game from scratch step by step learning JavaScript – $10 appeared first on Udemy Cupón.

from Udemy Cupón http://www.xpresslearn.com/udemy/coupon/92-off-html5-game-from-scratch-step-by-step-learning-javascript-10/

from https://xpresslearn.wordpress.com/2017/03/20/92-off-html5-game-from-scratch-step-by-step-learning-javascript-10/

0 notes

xpresslearn · 8 years ago

Text

92% off #HTML5 Game from scratch step by step learning JavaScript – $10

Learn how to create HTML5 and JavaScript games from scratch Step by step tutorials with real HTML5 code examples

Beginner Level, – Video: 2.5 hours Other: 20 mins, 30 lectures

Average rating /5 ()

Course requirements:

a computer desire to learn

Course description:

Crash course to learn how to create an HTML5 game from scratch for beginners.

We start with a blank document, add in html and then JavaScript to create the game.

We walk you through step by step with detailed explanations of code and more.

Full details anyone interested in learning about HTML5 game development using JavaScript and html5 canvas online web developers application developers

Reviews:

“” ()

About Instructor:

Laurence Svekis

Instructor Other Courses:

The post 92% off #HTML5 Game from scratch step by step learning JavaScript – $10 appeared first on Udemy Cupón.

from http://www.xpresslearn.com/udemy/coupon/92-off-html5-game-from-scratch-step-by-step-learning-javascript-10/

0 notes