Collective #565

Inspirational Website of the Week: Bruno Arizio An outstanding design with some very engaging and elegant interactions. Our pick this week. Get inspired This content is sponsored via Thought Leaders PM tool that’s easy on the eyes Try the modern project management Read more

Testing Made Easier Via Framework Minimalism And Software Architecture

dreamt up by webguru in Uncategorized | Comments Off on Testing Made Easier Via Framework Minimalism And Software Architecture

Testing Made Easier Via Framework Minimalism And Software Architecture

Testing Made Easier Via Framework Minimalism And Software Architecture

Ryan Kay

Like many other Android developers, my initial foray into testing on the platform lead me to be immediately confronted with a demoralizing degree of jargon. Further, what few examples I came across at the time (circa 2015) did not present practical use cases which may have inclined me to think that the cost to benefit ratio of learning a tool like Espresso in order to verify that a TextView.setText(…) was working properly, was a reasonable investment.

To make matters even worse, I did not have a working understanding of software architecture in theory or practice, which meant that even if I bothered to learn these frameworks, I would have been writing tests for monolithic applications comprised of a few god classes, written in spaghetti code. The punchline is that building, testing, and maintaining such applications is an exercise in self-sabotage quite regardless of your framework expertise; yet this realization only becomes clear after one has built a modular, loosely-coupled, and highly-cohesive application.

From here we arrive at one of the main points of discussion in this article, which I will summarize in plain language here: Among the primary benefits of applying the golden principles of software architecture (do not worry, I will discuss them with simple examples and language), is that your code can become easier to test. There are other benefits to applying such principles, but the relationship between software architecture and testing is the focus of this article.

However, for the sake of those who wish to understand why and how we test our code, we will first explore the concept of testing by analogy; without requiring you to memorize any jargon. Before getting deeper into the primary topic, we will also look at the question of why so many testing frameworks exist, for in examining this we may begin to see their benefits, limitations, and perhaps even an alternative solution.

Testing: Why And How

This section will not be new information for any seasoned tester, but perhaps you may enjoy this analogy nonetheless. Of course I am a software engineer, not a rocket engineer, but for a moment I will borrow an analogy which relates to designing and building objects both in physical space, and in the memory space of a computer. It turns out that while the medium changes, the process is in principle quite the same.

Suppose for a moment that we are rocket engineers, and our job is to build the first stage* rocket booster of a space shuttle. Suppose as well, that we have come up with a serviceable design for the first stage to begin building and testing in various conditions.

“First stage” refers to boosters which are fired when the rocket is first launched

Before we get to the process, I would like to point out why I prefer this analogy: You should not have any difficulty answering the question of why we are bothering to test our design before putting it in situations where human lives are at stake. While I will not try to convince you that testing your applications before launch could save lives (although it is possible depending on the nature of the application), it could save ratings, reviews, and your job. In the broadest sense, testing is the way in which we make sure that single parts, several components, and whole systems work before we employ them in situations where it is critically important for them to not fail.

Returning to the how aspect of this analogy, I will introduce the process by which engineers go about testing a particular design: redundancy. Redundancy is simple in principle: Build copies of the component to be tested to the same design specification as what you wish to use at launch time. Test these copies in an isolated environment which strictly controls for preconditions and variables. While this does not guarantee that the rocket booster will work properly when integrated in the whole shuttle, one can be certain that if it does not work in a controlled environment, it will be very unlikely to work at all.

Suppose that of the hundreds, or perhaps thousands of variables which the copies of the rocket design have been tested against, it comes down to ambient temperatures in which the rocket booster will be test fired. Upon testing at 35° Celsius, we see that everything functions without error. Again, the rocket is tested at roughly room temperature without failure. The final test will be at the lowest recorded temperature for the launch site, at -5° Celcius. During this final test, the rocket fires, but after a short period, the rocket flares up and shortly thereafter explodes violently; but fortunately in a controlled and safe environment.

At this point, we know that changes in temperature appear to be at least involved in the failed test, which leads us to consider what parts of the rocket booster may be adversely effected by cold temperatures. Over time, it is discovered that one key component, a rubber O-ring which serves to staunch the flow of fuel from one compartment to another, becomes rigid and ineffectual when exposed to temperatures approaching or below freezing.

It is possible that you have noticed that his analogy is loosely based on the tragic events of the Challenger space shuttle disaster. For those unfamiliar, the sad truth (insofar as investigations concluded) is that there were plenty of failed tests and warnings from the engineers, and yet administrative and political concerns spurred the launch to proceed regardless. In any case, whether or not you have memorized the term redundancy, my hope is that you have grasped the fundamental process for testing parts of any kind of system.

Concerning Software

Whereas the prior analogy explained the fundamental process for testing rockets (while taking plenty of liberty with the finer details), I will now summarize in a manner which is likely more relevant to you and I. While it is possible to test software by only launching it to devices once it is in any sort of deployable state, I suppose instead that we can apply the principle of redundancy to the individual parts of the application first.

This means that we create copies of the smaller parts of the whole application (commonly referred to as Units of software), set up an isolated test environment, and see how they behave based on whatever variables, arguments, events, and responses which may occur at runtime. Testing is truly as simple as that in theory, but the key to even getting to this process lies in building applications which are feasibly testable. This comes down to two concerns which we will look at in the next two sections. The first concern has to do with the test environment, and the second concern has to do with the way in which we structure applications.

Why Do We Need Frameworks?

In order to test a piece of software (henceforth referred to as a Unit, although this definition is deliberately an over-simplification), it is necessary to have some kind of testing environment which allows you to interact with your software at runtime. For those building applications to be executed purely on a JVM (Java Virtual Machine) environment, all that is required to write tests is a JRE (Java Runtime Environment). Take for example this very simple Calculator class:

class Calculator {
    private int add(int a, int b){
        return a + b;

    private int subtract(int a, int b){
        return a - b;

In absence of any frameworks, as long as we have a test class which contains a mainfunction to actually execute our code, we can test it. As you may recall, the main function denotes the starting point of execution for a simple Java program. As for what we are testing for, we simply feed some test data into the Calculator’s functions and verify that it is performing basic arithmetic properly:

public class Main {

    public static void main(String[] args){
    //create a copy of the Unit to be tested
        Calculator calc = new Calculator();
    //create test conditions to verify behaviour
        int addTest = calc.add(2, 2);
        int subtractTest = calc.subtract(2, 2);

    //verify behaviour by assertion
        if (addTest == 4) System.out.println("addTest has passed.");
        else System.out.println("addTest has failed.");

        if (subtractTest == 0) System.out.println("subtractTest has passed.");
        else System.out.println("subtractTest has failed.");

Testing an Android application is of course, a completely different procedure. Although there is a main function buried deep within the source of the file (the finer details of which are not important here), which is invoked prior to an Android application being launched on the JVM, even a junior Android developer ought to know that the system itself is responsible for calling this function; not the developer. Instead, the entry points for Android applications happen to be the Application class, and any Activity classes which the system can be pointed to via the AndroidManifest.xml file.

All of this is just a lead up to the fact that testing Units in an Android application presents a greater level of complexity, strictly because our testing environment must now account for the Android platform.

Taming The Problem Of Tight Coupling

Tight coupling is a term which describes a function, class, or application module which is dependent on particular platforms, frameworks, languages, and libraries. It is a relative term, meaning that our example is tightly coupled to the Java programming language and standard library, but that is the extent of its coupling. Along the same lines, the problem of testing classes which are tightly coupled to the Android platform, is that you must find a way to work with or around the platform.

For classes tightly coupled to the Android platform, you have two options. The first, is to simply deploy your classes to an Android device (physical or virtual). While I do suggest that you test deploy your application code before shipping it to production, this is a highly inefficient approach during the early and middle stages of the development process with respect to time.

A Unit, however technical a definition you prefer, is generally thought of as a single function in a class (although some expand the definition to include subsequent helper functions which are called internally by the initial single function call). Either way, Units are meant to be small; building, compiling, and deploying an entire application to test a single Unit is to miss the point of testing in isolation entirely.

Another solution to the problem of tight coupling, is to use testing frameworks to interact with, or mock (simulate) platform dependencies. Frameworks such as Espresso and Robolectric give developers far more effective means for testing Units than the previous approach; the former being useful for tests run on a device (known as “instrumented tests” because apparently calling them device tests was not ambiguous enough) and the latter being capable of mocking the Android framework locally on a JVM.

Before I proceed to railing against such frameworks instead of the alternative I will discuss shortly, I want to be clear that I do not mean to imply that you should never use these options. The process which a developer uses to build and test their applications should be born of a combination of personal preference and an eye for efficiency.

For those who are not fond of building modular and loosely coupled applications, you will have no choice but to become familiar with these frameworks if you wish to have an adequate level of test coverage. Many wonderful applications have been built this way, and I am not infrequently accused of making my applications too modular and abstract. Whether you take my approach or decide to lean heavily on frameworks, I salute you for putting in the time and effort to test your applications.

Keep Your Frameworks At Arms Length

For the final preamble to the core lesson of this article, it is worth discussing why you might want to have an attitude of minimalism when it comes to using frameworks (and this applies to more than just testing frameworks). The subtitle above is a paraphrase from the magnanimous teacher of software best practices: Robert “Uncle Bob” C. Martin. Of the many gems he has given me since I first studied his works, this one took several years of direct experience to grasp.

Insofar As I understand what this statement is about, the cost of using frameworks is in the time investment required to learn and maintain them. Some of them change quite frequently and some of them do not change frequently enough. Functions become deprecated, frameworks cease to be maintained, and every 6-24 months a new framework arrives to supplant the last. Therefore, if you can find a solution which can be implemented as a platform or language feature (which tend to last much longer), it will tend to be more resistant to changes of the various types mentioned above.

On a more technical note, frameworks such as Espresso and to a lesser degree Robolectric, can never run as efficiently as simple JUnit tests, or even the framework free test from earlier on. While JUnit is indeed a framework, it is tightly coupled to the JVM, which tends to change at a much slower rate than the Android platform proper. Fewer frameworks almost invariably means code which is more efficient in terms of the time it takes to execute and write one or more tests.

From this, you can probably gather that we will now be discussing an approach which will leverage some techniques which allows us to keep the Android platform at arms length; all the while allowing us plenty of code coverage, test efficiency, and the opportunity to still use a framework here or there when the need arises.

The Art Of Architecture

To use a silly analogy, one might think of frameworks and platforms as being like overbearing colleagues who will take over your development process unless you set appropriate boundaries with them. The golden principles of software architecture can give you the general concepts and specific techniques necessary to both create and enforce these boundaries. As we will see in a moment, if you have ever wondered what the benefits of applying software architecture principles in your code truly are, some directly, and many indirectly make your code easier to test.

Separation Of Concerns

Separation Of Concerns is by my estimation the most universally applicable and useful concept in software architecture as a whole (without meaning to say that others should be neglected). Separation of concerns (SOC) can be applied, or completely ignored, across every perspective of software development I am aware of. To briefly summarize the concept, we will look at SOC when applied to classes, but be aware that SOC can be applied to functions through extensive usage of helper functions, and it can be extrapolated to entire modules of an application (“modules” used in the context of Android/Gradle).

If you have spent much time at all researching software architectural patterns for GUI applications, you will likely have come across at least one of: Model-View-Controller (MVC), Model-View-Presenter (MVP), or Model-View-ViewModel (MVVM). Having built applications in every style, I will say upfront that I do not consider any of them to be the single best option for all projects (or even features within a single project). Ironically, the pattern which the Android team presented some years ago as their recommended approach, MVVM, appears to be the least testable in absence of Android specific testing frameworks (assuming you wish to use the Android platform’s ViewModel classes, which I am admittedly a fan of).

In any case, the specifics of these patterns are less important than their generalities. All of these patterns are just different flavours of SOC which emphasize a fundamental separation of three kinds of code which I refer to as: Data, User Interface, Logic.

So, how exactly does separating Data, User Interface, and Logic help you to test your applications? The answer is that by pulling logic out of classes which must deal with platform/framework dependencies into classes which possess little or no platform/framework dependencies, testing becomes easy and framework minimal. To be clear, I am generally talking about classes which must render the user interface, store data in a SQL table, or connect to a remote server. To demonstrate how this works, let us look at a simplified three layer architecture of a hypothetical Android application.

The first class will manage our user interface. To keep things simple, I have used an Activity for this purpose, but I typically opt for Fragments instead as user interface classes. In either case, both classes present similar tight coupling to the Android platform:

public class CalculatorUserInterface extends Activity implements CalculatorContract.IUserInterface {

    private TextView display;
    private CalculatorContract.IControlLogic controlLogic;
    private final String INVALID_MESSAGE = "Invalid Expression.";

    protected void onCreate(Bundle savedInstanceState) {

        controlLogic = new DependencyProvider().provideControlLogic(this);

        display = findViewById(;
        Button evaluate = findViewById(;
        evaluate.setOnClickListener(new View.OnClickListener() {
            public void onClick(View view) {
        //..bindings for the rest of the calculator buttons

    public void updateDisplay(String displayText) {

    public String getDisplay() {
        return display.getText().toString();

    public void showError() {
        Toast.makeText(this, INVALID_MESSAGE, Toast.LENGTH_LONG).show();

As you can see, the Activity has two jobs: First, since it is the entry point of a given feature of an Android application, it acts as a sort of container for the other components of the feature. In simple terms, a container can be thought of as a sort of root class which the other components are ultimately tethered to via references (or private member fields in this case). It also inflates, binds references, and adds listeners to the XML layout (the user interface).

Testing Control Logic

Rather than having the Activity possess a reference to a concrete class in the back end, we have it talk to an interface of type CalculatorContract.IControlLogic. We will discuss why this is an interface in the next section. For now, just understand that whatever is on the other side of that interface is supposed to be something like a Presenter or Controller. Since this class will be controlling interactions between the front-end Activity and the back-end Calculator, I have chosen to call it CalculatorControlLogic:

public class CalculatorControlLogic implements CalculatorContract.IControlLogic {

    private CalculatorContract.IUserInterface ui;
    private CalculatorContract.IComputationLogic comp;

    public CalculatorControlLogic(CalculatorContract.IUserInterface ui, CalculatorContract.IComputationLogic comp) {
        this.ui = ui;
        this.comp = comp;

    public void handleInput(char inputChar) {
        switch (inputChar){
            case '=':
            //...handle other input events
    private void evaluateExpression() {
        Optional result = comp.computeResult(ui.getDisplay());

        if (result.isPresent()) ui.updateDisplay(result.get());
        else ui.showError();

There are many subtle things about the way in which this class is designed that make it easier to test. Firstly, all of its references are either from the Java standard library, or interfaces which are defined within the application. This means that testing this class without any frameworks is an absolute breeze, and it could be done locally on a JVM. Another small but useful tip is that all of the different interactions of this class can be called via a single generic handleInput(...) function. This provides a single entry point to test every behaviour of this class.

Also note that in the evaluateExpression() function, I am returning a class of type Optional<String> from the back end. Normally I would use what functional programmers call an Either Monad, or as I prefer to call it, a Result Wrapper. Whatever stupid name you use, it is an object which is capable of representing multiple different states through a single function call. Optional is a simpler construct which can represent either a null, or some value of the supplied generic type. In any case, since the back end might be given an invalid expression, we want to give the ControlLogicclass some means of determining the result of the backend operation; accounting for both success and failure. In this case, null will represent a failure.

Below is an example test class which has been written using JUnit, and a class which in testing jargon is called a Fake:

public class CalculatorControlLogicTest {

    public void validExpressionTest() {

        CalculatorContract.IComputationLogic comp = new FakeComputationLogic();
        CalculatorContract.IUserInterface ui = new FakeUserInterface();
        CalculatorControlLogic controller = new CalculatorControlLogic(ui, comp);


        assertTrue(((FakeUserInterface) ui).displayUpdateCalled);
        assertTrue(((FakeUserInterface) ui).displayValueFinal.equals("10.0"));
        assertTrue(((FakeComputationLogic) comp).computeResultCalled);


    public void invalidExpressionTest() {

        CalculatorContract.IComputationLogic comp = new FakeComputationLogic();
        ((FakeComputationLogic) comp).returnEmpty = true;
        CalculatorContract.IUserInterface ui = new FakeUserInterface();
        ((FakeUserInterface) ui).displayValueInitial = "+7+7";
        CalculatorControlLogic controller = new CalculatorControlLogic(ui, comp);


        assertTrue(((FakeUserInterface) ui).showErrorCalled);
        assertTrue(((FakeComputationLogic) comp).computeResultCalled);


    private class FakeUserInterface implements CalculatorContract.IUserInterface{
        boolean displayUpdateCalled = false;
        boolean showErrorCalled = false;
        String displayValueInitial = "5+5";
        String displayValueFinal = "";

        public void updateDisplay(String displayText) {
            displayUpdateCalled = true;
            displayValueFinal = displayText;

        public String getDisplay() {
            return displayValueInitial;

        public void showError() {
            showErrorCalled = true;

    private class FakeComputationLogic implements CalculatorContract.IComputationLogic{
        boolean computeResultCalled = false;
        boolean returnEmpty = false;

        public Optional computeResult(String expression) {
            computeResultCalled = true;
            if (returnEmpty) return Optional.empty();
            else return Optional.of("10.0");

As you can see, not only can this test suite be executed very rapidly, but it did not take very much time at all to write. In any case, we will now look at some more subtle things which made writing this test class very easy.

The Power Of Abstraction And Dependency Inversion

There are two other important concepts which have been applied to CalculatorControlLogic which have made it trivially easy to test. Firstly, if you have ever wondered what the benefits of using Interfaces and Abstract Classes (collectively referred to as abstractions) in Java are, the code above is a direct demonstration. Since the class to be tested references abstractions instead of concrete classes, we were able to create Fake test doubles for the user interface and back end from within our test class. As long as these test doubles implement the appropriate interfaces, CalculatorControlLogiccould not care less that they are not the real thing.

Secondly, CalculatorControlLogichas been given its dependencies via the constructor (yes, that is a form of Dependency Injection), instead of creating its own dependencies. Therefore, it does not need to be re-written when used in a production or testing environment, which is a bonus for efficiency.

Dependency Injection is a form of Inversion Of Control, which is a tricky concept to define in plain language. Whether you use Dependency Injection or a Service Locator Pattern, they both achieve what Martin Fowler (my favourite teacher on such topics) describes as “the principle of separating configuration from use.” This results in classes which are easier to test, and easier to build in isolation from one another.

Testing Computation Logic

Finally, we come to the ComputationLogic class, which is supposed to approximate an IO device such as an adapter to a remote server, or a local database. Since we need neither of those for a simple calculator, it will just be responsible for encapsulating the logic required to validate and evaluate the expressions we give it:

public class CalculatorComputationLogic implements CalculatorContract.IComputationLogic {

    private final char ADD = '+';
    private final char SUBTRACT = '-';
    private final char MULTIPLY = '*';
    private final char DIVIDE = '/';

    public Optional computeResult(String expression) {
        if (hasOperator(expression)) return attemptEvaluation(expression);
        else return Optional.empty();


    private Optional attemptEvaluation(String expression) {
        String delimiter = getOperator(expression);
        Binomial b = buildBinomial(expression, delimiter);
        return evaluateBinomial(b);

    private Optional evaluateBinomial(Binomial b) {
        String result;
        switch (b.getOperatorChar()) {
            case ADD:
                result = Double.toString(b.firstTerm + b.secondTerm);
            case SUBTRACT:
                result = Double.toString(b.firstTerm - b.secondTerm);
            case MULTIPLY:
                result = Double.toString(b.firstTerm * b.secondTerm);
            case DIVIDE:
                result = Double.toString(b.firstTerm / b.secondTerm);
                return Optional.empty();
        return Optional.of(result);

    private Binomial buildBinomial(String expression, String delimiter) {
        String[] operands = expression.split(delimiter);
        return new Binomial(

    private String getOperator(String expression) {
        for (char c : expression.toCharArray()) {
            if (c == ADD || c == SUBTRACT || c == MULTIPLY || c == DIVIDE)
                return "" + c;

        return "+";

    private boolean hasOperator(String expression) {
        for (char c : expression.toCharArray()) {
            if (c == ADD || c == SUBTRACT || c == MULTIPLY || c == DIVIDE) return true;
        return false;

    private class Binomial {
        String operator;
        double firstTerm;
        double secondTerm;

        Binomial(String operator, double firstTerm, double secondTerm) {
            this.operator = operator;
            this.firstTerm = firstTerm;
            this.secondTerm = secondTerm;

        char getOperatorChar(){
            return operator.charAt(operator.length() - 1);


There is not too much to say about this class since typically there would be some tight coupling to a particular back-end library which would present similar problems as a class tightly coupled to Android. In a moment we will discuss what to do about such classes, but this one is so easy to test that we may as well have a try:

public class CalculatorComputationLogicTest {

    private CalculatorComputationLogic comp = new CalculatorComputationLogic();

    public void additionTest() {
        String EXPRESSION = "5+5";
        String ANSWER = "10.0";

        Optional result = comp.computeResult(EXPRESSION);

        assertEquals(result.get(), ANSWER);

    public void subtractTest() {
        String EXPRESSION = "5-5";
        String ANSWER = "0.0";

        Optional result = comp.computeResult(EXPRESSION);

        assertEquals(result.get(), ANSWER);

    public void multiplyTest() {
        String EXPRESSION = "5*5";
        String ANSWER = "25.0";

        Optional result = comp.computeResult(EXPRESSION);

        assertEquals(result.get(), ANSWER);

    public void divideTest() {
        String EXPRESSION = "5/5";
        String ANSWER = "1.0";

        Optional result = comp.computeResult(EXPRESSION);

        assertEquals(result.get(), ANSWER);

    public void invalidTest() {
        String EXPRESSION = "Potato";

        Optional result = comp.computeResult(EXPRESSION);


The easiest classes to test, are those which are simply given some value or object, and are expected to return a result without the necessity of calling some external dependencies. In any case, there comes a point where no matter how much software architecture wizardry you apply, you will still need to worry about classes which cannot be decoupled from platforms and frameworks. Fortunately, there is still a way we can employ software architecture to: At worst make these classes easier to test, and at best, so trivially simple that testing can be done at a glance.

Humble Objects And Passive Views

The above two names refer to a pattern in which an object that must talk to low-level dependencies, is simplified so much that it arguably does not need to be tested. I was first introduced to this pattern via Martin Fowler’s blog on variations of Model-View-Presenter. Later on, through Robert C. Martin’s works, I was introduced to the idea of treating certain classes as Humble Objects, which implies that this pattern does not need to be limited to user interface classes (although I do not mean to say that Fowler ever implied such a limitation).

Whatever you choose to call this pattern, it is delightfully simple to understand, and in some sense I believe it is actually just the result of rigorously applying SOC to your classes. While this pattern applies also to back end classes, we will use our user interface class to demonstrate this principle in action. The separation is very simple: Classes which interact with platform and framework dependencies, do not think for themselves (hence the monikers Humble and Passive). When an event occurs, the only thing they do is forward the details of this event to whatever logic class happens to be listening:

//from CalculatorActivity's onCreate() function:
evaluate.setOnClickListener(new View.OnClickListener() {
            public void onClick(View view) {

The logic class, which should be trivially easy to test, is then responsible for controlling the user interface in a very fine-grained manner. Rather than calling a single generic updateUserInterface(...) function on the user interface class and leaving it to do the work of a bulk update, the user interface (or other such class) will possess small and specific functions which should be easy to name and implement:

//Interface functions of CalculatorActivity:
    public void updateDisplay(String displayText) {

    public String getDisplay() {
        return display.getText().toString();

    public void showError() {
        Toast.makeText(this, INVALID_MESSAGE, Toast.LENGTH_LONG).show();

In principal, these two examples ought to give you enough to understand how to go about implementing this pattern. The object which possesses the logic is loosely coupled, and the object which is tightly coupled to pesky dependencies becomes almost devoid of logic.

Now, at the start of this subsection, I made the statement that these classes become arguably unnecessary to test, and it is important we look at both sides of this argument. In an absolute sense, it is impossible to achieve 100% test coverage by employing this pattern, unless you still write tests for such humble/passive classes. It is also worth noting that my decision to use a Calculator as an example App, means that I cannot escape having a gigantic mass of findViewById(...) calls present in the Activity. Giant masses of repetitive code are a common cause of typing errors, and in the absence of some Android UI testing frameworks, my only recourse for testing would be via deploying the feature to a device and manually testing each interaction. Ouch.

It is at this point that I will humbly say that I do not know if 100% code coverage is absolutely necessary. I do not know many developers who strive for absolute test coverage in production code, and I have never done so myself. One day I might, but I will reserve my opinions on this matter until I have the reference experiences to back them up. In any case, I would argue that applying this pattern will still ultimately make it simpler and easier to test tightly coupled classes; if for no reason other than they become simpler to write.

Another objection to this approach, was raised by a fellow programmer when I described this approach in another context. The objection was that the logic class (whether it be a Controller, Presenter, or even a ViewModel depending on how you use it), becomes a God class.

While I do not agree with that sentiment, I do agree that the end result of applying this pattern is that your Logic classes become larger than if you left more decisions up to your user interface class.

This has never been an issue for me as I treat each feature of my applications as self-contained components, as opposed to having one giant controller for managing multiple user interface screens. In any case, I think this argument holds reasonably true if you fail to apply SOC to your front end or back end components. Therefore, my advice is to apply SOC to your front end and back end components quite rigorously.

Further Considerations

After all of this discussion on applying the principles of software architecture to reduce the necessity of using a wide-array of testing frameworks, improve the testability of classes in general, and a pattern which allows classes to be tested indirectly (at least to some degree), I am not actually here to tell you to stop using your preferred frameworks.

For those curious, I often use a library to generate mock classes for my Unit tests (for Java I prefer Mockito, but these days I mostly write Kotlin and prefer Mockk in that language), and JUnit is a framework which I use quite invariably. Since all of these options are coupled to languages as opposed to the Android platform, I can use them quite interchangeably across mobile and web application development. From time to time (if project requirements demand it), I will even use tools like Robolectric, MockWebServer, and in my five years of studying Android, I did begrudgingly use Espresso once.

My hope is that in reading this article, anyone who has experienced a similar degree of aversion to testing due to paralysis by jargon analysis, will come to see that getting started with testing really can be simple and framework minimal.

Further Reading on SmashingMag:

Smashing Editorial
(dm, il)

Source: Smashing Magazine, Testing Made Easier Via Framework Minimalism And Software Architecture

Bringing A Better Design Process To Your Organization

dreamt up by webguru in Uncategorized | Comments Off on Bringing A Better Design Process To Your Organization

Bringing A Better Design Process To Your Organization

Bringing A Better Design Process To Your Organization

Eric Olive

As user experience (UX) designers and researchers, the most common complaint we hear from users is:

“Why don’t they think about what I need?”

In fact, many organizations have teams dedicated to delivering what users and customers need. More and more software developers are eager to work with UX designers in order to code interfaces that customers will use and understand. The problem is that complex software projects can easily become bogged down in competing priorities and confusion about what to do next.

The result is poor design that impedes productivity. For example, efficiency in healthcare is hampered by electronic medical records (EMRs). Complaints about these software systems are legion. Dr. Steven Ugent, a Boston-based dermatologist and Yale Medical School alumnus, is no exception.

Since 2010, Dr. Ugent has used two EMR systems: Before 2010, he finished work promptly at 5:15 every day. Since he and his colleagues started using EMRs, he typically works an extra half hour to 1.5 hours in the evening. “I don’t know any doctor who is happy with their medical records system. The crazy thing is that I was much more efficient when I was using pen and paper.”

man holding pen on paper

The EMR systems are clunky, inflexible, and hard to customize. Ugent, for instance, cannot embed photos directly into his chart notes. Instead, he must open the folder with the photo of the mole and then open a different folder to see the text. This setup is particularly cumbersome for dermatologists who rely heavily on photos when treating patients.

Ugent succinctly summarizes the problem with EMRs:

“The people who design it [the EMR system] don’t understand my workflow. If they did, they would design a different system.”

Doctors are not alone in their frustration with clunky software. Consumers and professionals around the world make similar complaints:

“Why can’t I find what I need?”

“Why do they make it so hard?”

“Why do I have to create a login when I simply want to buy this product. I’m giving them money. Isn’t that enough?”

A major contributor to clunky software is flawed design processes. In this article, we’ll outline four design process problems and explain how to address them.

  1. Complexity
  2. Next-Release Syndrome
  3. Insufficient Time For Design Iterations
  4. Surrendering Control To Outside Vendors

1. Complexity

Scale, multiple stakeholders, and the need for sophisticated code are among the many factors contributing to the complexity of large software projects.

Sometimes overlooked, however, are complex laws and regulations. For example, insurance is heavily regulated at the state level, adding a layer of complexity for insurance companies operating in multiple states. Banks and credit unions are subject to regulation while utilities must comply with state and federal environmental laws.

Healthcare products and software subject to FDA regulations offer an even greater challenge. The problem isn’t that the regulations are unreasonable. Safety is paramount. The issues are time, budget, and the planning necessary to meet FDA requirements.

As Jeff Horvath, Ph.D., a UX consultant with extensive experience in healthcare, explains: “These requirements add a couple of orders of magnitude to the rigor for writing test protocols, test setup, data gathering, analysis, quality controls, and getting approval to conduct the research in the first place.” For example, a single round of usability testing jumps from six weeks (a reasonable time frame for a standard usability test) to six months. And that’s with a single round of usability testing. Often, two or more rounds of testing are necessary.

This level of rigor is a wakeup call for companies new to working with the FDA. More than once, Horvath has faced tough conversations with clients who were unprepared for the extended timelines and additional budget necessary to meet FDA requirements. It’s hard, but necessary. “It pays to be thorough,” says Horvath. In 2018 the FDA approved a mere 11% of pre-market submissions.

The demands on researchers, designers, and developers are higher for healthcare software requiring FDA compliance than for traditional software products. For example:

  • A UX researcher can only conduct one or two usability test sessions per day as opposed to the more common five to six sessions per day for standard software.
  • UX designers must remain hyper-attentive to every aspect of the user’s interaction with software. Even one confusing interaction could cause a clinician to make an error that could jeopardize a patient’s health. For the same reason, UI designers must draw interfaces that remain faithful to every interaction.
  • A longer time frame for design and usability testing means that the developer’s coding efforts must be planned carefully. Skilled and well-intentioned developers are often eager to modify the code as soon as new information becomes available. While this approach can work in organizations well practiced in rapid iteration, it carries risk when designing and coding complex systems.

Failure to manage complexity can have fatal consequences as happened when Danielle McCray was admitted to Tallahassee Memorial Hospital as she was about to give birth. To ease her discomfort, healthcare workers connected her to a patient-controlled analgesia machine, a programmable infusion pump.

Eight hours later McCray was pronounced dead from a morphine overdose. A major factor in this tragedy was the flawed design of the infusion pump used to administer medication. The pump required 27 programming steps. Failure to address such complexity by designing a more intuitive user interface contributed to unnecessary death.


The solution is to acknowledge and address complexity This point sounds logical. Yet, as explained above, complicated FDA regulations often surprise company leaders. Denial doesn’t work. Failing to plan means your organization will likely fall into the 89% of pre-market submissions the FDA rejected in 2018.

When conducting usability tests, user experience researchers must take three steps to manage the complexity associated with FDA regulations:

  1. The moderator (the person who runs the usability test) must be hyper-attentive. For example, if an MRI scan requires a technician to follow a strict sequence of steps while using the associated software, the moderator must observe carefully to determine if the participant follows the instructions to the letter. If not, the task is rated as a failure meaning that both the interface design and associated documentation will require modification;
  2. The moderator must also track close calls. For example, a participant might initially perform the steps out of order, discover the mistake, and recover by following the proper sequence. The FDA considers this a near miss, and the moderator must report it as such;
  3. The moderator must also assess the participant’s knowledge. Does she believe that she has followed the proper sequence? Is this belief accurate?

2. Next-Release Syndrome

One factor in the failure to acknowledge complexity is a fix-it-later mindset we call next-release syndrome. Software bugs are not a problem because “we’ll fix that in the next release.” The emphasis on speed over quality and safety makes it all too easy to postpone solving the hard problems.

Anyone involved in product design and development must tackle next-release syndrome. Two examples make the point:

  • We discovered serious design flaws with a client’s healthcare tracking software. The company chose to release the software without addressing these problems. Not surprisingly, customers were unhappy.
  • We conducted usability tests for a large credit union based in the U.S. The participants were seasoned financial advisers. Testing revealed serious design flaws including confusing status icons, buttons with an unclear purpose, and a nearly hidden link that prevented participants from displaying important data. Remember, if the user doesn’t see it, it’s not there. When we reported the findings, the response was: “We’ll fix that in the next release.” As expected, the web application was not well received. Responses from users included: “Why did you ask us to review the app if you had no intention of making changes?”

Solution: Reject The Fix-It-Next-Time Mentality

The solution is to address serious design problems now. Sounds straightforward. But, how do you convince decision-makers to change the entrenched “fix-it-later” mindset?

The key is to shift the conversation about achievement away from product delivery toward the value created. For example, teams that take the time to revise a design based on user research are likely to see better customer reactions and, over time, increased customer loyalty.

Strengthen the case by using quantitative data to show decision-makers the direct connection between user research and increased revenue and a positive customer experience.

Use data to connect research and design improvements to specific business goals

Use data to connect research and design improvements to specific business goals (Large preview)

Re-defining value is, in effect, a process improvement because it establishes a new set of priorities that better serve customers and your company’s long-term interests. As McKinsey reports in The Business Value of Design: “Top-quartile companies embrace the full user experience; they break down internal barriers among physical, digital, and service design.”

3. Insufficient Time For Design Iterations

Related to the next-release syndrome is insufficient time to iterate the design based on research findings or changing business requirements. “We don’t have time for that,” is the common refrain from developers and product owners. Designers working in Agile environments are frequently pressured to avoid “holding up” the development team.

Development speeds along, and the software is released. We’ve all seen the results from confusing phone apps, to clunky medical records software, to the cumbersome user interface for financial advisers referenced above.

Solution: Design Spikes

One solution comes from the coding world. In his article “Fitting Big-Picture UX Into Agile Development”, Damon Dimmick offers the idea of design spikes, “bubbles of time that allow designers to focus on complex UX issues.” They fit into the Scrum framework by temporarily taking the place of a regular sprint.

Design iteration

Design iteration (Large preview)

Design spikes offer several advantages:

  • They allow UX teams to focus on holistic issues and avoid getting bogged down in granular design issues that are sometimes emphasized within a single sprint;
  • They offer the opportunity to explore complex UX questions from a high level. If needed, the UX design team can also engage in design-centric thinking at any point in order to solve larger UX challenges;
  • By adopting design spikes, UX teams can leverage the same flexibility that development teams use in the agile process and devote the time needed to focus on design issues that don’t always fit well into a standard scrum sprint;
  • Development unlikely to be affected by design decisions can proceed.

Naturally, design iterations often affect certain parts of the code for a site, app, or software product. For this reason, during design spikes any code that will likely be affected by the design spike cannot move forward. But, as Dimmick clearly states, this “delay” will likely save time by avoiding re-work. It simply does not make sense to write code now and then re-write it a few weeks later after the team has agreed on a revised design. In short, postponing some coding actually saves time and budget.

4. Relying Too Heavily On Vendors

Addressing complexity, resisting next-release syndrome, and allowing time for iteration are essential to an effective design process. For many firms, another consideration is their relationship with software vendors. These vendors play an important, even critical, role in development. Yet, granting them too much leverage makes it difficult to control your own product.

Outsourcing to software vendors

Outsourcing to software vendors (Large preview)

Certainly, we should treat colleagues and vendors with respect and make reasonable requests. That doesn’t mean, however, that it’s necessary to surrender all leverage as happened during my tenure at a large finance firm.

While working at this firm as a UX designer, I frequently encountered this dynamic:

Manager: “Hey, Eric can you evaluate this claims software that we’re planning to buy? We just want to make sure it works as intended.”

Me: “Sure, I’ll send you my preliminary findings by the end of the week.”

Manager: “Great”

The following week:

Manager: “Thanks for the review. I see that you found three serious issues: Hard to find the number for an existing claim, screens with too much text that are hard to read, and the difficulty of returning to a previous screen when processing a new claim. That is concerning. Do you think those issues will hinder productivity?”

Me: “Yes, I think these issues will increase stress and processing time in the Claims Center. I’m quite concerned because my previous work with Janet’s team demonstrated that the Claims Center reps are already highly stressed.”

Manager: “Really good to know. I just sent the check. I’ll ask the vendor to fix the problems before they ship.”

Me (screaming inside): “Noooooooooooooo!”

This well-intentioned manager did precisely the wrong thing. He asked for changes after sending the check. No surprise that the vendor never made the requested changes. Why would they? They had their money.

Not only did this scenario play out repeatedly at that company, but I’ve witnessed it throughout my UX career.


The solution is clear. If the vendor product does not meet customer and business needs, and the changes you request are within scope, don’t pay until the vendor makes the changes. It really is that simple.


In this piece, we’ve identified four common barriers to quality design and corresponding solutions:

  1. Complex regulations and standards
    The solution is to acknowledge and address complexity by devising realistic timelines and sufficient budget for research and iterative design.
  2. Shipping software with bugs with a promise to fix them later
    The solution is to avoid next-release syndrome and address serious problems now. Persuade decision-makers by re-defining the meaning of value within your organization.
  3. Insufficient time for design iterations
    The solution is to include design spikes in the agile development process. These bubbles of time temporarily take the place of a sprint and allow designers to focus on complex UX issues.
  4. Relying too heavily on vendors
    The solution is to retain leverage by withholding final payment until the vendor makes requested changes as long as these changes are within the original project scope.

The fourth solution is straightforward. While the first three are not easy, they are concrete because they can be applied directly to existing design processes. Their implementation does not require a massive reorganization or millions of dollars. It simply requires commitment to delivering a better experience.

Smashing Editorial
(ah, il)

Source: Smashing Magazine, Bringing A Better Design Process To Your Organization

How To Build A Real-Time Multiplayer Virtual Reality Game (Part 1)

dreamt up by webguru in Uncategorized | Comments Off on How To Build A Real-Time Multiplayer Virtual Reality Game (Part 1)

How To Build A Real-Time Multiplayer Virtual Reality Game (Part 1)

How To Build A Real-Time Multiplayer Virtual Reality Game (Part 1)

Alvin Wan

In this tutorial series, we will build a web-based multiplayer virtual reality game in which players will need to collaborate to solve a puzzle. We will use A-Frame for VR modeling, MirrorVR for cross-device real-time synchronization, and A-Frame Low Poly for low-poly aesthetics. At the end of this tutorial, you will have a fully functioning demo online that anyone can play.

Each pair of players is given a ring of orbs. The goal is to “turn on” all orbs, where an orb is “on” if it’s elevated and bright. An orb is “off” if it’s lower and dim. However, certain “dominant” orbs affect their neighbors: if it switches state, its neighbors also switch state. Only player 2 can control the dominant orbs while only player 1 can control non-dominant orbs. This forces both players to collaborate to solve the puzzle. In this first part of the tutorial, we will build the environment and add the design elements for our VR game.

The seven steps in this tutorial are grouped into three sections:

  1. Setting Up The Scene (Steps 1–2)
  2. Creating The Orbs (Steps 3–5)
  3. Making The Orbs Interactive (Steps 6–7)

This first part will conclude with a clickable orb that turns on and off (as pictured below). You will use A-Frame VR and several A-Frame extensions.

(Large preview)

Setting Up The Scene

1. Let’s Go With A Basic Scene

To get started, let’s take a look at how we can set up a simple scene with a ground:

Creating a simple scene

Creating a simple scene (Large preview)

The first three instructions below are excerpted from my previous article. You will start by setting up a website with a single static HTML page. This allows you to code from your desktop and automatically deploy to the web. The deployed website can then be loaded on your mobile phone and placed inside a VR headset. Alternatively, the deployed website can be loaded by a standalone VR headset.

Get started by navigating to Then, do the following:

  1. Click on “New Project” in the top right,
  2. Click on “hello-webpage” in the drop-down,
  3. Next, click on index.html in the left sidebar. We will refer to this as your “editor”.

You should now see the following Glitch screen with a default HTML file.

Glitch project: the index.html file

Glitch project: the index.html file (Large preview)

As with the linked tutorial above, start by deleting all existing code in the current index.html file. Then, type in the following for a basic webVR project, using A-Frame VR. This creates an empty scene by using A-Frame’s default lighting and camera.

<!DOCTYPE html>

Raise the camera to standing height. Per A-Frame VR recommendations (Github issue), wrap the camera with a new entity and move the parent entity instead of the camera directly. Between your a-scene tags on lines 8 and 9, add the following.

<!-- Camera! -->
<a-entity id="rig" position="0 3 0">
  <a-camera wasd-controls look-controls></a-camera>

Next, add a large box to denote the ground, using a-box. Place this directly beneath your camera from the previous instruction.

<!-- Action! -->
<a-box shadow width="75" height="0.1" depth="75" position="0 -1 0" color="#222"></a-box>

Your index.html file should now match the following exactly. You can find the full source code here, on Github.

      <!-- Camera! -->
      <a-entity id="rig" position="0 3 0">
        <a-camera wasd-controls look-controls></a-camera>

      <!-- Action! -->
      <a-box shadow width="75" height="0.1" depth="75" position="0 -1 0" color="#222"></a-box>

This concludes setup. Next, we will customize lighting for a more mysterious atmosphere.

2. Add Atmosphere

In this step, we will set up the fog and custom lighting.

A preview of a simple scene with a dark mood

A preview of a simple scene with a dark mood (Large preview)

Add a fog, which will obscure objects far away for us. Modify the a-scene tag on line 8. Here, we will add a dark fog that quickly obscures the edges of the ground, giving the effect of a distant horizon.

<a-scene fog="type: linear; color: #111; near:10; far:15"></a-scene>

The dark gray #111 fades in linearly from a distance of 10 to a distance of 15. All objects more than 15 units away are completely obscured, and all objects fewer than 10 units away are completely visible. Any object in between is partially obscured.

Add one ambient light to lighten in-game objects and one-directional light to accentuate reflective surfaces you will add later. Place this directly after the a-scene tag you modified in the previous instruction.

<!-- Lights! -->
<a-light type="directional" castshadow="true" intensity="0.5" color="#FFF" position="2 5 0"></a-light>
<a-light intensity="0.1" type="ambient" position="1 1 1" color="#FFF"></a-light>

Directly beneath the lights in the previous instruction, add a dark sky. Notice the dark gray #111 matches that of the distant fog.

<a-sky color="#111"></a-sky>

This concludes basic modifications to the mood and more broadly, scene setup. Check that your code matches the source code for Step 2 on Github, exactly. Next, we will add a low-poly orb and begin customizing the orb’s aesthetics.

Creating The Orbs

3. Create A Low-Poly Orb

In this step, we will create a rotating, reflective orb as pictured below. The orb is composed of two stylized low-poly spheres with a few tricks to suggest reflective material.

Rotating, reflective orb
(Large preview)

Start by importing the low-poly library in your head tag. Insert the following between lines 4 and 5.

Create a carousel, wrapper, and orb container. The carousel will contain multiple orbs, the wrapper will allow us to rotate all orbs around a center axis without rotating each orb individually, and the container will — as the name suggests — contain all orb components.

<a-entity id="carousel">
  <a-entity rotation="0 90 0" id="template" class="wrapper" position="0 0 0">
    <a-entity id="container-orb0" class="container" position="8 3 0" scale="1 1 1">
      <!-- place orb here -->

Inside the orb container, add the orb itself: one sphere is slightly translucent and offset, and the other is completely solid. The two combined mimic reflective surfaces.

<a-entity class="orb" id="orb0" data-id="0">
  <lp-sphere seed="0" shadow max-amplitude="1 1 1" position="-0.5 0 -0.5"></lp-sphere>
  <lp-sphere seed="0" shadow max-amplitude="1 1 1" rotation="0 45 45" opacity="0.5" position="-0.5 0 -0.5"></lp-sphere>

Finally, rotate the sphere indefinitely by adding the following a-animation tag immediately after the lp-sphere inside the .orb entity in the last instruction.

<a-animation attribute="rotation" repeat="indefinite" from="0 0 0" to="0 360 0" dur="5000"></a-animation>

Your source code for the orb wrappers and the orb itself should match the following exactly.

<a-entity id="carousel">
  <a-entity rotation="0 90 0" id="template" class="wrapper" position="0 0 0">
    <a-entity id="container-orb0" class="container" position="8 3 0" scale="1 1 1">
      <a-entity class="orb" id="orb0" data-id="0">
        <lp-sphere seed="0" shadow max-amplitude="1 1 1" position="-0.5 0 -0.5"></lp-sphere>
        <lp-sphere seed="0" shadow max-amplitude="1 1 1" rotation="0 45 45" opacity="0.5" position="-0.5 0 -0.5"></lp-sphere>
        <a-animation attribute="rotation" repeat="indefinite" from="0 0 0" to="0 360 0" dur="5000"></a-animation>

Check that your source code matches the full source code for step 3 on Github. Your preview should now match the following.

Rotating, reflective orb
(Large preview)

Next, we will add more lighting to the orb for a golden hue.

4. Light Up The Orb

In this step, we will add two lights, one colored and one white. This produces the following effect.

Orb lit with point lights
(Large preview)

Start by adding the white light to illuminate the object from below. We will use a point light. Directly before #orb0 but within #container-orb0, add the following offset point light.

<a-entity position="-2 -1 0">
    <a-light distance="8" type="point" color="#FFF" intensity="0.8"></a-light>

In your preview, you will see the following.

Orb lit with white point light
(Large preview)

By default, lights do not decay with distance. By adding distance="8", we ensure that the light fully decays with a distance of 8 units, to prevent the point light from illuminating the entire scene. Next, add the golden light. Add the following directly above the last light.

<a-light class="light-orb" id="light-orb0" distance="8" type="point" color="#f90" intensity="1"></a-light>

Check that your code matches the source code for step 4 exactly. Your preview will now match the following.

Orb lit with point lights
(Large preview)

Next, you will make your final aesthetic modification to the orb and add rotating rings.

5. Add Rings

In this step, you will produce the final orb, as pictured below.

Golden orb with multiple rings
(Large preview)

Add a ring in #container-orb0 directly before #orb0.

<a-ring color="#fff" material="side:double" position="0 0.5 0" radius-inner="1.9" radius-outer="2" opacity="0.25"></a-ring>

Notice the ring itself does not contain color, as the color will be imbued by the point light in the previous step. Furthermore, the material="side:double" is important as, without it, the ring’s backside would not be rendered; this means the ring would disappear for half of its rotation.

However, the preview with only the above code will not look any different. This is because the ring is currently perpendicular to the screen. Thus, only the ring’s “side” (which has 0 thickness) is visible. Place the following animation in between the a-ring tags in the previous instruction.

<a-animation attribute="rotation" easing="linear" repeat="indefinite" from="0 0 0" to="0 360 0" dur="8000"></a-animation>

Your preview should now match the following:

Golden orb with ring
(Large preview)

Create a variable number of rings with different rotation axes, speeds, and sizes. You can use the following example rings. Any new rings should be placed underneath the last a-ring.

<a-ring color="#fff" material="side:double" position="0 0.5 0" radius-inner="2.4" radius-outer="2.5" opacity="0.25">
  <a-animation attribute="rotation" easing="linear" repeat="indefinite" from="0 45 0" to="360 45 0" dur="8000"></a-animation>
<a-ring color="#fff" material="side:double" position="0 0.5 0" radius-inner="1.4" radius-outer="1.5" opacity="0.25">
  <a-animation attribute="rotation" easing="linear" repeat="indefinite" from="0 -60 0" to="-360 -60 0" dur="3000"></a-animation>

Your preview will now match the following.

Golden orb with multiple rings
(Large preview)

Check that your code matches the source code for step 5 on Github. This concludes decor for the orb. With the orb finished, we will next add interactivity to the orb. In the next step, we will specifically add a visible cursor with a clicking animation when pointed at clickable objects.

Making The Orbs Interactive

6. Add A Cursor

In this step, we will add a white cursor that can trigger clickable objects. The cursor is pictured below.

clicking on orb
(Large preview)

In your a-camera tag, add the following entity. The fuse attribute allows this entity the ability to trigger click events. The raycaster attribute determines how often and how far to check for clickable objects. The objects attribute accepts a selector to determine which entities are clickable. In this case, all objects of class clickable are clickable.

<a-entity cursor="fuse: true; fuseTimeout: 250"
      position="0 0 -1"
      geometry="primitive: ring; radiusInner: 0.03; radiusOuter: 0.04"
      material="color: white; shader: flat; opacity: 0.5"
      scale="0.5 0.5 0.5"
      raycaster="far: 20; interval: 1000; objects: .clickable">
    <!-- Place cursor animation here -->

Next, add cursor animation and an extra ring for aesthetics. Place the following inside the entity cursor object above. This adds animation to the cursor object so that clicks are visible.

<a-circle radius="0.01" color="#FFF" opacity="0.5" material="shader: flat"></a-circle>
<a-animation begin="fusing" easing="ease-in" attribute="scale"
   fill="backwards" from="1 1 1" to="0.2 0.2 0.2" dur="250"></a-animation>

Next, add the clickable class to the #orb0 to match the following.

<a-entity class="orb clickable" id="orb0" data-id="0">

Check that your code matches the source code for Step 6 on Github. In your preview, drag your cursor off of them onto the orb to see the click animation in action. This is pictured below.

clicking on orb
(Large preview)

Note the clickable attribute was added to the orb itself and not the orb container. This is to prevent the rings from becoming clickable objects. This way, the user must click on the spheres that make up the orb itself.

In our final step for this part, you will add animation to control the on and off states for the orb.

7. Add Orb States

In this step, you will animate the orb in and out of an off state on click. This is pictured below.

Interactive orb responding to clicks
(Large preview)

To start, you will shrink and lower the orb to the ground. Add a-animation tags to the #container-orb0 right after #orb0. Both animations are triggered by a click and share the same easing function ease-elastic for a slight bounce.

<a-animation class="animation-scale" easing="ease-elastic" begin="click" attribute="scale" from="0.5 0.5 0.5" to="1 1 1" direction="alternate" dur="2000"></a-animation>
<a-animation class="animation-position" easing="ease-elastic" begin="click" attribute="position" from="8 0.5 0" to="8 3 0" direction="alternate" dur="2000"></a-animation>

To further emphasize the off state, we will remove the golden point light when the orb is off. However, the orb’s lights are placed outside of the orb object. Thus, the click event is not passed to the lights when the orb is clicked. To circumvent this issue, we will use some light Javascript to pass the click event to the light. Place the following animation tag in #light-orb0. The light is triggered by a custom switch event.

<a-animation class="animation-intensity" begin="switch" attribute="intensity" from="0" to="1" direction="alternate"></a-animation>

Next, add the following click event listener to the #container-orb0. This will relay the clicks to the orb lights.

<a-entity id="container-orb0" ... onclick="document.querySelector('#light-orb0').emit('switch');">

Check that your code matches the source code for Step 7 on Github. Finally, pull up your preview, and move the cursor on and off the orb to toggle between off and on states. This is pictured below.

Interactive orb responding to clicks
(Large preview)

This concludes the orb’s interactivity. The player can now turn orbs on and off at will, with self-explanatory on and off states.


In this tutorial, you built a simple orb with on and off states, which can be toggled by a VR-headset-friendly cursor click. With a number of different lighting techniques and animations, you were able to distinguish between the two states. This concludes the virtual reality design elements for the orbs. In the next part of the tutorial, we will populate the orbs dynamically, add game mechanics, and set up a communication protocol between a pair of players.

Smashing Editorial
(rb, dm, il)

Source: Smashing Magazine, How To Build A Real-Time Multiplayer Virtual Reality Game (Part 1)

Collective #541

dreamt up by webguru in Uncategorized | Comments Off on Collective #541


Get Waves

A free SVG wave generator to make unique SVG waves. Choose a curve, adjust complexity and randomize.

Check it out



StoryTime enables developers to easily simulate debugger-like visuals to tell or read a story about pieces of code.

Check it out



A React codebase generator where you can select the stack you want, pick a template and then export a complete React codebase. By Gabe Ragland.

Check it out


Input delay

Monica Dinculescu created this experiment to see what amount of delay is too annoying for a user interaction like typing.

Check it out


Day/Night Ambient Light Animation

Mandy Michael shares a demo that shows how to change the page content based on the light level in the room using the Ambient Light API. Works behind the #enable-generic-sensor-extra-classes flag in chrome://flags.

Check it out



An open source Minecraft clone built with ThreeJS, ReactJS, GraphQL, and NodeJS.

Check it out



An AI powered interactive experiment where you can release fireballs from your mouth and head bang to break barriers.

Check it out



Vladimir Agafonkin introduces MARTINI, an open source, client-side terrain mesh generation library.

Check it out

Collective #541 was written by Pedro Botelho and published on Codrops.

Source: Codrops, Collective #541

Pitching Your Writing To Publications

dreamt up by webguru in Uncategorized | Comments Off on Pitching Your Writing To Publications

Pitching Your Writing To Publications

Pitching Your Writing To Publications

Rachel Andrew

Recently, I had a chat with Chris Coyier and Dave Rupert over on the Shoptalk Podcast about writing for publications such as Smashing Magazine and CSS-Tricks. One of the things we talked about was submitting ideas to publications — something that can feel quite daunting even as an experienced writer.

In this article, I’m going to go through the process for pitching, heavily based on my own experience as a writer and as Editor in Chief of Smashing. However, I’ve also taken a look at the guidelines for other publications in order to help you find the right places to pitch your article ideas.

Do Your Research

Read existing articles on the site that you would like to write for. Who do they seem to be aimed at? What tone of voice do the writers take? Does the publication tend to publish news pieces, opinion, or how-to tutorials? Check to see if there are already other pieces which are on the same subject as your idea, i.e. will your piece add to the conversation already started by those articles? If you can show that you are aware of existing content on a particular subject, and explain how you will reference it or add to that information, the editor will know you have done some research.

Research more widely; are there already good pieces on the subject that an editor will consider your piece to be a repeat of? There is always space for a new take on an issue, but in general, publications want fresh material. You should be ready to explain how your piece will reference this earlier work and build upon it, or introduce the subject to a new audience.

A good example from our own archives is the piece, “Replacing jQuery With Vue.js”. There are a lot of introductions to Vue.js, however, this piece was squarely aimed at the web developer who knows jQuery. It introduced the subject in a familiar way specifically for the target audience.

Find The Submission Guide

The next thing to do is to find the submission information on the site you want to write for. Most publications will have information about who to contact and what information to include. From my point of view, simply following that information and demonstrating you have done some research puts you pretty high up the queue to be taken seriously. At Smashing Magazine, we have a link to the guide to writing for us right there on the contact form. I’d estimate that only 20% of people read and follow those instructions.

Screenshot of the Smashing Contact Form
The link to our submission guide on our Contact Us page.

When you submit your idea, it is up to you to sell it to the publication. Why should I run with your idea over the many others that will show up today? Spending time over your submissions will make a huge difference in how many pieces you have accepted.

Different publications have different requirements. At Smashing Magazine, we ask you to send an outline first, along with some information about you so that we can understand your expertise in the subject matter. We’re very keen to feature new voices, and so we’ll accept pieces from writers who haven’t got a huge string of writing credentials.

The information we request helps us to decide if you are likely to be able to deliver a coherent piece. As our articles are technical in nature (often tutorials), I find that an outline is the best way to quickly see the shape of the proposal and the scope it will cover. A good outline will include the main headings or sections of the article, along with an explanation of what will be taught in that section.

For many other publications, a common request is for you to send a pitch for the article. This would typically be a couple of paragraphs explaining the direction your piece will take. Once again, check the submission guide for any specific details that publication is interested to see.

The Verge has an excellent submission guide which explains exactly what they want to see in a pitch:

“A good pitch contains a story, a narrative backbone. Pitches should clearly and concisely convey the story you plan to write and why it matters. The best pitches display promising pre-reporting and deep knowledge of the topic as well as a sense of the angle or insight you plan to pursue. If your story depends on access to a person or company, you should say whether you have obtained it already (and if not, what your prospects are). Pitches should also be written in the style you expect to write the story.”

— “How To Pitch The Verge,” The Verge

A List Apart explains what they will accept in their contribution page:

“… a rough draft, a partial draft, or a short pitch (a paragraph or two summarizing your argument and why it matters to our readers) paired with an outline. The more complete your submission is, the better feedback we can give you.”

— “Write For Us,” A List Apart

The Slate has a list of Do’s and Don’ts for pitching:

“Do distill your idea into a pitch, even if you have a full draft already written. If you happen to have a draft ready, feel free to attach it, but please make sure you still include a full pitch describing the piece in the body of the email.”

— “How To Pitch Slate,” The Slate

Including your pitch or outline in the body of the email is a common theme of pitch guidelines. Remember that your aim is to make it as easy as possible for the editor to think, “that looks interesting”.

Include A Short Biography

The editor doesn’t need your life story, however, a couple of sentences about you is helpful. This is especially useful if you are a newer writer who has subject matter expertise but fewer writing credentials. If you are proposing an article to me about moving a site from WordPress to Gatsby, and tell me that the article is based on your experience of doing this on a large site, that is more interesting to me than a more experienced writer who has just thought it would be a good topic to write about.

If you do have writing credits, a few relevant links are more helpful than a link to your entire portfolio.

When You Can’t Find A Submission Guide

Some publications will publish an email address or contact form for submissions, but have no obvious guide. In that case, assume that a short pitch as described above is appropriate. Include the pitch in the body of the email rather than an attachment, and make sure you include contact details in addition to your email address.

If you can’t find any information about submitting, then check to see if the publication is actually accepting external posts. Are all the articles written by staff? If unsure, then get in touch via a published contact method and ask if they accept pitches.

I’ve Already Written My Article, Why Should I Send An Outline Or Pitch?

We ask for an outline for a few reasons. Firstly, we’re a very small team. Each proposal is assessed by me, and I don’t have time in the day to read numerous 3000-word first draft proposals. In addition, we often have around 100 articles in the writing process at any one time. It’s quite likely that two authors will want to write on the same subject.

On receiving an outline, if it is going in a similar direction to something we already have in the pipeline, I can often spot something that would add to — rather than repeat — the other piece. We can then guide you towards that direction, and be able to accept the proposal where a completed piece may have been rejected as too similar.

If you are a new writer, the ability to structure an outline tells me a lot about your ability to deliver us something useful. We are going to spend time and energy working with you on your article, and I want to know it will be worthwhile for all of us.

If you are an experienced writer, the fact that you have read and worked with our guidelines tells me a lot about you as a professional. Are you going to be difficult for our editorial team to work with and refuse to make requested changes? Or are you keen to work with us to shape a piece that will be most useful and practical for the audience?

In The Verge submission guide included above, they ask you to “clearly and concisely” convey the story you plan to write. Your pitch shouldn’t be an article with bits removed or about the first two paragraphs. It’s literally a sales pitch for your proposed article; your job is to make the editor excited to read your full proposal! Some publications — in particular those that publish timely pieces on news topics — will ask you to attach your draft along with the pitch, however, you still need to get the editor to think it is worth opening that document.

Promoting Yourself Or Your Business

In many guides to self-promotion or bootstrapping the promotion of a startup, writing guest posts is something that will often be suggested. Be aware that the majority of publications are not going to publish an advert and pay you for the privilege.

Writing an article that refers to your product may be appropriate, as most of our expertise comes from doing the job that we do. It is worth being upfront when proposing a piece that would need to mention your product or the product of the company you work for. Explain how your idea will not be an advert for the company and that the product will only be mentioned in the context of the experience gained in your work.

Some publications will accept a trade of an article for some promotion. CSS-Tricks is one such publication, and describes what they are looking for as follows:

“The article is intended to promote something. In that case, no money changes hands. In this scenario, your pitch must be different from a sponsored post in that you aren’t just straight up pitching your product or service and that you’re writing a useful article about the web; it just so happens to be something that the promotion you’ll get from this article is valuable to you.”

— “Guest Posting,” CSS-Tricks

Writing for a popular publication will give you a byline, i.e. your credit as an author. That will generally give you at least one link to your own site. Writing well-received articles can be a way to build up your reputation and even introduce people to your products and services, but if you try and slide an advert in as an article, you can be sure that editors are very well used to spotting that!

Pitching The Same Idea To Multiple Publications

For time-sensitive pieces, you might be keen to spread the net. In that case, you should make publications aware of submitting that you have submitted it elsewhere. Otherwise, it is generally good practice to wait for a response before offering the piece to another publication. The Slate writes,

“Do be mindful if you pitch your idea to multiple publications. We try to reply to everyone in a timely manner, typically within one to two days. As a general rule, and if the story isn’t too timely, it’s best to wait that amount of time before sharing the pitch with another publication. If you do decide to cast a wide net, it’s always helpful to let us know ahead of time so we can respond accordingly.”

— “How To Pitch Slate,” The Slate

If Your Pitch Is Rejected

You will have ideas rejected. Sometimes, the editor will let you know why, but most often you’ll get a quick no, thanks. Try not to take these to heart; there are many reasons why the piece might be rejected that have nothing to do with the article idea or the quality of your proposal.

The main reasons I reject pitches are as follows:

  1. Obvious Spam
    This is the easy one. People wanting to publish a “guest post” on vague subjects, and people wanting “do-follow links”. We don’t tend to reply to these as they are essentially spam.
  2. No Attempt At A Serious Outline
    I can’t tell anything about an idea from two sentences or three bullet points, and if the author can’t spend the time to write an outline, I don’t think I want to have a team member working with them.
  3. Not A Good Topic For Us
    There are some outlines that I can’t ever see being a great fit for our readers.
  4. An Attempt To Hide An Advert
    In this case, I’ll suggest that you talk to our advertising team!
  5. Difficult To Work With
    Last but not least, authors who have behaved so badly during the pitch process that I can’t bring myself to inflict them on anyone else. Don’t be that person!

If I have a decent outline on a relevant subject in front of me, then one of two things are going to happen: I’ll accept the outline and get the author into the writing process or I’ll reply to the author because there is some reason why we can’t accept the outline as it is. That will usually be because the target audience or tone is wrong, or we already have a very similar piece in development.

Quite often in these scenarios, I will suggest changes or a different approach. Many of those initial soft rejections become an accepted idea, or the author comes back with a different idea that does indeed work.

Ultimately, those of us who need to fill a publication with content really want you to bring us good ideas. To open my inbox and find interesting pitches for Smashing is a genuine highlight of my day. So please do write for us.

Things To Do

  • Research the publication, and the type of articles they publish;
  • Read their submissions guide, and follow it;
  • Be upfront if you have sent the pitch to other publications;
  • Include a couple of sentences about you, and why you are the person to write the article. Link to some other relevant writing if you have it;
  • Be polite and friendly, but concise.

Things To Avoid

  • Sending a complete draft along with the words, “How do I publish this on your site?”;
  • Sending things in a format other than suggested in the submissions guide;
  • Pitching a piece that is already published somewhere else;
  • Pitching a hidden advert for your product or services;
  • Following up aggressively, or sending the pitch to multiple editors, Facebook messenger, and Twitter, in an attempt to get noticed. We publish a pitch contact, because we want pitches. It might take a day or two to follow up though!

More Pitching Tips

Smashing Editorial

Source: Smashing Magazine, Pitching Your Writing To Publications

Monthly Web Development Update 8/2019: Strong Teams And Ethical Data Sensemaking

dreamt up by webguru in Uncategorized | Comments Off on Monthly Web Development Update 8/2019: Strong Teams And Ethical Data Sensemaking

Monthly Web Development Update 8/2019: Strong Teams And Ethical Data Sensemaking

Monthly Web Development Update 8/2019: Strong Teams And Ethical Data Sensemaking

Anselm Hannemann

What’s more powerful than a star who knows everything? Well, a team not made of stars but of people who love what they do, stand behind their company’s vision and can work together, support each other. Like a galaxy made of stars — where not every star shines and also doesn’t need to. Everyone has their place, their own strength, their own weakness. Teams don’t consist only of stars, they consist of people, and the most important thing is that the work and life culture is great. So don’t do a moonshot if you’re hiring someone but try to look for someone who fits into your team and encourages, supports your team’s values and members.

In terms of your own life, take some time today to take a deep breath and recall what happened this week. Go through it day by day and appreciate the actions, the negative ones as well as the positive ones. Accept that negative things happen in our lives as well, otherwise we wouldn’t be able to feel good either. It’s a helpful exercise to balance your life, to have a way of invalidating the feeling of “I did nothing this week” or “I was quite unproductive.” It makes you understand why you might not have worked as much as you’re used to — but it feels fine because there’s a reason for it.


  • Three weeks ago we officially exhausted the Earth’s natural resources for the year — with four months left in 2019. Earth Overshoot Day is a good indicator of where we’re currently at in the fight against climate change and it’s a great initiative by people who try to give helpful advice on how we can move that date so one day in the (hopefully) near future we’ll reach overshoot day not before the end of the year or even in a new year.
  • Chrome 76 brings the prefers-color-scheme media query (e.g. for dark mode support) and multiple simplifications for PWA installation.



Web Performance

  • Some experiments sound silly but in reality, they’re not: Chris Ashton used the web for a day on a 50MB budget. In Zimbabwe, for example, where 1 GB costs an average of $75.20, ranging from $12.50 to $138.46, 50MB is incredibly expensive. So reducing your app bundle size, image size, and website cost are directly related to how happy your users are when they browse your site or use your service. If it costs them $3.76 (50MB) to access your new sports shoe teaser page, it’s unlikely that they will buy or recommend it.
  • BBC’s Toby Cox shares how they ditched iframes in favor of ShadowDOM to improve their site performance significantly. This is a good piece explaining the advantages and drawbacks of iframes and why adopting ShadowDOM takes time and still feels uncomfortable for most of us.
  • Craig Mod shares why people prefer to choose (and pay for) fast software. People are grateful for it and are easily annoyed if the app takes too much time to start or shows a laggy user interface.
  • Harry Roberts explains the details of the “time to first byte” metric and why it matters.



  • With Chrome 76 we get the loading attribute which allows for native lazy loading of images just with HTML. It’s great to have a handy article that explains how to use, debug, and test it on your website today.

Lazy loading images of cats

No more custom lazy-loading code or a separate JavaScript library needed: Chrome 76 comes with native lazy loading built in. (Image credit)



  • Here’s a technical analysis of the Capital One hack. A good read for anyone who uses Cloud providers like AWS for their systems because it all comes down to configuring accounts correctly to prevent hackers from gaining access due to a misconfigured cloud service user role.


Work & Life

  • For a long time I believed that a strong team is made of stars — extraordinary world-class individuals who can generate and execute ideas at a level no one else can. These days, I feel that a strong team is the one that feels more like a close family than a constellation of stars. A family where everybody has a sense of predictability, trust and respect for each other. A family which deeply embodies the values the company carries and reflects these values throughout their work. But also a family where everybody feels genuinely valued, happy and ignited to create,” said Vitaly Friedman in an update thought recently and I couldn’t agree more.
  • How do you justify a job in a company that has a significant influence on our world and our everyday lives and that not necessarily with the best intentions? Meredith Whittaker wrote up her story of starting at Google, having an amazing time there, and now leaving the company because she couldn’t justify it anymore that Google is using her work and technology to get involved in fossil energy business, healthcare, governance, and transportation business — and not always with the focus on improving everyone’s lives or making our environment a better place to live in but simply for profit.
  • Synchronous meetings are a problem in nearly every company. They take a lot of time from a lot of people and disrupt any schedule or focused work. So here’s how Buffer switched to asynchronous meetings, including great tips and insights into why many tools out there don’t work well.
  • Actionable advice is what we usually look for when reading an article. However, it’s not always possible or the best option to write actionable advice and certainly not always a good idea to follow actionable advice blindly. That’s because most of the time actionable advice also is opinionated, tailored, customized advice that doesn’t necessarily fit your purpose. Sharing experiences instead of actionable advice fosters creativity so everyone can find their own solution, their own advice.
  • Sam Clulow’s “Our Planet, Our Problem” is a great piece of writing that reminds us of who we are and what’s important for us and how we can live in a city and switch to a better, more thoughtful and natural life.
  • Climate change is a topic all around the world now and it seems that many people are concerned about it and want to take action. But then, last month we had the busiest air travel day ever in history. Airplanes are accountable for one of the biggest parts of climate active emissions, so it’s key to reduce air travel as much as possible from today on. Coincidentally, this was also the hottest week measured in Europe ever. We as individuals need to finally cut down on flights, regardless of how tempting that next $50-holiday-flight to a nice destination might be, regardless of if it’s an important business meeting. What do we have video conferencing solutions for? Why do people claim to work remotely if they then fly around the world dozens of times in their life? There are so many nice destinations nearby, reachable by train or, if needed, by car.

Update from a team member of what happened during the week and what he’s working on

The team at Buffer shares what worked and what didn’t work for them when they switched to asynchronous meetings. (Image credit)

Going Beyond…

  • Leo Babauta shares a tip on how to stop overthinking by cutting through indecision. We will never have the certainty we’d like to have in our lives so it’s quite good to have a strategy for dealing with uncertainty. As I’m struggling with this a lot, I found the article helpful.
  • The ethical practices that can serve as a code of conduct for data sensemaking professionals are built upon a single fundamental principle. It is the same principle that medical doctors swear as an oath before becoming licensed: Do no harm. Here’s “Ethical Data Sensemaking.”
  • Paul Hayes shares his experience from trying to live plastic-free for a month and why it’s hard to stick to it. It’s surprising how shopping habits need to be changed and why you need to spend your money in a totally different way and cannot rely on online stores anymore.
  • Oil powers the cars we drive and the flights we take, it heats many of our homes and offices. It is in the things we use every day and it plays an integral role across industries and economies. Yet it has become very clear that the relentless burning of fossil fuels cannot continue unabated. Can the world be less reliant on oil?
  • Uber and Lyft admit that they’re making traffic congestion worse in cities. Next time you use any of those new taxi apps, try to remind yourself that you’re making the situation worse for many people in the city.

Thank you for reading. If you like what I write, please consider supporting the Web Development Reading List.


Smashing Editorial

Source: Smashing Magazine, Monthly Web Development Update 8/2019: Strong Teams And Ethical Data Sensemaking

The (Upcoming) WordPress Renaissance

dreamt up by webguru in Uncategorized | Comments Off on The (Upcoming) WordPress Renaissance

The (Upcoming) WordPress Renaissance

The (Upcoming) WordPress Renaissance

Leonardo Losoviz

It has been 8 months since Gutenberg was launched as the default content editor in WordPress. Depending who you ask, you may hear that Gutenberg is the worst or the best thing that has happened to WordPress (or anything in between). But something that most people seem to agree with, is that Gutenberg has been steadily improving. At the current pace of development, it’s only a matter of time until its most outstanding issues have been dealt with and the user experience becomes truly pleasant.

Gutenberg is an ongoing work in progress. While using it, I experience maddening nuisances, such as floating options that I can’t click on because the block placed below gets selected instead, unintuitive grouping of blocks, columns with so much gap that make them useless, and the “+” element calling for my attention all over the page. However, the problems I encounter are still relatively manageable (which is an improvement from the previous versions) and, moreover, Gutenberg has started making its potential benefits become a reality: Many of its most pressing bugs have been ironed out, its accessibility issues are being solved, and new and exciting features are continuously being made available. What we have so far is pretty decent, and it will only get better and better.

Let’s review the new developments which have taken place since Gutenberg’s launch, and where it is heading to.

Note: For more information about this topic, I recommend watching WordPress founder Matt Mullenweg’s talk during the recent WordCamp Europe 2019.

Why Gutenberg Was Needed

Gutenberg arrived just in time to kick-start the rejuvenation of WordPress, to attempt to make WordPress appealing to developers once again (and reverse its current status of being the most dreaded platform). WordPress had stopped looking attractive because of its focus on not breaking backwards compatibility, which prevented WordPress from incorporating modern code, making it look pale in comparison with newer, shinier frameworks.

Many people argue that WordPress was in no peril of dying (after all, it powers more than 1/3rd of the web), so that Gutenberg was not really needed, and they may be right. However, even if WordPress was in no immediate danger, by being disconnected from modern development trends it was headed towards obsolescence, possibly not in the short-term but certainly in the mid to long-term. Let’s review how Gutenberg improves the experience for different WordPress stakeholders: developers, website admins, and website users.

Developers have recently embraced building websites through JavaScript libraries Vue and React because (among other reasons) of the power and convenience of components, which translates into a satisfying developer-experience. By jumping into the bandwagon and adopting this technique, Gutenberg enables WordPress to attract developers once again, allowing them to code in a manner they find gratifying.

Website admins can manage their content more easily, improve their productivity, and achieve things that couldn’t be done before. For instance, placing a Youtube video through a block is easier than through the TinyMCE Textarea, blocks can serve optimal images (compressed, resized according to the device, converted to a different format, and so on) removing the need to do it manually, and the WYSIWYG (What You See Is What You Get) capabilities are decent enough to provide a real-time preview of how the content will look like in the website.

By giving them access to powerful functionality, website users will have a higher satisfaction when browsing our sites, as experienced when using highly-dynamic, user-friendly web applications such as Facebook or Twitter.

In addition, Gutenberg is slowly but surely modernizing the whole process of creating the website. While currently it can be used only as the content editor, some time in the future it will become a full-fledged site builder, allowing to place components (called blocks) anywhere on a page, including the header, footer, sidebar, etc. (Automattic, the company behind, has already started work on a plugin adding full site editing capabilities for its commercial site, from which it could be adapted for the open-source WordPress software.) Through the site-building feature, non-techy users will be able to add very powerful functionality to their sites very easily, so WordPress will keep welcoming the greater community of people working on the web (and not just developers).

Fast Pace Of Development

One of the reasons why Gutenberg has seen such a fast pace of development is because it is hosted on GitHub, which simplifies the management of code, issues and communication as compared to Trac (which handles WordPress core), and which makes it easy for first-time contributors to become involved since they may already have experience working with Git.

Being decoupled from WordPress core, Gutenberg can benefit from rapid iteration. Even though a new version of WordPress is released every 3 months or so, Gutenberg is also available as a standalone plugin, which sees a new release every two weeks (while the latest release of WordPress contains Gutenberg version 5.5, the latest plugin version is 6.2). Having access to powerful new functionality for our sites every two weeks is very impressive indeed, and it enables to unlock further functionality from the broader ecosystem (for instance, the AMP plugin requires Gutenberg 5.8+ for several features).

Headless WordPress To Power Multiple Stacks

One of the side effects of Gutenberg is that WordPress has increasingly become “headless”, further decoupling the rendering of the application from the management of the content. This is because Gutenberg is a front-end client that interacts with the WordPress back-end through APIs (the WP REST API), and the development of Gutenberg has demanded a consistent expansion of the available APIs. These APIs are not restricted to Gutenberg; they can be used together with any client-side framework, to render the site using any stack.

An example of a stack we can leverage for our WordPress application is the JAMstack, which champions an architecture based on static sites augmented through 3rd party services (APIs) to become dynamic (indeed, Smashing Magazine is a JAMstack site!). This way, we can host our content in WordPress (leveraging it as a Content Management System, which is what it is truly good at), build an application that accesses the content through APIs, generate a static site, and deploy it on a Content Delivery Network, providing for lower costs and greater access speed.

New Functionality

Let’s play with Gutenberg (the plugin, not the one included in WordPress core, which is available here) and see what functionality has been added in the last few months.

Block Manager

Through the block manager, we can decide what blocks will be available on the content editor; all others will be disabled. Removing access to unwanted blocks can be useful in several situations, such as:

  • Many plugins are bundles of blocks; when installing such a plugin, all their blocks will be added to the content editor, even if we need only one
  • As many as 40 embed providers are implemented in WordPress core, yet we may need just a few of them for the application, such as Vimeo and Youtube
  • Having a large amount of blocks available can overwhelm us, impairing our workflow by adding extra layers that the user needs to navigate, leading to suboptimal use of the time; hence, temporarily disabling unneeded blocks can help us be more effective
  • Similarly, having only the blocks we need avoids potential errors caused by using the wrong blocks; in particular, establishing which blocks are needed can be done in a top-down manner, with the website admin analyzing all available blocks and deciding which ones to use, and imposing the decision on the content managers, who are then relieved from this task and can concentrate on their own duties.

Block manager

Enabling/disabling blocks through the manager (Large preview)

Cover Block With Nesting Elements

The cover block (which allows us to add a title over a background image, generally useful for creating hero headers) now defines its inner elements (i.e. the heading and buttons, which can be added for creating a call to action) as nested elements, allowing us to modify its properties in a uniform way across blocks (for instance, we can make the heading bold and add a link to it, place one or more buttons and change their background color, and others).

Cover block

The cover block accepts nested elements (Large preview)

Block Grouping And Nesting

Please beware: These features are still buggy! However, plenty of time and energy is being devoted to them, so we can expect them to work smoothly soon.

Block grouping allows to group several blocks together, so when moving them up or down on the page, all of them move together. Block nesting means placing a block inside of a block, and there is no limit to the nesting depth, so we can have blocks inside of blocks inside of blocks inside of… (you’ve got me by now). Block nesting is especially useful for adding columns on the layout, through a column block, and then each column can contain inside any kind of block, such as images, text, videos, etc.

Block grouping and nesting

Blocks can be grouped together, and nested inside each other (Large preview)

Migration Of Pre-Existing Widgets

Whereas in the past there were several methods for adding content on the page (TinyMCE content, shortcodes, widgets, menus, etc.), the blocks attempt to unify all of them into a single method. Currently, newly-considered legacy code, such as widgets, is being migrated to the block format.

Recently, the “Latest Posts” widget has been re-implemented as a block, supporting real-time preview of how the layout looks when configuring it (changing the number of words to display, showing an excerpt or the full post, displaying the date or not, etc).

Latest posts widget

The “Latest posts” widget includes several options to customize its appearance (Large preview)

Motion Animation

Moving blocks up or down the page used to involve an abrupt transition, sometimes making it difficult to understand how blocks were re-ordered. Since Gutenberg 6.1, a new feature of motion animation solves this problem by adding a realistic movement to block changes, such as when creating, removing or reordering a block, giving a greatly improved visual cue of the actions taken to re-order blocks. In addition, the overall concept of motion animation can be applied throughout Gutenberg to express change and thus improve the user experience and provide better accessibility support.

Motion animation
Blocks have a smooth effect when being re-ordered. (Large preview)

Functionality (Hopefully) Coming Soon

According to WordPress founder Matt Mullenweg, only 10% of Gutenberg’s complete roadmap has been implemented by now, so there is plenty of exciting new stuff in store for us. Work on the new features listed below has either already started, or the team is currently experimenting with them.

  • Block directory
    A new top-level item in wp-admin which will provide block discovery. This way, blocks can be independently installed, without having to ship them through a plugin.
  • Navigation blocks
    Currently, navigation menus must be created through their own interface. However, soon we will be able to create these through blocks and place them anywhere on the page.
  • Inline installation of blocks
    Being able to discover blocks, the next logical step is to be able to install a new block on-the-fly, where is needed the most: On the post editor. We will be able to install a block while writing a post, use the new block to generate its HTML, save its output on the post, and remove the block, all without ever browsing to a different admin page.
  • Snap to grid when resizing images
    When we place several images on our post, resizing them to the same width or height can prove to be a painful process of trying and failing repeatedly until getting it right, which is far from ideal. Soon, it will be possible to snap the image to a virtual grid layer which appears on the background as the image is being resized.

WordPress Is Becoming Attractive (Once Again)

Several reasons support the idea that WordPress will soon become an attractive platform to code for, as it used to be once upon a time. Let’s see a couple of them.

PHP Modernization

WordPress’s quest to modernize does not end with incorporating modern JavaScript libraries and tooling (React, webpack, Babel): It also extends to the server-side language: PHP. WordPress’s minimum version of PHP was recently bumped up to 5.6, and should be bumped to version 7.0 as early as December 2019. PHP 7 offers remarkable advantages over PHP 5, most notably it more than doubles its speed, and later versions of PHP (7.1, 7.2 and 7.3) have each become even faster.

Even though there seems to be no official plans to further upgrade from PHP 7.0 to its later versions, once the momentum is there it is easier to keep it going. And PHP is itself being improved relentlessly too. The upcoming PHP 7.4, to be released in November 2019, will include plenty of new improvements, including arrow functions and the spread operator inside of arrays (as used for modern JavaScript), and a mechanism to preload libraries and frameworks into the OPCache to further boost performance, among several other exciting features.

Reusability Of Code Across Platforms

A great side effect of Gutenberg being decoupled from WordPress is that it can be integrated with other frameworks too. And that is exactly what has happened! Gutenberg is now available for Drupal, and Laraberg (for Laravel) will soon be officially released (currently testing the release candidate). The beauty of this phenomenon is that, through Gutenberg, all these different frameworks can now share/reuse code!


There has never been a better time to be a web developer. The pace of development for all concerned languages and technologies (JavaScript, CSS, image optimization, variable fonts, cloud services, etc) is staggering. Until recently, WordPress was looking at this development trend from the outside, and developers may have felt that they were missing the modernization train. But now, through Gutenberg, WordPress is riding the train too, and keeping up with its history of steering the web in a positive direction.

Gutenberg may not be fully functional yet, since it has plenty of issues to resolve, and it may still be some time until it truly delivers on its promises. However, so far it is looking good, and it looks better and better with each new release: Gutenberg is steadily bringing new possibilities to WordPress. As such, this is a great time to reconsider giving Gutenberg a try (that is, if you haven’t done so yet). Anyone somehow dealing with WordPress (website admins, developers, content managers, website users) can benefit from this new normal. I’d say this is something to be excited about, wouldn’t you?

Smashing Editorial
(dm, il)

Source: Smashing Magazine, The (Upcoming) WordPress Renaissance

Smashing TV Interviews: The Mozilla View Source Line-Up

dreamt up by webguru in Uncategorized | Comments Off on Smashing TV Interviews: The Mozilla View Source Line-Up

Smashing TV Interviews: The Mozilla View Source Line-Up

Smashing TV Interviews: The Mozilla View Source Line-Up

Rachel Andrew

Smashing TV has been working with our friends over at Mozilla to bring you content from their upcoming View Source conference in Amsterdam. We’re really excited about the event that they are putting together.

Here on Smashing Magazine, we often feature articles that explain a little bit about how web technologies are created. I’m a CSS Working Group member, and I enjoy sharing the things that we’ve been discussing in our meetings, such as my post on “Designing An Aspect Ratio Unit For CSS”. Earlier this year, we published an article by Amy Dickens, “Web Standards: The What, The Why, And The How” in which Amy explained what we mean by web standards and how standards groups work. We’ve also shared with you how browser vendors such as Mozilla are making web platform features easier for us to use in our work, such as this post by Chen Hui Jing, “Debugging CSS Grid Layouts With Firefox Grid Inspector”.

If you enjoy articles like these, then you will love View Source, and the chance to spend two days with people who are involved with specifying the web, and implementing it in our browsers. It’s a very special View Source because friends from Google, Microsoft, Samsung, and the W3C are joining Mozilla to bring the best of the web to developers and designers this year. I’ll be there too, wearing my CSS Working Group hat, as part of a discussion corner on how CSS gets into browsers.

Our own Vitaly Friedman has been interviewing some of the speakers from the upcoming event, and you can watch the first of those interviews now.

Enjoy this conversation with Kenji Baheux, a Product Manager at Google, working on Chrome/Web Platform, about the web in different parts of the world, differences between usage of the web, and what we need to be aware of when expanding to an unfamiliar market in India or Southeast Asia.

Mozilla’s View Source Amsterdam event is happening on Monday and Tuesday, Sept 30th and October 1st at Theater Amsterdam. Get your tickets here. You can save 25% with the code Smashing_VS, or use a direct link to check out. I look forward to meeting you there!

An Interview With Kenji Baheux

Vitaly: Hello and welcome to one of those interviews on view source speakers, live sessions with a few behind-the-scenes about the speakers and the sessions and the talks and the interesting topics. And I’m very happy and honored to have Kenji Baheux with us today, from Google, currently living in Tokyo, Japan. How’re you doing today, Kenji?

Kenji Baheux: I’m doing pretty good, thank you.

Vitaly: Fantastic. I have questions. You know, I always do, I have too many questions I believe, but I’m really curious because you know, I know that you’ve spent quite a bit of time and you know, the session you’re going to present today, you’re going to present that in view source which is all about multicultural web thing, right? It’s like the web beyond the scope of what we’re used to, and very often when we think about designing a building for the web, we’re thinking about designing and building for our web. You know, for wonderful screens and wonderful devices and wonderful connections and powerful devices, and all of that. But when we think about designing for Indonesia, when you think about designing for Southeast Asia or India or kind of all places where we’re are not familiar with, we have stereotypes, right? We tend to believe slow devices, unreliable connections, bad screens, you know, horrible, horrible conditions. Almost the opposite of what we’re used to, is it the true web outside of the comfortable bubble that we live in? Tell us.

Kenji Baheux: So, unfortunately, there is some truth to that, and the interesting thing is that the market in India and Indonesia they have like a common aspect, but there are differences — especially around connectivity, for instance. It used to be the case that connectivity in India was very expensive, and so people like wanted to save like data and so they, you know, they didn’t want to use the web too much. For instance, today, it has become a lot more affordable and so people are not concerned too much about data consumption. It is still true that maybe in the newer kind of like user segment, it might still be quite expensive, but it’s getting better quite fast. So I think like in term of like data usage, it’s not so much a concern anymore, but at the same time like 4G is available over there, but if you look at the speed and the like readability of the collection, it’s more kind of like a 3G connection than a 4G connection.

Kenji Baheux: And so you need to be careful about like your assumption about, “Oh, 4G is affordable and therefore the connectivity is going to be the same than what I experience in my own country.” Like there are some stats but like, for instance, I think India is actually at the bottom in terms of speed for 4G and it’s about a 10x slower than what it should be compared to like the top one, for instance. So there is some nuance there and also because there are a lot of users in India depending on the time of the day, the speed will like fluctuate and also sometimes like depending on the bandwidth the [inaudible] will keep up.

Kenji Baheux: And so you might lose connection. You might be on the go. There are a lot of dot points, like not enough antennas and things like that. So you need to be careful about speed and also like this idea that not always on connectivity is not always what user experience is over there. And if you contrast that with Indonesia, Indonesia is doing a bit better in terms of speed, like 4G over there is more kind of like 4G, and there are some reasons to that. The country is much smaller, urbanization is much higher, and so it does help, right? The user, they can reach out in Indonesia tend to have better infrastructure. So that’s one aspect. You mentioned also the devices, so on that, like it’s still very true that the devices tend to be on the lower end of the spectrum. And so like iPhone for instance, are a very tiny market share mostly because those devices are too expensive. And so most of the people can’t afford like high-premium devices.

Kenji Baheux: It used to be the case also that the memory that devices have was very low and this has become better, but it doesn’t mean that the device is cracked, right. I think the OEMs understood what the user cares about. Like does it have a great camera, does it have enough RAM, what about the storage? But then they want to keep the price low and so they are going to find ways to make the device cheap, right? And so it means like slow CPU, slow storage, and things like that. So you need to be careful about the connectivity, but also how much JavaScript you send because it’s going to make your page go slow, right?

Vitaly: It’s, you know, you spend quite a bit of time thinking about performance and also now because you’re working at the Chrome team and you kind of want to work on the instant loading team — if I’m correct, right? It means for me, personally, it means that you have very different challenges at times as well because probably now living in Japan or living in Indonesia kind of have to really look into the types of devices people are using, the habits that they have, the cultural ways of how the web is different. You know, if you look into Africa, for example, I’m sure as you probably know, of course, many people that Africa will be using kind of totally bypassing credit cards altogether, sending money by SMS and having a different kind of web applications, right? So that makes me think as well, when it comes to performance, obviously we want to make things fast and all that, would you say that progressive web apps as a model has become or is becoming more and more established just because it’s kind of an easier way in to get to better performance in India, in Southeast Asian, and so on?

Kenji Baheux: Yeah, we’ve seen a trend of success with PWA in those markets, for the reasons that I’ve outlined, right? If you build a PWA right, it’s going to minimize the amount of data that you fetch, right? You can use the storage and API to make sure that you don’t over-fetch. You can also deliver a very fast-like experience by showing at least a bit of like a piece of UX and then fetching the new content, right? You can minimize the amount of content you need to fetch in order to show the letters like data. So it’s, I think it’s a great fit. It does help a lot of like partners over there.

Vitaly: Many companies that they kind of work with and some of my colleagues are working with, they have a very difficult time moving kind of exploring new markets, moving their architecture, their application, the the way they built up their app or the website really on these markets kind of trying to gather that market share. And it’s very often not very clear why is that? Is it just because the architecture that we’re used to with this mountain of JavaScript that we are pushing with, you know, the Western World that say it’s just totally unacceptable for Southeast Asia? And again, I don’t know, China’s a difficult story anyway, and India. So in many ways, many of these companies see as one of the paths to get to those markets is just built something entirely different. So when you see, if you see, let’s say somebody who had maybe watching this session later trying to get through those markets, would you recommend to adapt the existing architecture, try to kind of make it work for those markets, or would you say it’s better to start from scratch and use something like an assistant ecosystem that’s already there?

Kenji Baheux: Yeah, I think it’s usually better to start from scratch because you might be tempted to try to keep around different features because maybe you’ve seen them doing well in your market and so you, you think those will be like super important to have. And so it’s going to be hard to make some trade off. And so it might be better to start from scratch and like really find, okay, what are the keys— what is the goal of this product? What are we trying to achieve? And keep it to the essential and start from there and see if you really like your product too, it’s bare minimum, like how fast can it float on the connectivity that you can find in markets like that? Like, try to get a low-end device, it’s not too hard to get something that could feel relevant for the market that you are trying to target and just play with it.

Kenji Baheux: I think trying to create a product on your desktop computer or even looking at it like on an iPhone or like a high-end Android device is not going to give you a good idea of like what your experience is going to be. And so you need to really like put yourself in the the shoes of your customers and really like confirm for yourself that what you have is going to work. So yeah, start from something very simple like the bare minimum that your product is about, and see how far you can take it from there.

Vitaly:It’s interesting to also be talking about people, but also… most of the time when we have these conversations about performance, we think about devices. You know, when you start thinking about internationalization and localization and all those things that are actually just going to those markets, I start wondering about the habits of people. Maybe they use the web very differently. So this is exactly what you’re saying, right? We need to do some research to understand how people are used to certain things. What would work? Maybe a feature you spent two years on here in Germany somewhere is just not going to work at all in India, right? So because, I mean, I just have to ask you because I’m so curious, it’s maybe not on the technical side, but I’m just curious. So if you compare the web, how people use the web, but say in the Western World, and again, let’s say in Japan where you spent the last 20 years, I believe, how is it different? I mean, I’m sure that there are certain things that are just, just totally confusing for somebody who experiences, let’s say, the way people are using the web in Japan coming from very different culture, did you have any kind of cultural shocks or anything of that kind or do you see things differently?

Kenji Baheux: That’s an interesting one. I think one of the most surprising thing for me when I arrived in Japan, like 20 years ago, was the fact that the website were like very visual, to the point of like being very noisy. Like from a European viewpoint, it’s kind of like, oh, this is way too much in your face. Like, there was so much going on on that page, how can you even understand how to use it? But actually this is what like most users are actually here, like when it comes to user experience, they want to know more upfront about the product, and so you end up with this like long page detailing all the things about why this project is like the most amazing thing in the world. And then at the bottom of it, there is like finally a way to purchase that product, so that’s one typical user experience that I’ve seen a couple of times already.

Kenji Baheux: So yeah, so that’s very visual: Trying to put as much information upfront about what the product is about. So that’s for Japan. And then for countries like Indonesia and India, especially in India, there are a lot of difficulties around language. As you probably know, India has a lot of official languages and so you really need to understand which users you are trying to reach. Because if you don’t have the content in their language, it’s going to be very hard for them to understand how to use the website, and so on. For most, it’s the first time that they are getting online and there are still a lot like new users getting online every day, and so they don’t have any like notion of like what a tab is like background tab, all of these things that we take for granted, like a lot of users actually that’s the first time that they are online, and so it’s very hard for them to just know about the things we take for granted. And so be very careful about making sure that your product is like self-explaining, and that there is nothing that people need to know in advance, for instance.

Vitaly: I’m also wondering, very often when we’re building products or when we’re designing products, we tend to think that we are building this technology that’s almost neutral, but in the end, whenever we’re building something, we always reflect our identity somehow in the little snippets of JavaScript and CSS we’re writing, and so I think that, in many ways, as designers and developers, we also have certain stereotypes when it comes to designing for those markets or kind of adapting for those markets. So what do you see, I mean, I mentioned one of them in the very beginning, like everything is slow, everything is horrible, totally unreliable and all of that — what do you see maybe as other common misconceptions or myths surrounding global web from people who are designing and building in a Western World Web?

Kenji Baheux: Yeah, that’s an interesting one. I think one particular aspect is the local players tend to be much more successful for various reasons, but one of them is that, especially in Indonesia, they know that the population is very young in general, and so they opt for a more casual tone which is something that I guess most websites in the US and EU don’t tend to do a lot. And so if you’re in e-commerce, you might be tempted to be very serious because you want to present yourself as the company that people can trust, but it might actually be the [inaudible] to your brand image if you go to a market like Indonesia where people want to have a more fun experience maybe.

Vitaly: Right, and also if you look forward into how things are evolving or how they’ve changed, I mean, you’ve seen tremendous change on the web over the last 20 years, I’m sure, but I’m wondering also when we look forward, let’s say five years from now, and look into connectivity, it seems like there is this gap that we used to have. It’s kind of bridging, we have pretty much stable connectivity that’s coming, at least worldwide, it’s still a long way to go, but it’s, you know, it’s coming. How do you see the web — the World Wide Web as we intended it to be from the very first place — evolving? Will we breach all these gaps between the Western world and non-Western world, at least in terms of the web? Or are there going to be significant cultural differences still?

Kenji Baheux: Obviously, eventually, things will get in a similar place in terms of conductivity and, like, maybe even like devices. But I think it’s going to take a while because as I said, there is still a lot of like new users getting online for the first time, and for them it’s like the price of data and devices are getting in the affordable realm, and you see, especially in markets like India for instance, there is still a lot of like feature phone and it’s not the like the old-side feature phone. It’s kind of like a more fully-fledged feature phone. I believe that KaiOS is getting a lot of attraction — people should be aware of that brand. Go check it online, google for KaiOS devices, and you will see that it’s actually bringing the modern web into a feature phone from factor.

Kenji Baheux: And so the idea is that the lowest end of the smartphone is still too expensive for a lot of users, and so by bringing something that people can use and get connected to on a feature phone from factor, like carriers can lower the price points where a lot more users can get online. So I think this is still going to be the case for a long time, and so having to be mindful about low-end devices and slow connectivity because as more people get online, the infrastructure should keep up but it’s going to be very hard. All of these programs are still going to be a thing for a long time, I think.

Vitaly: When I was in Indonesia, by the way, I was surprised about one thing because it’s the first time when I experienced it, and it was the fact that I would go online and we’d get a SIM card and then there would be a Facebook Internet and everything else. Essentially, whenever I go through the gates of Facebook and I try to, you know, going to click on the links and all that, it’s free. But then as long as I want to type in anything else in my URL bar, I have to pay. So this is where I actually got to be hit almost by the role that net neutrality has and how it’s actually not respected really in those countries where you have to pay more for access in certain parts of the web. In terms of net neutrality, how do you see things there? Because I’ve only been to Indonesia where it happened to me. Is that a common thing that we have a Facebook Internet in many places around the world?

Kenji Baheux: So I believe this is part of something that was called Facebook Basics. I don’t know if it’s still the same name, but I’ve seen different countries where you can get online for free but you only have access to a few websites. And I’m just guessing that it’s a deal between those websites and the carrier. The stats that we have indicate that it only gets, like, a lot of people would just move away from that very soon, like quickly because as they get to hear from their friends and family about all the different things that they are able to do, they quickly realize that what they have is like very limited. And so as the purchasing power like grows, they do like pay a few additional like quota, not maybe for the full month, and eventually at some point they will be able to do so, but there is an appetite for getting beyond this like few websites sites that are available for free.

Vitaly: Yeah. And then maybe the final one, Kenji, and I will let you go, and free… So, if you look forward, let’s say in a few years from now, and maybe if you look back into that interview when I asked that question, what would you like to see changed in the next two years? Is there anything on the web that you desperately want to fix or something that kind of bothers you for quite a bit of time where you are spending all your time and efforts and you know, you’re in the nighttime when you can’t sleep, and just to solve that thing… If you had to, if you could solve just one thing for good on the web, what would it be?

Kenji Baheux: That’s a tough one. I feel that the web in general is still, like, we say that web is like very low friction and it is in a sense because everything is just like one link away. And so, and also there’s like no new install phase, it’s very safe and secure, right? But at the same time, on mobile, a lot of time it’s very frustrating because you have to wait and the pages load very slowly, the UX is not always great… So I hope that the work we do will eventually get us in a place where the web feels like instant, seamless, and delightful. And I’m wondering if there is something that is missing, which is some of the, like the native apps are on, you know, like do provide a better user experience cause I feel they have the incentive to do so to like things like ratings and reviews, right? There is a way to know where you are falling off the path, like what is wrong about my app? How can I fix it? And also you have the incentive to do it because there is like rankings and people can see what other people think about your app, and so I’m wondering if there is something on the web that is missing there where we could get more signals from users and help the web get better based on that, and so I would like to, to get some feedback on that and what people think about this idea.

Vitaly: Oh, that sounds exciting. So I guess that maybe that’s something you’ll bring up in your session on October 1st at View Source in Amsterdam, and I can’t wait to hear more insights about the web in different parts of the world because the web is much bigger than just us sitting here in fancy offices in front of wonderful displays. Alright, Kenji, thank you so much for being with us today, and thanks to everyone for watching as well. I’m looking forward to the next one and I’m looking forward to seeing you in Amsterdam.

Vitaly: Thank you, Kenji. Bye!

Kenji Baheux: Thank you, bye!

Watch the Smashing YouTube and Smashing Vimeo channels for more interviews with the View Source speakers.

Smashing Editorial
(vf, mc, il)

Source: Smashing Magazine, Smashing TV Interviews: The Mozilla View Source Line-Up

Movie Poster Designs To Inspire Your PWA Hero Images

dreamt up by webguru in Uncategorized | Comments Off on Movie Poster Designs To Inspire Your PWA Hero Images

Movie Poster Designs To Inspire Your PWA Hero Images

Movie Poster Designs To Inspire Your PWA Hero Images

Suzanne Scacca

I visited the Fandango website last weekend, hoping to find something that would give me an excuse to spend a couple of hours inside an air-conditioned movie theater. This is what first caught my eye when I got there:

The Fandango home page shows a slider with popular movies and their posters

The Fandango home page shows a slider with popular movies and their posters. (Image credit: Fandango) (Large preview)

To be honest, most of these movie posters did absolutely nothing to motivate me to leave the house. Except for The Lion King, which has such a striking color palette, and Once Upon a Time in Hollywood, which does some cool stuff with typography.

Has anyone else ever experienced this before? You’re in the mood to watch a movie and either:

  • Catch a glimpse of the movie poster you were interested in, only to question whether or not it’s even worth watching?
  • Catch a glimpse of a movie poster you hadn’t given much thought to, but then changed your plan and saw that one instead?

And we’re not even talking about movie trailers here. We’re talking about what a single poster designed to promote a movie and entice people to watch it can do to your perception of it.

If you think about it, the hero image on a PWA has just as much sway over a first-time visitor.

You have only a few seconds to make an impression with your hero image. How do you want yours to make visitors feel?

Do your visitors proceed through the PWA with excitement over what they’re about to find? Or do they do so with apprehension due to disappointment or confusion caused by the first image?

Let’s look at some examples of good and bad movie posters and see what sort of lessons we can use to help you with your PWA hero design:

1. Avoid Stock Photos When You Can

In other parts of a PWA, high-quality stock photos purchased from sites like Getty or iStock may suffice. But your hero image?

I’d say you should be very careful with this, especially if using a stock photo that’s easily recognizable. Even if it’s an attractive photo and aligns perfectly well with the brand’s story, do you really think someone else’s imagery belongs at the top of the PWA?

When Aquaman came out in 2018, they released a series of movie posters to promote it. However, it was this particular poster that caused a huge uproar online:

The Aquaman movie poster includes stock photos of sharks

The Aquaman movie poster includes stock photos of sharks. (Image credit: “Aquaman” on IMDB) (Large preview)

Essentially, the complaints on Twitter boiled down to the usage of this stock photo from Getty:

Twitter users were in an uproar over the Aquaman movie poster

Twitter users were in an uproar over the Aquaman movie poster. (Image credit: Twitter) (Large preview)

Now, you can expect there to be arguments whenever any major criticism is made of a superhero movie. With camps clearly divided between Marvel and DC movies, it’s kind of hard not to want to defend your superheroes tooth and nail when someone insults them. Even if it’s because of a stock photo of a shark.

The people against the criticism have a point though. It’s not like the real stars of the movie could be submerged in a body of water with live sharks. Aside from stock photography or CGI, what choice did the poster designers really have?

That said, I think what the real issue is, is that this is a huge movie with a huge studio budget, and the inclusion of a stock photo makes you wonder if they cut corners anywhere else in the film.

The usage of recognizable stock photos in a hero image may send the same sort of signal to visitors if they’re expecting an end-to-end premium experience from the brand behind it.

2. Make It Unique

If you watch as many movies as I do, you’re bound to notice certain trends when it comes to movie posters. This is especially so in the rom-com genre where it almost feels like designers don’t bother to be original or creative.

While this lookalike quality of movie posters can help fans of certain genres instantly identify the kinds of movies they want to watch, it sends another signal to them as well.

If you don’t know who Nicholas Sparks is, he’s the author of over twenty books, most of which have similar plots.

I’m going to let this Vanity Fair movie poster compilation demonstrate my point:

A Vanity Fair article shows off various covers from Nicholas Sparks movies

A Vanity Fair article shows off various covers from Nicholas Sparks movies. (Image credit: Vanity Fair) (Large preview)

If you were to talk to someone about one of these movies, it could be summed up as:

“You know the movie… The one with the boy and the girl who don’t really like each other at first, but then they fall madly in love and can’t stand to be apart? Oh yeah and there’s that person who dies in the end.”

That describes about 80% of these stories, which is why it’s not all that surprising that the movie posters for each look so darn similar.

Like I said, a similarly designed poster could work in their favor if they were trying to appeal to a very specific subset of moviegoers. But it doesn’t work that way with PWAs.

Unless you’re building a PWA to directly complement another brand, there’s no reason to design your hero image to look similar to anyone else’s. It’ll only cause confusion when visitors pick up on the similarities. Or they’ll wonder why they’re bothering to look at the PWA, assuming that it’s not just the images that look the same, but the services and products within, too.

If you want your PWA to stand out from the crowd, your hero image should be unique.

3. Zero In On One Thing

One of the problems with making a movie with an all-star cast is that’s it’s impossible to focus on just one person — not just within the plot, but in the movie poster as well.

Case in point: What to Expect When You’re Expecting:

The all-star cast from What to Expect When You’re Expecting

The all-star cast from What to Expect When You’re Expecting. (Image credit: “What To Expect When You’re Expecting” on IMDB) (Large preview)

If I were just stumbling upon this poster for the first time, I wouldn’t know where to start with it.

The title being in the middle helps, but the competing photos are overwhelming. Plus, if you look closely at the top photo, you’ll see that each of the women was individually layered into the picture. Why use a poorly compiled photo beside an actual shot from the movie? It creates a very disjointed experience.

To show you what a difference a singular focus can make, let’s look at the movie poster for E.T. the Extra-Terrestrial:

The poster for E.T. highlights the relationship between the boy and the alien

The poster for E.T. highlights the relationship between the boy and the alien. (Image credit: “E.T. the Extra-Terrestrial” on IMDB) (Large preview)

It’s not as though this film is without a great cast of stars. It’s just that the team who designed this recognized that there’s one real focus at the heart of the movie and it’s the relationship between Elliott (the boy) and E.T. (the alien).

I’d urge you to look for something similar when designing your hero image — even if your clients come to you and say that all of their services are equally important and they want the PWA to demonstrate that they can do all things for everyone. If you try to translate that sort of message into an image, it’s going to fail. So, find your focus.

4. Give The City A Subtle Nod

Movies can take place in any number of settings. Depending on what kind of movie it is, you may even find that the setting almost becomes a character within the story. Let me explain.

Richard Linklater filmed a trilogy of movies with Julie Delpy and Ethan Hawke.

The first movie is called Before Sunrise and takes place when Delpy and Hawke decide to get off a train and walk around the city of Vienna before parting the next morning:

The Before Sunrise movie poster features Vienna in the background

The Before Sunrise movie poster features Vienna in the background. (Image credit: “Before Sunrise” on IMDB) (Large preview)

The second movie is called Before Sunset and it takes place around the city of Paris:

The Before Sunset movie poster features Paris in the background

The Before Sunset movie poster features Paris in the background. (Image credit: “Before Sunset” on IMDB) (Large preview)

The final movie is called Before Midnight and it takes place in Greece:

The Before Midnight movie poster features a sunny Greek island in the background

The Before Midnight movie poster features a sunny Greek island in the background. (Image credit: “Before Midnight” on IMDB) (Large preview)

In each of these posters, you can see that the backdrop of the story plays heavily into the design. And that’s because there really is no story without their geographic surroundings.

They’re not just movies about two people talking to one another. It’s about two people getting to know one another as they explore a new city — a city which almost becomes like a third character that the viewer becomes acquainted with throughout the films.

If the company for whom you’re designing has a strong tie to a specific geographic region, see if you can find a way to incorporate it into the hero image somehow. It doesn’t have to be this explicit with the actual cityscape in the background. But there may be other ways to add a special touch that has local visitors thinking, “Hey, that’s where I’m from!” or “I’ve been there!”

5. Be Creative With White Space

You already know that white space is an important part of design, especially when you’re trying to convey a big message above-the-fold on a PWA. So as not to overwhelm visitors, you want to keep things simple. But that doesn’t mean you can’t be creative with how you fill that white space.

Take, for instance, the poster for Independence Day:

The Independence Day poster fills its white space with a spaceship

The Independence Day poster fills its white space with a spaceship. (Image credit: “Independence Day” on IMDB) (Large preview)

Although the space ship does convey a sense of dread, it’s also a really creative way to fill up all of the white space that would otherwise occupy the top of this photo.

Another fun example of playing with white space can be seen in the poster for Scarface:

The Scarface movie poster designers likely used symbolism to create this white space

The Scarface movie poster designers likely used symbolism to create this white space. (Image credit: “Scarface” on IMDB) (Large preview)

At first glance, you might just take this for the striking image that it is. However, knowing that Tony Montana is the head of a drug cartel and has an obscene penchant for snorting coke, the white that consumes him takes on another meaning here.

This one is a bit difficult to give you strict guidance on since this is all about being creative with the space that you have. What I would suggest if you want to go this route, though, is to think of ways to play with symbolism without having to explicitly present them within the photo. If you can play with shadows and light and space to do so, that would have a much greater impact.

6. Be Playful With Typography

For the most part, designers of movie posters tend to be very conservative when it comes to typography. They choose a single color for the font and it’s almost always a big blocky sans serif font.

But why not have a little fun with it? Just as you can imbue the image with creative flourishes, it wouldn’t be such a bad idea to do the same with text so long as the two complement one another.

You’ll find a beautiful example of this in the John Wick poster:

The John Wick movie poster typography has a unique edge

The John Wick movie poster typography has a unique edge. (Image credit: “John Wick” on IMDB) (Large preview)

If you were to quickly glance at the image, you might not pick up on the subtleties of the design. But they’re there.

For starters, the barrel of the gun takes the place of the letter “o”. But notice how the rim is tinged in the same color as the rest of the letters? This is what helps it blend so well at first glance.

Then, you have the unhinged look of the letters themselves, where they’re split and slanted through the middle.

For those of you who haven’t seen the film, this is essentially what’s happening to Keanu Reeves’s character. He was once an assassin, but gave it up for love. When his wife dies and the last remnants of her are taken from him, he’s torn. Does he continue the life of a normal man? Or does he give it all up and go on a murderous rampage?

I know that the smart thing to do when designing a hero image is to let the image tell the story, but I think subtle touches to the text can really take it up a notch.

Wrapping Up

So, what have we learned here? Well, there’s certainly a right and wrong way to go about designing a movie poster and PWA. But, more than that, the most important thing to do is to put some real thought into what you want those first few seconds to convey to your viewers.

If you fail to capture what the PWA is about or you do so in a manner that’s boring, unoriginal, vague or cheesy, you’re going to lose their interest almost immediately.


If you can perfectly capture what a brand is all about along with the subtle nuances that make it special, you’ll encourage more visitors to scroll and click with a single image.

Smashing Editorial
(ra, il)

Source: Smashing Magazine, Movie Poster Designs To Inspire Your PWA Hero Images

Collective #540

dreamt up by webguru in Uncategorized | Comments Off on Collective #540


Largest Contentful Paint

Philip Walton explains how to make it easier to know when a page’s important content has loaded using the Largest Contentful Paint (LCP) API.

Read it



A CSS Houdini library giving some cool features to your site (turn on Experimental Web Platform features or use Chrome Canary to see the effects). By Una Kravets.

Check it out



Ethan Marcotte discovers some accessibility issues with the AMP Story format.

Read it


The birth of Inter

Learn how the new open-source typeface used by GitHub and Mozilla came to be in this article by Carmel DeAmicis.

Read it


Uno Platform

In case you missed it: Uno let’s you build mobile, desktop and WebAssembly apps with C# and XAML.

Check it out

Collective #540 was written by Pedro Botelho and published on Codrops.

Source: Codrops, Collective #540