Prettier is an “opinionated code formatter.” I highly suggest using it. They have a document going deeper into the reasons, but their three marketing bullet points say it best:
You press save and code is formatted
No need to discuss style in code review
Saves you time and energy
But Prettier doesn’t do all languages. Notably HTML. It’s great at JSX, and I’ve gotten really used to enjoying that. But then when I switch to a Rails .erb template or a WordPress site where I’m editing a .php file, or even a plain ol’ .html file… no Prettier.
Overeating and standing in line in the rain aren’t necessarily good for your health. But they’ve become traditions when Black Friday rolls around. We can’t do much about you eating too much the day before, nor would we want to. But we can at least help you avoid long lines and keep you out of the rain.
As usual, this Black Friday brings with it a host of amazing deals for designers and developers. Check them out so you won’t risk having to wait a year before deals like this show up again.
We love having the opportunity to present freebies and deep discounts to you. This is especially when they involve top-of-the-line website-building themes, tools, and design aids. No doubt you’ll find one or more offers that will brighten your day. They will allow you to finish your 2018 design or development activities with a flourish.
First on the list is Elementor’s ultimate web design tool, a tool designed to keep you from being constrained by or becoming “stuck in” a theme. It’s a liberating experience to be able to design what you want, when you want, without having to rely on code and without being told there are certain things you just can’t do.
This website builder gives you crazy-fast performance, which will speed up your workflow and be reflected in your designs as well. You don’t have to resort to using header and footer templates, that while customizable to some extent, never give you quite what you’re really looking for. With Elementor, you can get your designs exactly right.
Elementor works with any template, it gives you live, frontend editing and advanced mobile editing. It works with any theme and is developer-friendly as well.
Don’t let Black Friday slip away without taking advantage of Elementor’s 25% discount on each of its plans.
The Visual Composer editor plugin is a standby in the website design world. This popular plugin is the editor of choice for many if not most of the best-selling website-building themes on the market, including the premium themes. Black Friday gives you an opportunity to step up to the next level with the purchase of Visual Composer’s Website Builder at a 50% discount on all licenses.
This website builder gives you the power of drag and drop and the ability to create a website without any need for coding skills. It comes complete with header, footer, content, and sidebar editors, advanced design options, and parallax effects.
To make your Black Friday purchase even sweeter, you’ll get unlimited access to the Visual Composer Hub. This cloud-based marketplace is chock-full of first-class design features, multipurpose templates, and ready-to-use content elements.
Incorporating a map has become practically mandatory for most types of business websites, and for many other types of websites as well, especially those that use maps as interactive tools. For those instances when something more than a Google map is needed to get your message across, we highly recommend the MAPSVG WordPress plugin as your tool of choice.
This is the last WordPress mapping plugin you’ll ever need, and it’s being offered at a 30% Black Friday discount,
With MAPSVG you can create your own custom interactive vector maps, image maps, and Google maps. MAPSVG includes all countries and all North American states and provinces. You can create custom maps from your PNG or JPEG files, add markers and directory listings, use regions of a map as links, and add custom artwork to give a map an extra touch.
Here’s a Black Friday offering designed to make your life easier. Visme could best be described as an ultimate visual communication and storytelling tool. Check out Blockbuster Visme deal – save 30% off of any Individual or Business Plan using the discount code THANKS19 when upgrading to Premium.
Even if you’re among the many who are somewhat challenged when it comes to presentation design skills, Visme will make it easy for you to prepare stunning interactive presentations, infographics, tables, charts, and summaries – in minutes.
This may be the Black Friday special of specials. A 91% savings should be hard to ignore if you’re in the market for a premier website builder kit. The Mobirise Complete Website Builder package includes more than 1500 website blocks in a variety of themes and extensions and a huge library of icons, Google fonts, and free images.
Mobirise is an offline builder, so you’re not tied to a particular platform or host and it’s lightning fast and 100% mobile friendly.
No list of Black Friday specials would be complete without a set of app prototyping tools that anyone can use, including small teams and freelancers. Get feedback on your design with a single click and keep track of all the feedback with a built-in to-do list. Sync your design with you Sketch and play offline prototypes on the Savah mobile app.
On this Black Friday, any Savah’s 3 paid plans can be yours at a 50% discount.
While awesomeness is an all-to-frequently used adjective, it nicely describes what MOVEDO is all about. This multi-purpose WordPress theme boasts an impressive set of new features designed to help you break away from the feeling of sameness that can be so difficult to shake off.
Ultra-dynamics parallax, moldable typography, and other futuristic styles and options make this top-rated theme a great Black Friday pick at a 50% discount.
Conclusion
How to make this a better than usual Black Friday? Try our selection of powerful multi-purpose website building tools. You have a prototyping toolkit and a killer of a mapping tool.
It’s a nice bonus to be able to peruse this list in the comfort of your home or local coffee shop. These offerings won’t be obsolete when the next Black Friday rolls around either.
I totally get the push (pun intended) to make that happen. There is an omnipresent sentiment that we want the web to win, as there should be in this industry. Losing on the web means losing to native apps on all the different platforms out there. Native apps aren’t evil or anything — they are merely competitive and exclusionary in a way the web isn’t. Making the web a viable platform for any type of “app” is a win for us and a win for humans.
One of the things native apps do well is push notifications which gives them a competitive advantage. Some developers choose native for stuff like that. But now that we actually have them on the web, there is pushback from the community and even from the browsers themselves. Firefox supports them, then rolled out a user setting to entirely block them.
We’re seeing articles like Moses Kim’s Don’t @ me:
Push notifications are a classic example of good UX intentions gone bad because we know no bounds.
Very few people are singing the praises of push notifications. And yet! Jeremy Keith wrote up a great experiment by Sebastiaan Andeweg. Rather than an obnoxious and intrusive push notification…
Here’s what Sebastiaan wanted to investigate: what if that last step weren’t so intrusive? Here’s the alternate flow he wanted to test:
A website prompts the user for permission to send push notifications.
The user grants permission.
A whole lot of complicated stuff happens behinds the scenes.
Next time the website publishes something relevant, it fires a push message containing the details of the new URL.
The user’s service worker receives the push message (even if the site isn’t open).
The service worker fetches the contents of the URL provided in the push message and caches the page. Silently.
It worked.
Imagine a PWA podcast app that works offline and silently receives and caches new podcasts. Sweet. Now we need a permissions model that allows for silent notifications.
Gutenberg is a JavaScript-based editor (more specifically, it is a React-based editor), which will soon transform the experience of creating content for WordPress and (on an upcoming stage when Gutenberg is transformed into a site builder) the experience of creating WordPress sites.
Gutenberg, the site builder, will demand a different way of thinking how to lay the foundations of a website. In what we can already call the “old” model, WordPress sites are created by giving structure through templates (header.php, index.php, sidebar.php, footer.php), and fetching the content on the page from a single blob of HTML code. In the new model, the page has (React) components placed all over the page, each of them controlling their own logic, loading their own data, and self-rendering.
To appreciate the upcoming change visually, WordPress is moving from this:
…to this:
I believe that switching from blobs of HTML code to components for building sites is nothing short of a paradigm shift. Gutenberg’s impact is much more than a switch from PHP to JavaScript: there are things that could be done in the past which will possibly not make sense anymore. Likewise, a new world of possibilities opens up, such as rich and powerful user interactions. Web developers will not go from creating their sites in one language to creating their sites in another language because the site will not be the same anymore; it will be a completely different site that will be built.
Gutenberg has not been fully embraced by the WordPress community yet, for many reasons. For one, the new architecture is based on a plethora of tools and technologies (React, NPM, Webpack, Redux, and so on) which is much more difficult to learn and master than the old PHP-based one. And while it may be worth learning a new stack that delivers new functionalities, not every mom&pop site needs these new, shiny features.
After all, it is no coincidence that 30% of all sites across the globe are WordPress sites: most of these are really simple sites such as blogs, not dynamic social networks like Facebook. For another, WordPress inclusivity means that anyone could build a simple website — even people without coding experience, such as designers, content marketers, and bloggers.
But the complexity of the new architecture will leave many people out (I don’t even want to think about debugging my site in minified JavaScript code). And for another, once Gutenberg goes live, Facebook-backed React will be added to as many as 30% of all websites in the world — overnight. Many folks are uncomfortable with giving so much power to any sort of JavaScript library, while many others are mistrustful of Facebook. To alleviate this concern, Gutenberg abstracts React to also enable coding in other frameworks or libraries; however, in practice, React will undoubtedly be the predominant JavaScript library.
And yet, the prospect of being offered a new world of possibilities is sweet indeed. In my case, I am excited. However, my excitement is not about the technology (React) or about the implementation (Gutenberg), but about the concept, which is to create sites using components as the building unit. In the future, the implementation may switch to another platform, such as Vue, but the concept will remain.
Foreseeing what new features we will be able to implement is not always easy. It takes time to adapt to a new paradigm, and we tend to use new tools the old way until it dawns upon us how to use the new tools to accomplish new objectives. Even PDF files (which are a representation of print, the predominant technology before the web was born) are still a common sight on the web, neglecting the advantages that the web has over print.
“Imitating paper on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway.” — Ted Nelson
In this article, I will analyze several implications of building sites through a component-based architecture (as the concept) and through Gutenberg (as the implementation), including what new functionalities it can deliver, how much better it can integrate with current website development trends, and what it means to the future of WordPress.
Extended Versatility And Availability Of Content
A very important side effect of treating all content as blocks is that it allows to target chunks of HTML individually and use them for different outputs. Whereas content inserted in the HTML blob is accessible only through the webpage, as chunks it can be accessed through an API, and its metadata is readily available. Take media elements — such as videos, audio or images. As a standalone block, the video can be played in an app, the audio can be played as a podcast, and the images can be attached to the email when sending a digest — all of this without having to parse the HTML code.
Likewise, content from blocks can be adapted for different mediums: from the tiniest screen to the biggest ones, touchscreen or desktop, commanded by voice or by touch, 2D/AR/VR, or who knows what the future might bring. For instance, an audio block allows the audio to be played on an Apple Watch, commanded by voice through the In-car system or an AWS Echo, or as a floating item in our virtual world when using a VR headset. Blocks can also make it easier to set-up a single source of truth for content to be published in different outputs, such as a responsive website, AMP, mobile app, email, or any other, as was done by NPR through their Create Once, Publish Everywhere (COPE) approach.
Blocks can improve the user experience too. If browsing the site through 3G, blocks can self-render in a slow-connection mode to display low-quality images and skip loading videos. Or it can enhance the layout, such as offering to show an image gallery with one click at any point of the webpage, and not just at the place where it was embedded in the article.
These experiences can be attained by separating content from form, which implies that the presentation and the meaning of the content are decoupled, and only the meaning is saved on the database, making presentation data secondary and saving it on another place. Semantic HTML is an expression of this concept: we should always use which implies meaning, instead of which is a form of presentation (to make the character be displayed in italics), because then this content will be available to other mediums, such as voice (Alexa can’t read in italics, but she can add emphasis to the sentence).
Obtaining a thorough separation of content from form is very difficult since presentation code will often be added inside the block, through HTML markup (adding class “pull-right” already implies presentation). However, architecting the site using blocks already helps attain some level of separation at the layout level. In addition, blocks created to do just one thing, and do it very well, can make use of proper semantic HTML, have a good separation of concerns in its own architecture concerning HTML, JS, and CSS (so that porting them to other platforms may require only a minimum effort,) and be accessible, at least at the component-level.
Note: A general rule of thumb: The more inclusive a component is, the more prepared it is for mediums yet to be invented.
Unfortunately, Gutenberg was not designed with this purpose in mind, so blocks contain plenty of HTML markup for presentation too. For instance, an image block from an external image has, as its meaning, only the URL for the image, the alt description, and the caption (and possibly also the width and height); after creating an image block, the following chunk of code was saved in the DB (class aligncenter is for presentation, and the markup
would be completely redundant if storing only meaning):
<!-- wp:image {"align":"center"} -->
<div class="wp-block-image">
<figure class="aligncenter">
<img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/>
<figcaption>If your theme supports it, you'll see the "wide" button on
the image toolbar. Give it a try.</figcaption>
</figure>
</div>
<!-- /wp:image -->
In addition, blocks are saved inside the post’s content (which is a big HTML blob) instead of each having an entry of its own in the database. Reusable blocks (also called global blocks) do have their own entry though, which makes me fear that developers may convert standard blocks to reusable blocks just for a quick hack to access them straight in the DB.
Similarly, I am worried that, if not properly designed, blocks can even cause havoc in our sites. For instance, unaware developers may ignore the rule of least power, using JavaScript not just for functionality but also for CSS and markup. In addition, Gutenberg’s server-side rendering (SSR) functionality is not isomorphic (i.e. it does not allow a single codebase to produce the output for both client and server-side code), hence dynamic blocks must implement the function to generate the HTML code also as PHP as to offer progressive enhancement (without which the site is unaccessible while being initially loaded).
In summary, blocks are a step in the right direction towards making WordPress content available on any format and for any medium, but they are not a definitive solution, so much work still needs to be done.
Performance
Performance matters. Faster sites lead to happier users, which leads to better conversion rates. The team at Etsy, for instance, shelves new features, as cool as they may be, if these make their site loading time go over a critical threshold (I recommend watching Allison McKnight’s talk on Building Performance for the Long Term and slides), while the team at Twitter re-architected their site several years ago to support server-side rendering in order to show content as soon as possible, and continually implements plenty of small changes that add up to deliver a fast user experience.
As it stands now, Gutenberg is far from optimal: whereas creating a post with the old editor (for which we need to install the Classic Editor) requires loading around 1.4 MB of JavaScript, Gutenberg loads around 3.5 MB of JavaScript, just for its basic experience (that is, without installing any additional block):
That means that, as it stands now, 3.5 MB is the baseline, and loading size will only increase from there as the site admin installs more blocks. As was seen in a recent article on Smashing Magazine, creating a testimonials block required 150KB of minified JavaScript. How many blocks will a standard site require? How many MB of JavaScript will the average site need to download?
The implications are several: for one, a heavy site is out of reach to the next billion users, who have access mainly on slow connections, and who buy data plans which represent a significant chunk of their wage. For them, every MB of data makes a difference: sending Whatsapp messages is affordable, downloading several MBs of scripts just to load one site is not.
It is true that the user of the website will not need to interact with Gutenberg, since Gutenberg is simply for building the site, not for using it: Gutenberg is a back-end editor, not a front-end editor (and it may never be — at least as part of WordPress core). However, content creators will be penalized, and they are already a sizable target. In addition (as I argued earlier), users may end up being penalized too through dynamic blocks, which may create their markup through client-side JavaScript instead of server-side PHP.
There is also the issue of bloat from duplicated functionality added by 3rd party plugins. In the old days, a WordPress site may have loaded several versions of jQuery, which was relatively easy to fix. Nowadays, there is a huge array of open source libraries to choose from for implementing a needed functionality (drag and drop, calendars, multi-select components, carousels, etc.,) so more likely than not a site with dozens of 3rd party blocks will have the same functionality implemented by different libraries, creating unnecessary bloat. In addition, there is a bit of bloat added to Gutenberg itself: because blocks are registered in the frontend, unregistering an already-registered block is done by loading an additional script. In my opinion, this is one of the biggest challenges for the Gutenberg contributors: to put in place a streamlined process that allows anyone (not just developers experienced with Webpack) to remove undesired libraries and package only the minimal set of resources needed for the application.
Finally, I mention again that Gutenberg supports server-side rendering, but because it may not be easy to maintain, developers may be tempted to not rely on it. In this case, there is the cost of additional roundtrips needed to get the data from the REST endpoints, just to render the layout, during which time the user will be waiting.
In my opinion, performance will be one of the major challenges for Gutenberg, the one that could make or break in terms of widespread adoption, and there is still plenty of work that should be done, mainly targeting the next stage when Gutenberg becomes a site builder.
Web Standards
As mentioned earlier, Gutenberg abstracts React to provide a framework-agnostic approach to building blocks which, if implemented properly, can avoid WordPress being locked to React. The WordPress community is cautious when merging any JavaScript framework into WordPress core, in great part because Backbone.js, not long after being added to WordPress core, saw a sharp decline in popularity, and other than powering the Media Manager not many features were accomplished with it. Even if React is the most popular JavaScript library right now, there is no reason to believe that this will always be the case (as jQuery’s unraveling can attest), and WordPress must be prepared for when that day finally arrives (which, given the fast pace of technology, may happen sooner than expected).
The best way to avoid being locked to any library is through web standards and, more specifically in this case, the implementation of blocks through web components. Web components are strongly encapsulated components which operate with the browser APIs, so they don’t require any JavaScript library to work with. However, they can be implemented through any client-side JavaScript framework.
“React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.”
As of today, prospects of this situation taking place are not looking very promising: I haven’t been able to find any tutorial for building blocks with web components. I believe the community should focus some effort towards this cause, encouraging developers to start building blocks using web components, and the sooner the better, since Gutenberg forces us to learn new technologies anyway, right now. It is an opportunity to establish a strong foundation with web standards, from the very beginning.
Interoperability Between Sites, Homogenization Of Sites
A block is a smaller entity than a theme or a plugin, so eventually blocks will be accessible on their own, and acquired through newly created block markets. Most likely there will initially be a Cambrian explosion of blocks as many players in the ecosystem rush to be the first to market their solutions, leading on the medium and long-term towards consolidation of the most successful ones.
Once the dust has settled, a few blocks will stand out and become the winners, obtaining most of the market on their specific categories. If/when that happens will be a cause of both concern and jubilation: concern about a new wave of homogenization of the web taking place (as it happened with Bootstrap), as sites using the same components may end up with the same look and feel, an jubilation about an increased interoperability between sites from relying on the same components and the same APIs, which can open the gates to new opportunities.
I am particularly excited about expanding interoperability between sites. It is an area that could, in the long term, undo kingdoms such as Facebook’s: instead of relying on a monopolistic gateway for sharing information, sites with different communities can easily share data among themselves, directly. This is not a new concept: the IndieWeb movement has long been working towards enabling anyone to own their own data on their own servers, by having websites talk to each other through microformats. For instance, their Webmention web standard allows two sites to have a conversation, in which each comment and response is stored in both of them, and Micro.blog offers a Twitter-of-sorts but based on the open web, in which the posts on the user’s timeline are gathered from RSS and JSON feeds from subscribed sites. These endeavors are wonderful, but still very small in impact, since there is some level of tech-savviness required to be part of them. Gutenberg’s component-based architecture can potentially produce a much broader impact: Popular blocks can enable scores of WordPress sites to talk to each other, eventually allowing up to 30% of all sites on the web to be part of a decentralized, loosely-coupled network.
This area will need plenty of work though, before being viable. I do not think the default REST endpoints are the best communication interface since they were not conceived for this purpose (the folks from micro.blog have proposed a better solution through their JSON interface, which is based on the RSS specification). In addition, REST is itself being made obsolete by GraphQL, so I wouldn’t place high hopes on it for the long term. I am also involved in finding a better way, for which I am currently working on a different type of API, which can retrieve all the required data in only one request, and supports extensibility through a component-based architecture.
I also expect integration with cloud services to be more prominent, since providers can release their own blocks to interact with their own services. Because a component is a standalone unit, just by drag-and-dropping the block into the page already does all the work from the user’s perspective, making it very easy to build powerful websites with little or no knowledge. For instance, an image storage provider like Cloudinary could release a block that automatically crops the image according to the viewport of the device, or requests the image as WebP if supported, or other use cases.
In summary, consolidation of the block market may bring homogenization of the way in how it looks and feels, which would be a regrettable event and should be avoided, and powerful capabilities concerning interoperability and data-sharing between sites and integration with cloud services.
Integration With Pattern Libraries
A pattern library is a collection of user interface design elements, each of them often composed by snippets of HTML, JS, and CSS. A block is an autonomous component, often made up of bits of HTML, JS, and CSS. So blocks are evidently well-suited to be documented/built with pattern libraries. Having blocks ship their pattern libraries would be a great deal since it could enable teams not to start implementing the site’s pattern library only at the site level, but as an aggregation and refinement of the mini-pattern libraries from all the required blocks.
I believe something similar to the streamlining process for producing bloatless JavaScript packages that I mentioned earlier happens in this case, but concerning UI/UX/Documentation. It would be both a challenge and an opportunity for Gutenberg contributors to put in place a process that makes it easy for block developers to create pattern libraries for their blocks which, when aggregated all together, can result in a coherent pattern library for the site. Well implemented, such feature could drive down the costs of building sites from a documentation/maintenance perspective.
What Will Become Of WordPress?
Gutenberg will certainly make websites more attractive, even though at the cost of a required level of expertise that not everyone will be able to handle. In the longer term, this may lead to higher quality, lower quantity. Coming from the WordPress maxim of “Democratizing Publishing,” this may become a problem.
I am enthusiastic about Gutenberg, but more as the concept of a component-based architecture, than the React-based implementation. In general terms, I do agree with what Matt Mullenweg said during WordCamp Europe 2018 to justify Gutenberg:
“The foundation of WordPress that is now served us well for fifteen years will not last for the next fifteen.”
However, I also believe that the WordPress of fifteen years into the future may end up being completely different than the one we know today. I wonder if WordPress will end up primarily being the client-based editor, and not much more: the initiative to integrate Gutenberg into Drupal, with the aim of making Gutenberg become the editor of the open web, will officialize WordPress as a headless CMS operating through REST endpoints. This is a good development by itself, but it will make WordPress the back-end dispensable: if any other back-end platform provides better features, there is no reason to stick to the WordPress back-end anymore. After all, client-side Gutenberg will be able to work with any of them, while the simplicity of creating a site with WordPress will be lost, leveling the playing field with all other platforms.
In particular, I would not be surprised if developers feel that maintaining two codebases (one in JavaScript and one in PHP) for rendering dynamic blocks is too taxing, and decide to shift towards platforms which support isomorphic server-side rendering. If this scenario actually happens, would Matt decide to shift the WordPress backend to Node.js?
It is mainly because of this issue that I dare to say that the WordPress from 15 years from now may be a very different entity than what it is nowadays. Who knows what will happen?
Conclusion
By making components the new unit for building sites, the introduction of Gutenberg will be transformational to WordPress. And as with any paradigm shift, there will be winners and losers. Different stakeholders will consider Gutenberg a positive or negative development depending on their own situation: while the quality of a website will go up, the price of building such a site from hiring developers who can handle its complexity will also go up, making it less affordable and less popular.
These are exciting times, but also pivotal times. From now on, WordPress may slowly start being a different entity from what we are used to, and we may eventually need to think about what WordPress is, and what it represents, all over again.
Researchers have known for some time that human behavior happens in patterns. Rather than seek out new ways to interact with technology, humans default to the familiar.
Evidence to support people’s love of patterns is abundant. The architect Alexander Christopher recognized, and wrote extensively about, design patterns as early as the 1960s.
More recently, Charles Duhigg examined how the majority of our day to day lives are the product of our habits — which corresponds nicely to Nir Eyal’s work on habit forming products.
Given the influence of patterns over human behavior, it’s no surprise that using established design patterns in your work can be beneficial.
But repetition can also be the enemy of innovation. How can you design something new for your audience if you only focus on what’s come before?
If you want to learn how you utilize design patterns and still create original ideas to meet the needs of your end-users, read on.
The Good and Bad of Design Patterns
By definition, design patterns are established solutions to recurring problems. So for nearly any user interface designer, established patterns can be tremendously useful.
For example, positioning the login call to action at the upper right hand corner of the navigation is a classic UI design pattern. People know to look in that area of an interface, because they’ve used the same behavior to log in or check their profile for years.
As I highlighted earlier, people enjoy the familiar. When an interface matches the user’s expectations, it reduces cognitive load, saves the user time, and makes the software more intuitive. That’s what gives these conventions lasting power.
What’s more, patterns have a number of advantages for your design process.
Utilizing a UI Pattern Saves You Time
Because you don’t have to design an interface from scratch, you’ll be able to move more quickly to testing and iterating your design.
You’ll Be Building on a Solution That Has Worked in the Past
Just like scientists standing on the shoulders of giants, you’ll be standing on the shoulders of, well, designers who solved similar challenges for their audience.
But it’s important to remember that patterns are only a starting place. They are models for your design, not fully-realized solutions to your users’ problems.
Over-Reliance on UI Design Patterns Can Easily Lead to an Under-Researched Design
That is to say, instead of uncovering a solution that’s optimal for your users, you could settle for what’s ready-made in a design pattern.
A lack of innovation, i.e., not tailoring the experience to solve the unique challenges of your users, will just leave your website or product feeling like a collection of templates.
Choose the Right Pattern
Before you start customizing patterns, make sure you select the right pattern for the job.
Yes, design patterns are usually reliable solutions to recurring problems, but if you don’t choose the right one your design could actually reduce clarity for your audience.
There’s a simple solution. There are a number of repositories that offer examples of important design patterns. For example, ui-patterns.com organizes interface patterns by category, provides examples, and explains the rationale of each solution.
Side note: if you’ll be working on the same project (or working at the same company) for the foreseeable future, it’s wise to start building your own pattern library.
How to Innovate for Your Audience
Once you have your patterns in place, it’s time to move from the vanilla design pattern to an interface that’s optimized to help your audience accomplish their goals.
To be clear, innovation in this context often means specific changes in a few parts of the interface. The fundamental design still fits a pattern, but new ideas are added to better help your users comprehend the interface, satisfy their needs, and accomplish their goals.
Austrian physicist Erwin Schrodinger articulated the challenge best when he said:
The task is, not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.
Of course, to do this, you must deeply understand the needs of your audience.
We use a number of techniques that help us build deeper empathy with the audience and identify original functionality or UI elements that need to be added to a pattern.
Here are two of our favorite techniques:
Mental Models
A mental model refers to an established belief someone has about how a system should look or function. This principles manifests when people find something challenging to use because the interface doesn’t function as they have already decided it should.
Often, there’s a sizable disparity between how designers perceive a product or website and how users perceive the same experience. This is discrepancy is a common pathway to poor design.
Snapchat learned the hard way when its 2018 redesign didn’t match the mental model its users had established based on the old design.
Naturally, research is the best way to uncover what’s on your users’ minds.
Usability testing — specifically where people verbalize what they’re thinking as they interact with your site — can be an excellent method for uncovering someone’s mental model of how they expect your site to perform.
Similarly, card sorting, where users group types of data based on categories, can help you understand where in the interface people expect to find content.
For example, Lyft utilized people’s mental models to design their UI.
Their users were already familiar with navigation interfaces like Google Maps, so Lyft mirrored that convention and innovated based on the needs of the audience — like visualizing where drivers are located before and during the ride.
Empathy Maps
An empathy map is a qualitative research method that visualizes specific needs and actions of your users.
Using data collected from user interviews, surveys, and field studies, empathy maps typically categorize user needs in four sections: Says, Thinks, Does, and Feels.
Synthesizing research in this way is an excellent method for uncovering conflicts between the quadrants — for example what users feel versus what they do.
These conflicts will help you identify what elements to highlight in your UI design based on the friction or gaps uncovered on the empathy map.
This insight is useful in any circumstance, but particularly when you’re designing enterprise UX, where they are a lot of environmental constraints and conflicting priorities.
Earlier this year, we utilized empathy maps to innovate the design of a fleet management application for a marine transport company. (Yes, it was as complex as it sounds.)
After we conducted our research, the empathy map revealed how much time the line haul captains needed to spend watching the river. So our designers knew that our application would only have a very limited amount of their attention.
By referencing what the line haul captains were seeing versus what they were thinking, our design team intuited that the interface had to have very large CTAs at the top of the screen to make the user’s cognitive load as small as possible.
The design was so popular that the line haul captains applauded when we presented the design for the new application.
It may not sound pioneering, but those small design innovations totally optimized the way they worked.
Conclusion
People like what’s familiar, but they also covet what’s uniquely useful.
To add innovations that bridge the gap, it’s best to start with a design pattern and let your user research guide you to the innovations that will best equip your audience to complete their goals.
In the world of design, whether it be graphic or web, you’ll always have a need to create vector graphics. Of course, there are lots of tools out there to help you with your need, but are they really the best? Today, we’re going to be taking a lot at one of the most robust apps on the market to see if it really lives up to its hype. We’re going to be reviewing Gravit Designer. Many have described it as an amazing alternative to Illustrator and Sketch, amazed by its multitude of features. But before we get more into the details that set Gravit Designer above many other designing tools, let’s find out more on our subject today.
If you haven’t already heard about it, Gravit Designer is a completely free software that gives users the power to create and design icons, presentations, illustrations, prints, apps, and even screen designs. With this program, you’ll have access to a wide range of very powerful tools to help you leap over any obstacle you may come across.
With an impressive toolset that includes UI design, icons, marketing tool graphics, concept art design, and animators, it’s a wonder that this thing is free. To top it all off, it can run both as a desktop application and in-browser, and it runs smoothly on most operating systems.
Features
A lot of these apps come with useless tools that they overcharge for, but Gravit Designer seems to be loaded down with surprisingly useful ones. Check them out:
Artboards
Layers and symbols
Booleans
A knife tool
Path graphs
Very high export quality
Text engine
Grids, anchors, and auto-layers
Multiple fills, effects, and blending modes
This list is fairly comprehensive, but there are a few other features on the app that are worth checking out for yourself. Even with just the features listed above, Gravit Designer is nothing to shake a stick at.
Price
As I mentioned before, Gravit Designer is completely free and offers no upgrade packages. Everything that the app has to offer is 100% accessible by anyone that uses it. The reason price is included in this review is so that we can compare the prices of similar apps.
Most apps similar to service and features like the ones Gravit Designer has to offer cost between $5 and $20 for the mobile versions and anywhere between $30 and $50 for the desktop application. Now, compare that to Gravit Designer’s price tag of… well, free, and you can’t beat it.
In the words of Alexander Adam, CEO of Gravit:
If it will definitely remain free and it will never be crippled by the stupid freemium or whatever, then we could offer additional things for equipment that could be paid (since we also need to pay those server accounts) but the Designer will remain free since we want everyone can have access to a professional free design tool.
User Satisfaction
One of the biggest deciding factors when purchasing a vector design tool is seeing how well it sits with other users. As of right now, there are very few, if any negative reviews on Gravit Designer. This is great news for anyone looking for a helpful tool. Combine that with the fact that it’s completely free, and you have yourself a great app.
Don’t get me wrong, there are a few reviews that list some cons to the app. Here are a few examples:
You cannot export to most popular files. This means that you can’t pick up where you left off if you decided to swap to another platform. This can cause massive delays if you need to switch things up.
The app changes constantly. With all the attention it’s getting, there are almost constant updates to keep things fresh. This could be viewed as a negative or a positive, however, as it’s always good to get refreshing updates.
Since it is free, it does often lack some of the power the other paid programs produce.
Again, for a free app, you really can’t be too mad at the features Gravit Designer offers. Ignoring the features, the interface is very straightforward and easy to follow. It makes it difficult to get lost and allows you more time to focus on your designs. Depending on your needs, or if you’re just starting out in the industry, Gravit Designer is definitely worth looking into.
Here are some honest opinions of people who have tried it and shared their experience with the world on g2crowd:
I love Gravit Designer because it is a fantastic multiplatform application for vector design.
It does not matter if we need to work with vector images, icons, if we want to build a website, a mobile application, or simply create presentations with art concepts. Gravit Designer for Windows is the application that we must install on our PC, and the best totally free and very easy to use. JUAN M.
The best thing about it that it’s free. When you struggle to pay for your tools or get overcharged on cards while still need to complete work for yourself or client, gravit has your back. Paulius P.
Gravit has a modern, accessible UI, and it’s far easier to approach. I actually find it superior to Illustrator and similar applications in this regard. Jeff C.
The takeaway
Gravit Designer is definitely a contender in its category for the best software you can get your hands on. Yes, it does lack a few features that the competing paid programs offer, but considering that Gravit Designer is free, it’s worth looking into. The features that it does offer are very inclusive and easy to use, and the interface is very user-friendly. All-in-all, Gravit Designer is a great addition to anyone’s desktop.
We would love to find out your opinion on Gravit Design after you give it a try. What other weather app design tools do you use? We would love to hear more about it in the comment section below. Also, if you enjoy reviews like this, and want to stay up-to-date with the design world, then be sure to tune into Webdesignledger daily for new and creative content.
Harry completely adores the use of adding multiple classes like this to an element:
So what I’m trying to advocate here is taking advantage of the work that others have done in building functional CSS libraries. They’re built on solid foundations in design, people have spent many hours thinking about how these libraries should be built, and what the most useful classes will be.
And it’s not just the classes that are useful, but the fundamental design principles behind Tachyons.
This makes a ton of sense to me. However, Chris notes that he hasn’t heard much about the downsides of a functional/atomic CSS approach:
What happens with big redesigns? Is it about the same, time- and difficulty-wise, or do you spend more time tearing down all those classes? What happens when you need a style that isn’t available? Write your own? Or does that ruin the spirit of all this and put you in dangerous territory? How intense can all the class names get? I can think of areas I’ve styled that have three or more media queries that dramatically re-style an element. Putting all that information in HTML seems like it could get awfully messy. Is consistency harder or easier?
This also makes a ton of sense to me, but here’s the thing: I’m a big fan of both methods and even combine them in the same projects.
Before you get mad, hear me out
At Gusto, the company I work for today, I’ve been trying to design a system that uses both methods because I honestly believe that they can live in harmony with one another. Each solve very different use cases for writing CSS.
Here’s an example: let’s imagine we’re working in a big ol’ React web app and our designer has handed off a page design where a paragraph and a button need more spacing beneath them. Our code looks like this:
In other words, we use functional classes to make layout adjustments that might be specific to a particular feature that we’re working on. However! That Button component is made up of a regular ol’ CSS file. In btn.scss, we have code like this which is then imported into our btn.jsx component:
.btn {
padding: 10px 15px;
margin: 0 15px 10px;
// rest of the styles go here
}
I think making brand new CSS files for custom components is way easier than trying to make these components out of a ton of classes like margin-*, padding-*, etc. Although, we could be using functional styles in our btn.jsx component instead like this:
This isn’t a realistic example because we’re only dealing with two properties and we’d probably want to be styling this button’s background color, text color, hover states, etc. And, yes, I know these class names are a little convoluted but I think my point still stands even if you combine vertical and horizontal classes together.
So I reckon that we solve the following three issues with functional CSS by writing our custom styles in a separate CSS file for this particular instance:
Readability
Managing property dependencies
Avoiding the painful fact that visual design doesn’t like math
As you can see in the earlier code example, it’s pretty difficult to read and immediately see which classes have been applied to the button. More classes means more difficulty to scan.
Secondly, a lot of CSS property/value pairs are written in relation to one another. Say, for example, position: relative and position: absolute. In our stylesheets, I want to be able to see these dependencies and I believe it’s harder to do that with functional CSS. CSS often depends on other bits of CSS and it’s important to see those connections with comments or groupings of properties/values.
And, finally, visual design is an issue. A lot of visual design requires imperfect numbers that don’t properly scale. With a functional CSS system, you’ll probably want a system of base 10, or base 8, where each value is based on that scale. But when you’re aligning items together visually, you may need to do so in a way that it won’t align to those values. This is called optical adjustment and it’s because our brains are, well, super weird. What makes sense mathematically often doesn’t visually. So, in this case, we’d need to add more bottom padding to the button to make the text feel like it’s positioned in the center. With a functional CSS approach it’s harder to do stuff like that neatly, at least in my experience.
In those cases where you need to balance readability, dependencies, and optical adjustments, writing regular CSS in a regular old-fashioned stylesheet is still my favorite thing in the world. But functional CSS still solves a ton of other problems very eloquently.
For example, what we’re trying to prevent with functional classes at Gusto is creating tons of stylesheets that do a ton of very specific or custom stuff. Going back to that earlier example with the margin beneath those two elements for a second:
I would argue that styles like this make our code harder to understand, harder to read, and encourages diversions from our library of components. By replacing this with a class from our library of functional classes, it’s suddenly much easier to read, and to change in the future. It also solves a custom solution for our particular needs without forking our library of styles.
So, I haven’t read much about balancing both approaches this way, although I assume someone has covered this in depth already. I truly believe that a combination of these two methods is much more useful than trying to solve all problems with a single bag of tricks.
This article presents a modern approach to building an interactive infographic. You sure can have plain infographic with all the information available upfront — without any user interaction. But, thinking of building an interactive experience — changes the technology landscape we choose. Therefore, let’s understand first, why Vue.js? And you’ll see why GSAP (GreenSock Animation Platform) and SVG (Scalable Vector Graphics) become obvious choices.
Vue.js provides practical ways to build component-based, dynamic user interfaces where you can manipulate and manage DOM elements in powerful ways. In this instance, it’s going to be SVG. You can easily update and manage different SVG elements — dynamically — using only a small subset of features available in Vue.js — some of the staple features that fit the bill here, are, data binding, list rendering, dynamic class binding to name a few. This also allows you to group relevant SVG elements together, and componentize them.
Vue.js plays nice with external libraries without losing its glory, that is GSAP here. There are many other benefits of using Vue.js, one of which is that, Vue.js allows you to isolate related templates, scripts, and styles for each component. This way, Vue.js promotes modular application structure.
Vue.js also comes packaged with powerful lifecycle hooks that let you tap into the different stages of application to modify application behavior. Setting up and maintaining Vue.js applications doesn’t require a big commitment, meaning you can take phased-approach to scale your project as you go.
The infographic is very light-weight in a visual sense, as the main aim of this article is to learn how to think in terms of data, visual elements, and of course, Vue.js — the framework that makes all the interactivity possible. In addition, we’ll use GreenSock, a library for animating SVG elements. Before we dive in, take a look at the demo.
We’ll start with:
The overview of the data for infographic;
SVG image preparation;
An overview of Vue components in context of the SVG artwork;
Code samples and diagrams of key interactivity.
The infographic that we’re going to build is about Tour De France, the annual bicycle racing event held in France.
Overview Of Tour De France Data
In infographic design, data drives the design of your infographic. Therefore, while planning your infographic design, it’s always a good idea to have all data, information, and statistics available for the given subject matter.
During Tour De France of 2017, I learned everything about this biggest cycling event that I could in 21 days of the game in July, and I familiarized myself with the subject.
Basic entities of the race that I decided to go for in my design are,
Stages,
Teams,
Routes,
Winners,
Length and classifications of each routes.
This next part of the process depends on your thinking style, so you can be creative here.
I created two sets of data, one for stages and other for teams. These two datasets have multiple rows of data (but within limit)? — ?which matched with two wheels of the bicycle with multiple spokes in each. And that defined the key element of the design, The Bicycle Art that you saw at the beginning? — ?where each spoke will be interactive & responsible to drive what information is revealed on screen.
I mentioned within limits above, because what we’re aiming for in this instance is not a full-blown data-visualization in context of big data but rather an infographic with high-level data.
Therefore, spend quality time with data and look for similarities, differences, hierarchy or trends that can help you convey a visual story. And don’t forget about the amazing combination of SVG and Vue.js while you’re at it, as it will help you bring about the right balance between information (data), interactivity (Vue.js) and design elements (SVG Artwork) of infographic.
Here’s the snippet of a stage data object:
{
"ID": 1,
"NAME": "STAGE 01",
"DISTANCE": "14",
"ROUTE": "KMDÜSSELDORF / DÜSSELDORF",
"WINNER": "THOMAS G.","UCI_CODE": "SKY","TYPE": "Individual Time Trial","DATE": "Saturday July 1st","KEY_MOMENT": " Geraint Thomas takes his first win at 32"}
This infographic is operated by a very simple logic.
UCI_CODE (Union Cycliste Internationale) is the connecting key between the stage and the team object. When a stage is clicked, first we’ll activate that stage, but also use UCI_CODE key to activate corresponding winning team.
SVG Preparation
Having a couple of datasets and a rough concept of bicycle art ready, here’s the static SVG CodePen of the infographic I came up with.
We have created only one spoke for each wheel, that is because we’ll dynamically create rest of the spokes using a number of records found in the dataset, and animate them using GreenSock Library.
The workflow to create this SVG code is also very simple. Create your Infographic artwork in Adobe Illustrator and save as SVG. Make sure to name each group and layer while working in Illustrator, because you will need those ids to separate parts of SVG code that will eventually populate area of Vue components. Remember that layer names given in Illustrator become element ids in SVG markup.
You can also use SVGOMG and further optimize SVG code exported from Adobe Illustrator.
Important Note: If you use SVGOMG to optimize SVG markup, your code certainly will look neat, but note that it will convert all elements into with d attribute. This results into losing x and y values of the rectangle, in case you wish to adjust few pixels manually later-on.
Second thing, make sure to uncheck Clean Id option (right-hand side options in SVGOMG interface), this will help maintain all groups and ids intact that were created in Illustrator.
Vue Component Overview
Even if interactivity and data-flow in your infographic project is quite simple in nature, you should always take a moment to draw up a tree diagram of components.
This will especially help in case you’re not using any shared-data mechanism, where child components are dependent on the values sent from the parent component (i.e. via props) or vice-versa (i.e. this.$emit events). This is your chance to brainstorm these prop values, emit events and local data — and document them before starting to write the code.
Diagram above is the snapshot of Vue components that is partially derived from interactivity requirements and partially based on SVG markup. You should be able to see how SVG markup will be split up based on this tree structure. It’s pretty self-explanatory from hierarchy view-point.
Chain-wheel will imitate rotation of spokes.
Stage component is the rear wheel that will list all 21 stages.
Stage-detail component will display related information on a curved path (left-hand side).
Team component is the front wheel that will list all participating teams on spokes.
Team-detail component will display related information on a curved path (right-hand side).
Navigation will include back and next button to access stages.
The diagram below represents the same Vue components seen above, but in the context of the infographic design.
Less is more — should be the approach you should try to take while working on similar projects. Think through the animation and transition requirements you have, if you can get away with using TweenLite instead of TweenMax — do so. If you have the option to choose elementary shapes and simpler paths over complex ones — by all means try to opt-in for light-weight elements that are easy to animate — without any performance penalty.
Next section will take you through an exciting part with GreenSock animation and Vue.js.
GreenSock Animation
Let’s take a closer look at:
Text animation on a curved path;
Spoke animation on a wheel.
Animating Text On A Curved Path
Remember the curve path seen around the bicycle wheel, that curved path is slightly bigger than the radius of the bicycle wheel. Therefore, when we animate text on this path, it will look as if it follows the shape of the wheel.
As you increase the startOffset percentage, text will travel further through the circle perimeter.
In our final project, this animation is triggered every time any spoke is clicked. Now, let’s move on to a more exciting part of the animation.
Animating Stages/Spokes Inside The Wheel
It’s visible from the demo that stage and team components are similar in nature with couple of small differences. So, let’s focus on just one wheel of the bicycle.
The CodePen example below zooms in on just the three key ideas:
You may have noticed in the static SVG CodePen above that the spokes are nothing but SVG rectangles and text grouped together. I have grouped them together since I wanted to pick both text and rectangle for the purpose of animation.
Rotation To rotate spokes, we’ll simply map through all elements with className stage, and set dynamic rotation value that is calculated for each spoke.
Transform Origin Notice transformOrigin value in the code above, which is as important as index value, because “0% 100%” enables each spoke to rotate from the center of the wheel.
stageAngle This is calculated using total number of stages divided by 360-degree. This will help us lay every spokes evenly in 360-degree circle.
ADDING INTERACTIVITY
Next step would be to add click-event on each stage to make it interactive and reactive to data changes? — ?hence, it will breathe more life into an SVG image!
Let’s say, if stage/spoke is clicked, it executes goAnimate(), which is responsible to activate and rotate the stage being clicked using the stageId parameter.
We’ll use DirectionalRotationPlugin…which is a key ingredient for this interactivity. And yes, it is included in TweenMax.
There are three different ways of using this plugin. It animates rotation property in 1) clockwise, 2) counter-clockwise and 3) in the shortest distance calculated to the destination.
As you’d have guessed by now, we’re using the third option to rotate the shortest distance between the current stage and new stage.
Review the CodePen above and you’ll see how Stage 01 is constantly moving around the circle, leaving its original spot for new active stage at 0-degree angle.
First, we need to find the angle of a stage being clicked, and interchange its rotation with Stage 01. So, how do we find the rotation value of the stage being clicked? Check out the diagram below.
For example, if Stage 05 is clicked (as you can see above), the journey from Stage 01 to Stage 05? — ?requires 4 x angle-value.
And therefore, we can get the correct angle using, (Active stage Id - 1) * 17 degree, followed by ‘_short’ string postfix to trigger directional rotation plugin.
The final goAnimate() function will look something like below:
_.map(spokes, (item, index) => {
if(activeId == index+1) {
// active stage
TweenMax.to(item, 2,
{ rotation: 0+'_short',
transformOrigin: "0 100%"
})
} else if (index == 0) {
// first stage
TweenMax.to(item, 2,{ rotation: (activeId*angle)-angle+'_short',transformOrigin: "0 100%"})} else {TweenMax.to(item, 2,{ rotation: index*angle+'_short',transformOrigin: "0 100%"})}}) // end of map
Once we have the rear wheel ready, the front wheel (for team) should follow the same logic with a couple of tweaks.
Instead of stage, we’ll fetch team data and update registration point of transformOrigin attribute to enable spokes generation from opposite registration point than the stage wheel.
// set team spokes
map(teamSpokes, (index, key) => {
TweenMax.to(index, 2,
{ rotation: angle*key,
transformOrigin: "100% 100%"}, 1)})
Final Project
Like me, if you have written all animation and data related functions in Vue components itself. It’s time to clean them up using Vuex and Mixins.
VUEX
Vuex eases up the management of shared data among components, and more importantly, it streamlines your code, keeping methods and data() clean and tidy, leaving components only to render the data, not to handle it.
Lifecycle hooks are a very suitable place to perform any HTTP requests. We fetch initial data in created hook, when the Vue application has initialized, but hasn’t yet mounted into the DOM.
Empty state variables, stages and teams are updated using mutations at this stage. We then, use watcher (only once) to keep track of these two variables, and soon as they’re updated, we call in animation script (from mixin.js).
Every time user interacts with stage or team component, it will communicate with Vuex store, executes setActiveData, and updates current stage and current team values. That is how we set active data.
And when the active data is set after state update, goAnimate will kick in to animate (directional rotate) spokes using updated values.
Now that the data is handled by Vuex, we’ll separate out GreenSock animations. This will prevent our Vue components being cluttered with long animation scripts. All GreenSock functions are grouped together in mixin.js file.
Since you have access to Vuex Store within Mixins, all GSAP functions use state variables to animate SVG elements. You can see fully functional store.js and mixin.js in the CodeSandbox example over here.
Conclusion
Creating interactive and engaging infographics requires you to be analytical with the data, creative with visuals and efficient with the technology you use, which in this case is Vue.js. You can further use these concepts in your project. As a closing note, I’ll leave you with this circular interactive color wheel below that uses an idea similar to the one we’ve discussed in this article.
With no doubt, Vue.js has many great features; we’re able to create interactive infographics with just a few things, such as watchers, computed properties, mixins, directive (see color-wheel example) and a few other methods. Vue.js is the glue that holds both SVG and GreenSock animation together efficiently, giving you ample of opportunity to be creative with any number of subject matter and custom interactivity at the same time.
Welcome back, readers! My favorite thing about you all is that you’re all much too classy to put up Christmas decorations this darned early. Yes. You are. I insist.
I could also insist that you have a look at these portfolios, but you already clicked, and we all know what you’re here for: a mix of minimalist, corporate, and super artsy designs!
Note: I’m judging these sites by how good they look to me. If they’re creative and original, or classic but really well-done, it’s all good to me. Sometimes, UX and accessibility suffer. For example, many of these sites depend on JavaScript to display their content at all; this is a Bad Idea, kids. If you find an idea you like and want to adapt to your own site, remember to implement it responsibly.
Justin Jackson
Justin Jackson’s portfolio does that rare and beautiful thing of making use of monospace fonts in a way that doesn’t look too brutalist. Okay, so maybe it looks a bit “grunge”, but it’s grunge and it’s usable. What’s not to love?
Platform: Statamic
Paul Macgregor
Paul Macgregor’s portfolio brings us to our first (but probably not last!) uber-minimal design of the month. And it’s a fantastic example of the principle, too, with all the important information right up front, and quite literally center. Other than my usual issues with JS-dependent navigation, I can find no fault.
Platform: Static Site
Mawla
Mawla is an app development studio, and I’m slightly in love with their site design. All the colorful blobs remind me of fliers from my childhood, but better. Yeah, they actually made blobs work.
Look, I’m not saying everyone should adopt colorful blobs as a strategy. That way lies madness and/or blindness. But running across these sites that let their designers go a little wild without sacrificing general usability is always nice.
Platform: WordPress
Ethan Tennier-Stuart
Ethan Tennier-Stuart brings us back down to earth with a very type-and-whitespace-focused design that keeps things simple. This one is an absolute master class in spacing out elements.
Platform: Static Site
Owl
Owl is a Russian design agency, but maybe don’t quote me on that. You know typography is good when you can’t read a word of it, but you don’t mind just staring at it for a bit. Their graphic design skills are impeccable, too.
It reminds me of that brief moment in time when photomontages were everywhere.
Platform: WordPress
Jack McDade
Jack McDade bills himself as the “Ultimate Web Master”, a title as full of nostalgia as his site’s aesthetic. It’s simple, but colorful.
I have to say that Jack is pretty confident in his work’s ability to speak for itself. He lists some of his former and current projects in paragraph form, and leaves you to decide whether or not to click. Considering that he built the CMS known as Statamic, I’d say he can afford to be confident.
Platform: Statamic (Probably)
Future Comes
Future Comes is an interesting case. It’s a one-page website, but the studio seems to do a lot of different things. They don’t really bother to explain what they do in simple terms. They assume that if you need what they have, you understand what they’re telling you.
Since it all seems to be fairly technical, and geared toward corporate customers, the site is highly corporate in its aesthetic. There is sans-serif type, subdued reds and blues, fun with gradients, and a little tasteful animation.
Platform: Static Site
Cyber-Duck
If the last site whet your appetite for some clean corporate goodness, look no further than Cyber-Duck. It’s simple, it’s solid, it has a ton of blue. It’s strangely comforting.
It also has a page that details their accessibility principles, which includes such delights as big text, their commitment to making the site accessible without JavaScript, and many other things that made me happy.
This is how you do it, front-end devs!
Platform: Undetermined CMS
double take
double take goes for the good-old black, white, and yellow approach that just stand out so nicely. There’s a bit of asymmetry thrown in for good measure. Still not a fan of cursor replacement, but otherwise, this one’s worth a look.
Platform: Static Site
Paul O’Rely
Paul O’Rely caught my eye with those thin diagonal lines, and the highly expressive type in his one-page site. Overall, it creative and stylish.
My only complaint is that the contact form really doesn’t look like one. To balance that out, I’ll say that I love the auto-generated ice-breaker feature. And the fact that you can send him drawings made right on the page. That’s pretty cool.
Platform: Static Site
Jack Watkins
Jack Watkins’ portfolio features some lovely typography, and a generally solid aesthetic. The part I really like, though, is the layout. In a world of mobile-first layout—which is important—it seems like big screen often get underutilized. This site bucks that trend.
Platform: Static Site
K2
K2 brings us a design that feels rather “Medium-ish”. For all that, it’s pretty, stylish, and a pleasure to browse. What can I say? Medium has good taste.
Platform: Static Site
Rubxkub
Rubxkub brings us back a few months to an age when everything was artistic and collage-ridden. Good times. Don’t take my joking the wrong way, it looks beautiful. It’s some good old artsy minimalism.
Platform: Static Site
New Need
New Need is a furniture design studio with an emphasis on the modern aesthetic. Their website matches their work with a very PowerPoint style design.
Platform: JS App
Great Design
Great Design is a boldly named studio with bold black lines everywhere. It’s just how they roll, apparently. I also like how they used independently scrolling columns in their portfolio. I’m not saying we need to be using iframes for everything again, but I will say that I rather like the look of the thing.
Platform: Static Site
Thomas Williams
For something easier on the eyeballs, look no further than Thomas Williams who comes at us rather gently with a dark design. It’s still trends toward the modernist, but it’s more “solid” than “artsy”.
Platform: WordPress
Netrix
Netrix uses a lot of building-block-style imagery, and the masonry layout of the portfolio will cement that concept in your mind in a slightly more subtle way. It does all of this while looking quite classy.
Platform: Static Site
Wonderland
Wonderland is one of those sites that transitions from PowerPoint style to fairly standard minimalism, with a healthy dose of animation all throughout. It also makes nice use of the Lydian typeface, which makes a refreshing change from a lot of the usual typefaces.
Platform: VueJS
Koysor Abdul
Koysor Abdul’s photography portfolio keeps things simple with earthy tones and a lot of off-white space. Browsing this one is an almost peaceful experience.
Platform: Webflow
Aristide Benoist
I love to see the trends I’ve known and named evolve over time, and Aristide Benoist’s portfolio is a prime example of that evolution. It has a touch of both the modern and the post-modern, each helping to smooth out the edges of the other. There’s a little asymmetry, but everything still feels intentionally placed. It just feels good.
Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.
The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.
Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.
Web.Dev
25 Years Ago Today, the First Major Web Browser was Released: NCSA Mosaic 1.0
Just-in-time Design
Why Does Every Homepage Look the Same?
Why You Should Use a Text Area for Address Form Fields
UX Portfolio Tips and Best Practices
In the Dead of Night: Why We are Drawn to Dark Interfaces
Creatives’ Worldwide Tribute to Legendary Stan Lee
Building your Color Palette
Creating Excellent UX Flow Charts
The Importance of Wireframing in Web Design
These 5 Questions Kill Creativity
Tensorflow 2.0 – A More User Friendly API
Codevember
The Dangerous Fetishization of ‘Hustle Porn’
Why Doctors Hate their Computers
World War Three
Starting a Design System
Google Admits Too Much White Space in Apps is Bad for Battery Life
How Nirvana’s Iconic Nevermind Album Cover was Designed
Kill your Personas
What Chinese Travel Sites Taught Me About UI
Balancing Creativity and Usability
Why are Tech Companies Making Custom Typefaces?
Videogame Onboarding Experiences are a Lesson to Designers
Want more? No problem! Keep track of top design news from around the web with Webdesigner News.