#you could count html and css as different languages. but css is like a framework for html so i dont jfbdhd. maybe thats another half

[borealing]

"learn to code" as advice is such bullshit. i have learned and used four and a half different coding languages through my career (html/css, java, python+sql, c++) and when i say used i mean I've built things in every one but the things that i actually used these languages for??? these earn zero money (with the caveat of until you have seniority in, e.g. front end web dev) what people really mean when they say learn coding is "learn to code. go into investment banking or finance startups." coding does not inherently have money in it. my absolute favourite part of coding? my peak enjoyment? was when i was developing for a visual coding language (you put it together like a flowchart, so say youre using a temperature sensor and you want it to log the temperature once every four hours, you can put the blocks together to make it do that. i was writing the code behind the blocks for new sensors) and i was earning £24k a year and that wasn't even part of my main role. it was an extra voluntary thing i was doing (i was working as a research assistant in biosensors - sort of - at a university, and was developing the visual code for students who didnt want to learn c++) like. i want people to learn to code, i want people to know how their electrical equipment works and how coding works, but dont believe the myth that there is inherently money in coding. the valuable things, the things people are passionate about are still vulnerable to the passion tax (if you want to do it you dont have to be paid for it). skills arent where the money is, money is where the money is.

[lukasezub244]

Biggest Java Accreditation, Finest Online Java Training, Java Coding Bootcamps, In Bay Area, The gold state, Usa

Definitely suggest to anyone who needs to study automation testing. Before choosing for this course, it is necessary to understand important role played by a Java developer or programmer. TheJava Programmeris mainly answerable for coding and unit testing of the coding. He develops applications in Java language and executes them once created to test whether or not the coding is working properly or not.

The teaching methods / tools / topics we chosen are based on the current competitive job market.

He serves as professor and chair of the division of laptop information methods at Oakland Community College.

This bootcamp prepares members to take the Java SE 11 Programmer 1 Exam.

For more information, see Admission Requirements for International Students. Including time in class, you should count on to spend about eleven to 13 hours each week on coursework. IT professionals with two years of programming experience in either an object-oriented or procedural language.

Why Take Programs At

You'll study the basics of working with the Spring framework, and then some fundamentals of SQL. You'll begin with our HTML and CSS basics programs, to lay the inspiration. Then, we'll introduce the ideas of Java Lambdas, Git, and Spark, a micro-framework. Post completion of your Java training, you can build a profession in different industries like finance, e-commerce, healthcare, training, manufacturing, and so on.

Can I learn coding in one month?

Depending on your dedication, current knowledge of coding, and time available, you could learn to code in as little as 3 months at a coding bootcamp. Coding bootcamp can make you a professional programmer in just months.

We additionally don't put a restrict on the variety of tickets you can increase for question decision and doubt clearance. The passionate builders of Programiz work continuously to reinforce the consumer experience by explaining each concept clearly along with examples. Provide your e-mail tackle, and full name in order to enroll on caveofprogramming.com. Apart from Java, you can even find out about other languages corresponding to C, C++, Python, DBMS, SQL, JSP, CSS and plenty of others. Apart from Java, it additionally offers high quality information about different languages as nicely, together with Android, Scala, Kotlin, JRuby and so forth. In addition to this, it additionally offers help for subtitles of movies.

Curriculum Of Our Java Training Program

Comb by way of all of the Java lessons available to you as a programmer with this take a glance at the Java Class Library. One of the numerous beauties of Java is that this library of usable courses you can plug into your personal classes, with out having to write them yourself. How are you able to defend your lessons from catastrophic programming mistakes? How do getters and setters truly pressure you to set up your class properties in safer ways?

Which pays more Java or Python?

Java Developer Salary in India

Freshers in this field earn around INR 1.99 lakh per annum while experienced Java developers can earn up to INR 11 lakh per annum. As you can see, the average salary of Java developers in India is slightly lower than that of Python developers. However, it offers quite a handsome pay.

It presents a six-month pro membership from Hirist that provides you entry to technical job occasions and webinars. It covers many instruments like Angular, Docker, CSS, Git, HTML, Jenkins, JUnit, Maven, MySQL, RabbitMQ, Selenium, TypeScript, MongoDB, and so on. In this course, you'll master important concepts and will have the ability to build an internet utility via simple steps and professional steering. Our Unique Online Java Course Contains forty four lectures which can help you discover all the concepts of java through our Online Java Programming Courses. The Java Tutorials Online, Online Java Course & Java Programming Course targets Java Programmers & Developers who want to be taught java by way of top-of-the-line Java tutorial online.

About Java Certification Course

Like different programming languages similar to C++ and C, Java also lets you store information in variables. This course will allow you to to be taught the JavaScript language and its functions. This tutorial doesn’t contain much video-based learning but you’re going to get an in-depth understanding of ideas and their uses. The presentation and details are high quality however this is such a brief course that I do not feel it lives up to TGC quality. It has 36 lessons but you only get somewhat over 8 hours of instruction. I even have been programming for forty years but know little about Java.

The Oracle Certified Professional Java Application Developer is for software program developers who wish to write completely different purposes and automation tools utilizing Java. Through this course, developers can show their experience and talents to develop and deploy applications through Java Enterprise Edition 7. OCPJAD is good for desktop software developers, frontend + backend app builders, software engineers, and application architects. The editorial group right here at Vault50.com is made up of numerous writers primarily based all round the world.

[vwwordpressthemes]

   Ways Premium WordPress Themes Will Help You Get More Business

Premium WordPress theme is talk of the town when it comes to the success of business but one thing that is quite important is the marketing aspect. The art of selling of the popular premium WordPress theme is a niche in itself for the developers. When you market and develop the premium WP themes, you will have to consider the important factors otherwise it will become quite difficult to move forward.

Selection Is Important

When you go for the selection of the best premium WordPress theme, you need to come to the expectation level of the buyer. The WP theme has to be tailored in accordance with the expectation of the content and also should go with the purpose of the website for which it is being put to use. You will get the niche WP themes and there is no doubt about it. You will get the niche WP themes for personal portfolios, photographers, musicians, business or any other niche that you think of. When you research the niche, it will also determine your inclination towards the area of business prevalent in the market. It determines your competition and your chances of success. You need to choose a niche for the premium responsive WordPress theme and focus on the target audience that you are able to market for overall success in the long run. Your one positive strategy will be the selection of keywords as well as marketing strategy. Both will work well for your premium WP theme. You can also alternately approach a good company to market popular premium WordPress themes.

Make The WP Premium Theme Amazing

Market has stiff competition and there are best premium WordPress themes in innumerable numbers and your WP theme has to stand distinct in this competition. One of the best things to achieve this is to put extra attention as far as the aspect of design is concerned. You will have to focus on the graphic elements and also the content that is in the demo theme. If you are interested in using the full visual potential of the premium WordPress theme, you can make use of captivating images. You also have the choice for multiple design options like multiple page layout options and colour schemes.

Responsive Design - Something You Cannot Ignore

You can make the premium WordPress theme 2019 responsive and this will make it excellent for marketing. If there is no responsive styling and setting, theme shoppers will ignore it and move further. If you want to make your WP theme distinct, do not collapse the content in single column for screens of small sizes. You have to use creativity to make your WP theme beautiful on various dimensions. Do commence a responsive framework for your WP theme.

Follow The Coding Standards

When you make premium responsive WordPress themes especially the ones that are used by other developers, you will have to follow the basic coding standards of WordPress. You can go to the comprehensive standard guides. When you follow such standards, it becomes easy for WordPress developers to abide by as well as edit the code and also because marketplaces need you to meet some standard compliance. Before releasing premium WordPress theme, you can try out particular plugin for testing code as per basic standards of WordPress.

Putting The Right Theme Templates

You can include custom template unique to the functionality and design of the theme. Some themes especially frameworks go far in slicing up theme into include files. Balance theme for flexibility.

Make WP Theme Easy For Customization

The WP theme has to become easy for the developer or the site owner when it comes to customization. You have to make a balance about the provision of customization options and not providing enough. The WP premium theme has not to be over simple and over complex because both of these can be frustrating in the long term. You can create good theme options page and also include the thorough documentation. You can include shortcodes and custom templates and this will make site easy for customization. Before you release popular premium WordPress themes for sale, developers and professionals of different skill levels will set up and customize.

Creating Good Theme Option Page

With option, the site admin edits theme aspects like functionality or design and there is no need of using PHP or CSS. Best premium WordPress themes have robust theme options and these include pages with settings in dozens. When you create theme options page, include what people will actually use and do the testing for organization of settings. You can go for the option tree plugin and this will create theme options page without writing code by yourself.

Detailed Documentation

Good documentation includes set up and configuration of WP theme as well as the methodology of work on the custom templates. It could be frustrating if you buy a popular premium WordPress theme and not have any knowledge of the change related to certain settings. It is better if you go through the process of writing good documentation and after that download the documentation template in order to get started.

Marketing The WP Theme - Quite Important

Innumerable premium responsive WordPress themes are available in the market as of today and you need to have a clear plan as far as the theme marketing is concerned. The truth is people have to find it and purchase it.

You can put the theme in theme marketplace.

You can make a framework having examples gallery or store.

You can create site and do the theme marketing

You submit the free version on WordPress with choice for premium upgrade

Remember one thing that pros and cons are in each option and you need to select the option that works fine for you. When you submit to the marketplace, it will increase the audience count. You will be confused probably with large theme catalogue. When you market theme yourself, it is going to increase margins of profit but it could be hard to reach wider audience. You have to leverage social and professional circles for the promotion of the premium WordPress themes.

Handling Of Support And Its Planning

WordPress has the in-built support system and there are certain marketplaces having the in-built support systems. There has to be support system in place when you release the WP theme. You will have to provide the accountability as far as the time dedication for the support threads is concerned. The same is related to the feature requests depending on the popularity of the theme. When you pay for the premium WordPress themes 2019, you have the expectation for not only the rapid but also reliable support as well. You do not want to be called a theme developer providing poor support to the WP themes.

Selecting Perfect WordPress Theme - Be Careful During Selection

As a beginner, you may feel overwhelmed when it comes to the selection of WP theme for a particular site. You have innumerable free as well as paid options. Now, the selection aspect of free or premium WordPress themes is very important. WP themes cater to the different markets and your WP theme has to complement the website content. For example, if you commence a blog on social problems or politics or fashion, then you require a WP premium theme that has the potential to improve readability. When you go for the premium responsive WordPress themes, you have innumerable customization options and in case there is no proper coding, these options will make things difficult to change themes or put other WP plugins to use. Do not always go for the look of WP theme. Some look great but the website can become slow.

Simplicity - An Important Factor

Best premium WordPress themes come with colours and complex layouts and these also have the flashy animations. You may need these things at times but you may not require them in general. You have to look for the WP premium theme having the design layout that will support your goal. Your WP theme has to look good but there has to be no compromise when it comes to the usability as well as simplicity. The style of presentation of WordPress theme should not be complicated more than desired. The chief purpose of web design is to help the users to trace the information they require. This helps site owners in their goal achievement at the same time.

Translation Ready - Multilingual

Know that many WP sites are not always in the English language. If you create the site in multiple languages, the demand will be more in the international platform. You can create the website in multiple languages apart from English. Be sure to make the WP theme translation ready with the support of multilingual WP plugins.

Page Builder

With page builders, you can create the page layouts with the help of drag and drop user interface. Various premium WordPress themes have pre-installed page builders. When you use the page builder to create landing pages, it can produce unwanted code and when you switch the theme, there needs to be a clean-up of pages. You need to select the best premium WordPress theme with popular page builder plugin. You can separately purchase these page builders.

Support Options

If you talk about the free WordPress themes, you do not have the guaranteed support. There are developers who give excellent support to the free WP themes but there are certain free WP themes having no support option. It will be nice if you select premium WP theme having the fine documentation as well as support option. It should also have an email support for a period of one year.

SEO Friendly

Your best premium WordPress theme has a crucial role to play when it comes to the SEO friendliness of the business website. Even if the theme is good looking, it can still generate HTML that is poorly coded. This can impact the performance of the site on the search engines. For the beginners, it is not easy to analyse the source code of the theme and they cannot do this on their own. This is the reason developers of the premium WordPress theme let you know that pages are optimised for SEO. Know that if page generates proper HTML5 and you can simply check this by tapping on W3C Markup Validation service. If you use the W3C tool, it generates multiple warnings and there is no need of any worry.

Rating And Review

When you talk of the quality of the premium responsive WordPress theme, the rating and reviews play a very good role. If you sell the WordPress premium theme at 3rd party marketplace, then the reviews play a very good role. If bad reviews are more, then you have to give a careful look.

[t-baba]

How to find the minimal CSS framework for you

#441 — May 20, 2020

Read on the Web

Frontend Focus

A Drop-in Minimal CSS Framework Switcher — There are a lot of so called ‘minimal’ CSS systems out there, such as new.css and GitHub’s Primer but it can be hard to sort through them for something you’d like. Enter this ‘minimal CSS framework switcher’ where you get to preview lots of minimal CSS frameworks on a single page. Alternatively, you can find a list of all the frameworks involved here.

Liam Doherty

What's New in Lighthouse 6.0 — Lighthouse 6 (the automated website UX auditing tool) has just dropped. Some of the changes include new metrics, audits for unused JavaScript, changes to the Chrome extension, and lots more.

Connor Clark

Faster CI/CD for All Your Software Projects Using Buildkite — See how Shopify scaled from 300 to 1800 engineers while keeping their build times under 5 minutes.

Buildkite sponsor

Second-Guessing the Modern Web — What if everyone’s wrong? Can we solve things in a better way that single page applications? Interesting thought piece and Rich Harris replied with In Defense of the Modern Web.

Tom MacWright

Just How Bad Is The ICO's Draft 'Age Appropriate' Design Code? — The author proclaims that as “a policy wonk, a technologist, a privacy campaigner, and as a parent” the UK data protection regulator’s proposed ‘Age Appropriate Design Code’ is one of the worst proposals she’s ever seen, and could result in age-gating across the internet, and a huge increase in data collection.

Heather Burns

What's New in Chrome 83 for Developers? — Version 83 is rolling out to stable now, and adds trusted types support, introduces changes to styling in HTML form controls, and more. Here’s a four-minute video version that covers the changes if you’d prefer. Secure DNS (DNS-over-HTTPS) support is another interesting development.

Pete Le Page (Google)

▶  Understanding Cumulative Layout Shift — Content moving unexpectedly on a page can be really irritating. This 20-minute explainer looks at the new ‘Cumulative Layout Shift’ speed metric (reported in Lightouse 6.0) and how it can help developers understand the impact of this problem on their pages.

Annie Sullivan and Steve Kobes

Microsoft Shows Off Its Edge Browser Running on Linux — Spotted at Microsoft’s Build 2020 conf where Microsoft has been releasing things left, right, and center like a package manager for Windows and Windows Terminal 1.0.

Rich Woods

⚡️ Quick bits:

Microsoft showed off a bunch of new Edge features in this snazzy video from their annual Build conference.

Support for the :where() pseudo class is now in the latest Safari preview.

Mozilla has launched a new accessibility blog featuring posts from the Firefox Accessibility Team.

How to center things in CSS is pretty much evergreen content, right...? 😅

I asked on Twitter whether it's 'frontend', 'front-end' or 'front end'. Here are the results.

Microsoft's Edge browser now has its own origin trials system with a couple of experiments already live.

A tab grouping feature is coming to Chrome.

💻 Jobs

Find a Job Through Vettery — Vettery specializes in tech roles and is completely free for job seekers. Create a profile to get started.

Vettery

Frontend Developer at X-Team (Remote) — Join X-Team and work on projects for companies like Riot Games, FOX, Coinbase, and more. Work from anywhere.

X-Team

ℹ️ Interested in running a job listing in Frontend Focus? There's more info here.

📙 Tutorials & Opinion

Minimalist HTML — The irony here is that this blog is literally in plain text. But overall, some good points about how to keep your HTML brief, should you want to reduce character counts.

Ryan Jacobs

The Need for Speed, 23 Years Later — In this somewhat historical look at website and internet speed, Kathryn looks at the fact that page speeds have not improved over time in spite of the increase in internet speed.

Kathryn Whitenton

Using CSS calc() to Figure Out Optimal Line-height — A quick, but math-heavy post by Jesús Ricarte on optimal line-height values that are more maintainable.

Jesús Ricarte

IE11 Mainstream End Of Life in Oct 2020 — Some interesting thoughts on Windows 10 and supporting IE11. As the author points out, he made up the term ‘mainstream EOL’ and he links to a response from an Edge team member.

Shawn Wang

Form Design: Multiple Inputs Versus One Input — Some web forms use multiple inputs for what really should be a single unit of data. This usability guide looks at the drawbacks of that approach and how to improve the experience.

adam silver

Safe/Unsafe Alignment in CSS Flexbox — This is a brief look at the new safe keyword that can be used with the align-items property in Flexbox, so far only supported in Firefox.

stefan judis

Detect Inactive Users with The Idle Detection API — Currently in development, this API can be used to find out when a user isn’t actively using their device.

Thomas Steiner

Stop Setting The Language of Your Website Based On User Location — A little PSA on why this might not always be the best idea…

Pedro Pimenta

🔧 Code, Tools and Resources

Animal Crossing: Isabelle's Day Off — Yep, I’m playing Animal Crossing at the moment, so felt it appropriate to include this great little animated diorama created with CSS. There’s also a neat time-lapse video of it all being put together. Impressive!

Tee Diang codepen

MongoDB Is Easy. Now Make It Powerful. Free Download for 30 Days.

Studio 3T sponsor

IntersectionObserver Visualizer — If you’re new to using the IntersectionObserver API, this useful interactive demo might help you comprehend it a little better.

michelle barker

Stylemug: A CSS-in-JS Library with Support for Atomic CSS Extraction — Another solution on the CSS-in-JS scene that features the ability to extract CSS rules to a .css file, which then replaces the stylesheet in your bundle.

Matthias Van Parijs

new.css: A Classless CSS Framework to Write Modern Websites using Only HTML — Weighs only ~4.5kb. Demo here.

xz

🐦 ...spotted on Twitter

Here's a list of all the different length units you can use in CSS. I don't think I was familar with the Q unit.

by via Frontend Focus https://ift.tt/2ZlOl4V

[nancydsmithus]

Designing And Building A Progressive Web Application Without A Framework (Part 1)

Designing And Building A Progressive Web Application Without A Framework (Part 1)

Ben Frain

2019-07-23T14:00:59+02:002019-07-23T12:07:36+00:00

How does a web application actually work? I don’t mean from the end-user point of view. I mean in the technical sense. How does a web application actually run? What kicks things off? Without any boilerplate code, what’s the right way to structure an application? Particularly a client-side application where all the logic runs on the end-users device. How does data get managed and manipulated? How do you make the interface react to changes in the data?

These are the kind of questions that are simple to side-step or ignore entirely with a framework. Developers reach for something like React, Vue, Ember or Angular, follow the documentation to get up and running and away they go. Those problems are handled by the framework’s box of tricks.

That may be exactly how you want things. Arguably, it’s the smart thing to do if you want to build something to a professional standard. However, with the magic abstracted away, you never get to learn how the tricks are actually performed.

Don’t you want to know how the tricks are done?

I did. So, I decided to try building a basic client-side application, sans-framework, to understand these problems for myself.

But, I’m getting a little ahead of myself; a little background first.

Before starting this journey I considered myself highly proficient at HTML and CSS but not JavaScript. As I felt I’d solved the biggest questions I had of CSS to my satisfaction, the next challenge I set myself was understanding a programming language.

The fact was, I was relatively beginner-level with JavaScript. And, aside from hacking the PHP of Wordpress around, I had no exposure or training in any other programming language either.

Let me qualify that ‘beginner-level’ assertion. Sure, I could get interactivity working on a page. Toggle classes, create DOM nodes, append and move them around, etc. But when it came to organizing the code for anything beyond that I was pretty clueless. I wasn’t confident building anything approaching an application. I had no idea how to define a set of data in JavaScipt, let alone manipulate it with functions.

I had no understanding of JavaScript ‘design patterns’ — established approaches for solving oft-encountered code problems. I certainly didn’t have a feel for how to approach fundamental application-design decisions.

Have you ever played ‘Top Trumps’? Well, in the web developer edition, my card would look something like this (marks out of 100):

CSS: 95

Copy and paste: 90

Hairline: 4

HTML: 90

JavaSript: 13

In addition to wanting to challenge myself on a technical level, I was also lacking in design chops.

With almost exclusively coding other peoples designs for the past decade, my visual design skills hadn’t had any real challenges since the late noughties. Reflecting on that fact and my puny JavaScript skills, cultivated a growing sense of professional inadequacy. It was time to address my shortcomings.

A personal challenge took form in my mind: to design and build a client-side JavaScript web application.

On Learning

There has never been more great resources to learn computing languages. Particularly JavaScript. However, it took me a while to find resources that explained things in a way that clicked. For me, Kyle Simpson’s ‘You Don’t Know JS’ and ‘Eloquent JavaScript’ by Marijn Haverbeke were a big help.

If you are beginning learning JavaScript, you will surely need to find your own gurus; people whose method of explaining works for you.

The first key thing I learned was that it’s pointless trying to learn from a teacher/resource that doesn’t explain things in a way you understand. Some people look at function examples with foo and bar in and instantly grok the meaning. I’m not one of those people. If you aren’t either, don’t assume programming languages aren’t for you. Just try a different resource and keep trying to apply the skills you are learning.

It’s also not a given that you will enjoy any kind of eureka moment where everything suddenly ‘clicks’; like the coding equivalent of love at first sight. It’s more likely it will take a lot of perseverance and considerable application of your learnings to feel confident.

As soon as you feel even a little competent, trying to apply your learning will teach you even more.

Here are some resources I found helpful along the way:

Fun Fun Function YouTube Channel

Kyle Simpson Plural Sight courses

Wes Bos’s JavaScript30.com

Eloquent JavaScript by Marijn Haverbeke

Right, that’s pretty much all you need to know about why I arrived at this point. The elephant now in the room is, why not use a framework?

Why Not React, Ember, Angular, Vue Et Al

Whilst the answer was alluded to at the beginning, I think the subject of why a framework wasn’t used needs expanding upon.

There are an abundance of high quality, well supported, JavaScript frameworks. Each specifically designed for the building of client-side web applications. Exactly the sort of thing I was looking to build. I forgive you for wondering the obvious: like, err, why not use one?

Here’s my stance on that. When you learn to use an abstraction, that’s primarily what you are learning — the abstraction. I wanted to learn the thing, not the abstraction of the thing.

I remember learning some jQuery back in the day. Whilst the lovely API let me make DOM manipulations easier than ever before I became powerless without it. I couldn’t even toggle classes on an element without needing jQuery. Task me with some basic interactivity on a page without jQuery to lean on and I stumbled about in my editor like a shorn Samson.

More recently, as I attempted to improve my understanding of JavaScript, I’d tried to wrap my head around Vue and React a little. But ultimately, I was never sure where standard JavaScript ended and React or Vue began. My opinion is that these abstractions are far more worthwhile when you understand what they are doing for you.

Therefore, if I was going to learn something I wanted to understand the core parts of the language. That way, I had some transferable skills. I wanted to retain something when the current flavor of the month framework had been cast aside for the next ‘hot new thing’.

Okay. Now, we’re caught up on why this app was getting made, and also, like it or not, how it would be made.

Let’s move on to what this thing was going to be.

An Application Idea

I needed an app idea. Nothing too ambitious; I didn’t have any delusions of creating a business start-up or appearing on Dragon’s Den — learning JavaScript and application basics was my primary goal.

The application needed to be something I had a fighting chance of pulling off technically and making a half-decent design job off to boot.

Tangent time.

Away from work, I organize and play indoor football whenever I can. As the organizer, it’s a pain to mentally note who has sent me a message to say they are playing and who hasn’t. 10 people are needed for a game typically, 8 at a push. There’s a roster of about 20 people who may or may not be able to play each game.

The app idea I settled on was something that enabled picking players from a roster, giving me a count of how many players had confirmed they could play.

As I thought about it more I felt I could broaden the scope a little more so that it could be used to organize any simple team-based activity.

Admittedly, I’d hardly dreamt up Google Earth. It did, however, have all the essential challenges: design, data management, interactivity, data storage, code organization.

Design-wise, I wouldn’t concern myself with anything other than a version that could run and work well on a phone viewport. I’d limit the design challenges to solving the problems on small screens only.

The core idea certainly leaned itself to ‘to-do’ style applications, of which there were heaps of existing examples to look at for inspiration whilst also having just enough difference to provide some unique design and coding challenges.

Intended Features

An initial bullet-point list of features I intended to design and code looked like this:

An input box to add people to the roster;

The ability to set each person to ‘in’ or ‘out’;

A tool that splits the people into teams, defaulting to 2 teams;

The ability to delete a person from the roster;

Some interface for ‘tools’. Besides splitting, available tools should include the ability to download the entered data as a file, upload previously saved data and delete-all players in one go;

The app should show a current count of how many people are ‘In’;

If there are no people selected for a game, it should hide the team splitter;

Pay mode. A toggle in settings that allows ‘in’ users to have an additional toggle to show whether they have paid or not.

At the outset, this is what I considered the features for a minimum viable product.

Design

Designs started on scraps of paper. It was illuminating (read: crushing) to find out just how many ideas which were incredible in my head turned out to be ludicrous when subjected to even the meagre scrutiny afforded by a pencil drawing.

Many ideas were therefore quickly ruled out, but the flip side was that by sketching some ideas out, it invariably led to other ideas I would never have otherwise considered.

Now, designers reading this will likely be like, “Duh, of course” but this was a real revelation to me. Developers are used to seeing later stage designs, rarely seeing all the abandoned steps along the way prior to that point.

Once happy with something as a pencil drawing, I’d try and re-create it in the design package, Sketch. Just as ideas fell away at the paper and pencil stage, an equal number failed to make it through the next fidelity stage of Sketch. The ones that seemed to hold up as artboards in Sketch were then chosen as the candidates to code out.

I’d find in turn that when those candidates were built-in code, a percentage also failed to work for varying reasons. Each fidelity step exposed new challenges for the design to either pass or fail. And a failure would lead me literally and figuratively back to the drawing board.

As such, ultimately, the design I ended up with is quite a bit different than the one I originally had in Sketch. Here are the first Sketch mockups:

Initial design of Who’s In application (Large preview)

Initial menu for Who’s In application (Large preview)

Even then, I was under no delusions; it was a basic design. However, at this point I had something I was relatively confident could work and I was chomping at the bit to try and build it.

Technical Requirements

With some initial feature requirements and a basic visual direction, it was time to consider what should be achieved with the code.

Although received wisdom dictates that the way to make applications for iOS or Android devices is with native code, we have already established that my intention was to build the application with JavaScript.

I was also keen to ensure that the application ticked all the boxes necessary to qualify as a Progressive Web Application, or PWA as they are more commonly known.

On the off chance you are unaware what a Progressive Web Application is, here is the ‘elevator pitch’. Conceptually, just imagine a standard web application but one that meets some particular criteria. The adherence to this set of particular requirements means that a supporting device (think mobile phone) grants the web app special privileges, making the web application greater than the sum of its parts.

On Android, in particular, it can be near impossible to distinguish a PWA, built with just HTML, CSS and JavaScript, from an application built with native code.

Here is the Google checklist of requirements for an application to be considered a Progressive Web Application:

Site is served over HTTPS;

Pages are responsive on tablets & mobile devices;

All app URLs load while offline;

Metadata provided for Add to Home screen;

First load fast even on 3G;

Site works cross-browser;

Page transitions don’t feel like they block on the network;

Each page has a URL.

Now in addition, if you really want to be the teacher’s pet and have your application considered as an ‘Exemplary Progressive Web App’, then it should also meet the following requirements:

Site’s content is indexed by Google;

Schema.org metadata is provided where appropriate;

Social metadata is provided where appropriate;

Canonical URLs are provided when necessary;

Pages use the History API;

Content doesn’t jump as the page loads;

Pressing back from a detail page retains scroll position on the previous list page;

When tapped, inputs aren’t obscured by the on-screen keyboard;

Content is easily shareable from standalone or full-screen mode;

Site is responsive across phone, tablet and desktop screen sizes;

Any app install prompts are not used excessively;

The Add to Home Screen prompt is intercepted;

First load very fast even on 3G;

Site uses cache-first networking;

Site appropriately informs the user when they’re offline;

Provide context to the user about how notifications will be used;

UI encouraging users to turn on Push Notifications must not be overly aggressive;

Site dims the screen when the permission request is showing;

Push notifications must be timely, precise and relevant;

Provides controls to enable and disable notifications;

User is logged in across devices via Credential Management API;

User can pay easily via native UI from Payment Request API.

Crikey! I don’t know about you but that second bunch of stuff seems like a whole lot of work for a basic application! As it happens there are plenty of items there that aren’t relevant to what I had planned anyway. Despite that, I'm not ashamed to say I lowered my sights to only pass the initial tests.

For a whole section of application types, I believe a PWA is a more applicable solution than a native application. Where games and SaaS arguably make more sense in an app store, smaller utilities can live quite happily and more successfully on the web as Progressive Web Applications.

Whilst on the subject of me shirking hard work, another choice made early on was to try and store all data for the application on the users own device. That way it wouldn’t be necessary to hook up with data services and servers and deal with log-ins and authentications. For where my skills were at, figuring out authentication and storing user data seemed like it would almost certainly be biting off more than I could chew and overkill for the remit of the application!

Technology Choices

With a fairly clear idea on what the goal was, attention turned to the tools that could be employed to build it.

I decided early on to use TypeScript, which is described on its website as “… a typed superset of JavaScript that compiles to plain JavaScript.” What I’d seen and read of the language I liked, especially the fact it learned itself so well to static analysis.

Static analysis simply means a program can look at your code before running it (e.g. when it is static) and highlight problems. It can’t necessarily point out logical issues but it can point to non-conforming code against a set of rules.

Anything that could point out my (sure to be many) errors as I went along had to be a good thing, right?

If you are unfamiliar with TypeScript consider the following code in vanilla JavaScript:

console.log(`${count} players`); let count = 0;

Run this code and you will get an error something like:

ReferenceError: Cannot access uninitialized variable.

For those with even a little JavaScript prowess, for this basic example, they don’t need a tool to tell them things won’t end well.

However, if you write that same code in TypeScript, this happens in the editor:

TypeScript in action (Large preview)

I’m getting some feedback on my idiocy before I even run the code! That’s the beauty of static analysis. This feedback was often like having a more experienced developer sat with me catching errors as I went.

TypeScript primarily, as the name implies, let’s you specify the ‘type’ expected for each thing in the code. This prevents you inadvertently ‘coercing’ one type to another. Or attempting to run a method on a piece of data that isn’t applicable — an array method on an object for example. This isn’t the sort of thing that necessarily results in an error when the code runs, but it can certainly introduce hard to track bugs. Thanks to TypeScript you get feedback in the editor before even attempting to run the code.

TypeScript was certainly not essential in this journey of discovery and I would never encourage anyone to jump on tools of this nature unless there was a clear benefit. Setting tools up and configuring tools in the first place can be a time sink so definitely consider their applicability before diving in.

There are other benefits afforded by TypeScript we will come to in the next article in this series but the static analysis capabilities were enough alone for me to want to adopt TypeScript.

There were knock-on considerations of the choices I was making. Opting to build the application as a Progressive Web Application meant I would need to understand Service Workers to some degree. Using TypeScript would mean introducing build tools of some sort. How would I manage those tools? Historically, I’d used NPM as a package manager but what about Yarn? Was it worth using Yarn instead? Being performance-focused would mean considering some minification or bundling tools; tools like webpack were becoming more and more popular and would need evaluating.

Summary

I’d recognized a need to embark on this quest. My JavaScript powers were weak and nothing girds the loins as much as attempting to put theory into practice. Deciding to build a web application with vanilla JavaScript was to be my baptism of fire.

I’d spent some time researching and considering the options for making the application and decided that making the application a Progressive Web App made the most sense for my skill-set and the relative simplicity of the idea.

I’d need build tools, a package manager, and subsequently, a whole lot of patience.

Ultimately, at this point the fundamental question remained: was this something I could actually manage? Or would I be humbled by my own ineptitude?

I hope you join me in part two when you can read about build tools, JavaScript design patterns and how to make something more ‘app-like’.

(dm, yk, il)

[goodcore101]

Custom software development process stages

One by one, here I described all development stages for custom software we follow in Syndicode (the agency I work in). Custom software development process stages in details.

In my custom software development handbook, I talked about and shared different nuances to consider before someone hired a dedicated development team to work on a product. In addition to access to the core business data, signing an NDA, and many other non-functional but important issues, you have to understand custom software development process stages.

Custom software development is an iterative process that goes through defined process stages to implement all the required features and reach the desired result. Even if we aim to create a custom product specifically tailored for the specific group of users or an organization, the development process still heavily depends on software development methodology your software development partner follows. (For example, Syndicode follows Agile methodology). But the main iteration stages are pretty similar.

Сustom software development process

includes the next stages:

Analysis and Planning

— a collection of requirements,

— research,

— changes management,

— risk management,

— software architecture.

Design

Development

— backend development,

— frontend development.

Quality Assurance and testing

Intermediate deliveries

Documentation

Maintenance (software evolution)

Reporting

If you’re looking for details, here they are.

Analysis and Planning

Collection of requirements in custom software development is a cornerstone. At this stage, we understand the niche, business values and plans of our client. Whether the client wants to launch a web app for logistics or develop an IoT platform, together we need to go through a Discovery Session. This is a meeting (online or offline) between client’s and developer’s team the main purpose of which is to define a tech stack and product’s features to be implemented. Tech stack for custom software development might contain a bunch of different technologies like Ruby, PHP, NodeJS, GoLang, Python, Swift, Kotlin, Elixir and so on… They are defined according to a technical specification created by software architect or lead developer. Find out the other Discovery Session tasks, key participants, timeframe and results.

Software development research aimed to understand the current tech trends and main characteristics of the technologies meant to be used in this particular project. All the difficulties and best practices count. Apart from the tech side, project manager and business analyst do research about implementation and maintenance prospects. SWOT for current competitors should be prepared as well. After this research, we usually create a plan for the software development process and wait for the client’s approval.

Changes management helps us to prepare, equip for and adopt all the possible changes that might appear during the process of custom software development. Because we might face changes in tech, design, business needs and priorities from the client or even the end-user anytime. Changes management is connected with risk management in software engineering. Here, risk management stands for risk containment and mitigation. We should be ready to act when a risk arises, drawing upon the experience and knowledge of the entire team to minimize the impact to the project.

There are 5 types of risks you can face working in a software development company:

New technologies (that are not tested yet)

Functional requirements There is a risk that the change in elemental requirements will likely propagate throughout the entire project, and modifications to user requirements might not translate to functional requirements.

System architecture Wrong platform, component, or architecture can have disastrous consequences.

Performance Users’ and client’s expectations on performance should be met no matter the changes and failures occurred during the process of product development.

Organizational This risk heavily depends on reliability and professional skills of your software development partner.

Design

If you’re developing a web or mobile application, one of the major things you need to get right is the way your app looks and feels. For example, if your field is eCommerce, a poorly designed app will lose you many potential customers. That is why visual design, your brand identity and user experience of your digital product play one of the most significant roles. I devoted a whole page to describe the purpose of the great UI/UX design, the main terms, history, some examples and processes for design development — read a comprehensive UI/UX design guide.

Development

Backend development handles the functionality of web applications. You can’t see it on the screen but every interaction in the human-computer system is possible thanks to backend development. Backend development refers to the server side of development where you are primarily focused on how the site works. It is code that manages user connections, connects the web to a database, and powers the web application itself.

Here in Syndicode, we work with many different languages for backend development, but Ruby is our language of choice. Ruby on Rails (Ruby’s main framework) backend development helps the workload become easier for the architects and developers through the collection of pre-packaged codes that make the development of the backend seamless and fast. It makes the entire programming a lot speedier and more profitable. As far as most businesses now want to get a web application, I compiled the list of the reasons why Rails is ideal for web app development. And here you can explore the examples of the most famous web applications built with Ruby.

Talking about frontend development I mean everything you can see on the screen. Look, feel and design — that are the 3 main parts generated by code for your digital product in frontend development. Frontend development is focused on the client side of development and responsible for seamless user experience.

In Syndicode, we use JavaScript and its main frameworks like React and Angular (and explore Vue.js as we see a lot of potential use cases for it). Also, we work with CSS and HTML.

For custom mobile development we use Ruby on Rails for mobile backends and RESTful APIs. When there’s no need for heavy effects or computations we use React Native. This technology is beneficial for marketplaces and CRM, or projects where you need just to duplicate what you have on the web and add some geofencing, notifications, and other mobile features. For native development of iOS applications, we use Swift. The same story with Android SDK — we choose it in cases when features could be implemented only in native tech stack. Also, when it’s required in the project, we work with Python, Node.js, and PHP. Also, we are big fans of Flutter.

Of course, the tech stack for custom software development might have every possible configuration, depending on the client’s needs, and we are not bound to one technology just because we like it.

QA and testing

Quality assurance is a set of activities for ensuring quality in software engineering processes. This stage ensures that software meets and complies with the defined or standardized quality specifications. QA is a process that checks the developed software to ensure it meets the desired quality measures.

Software testing is the process of checking developed software for any mistakes or bugs. This helps to validate and eventually verify the product as to whether it is ready for the market.

What is the difference between QA and testing? Put is simply, QA enhances the quality via improvement of the development process and testing enhances it via finding bugs.

Intermediate deliveries

Intermediate deliveries great because they help to provide a fast feedback loop that immediately show developers the effects of their work. Mistakes are fixed quickly, while beneficial changes can be released and deployed to customers without having to wait for a distant future release date. Find the example of continuous integration and delivery with Github, Gitflow, and Jenkins.

Documentation

Development documentation stage encompasses all written documents and materials dealing with software product development. Except for pre-development documentation (where you should describe:

vision statement;

initial assessment document with stages of development;

roadmap;

technology stack;

software requirements specifications;

wireframes and UX roadmap),

you also should add documents created in course of the software engineering process. There are only two main types of them:

coding documentation;

testing documentation.

Also, software development agency must provide post-development documentation that includes:

support papers, and

users manual.

Maintenance

Software maintenance is a continuation of the collaboration with the client to improve, modify and update software product after delivery to correct faults and to improve performance. There are 4 categories of software maintenance:

Corrective — to rectify some bugs detected while the system is in use, or to improve the performance of the system.

Adaptive — to modify and update when the customer needs the product to run on new platforms/operating systems/hardware/software.

Perfective — to support the new features or to change functionalities according to the customer’s demands.

Preventive — to prevent future problems of the software. Some problems might be not significant at this moment but may cause serious issues in the future.

Reporting

Reporting helps us to inform our client about the current stage of development or issues found or solved during the software development process. This is a critical part of effective project communications and management strategy. As in the early stages of development so as in the middle and when the product is released, we prepare a project status report. Also, there is a project management report that includes:

general product info;

status Info;

milestone review;

project summary;

issues and risks;

projects metrics, and so on.

Reporting keeps the client updated to what is happening with the custom software during its development. And reporting generates trustful relationships between a software development company and the client which guarantees transparency and loyalty — the key factors of successful cooperation.

This part of the story was related to the process you’ll go through while developing your product. But there are also aspects a business owner should consider long before the development starts. Such aspects as innovations. To be successful you have to embrace new technologies and hacks available nowadays. Do you want to know what innovations can grow your business and save money?

Thanks for reading!

(Content Source: https://syndicode.com/2019/05/23/custom-software-development-process-stages/ )

[siliconwebx]

What Does it Mean to Be “Full Stack”?

I was asked this recently by a fellow developer who was at the same web tech conference I was at. This developer had met a lot of new people who literally introduced themselves as full-stack developers sort of the way Bob Vance, Vance Refrigeration would on The Office, but it was Tony Frank, Full-Stack Developer instead.

I suspect the developer asking the question taken from the title of this post already knew the basic idea of what people mean by "full-stack developer," but was wondering what the heck it's all about. There was a tone in the question. A tone that suggested this person isn't exactly in love with the term.

The traditional explanation A person who identifies (or has the job title of) "full-stack" developer can do both what is considered front-end development work and back-end development work.

These days, probably a bit of DevOps (e.g. Git, testing, and getting sites to production). The "stack" is all these things combined, so a full-stack developer is shorthand for: when it comes to building websites, I can do it all.

There are some stacks that have achieved notoriety over the years. Maybe you've heard of the LAMP stack?

Linux Apache MySQL PHP

A full-stack developer on that stack means you know Linux, Apache, MySQL, and PHP. (Abstractly: server software, web server, database, back-end language.) This site runs on that stack, and I'm solely responsible for its development, so I guess I'm a full-stack developer in some loose sense.

But "loose" is a generous interpretation. I don't know the first thing about Linux, except that's what runs my web servers. I don't know much about Apache, except that I sometimes use HTAccess directives to do things. I could count the number of MySQL queries I've written on my two hands, and I only really know PHP in the context of WordPress.

Looked at that way, I'm barely a developer at all. Full stack, on the other hand, generally refers to tossing front-end tasks into the mix and I'm competent enough in that space that my front-end skill set alone, has allowed me to build dozens (or hundreds!) of sites throughout my career. Full-stack-enough, anyway.

There are loads of other stacks.

LAMP isn't particularly prescriptive about how you build the front-end. It came from an era where it was assumed you'd build a back end to spit out HTML and that's your front end.

Another stack that's achieved notoriety since the Grand Arrival of JavaScript is the MEAN stack.

MongoDB Express Angular Node

It is perfectly plausible to replace parts of a stack. Perhaps you'd use Nginx instead of Apache, or PostgreSQL instead of MySQL in what's otherwise LAMP stack. MEAN is notable in that every layer of the stack was replaced with new technology. Node brought JavaScript to the back end, which could power web servers, handle routing, connect data sources, run build processes, compile code, and more.

A full-stack developer in this world is writing nearly everything in JavaScript. No wonder there is somewhat of an explosion of people considering themselves "full" stack. A single language, like JavaScript, that runs in browsers itself and is a paramount front-end technology is a widely transferrable skill.

The MEAN stack can have layers swapped out just as easily as LAMP. Perhaps you use a data store like Fauna or Firebase instead. Perhaps you use Vue or React instead of Angular. Perhaps you don't need Express because you leave your routing to a framework or do it client-side.

Shawn Wang calls another a popular stack STAR:

Design Systems TypeScript Apollo React

That's JavaScript all the way down.

It's notable that, while we're still thinking of this as a stack, we're thinking less about our servers and server software to the point they aren't really a key part of the stack. Not that developers and companies don't take it seriously, but it's more abstracted now than it has traditionally been. I'd point to the world of serverless as a case in point. The questions aren't about what operating system our servers should use; it's what platform is the most cost-effective to run our JavaScript functions.

So, stacks evolve over time. But it's not just what technologies they use, but what technology we even consider a part of a stack. What full-stack means morphs over time.. We're in a place right now where knowing JavaScript grants you a full-stack merit badge. You can work with client site frameworks, architect components and piece them together to build an entire front end. You can write web servers. You can write back-end code that talks to APIs. You can do all the state management you need. You can construct build processes and deployment pipelines. You can even bring CSS into JavaScript if you're so inclined.

Even if you're largely focused on JavaScript, people's skillsets are generally wider than that. Throw in some HTML and CSS competency, Git foo, and a little DevOps hobby and you're a real web powerhouse. You can do it all! A renaissance man! Lord of the seven kingdoms!

I think that's kinda awesome, actually. It truly empowers developers. While it's worth considering where the barriers of entrance for front-end development or high, it's also interesting to consider all the places where that bar has been lowered. It's particularly cool for me to see front-end development grow and grow to the point of nearly swallowing up the entire stack. The All-Powerful Front-End Developer, as it were.

It reminds me an awful lot of how powerful being a WordPress site-slinger feels. You can do a lot, even if you don't deeply understand every little bit of it.

My conference acquaintance went on:

Why are some developers so proud of being a full stack? Many of them say it with a prideful smile. They, for some reason, feel the need to emphasize full stack when introducing themselves.

I suspect it's just that: Pride.

Pride is a tricky thing. It meant the world to me when my parents ceaselessly told me they were proud of me or something I did. A positive thing on both sides. But, strangely enough, pride is also one of the seven deadly sins and one, as they say, that might be the root of all the rest. I don't want to over-blow things, but I think there is some connection here. It's one thing to be empowered and to feel strong and capable, but it's another to be boastful and not sense the edges of your ability.

We've all got plenty of edges, particularly when it comes to doing an exemplary job versus merely getting the job done. Standing out these days requires being exemplary. How is your visual design skill? Are you building design systems or implementing existing ones? How many years have you maintained systems? Do you have a good eye for the most painful kinds of technical debt? How are you at helping co-workers succeed? Can you facilitate a user testing session? How good are you at diagnosing performance bottlenecks? What if there are serious server problems? Does your full stack moniker help you comprehend server logs? Are you versed in accessibility audits? Have you ever dealt with tricky relational data and slow queries?

I'm not trying to convince anyone they aren't a full-stack developer or don't deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills. If you're interviewing for a job asking for a full-stack developer, by all means, tell them how full-stack-y you are.

The post What Does it Mean to Be “Full Stack”? appeared first on CSS-Tricks.

😉SiliconWebX | 🌐CSS-Tricks

[mariaaklnthony]

My Accessibility Journey: What I’ve Learned So Far

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

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

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

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

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

Accessibility is exciting

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

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

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

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

1. Accessibility is a broad concept

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

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

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

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

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

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

2. There are permanent, temporary, and situational impairments

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

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

3. The first step is to make accessibility a requirement

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

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

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

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

4. Making accessible sites is a team sport

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

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

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

5. Communication is key

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

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

Highlight the benefits beyond accessibility

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

Challenge your colleagues

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

Help people empathize

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

6. Talk about accessibility before a projects kicks off

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

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

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

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

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

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

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

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

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

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

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

10. Keep learning about accessibility and share your knowledge

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

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

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

Share your knowledge

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

Go to conferences and meetups

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

Organize meetups

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

Invite experts to your meetup or conference

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

Follow accessibility experts on Twitter

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

11. Simply get started

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

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

Video series

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

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

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

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

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

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

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

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

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

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

[pattersondonaldblk5]

My Accessibility Journey: What I’ve Learned So Far

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

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

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

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

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

Accessibility is exciting

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

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

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

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

1. Accessibility is a broad concept

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

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

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

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

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

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

2. There are permanent, temporary, and situational impairments

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

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

3. The first step is to make accessibility a requirement

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

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

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

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

4. Making accessible sites is a team sport

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

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

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

5. Communication is key

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

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

Highlight the benefits beyond accessibility

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

Challenge your colleagues

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

Help people empathize

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

6. Talk about accessibility before a projects kicks off

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

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

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

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

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

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

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

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

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

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

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

10. Keep learning about accessibility and share your knowledge

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

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

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

Share your knowledge

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

Go to conferences and meetups

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

Organize meetups

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

Invite experts to your meetup or conference

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

Follow accessibility experts on Twitter

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

11. Simply get started

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

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

Video series

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

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

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

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

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

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

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

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

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

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

[suzanneshannon]

Telling the Story of Graphic Design

Let me just frame this for you: we're going to take a piece of production UI from a Sketch file, break it down into pieces of information and then build it up into a story we tell our friends. Our friends might be hearing, or seeing, or touching the story so we are going to interpret and translate the same information for different people. We're going to interpret the colors and the typography and even the sizes, and express them in different ways. And we really want everyone to pay attention. This story mustn't be boring or frustrating; it's got to be easy to follow, understand and remember. And it's got to, got to, make sense, from beginning to end.

I've asked my colleague Katie to choose a component she has designed in Sketch. I'll go through and mark it up (we mainly use SCSS, Twig and Craft but the templating language is not very important), then she will respond briefly. Hopefully I'll get most of it right, and then one or two things wrong, so we can look at how things get lost during handoff.

In white label or framework type front-end, the focus is on building pieces that are as flexible and adaptable as possible, as content and style-agnostic as possible (within the scope of the product), because you simply will never know where the code is going and for what, ultimately it is being used. But recently I moved to a web design agency, which has a complete inversion of this focus. It is particular. It is bespoke. It's all about really deeply engaging with the particular client you have and the particular clients they have, and designing something that suits them, as a tailor would.

Working so closely with a graphic designer like Katie, with highly finished pixel-spaced UI, instead of directly from wireframes or stories is an adjustment and an education, but there are still lots of things I can bring to the table. Chiefly: document design.

Document design, which admittedly is just the old semantic web with an accessibility hat on, is really looking at graphic design, engaging with it as a system of communication, and translating the underlying purpose of the colors/type/layout into an accessible, linearizable, and traversable DOM. It's HTML, kids. It's just HTML. You'd think we all knew it by now… but look around you. You'd be wrong!

Katie has slung me a Sketch file chock full of artboards, and she's pretty great at writing out what she wants so I don't have to think too hard:

Event card

First I look through the whole UI file and figure out what is actually a card on this site — it turns out there are six or seven components that use this paradigm. Let's make some observations:

Zoom out on section of artboards

Another card, classes this time.

A card is a block of meta data about a page on the site.

It has an image/media and metadata — it's a media object.

It's shown in a group of objects.

That group is always typed (there's no view where there are search results and news articles and classes are all mixed up).

Each object has a single link to a page and no other actions.

Each object has a call to action (Book, etc.).

Each object may have times, categories, badges, and calls to action.

Each object must have media, title, and link.

So a card is the major way my user is going to find their way around this site. They are going to be clicking through guided pathways where they get a set of cards they can choose from, based on top pages like "what's on" or "classes." They're not getting options on this card. It's not really an interactive element — it's a guide, an index card, that sets her onto her path: in this case a purchase path where she books a ticket for a show at this arts centre.

Before going on, let me just frame this for you:

Imagine you were looking at a flyer for a show and discussing it on the phone. If you actually wanted to go to this show in real life. What would you do? You wouldn't just read the flyer out, would you? That's the text. And it might have all kinds of random stuff on it if you started literally at the top. You wouldn't start with "Twentieth Century Fox" or "Buy Hot Dog Get Cola Free" or "Comedy Drama Musical Family Friendly." (I would actually hang up on you if you did!) And you wouldn't simply describe the color or fonts. That's the CSS. You'd talk through the information on the flyer. You'd say, "It's The Greatest Showman and it's on Tuesday, starts at 7:30. It's at the Odeon on Oxford Street by the tram." Right?

This is the document. Keep that person on the phone in your mind.

Count, group, and name

So let's say we'll deliver a card as the inside of a list item. We want a group and that group should be countable. We've already named the page with an <h1> so we'll introduce and describe the group with a heading, an <h2>. First we'll name it, then we'll deliver it, so someone using a screen reader can:

Get the list signaled in the headings overview.

Get a count up front of the number of items on a page.

Know they can skip to the next list item to get the next card.

Know they can skip the group at any point and go to the next page — the pagination is the very next element and it will be labelled as a landmark.

See the Pen Cards delivered as a countable list with descriptive heading by limograf (@Sally_McGrath) on CodePen.

Anchor

In this particular case, I'm gonna wrap this whole card in an anchor element (<a>). There's only one link on the card and I want to front load that information so someone can click as soon as they know it's the right card, instead of having to search forward for the action. A big clickable area is nice too, though of course that can be taken too far and make an interface a sort of booby trap! But these cards are not too enormous and I can see they have a nice gutter around them, so there's a rest space that will reduce accidental clicking for people with more limited dexterity.

Title

Event card "title" element

Then we'll jump down a heading level and mark up the name of each show as a heading, an <h3>. The designer has made this type the focus and we will too. Some people browse super fast by jumping to the next heading, then next heading, so I'm not going to put any important information before the heading — they'll jump right over it. I will put the image there, though, as I know in this case, I can't get meaningful image descriptions from the API so those images are hidden and have empty alt attributes. Now the user can guess (correctly in my case) that the developer is actually describing the content in some meaningful way and might flip back to headings overview (list headings level 3) and just get a list of the shows.

Now let's deliver our metadata. Let's list it:

Badge

Date/Time

Categories

Badge

Event card "badge" element

This seems to be something the venue adds to a card to highlight it. As a developer, I can't immediately see why a user would look for this, but it's emphasized strongly by the designer, so I'll make sure it stays in. Katie has moved the badge up out of the flow, but I know that with a headings jump our user could miss it. So I'll just put the wording directly after the title, I think. I'll either put it first or last, so make it easier to account for in a non-visual browse and not be too crazy paving in a tabbing, visual browse.

<p class="c-card__badge"><abbr title="Harrow Arts Centre">HAC</abbr> Highlight.</p>

...But on second thought, I won't put an <abbr> after all. It's the brand color, so it's really a statement of ownership by this venue, and we've already said HAC a million times by now, so the user knows where they are.

<p class="c-card__badge">HAC Highlight </p>

See the Pen Badge by limograf (@Sally_McGrath) on CodePen.

A quick aside: the 'badging' is very specific to this organisation. They want to show people clearly and quickly which events they've programmed themselves, and which are run by other organizations who've hired their venue.

Date/Time

Event card "date/time" element

Now date and time. Katie is keying me in to this decision point by styling the dates in bold. Dates are important. I'm going to pop it in an <h4>, because I'm thinking it looks like someone might be quickly scanning a page of events looking for the matinee, for example, or looking for a news article published on a particular day. I don't always put dates into headings, especially if there are millions on a page, but I do always make sure they're in a <time> element with a complete value so the <time>Thu</time> or <time>Mon</time> Katie has specified is read out as comprehensible English words "Thursday" instead of garblage. I could also have used hidden completion or <abbr> with a title.

Categories/ Tags

Event card "categories/tags" element

Next come the categories, and I'm putting them after badge and date. This section is next in the visual order reading top-to-bottom, left-to-right, of course, but it also seems to be deprioritized: it's been pushed down on the left and the type is smaller. This works for our linear storytelling. As a rule, we don't want people to sit through repeated or more general content (cinema, cinema, cinema) to get to unique or more specific content (Monday, Tuesday, Wednesday). Remember, we are inside our card: we know it has already been sorted in a few general ways (news, show, class, etc), so it's likely to have a lot of repeated pieces. We want to ensure that the user will go from specific to general if we can.

There is a primary category that is sorted first and then some other categories sometimes. I won't deliver this as a countable list as there's mostly just one category, and loads of lists of one item is not much use. But I will put a little tag beforehand because otherwise, it's a slightly impenetrable announcement. MOVEMENT! SPOKEN WORD! (I mean, you can work it out retrospectively, but we always try to name things first and then show them, in linear order. This isn't Memento.) I used to use title="" fairly heavily but I've gotten complaints about the tooltip so I route around. Note the use of colon or full stop to give us a "breath." That's a nice bit of polish.

<p class="c-card__tags h-text--label> <span class="h-accessibility">Categories: </span> </p>

Also I'm hard-coding in my spaces to make sure the categories never run together into complete garblage even with text compression or spaceless rendering turned on somewhere down the pipeline. (This can happen with screen readers and spans and it's rather alarming!)

There's a piece of this design I will do in the CSS but haven't really pulled into the document design: the color-coding on primary category. I am not describing the color to the reader as it seems arbitrary, not evocative. If there were some subtextual element to the color coding beyond tagging categories (if horticultural classes were green, say), then I might bring it through, but in this case it's a non-verbal key to a category, so we don't want it in our verbal key.

I'm sorting the primary category to the front of the category paragraph, but I'm not labeling it as primary. This is because there's a sorting filter before this list that sorts on primary category, and it's my surmise that it would be easier and less annoying to select a category from that dropdown than to read through each card saying Categories Primary Category Music Secondary Categories Dance. I could be wrong about that! Striking a balance between useful and too much labeling is sometimes a bit tricky. You have to consider the page context. We may be building components but our user is on a page.

See the Pen Dummies in page context by limograf (@Sally_McGrath) on CodePen.

Action

Event card "action" element

Last, the action. The direction to the user, to Book, or Learn More, or whatever it is, has been styled as a button. It's not actually a button, it's just a direction, so I'll mark it up as a span in this case. I definitely want this to come last in the linear document. It's a call to action and also a signal that we've reached the end of this card. The action is the exit point in both cases: if the user acts, we go to the target entry; if they do not, we go to the next card. We definitely never want any data to come after the action, as they might have left by then.

See the Pen Card by limograf (@Sally_McGrath) on CodePen.

My conclusion

This markup, which counts, groups, and names data, delivers linear and non-linear interactions. The page makes sense if you read it top to bottom, makes sense if you read parts of it out of context, and helps you jump around.

Katie, over to you...

Katie Parry, designer

What an ace article! Really interesting. (I particularly like that "Mon," "Tue," etc. on cards are read as "Monday," "Tuesday"... smart!)

One thing that struck me is that using assistive tech means users get information served to them in a "set" order that we've decided. So, unless there's a filter, someone browsing for dance events, for example, has to sit/tab through a title, badge, dates, and maybe several other categories to find out whether an event's for them or not. Bit tiresome. But that's not something you've got wrong — it's just how the internet works. Something for me to think about in the future.

Most of our clients are arts and cultural venues that need to sell tickets for events so I design a lot of event cards. They're one of the very first things I'll work on when designing a site. (Before even settling on a type hierarchy for the rest of the site.)

Thinking visually, here's how I'd describe the general conventions of an event card:

It must look like a list – so people understand how to use it.

It needs to provide enough information for folks to decide if they're interested or not. (The minimum information is likely an image, title, date, and link.)

It needs to include a clear call to action — usually a link to find out more information.

It needs to be easily scannable, visually.

Making information visually scannable is a pretty straightforward case of ensuring every information type (e.g. image, title, date, category, link) is sitting in the same place on every card and follows a clear hierarchy.

I focus a lot on typography in my work anyway but clearly: titles are styled to be highly prominent; dates are styled the same as each other but are different from titles; categories look different again – so that folks can easily pick-out the information they're interested in from simply scanning the page. I'm composing the card for the user, saying, "Hey, look here's the event's name, this is when it's on — and here's where you go to get your tickets!"

The type styles – and particularly the spacing between them – are doing a lot of work, so I will point out here that the spacings are not quite right in the code sample:

Spacing between the title and dates, dates and button, and button and piping don't match the design.

This is important. Users need to be able to scan information quickly as they aren't all looking for the same thing in order to make the decision to go to an event. Too much or too little space between elements can be distracting.

Here, let me tighten that up for you:

See the Pen Card with accurate spacings by limograf (@Sally_McGrath) on CodePen.

Perfect!

Some people just want a general mooch at what's coming up at their local venue. Others may have seen an advert for a specific show that tickles their fancy, and want to buy tickets. There are people who love music but don't care for theatre who just want a list of gigs; nothing else. And some folks who feel like going out at the weekend but aren't that fussed about what it is they go to. So, I design cards to be easy to scan — because most users aren't at all reading from top to bottom.

Despite the conventions I just laid out, cards certainly don't all look the same — or work in the same way — across projects.

There is always a tension in web design between making an interface familiar to the user and original to the client. Custom typefaces and color palettes do a lot here, but the other piece of it is through discovery.

I spend time reading-up about a client, including who their audience is by reading what they say on review sites and social media, as well as working directly with the client. Listening to people talk through how they work, what feedback they get from their audience/users often uncovers some interesting little nuggets which influence a design. Developers aren't typically involved much in discovery, which is something I'd like to change, but for now, I need to make it super-clear to Sally what's special about this event card for each new project. I write many, many (many) notes on Sketch files, but find they can tend to get lost, so sometimes we have a spreadsheet defining particular functionality.

And soon a data populator instead! :P

See the Pen Cards in page context, scraped from production by limograf (@Sally_McGrath) on CodePen.

The post Telling the Story of Graphic Design appeared first on CSS-Tricks.

Telling the Story of Graphic Design published first on https://deskbysnafu.tumblr.com/

[dustinwootenne]

My Accessibility Journey: What I’ve Learned So Far

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

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

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

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

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

Accessibility is exciting

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

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

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

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

1. Accessibility is a broad concept

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

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

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

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

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

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

2. There are permanent, temporary, and situational impairments

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

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

3. The first step is to make accessibility a requirement

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

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

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

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

4. Making accessible sites is a team sport

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

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

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

5. Communication is key

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

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

Highlight the benefits beyond accessibility

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

Challenge your colleagues

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

Help people empathize

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

6. Talk about accessibility before a projects kicks off

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

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

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

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

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

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

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

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

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

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

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

10. Keep learning about accessibility and share your knowledge

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

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

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

Share your knowledge

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

Go to conferences and meetups

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

Organize meetups

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

Invite experts to your meetup or conference

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

Follow accessibility experts on Twitter

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

11. Simply get started

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

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

Video series

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

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

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

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

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

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

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

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

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

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

[jeanshesallenberger]

My Accessibility Journey: What I’ve Learned So Far

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

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

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

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

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

Accessibility is exciting

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

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

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

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

1. Accessibility is a broad concept

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

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

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

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

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

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

2. There are permanent, temporary, and situational impairments

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

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

3. The first step is to make accessibility a requirement

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

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

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

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

4. Making accessible sites is a team sport

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

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

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

5. Communication is key

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

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

Highlight the benefits beyond accessibility

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

Challenge your colleagues

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

Help people empathize

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

6. Talk about accessibility before a projects kicks off

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

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

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

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

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

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

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

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

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

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

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

10. Keep learning about accessibility and share your knowledge

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

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

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

Share your knowledge

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

Go to conferences and meetups

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

Organize meetups

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

Invite experts to your meetup or conference

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

Follow accessibility experts on Twitter

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

11. Simply get started

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

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

Video series

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

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

Books

Heydon Pickering’s Inclusive Design Patterns

Laura Kalbag’s Accessibility for Everyone

Blogs

Adrian Roselli

The Paciello Group

Newsletters

WebAIM newsletter

A11yWeekly

Accessible JavaScript components

Inclusive components

Frend

a11y-dialog

Resources and further reading

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

“Growing an Accessibility Meetup” (article)

“Every Day Website Accessibility” (video)

“5 Common Misconceptions About Web Accessibility” (article)

“Designing the Conversation” (video)

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

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

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

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

“Writing CSS with Accessibility in Mind” (article)

“Understanding Progressive Enhancement” (article)

http://ift.tt/2ENHNjr

[dorothydelgadillo]

How to Easily Up Skill and Make More Money

If you’re on the job market, you know you need to make your resume stand out. But beyond your years of work experience, what if there were some extra skills you could easily add to your resume that would increase not just your hireability, but also set you up for a higher starting salary? Time is precious and it might seem impossible, but it’s actually completely doable with minimal upfront investment (I’m not talking about going back for another degree here).

So, where should you even begin? To answer this question, I picked the brains of HR and recruiting professionals to learn what kind of skills make a difference to employers—and how much of salary bump you can expect from each.

Coding Languages

Right off the bat, there are the usual suspects—HTML, CSS, JavaScript, and WordPress make a solid foundation for coding languages, and a great example of where up skilling can come into play. Being fluent in these languages maximizes your flexibility, and can provide a compelling case to employers to start you at a higher rate or salary—regardless of industry.

Xavier Parkhouse-Parker, Co-Founder and Director at digital recruiting firm PLATO Intelligence, says that if an applicant can stack a high level of HTML coding knowledge on top of the specialized role they’re applying for, it’s possible to aim for a 25 percent starting pay bump when negotiating a salary. Jonathan Lau, Founder and CEO of coding school directory SwitchUp, adds that SwitchUp’s 2016 job outcome survey for coding bootcamp graduates found that 63 percent of graduates reported increases in salaries after completing a bootcamp program. (Among those graduates, the average gain was $22,700.) With these kind of numbers in mind, it’s clear that adding some coding know-how to your toolkit is a wise investment in your career future, whether or not you’re specifically interested in developer roles—since having programming skills means you can work in virtually any field.

Go Open-Source

Beyond HTML, CSS, and WordPress, Elizabeth Becker, Client Partner and Tech Recruiter at the software recruiting company PROTECH, suggests going open-source. What does that mean? Open-source software is computer software whose source code (the code that makes it work) is open to the public and the software itself is free to use. Examples of open-source software include web browsers like Firefox, operating systems like Linux, and content management systems like WordPress. Because of its collaborative and free-to-use model, Becker says that an increasing number of employers are adopting open-source software platforms, which means an increased demand for tech professionals with open-source skills. The open-source model also means there’s nothing preventing you from picking up these skills on your own—open-source software is free, and is often just a few clicks away via your web browser.

Becker cites knowledge of AngularJS—an open-source JavaScript-based framework (collection of common JavaScript functions) developed by Google—as an example of an in-demand open-source skill to have. “[Even] being able to include a completed training course on AngularJS on your resume [can] validate your skills, especially if you don’t yet have job-related experience with it,” Becker says. “I often see highly skilled open-source professionals being able to command 10-15 percent higher salaries than other professionals without open-source experience.”

It’s not a bad idea to start taking a look at what open-source software you’re already using and spending some time getting a better understanding of how it works—in the case of Becker’s example of AngularJS, you can dive deeper with resources like the AngularJS Google Group, AngularJS questions at Stack Overflow, and W3Schools’ AngularJS Tutorial.

Search Engine Marketing

Search Engine Marketing (SEM) is the practice of using techniques like Search Engine Optimization (SEO) and Keyword Research (more on these below) to increase a website’s visibility on search engines like Google, Bing, and Yahoo. According to Steve Pritchard, HR Consultant at mobile phone provider giffgaf, it’s also a skill that can fire up your resume and lead directly to more money when negotiating for a job. “Knowledge of how to get a business’ website to appear higher in Google rankings…is a…skill that every business should be keen to capitalize on. The return on investment [is] well worth [a bump in] salary,” Pritchard says. How much of a bump? Pritchard estimates that applicants with a track record of a couple successful SEM campaigns could increase their salaries by as much as 15 percent.

Whether you’re learning web development, breaking into digital marketing, or working as a digital designer, two of SEO’s main building blocks—SEM and Keyword Research—are skills you can (and should!) start experimenting with on your own. Not only can those skills lead to the kind of salary increase Pritchard describes, but SEO is invaluable in promoting your own brand and presence online: Knowing how to maximize your projects’ searchability is crucial for standing out from the pack.

Start by reading through Google’s own SEO Guidelines, which should give you a jumping-off point for the next time you’re reworking your personal or business website. You can incorporate some SEO best practices easy with small tweaks like creating user-friendly URLs to make a website more searchable (for instance, “www.yourkillerwebsite.com/tips-for-up skilling” instead of “www.yourkillerwebsite.com/qs?/3600”) and integrating responsive/mobile-friendly design (Google uses mobile-friendliness as part of its site ranking system). Next, dive into online resources like Moz’s Beginner’s Guide to SEO, and Webmaster World (an online forum for SEO talk).

Researching web search keywords that can drive traffic to your site or project is another crucial element of SEM—by getting a handle on the keyword demand for your website you’ll not only get a better idea of what keywords to incorporate in your site’s searchable text and content, you’ll also piece together a picture of what your site’s potential visitors are looking for. You can try using a tool like Google AdWords Planner (a free program that requires an AdWords account, but doesn’t require you to actually create an ad) to research information on the volume of searches your keywords produce and decide which ones should be used prominently on your site.

As you read about, practice, and get a handle on these SEM skills, you’ll eventually be able to add SEM literacy to your resume, and—regardless of whether you’re looking to work as a web designer or a web developer—boost your value to potential clients and employers.

Microsoft Excel and Microsoft Word (No, Seriously.)

With so much emphasis on advanced coding and design skills, it’s easy to overlook basic, old-fashioned computer know-how. While having these skills might seem like a no-brainer, Dawn D. Boyer, Ph.D. and CEO at Boyer Consulting, says otherwise.

“I can’t tell you how many high school students in their first year of college taking my IT courses have never opened an Excel spreadsheet,” Boyer says. For Boyer, this creates a disconnect when it comes to the practical reality of making things more efficient and easier in the working world. Similarly, Boyer says that database management is another overlooked computing skill that goes a long way in business.

According Boyer, Microsoft Word is the most important office software program to learn, followed by Excel. “Everyone has to write something in their work,” Boyer says, “and if you have the ability to use Word paragraph and tabs formatting, as well as spell check, grammar and punctuation check, you are halfway to being more proficient in the software than about 80 percent of the competition for a job. [You’d be surprised] how many…Ph.D. students can’t format a document for margins, paragraph indents, and tabs, or even insert a table, [yet] are out on the job market.” As for Excel, Boyer says that vital functions to have a handle on are vertical lookup—a function used to lookup and retrieve data from specific columns in a table—and knowing how to create formulas—expressions that calculate the value of a spreadsheet cell.

If you’re feeling particularly lost when trying to find your way around routine office software, consider taking an online class to get yourself up to speed. Excel, Access, Powerpoint, and Word might not be as exotic as Ruby on Rails, but they’re a solid bump up in well-rounded resume skills. Boyer says that it’s difficult to cite specific salary increases due to the amount of other factors involved (education, years of experience, overall skill set, etc,), but to think of these extra skills as a vital way to get yourself to the head of the application process.

Human Resources and Leadership Experience

HR skills give you an excellent chance at getting employers to pay more, says Georgene Huang, CEO and Co-Founder at Fairygodboss, from hiring to leading teams.

According to Huang, management experience is a crucial skill to leverage on a resume. The larger and more diverse teams you’ve managed, the higher the chance you have at commanding extra pay. Whether it’s heading a team of developers, or managing a team of sous chefs, the same basic principles of leadership apply.

Specific experience with hiring, firing, and navigating difficult situations (company pivots, large scale business model changes, or moving from old business systems to building new ones) also builds a strong case for a higher starting salary. Again, think back and think big—it might feel like you don’t have this kind of experience, but when you start to drill down you might be surprised at what’s applicable. That time you chaired your kids’ school’s PTO board, helped overhaul the yearly fundraising programs, and participated in revamping the music program? It counts!

Finally, Huang says that abilities that demonstrate leadership like communication and presentation skills can go a long way in upping your value. And if you’re petrified by the thought of public speaking—don’t panic! Try some mock presentations with family and friends—and if you feel like you still need some work in the public speaking department, think about taking a quick speech class at your local community college or business school. In Huang’s experience, the kind of leadership, decision making, and communication skills she’s described can result in a 20-30 percent higher starting salary than applicants unable to demonstrate those skills.

Speaking a Second Language

Nora Leary, Co-Founder and Head of Marketing and Business Development at marketing firm Launchway Media, says that—due to her work with an international internship company—she’s always looking into the economic impacts of spoken language skills. She cited studies covered by The Economist that demonstrate knowing a second spoken language correlates to about 2 percent more in annual income—which may not sound like much, until you start to crunch the numbers. The Economist extrapolates that even a 2 percent bump on a $45,000 a year salary can lead to as much as an extra $67,000 over the course of a 40-year working career, if you were to set aside your language bump in savings and figure in compound interest.

If you’re looking to learn a second language, try classes at your local college, online classes, or even apps like Duolingo.

Show Me the Money

So you’re an SEM wizard, you’re strapped with a Rolodex of open-source certifications, you have an Excel tattoo, management skills are oozing from your pores, and you just spent the morning coding a Riverdale fan website. How exactly do you put this all together and communicate it to employers, short of an embarrassing, “show me the money” meltdown?

“A resume is the most important vessel in a job search,” says Brianna Rooney, Founder and Lead Technical Recruiter at tech recruiting firm Techees.  “[That] or a thorough LinkedIn.” Rooney warns that an employer will be spending mere seconds looking at your resume, so it’s critical you get straight to the point. List your background and skills explicitly and efficiently without a lot of filler. Remember, there’s no way for potential employer to know you have these skills unless you tell therm. In Rooney’s experience, a qualified resume combined with an array of bonus skills can tack on as much as $20,000-$40,000 more to a starting salary. “That is,” Rooney says, “if you interview well.”

So there you have it—a robust skillset presented in a crisp, comprehensive resume can be your ticket not only to landing a job, but landing it at above entry-level pay. And while there’s no magic combination of skills that guarantees a dream salary, it’s clear from talking to these pros that having an array of versatile skills above and beyond the bare minimum—whether it’s a combination of coding tools or speaking Mandarin—goes a long way towards improving your chances for a salary that truly reflects all your hard work.

from Web Developers World https://skillcrush.com/2017/12/04/how-to-easily-up-skill-and-make-more-money/

[euro3plast-fr]

How ecommerce can increase conversions with AMP

An easy, visual guide to help you implement AMP for ecommerce to increase conversions

E-commerce is all about creating an amazing shopping experience online for the visitor with the intention of getting them to click, convert, and become a customer.

With changes in consumer shopping behaviors, online brands have had to adjust how they market to prospective customers, as well as the user experience, to ensure an enjoyable experience.

The largest change has come from the adoption of mobile technology.   There are more than 4.9 billion people globally utilizing smartphones, representing around 66% of the world’s population.

And as of January 2017, mobile phones accounted for 50% of internet traffic. That’s a 30% increase from last year alone.

That growth has triggered a need for more streamlined mobile shopping experiences, but not all brands made the jump right away. Without mobile-optimized sites, mobile users were experiencing high site loading times and having difficulty getting the information and items they wanted while on their phone.

That’s where Google stepped in.

In 2015, Google launched its Accelerated Mobile Pages (AMP) framework to create web pages that load much faster on mobile devices. It was created as an open source initiative that would allow publishers and online brands the ability to ramp up the load speed and reduce wait times for online users.

This kind of optimization was already attainable with the right developers on hand, but not all brands have the resources capable of intensive remodeling of their sites in order to tend to the mobile experience.

Why AMP is Important

With AMP, it all comes down to speed.

Search engines like Google survive by the positive experiences of the user who can find the information they want/need quickly, without long delays. It’s in their best interest to make sure the user has the best experience.

That’s why site speed was added as a ranking factor. If your site takes too long to load, and your customers are bouncing, you’ll likely see that negatively impact your organic search visibility.

For online brands, you not only want to protect your organic search rank by creating a fast-loading experience, embracing AMP also improves conversions.

Check out the figures from this infographic shared by Kissmetrics:

The full data on the infographic reveals a few key things.

The big one is that roughly 44% of mobile users expect a site to load as fast as a desktop experience or faster. When that performance drops and you don’t meet expectations—guess what?

Prospective customers bail and may not come back.

What’s worse is that for every delay of just one second in your load time you take a 7% hit in your conversation rates because visitors start bailing.

If the average rate of cart abandonment is about 68%, imagine how that would be climbing if a large portion of your audience is on mobile and your site loads so slow they get impatient and leave.

How Accelerated Mobile Pages Are Implemented in E-Commerce

The visitors on your site come from any number of landing pages, from your homepage to product and categories, and even blog posts. While it’s important to optimize the visitor’s shopping experience, it isn’t necessary to implement AMP on every page.

Instead, look at the visitor flow through your site so you can visualize your customer journey or funnel and employ AMP at key points through the process.

This is necessary because AMP depends on simplified JavaScript and CSS and will limit or restrict some other CSS and JavaScript, such as no iframes and a lack of support for JavaScript library such as those used for loading reviews.

The simplified framework of AMP is what allows pages to load quickly. Paul Shapiro lays out the three elements of this framework in his post for Search Engine Land:

AMP HTML: A subset of HTML, this markup language has some custom tags and properties and many restrictions. But if you are familiar with regular HTML, you should not have difficulty adapting existing pages to AMP HTML. For more details on how it differs from basic HTML, check out AMP Project’s list of required markup that your AMP HTML page “must” have.

AMP JS: A JavaScript framework for mobile pages. For the most part, it manages resource handling and asynchronous loading. It should be noted that third-party JavaScript is not permitted with AMP.

AMP CDN: An optional Content Delivery Network, it will take your AMP-enabled pages, cache them, and automatically make some performance optimizations.

If you use a content management system such a WordPress and Magento, or e-commerce platforms like Shopify, you can find third-party plugins.

There’s an official WordPress plugin for AMP available on GitHub that you would upload just like any other WordPress plugin.

  Key Benefits and AMP Element Implementation in E-Commerce

With the limitations of AMP, you won’t be able to use it where you have things like form elements and third-party JavaScript, but there are still plenty of opportunities for utilizing AMP in e-commerce throughout the customer’s shopping experience—just not in the checkout.

If you’re still not sure how or where to use AMP on your e-commerce site or how it could benefit you, here are some examples of AMP implementation.

Reduced Bounce Rates To Site Pages

Remember the bit above about how slow load times can make visitors bail on the experience? That impacts your bounce rate which is one of many ranking factors. One of the major benefits of AMP is reducing that bounce rate since mobile users are going to spend more time on your site, and view more content.

So that secondary benefit of improving load times is a bump in visibility. Your site will rank better than similar sites without AMP implementation.

Look at the two versions of this page to see how content is trimmed for efficient loading:

Improved Click-Through Rates in SERPs

One way Google lets users know about an optimized mobile experience is through the use of the AMP symbol. When a site has implemented AMP, the algorithm will display this symbol within the search results.

This symbol can help your content stand out in the search results, and once more consumers begin to recognize that AMP content loads faster they’ll be more likely to continue looking for that content in the search results.

Media Rich Page Optimization

Customers are most likely to land on your homepage and your category pages, but product landing pages or product detail pages are also a possibility just like any other page on your site.

If you’re linking to or grabbing referral traffic on media-rich pages you can implement AMP on these pages to improve image load time as well as how video is handled on mobile. Like images, there is a custom AMP tag for locally hosted videos in HTML5 called amp-video.

However, if you’re using videos hosted on YouTube like many online brands due then you would use a separate component called amp-youtube.

For other image-handling needs, AMP also has support for slideshows using amp-carousel as well as lightbox support with the amp-image-lightbox tag.

These can greatly improve the load time for homepages and category pages that often contain the most content and act as the most common landing pages for visitors.

Handling Detail Rich Pages

Any extra content takes time to load, even if it’s just text. If you have detail-rich product pages or information pages you can use the amp-accordion element to condense information until a visitor calls for it when it expanding the accordion or section.

Not only with this speed up load time but it improves the visitor experience by allowing them to only load or ‘jump to’ the content they’re specifically interested in.

CSS selectors can be even used to style the accordion element.

Customized Shopping with AMP

Conversion rate optimization should always be a priority for e-commerce brands, but not at the expense of the user experience, load times, etc. One always benefits the other. Thankfully, no sacrifice has to be made.

The amp-access element can be used to customize the content shown to users based on the status of the user, such as if they’re logged in or not. This allows you to personalize the shopping experience (which can improve conversions) while also trimming the load time for mobile users.

Conversion Optimization and User Experience Testing is Supported

With conversion in mind, you won’t have to sweat the simplification off CSS and JavaScript when working to improve conversion rates. The amp-experiment element is used to conduct user experience experiments such as A/B testing and multivariate testing.

This is a great way to see how individual page optimizations and AMP implementation are performing with your mobile users, so you know if your efforts are having a positive or negative impact.

Maintain Tracking Without Negatively Impacting Load Time

Any scripts that must be loaded can slow down the mobile experience, including tracking scripts. Running multiple analytics tracking scripts can compound this. The AMP analytics element streamlines tracking by taking the “measure one, report to many” approach.

There are two ways to implement tracking:

The amp-pixel element is a simple tag that allows you to count page views and track users with a number of customizable variables.

The amp-analytics extended component is the more in-depth analytics you might be more familiar with but requires a little setup to complete. It has built-in support for Google Analytics though for easy reporting once you have it in place. This is the best approach to track and measure user behavior and the performance of your content to continue improving the user experience.

AMP provides a basic demo of how some activities can be tracked.

Conclusion

While AMP does have some limitations that can make some tracking difficult, it’s highly recommended at key points in the buyer’s journey of your e-commerce site to optimize load times.

When you can improve the shopping experience and improve performance you will, without a doubt, improve the conversion rates of your online store.

Thanks to Emil Kristensen for sharing their advice and opinion in this post. Emil is the CMO and co-founder of Sleeknote, a company that helps ecommerce business owners capture and convert more leads without hurting the user experience.

from Blog – Smart Insights http://www.smartinsights.com/ecommerce/ecommerce-strategy/ecommerce-can-increase-conversions-amp-implement/

[mbaljeetsingh]

JavaScript-Based Animations Using Anime.js, Part 1: Targets and Properties

Anime.js is a lightweight JavaScript-based animation library. You can use it to animate different CSS properties, SVG or DOM attributes on a webpage. The library allows you to control all aspects of the animation and provides a lot of ways for you to specify the elements that you want to target or the properties that you want to animate. 

You have full control over the sequence in which the animations are played or how synchronized the animations of different elements are with respect to each other. The library supports all modern browsers, including IE10+. 

In this tutorial series, you will learn about all the features of Anime.js so that you can use them in real-life projects with ease.

Before diving deep into the topic, let's install the library first. You can use either npm or bower to perform the installation by running the following commands:

npm install animejs bower install animejs

You can also download the library and include it in your project or directly link to the latest version of the library hosted on a CDN.

<script src="path/to/anime.min.js"></script>

After a successful installation, you are now ready to use this library to add interesting animation to your elements. We will start with the basics of the library, focusing on one particular area at a time.

Specifying Target Elements

To create any animations using Anime.js, you will have to call the anime() function and pass it an object with key-value pairs that specify the target elements and properties that you want to animate, among other things. You can use the targets key to tell Anime.js which elements you want to animate. This key can accept values in different formats.

CSS Selectors: You can pass one or more CSS selectors as a value for the targets key. 

var blue = anime({ targets: '.blue', translateY: 200 }); var redBlue = anime({ targets: '.red, .blue', translateY: 200 }); var even = anime({ targets: '.square:nth-child(even)', translateY: 200 }); var notRed = anime({ targets: '.square:not(.red)', translateY: 200 });

In the first case, Anime.js will animate all the elements with a blue class. In the second case, Anime.js will animate all the elements with either the red or blue class. In the third case, Anime.js will animate all the even children with a square class. In the last case, Anime.js will animate all the elements with a square class that don't have a red class.

DOM Node or NodeList: You can also use a DOM node or a NodeList as a value for the targets key. Here are a few examples of setting the targets as a DOM node.

var special = anime({ targets: document.getElementById('special'), translateY: 200 }); var blue = anime({ targets: document.querySelector('.blue'), translateY: 200 }); var redBlue = anime({ targets: document.querySelectorAll('.red, .blue'), translateY: 200 }); var even = anime({ targets: document.querySelectorAll('.square:nth-child(even)'), translateY: 200 }); var notRed = anime({ targets: document.querySelectorAll('.square:not(.red)'), translateY: 200 });

In the first case, I have used the getElementById() function to get our special element. The querySelector() function is used to get the first element that has the blue class. The querySelectorAll() function is used to get all the elements within the document that match the specified group of selectors. 

There are a lot of other functions as well that you can use to select your target elements that you want to animate. For example, you can get all the elements with a given class name using the getElementsByClassName() function. Similarly, you can also get all the elements with a given tag name using the getElementsByTagName() function. 

Any function that returns a DOM node or a NodeList can be used to set the value of the targets key in Anime.js.

Object: You can also use a JavaScript object as a value for the targets key. The key of that object is used as an identifier, and the value is used as a number that needs to be animated. 

You can then show the animation inside another HTML element with the help of additional JavaScript. Here is the code to animate the values of two different keys of an object.

var filesScanned = { count: 0, infected: 0 }; var scanning = anime({ targets: filesScanned, count: 1000, infected: 8, round: 1, update: function() { var scanCount = document.querySelector('.scan-count'); scanCount.innerHTML = filesScanned.count; var infectedCount = document.querySelector('.infected-count'); infectedCount.innerHTML = filesScanned.infected; } });

The above code will animate the scanned files count from 0 to 1,000 and the infected files count from 0 to 8. Keep in mind that you can only animate numerical values this way. Trying to animate a key from 'AAA' to 'BOY' will result in an error. 

We have also used a callback function for the update key that is called on every frame while the animation is running. We have used it here to update the count of scanned and infected files. However, you could go a step further and show users an error message when the number of infected files goes over a certain threshold. 

Array: The ability to specify a JavaScript array as the target comes in handy when you have to animate a bunch of elements that fall under different categories. For example, if you want to animate a DOM node, an object and a bunch of other elements based on CSS selectors, you can do so easily by putting all of them inside an array and then specifying that array as a value for the targets key. The following example should make it clearer:

var multipleAnimations = anime({ targets: [document.querySelectorAll('.blue'), '.red, #special'], translateY: 250 });

Properties That Can Be Animated in Anime.js

Now that you know how to specify different elements that you want to animate, it is time to learn about all the properties and attributes that can be animated using the library.

CSS Properties: Anime.js lets you animate a lot of CSS properties, like the width, height, and color, for different target elements. The final values of different animatable properties like background-color and border-width are specified using a camel case version of that property. Therefore, background-color becomes backgroundColor, and border-width becomes borderWidth. The following code snippet shows how to animate the left position and the background color of a target element in Anime.js.

var animateLeft = anime({ targets: '.square', left: '50%' }); var animateBackground = anime({ targets: '.square', backgroundColor: '#f96' });

The properties can accept all kinds of values that they would have accepted when used in regular CSS. For example, the property left could be set to 50vh, 500px, or 25em. You could also specify the value as a bare number. In this case, the number would be converted to a pixel value. Similarly, the background color could be specified as a hexadecimal, RGB or HSL color value.

CSS Transforms: You can also animate different CSS transform properties using Anime.js. Translation along the x and y axes can be achieved using the translateX and translateY properties. Similarly, it is possible to scale, skew or rotate an element along a specific axis by using the scale, skew and rotate property corresponding to that specific axis. 

You can specify different angles either in terms or degrees or in terms of turn. The value of 1 turn is equal to 360°. This can make the calculation easier when you know how much you want to turn the elements in terms of complete rotations. The following example shows how to animate the scaling, translation or rotation of an element on an individual basis as well as all at once.

var animateScaling = anime({ targets: '.square', scale: 0.8 }); var animateTranslation = anime({ targets: '.square', translateX: window.innerWidth*0.8 }); var animateRotation = anime({ targets: '.square', rotate: '1turn' }); var animateAll = anime({ targets: '.square', scale: 0.8, translateX: window.innerWidth*0.8, rotate: '1turn' });

SVG Attributes: It is possible to animate attributes of different SVG elements using Anime.js. The only condition is that the value of those attributes should be numerical. This ability to animate different attributes opens up the possibility of creating some really cool effects. Since you are just starting to learn about Anime.js, we will keep the examples in this tutorial very basic. 

As we move forward, you will learn how to create more complex animations. Here is the code to animate the cx, cy and stroke-width attributes of a circle. Just like the CSS properties, you need to use a camel case version of stroke-width for the code to work.

var animateX = anime({ targets: '.circle', cx: window.innerWidth*0.6 }); var animateStrokeWidth = anime({ targets: '.circle', strokeWidth: '25' });

DOM Attributes: You can also animate numerical DOM attributes just like you animated the SVG attributes. One situation where animating a DOM attribute can be useful is the HTML5 progress element. This element has two attributes, value and max. In our example, we will be animating the value attribute to show the progress of our file transfer process. Here is the code to animate the value attribute.

var animateProgress = anime({ targets: 'progress', value: 100, easing: 'linear' });

Final Thoughts

In this tutorial, you learned about all the ways of selecting target elements in Anime.js and how to animate different CSS properties and attributes related to them. At this point, we are not controlling anything related to the actual animation. 

JavaScript is arguably the language of the web. It’s not without its learning curves, of course, and there are plenty of frameworks and libraries to keep you busy, as you can tell. If you’re looking for additional resources to study or to use in your work, check out what we have available in the Envato marketplace.

In the next tutorial of the series, you will learn how to control the easing, delay and duration of the animation for different properties as a group as well as individually. You will then learn how to control all these animation parameters for individual elements.

If there are any questions related to this tutorial or if you have used Anime.js in any interesting projects, please let us know in the comments.

via Envato Tuts+ Code http://ift.tt/2wpUxYz

[machinelearningstuff]

First Programs When Learning a New Language

There are several languages that are key to using in Machine Learning:

Elixir - the, “pipeline,” for robust, large amounts of data.

There are several, “rule of thumb” programs which are noted as being important to start out with writing:

Basic: Hello World

Python - Done.

Ruby - Done.

Javascript - Done.

Matlab - Done.

C++ - Done.

Elixir - Done.

Type casting: return int with reversed digits of int input

Elixir - Done.

Map: return a dict of letter counts in a string

Elixir

Recursion: Fibonacci

Pattern matching: extract phone numbers from a text file

DB: parse CSV and store in (no)SQL db

Elixir

Net: API endpoint that returns aggregate results from multiple external API request (use some sort of concurrency for requests and/or aggs?)

Data structures, text input: tic tac toe, battleship, or some similar game

Graphics, visual input: flood fill, line drawing, A* pathing, or somesuch

Data statistics: calc mean, max, min, 95% from a time series dataset for various time intervals (and graph them?)

Second opinion on the above:

DB

This one is library dependent. Most languages don't have something like linq. A lot of the DSLs that map SQL queries to your favourite language are at times not very performant as well. Many times, you end up using plain SQL or whatever NOSQL depending on how good the library is.

Net

Also library dependent unless you want to get into low level sockets which most people don't even remotely understand. On top of this, depending on what framework you're using (because no one makes a server from scratch nowadays when there are entire organizations dedicated to developing a framework) the library is different.

Tic-tac-toe/battleship

I work in software and I can imagine how i'd implement this, but I've never done it. Seriously have never found a reason to ever do this. This is some intro to cs shit. That's like asking "How to implement quicksort in X lang". Most of the time wont need it.

Graphics

I never work with graphics. I don't know jack shit about graphics. I'm a server side developer/security analyst and I don't need to know this shit. I'd hardly make this a must.

IMO, the entire problem with this thread and responses is you only need to memorize specifics once you work in something very often. I can sniff a network with scapy without looking at any references but if you ask me how to do this in C I have no idea, but give me a few hrs I could get it to work.

What people need to understand is that knowledge of concepts matter more than individual implementation. If you understand concepts from the ground up, you can work with any implementation.

More Advanced Things...

Consume an API ( REST / SOAP )

Create an API ( REST / SOAP )

Implement a few data structures ( Linked List / ArrayList / Binary Search Tree )

Implement a few algorithms ( A*, DFS, BFS, etc. )

Create some bot ( Discord, Reddit )

Scrape some website that doesn't have a public-facing API ( Craigslist )

Various side projects related / tied into your personal hobbies ( for me, cars )

Section 1. 2nd nature Basics: these should be things you don't have to think about

Simple Types. If you can't deal with words (Strings), numbers (integers, doubles, floats etc) and binary options (booleans), you cant really do anything useful for non technical humans to understand

Type Manipulation. if you cant convert 11 (as a string) into 11 (as an integer) then you cannot do a calculation with written numbers. If you don't know how

Logical loops and conditions. (e.g If, Else If, For Each, While, Switch Case etc. ) if you cant do this you cannot program anything useful... and for gods sake don't create a potentially infinite loop in your program.

I/O or Read/Write. if you cant take inputs from somewhere and provide an output, what's the point?!

Functions/methods and overloads. Learn how to create them and reuse them as often as you can whenever a similar problem presents itself.

Error handling AND LOGGING. no function should be without a try catch [turns out this is fairly specific to my specific application specifications]. use what you learned doing I/O and output the errors to a log file so you can see where things are going wrong, even if they don't cause unexpected behaviour.

Section 2. Necessary basics: these might require a little more thought in terms of how you optimise certain things, but definitely not challenging on a day to day basis.

Complex Types. Lists, collections, multidimensional arrays. all very useful when dealing with lots of data

Interfacing: how to create reusable interfaces to be used throughout your application

Classes and inheritance and class structure: This will form the basic structure of all your programs

I/O 2 Database transactions. so how to query SQL to get your data, and how to update tables with the results.

Section 3. stuff you should know but might want to look up occasionally

learn a structural framework (MVVM, MVC)

Front end (Xaml if you're doing WPF, HTML/CSS + a bit of JS for web)

Section 4 Everything Else:

Google.... no i'm serious, google has the answer to every question you could possibly want to ask about programming. so unless you are doing something groundbreaking and new, google will likely have your answer. so long as you have a solid grasp of everything i put above you should be able to integrate any solution provided on the web into your own code. but it's up to you to make it as efficient as possible...