Mittwochmorgen – Zeit für eine neue „GIFparade“! Wobei, dieses Mal ist die Ausgabe leider nur so halb neu, da ich zeitlich nicht groß dazu gekommen bin, wie gewohnt das Netz nach bewegten Bildern zu durchforsten. Entsprechend sind ein paar ältere Motive dazu gekommen, die ich noch auf Halde hatte (aber die bislang noch nicht in einer GIFparade vorgekommen sind!). Insgesamt sind es damit dann auch stattliche 40+8 bewegte Bildchen geworden. Nächste Woche gibt es dann hoffentlich wieder mehr „frische Kost“ für euch. Ich wünsche aber auch so gute Unterhaltung!

GIF der Woche: Face-Face

Hintergrund-Erklärung: Neu von den Machern von Facebook, Facetime und Notebook: „Face-Face“ (Patent Pending)! Was ausschaut wie eine neue Folge der atemberaubenden Science-Fiction-Gesellschafts-Satire-Serie „Black Mirror“ ist bereits greifbare Realität. Demnächst bei „Die Höhle der Löwen“ können Sie „Face-Face“ genauer vorgestellt und selbst vor das Face auf dem Bildschirm präsentiert bekommen. Der Clou: Man setzt sich einfach ein anderes Gesicht über das eigene! Dank modernste Flachbildschirm-Technologie lässt sich das ausgewählte Gesicht sogar beleuchten und bewegen. Wahnsinn. Noch dazu bietet Face-Face eine zubuchbare Audio-Option, die vorher eingegebene Texte in Sprache konvertiert, so dass eine andere Stimme als die eigene zu hören ist. Perfekt für alle, die eh schon mit einer Maske durchs Leben laufen. Denn sind wir doch mal ehrlich: In unserer heutigen Gesellschaft zählt nur der Schein. In Zukunft kann man richtig damit scheinen – mit „Face-Face“! Für schlappe 5.999 Euro können Sie ihr eigenes „Face-Face“ erwerben. Beim Standard-Tarif sind vier Gesichts-Optionen auswählbar. Weitere Basis-Exemplare sowie Accessoires, Tattooes und Looks sind gegen kleine Transaktionen hinzubuchbar. So ist das inviduelle „Face-Face“-Erlebnis für jede:n möglich. Ja, es klingt komisch, ist aber so: Wir leben in der Zukunft.

Image via Survival Condo

Time and again, a calendar predicts the next probable date for an apocalypse; and time and again, that date passes without a hitch. With a pandemic and a war going on in tandem, though, the concept doesn’t seem all that far-fetched.

Waiting in the wings at the end of time are luxury bunkers, with one of the most renowned being the Survival Condo.

Tucked away at a secret location north of Wichita, Kansas, the shelter welcomes families hiding from the grasp of a world-ending disaster. In its former life, it served as a missile silo for the US government during the Cold War.

Its owner Larry Hall purchased the property in 2007 for US$300,000 and dedicated nearly US$20 million into making it a place of escape for as many as 12 families and their pets.

Between walls of up to nine feet thick and 15 stories underground, the self-sufficient facility runs on various water systems, power supplies, as well as hydroponic food and aquaponic farming equipment. There’s a volcano ash remover in the event of a volcanic eruption too.

Image via Survival Condo

It’s capable of sustaining 75 residents for five years. And when the coronavirus swept the world, builders of the Survival Condo armed it with “Nuclear, Biological, and Chemical (NBC) air filtration [that] can filter out pathogens like COVID-19.”

“However, we cannot guarantee that you will not pick up the virus from direct or indirect contact with an infected person or object either before or after you arrive at our facility,” the website cautions.

While it’s all about keeping people alive, the condo doesn’t deny its occupants of luxuries like a swimming pool with a water slide, movie theater, library, gym, bar, dog park, rock climbing wall, arcade room, and more.

Image via Survival Condo

These privileges provide a touch of normalcy for residents who have been deprived of things like sunlight.

Image via Survival Condo

Speaking of sunlight, rooms are fitted with remote-controlled artificial windows that display fake scenery, given that the shelter is buried way underground. But they’re not just for ornamental purposes.

Image via Survival Condo

During a month-long stay at the bunker, Hall felt especially alone due to the less tangible cues of telling time. So he installed the LED windows to simulate the natural progression of day to night and help restore residents’ circadian rhythms.

Interestingly, a psychologist hired to make the bunker more comfortable persuaded its owners to build a supermarket, complete with shopping carts, to replace the dystopian “storerooms” drawn out on its blueprint. The space was to be like a “miniature Whole Foods,” Hall recounted in a statement via the Guardian, as the act of rummaging through cardboard boxes for rations would overwhelm people.

Bringing to mind the days of stockpiling during the pandemic, the toilets have a bidet system—like the sort in Japan—so there wouldn’t be a need for toilet paper, which take up too much storage space.

All this, of course, comes at a price. A half-floor unit will set you back US$1.5 million, while a full-floor apartment is priced at US$3 million and a 3,600-square-foot, two-story penthouse costs US$4.5 million. 

Image via Survival Condo

The news outlet cited one apartment that mimics a log cabin and has its own artificial fireplace.  

Hall emphasized in an interview with Insider in 2019, pre-pandemic, that the bunker’s high operational costs come from “the caliber” of its infrastructure, rather than its opulence. 

Residents also have to fork out an extra US$5,000 a month to pay for association fees, the Guardian notes. That’s evidently not an issue for the property’s clientele; as per Insider, every unit was snapped up even before construction for the condominium was complete.

When all is said and done, this is still a den for people fighting to survive. Hall revealed that the facility includes a .223 remote-controlled rifle that enables residents to wound—or perhaps even kill—intruders or nemeses like “a video game.” True enough, the control room connected to this rifle has a joystick.

For those who don’t believe in taking someone else’s life, the site can also unleash paintballs to warn enemies about what to expect  if they get too near. 

[via Insider, The Guardian, What’s Inside?, images via Survival Condo]

It’s not necessarily just the sheer amount of data that is difficult to make sense of though; it’s the complexity and lack of consistency that the data usually entails which requires some filtering — such a common scenario in data grids, enterprise dashboards, vaccine tracking and public records registries.

As customers, we use filters to reduce a large set of options to a more manageable and highly relevant selection. Perhaps just a few dozens of payment slips instead of thousands, or just a handful of blouses rather than the entire collection.

We have specific attributes of interest, a specific intent, that we need to somehow communicate to the interface. We do so by breaking our intent down into a set of available features. That intent might be fairly specific or quite general, but in both cases, the design should minimize the time needed for customers to get from the default state (when no filters are selected) to the final state (when all filters are successfully applied).

That’s only one part of the story though. Applying relevant filters is the easy part, but showing just enough relevant results is slightly more difficult. In fact, for every interface, and for every intent, we have a particular comfortable range in mind, that is a preferred number of options that we think we can manage relatively effortlessly.

This range of options doesn’t have to fit on a single screen, or be displayed on a single page, or be limited to a small shortlist that we can easily remember. It can be anything from dozens to hundreds of items scattered over a number of pages.

The important part is that this range meets our expectations that:

• we are looking at highly relevant options,
• we can easily understand what we are exploring,
• we can spot the differences between all options, and
• we can process everything within a reasonable, foreseeable timeframe.

Unlike sorting, which merely rearranges the results according to some preferred attributes (soft boundaries), filters always represent hard boundaries. They strictly limit the scope of results. Not enough proper filters and users shoot way over the comfortable range; too many filters and users end up with zero-results and abandon the site altogether.

The comfortable range varies significantly from a product to product. The cue to where it lies can be inferred from how different the options actually are. In usability tests, we see people having no issues exploring 20–30 kinds of vehicles, 40–50 kinds of sneakers, 70–80 bouquets of flowers, or even paginating through 100–200 payment slips. Yet they feel utterly overwhelmed when exploring 15 different types of sharpies or AAA-batteries. As a rule of thumb, it seems that the more different the options are, the more comfortable we feel with a slightly larger set of options.

The ultimate question, then, is how to find that delicate balance, when our interface helps users quickly arrive at just enough results. One answer to that question lies in something that sounds awfully obvious: eliminate any roadblocks on users' path towards that comfortable range. It’s easier written than done though — especially when you have dozens or even hundreds of filters that have to be accessible on mobile, on desktop, and everywhere in-between.

At the first glance, filtering doesn’t seem like a particularly complex endeavour. Of course we can have lengthy debates about the right form elements for different kind of filters — autocomplete, radios, toggles, select-dropdowns, sliders and buttons just to name a few — but in their essence, all of the form elements are just basic input, right?

Well, as it turns out, there are quite a few facets of the experience that make designing filters quite difficult:

• filters can come in various flavours and shapes, for pricing, ratings, colors, dates, times, size, brand, capacity, features, level of experience, age range, symptoms, product status etc.
• filters usually come in large numbers, and they need to be displayed across screens,
• filters often have different states (selected, unselected, disabled)
• filters often need sensible defaults, and they have to remember user’s input,
• filters can be interdependent, and these dependencies need to be obvious,
• filters can be difficult to validate, e.g. when users can type in complex data, such as time or dates,
• filters need to support and show meaningful error messages,
• and so many others.

Filters never exist on their own; in one way or another, they are always connected to the results that they are acting upon. This connection often causes filters and matching results to be somewhat synchronous, as the latter depend on how fast the UI registers an input, and how much time it needs to successfully process it.

Now, addressing all the fine intricacies of each of these challenges is nothing short of monumental work, yet some issues are slightly more frustrating than others, making the overall experience painful and annoying, and hence causing high abandonment and high bounce rates. Let’s explore some of the critical ones.

After just a few usability sessions with customers who try to use filters on their own device, one can spot some common frustrations making rounds over and over again. One of the most annoying patterns comes from lengthy filter sections that contain dozens of options. These options often get tucked away in a tiny scrollable pane, showing 3–4 options at a time and requiring vertical scrolling to browse the options.

These sections often cause customers to scroll vertically, slowly, accurately, with extreme focus and precision. As they do so on mobile, some filters get activated by mistake, prompting the customer to be even more focused. A classic example of this pattern is the “Brands” filter, which often contains hundreds of options, sorted by popularity or by alphabet.

An alternative option would be to show as many as 7–10 options at a time with an accordion that would expand and show all options on tap/click. These options don’t have to be displayed in their full height, but can live in a larger scrollable pane. But then they shouldn’t be activated by scrolling through the pane.

It’s also a good idea to compliment the filter with a search autocomplete and an alphabetical view if some of the popular options are highlighted at the top. A good example of it is Rozetka.ua, an eCommerce retailer from Ukraine (see above).

Whenever users can define a large range of values, be it pricing range in retail store, max duration of a train trip or a min/max coverage for an insurance plan, we probably will use some sort of a slider. All sliders have one thing in common: they are wonderful when we want to encourage customers to explore many options quickly, but they are quite frustrating when the user has something specific in mind and hence needs to be a little bit more precise.

Just think about the frustration we usually have to go through when bumping up the price a little bit, from $200 to $215, or adding another hour for the duration of a flight. Doing so with a slider is difficult because it requires incredible precision, and that always produces mistakes and causes frustration.

We’ve covered how to design a perfect slider in detail already, but probably the most important feature that every slider needs is to support different speeds of interaction. In fact, there are a few common types of interaction:

• when customers want to explore many options quickly, a good ol’ slider with a track and a thumb works perfectly fine;
• when customers want to be more precise in their exploration, we can help by adding steppers (+/-) for granular jumps forward and backwards,
• when customers have an exact value in mind, we can help by providing text input fields for min/max values, so users can type in values directly without having to use the slider,
• in all of these cases, solutions have to be accessible and support keyboard-only interaction.

Take a look at the Lloydsbank’s example below. A personal loan calculator supports all types of interaction beautifully. Also, notice the focus styles when the thumb is activated, and ranges displayed below the interest rate slider at the top to indicate where the customer is currently navigating. The interest rate changes depending on how much money the customer would like to borrow.

Another interesting example of a well-designed slider comes from Made.com’s Sofasizer, which allows you to filter couches based on the dimensions that they need to have. Rather than using a set of input fields, Made.com chose to use a visual interface with a “Resize” icon. You can drag the handle to adjust the size, or you can type in exact values in the height and width input fields.

Another option is to turn all filter sections into overlays and display them on tap/click above the results. In fact, you could even use floating filters, so as a customer scrolls down the page, the filters are still accessible all the time.

An example of this pattern is Adidas (see the image below). The filters bar is persistent; even as users are scrolling down the page, the filter overlay won’t close automatically — it requires user’s input, again handing over the control to the user. However, it does close automatically once one of the filters is selected. If the user wants to select multiple filters, they have to re-open the same filter group over and over again. Keeping the filters persistent might be a better idea. Still, the result: no layout shifts, no frustrating scrolling in narrow corridors, and filters are always accessible.

Not to say that displaying filters above the results is always better by default. On Asos, every filter input causes jumps to the top of the page, so customers have to manually scroll down to continue filtering. Instead of re-rendering the entire page, it would make more sense to re-render the filters area and the product list separately.

Ikea features filters at the top of the results. Sometimes filters appear in a drop-down overlay, and sometimes as a pill below the filters. But most of the time, unlike previous examples, when a filter is selected, it displays a sidebar mega-filter-overlay on the right with all available filtering options grouped there. As the customer is making their way through the filters, the product list is updated in the background asynchronously. More importantly, notice the “Apply” button which label changes depending on the input.

With every filter input, a new request is sent to the server, retrieving the number of results, and then showing that number in the UI. That’s a great way to give users a very clear sense of how far or how close they are towards their comfortable range.

Another example is Galaxus.ch (see below), a Swiss eCommerce retailer that provides a first-class experience when it comes to filtering. The filters are displayed above product results; a filter overlay appears on tap/click. No slowdowns, fast response times and a lovely integration of active filters with the filters area. A great reference example that is worth considering when designing any kind of filter.

In general, having an “Apply” button along with real-time updates of the content area seems to be working best. It really combines the best of both solutions: showing results immediately when they arrive, while keeping filters accessible at all times.

The issues that we’ve explored in the article apply equally to large and small screens. However, on small screens, and especially on slow connections, these issues become even more critical. Most of the time, interfaces tend to block the entire UI on a single filter input, causing massive delays for customers on the go (e.g. Crutchfield, Walgreens). On the other hand, it’s common to split the screen to display a filters overlay, while still showing the product list updated in the background (e.g. Nordstrom).

In general, though, it might be a better idea to experiment if a full-page overlay for filters would perform better. It gives more space to experiment with a multi-column view, or perhaps even display a swipeable area to choose filters without having to move between separate pages. In fact, using accordions that could collapse and expand instead of bringing the user to a separate page might be a good idea — similar to what we’ve discussed with mega-dropdowns.

Unlike on desktop, having an “Apply” button in all these examples matters, and you can make it slightly more useful by adding the amount of products as a label on the button and keeping the button sticky at the bottom as the user is scrolling down.

As usual, here are all the things to keep in mind when designing any kind of filter — a little helper to avoid missing important details before heading into conversations with your fellows designers and developers. You can find a full deck of Smart Interface Design Patterns Checklists at yours truly Smashing Magazine as well.

1. Can we avoid a filter icon and show filters as they are?
2. If not, what icon do we choose to indicate filtering?
3. Is the icon + padding large enough for comfortable tapping?
4. Do we put the icon at the top, bottom or floating (mobile/desktop)?
5. What exactly happens when the user clicks/taps on the icon?
6. How will the icon change on tap/click?
7. Will we have some sort of animation or transition on click?
8. Will filters appear as full page/partial overlay or slide-in?
9. Can we avoid sidebar filtering as it’s usually slow?
10. Do we expose popular or relevant filters by default?
11. Do we display the number of expected results for each filter?
12. Can we use a horizontal swiper to move between filters?
13. Can we avoid drop-downs and use only buttons/chips + toggles?
14. For complex filters, do we provide search within filters?
15. Do we use icons to explain differences between various filters?
16. Do we use the right elements for filters, e.g. sliders, buttons, toggles?
17. Do filters apply automatically (yes, for slide-ins)?
18. Do filters apply manually on confirmation (“Apply”) (yes, for overlays)?
19. How do we communicate already selected filters?
20. Can selected filters appear as removable pills, chips or tags?
21. Do we recommend relevant filters based on selection?
22. Do we track incompatibility between selected filters?
23. How do error messages or warning appear in the UI?
24. Do we allow customers to reset all filters quickly, at once?
25. Are filters (or filters button) floating on scroll on mobile/desktop?
26. Can users tap on the same spot to open/close filters?

Too often the filtering experience on the web is broken and frustrating, making it just unnecessarily difficult for customers to get to that shiny comfortable range of relevant results. When designing the next filter, take a look at some of the common issues that you might want to avoid, and hopefully avoid all the frustration that comes from broken and inaccessible implementations.

• Design for the comfortable range of options, for the case when a customer wants to add multiple filters quickly — one right after another.
• For lengthy filter groups, avoid tiny scrollable panes and show as many as 7–10 options at a time with an accordion that would expand and show all options on tap/click. Add a search autocomplete and an alphabetical view as well.
• Always add steppers (+/-) and text input fields when using sliders,
• Customer often want to set a number of filters of the same type. Never auto-scroll users on a single input and never collapse a group of filters automatically.
• Never freeze the UI on a single input, and never make your customer wait for an interface to respond back when setting filters.
• Always update filters and show results asynchronously, so that on every filter input, matching results could be updated asynchronously, while the filters always remain accessible and at the same place.
• Always avoid layout shifts on filter input and consider displaying filters above the results.
• On mobile, “Apply”-button could be sticky at the bottom of the screen. Update the count of products and show them on the button.

Articles of The Series

If you find this article useful, here’s an overview of similar articles we’ve published over the years — and a few more are coming your way.

• Perfect Accordion
• Perfect Responsive Configurator
• Perfect Birthday Picker
• Perfect Date and Time Picker
• Perfect Mega-Dropdown
• Perfect Feature Comparison
• Perfect Slider
• Form Design Patterns Book by Adam Silver, published on SmashingMag
• Subscribe to our email newsletter to not miss the next ones.

The result of jQuery popularity is measurable still today: Almost 80% of the most popular websites of the world still use it. Some of the reasons why jQuery is so popular are:

• It supports DOM manipulation.
• It provides CSS manipulation.
• Works the same on all web browsers.
• It wraps HTML event methods.
• Easy to create AJAX calls.
• Easy to use effects and animations.

Over the years, JavaScript changed a lot and added several features that we didn’t have in the past. With the re-definition and evolution of ECMAScript, some of the functionalities that jQuery provided were added to the standard JavaScript features and supported by all the web browsers. With this happening, some of the behavior jQuery offers was not needed anymore, as we are able to do the same things with plain JavaScript.

On the other hand, a new way of thinking and designing user interfaces started to emerge. Frameworks like React, Angular or Vue allow the developers to create web applications based on reusable functional components. React, i.e., works with the “virtual DOM”, which is a DOM representation in the memory, whereas jQuery interacts directly with the DOM, in a less performant way. Also, React offers cool features to facilitate the development of certain features, such as state management. With this new approach and the popularity that Single Page Applications started to gain, a lot of developers started to use React for their web application projects.

And front end development evolved even more, with frameworks created on top of other frameworks. That is the case, for example, of Next.js. As you probably know, it’s an open-source React framework that offers features to generate static pages, create server-side rendered pages, and combine both types in the same application. It also allows creating serverless APIs inside the same app.

There is a curious scenario: Even though these frontend frameworks are more and more popular over the years, jQuery is still adopted by a vast majority of web pages. One of the reasons why this happens is that the percentage of websites using WordPress is really high, and jQuery is included in the CMS. Another reason is that some libraries, like Bootstrap, have a dependency on jQuery, and there are some ready-to-use templates that use it and its plugins.

But another reason for this amount of websites using jQuery is the cost of migrating a complete web application to a new framework. It’s not easy, it’s not cheap and it’s time-consuming. But, in the end, working with new tools and technologies brings a lot of benefits: wider support, community assistance, better developer experience, and ease of getting people working on the project.

There are many scenarios where we don’t need (or don’t want) to follow the architecture that frameworks like React or Next.js impose on us, and that is OK. However, jQuery is a library that contains a lot of code and features that are not needed anymore. Many of the features jQuery offers can be accomplished using modern JavaScript native functions, and probably in a more performant way.

Let’s discuss how we could stop using jQuery and migrate our website into a React or Next.js web application.

Do We Need A Library?

Depending on the features of our web application, we could even have the case where a framework is not really needed. As mentioned before, several jQuery features were included (or at least a very similar one) to the latest web standard versions. So, considering that:

• $(selector) pattern from jQuery can be replaced with querySelectorAll().

Instead of doing:

$("#someId");

We can do:

document.querySelectorAll("#someId");

• We have now the property Element.classList if we want to manipulate CSS classes.

Instead of doing:

$(selector).addClass(className);

We can do:

element.classList.add(className);

• Many animations can be done directly using CSS, instead of implementing JavaScript.

Instead of doing:

$(selector).fadeIn();

We can do:

element.classList.add('show');
element.classList.remove('hide');

And apply some CSS styling:

.show {
  transition: opacity 400ms;
}

.hide {
  opacity: 0;
}

• We have now addEventListener function if we want to handle events.

Instead of doing:

$(selector).on(eventName, eventHandler);

We can do:

element.addEventListener(eventName, eventHandler);

• Instead of using jQuery Ajax, we can use XMLHttpRequest.

Instead of doing:

$.ajax({
  type: 'POST',
  url: '/the-url',
  data: data
});

We can do:

var request = new XMLHttpRequest();
request.open('POST', '/the-url', true);
request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8');
request.send(data);

For more details, you can take a look at these Vanilla JavaScript Code Snippets.

Identify Components

If we are using jQuery in our application, we should have some HTML content that is generated on the web server, and JavaScript code that adds interactivity to the page. We are probably adding event handlers on page load that will manipulate the DOM when the events happen, probably updating the CSS or the style of the elements. We could also be calling backend services to execute actions, that can affect the DOM of the page, or even reload it.

The idea would be to refactor the JavaScript code living in the pages and build React components. This will help us to join related code and compose elements that will be part of a larger composition. By doing this we will also be able to have better handling of the state of our application. Analyzing the frontend of our application, we should divide it into parts dedicated to a certain task, so we can create components based on that.

If we have a button:

<button id="btn-action">Click</button>

With the following logic:

var $btnAction = $("#btn-action");

$btnAction.on("click", function() {
  alert("Button was clicked");
});

We can migrate it to a React Component:

import React from 'react';

function ButtonComponent() {

  let handleButtonClick = () => {
    alert('Button clicked!')
  }

  return <button onClick={handleButtonClick}>Click</button>
}

But we should also evaluate how the migration process will be accomplished since our application is working and being used, and we don’t want to affect it (or, at least, affect it as little as possible).

Good Migration

A good migration is one where all the parts of the application are fully migrated to the new framework or technology. This would be the ideal scenario for our application since we would keep in sync all the parts, and we would be using a unified tool and a unique referred version.

A good and complete migration usually includes a complete re-write of the code of our app, and that makes sense. If we build an app from scratch, we have the possibility of deciding what direction we want to take with the new code. We could use a fresh point of view over our existing systems and workflow, and create a whole new app with the knowledge that we have at this moment, more complete than the one we had when we first created our web application.

But a complete rewrite has some problems. First of all, it requires a lot of time. The bigger the application is, the more time we will need to rewrite it. Another problem is the amount of work, and amount of developers, that it takes. And, if we don’t do a progressive migration, we have to think about how much time our application will be unavailable.

Normally, a complete rewrite can be accomplished with small projects, projects that don’t change frequently, or applications that are not so critical for our business.

Fast Migration

Another approach is dividing the application into parts or pieces. We migrate the app part by part, and we release those parts when they are ready. So, we have migrated parts of our application available for the users, and coexisting with our existing production app.

With this gradual migration, we deliver separated features of our project in a faster way to the users, since we don’t have to wait for the complete application to be re-written. We also get faster feedback from the users, which allows us to detect bugs or issues earlier.

But a gradual migration drives us to have different tools, libraries, dependencies, and frameworks. Or we could even have to support different versions from the same tool. This extended support could bring conflicts to our application.

We could even have problems if we are applying policies in the global scope since each one of the migrated parts could work in a different way, but being affected by the code that set global parameters to our system. An example of this is the use of a cascade logic for CSS styling.

Imagine we work with different versions of jQuery across our web application because we added functionalities from newer versions to the modules that have been created later. How complicated would it be to migrate all our app to a newer version of jQuery? Now, imagine the same scenario but migrating to a completely different framework like Next.js. That can be complicated.

Frankenstein Migration

Denys Mishunov wrote an article on Smashing Magazine presenting an alternative to these two migration ideas, trying to get the best of the previous two approaches: The Frankenstein Migration. It bases the migration process in two main components: Microservices and Web Components.

The migration process consists of a list of steps to follow:

1. Identify Microservices

Based on our app code, we should divide it into independent parts that are dedicated to one small job. If we are thinking about using React or Next.js, we could link the concept of microservices to the different components that we have.

Let’s think about a grocery list application as an example. We have a list of things to purchase, and an input to add more things to the list. So, if we want to split our app into small parts, we could think about an “item list” component and an “add item”. Doing this, we can separate the functionality and markup related to each one of those parts into different React components.

To corroborate the components are independent, we should be able to remove one of them from the app, and the other ones shouldn’t be affected by that. If we get an error when removing the markup and functionality from a service, we are not correctly not identifying the components, or we need to refactor the way our code works.

2. Allow Host-to-Alien Access

"Host" is our existing application. “Alien” is the one we will start creating, with the new framework. Both should work independently, but we should provide access from Host to Alien. We should be able to deploy any of the two applications without breaking the other one, but keeping the communication between them.

3. Write An Alien Component

Re-write a service from our Host application into our Alien application, using the new framework. The component should follow the same principle of independence that we mentioned before.

Let’s go back to the grocery list example. We identified an “add item” component. With jQuery, the markup of the component will look something like this:

<input class="new-item" />

And the JavaScript/jQuery code to add the items to the list will be something like this:

var ENTER_KEY = 13;

$('.new-item').on('keyup', function (e) {
  var $input = $(e.target);
  var val = $input.val().trim();

  if (e.which !== ENTER_KEY || !val) {
    return;
  }

  // code to add the item to the list

  $input.val('');
});

Instead of that, we can create an AddItem React component:

import React from 'react'

function AddItemInput({ defaultText }) {
  let [text, setText] = useState(defaultText)

  let handleSubmit = e => {
    e.preventDefault()
    if (e.which === 13) {
      setText(e.target.value.trim())
    }
  }

  return 
    <input type="text" 
      value={text} 
      onChange={(e) => setText(e.target.value)} onKeyDown={handleSubmit} />
}

4. Write Web Component Wrapper Around Alien Service

Create a wrapper component that imports our just created Alien service and renders it. The idea is to create a bridge between the Host app and the Alien app. Keep in mind that we could need a package bundler to generate JavaScript code that works in our current application since we will need to copy our new React components and make them work.

Following the grocery list example, we can create an AddItem-wrapper.js file in the Host project. This file will contain the code that wraps our already created AddItem component, and creates a custom element with it:

import React from "../alien/node_modules/react";
import ReactDOM from "../alien/node_modules/react-dom";
import AddItem from "../alien/src/components/AddItem";

class FrankensteinWrapper extends HTMLElement {
  connectedCallback() {
    const appWrapper = document.createElement("div");
    appWrapper.classList.add("grocerylistapp");

    ...

    ReactDOM.render(
      <HeaderApp />,
      appWrapper
    );

    …

  }
}

customElements.define("frankenstein-add-item-wrapper", FrankensteinWrapper);

We should bring the necessary node modules and components from the Alien application folders since we need to import them to make the component work.

5. Replace Host Service With Web Component

This wrapper component will replace the one in the Host application, and we will start using it. So, the application in production will be a mix of Host components and Alien wrapped components.

In our example Host application, we should replace:

<input class="new-item" />

With

<frankenstein-add-item-wrapper></frankenstein-add-item-wrapper> 

... 

<script type="module" src="http://www.smashingmagazine.com/js/AddItem-wrapper.js"></script>

6. Rinse And Repeat

Go through steps 3, 4, and 5 for each one of the identified microservices.

7. Switch To Alien

Host is now a collection of wrapper components that include all the web components we created on the Alien application. As we converted all the identified microservices, we can say that the Alien application is finished and all the services were migrated. We just need to point our users to the Alien application now.

The Frankenstein Migration method works as a combination of both the Good and the Fast approaches. We migrate the complete application but release the different components when they are done. So, they are available to be used sooner and evaluated by the users in production.

We have to consider, though, that we are doing some over-work with this approach. If we want to use the components we create for our Alien application, we have to create a wrapper component to include in the Host app. This makes us spend time developing the code for these wrapper elements. Also, by using them in our Host application, we are duplicating the inclusion of code and dependencies, and adding code that will affect the performance of our application.

Strangler Application

Another approach we can take is the Legacy Application Strangulation. We identify the edges of our existing web application, and whenever we need to add functionalities to our app we do it using a newer framework until the old system is “strangled”. This approach helps us to reduce the potential risk we can experiment while migrating an app.

To follow this approach, we need to identify different components, as we do in Frankenstein Migration. Once we divide our app into different pieces of related imperative code, we wrap them in new React components. We don’t add any additional behavior, we just create React components that render our existing content.

Let’s see an example for more clarification. Suppose we have this HTML code in our application:

<div class="accordion">
  <div class="accordion-panel">
    <h3 class="accordion-header">Item 1</h3>
    <div class="accordion-body">Text 1</div>
  </div>
  <div class="accordion-panel">
    <h3 class="accordion-header">Item 2</h3>
    <div class="accordion-body">Text 2</div>
  </div>
  <div class="accordion-panel">
    <h3 class="accordion-header">Item 3</h3>
    <div class="accordion-body">Text 3</div>
  </div>>
</div>

And this JavaScript code (we already replaced jQuery functions with new JavaScript standard features).

const accordions = document.querySelectorAll(".accordion");
for (const accordion of accordions) {
  const panels = accordion.querySelectorAll(".accordion-panel");
  for (const panel of panels) {
    const head = panel.querySelector(".accordion-header");
    head.addEventListener('click', () => {
      for (const otherPanel of panels) {
        if (otherPanel !== panel) {
          otherPanel.classList.remove('accordion-expanded');
        }
      }
      panel.classList.toggle('accordion-expanded');
    });
  }
}

This is a common implementation of an accordion component for JavaScript. As we want to introduce React here, we need to wrap our existing code with a new React component:

function Accordions() {
  useEffect(() => {
    const accordions = document.querySelectorAll(".accordion")
    for (const accordion of accordions) {
      const panels = accordion.querySelectorAll(".accordion-panel")
      for (const panel of panels) {
        const head = panel.querySelector(".accordion-header")
        head.addEventListener("click", () => {
          for (const otherPanel of panels) {
            if (otherPanel !== panel) {
              otherPanel.classList.remove("accordion-expanded")
            }
          }
          panel.classList.toggle("accordion-expanded")
        });
      }
    }
  }, [])

  return null
}

ReactDOM.render(<Accordions />, document.createElement("div"))

The component is not adding any new behavior or feature. We use useEffect because the component has been mounted in the document. That is why the function returns null because the hook doesn’t need to return a component.

So, we didn’t add any new functionality to our existing app, but we introduced React without changing its behavior. From now on, whenever we add new features or changes to our code, we will do it using the newer selected framework.

Client-side Rendering, Server-side Rendering, Or Static Generation?

Next.js gives us the possibility of choosing how we want to render each page of our web application. We can use the client-side rendering that React already offers us to generate the content directly in the user’s browser. Or, we can render the content of our page in the server using server-side rendering. Finally, we can create the content of our page at build time using static generation.

In our application, we should be loading and rendering code on page load, before we start interacting with any JavaScript library or framework. We may be using a server-side rendering programming language or technology, such as ASP.NET, PHP, or Node.js. We can get advantage of Next.js features and replace our current rendering method with the Next.js server-side rendering method. Doing this, we keep all the behavior inside the same project, that works under the umbrella of our selected framework. Also, we keep the logic of our main page and the React components within the same code that generates all the needed content for our page.

Let’s think about a dashboard page as an example. We can generate all the initial markup of the page at load time, in the server, instead of having to generate it with React in the user’s web browser.

const DashboardPage = ({ user }) => {
  return (
    <div>
       <h2>{user.name}</h2>

       // User data

    </div>
  )
}

export const getServerSideProps = async ({ req, res, params }) => {
    return {
      props: {
        user: getUser(),
      },
    }
  },
})

export default DashboardPage

If the markup that we render on page load is predictable and is based on data that we can retrieve at build time, static generation would be a good choice. Generating static assets at build time will make our application faster, more secure, scalable, and easier to maintain. And, in case we need to generate dynamic content on the pages of our app, we can use React’s client-side rendering to retrieve information from services or data sources.

Imagine we have a blog site, with many blog posts. If we use Static Generation, we can create a generic [blog-slug].js file in our Next.js application, and adding the following code we would generate all the static pages for our blog posts at build time.

export const getStaticPaths = async () => {
  const blogPosts = await getBlogPosts()

  const paths = blogPosts.map(({ slug }) => ({
    params: {
      slug,
    },
  }))

  return {
    paths,
    fallback: false,
  }
}

export const getStaticProps = async ({ params }) => {
  const { slug } = params

  const blogPost = await getBlogPostBySlug(slug)

  return {
    props: {
      data: JSON.parse(JSON.stringify(blogPost)),
    },
  }
}

Create An API Using API Routes

One of the great features Next.js offers is the possibility to create API Routes. With them, we can create our own serverless functions using Node.js. We can also install NPM packages to extend the functionality. A cool thing about this is that our API will leave in the same project/app as our frontend, so we won’t have any CORS issues.

If we maintain an API that is called from our web application using jQuery AJAX functionality, we could replace them using API Routes. Doing this, we will keep all the codebase of our app in the same repository, and we will make the deployment of our application simpler. If we are using a third-party service, we can use API Routes to “mask” the external URLs.

We could have an API Route /pages/api/get/[id].js that returns data that we use on our page.

export default async (req, res) => {
  const { id } = req.query

  try {
    const data = getData(id)
    res.status(200).json(data)
  } catch (e) {
    res.status(500).json({ error: e.message })
  }
}

And call it from the code of our page.

 const res = await fetch(`/api/get/${id}`, {
    method: 'GET',
  })

  if (res.status === 200) {
    // Do something
  } else {
    console.error(await res.text())
  }

Netlify is a complete platform that can be used to automate, manage, build, test, deploy and host web applications. It has a lot of features that make modern web application development easier and faster. Some Netlify highlights are:

• Global CDN hosting platform,
• Serverless functions support,
• Deploy previews based on Github Pull Requests,
• Webhooks,
• Instant rollbacks,
• Role-based access control.

Netlify is a great platform to manage and host our Next.js applications, and it’s pretty simple to deploy a web app with it.

First of all, we need to keep track of our Next.js app code in a Git repository. Netlify connects to GitHub (or the Git platform we prefer), and whenever a change is introduced to a branch (a commit or a Pull Request), an automatic “build and deploy” task will be triggered.

Once we have a Git repository with the code of our app, we need to create a “Netlify Site” for it. To do this, we have two options:

1. Using Netlify CLI
   After we install the CLI (npm install -g netlify-cli) and log into our Netlify account (ntl login), we can go to the root directory of our application, run ntl init and follow the steps.
2. Using Netlify web app
   We should go to https://app.netlify.com/start. Connect to our Git provider, choose our application’s repository from the list, configure some build options, and deploy.

For both methods, we have to consider that our build command will be next build and our directory to deploy is out.

Finally, the Essential Next.js plugin is installed automatically, which will allow us to deploy and use API routes, dynamic routes, and Preview Mode. And that's it, we have our Next.js application up and running in a fast and stable CDN hosting service.

In this article, we evaluated websites using jQuery library, and we compared them with new frontend frameworks like React and Next.js. We defined how we could start a migration, in case it benefits us, to a newer tool. We evaluated different migration strategies and we saw some examples of scenarios that we could migrate to Next.js web application projects. Finally, we saw how to deploy our Next.js application to Netlify and get it up and running.

Further Reading and Resources

• Frankenstein Migration: Framework-Agnostic Approach
• Removing jQuery from GitHub.com frontend
• Getting Started with Next.js
• How to Deploy Next.js Sites to Netlify
• Next.js articles in Netlify Blog

Perhaps a person has arthritis, Multiple Sclerosis, or another form of motor skill disorder, and there is a part of the site that they cannot access because there is an issue that prevents them from obtaining that information they wish to on a site that they want to buy something on.

These are just a couple of examples of what disabled users face daily when they try and access a website that is inaccessible. The case for accessibility is this; we as stakeholders, managers, teams, designers and developers need to do better in not only practicing accessibility but advocating for it as well.

If you have ever read the WebAIM Million report, you can see where the breakdown is, and until 2021, there hasn’t been much in the way of improvement. Of the 1 million home pages that were tested, over 51 million errors were detected averaging 51.4 errors per page. While the number of errors decreased, home page complexity increased regarding the number of page elements that had detectable accessibility errors.

Inclusive design is a way of creating digital products that are accessible to a wide range of people regardless of who they are, disabled or not, where they are, and encapsulates a diverse spectrum of people. The British Standards Institution (2005) defines inclusive design as:

“The design of mainstream products and/or services that are accessible to, and usable by, as many people as reasonably possible ... without the need for special adaptation or specialized design.”

Practicing accessibility in your workflows and methodologies ensures people — disabled or not — that they can access your product, your website, and your brands. Inclusive design and accessibility go hand-in-hand. Let’s look at some examples of accessibility.

1. Your site has a color scheme that looks great after the designers are done with the mock-ups or the color scheme your brand uses is “perfect”’ in the eyes of people that do not have a visual disability. For people that have a visual disability like glaucoma, cataracts, or tritanopia (the deficiency of blue in one’s vision) they cannot make out that particular color and it does not meet WCAG standards.
2. If your light blue font color on a darker blue background did not meet those guidelines set in WCAG, then it would be inaccessible. If you switched to a lighter blue or white font within the 4.5 to 1 ratio guideline that you can read about in (Success Criterion 1.4.3: Contrast (Minimum)), then it would meet the standard and be accessible to more people.

1. You have a site that does not traverse well (or at all) when disabled users use assistive technologies such as a screen reader, keyboard, or voice recognition to navigate around the site because they lack the motor skills or dexterity to do so. An accessible site makes sure there is a way for those users to navigate through the site with no issues. Examples of keyboard navigation can be seen in this video and in this short video about voice recognition.
2. An accordion component with information that creates content that is not scrollable. It is inaccessible to people that use the keyboard for navigation. Make sure that the content is accessible by keyboard in that instance.
3. Using alternative text to describe the information in a picture for Blind users. Images that do not have alternative text that describes to screen reader users what the picture conveys are a barrier to blind people, e.g.

   <img src="http://www.smashingmagazine.com/" alt="This is my favorite kind of animal, a Maine Coon cat.">
   

4. Users of newer technologies, people that live in metropolitan areas, or people that can afford to buy the latest tech, for example, have fewer barriers to break through than people that cannot afford a new phone or tablet, or are in very remote or rural areas.
5. The glare of the sun on your mobile device as you’re on the beach on a sunny day. You’re shielding the screen or squinting to see the screen to read what restaurant to go to after you’re day at the beach is done. That is a situational impairment.
6. A fussy child on your lap moving around while you are trying to read an email or an injured arm as you try to answer an email, hindering your ability to type as you normally would is a situational impairment.

There are a lot more examples of accessibility I could mention but that would take a very long time to write, so these are just a few examples.

Two of the most widely used reasons I hear as to why people or companies aren’t practicing accessibility are:

• “The client has no budget for it.”
• “My manager said we’ll get to it after launch.”

From the outset, advocating for accessibility starts at the top. Once you have stakeholder support, then you may see support trickle down to managers, then teams, and then individuals. It all starts with you first. Buy-in and support from executives will continuously be successful across the organization.

When the ethical approach doesn’t work, the approach I will take is the financial approach:

“You’ll be saving the company a lot of money when you do this from the start. When maintenance is needed, it won’t take the team as long to maintain the code because of accessibility and clean code.”

When, or if that fails, I’ll go for the legal ramifications and cite instances from the lawsuits that have been won against Target, Bank of America, Domino’s Pizza, and others. It’s amazing to see how fast executives and stakeholders do not want to get sued.

Keeping executives engaged and meeting with them regularly will ensure success with your accessibility initiatives, but will also provide support for when new accessibility initiatives need to be implemented or when there are disagreements among teams on the implementation or prioritization, you have the support of executives.

Being accessible is a good way for a company to differentiate itself from other companies, when you make a quality product, then the company buy-in becomes greater in some instances. Teams that push for accessibility usually lead the way to getting buy-in from other departments and executives. If the product is high quality and makes the company money, that’s when the company is swayed to adopt the practice.

Demonstrations of live testing with disabled users are also another way to get buy-in across the board. To humanize the decision-making process and get executives and colleagues on board by showing them when design choices do not meet user needs by disabled users using inaccessible products. Or one that I have used in the past, don’t ask, just do it.

Most of the time, however, it is how the practice of accessibility can make the company money or the legal consequences that a company can face, that sways an executive to adopt the practice. Then, in those instances, is when an executive or stakeholder starts learning about accessibility if they want to invest in that time.

Coordinating efforts across departments may be difficult and time-consuming at first so that support from the top will help alleviate the pressures and burnout that can happen when taking on the task of creating and implementing an accessibility strategy.

Once you have buy-in from executives or stakeholders, having a person throughout each department or a team focused on accessibility. Throughout each department have an individual who is the liaison regarding accessibility.

Have someone that can answer questions and work with others to practice the guidelines and work with others to make accessible products. Help set up documentation and tooling, serve as an intermediary between departments.

Gauging the point where the product(s) are as far as how inclusive and accessible they are is a key priority. This ensures the team or individual that their efforts to make the product better and accessible are happening. What is the current state of the product? What is the current state of the website or mobile application?

Getting the general idea of the level of knowledge that teams and people in the company currently have is important going forward. How versed are they in accessibility guidelines and practices? Do they know anything about the Web Content Accessibility Guidelines (WCAG)? How much training do you have and will you need?

Maintaining a written record of all accessibility training done to meet the requirements that apply to your organization is a great way to keep data on all the training done within the organization. Recording the training and who and when it was completed. If there is no inter-organizational accessibility training available your organization can look into different methods of training like the kind WebAIM, the ADA, or Knowbility has to offer.

Consistent implementation of the product greatly benefits the organization. It reduces the amount of work, which in turn can reduce the number of stress teams are under. Design systems should be used not only to ensure branding and consistency, but accessibility, inclusivity, and understanding of code better.

Accessible components help for obvious reasons and reduces the time it takes to implement, rather than start from nothing and try to re-invent something that has already been done. Testing procedures should be implemented so that departments do their jobs well and do them efficiently, especially QA and developers.

Documenting guidelines for your organization is as simple as creating a set of accessibility guidelines. You could internally document them in a collaborative software such as Notion or Dynalist; or an online documentation like Google Docs or Dropbox Paper. Somewhere that has a collaborative aspect where people can add to the documentation that the organization has.

In this landscape of frameworks and libraries, “going fast and breaking things”, and overlooking and undervaluing accessibility, people need to be educated and that also needs to happen at the team level. The people that do not have voices, the “people on the other side of the glass” need YOU to be their voice.

As a freelancer, setting up meetings or training sessions to onboard organization members that you may be working with can be beneficial to all. Holding a workshop or webinar is also an option to training colleagues to buy-in as well.

Getting a team onboard because training brings the team together and people know the importance of accessibility, and they want to produce a quality product that people can use regardless of disability.

Pitching to those who do not or may not know that accessibility means less time spent working on what they work on, less stress and headaches, can sway a developer very fast from my experience.

Whether you live in the EU, the UK, Canada, or the United States, most countries have rules regarding standards for accessibility. Familiarity with those rules and guidelines only ensures compliance on another level.

Whether it is the ADA (American Disabilities Act) or Section 508 (Government compliance) in the U.S., the ACT (Accessible Canada Act) in Canada, or EN 301 549 in the EU, sharing the importance of the guidelines can be crucial to getting departments, executives, and the organization as a whole on board.

Test and record cases where a disabled user is trying to use the product, website, or mobile app. Showing colleagues and executives these tests and use cases will bolster the argument you have for implementing accessibility at your organization.

From there, you could get a source outside the organization that specializes in accessibility testing with disabled users, such as Applause, for instance. The organization and people within may turn around and embrace accessibility at the company and in the workflow.

Whether it is internally or on a contract basis with an outside firm like Applause, there are the people with the lived experiences. They can benefit you and your company and team by having them aboard. These folks bring value to you and the organization.

Get executives and hiring managers on board to bring on people with disabilities to not only help with accessibility, but also teach and advocate for accessibility and inclusivity within the organization.

Accessibility does not end at handoff or when the project is “finished” as is with the web, accessibility is ever-evolving and needs periodic checking when new features are implemented or changes are made to see if accessibility is still be practiced and adhered to.

Vigilance of the accessibility of the product(s) ensures a standard of accessibility. Automated testing of the product wherever possible that fits the strategy of the departments when it comes time to release new features or changes.

Any barriers that may arise (and they will) will be addressed and they can be handled in a manner that expedites the process and rolls out fixes for those barriers that take them down and makes the product accessible for those who need it.

Performing screen reader analysis before every release to ensure that users of screen readers and other assistive technologies can use the website or mobile app.

Annual audits and user testing is always important whether made internally by a team, or a third-party that specializes in accessibility auditing, especially with user testing by disabled users. What does that audit entail?

• An executive summary for stakeholders that details the needs of the product so that it can become compliant as well as addressing the current state of affairs as well.
• A developer report that details every possible path that can be taken through the website, mobile app, and product that addresses concerns and needs that will be encountered along the way.

Accessibility matters. It matters to those who are getting shut out on a daily basis from some form of digital creation they encounter. Whether it is by design or not, the fact that accessibility is an afterthought in most cases is a critical oversight we all have to correct.

Accessibility and accessible sites and apps make the web better, they make everyone feel included no matter what situation or disability. Inclusion and accessibility remove barriers for disabled people and accessibility and performance also make the web accessible for those that aren’t equipped with the latest and greatest phones or devices.

Getting on board with accessibility is something we should all do. Let’s remember the people on the other side of the glass. Accessibility is a right, not a privilege. Let’s make accessibility a priority.

In May 2022, the ‌iCloud‌ Documents and Data service, our former document synchronization service, will be interrupted and completely replaced by ‌iCloud Drive‌. Therefore, if you use ‌iCloud‌ Documents and Data, your account will be migrated to ‌iCloud Drive‌ after that date.

If you use the ‌iCloud‌ Documents and Data service, you must activate ‌iCloud Drive‌ by following the steps below to view your files. Upgrading to ‌iCloud Drive‌ does not change the storage space used by your files saved in ‌iCloud‌.

Xavi Bou hat die Bewegungen eines Schwarmes Staren genommen, was an sich bereits wunderschön anzuschauen ist. Durch unterstreichende Visualisierung kann man die Bewegungen und deren in den Himmel gemalten Muster noch etwas besser nachvollziehen. Wie ein grober Pinsel vermögen die dutzenden Vögel ein abstraktes Bild zu zeichnen. Und als wäre das alles nicht bereits sehenswert genug, gesellt sich noch ein angriffslustiger Adler hinzu, der zu originellen Ausweich-Manöver des Schwarmes führt. Die Natur ist halt noch immer der größte Unterstützer der Kunst!

„In winter, starlings join in flocks of thousands of individuals to try to confuse the hawks that attack them, doing a mesmerizing dance. This video is part of the Ornitografias project, a project in which Xavi Bou has been working for years, which consists in visualizing the beauty of bird flight paths.“

via: kraftfuttermischwerk

Uff, so ein Erster des Monats, der auf einen Montag fällt, ist ja so ziemlich der Endgegner für mich. Da ist die perfekte Vier-Wochen-Datums-Verteilung des diesjährigen Februars nicht wirklich toll für… Entsprechend habe ich es auch erst gestern geschafft, die neue Ausgabe der „WIN Compilation“ fertig zu schneiden. 4K-Verarbeitung bei YouTube, Vorabansicht für unsere Unterstützenden auf Patreon und ein bisschen Blick auf die Wach-Zeiten unserer internationalen Zuschauer – entsprechend haben Martin und ich die neue Folge mal wieder am Zweiten abends für euch. Aber hey – bislang hat niemand gemeckert und vermutlich seid ihr das mittlerweile ja von uns gewohnt. So konnten wir wenigstens noch eine kleine Content-Erkundungs-Runde einlegen, auch wenn die im Februar doch verdammt mau ausgefallen ist. Aber für 42 tolle Videos hat es dann doch noch gereicht, die euch für neun Minuten die Langeweile vertreiben sollten!

Enjoy & share!

WIN Compilation: Die besten Videos des Monats Februar 2021

„The good thing about a short February is, that you don’t have to wait that long for a new WIN Compilation of ours. The bad thing about a short February is, that usually there are less cool clips for us to collect and show you. Nevertheless we found 42 original ones that should be able to brighten your day. Did you know that you can make our day by subscribing to our channel? Just saying…“

Du mochtest das? Dann abonniere doch unseren Kanal! Das würde uns nicht nur enorm freuen, sondern auch helfen, weiterhin mindestens monatlich Videos rauszuhauen.

Dabei kannst du helfen, indem du unser Video mit Freunden, Familie, Bekannten und Feinden teilst (am besten einfach mit ALLEN!). Neuerdings könnt ihr uns auch mittels Einkäufen bei Amazon über unseren Partnerlink unterstützen (Affiliate, ihr zahlt also das Gleiche, wir bekommen einen kleinen Anteil davon ab). Wer darüber hinaus noch seine Wertschätzung zeigen und sich coole Boni sichern möchte, darf das gerne über Patreon (oder alternativ indirekt über das deutsche Äquivalent Steady) machen. Aber auch wenn ihr „nur“ unsere Videos schauen solltet: HABT VIELEN DANK!

Liste der originalen Clips

Zum Schluss gibt es wie immer die Auflistung der Originalvideos zum Nachschauen und Einholen von Hintergrund-Infos. Die ist chronologisch geführt und entsprechend der oben links im Video jeweils pro Clip eingeblendeten Nummer sortiert. Einfach abgleichen, aufsuchen und in ganzer Länge anschauen. Plus: etwas Linkliebe für unsere Fundquellen.

• Anklageschrift gegen Trump am Montag im US-Senat, 22.01.2021
• Wirtschaft wendet sich von Trump ab, 12.01.2021

Meldung bei www.tagesschau.de lesen

Apple co-founder and former CEO Steve Jobs will be memorialized in the National Garden of American Heroes along with hundreds of other notable American figures. The late Apple co-founder’s name appeared in a list of notables in an executive order signed by outgoing U.S. President Donald Trump.

The order, signed on Monday, says the garden will be built in honor of “legends of America’s past.” The order reads:

Each individual has been chosen for embodying the American spirit of daring and defiance, excellence and adventure, courage and confidence, loyalty and love. Astounding the world by the sheer power of their example, each one of them has contributed indispensably to America’s noble history, the best chapters of which are still to come.

The garden will include statues of Ansel Adams, John Adams, Samuel Adams, Muhammad Ali, Luis Walter Alvarez, Susan B. Anthony, Hannah Arendt, Louis Armstrong, Neil Armstrong, Crispus Attucks, John James Audubon, Lauren Bacall, Clara Barton, Todd Beamer, Alexander Graham Bell, Roy Benavidez, Ingrid Bergman, Irving Berlin, Humphrey Bogart, Daniel Boone, Norman Borlaug, William Bradford, Herb Brooks, Kobe Bryant, William F. Buckley, Jr., Sitting Bull, Frank Capra, Andrew Carnegie, Charles Carroll, John Carroll, George Washington Carver, Johnny Cash, Joshua Chamberlain, Whittaker Chambers, Johnny “Appleseed” Chapman, Ray Charles, Julia Child, Gordon Chung-Hoon, William Clark, Henry Clay, Samuel Clemens (Mark Twain), Roberto Clemente, Grover Cleveland, Red Cloud, William F. “Buffalo Bill” Cody, Nat King Cole, Samuel Colt, Christopher Columbus, Calvin Coolidge, James Fenimore Cooper, Davy Crockett, Benjamin O. Davis, Jr., Miles Davis, Dorothy Day, Joseph H. De Castro, Emily Dickinson, Walt Disney, William “Wild Bill” Donovan, Jimmy Doolittle, Desmond Doss, Frederick Douglass, Herbert Henry Dow, Katharine Drexel, Peter Drucker, Amelia Earhart, Thomas Edison, Jonathan Edwards, Albert Einstein, Dwight D. Eisenhower, Duke Ellington, Ralph Waldo Emerson, Medgar Evers, David Farragut, the Marquis de La Fayette, Mary Fields, Henry Ford, George Fox, Aretha Franklin, Benjamin Franklin, Milton Friedman, Robert Frost, Gabby Gabreski, Bernardo de Gálvez, Lou Gehrig, Theodor Seuss Geisel, Cass Gilbert, Ruth Bader Ginsburg, John Glenn, Barry Goldwater, Samuel Gompers, Alexander Goode, Carl Gorman, Billy Graham, Ulysses S. Grant, Nellie Gray, Nathanael Greene, Woody Guthrie, Nathan Hale, William Frederick “Bull” Halsey, Jr., Alexander Hamilton, Ira Hayes, Hans Christian Heg, Ernest Hemingway, Patrick Henry, Charlton Heston, Alfred Hitchcock, Billie Holiday, Bob Hope, Johns Hopkins, Grace Hopper, Sam Houston, Whitney Houston, Julia Ward Howe, Edwin Hubble, Daniel Inouye, Andrew Jackson, Robert H. Jackson, Mary Jackson, John Jay, Thomas Jefferson, Steve Jobs, Katherine Johnson, Barbara Jordan, Chief Joseph, Elia Kazan, Helen Keller, John F. Kennedy, Francis Scott Key, Coretta Scott King, Martin Luther King, Jr., Russell Kirk, Jeane Kirkpatrick, Henry Knox, Tadeusz Kościuszko, Harper Lee, Pierre Charles L’Enfant, Meriwether Lewis, Abraham Lincoln, Vince Lombardi, Henry Wadsworth Longfellow, Clare Boothe Luce, Douglas MacArthur, Dolley Madison, James Madison, George Marshall, Thurgood Marshall, William Mayo, Christa McAuliffe, William McKinley, Louise McManus, Herman Melville, Thomas Merton, George P. Mitchell, Maria Mitchell, William “Billy” Mitchell, Samuel Morse, Lucretia Mott, John Muir, Audie Murphy, Edward Murrow, John Neumann, Annie Oakley, Jesse Owens, Rosa Parks, George S. Patton, Jr., Charles Willson Peale, William Penn, Oliver Hazard Perry, John J. Pershing, Edgar Allan Poe, Clark Poling, John Russell Pope, Elvis Presley, Jeannette Rankin, Ronald Reagan, Walter Reed, William Rehnquist, Paul Revere, Henry Hobson Richardson, Hyman Rickover, Sally Ride, Matthew Ridgway, Jackie Robinson, Norman Rockwell, Caesar Rodney, Eleanor Roosevelt, Franklin D. Roosevelt, Theodore Roosevelt, Betsy Ross, Babe Ruth, Sacagawea, Jonas Salk, John Singer Sargent, Antonin Scalia, Norman Schwarzkopf, Junípero Serra, Elizabeth Ann Seton, Robert Gould Shaw, Fulton Sheen, Alan Shepard, Frank Sinatra, Margaret Chase Smith, Bessie Smith, Elizabeth Cady Stanton, Jimmy Stewart, Harriet Beecher Stowe, Gilbert Stuart, Anne Sullivan, William Howard Taft, Maria Tallchief, Maxwell Taylor, Tecumseh, Kateri Tekakwitha, Shirley Temple, Nikola Tesla, Jefferson Thomas, Henry David Thoreau, Jim Thorpe, Augustus Tolton, Alex Trebek, Harry S. Truman, Sojourner Truth, Harriet Tubman, Dorothy Vaughan, C. T. Vivian, John von Neumann, Thomas Ustick Walter, Sam Walton, Booker T. Washington, George Washington, John Washington, John Wayne, Ida B. Wells-Barnett, Phillis Wheatley, Walt Whitman, Laura Ingalls Wilder, Roger Williams, John Winthrop, Frank Lloyd Wright, Orville Wright, Wilbur Wright, Alvin C. York, Cy Young, and Lorenzo de Zavala.

Each individual has been chosen for embodying the American spirit of daring and defiance, excellence and adventure, courage and confidence, loyalty and love. Astounding the world by the sheer power of their example, each one of them has contributed indispensably to America's noble history, the best chapters of which are still to come.

• Covid-Impfung bei Hochbetagten: Norwegen warnt

Meldung bei www.tagesschau.de lesen

Apple CEO Tim Cook sat down for a brief interview with Chris Wallace on Fox News Sunday. Cook discussed social reform, as well as the possible return of social platform Parler to the App Store.

Cook told Wallace that Parler could return to the App Store if it begins following Apple’s Terms of Service.

When asked if Apple and other tech companies are restricting free speech, Cook pointed out that the App Store is a private platform that can make its own rules.

When asked by Wallace what he expects to accomplish with the initiative, Cook responded, “I remember periods of time, Chris, where, whether you were in high school or college or beyond, where you look around and there are only white people around, whether it’s a college or a university or a graduate school or something. It doesn’t feel right.”

What is accountsd?

The Accounts framework provides access to user accounts stored in the Accounts database, which is managed by the system. An account stores the login credentials of a particular service, such as Twitter, and you use those credentials to authenticate with the service. When you integrate the Accounts framework into your app, you don't need to store account logins yourself. Instead, the user grants your app access to use their account login credentials, bypassing the need to type their username and password. If no account for a particular service exists in the user's Accounts database, you can let them create and save an account from within your app.

How to fix accountsd CPU usage?

Vergangenes Jahr hatte ich bereits Zeitlupenaufnahmen abhebender Flugkäfer hier im Blog, jetzt hat der YouTube-Kanal Ant Lab ein ganz ähnliches Video online gestellt. Mit bis zu 3.200 Frames die Sekunde bekommen wir das zu sehen, was das menschliche Auge sonst nicht zu erkennen imstande ist. Allerfeindes Bewegungen von Flügeln, Fühlern und Beinen. Beeindruckend!

„Takeoff and flight sequences of insects spanning 8 different taxonomic orders captured at 3,200 fps!“

via: thekidshouldseethis

Ein bisschen schummeln die Leute von Pongfinity ja schon in ihrem neuesten Video, denn statt dem Titel entsprechender 100 Fähigkeitsstufen erhalten wir ledigliches jede fünfte. Aber klar, „1 to 100“ klingt halt cooler als „1 to 20“. Dennoch sind da viele richtig gute Einlagen bei und wenn wir ehrlich sind startet das nicht mal wirklich im Normalobereich, bereits spätestens ab Level 15 bin ich raus…

June 16

• Epic Games CEO Tim Sweeney tells The Washington Post that "the iOS App Store's monopoly protects only Apple profit, not device security."


• Sweeney quote tweets The Washington Post's story: "Here Apple speaks of a level playing field. To me, this means: All iOS developers are free to process payments directly, all users are free to install software from any source. In this endeavor, Epic won't seek nor accept a special deal just for ourselves."

June 23

• Sweeney tweets: "Opening iOS and Android up as truly open platforms with a genuinely level playing field between first party and third party apps and stores is the only way to ensure a competitive, healthy, and fair app economy."

July 24

• Sweeney tells CNBC that the App Store is an "absolute monopoly," arguing that "Apple has locked down and crippled the ecosystem by inventing an absolute monopoly on the distribution of software, on the monetization of software."

July 28

• Sweeney tweets: "It pains me to complain about Apple in this way. Apple is one of the greatest companies that has ever existed, perhaps the greatest. But they're fundamentally wrong in blocking competition and choice on devices they make, and that holds up entire fields of technological progress."


• Sweeney tweets: "This is a critical consideration in these 30% store fees. They come off the top, before funding any developer costs. As a result, Apple and Google make more profit from most developers' games than the developers themselves. That is terribly unfair and exploitative."

August 1

• Sweeney tweets: "Apple's intentional anti-competitive strategy has been running for much longer than most realize. Here they are in 2011 muscling Kindle purchases off of iPhone by demanding 30% of e-book revenue, 'which we acknowledge is prohibitive for many things.'"

August 13

• Epic Games introduces a direct payment option in the Fortnite app for iPhone and iPad, allowing players to purchase in-game V-Bucks at a 20 percent discount by sidestepping Apple's in-app purchase mechanism. This functionality violates Apple's App Store Review Guidelines, which indicate that apps offering in-game currency must use Apple's in-app purchase mechanism only.


• The direct payment option is also added to the Fortnite app on Android in violation of Google's Play Store rules.


• Epic Games describes Apple's and Google's 30 percent cut on in-app purchases as "exorbitant." Epic also notes that apps that offer real-life goods and services like Uber, DoorDash, and StubHub are not required to use Apple's in-app purchase mechanism, a rule that it believes should apply to all developers.



• Apple removes Fortnite from the App Store. In a statement shared with MacRumors, the company said that "Epic Games took the unfortunate step of violating the App Store guidelines that are applied equally to every developer and designed to keep the store safe for our users." The full statement is below.

  Today, Epic Games took the unfortunate step of violating the App Store guidelines that are applied equally to every developer and designed to keep the store safe for our users. As a result their Fortnite app has been removed from the store. Epic enabled a feature in its app which was not reviewed or approved by Apple, and they did so with the express intent of violating the App Store guidelines regarding in-app payments that apply to every developer who sells digital goods or services.
  
  Epic has had apps on the App Store for a decade, and have benefited from the App Store ecosystem - including its tools, testing, and distribution that Apple provides to all developers. Epic agreed to the App Store terms and guidelines freely and we're glad they've built such a successful business on the App Store. The fact that their business interests now lead them to push for a special arrangement does not change the fact that these guidelines create a level playing field for all developers and make the store safe for all users. We will make every effort to work with Epic to resolve these violations so they can return Fortnite to the App Store.



• Epic Games files a lawsuit [PDF] against Apple in California, describing the company as a "monopoly power" and accusing it of "unfair and anti-competitive actions." The complaint alleges that "Apple has become what it once railed against: the behemoth seeking to control markets, block competition, and stifle innovation."



• Epic Games shares a video called "Nineteen Eighty-Fortnite," parodying Apple's iconic "1984" ad. Whereas Apple's ad portrayed IBM as the evil "Big Brother," Epic Games aims to show that Apple is now the dominant power. "Epic Games has defied the App Store Monopoly. In retaliation, Apple is blocking Fortnite from a billion devices. Join the fight to stop 2020 from becoming '1984.'"

  
  
  



• In a blog post, Epic Games encourages Fortnite players to fight against Apple's "app tax" by using the hashtag #FreeFortnite on social platforms.


• In an FAQ, Epic Games says that "all mobile developers and consumers have the right to choose alternate payment providers that charge less, as is the norm on all other general-purpose computing platforms, including Web, Windows, and Mac." Epic adds that "Apple even allows Amazon Prime Video to process payments directly as a special deal while holding other apps to a different standard."


• Spotify sides with Epic Games.


• Google removes Fortnite from the Play Store.


• Epic Games files a similar anti-competitive lawsuit against Google.


• Sweeney tweets: "Today, Apple said Epic is seeking a special deal, but that's not true. We're fighting for open platforms and policy changes equally benefiting all developers. And it'll be a hell of a fight!"

August 14

• Sweeney tweets: "At the most basic level, we're fighting for the freedom of people who bought smartphones to install apps from sources of their choosing, the freedom for creators of apps to distribute them as they choose, and the freedom of both groups to do business directly."

Was für ein gewaltiges Mashup! Nicht nur musikalisch, sondern auch in Sachen Video-Edit, haut DJ Primetim auf seinem YouTube-Kanal PRIMETIMEVIDEO einfach mal ein absolutes Brett raus. Insgesamt 300 Lieder aus der mittlerweile rund 40 Jahre andauernden Ära des deutschen Hip Hop (oder heutzutage „Deutschrap“) wurden in 7:30 Minuten vermixt. Von Fettes Brot über Dendemann bis hin zu dem, was da heute in den Charts rumlungert. Vor allem der nostalgische Blick auf die frühen Zeiten ist natürlich absolutes Gold!

„300 Songs aus vierzig Jahren Deutschrap-Geschichte im wilden Video-Mix by DJ Primetime! Leicht anachronistisch, entkontextualisiert! und leider (natürlich) unvollständig!“

via: @falkschacht