Tag: Should

2-email-testing-flow
02 Jul

Email Testing Flow As It Should Be

by TBSCategories: News

We spend a lot of time and effort crafting emails with a specific purpose: to make their recipients read them and take the desired actions. The three known bottlenecks of every email sequence include:

  1. Deliverability Emails are going to spam folders and are never read.
  2. Display issues Email content is broken or not properly rendered and as a result, such emails are read but don’t prompt the reader to take action.
  3. Engagement This is a whole set of reasons, such as vague email subject or unclear email copy, which can cause both not reading and not taking action.

How can we address these challenges? It is recommended to follow rules and best practices of building and sending emails.

But how do we know that they work?

By testing every single email aspect! Unfortunately, email testing is often underestimated and leads to email testing mistakes that kill all your effort spent on creating a great email sequence.

Let’s talk email testing! In this article, we’ll explain how a proper email testing workflow can help you improve email sending efficiency. We’ll describe common testing approaches and mistakes, and demystify the seamless email testing flow.

With this article, you will enhance your testing workflows by covering all the important aspects, and saving time and stress with suitable email testing methods and tools.

Are You Keeping On Top Of Your Email Metrics?

While there’s always something to be improved, it’s important to understand when you underperform and need to take action right away.

With any type of email you send, you need to track at least these metrics:

Open rate How many messages you sent vs. how many of them were opened.
Bounce rate How many emails were returned to you?
Click-through rate For those emails that contain links, how many links were clicked?
Unsubscribe rate For marketing email campaigns, the unsubscribe option is required.

When sending marketing messages (such as newsletters, special offers, abandoned cart emails, and so on), you can compare your rates to the industry standards. However, they will also change over time and in different circumstances.

According to Hubspot, the average email rates are:

  • Open rate varies from 19% to 26% depending on the industry.
  • Click-through rate is naturally lower, from 6.82% to 9.31%.
  • Hard bounce rate should be as low as 0.3% to 0.9%.
  • Unsubscribe rate is fine when it’s between 0.3% and 0.6%.

The research conducted by Constant Contact shows the following numbers:

  • The average open rate across all industries is 17.13%, with the highest value of 28.84% for religious organizations and the lowest of 10.25% for automotive services.
  • Click-through rate is 10.25% on average — the highest is 17.35% for publishing and the lowest is 5.54% for real estate.
  • Both hard and soft bounce rates are about 10.28% — as low as 6.47% for civic/social membership and as high as 15.47% for legal services.

With transactional emails, it’s a bit trickier, because the open rate you should strive for depends on the type of email you send. For example, reset password emails should be opened by the majority of your recipients, let’s say up to 90%. Order confirmation emails won’t have such a high open-rate but will receive much more interest than a marketing campaign, even with an exclusive offer.

The other side of the coin for transactional emails is that they should be opened by the right people at the right time. Otherwise, such emails are useless or even harmful. Imagine that John has just signed up for a financial service to create a tax report. To proceed, he needs to click a button in the confirmation email. After three hours, when John’s working day has already finished, he receives an email welcoming someone named Jack. Will he move on with that service? It’s doubtful.

We are pretty sure that you test your emails before sending them to avoid such ridiculous situations. But are you certain that your email testing flow is comprehensive and smooth enough?

What Should You Test For Different Sorts Of Emails?

We have already mentioned the difference between marketing and transactional emails. Their purpose, sending method, and performance vary, and so should the testing flow.

However, the goals of testing are common for all types of email sequences — ensure deliverability, content excellence, and engagement. That’s why there is a list of aspects that you should test for any kind of email.

Universal Email Testing Aspects

  1. Email sending infrastructure.
    Even when you use a dedicated email marketing service, you need to check whether all integrations work perfectly fine, especially, when it is first set up.

    • Make sure you use the proper domain for sending emails. A mistake could be made when you work with several projects/websites.
    • Check whether necessary authentication methods are set — SPF and DKIM are required, while DKIM is highly recommended, but it’s still optional.
    • Test your SMTP connection (there are tools both for developers and marketers — we will take a look at them later in this article).
    • Examine all other additional settings, such as using dedicated or shared IP, feedback loops, and so on.

  2. Email template.
    No matter what the message’s purpose is, it should be correct and visually appealing for every recipient.

    • Every company email, from a small notification to a detailed tutorial or newsletter, should be built with an HTML template. It is important to make sure that your message looks as designed for all your recipients. The trick is that different email clients use different rendering engines — this means that there is no standard for processing email templates. Even if you included a small PNG picture, there’s no guarantee that it will be properly displayed across all email clients and devices — let alone more complex elements, such as video or animation.
    • Needless to say, the email message must not contain any mistakes or typos. Email copy also needs testing, to be clear, concise, and correct.
    • All the links and buttons should be valid and lead to the right destinations. Pay special attention to automatically generated personal links — for example, account confirmation, password reset, personal offer, etc.
      • Personalization and/or dynamic content.
        Today almost all messages contain at least a tiny bit of personalization. When using merge mechanisms, make sure that emails are sent to the right addresses and that dynamic variables are generated correctly (e.g. username, location, behavior in the app, and so on). Otherwise, you risk not only offending your customers by calling them a wrong name (Hello %FirstName%!), but also disclosing personal information. All in all, it may result in a low conversion rate for your campaigns.

  3. Email headers and subject.
    The sender’s name and the email subject line are the first two things the recipient sees and considers when clicking your message to open it or to route it to a spam folder. Add more focus here!

    • From, To, and Cc are three well-known headers. Make sure they are technically correct, and also don’t be afraid to experiment — changing the “From” address can also impact the email open rate.
      • The subject line is also a header, and much has been said about it — there are special subject line checkers, various lists of “100 words that you shouldn’t use in subject lines”. Besides, the email subject is the first thing used in email A/B testing. So we won’t focus on it a lot. Let’s talk instead about the pre-header, the third thing you see in your email inbox after the sender’s name and subject line. Pre-header is often neglected, but it’s a preview text that should explain the quintessence of your message and nudge a recipient to open it. If you don’t set it, the first characters of your email will be used by default. Why should you waste those precious 50-100 characters for “Hey #name something”?
        Tip: Use the &nbsp trick to set a pre-header if your email sending tool doesn’t offer such functionality, and then test how it will look for your recipients.
    • Technical headers or metadata.
      There is message metadata that can help you debug messages or track them. For example, some providers allow adding categories to the X-SMTPAPI header of the emails, which is useful for email performance tracking. Checking the raw message data can provide you with helpful information if you are an advanced SMTP email user.

  4. Spam checks.
    Would you like to have a list of precise criteria that cause emails to be marked as spam? Everyone would, especially spammers. That’s why you can only follow some general rules and use dedicated services that analyze the reputation of your sending IP, the content of your email headers, the correctness of your HTML, whether you use certain phrases, and so on. Transactional emails can get classified as spam, too.

Peculiarities Of Transactional Email Testing

When you send triggered emails, especially from your own application or online service, you should take care of a few more aspects.

  1. Test your sending script. Here are two important aspects:

    • Test whether your code works and sends emails in the right way.
      • Check whether it seamlessly works with triggers: when a user completes a specific action, they should receive an appropriate email notification. It’s efficient to cover this part of your app functionality with automated tests — perform user acceptance testing.

  2. If you are launching a large-scale system, it’s important to perform email app load testing. What if 2,000 users simultaneously click “reset password”? What happens next? How soon will they receive an email confirmation?

Marketing Emails Testing Focus

When you use a bulk email service, in most cases, you have built-in automation and basic testing functionality.

However, there are a couple of moments that require manual checking. They may seem obvious, but are still often overlooked.

  • Make sure that the right database is selected (or the right list of contacts in your email marketing service). There are many cases when test emails are sent to customers, or a customer segment receives an offer that is not valid for them. Our favorite real story is about the US embassy in Australia accidentally sending out a test email known as a “Cookie Monster cat email”. It had “Meeting” in the subject line and a picture of a cat in blue pajamas holding a plate of cookies in the content. They were testing some new email sequences and selected their real email database instead of a testing list.

This email failure quickly became popular on Twitter. Dozens of cat memes on social media are obviously funny, but this is not always the type of PR activity you expected to be part of. Take care of the proper naming for your clients’ lists — in some tools, they can be visible for your customers when they double opt-in or unsubscribe.

  • Check Bcc and Cc to not reveal any email addresses. It is not recommended, but sometimes Bcc is still used for sending small batches of emails. Just a couple of years ago one online media for software developers sent a digest to its subscribers by listing them in a Cc field. Therefore, everyone on that list could see the email addresses of other recipients — obviously, the Cc and Bcc fields were just confused in that message.

Common Email Testing Mistakes

Everyone has received an email sent by mistake at least once. Wrong links sent in promo campaigns don’t cause much harm, but what if your broken email script can lead to a data breach or a system crash? With strict data privacy guidelines, such as GDPR and CCPA, unintentional emailing to unsubscribed users or using email addresses of people who have never subscribed to your communication can lead to conflicts or penalties.

There are two main types of email testing mistakes:

  1. Important email aspects being ignored or
  2. The email testing infrastructure being set improperly.

In many teams, the email testing process is limited to sending a few test emails to your own or colleagues’ inboxes. Alternatively, public email inboxes for testing are used not to flood personal inboxes.

What can such an approach inform you about? Well, you can learn that your email sending service is functioning and that your email content is displayed correctly in your recipients’ email clients (or in a web browser). You can also ask your colleagues to click links and read the email copy. But what about other email clients and, even more importantly, deliverability?

Another point is testing 5 emails out of 5,000. When you have a robust email-related system, you have to make sure that it functions correctly. We have mentioned the importance of merging mechanisms, so here’s the case — can you be certain that the billing information of Mr. Bluesky & Co. doesn’t go to Bluebird & Bluebird because of a tiny mistake in your database? The most efficient way is to run a set of automated tests (for example, with Selenium) and check the content of each email.

Correct Email Testing Process

A smooth email testing process is based on simple principles:

  • Use a checklist to cover all important email aspects.
  • Automate everything you are able to in order to minimize human error.
  • Limit access to your sending servers and deployment processes.
  • Run all tests in a staging environment and use a fake SMTP to avoid sending test emails to real users. Some developers tend to use /dev/null fake SMTP server for email testing, but this is not efficient as it doesn’t imitate production. If you run tests in a production environment, be ready to reveal test data to real users.
  • Use server monitoring tools. They can help you indicate the abnormal activity and quickly take action if something goes wrong.

Email Testing Toolkit

There is no ubiquitous email testing flow because the process of testing depends on the type of email campaign you send, the method you use (whether it’s an email marketing service or your custom email functionality in your application), and the team you work with.

Development and QA teams who build transactional email sequences usually run automated tests by integrating testing frameworks and tools, such as Selenium.

For marketing campaigns, it’s more common to create an email testing checklist. I’d recommend creating a custom email testing list based on the aspects explained in the “What should you test for different sorts of emails?” section and competing it with the tools of your choice.

When you select an email tool, especially a paid one, pay attention to those services that offer wide functionality and can be used by both marketing and development teams.

We have talked about the general rules of successful and painless email testing. Now let’s go into detail about each type of test, with examples of tools.

How To Test Sending Infrastructure

This type of testing is usually used by developers, but there are tools that can come in handy for marketers as well.

In general, you should test your mail server when you establish a new integration, change your setup, or maintain your own email sending infrastructure.

Telnet is a computer protocol that provides communication with a remote server. It’s also a command-line utility available in most common computer systems, including Windows, Mac, Linux, and more. It can help you test server connection, ports open for email communication, supported SMTP commands, relaying specific email addresses or domains.

To use this utility for testing, you will need to run a set of SMTP commands in a telnet client (which is pre-installed on the majority of systems).

Wormly is an uptime monitoring service that also has an SMTP/Mail Server Test. It can help you test whether your SMTP server is configured correctly by sending a test message to your email server. Wormly will log the SMTP conversation for you so you can check and debug errors or exceptions if there are any to be found.

It’s super simple to use: you just need the address of your sending server, a recipient email address, and a port. You can also share the results of your team with a shareable link. Here is the case of how a marketer can use it — run a test in Wormly, proceed if no errors were thrown, and, if any were found, send a link to your dev team for troubleshooting help.

Wormly can be also useful for SMTP server monitoring, which I’ve mentioned in the Correct Email Testing Process section.

Gmass is an email marketing service inside Gmail. It also has a mail merge functionality and cold email sending options. The tool is a paid service, but it has a few helpful free tests:

  • SMTP tester,
  • Email tester (SPF, DKIM, blacklisting),
  • Inbox, Spam, or Promotions (inbox placement),
  • Email verifier (contact list),
  • Email deliverability wizard (stats for a list of campaigns via any Google account within the last 24 hours that had at least 1,000 recipients).

If you expect high loads on your email server, it will also be good to perform load testing with a tool like Apache JMeter™ or an email sandbox service.

How To Test Email Content

In this category, you have the widest choice of tools. We will name a few to provide you with a starting kit.

Email Template Checkers

When building an HTML email template with a special template builder or using a drag-and-drop editor in your email sending tool, you will have a preview option. It will display how your template is rendered and, in most cases, how it looks on different devices.

If you need a separate solution for HTML preview, you can use a tool like PilotMail. It provides an email builder, layout viewer, and a test email sending to 10 addresses. There is a free plan, but the paid one costs just $ 3/month.

With no rendering standards for email clients, it’s important to perform email client testing to make sure that your email will look perfect in any of the recipient’s email clients. The most popular tools in this category are Litmus and Email on Acid. They generate previews for a list of email clients and allow you to manually compare them and look for issues. You can experiment with both of them on a 7-day free trial, while further usage starts at $ 73/month.

Another approach for email client testing is used in HTML Email Check and Mailtrap (As a friendly disclaimer, I actually work there.) These tools analyze your email template for HTML and CSS validity and provide you with an actionable list of errors for each email client. Free plans are available for both tools, and their paid subscription plans start at $ 10/month.

Email Content Checks

Spell checkers and content testing tools are helpful for emails as well. Grammarly or ProWritingAid can help you check your email copy for errors and typos (both have free plans). Hemingway Editor can give you tips on improving readability and if you’re struggling with writing, Conversion.ai can actually write you an email copy.

The Subject Line And Preheader

Email marketing services usually provide options to preview the subject line and preheader. You can also play with TESTSUBJECT by Zurb that displays email subject and preheader previews for a few types of mobile devices. Preheader Testing Tool also provides similar functionality.

Subject Line Tester by CoSchedule and Send Check It can help you optimize your subject line for driving more opens.

How To Test Email Deliverability

Finally, we’ve made it to our favorite, but the most complicated, point — email deliverability. A whole set of factors impact your spam score: sender reputation, authentication, and email content.

There are a few tools that test your email against all the criteria.

You can start with Mail Tester. It’s free, but it provides a number of important tests. You can view your message and its source code after sending your email to a provided test address, get a SpamAssassin score, authentication check, message body analysis (it also shows HTML size), blacklisting report, link validation, and more.

Free Spamcheck by Postmark offers similar functionality. You can use it without sending a test message — just paste your HTML code with all headers and get an instant result. You can also integrate Spamcheck with your app via their JSON API and run automatic spam checks for all emails you send.

If you need a more robust solution, there is GlockApps. It has a 14-day free trial and then offers subscription plans starting at $ 79/month. By the way, their website states that:

“On average 51% of emails never reach the inbox! So where do they go? 26% go to the spam or junk folder and 25% are never delivered.”

GlockApps is known for its powerful reports available for registered users. It provides inbox placement, reputation check, DMARC analytics, bounce analytics, automatic tests, monitoring and alerts, and template editor. In addition, there are a few useful separate free tools: domain checker, inbox email tester, inbox insight, DMARC analytics, and uptime monitor.

Deliverability tests are also included in many full-featured email sending and testing tools.

Summary And Main Takeaways

The main purpose of this article was to prompt you to take email testing seriously, run it as a separate project, and pay attention to every important aspect. Email is not just another line in someone’s inbox — it’s a part of the user experience of your app, website or blog. It’s ideal to be able to have a team of marketers, developers, product managers, and QAs who can work together on spotless email sequences. But even if you are running a small project or have limited time and resources, you have a great list of handy tools that can do the job for you.

For any type and scale of the email-related project, it is worth allocating time to establish an email testing workflow and to experiment with tools. This will save you time and improve the quality of your campaigns at every iteration. And of course, you are very welcome to share your email testing stories and approaches in the comments!

Related Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

the-relevance-gap_kzwi6q
05 Jan

Should The Web Expose Hardware Capabilities?

by TBSCategories: News

I have recently been interested in the difference of opinions between the different browser vendors about the future of the web — specifically in the various efforts to push web platform capabilities closer to native platforms, such as Chromium’s Project Fugu.

The main positions can be summarized as:

  • Google (together with partners like Intel, Microsoft and Samsung) is aggressively pushing forward and innovating with a plethora of new APIs like the ones in Fugu, and ships them in Chromium;
  • Apple is pushing back with a more conservative approach, marking many of the new APIs as raising security & privacy concerns;
  • This (together with Apple’s restrictions on browser choice in iOS) has created a stance labeling Safari to be the new IE while claiming that Apple is slowing down the progress of the web;
  • Mozilla seems closer to Apple than to Google on this.

My intention in this article is to look at claims identified with Google, specifically ones in the Platform Adjacency Theory by Project Fugu leader Alex Russell, look at the evidence presented in those claims, and perhaps reach my own conclusion.

Specifically, I intend to dive into WebUSB (a particular controversial API from Project Fugu), check whether the security claims against it have merit, and try to see if an alternative emerges.

The Platform Adjacency Theory

The aforementioned theory makes the following claims:

  • Software is moving to the web because it is a better version of computing;
  • The web is a meta-platform — a platform abstracted from its operating system;
  • The success of a meta-platform is based on it accomplishing the things we expect most computers to do;
  • Declining to add adjacent capabilities to the web meta-platform on security grounds, while ignoring the same security issues in native platforms, will eventually make the web less and less relevant;
  • Apple & Mozilla are doing exactly that — declining to add adjacent computing capabilities to the web, thus “casting the web in amber”.

I relate with the author’s passion for keeping the open web relevant, and with the concern that going too slow with enhancing the web with new features will make it irrelevant. This is augmented by my dislike of app stores and other walled gardens. But as a user I can relate to the opposite perspective — I get dizzy sometimes when I don’t know what websites I’m browsing are capable or not capable of doing, and I find platform restrictions and auditing to be comforting.

Meta-Platforms

To understand the term “meta-platform”, I looked at what the theory uses that name for — Java and Flash, both products of the turn of the millennium.

I find it confusing to compare either Java or Flash to the web. Both Java and Flash, as mentioned in the theory, were widely distributed at the time through browser plug-ins, making them more of an alternative runtime riding on top of the browser platform. Today, Java is used mainly in the server and as part of the Android platform, and both do not share much in common, except the language.

Today server-side Java is perhaps a meta-platform, and node.js is also a good example of a server-side meta-platform. It’s a set of APIs, a cross-platform runtime, and a package ecosystem. Indeed node.js is always adding more capabilities, previously only possible as part of a platform.

On the client side, Qt, a C++-based cross-platform framework, does not come with a separate runtime, it’s merely a (good!) cross-platform library for UI development.

The same applies for Rust — it’s a language and a package manager, but does not depend on pre-installed runtimes.

The other ways to develop client-side applications are mainly platform-specific, but also include some cross-platform mobile solutions like Flutter and Xamarin.

Capabilities vs. Time

The main graph in the theory, shows the relevance of meta-platforms on a 2D axis of capabilities vs. time:

I can see how the above graph makes sense when talking about cross-platform development frameworks mentioned above like Qt, Xamarin, Flutter and Rust, and also to server platforms like node.js and Java/Scala.

But all of the above have a key difference from the web.

The 3rd Dimension

The meta-platforms mentioned earlier are indeed competing against their host OSes in the race for capabilities, but unlike the web, they are not opinionated about trust and distribution — the 3rd dimension, that in my opinion is missing in the above graph.

Qt and Rust are good ways to create apps that are distributed via WebAssembly, downloaded and installed directly on the host OS, or administered through package managers like Cargo or Linux distributions like Ubuntu. React Native, Flutter and Xamarin are all decent ways to create apps that are distributed via app stores. node.js and Java services are usually distributed via a docker container, a virtual machine, or some other server mechanism.

Users are mostly unaware of what was used to develop their content, but are aware to some degree of how it is distributed. Users don’t know what Xamarin and node.js are, and if their Swift App was replaced one day by a Flutter App, most users wouldn’t and ideally shouldn’t care about it.

But users do know the web — they know that when they’re “browsing” in Chrome or Firefox, they are “online” and can access content they don’t necessarily trust. They know that downloading software and installing it is a possible hazard, and might be blocked by their IT administrator. In fact, it’s important for the web platform that users know that they’re currently “browsing the web”. That’s why, for example, switching to full-screen mode shows a clear prompt to the user, with instructions of how to get back from it.

The web has become successful because it’s not transparent — but clearly separated from its host OS. If I can’t trust my browser to keep random websites away from reading files on my hard-drive, I probably wouldn’t go to any website.

Users also know that their computer software is “Windows” or “Mac”, whether their phones are Android or iOS-based, and whether they’re currently using an app (when on iOS or Android, and on Mac OS to some degree). The OS and the distribution model are generally known to the user — the user trusts their OS and the web to do different things, and to different degrees of trust.

So, the web cannot be compared to cross-platform development frameworks, without taking its unique distribution model into account.

On the other hand, web technologies are also used for cross-platform development, with frameworks like Electron and Cordova. But those are not exactly “the web”. When compared to Java or node.js, The term “The web” needs to be substituted with “Web Technologies”. And “web technologies” used in this way don’t necessarily need to be standard-based or work on multiple browsers. The conversation about Fugu APIs is somewhat tangential to Electron and Cordova.

Native Apps

When adding capabilities to the web platform, the 3rd dimension — the trust and distribution model — cannot be ignored, or taken lightly. When the author claims that “Apple and Mozilla posturing about risks from new capabilities is belied by accepted extant native platform risks”, he is putting the web and native platforms in the same dimension in regards to trust.

Granted, native apps have their own security issues and challenges. But I don’t see how that’s an argument in favor of more web capabilities, like here. This is a fallacy — the conclusion should be fixing security issues with native apps, not relaxing security for web apps because they’re in a relevance catch-up game with OS capabilities.

Native and web cannot be compared in terms of capabilities, without taking the 3rd dimension of trust and distribution model into account.

App Store Limitations

One of the criticisms about native apps in the theory is about lack of browser engine choice on iOS. This is a common thread of criticism against Apple, but there is more than one perspective to this.

The criticism is specifically about Item 2.5.6 of Apple’s app store review guidelines:

“Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”

This might seem anti-competitive, and I do have my own reservation about how restrictive iOS is. But item 2.5.6 cannot be read without the context of the rest of the app-store review guidelines, for example Item 2.3.12:

“Apps must clearly describe new features and product changes in their ‘What’s New’ text.”

If an app could receive device access permissions, and then included its own framework that could execute code from any web site out there, those items in the app store review guidelines would become meaningless. Unlike apps, web sites don’t have to describe their features and product changes with every revision.

This becomes an even bigger problem when browsers ship experimental features, like the ones in project Fugu, which are not yet considered a standard. Who defines what a browser is? By allowing apps to ship any web framework, the app store would essentially allow the “app” to run any unaudited code, or change the product completely, circumventing the store’s review process.

As a user of both web sites and apps, I think both of them have space in the computing world, although I hope as much as possible could move to the web. But when considering the current state of web standards, and how the dimension of trust and sandboxing around things like Bluetooth and USB is far from being solved, I don’t see how allowing apps to freely execute content from the web would be beneficial for users.

The Pursuit Of Appiness

In another related blog post, the same author addresses some of this, when speaking about native apps:

“Being ‘an app’ is merely meeting a set of arbitrary and changeable OS conventions.”

I agree with the notion that the definition of “app” is arbitrary, and that its definition relies on whoever defines the app store policies. But today, the same is true for browsers. The claim from the post that web applications are safe by default is also somewhat arbitrary. Who draws the line in the sand of “what is a browser”? Is the Facebook app with a built-in browser “a browser”?

The definition of an app is arbitrary, but also important. The fact that every revision of an application using low-level capabilities is audited by someone that I might trust, even if that someone is arbitrary, makes apps what they are. If that someone is the manufacturer of the hardware I’ve paid for, it makes it even less arbitrary — the company that I’ve bought my computer from is the one auditing software with lower capabilities to that computer.

Everything Can Be A Browser

Without drawing a line of “what’s a browser”, which is what the Apple app store essentially does, every app could ship its own web engine, lure the user to browse to any website using its in-app browser, and add whatever tracking code it wants, collapsing the 3rd dimension difference between apps and websites.

When I use an app on iOS, I know my actions are currently exposed to two players: Apple & the identified app manufacturer. When I use a website on Safari or in a Safari WebView, my actions are exposed to Apple & to the owner of the top-level domain of the web site I’m currently viewing. When I use an in-app browser with an unidentified engine, I am exposed to Apple, the manufacturer of the app, and to the owner of the top-level domain. This can create avoidable same-origin violations, such as the owner of the app tracking all of my clicks on foreign websites.

I agree that perhaps the line in the sand of “Only WebKit” is too harsh. What would be an alternative definition of a browser that wouldn’t create a backdoor for tracking user browsing?

Other Criticism About Apple

The theory claims that Apple’s decline to implement features is not limited to privacy/security concerns. It includes a link, which does indeed show a lot of features that are implemented in Chrome and not in Safari. However, when scrolling down, it also lists a sizable amount of other features that are implemented in Safari and not in Chrome.

Those two browser projects have different priorities, but it’s far from the categorical statement “The game becomes clear when zooming out” and from the harsh criticism about Apple trying to cast the web in amber.

Also, the links titled it’s hard and we don’t want to try lead to Apple’s statements that they would implement features if security/privacy concerns were met. I feel that putting these links with those titles is misleading.

I would agree with a more balanced statement, that Google is a lot more bullish than Apple about implementing features and advancing the web.

Permission Prompt

Google goes long innovative ways in the 3rd dimension, developing new ways to broker trust between the user, the developer and the platform, sometimes with great success, like in the case of Trusted Web Activities.

But still, most of the work in the 3rd dimension as it relates to device APIs is focused around permission prompts and making them more scary, or things like time-box permission grants, and block-listed domains.

“Scary” prompts, like the ones in this example we see from time to time, look like they are meant to discourage people from going to pages that seem potentially malicious. Because they’re so blatant, those warnings encourage developers to move to safer APIs and to renew their certificates.

I wish that for device-access capabilities we could come up with prompts that encourage engagement and ensure that the engagement is safe, rather than discourage it and transfer the liability to the user, with no remediation available for the web developer. More on that later.

I do agree with the argument that Mozilla & Apple should at least try to innovate in that space rather than “decline to implement”. But maybe they are? I think isLoggedIn from Apple, for example, is an interesting and relevant proposal in the 3rd dimension that future device APIs could build upon — for example, device APIs that are fingerprinting-prone can be made available when the current website already knows the identity of the user.

WebUSB

In the next section I will dive into WebUSB, check what it allows, and how it’s handled in the 3rd dimension — what is the trust and distribution model? Is it sufficient? What are the alternatives?

The Premise

The WebUSB API allows full access to the USB protocol for device-classes that are not block-listed.

It can achieve powerful things like connecting to an Arduino board or debugging and Android phone.

It’s exciting to see Suz Hinton’s videos on how this API can help achieve things that were very expensive to achieve before.

I truly wish platforms found ways to be more open and allow quick iterations on educational hardware/software projects, as an example.

Funny Feeling

But still, I get a funny feeling when I look at what WebUSB enables, and the existing security issues with USB in general.

USB feels too powerful as a protocol exposed to the web, even with permission prompts.

So I’ve researched further.

Mozilla’s Official View

I started by reading what David Baron had to say about why Mozilla ended up rejected WebUSB, in Mozilla’s official standards position:

“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they’re connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent.”

The Current Permission Prompt

This is what Chrome’s WebUSB permission prompt looks like at the time of publishing this post:

Particular domain Foo wants to connect to particular device Bar. To do what? and how can I know for sure?

When granting access to the printer, camera, microphone, GPS, or even to a few of the more contained WebBluetooth GATT profiles like heart rate monitoring, this question is relatively clear, and focuses on the content or action rather than on the device. There is a clear understanding of what information I want from the peripheral or what action I want to perform with it, and the user-agent mediates and makes sure that this particular action is handled.

USB Is Generic

Unlike the devices mentioned above that are exposed via special APIs, USB is not content-specific. As mentioned in the intro of the spec, WebUSB goes further and is intentionally designed for unknown or not-yet-invented types of devices, not for well-known device classes like keyboards or external drives.

So, unlike the cases of the printer, GPS and camera, I cannot think of a prompt that would inform the user of what granting a page permission to connect to a device with WebUSB would allow in the content realm, without a deep understanding of the particular device and auditing the code that’s accessing it.

The Yubikey Incident And Mitigation

A good example from not too long ago is the Yubikey incident, where Chrome’s WebUSB was used to phish data from a USB-powered authentication device.

Since this is a security issue that is said to be resolved, I was curious to dive into Chrome’s mitigation efforts in Chrome 67, which include blocking a specific set of devices and a specific set of classes.

Class/Device Block-List

So Chrome’s actual defense against WebUSB exploits that happened in the wild, in addition to the currently very general permission prompt, was to block specific devices and device classes.

This may be a straightforward solution for a new technology or experiment, but will become harder and harder to accomplish when (and if) WebUSB becomes more popular.

I’m afraid that the people innovating on educational devices via WebUSB might reach a difficult situation. By the time they’re done prototyping, they could be facing a set of ever-changing non-standard block lists, that only update together with browser versions, based on security issues that have nothing to do with them.

I think that standardizing this API without addressing this will end up being counterproductive to the developers relying on it. For example, someone could spend cycles developing a WebUSB application for motion detectors, only to find out later that motion detectors become a blocked class, either due to security reasons or because the OS decides to handle them, causing their entire WebUSB effort to go to waste.

Security vs. Features

The platform adjacency theory, in some ways, considers capabilities and security to be a zero-sum game, and that being too conservative on security & privacy concerns would cause platforms to lose their relevance.

Let’s take Arduino as an example. Arduino communication is possible with WebUSB and is a major use case. Someone developing an Arduino device will now have to consider a new threat scenario, where a site tries to access their device using WebUSB (with some user permission). As per the spec, this device manufacturer now has to “design their devices to only accept signed firmware”. This can add burden to firmware developers, and increase development costs, while the whole purpose of the spec is to do the opposite.

What Makes WebUSB Different From Other Peripherals

In browsers, there is a clear distinction between user interactions and synthetic interactions (interactions instantiated by the web page).

For example, a web page can’t decide on its own to click a link on or wake up the CPU/display. But external devices can — for example, a mouse device can click a link on behalf of the user and almost any USB device can wake up the CPU, depending on the OS.

So even with the current WebUSB specification, devices can choose to implement several interfaces, e.g. debug for adb and HID for pointer input, and using malicious code that takes advantage of ADB, become a keylogger and browse websites on behalf of the user, given the right exploitable firmware flashing mechanism.

Adding that device to a blocklist would be too late for devices with firmware that was compromised using ADB or other allowed forms of flashing, and would make device manufacturers even more reliant than before on browser versions for security fixes associated with their devices.

Informed Consent & Content

The problem with informed consent and USB, as mentioned before, is that USB (specifically in the extra-generic WebUSB use-cases) is not content-specific. Users know what a printer is, what a camera is, but “USB” for most users is merely a cable (or a socket) — a means to an end — very few users know that USB is a protocol and what enabling it between websites and devices means.

One suggestion was to have a “scary” prompt, something along the lines of “Allow this web page to take over the device” (which is an improvement over the seemingly harmless “wants to connect”).

But as scary as prompts get, they cannot explain the breadth of possible things that can be done with raw access to a USB peripheral that the browser doesn’t know intimately, and if they did, no user in their right mind would click “Yes”, unless it’s a device that they fully trust to be bug-free and a website they truly trust to be up-to-date and not malicious.

A possible prompt like that would read “Allow this web page to potentially take over your computer”. I don’t think that a scary prompt like this one would be beneficial for the WebUSB community, and constant changes to these dialogs will leave the community confused.

Prototyping vs. Product

I can see a possible exception to this. If the premise of WebUSB and the other project Fugu APIs was to support prototyping rather than product-grade devices, all-encompassing generic prompts could make sense.

In order to make that viable, though, I think the following must happen:

  1. Use language in the specs that set expectations about this being for prototyping;
  2. Have these APIs available only after some opt-in gesture, like having the user enable them manually in the browser settings;
  3. Have “scary” permission prompts, like the ones for invalid SSL certificates.

Not having the above makes me think that these APIs are for real products rather than for prototypes, and as such, the feedback holds.

An Alternative Proposal

One of the parts in the original blog post that I agree with is that it’s not enough to say “no” — major players in the web world who decline certain APIs for being harmful should also play offense and propose ways in which these capabilities that matter to users and developers can be safely exposed. I don’t represent any major player, but I’m going to give it a humble go.

I believe that the answer to this lies in the 3rd dimension of trust and relationship, and that it’s outside the box of permission prompts and block-lists.

Straightforward And Verified Prompt

The main case I’m going to make is that the prompt should be about the content or action, and not about the peripheral, and that informed consent can be granted for a specific straightforward action with a specific set of verified parameters, not for a general action like “taking over” or “connecting to” a device.

The 3D Printer Example

In the WebUSB spec, 3D printers are brought as an example, so I’m going to use it here.

When developing a WebUSB application for a 3D printer, I want the browser/OS prompt to ask me something along the lines of Allow AutoDesk 3ds-mask to print a model to your CreatBot 3D printer?, be shown a browser/OS dialog with some print parameters, like refinement, thickness and output dimensions, and with a preview of what’s going to be printed. All of these parameters should be verified by a trusted user agent, not by a drive-by web page.

Currently, the browser doesn’t know the printer, and it can verify only some of the claims in the prompt:

  • The requesting domain has a certificate registered to AutoDesk, so there is some certainty that this is AutoDesk Inc;
  • The requested peripheral calls itself “CreatBot 3d printer”;
  • This device, device class and domain are not found in the browser’s block-lists;
  • The user responded “Yes” or “No” to a general question they were asked.

But in order to show a truthful prompt and dialog with the above details, the browser would also have to verify the following:

  • When permission is granted, the action performed will be printing a 3D model, and nothing but that;
  • The selected parameters (refinement/thickness/dimensions etc.) are going to be respected;
  • A verified preview of what is going to be printed was shown to the user;
  • In certain sensitive cases, an additional verification that this is in fact AutoDesk, maybe with something like a revokable short-lived token.

Without verifying the above, a website that was granted permission to “connect to” or “take over” a 3D printer can start printing huge 3D models due to a bug (or malicious code in one of its dependencies).

Also, an imagined full-blown web 3D printing capability would do a lot more than what WebUSB can provide — for example, spooling and queuing different print requests. How would that be handled if the browser window is closed? I haven’t researched all the possible WebUSB peripheral use-cases, but I’m guessing that when looking at them from a content/action perspective, most will need more than USB access.

Because of the above, using WebUSB for 3D printing will probably be hacky and short-lived, and developers relying on it will have to provide a “real” driver for their printer at some point. For example, if OS vendors decide to add built-in support for 3D printers, all sites using that printer with WebUSB would stop working.

Proposal: Driver Auditing Authority

So, overarching permissions like “take over the peripheral” are problematic, we don’t have enough information in order to show a full-fledged parameter dialog and verify that its results are going to be respected, and we don’t want to send the user on an unsafe trip to download a random executable from the web.

But what if there was an audited piece of code, a driver, that used the WebUSB API internally and did the following:

  • Implemented the “print” command;
  • Displayed an out-of-page print dialog;
  • Connected to a particular set of USB devices;
  • Performed some of its actions when the page is in the background (e.g. in a service worker), or even when the browser is closed.

An auditing of a driver like this can make sure that what it does amounts to “printing”, that it respects the parameters, and that it shows the print preview.

I see this as being similar to certificate authorities, an important piece in the web ecosystem that is somewhat disconnected from the browser vendors.

Driver Syndication

The drivers don’t have to be audited by Google/Apple, though the browser/OS vendor can choose to audit drivers on its own. It can work like SSL certificate authorities — the issuer is a highly trusted organization; for example, the manufacturer of the particular peripheral or an organization that certifies many drivers, or a platform like Arduino. (I imagine organizations popping up similar to Let’s Encrypt.)

It might be enough to say to users: “Arduino trusts that this code is going to flash your Uno with this firmware” (with a preview of the firmware).

Caveats

This is of course not free of potential problems:

  • The driver itself can be buggy or malicious. But at least it’s audited;
  • It’s less “webby” and generates an additional development burden;
  • It doesn’t exist today, and cannot be solved by internal innovation in browser engines.

Other Alternatives

Other alternatives could be to somehow standardize and improve the cross-browser Web Extensions API, and make the existing browser add-on stores like Chrome Web Store into somewhat of a driver auditing authority, mediating between user requests and peripheral access.

Summary Of Opinion

The author, Google and partners’ bold efforts to keep the open web relevant by enhancing its capabilities are inspirational.

When I get down to the details, I see Apple and Mozilla’s more conservative view of the web, and their defensive approach to new device capabilities, as carrying technical merit. Core issues with informed consent around open-ended hardware capabilities are far from being solved.

Apple could be more forthcoming in the discussion to find new ways to enable device capabilities, but I believe this comes from a different perspective about computing, a standpoint that was part of Apple’s identity for decades, not from an anti-competitive standpoint.

In order to support things like the somewhat open-ended hardware capabilities in project Fugu, and specifically WebUSB, the trust model of the web needs to evolve beyond permission prompts and domain/device block-lists, drawing inspiration from trust ecosystems like certificate authorities and package distributions.

Further Reading on SmashingMag:

Articles on Smashing Magazine — For Web Designers And Developers

1-xkcd-here-to-help-algorithm-webcomic
01 May

Readability Algorithms Should Be Tools, Not Targets

by TBSCategories: News

Readability Algorithms Should Be Tools, Not Targets

Readability Algorithms Should Be Tools, Not Targets

Frederick O’Brien

The web is awash with words. They’re everywhere. On websites, in emails, advertisements, tweets, pop-ups, you name it. More people are publishing more copy than at any point in history. That means a lot of information, and a lot of competition.

In recent years a slew of ‘readability’ programs have appeared to help us tidy up the things we write. (Grammarly, Readable, and Yoast are just a handful that come to mind.) Used everywhere from newsrooms to browser plugins, these systems offer automated feedback on how writing can be clearer, neater, and less contrived. Sounds good right? Well, up to a point.

xkcd webcomic about algorithms
As with most things, there’s an xkcd comic for this. (Large preview)

The concept of ‘readability’ is nothing new. For decades researchers have analyzed factors like sentence length, syllable count, and word complexity in order to ‘measure’ language. Indeed, many of today’s programs incorporate decades-old formulas into their scoring systems.

The Flesch-Kincaid system, for example, is a widely used measure. Created by Rudolf Flesch in 1975, it assigns writing a US grade level. The Gunning fog index serves a similar purpose, and there are plenty more where they came from. We sure do love converting things into metrics.

It’s no mystery why formulas like this are (quite rightly) popular. They help keep language simple. They catch silly mistakes, correct poor grammar, and do a serviceable job of ‘proofreading’ in a pinch. Using them isn’t a problem; unquestioning devotion to their scores, however, is.

No A-Coding For Bad Taste

I want to tread carefully here because I have a lot of time for readability algorithms and the qualities they tend to support — clarity, accessibility, and open communication. I use them myself. They should be used, just not unquestioningly. A good algorithm is a useful tool in the writer’s proverbial toolbox, but it’s not a magic wand. Relying on one too heavily can lead to clunkier writing, short-sightedness, and, worst of all, a total uniformity of online voices.

One of the beauties of the internet is how it melts national borders, creating a fluid space for different cultures and voices to interact in. Readability historically targets academic and professional writing. The Flesch-Kincaid test was originally developed for US Navy technical manuals, for example. Most developers can appreciate the value of clear documentation, but it’s worth remembering that in the world of writing not everything should sound like US Navy technical manuals. There are nuances to different topics, languages, and cultures that monosyllabic American English can’t always capture.

Deference to these algorithms can take writers to absurd lengths. Plain English is one thing, but unquestioning obedience is another. I’ve seen a good few sentences butchered into strings of words that tick readability boxes like ‘write in short sentences’ and ‘use monosyllabic words wherever possible’, but border on nonsensical to the human eye. It’s a near-impossible thing to quantify, but it has been a recurring phenomenon in my own work, and having spoken with other copywriters and journalists I know it’s not just my rampant paranoia at work.

Let’s look at the limitations of these tools. When faced with some of the greatest writers of all time — authors, journalists, copywriters, speech writers — what’s the verdict? How do the masters manage?

  • A Tale of Two Cities by Charles Dickens.
    The opening chapter receives a grade of E from Readable.
  • George Orwell’s essay ‘Politics and the English Language’, which bemoans how unclear language hides truth rather than expresses it. He gets a grade of D. Talk about having egg on your face!
  • The beginning of The Old Man and the Sea by Ernest Hemingway does tolerably well in the Hemingway Editor, though you’d have to edit a lot of it down to appease it completely.

A personal favorite that came up here was Ernie Pyle, one of the great war correspondents. His daily columns from the front lines during World War II were published in hundreds of newspapers nationwide. One column, ‘The Death of Captain Waskow’, is widely regarded as a high watermark of war reporting. It receives a grade of B from Readable, which notes the writing is a tad ‘impersonal.’ Have a read and decide for yourself.

War correspondent Ernie Pyle during World War II
Impersonal war correspondent Ernie Pyle. Credit: Indiana University. (Large preview)

Not all copywriting is literary of course, but enjoyable writing doesn’t always have to please readability algorithms. Shoehorning full stops into the middle of perfectly good sentences doesn’t make you Ernest Hemingway. I’m an expert in not being as good as Ernest Hemingway, so you can trust me on that.

Putting Readability Into Context

None of this is supposed to be a ‘gotcha’ for readability algorithms. They provide a quick, easy way to identify long or complex sentences. Sometimes those sentences need editing down and sometimes they’re just fine the way they are. That’s at the author’s discretion, but algorithms speed up the process.

Alternatively, if you’re trying to cut down on fluffy adverbs like ‘very’ you can do a lot worse than turning to the cold, hard feedback of a computer. Readability programs catch plenty of things we might miss, and there are plenty of examples of great writing that would receive suitably great scores when put through the systems listed above. They are useful tools; they’re just not infallible.

Algorithms can only understand topics within the confines of their system. They know what the rules are and how to follow them. Intuition, personal experience, and a healthy desire to break the rules remain human specialties. You can’t program those, not yet anyway. Things aren’t the done thing until they are, after all.

It’s a fine line between thinking your writing has to be clear, and thinking your readers are stupid. You stop seeing the woods for the trees. Every time I hear that the ‘ideal’ article length is X words regardless of the topic or audience, or that certain words should always be used because they improve CTR by 0.06%, I want to gauge my eyes out. Readability algorithms can make sloppy writing competent, but they can’t make good writing great.

Remember, when all is said and done, copy is written for people. From an SEO perspective, Google itself has made it clear in the past that readability should match your target audience. If you’re targeting a mass audience that needs information in layman’s terms, great, do that. If you produce specialized content for experts in a certain field then being more specialized is perfectly appropriate.

As Readable has itself explored, readability can be a kind of public good. Easy to read newspapers spread information better than obtuse ones do. Textbooks written for specific age groups teach better than highly technical ones do. In other words, understand the context you are writing in. Just remember:

“When a measure becomes a target, it ceases to be a good measure.”

— Goodhart’s Law

Find Your Voice

I have no beef with readability algorithms. My problem is with the laziness they can enable, the thoughtlessness. Rushing out a draft and running it through a readability tool is not going to improve your writing. As with any skill worth developing you have to be willing to put the hours in. That means going a step or two beyond blindly appeasing algorithms.

Not everyone has a luxury of a great editor, but when you work with one, make full use of the opportunity. Pay attention to their suggestions, ask yourself why they made them. Ask questions, identify recurring problems in your writing and work to address them.

Analyse how the algorithms themselves work. If you’re going to use readability systems they should be supplemental to a genuine search for your own voice. Know how the things calculate scores, what formulas they’re drawing from. Learn the rules yourself. By doing so you earn the knowledge required to break them.

In his aforementioned essay George Orwell offers up his own approach to rules:

  1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  2. Never use a long word where a short one will do.
  3. If it is possible to cut a word out, always cut it out.
  4. Never use the passive where you can use the active.
  5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  6. Break any of these rules sooner than say anything outright barbarous.

These are founded on solid principles applicable to the web. Where did those principles come from? Not computers, that’s for sure.

Real editors and honest self-reflection do a lot more for your writing ability long term than obeying algorithms does. It all feeds back into your communication, which is an essential skill whether you’re a copywriter, a developer, or a manager. Empathy for other people’s work improves your own.

There is another essential thing good writers do: they read. No algorithm can paper over the cracks of an unengaged mind. Whatever your interests are I guarantee there are people out there writing about it beautifully. Find them and read their work, and find the bad writing too. That can be just as educational.

If you’re so inclined, you may even decide to get all meta about it and read about writing. If you’re not sure where to start, here are a handful of suggestions to get the ball rolling:

Also keep in mind that readability is not just a question of words. Design is also essential. Layout, visuals, and typography can have just as much impact on readability as the text itself. Think about how copy relates to the content around it or the device it’s being read on. Study advertising and newspapers and branding. On the other side of that sprawling jungle is your voice, and that’s the most valuable thing of all.

To reiterate one last time, readability algorithms are handy tools and I wholeheartedly support using them. However, if you’re serious about making your copy ‘compelling’, ‘informative’, or even (shudder) ‘convert’, then you’re going to have to do a lot more besides. The best writers are those algorithms are trying to imitate, not the other way around.

Whoever you are and whatever your discipline, your writing deserves attention. Whether it’s website copy, technical guides, or marketing material, developing your voice is the best way to communicate the things most important to you. By all means, use the tools at your disposal, but just don’t phone it in.

Smashing Editorial (ra, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers

zillow-mobile-website-2020
31 Mar

What Should You Do When A Web Design Trend Becomes Too Popular?

by TBSCategories: News

What Should You Do When A Web Design Trend Becomes Too Popular?

What Should You Do When A Web Design Trend Becomes Too Popular?

Suzanne Scacca

I read an interesting article on Forbes recently about language saturation. Here’s the problem:

Consumers don’t always understand the technicalities of what businesses do or the solutions they’ve created for them. So, copywriters use jargon that translates something like “Internet-connected devices with computing capabilities” into “smartphones”, “smart watches” and “smart speakers”.

Some of these buzzwords spread like wildfire and it soon becomes impossible to find a brand or website that doesn’t use them. When that happens, the words — and the associated product or service — become meaningless in the minds of consumers because everyone is saying the same thing.

The same thing happens when design trends become too popular. This is something Vitaly Friedman talked about last year with regards to cookie consent notices and banner blindness.

But what choice do you have? Are you supposed to hop on the design bandwagon anyway so your website doesn’t get left behind? Today, we’re going to look at what your options are.

To be clear, I’m not suggesting that you ignore any and all rising design trends.

There are certain trends that we absolutely need to adopt across the board. Like minimalism and mobile-first design. When there’s substantial, quantifiable proof that a design technique is needed, please don’t ignore it.

What I’m talking about are design trends that aren’t aimed at strengthening the web. Instead, they’re solely about driving up engagement on websites.

Brutalism. Facebook Messenger pop-ups. Home page hero sliders. The second that popular websites begin to adopt these trends and once writers and designers start including them in design trend roundups, it’s only a matter of months before consumers are inundated with them. And this is when banner blindness kicks in.

So, what are your options when you learn about a new design trend that promises big results?

Option 1: Ignore It and Stick with What Works

There are a few reasons you should consider going with this option:

You work on short-term website projects.

For those of you who build websites, hand them over to clients and then wish them luck as you move onto the next, it’s probably not a good idea to play around with fad-like design trends.

You know how quickly design trends change, so why put your client in a position where they have a website with an outdated design? One of three things is going to happen:

  1. They’ll leave the outdated feature as is and have no idea that it’s costing them conversions.
  2. They’ll ask you for help in removing the feature not too long after launch and won’t be happy about needing a rework so soon.
  3. They’ll ask another designer for help because they’re upset you put them in this less than ideal position.

Unless your client has a very good reason why they need to exploit a passing design trend, try to dissuade them from it. If they understand the fleeting nature of some of these trends, as well as how banner blindness develops from oversaturation, they should be onboard with you sticking to what works.

You’re designing (or redesigning) a site for a very well-established company.

When building a website for a company that has a long-standing reputation with its audience as well as a tried-and-true formula for success, adopting a passing trend could be risky.

Take Zillow, for example.

Zillow homepage on mobile
The homepage for Zillow on mobile (Image source: Zillow) (Large preview)

This is the mobile homepage as it stands today. It’s simple, sleek and intuitive by nature.

Can you imagine what would happen if the designer decided to add a video background to the hero banner? Or to interrupt the property browsing experience with a pop-up advertising a free ebook download?

You have to really think about what disruptions to the expected design would do to the flow of things. So, when building something for a brand that’s known for its consistency and convenience, it’s best to ignore passing trends.

This doesn’t mean that a website like this shouldn’t be redesigned. Like I said before, lasting design “trends” can’t be ignored as they enable us to move websites in the right direction (like responsive design). For example, this was Zillow in 2017:

Zillow mobile homepage in 2017
The mobile homepage for the Zillow website in 2017 (Image source: Zillow) (Large preview)

See how far we’ve come in terms of making websites mobile responsive and mobile-first in just a few years? These are the kinds of popular changes that don’t require debating.

The company’s goal is to build relationships; not to increase sales.

I realize that every website needs conversions in order to survive. However, many business models can’t sustain with just one-off sales. It costs too much money to constantly market to new customers, which is why some businesses focus on building long-term relationships with their customer base.

And that’s why you need to steer clear of conversion-boosting design trends on these kinds of websites.

Take, for instance, Gary Vaynerchuk’s website:

Gary Vaynerchuk mobile site
The mobile website for Gary Vaynerchuk is free of passing design trends and elements. (Source: Gary Vaynerchuk) (Large preview)

Remember when every website seemed to have a pop-up containing two buttons — one of which would be super-positive like “Yes, I want to change my life!” and the other which was meant to shame the visitor with something like “No, I like living in squalor.”

How do you think Vaynerchuk’s always-growing loyal following would feel if the site displayed one of those pop-ups? Not only would they be annoyed by the disruption keeping them from the content, but they’d probably be upset that he’d use such a shameless ploy to bully them into signing up.

If the brand you’re building a website for is on a similar mission — to build long-lasting and meaningful relationships — you don’t want to sully that with bad design decisions.

Option 2: Adopt the Trend But Keep an Eye on Market Saturation

Patrick Ward, the author of the Forbes article mentioned above, explained that many writers in the fintech space have had to pivot towards a simpler style of writing:

“At first, new startups used jargon and buzzwords to highlight their brand new tech and give themselves a competitive edge.”

I think this is a good lesson for designers as well. It’s not always a bad thing to hop on a design trend’s bandwagon — especially if it’s proven to work and it’s still in the very early stages of public awareness.

So, while there are clear cases where it makes sense to avoid design fads, I think there are times when it makes sense to take advantage of them. The only thing is, you can’t just implement the design and then leave it be.

For instance, this is the 15 Finches website on desktop:

15 Finches website animation
A walk-through of the animation on the 15 Finches website on desktop. (Source: 15 Finches) (Large preview)

Now let’s compare this same animated experience to what users get on their mobile devices:

15 Finches mobile website
A walk-through of the 15 Finches website on mobile with layering errors and no animation. (Source: 15 Finches)(Large preview)

There are a number of design choices made on this mobile site that should’ve been long phased out.

  1. The vertical typography in the background should go. It might add texture to the desktop site, but it’s just a confusing distraction on mobile.
  2. The animation on the desktop site doesn’t translate to mobile. To present visitors with a consistent experience, the designer should commit to mobile-first design.
  3. There are also layering errors all over the mobile site, with text often covering other bits of text as well as missing call-to-action buttons.

As I said, there are some sites where it’s okay to adopt short-term design trends. Just keep an eye on them.

For example, the Hubspot site design is always changing, but any design trends it adopts never seem to overstay their welcome. Hubspot tends to cut out just before they become too much. And that’s a key thing to remember.

Hubspot mobile site with chatbot widget
Hubspot’s mobile site continues to use a chatbot widget to guide prospective customers in the right direction. (Image ource: Hubspot) (Large preview)

As you can see, the mobile site still uses a chatbot widget. For a business that sells sales and marketing software, it’s an important element to retain even if other sites have since ditched theirs.

That said, I’m positive that Hubspot keeps close tabs on its user data so it probably has confirmation that the element continues to work well. This is just one of the things you should be mindful of when monitoring a trend.

If you want to utilize popular design trends, you need to be in it for the long haul with your clients. That way, the second you start to notice:

  • Oversaturation in the market,
  • The trend has gone completely stale,
  • Or your users aren’t responding positively to it.

You can immediately move the website to safer ground.

Option 3: Go in a Similar But Different Direction

When a design technique or element immediately and universally becomes popular, there’s more value to it than just its ability to increase conversions or create a prettier design.

Take a look at why it’s caught on the way it has. If you understand what’s driving the popularity of the fad, you can leverage the strongest parts of it, make it your own and have something with real staying power.

Do you remember the New York Times’ Snow Fall article in 2012? This was shortly after parallax scrolling started to pick up speed in web design. And despite some websites utilizing the trend, it was the way the NYT creatively integrated it along with interactive and animated images that really blew people away — so much so that it won a number of journalism awards for it.

Notice that the NYT didn’t try to redesign its website with parallax scrolling or interactivity. It took the basic principles gaining in popularity and applied it to one groundbreaking story. By considering how the trend could be best used for maximum impact, the NYT turned a short-term fad into something that would make its story memorable.

If you understand what’s driving the popularity of the fad, you can leverage the strongest parts of it, make it your own and have something with real staying power.

“

Let’s take a look at a more recent example of a site using this approach.

You’re all familiar with the trend of split-screen design, right? It worked really well on desktop, both in its static form as well as when one half of the screen would remain put while the other moved. But on mobile? It wasn’t so great.

While we’ve seen a lot of split screen designs get phased out, EngineThemes has made the trend its own:

EngineThemes mobile site with split screen design
EngineThemes has put a playful twist on the once-trendy split screen design. (Source: EngineThemes) (Large preview)

Upon entering the site, it’s a look we’re familiar with as consumers. But it doesn’t take long to realize that this is going to be a different experience.

For starters, the bobbing bird and red double-headed arrow are something you don’t see much of, if at all, on other sites. I can’t imagine many visitors scroll past this banner without engaging with it.

Secondly, there are no words in this banner on mobile. (There are on the desktop website.)

One of the reasons why this design trend doesn’t work anymore is because it can’t be used on mobile sites — there just isn’t enough space to split the screen and fit enough words in there. Or is there?

EngineThemes hidden message to mobile visitors
EngineThemes has hidden a message in its animated, split screen graphic. (Image source: EngineThemes) (Large preview)

Eagle-eyed visitors will notice that there’s a message carefully hidden in the bird graphic when the arrow is moved to the right. Granted, the text should be bigger, but mobile visitors can zoom in if they’re struggling to read it.

It’s a string of code that reads:

"EngineThemes provides effective business solutions with simple and powerful WordPress app themes."

But do you see what I mean? When a design trend suddenly becomes popular — for a short or long while, too — it doesn’t necessarily mean you need to use the same exact version of it like everyone else. This is why oversaturation quickly turns once great-looking websites stale.

By taking what’s so innovative about a design trend and making it your own, though, you can give the trend real staying power while making your site a standout in the process.

Wrapping Up

When we overdo it by leveraging the same design trends as everyone else, we put our websites at risk of becoming redundant or, worse, invisible. So, how do we establish a cutting edge if we can’t make use of design “jargon”?

The truth is, there’s no one clear-cut answer. You need to be able to read the room, so to speak, and figure out which approach is best for you. You could leave the passing trend alone, you could adopt it temporarily or you could make it your own.

Further Reading on SmashingMag:

Smashing Editorial (ra, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
1-designers-learn-to-code-terminal-and-text-editors-4
26 Mar

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

by TBSCategories: News

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

Paul Hanaoka

As a designer with many years of experience, I often encourage my colleagues and reports to pick up some coding skills. While many are open to the idea, others balk at the notion. I usually hear some variation of “I didn’t study design to become a developer.” Although this is a valid concern, I’d like to emphasize two points: a better understanding of the materials usually leads to better outcomes, and there is an important distinction between “coding” and “software engineering.”

This two-part series of articles should be useful for any designers out there who’d like to gain also some coding skills.

Understanding The Raw Materials

Contrary to what some may think, design isn’t about creating beautiful mockups, it’s about delivering an intuitive, functional experience to the end user. That simply can’t be done without an understanding of the building blocks of a solution. An architect isn’t going to be very good at her job if she doesn’t understand the materials her plans demand and a designer isn’t going to be very good if he doesn’t understand the materials that make his designs come to life — the code. Experience with coding helps designers understand what’s possible and what’s not and whether or not their designs will be able to effectively perform their desired functions.

I also reassure my colleagues that knowledge of coding doesn’t mean one has to become an engineer. The two refer to different, though related, skill sets. As Kyle Thayer, a PhD candidate at the University of Washington recently wrote, the field of computer science (or engineering) is about giving students “an overview of the scientific field of computing”:

“The purpose of a Computer Science degree is to give students an overview of the scientific field of computing. While this includes some programming, programming is done primarily for the purpose of learning about other areas (e.g., operating systems, algorithms, machine learning, human-computer interaction). A CS degree is a good first step into the academic field of computer science.”

— Kyle Thayer

By contrast, coding simply means becoming familiar enough with a given programming language to complete a task. Asking someone to learn basic HTML or JavaScript does not necessitate their becoming a full-stack software architect. Despite what some might think, forking a repo and copy/pasting Stack Overflow answers in does not make you a software engineer — but it can increase the value you bring as a designer to a product development team.

What About “Low Code”?

Some may say that we’re entering a low code future where designers (and developers) are able to build applications through drag-and-drop functionality and a GUI (graphical user interface). So taking the time to learn a programming language isn’t “worth it.” The emergence of tools like Webflow, Modulz, FramerX, UXPin, etc., seems to support this line of reasoning. And this can be very true for many applications — it’s easier than ever to create a site or app without a single line of code. However, if you don’t understand the underlying principles, you will be capping the value you can deliver with a low code application.

Logos and screenshots showing the code behind tools developed by companies like Modulz, Studio.Design, FramerX, and others.
Modulz, Studio.Design, FramerX, and other apps — there’s still a lot of code in there… (Large preview)

We’re also not yet at the point where you can build enterprise-scale applications with low code platforms. As designers we have to work in the world we live in, not the one we imagine is coming.

That being said, everyone brings a unique blend of skills to the table. Knowledge of code is not an absolute necessity and it should just be encouraged, not required.

Where To Start?

There is an endless amount of tools, languages, schools, guides, and other resources available for anyone who has access to the internet — so where to begin? An important disclaimer — I am by no means an expert, or anything close to a software engineer — and the following are insights from my personal experience, not a guaranteed path to success.

Many of the designers/developers I know have usually started hacking HTML and CSS templates on sites like MySpace, Geocities, Tumblr, Neopets, or others. Now that I have sufficiently dated myself, for anyone starting out today, I would recommend beginning in your friendly command-line interface (CLI) shell.

The Terminal: An Essential Tool

The go-to application for Hollywood directors whenever there’s a computer hacker on the screen, the terminal is simply an interface that allows you to execute actions via a text input rather than the graphical user interface (GUI) that most people are accustomed to. I’ll let real developers explain the intricacies and technical how-to, but for our purposes it’s good enough to know that familiarizing yourself with the CLI is beneficial for a number of reasons.

The terminal gives you access to your computer’s file and folder structure — the same way that you click through Finder or Explorer, you navigate using your keyboard in the terminal. It definitely takes some time getting used to, but developing your mental model in this area is foundational to working in code.

Like a lot of designers, I am using the macOS environment (formerly known as OS X), but the following applies to other *nix operating systems (Linux, Unix), and also to Windows PowerShell. While there is a lot of overlap between different modern operating systems, there are some differences that I will do my best to highlight.

Note: For a more complete introduction to the terminal, I recommend reading Paul Tero’s article, “Introduction To Linux Commands”.

Regular Expressions

A key feature in a CLI is the ability to use regular expressions (regex) in your commands. Think of regex as boolean search operations (using quotation marks to search for exact phrases or the minus sign to exclude words) on steroids — they allow you to define a pattern in a string of text so that you can perform some action on the output. Here are some real-world examples:

  1. If you have a long list of phone numbers in a variety of formats, you could define a script that would give you a consistent output based on a regular expression — e.g.: (###) ###-#### for the U.S. phone numbers format.
  2. If you want to quickly rename a group of files to a specific case — from kebab-case to CamelCase or anything in between.

I highly recommend watching Wes Bos’ Command Line Power User series — or at the very least his intro video which will give you a good idea about a few essentials commands that you can use.

Here are some basic terminal commands* to help you getting started:

  1. cd stands for “Change Directory”, type this and then a file or a folder path to go — note that you can type a folder name but it needs to be inside your current folder to go to it.
  2. ls lists the files and folders in your current folder.
  3. pwd stands for “Print Working Directory” — this will list out where you currently are in your computer.
  4. mkdir and a folder name will create a folder in your working directory.
  5. using cd with .. takes you one level up — if you’re in /users/username/documents/2019 and you enter cd ../.. you’ll end up in /users/username.
  6. Bonus tip — hitting the Tab key will autocomplete as you type a folder/file path.

Note: The following will work on the Windows command line (cmd):

  • cd, cd .., mkdir, Tab key for path autocomplete (ls and pwd won’t work).

The more modern Windows command line (Windows PowerShell) supports all of them:

  • cd, cd .., ls, pwd, mkdir, and Tab for path autocomplete.

For a complete list of commands available in PowerShell, check this Microsoft’ Help page “Using Familiar Command Names”.

Mass-File Management

You can manipulate files and folders en masse via the terminal — here are a few ideas:

  1. You can create three years of folders with subfolders for each month in a single command — using mkdir -p and {list-of-years}/{list-of-months} will create folders for each year with subfolders for each month. Use your imagination, I’m sure you can put this to good use!
  2. You can quickly clean up your desktop by using mv Screen Shot* Screenshots — this will move all of your files that start with “Screen Shot” to a folder named “Screenshots”.
A screenshot of a terminal window showing the commands and output of a folder creation script.
Create 36 folders on your computer with a single line of code! (Large preview)

Note: These two examples will most likely only work in *nix environments — but the theory still applies. And Windows PowerShell is also a very powerful command line tool, you just need to learn its features and specific commands.

Scripting And Maintenance

Now that we have a glimpse into the power of regular expressions and the options available in the terminal we can start combining those things into scripts. One very simple, yet powerful and commonly used script is Mike G’s file renamer:

criteria=$ 1  re_match=$ 2  replace=$ 3  for i in $ ( ls *$ criteria* );   do      src=$ i      tgt=$ (echo $ i | sed -e "s/$ re_match/$ replace/")      mv $ src $ tgt  done

What this script allows you to do, is define the scope (criteria), define what you’d like to change (re_match), and what you’d like to change it to (replace) — and then execute it.

There are countless other scripts that you can create beyond creating and renaming files — Vlad’s Batch Resizing script is an excellent example of the time-saving capabilities that you can create using bash scripts.

Advanced Tips And Tricks

Something I have found over the years is that regularly resetting my computer and reinstalling the operating system helps it stay relatively clutter-free and prevents the slowdowns everyone experiences after years of digital detritus that accumulates on harddrives. For many, the prospect of wiping a computer and re-setting everything back at best sounds like a few days of work, and at worst an impossible nightmare that you may never recover from.

But it doesn’t have to be — by using a few command-line tools, once you’ve backed up, wiped, and reinstalled your OS, you can install not only your list of favorite apps, but also fonts in a matter of minutes using Homebrew. (Homebrew is for Mac and Linux only. For Windows, try Chocolatey which is a solid alternative.)

If you’re interested — we’ve created an easy-to-follow setup guide to get your computer in good shape for most development. Our guide is for macOS, but Owen Williams has written a solid guide for Windows as well.

If you don’t have the time for Wes’ entire series of tutorials about the command line — at the very least I highly recommend the following stack:

  1. Oh My ZSH
  2. zsh-autosuggestions
  3. zsh-syntax-highlighting
  4. z-jump-around

Choosing A Text Editor

There are many options when it comes to choosing a code editor — Sublime Text and VS Code (Visual Studio Code) are the two I have the most experience with and am currently using.

Sublime Text was one of the earlier text editors that became popular with front-end developers — it was the gold standard up until a few years ago. Features like multiple cursors, a powerful package manager, and highly customizable shortcuts that allowed you to quickly navigate in and between files and folders. Not to mention it was an incredibly lightweight and fast application which made it an easy choice.

VS Code (Visual Studio Code) came on the scene around 2015, it took a while for people to switch from Atom and Sublime, but VS Code has established itself as many developers’ favorite editor. In addition to pretty much all of Sublime’s features, VS Code differentiated itself with a built-in terminal and tight integration with Git. In addition, Visual Studio Code has a rich plugin ecosystem that allows you to extend and customize your environment to your heart’s delight.

All that is to say — you don’t need to be a developer to appreciate the features of a good code editor. I have found many uses for it in my daily work; two, in particular, are the ability to use multiple cursors, and using regex to find-and-replace text across folders of files. Let’s take a closer look at both.

Editing With Multiple Cursors

Picture your typical word processor — that blinking vertical line that shows where the text you’re entering will go? Now picture the ability to add more than one cursor to this window so that whatever you type will appear wherever there is a cursor!

This might not be blowing your mind just yet — so here’s an example that shows a few ways that an advanced text editor can help you create everyday efficiencies in your workflow.

A screencap showing a list of names being manipulated and turned into a list of email addresses.
Mass-editing in a text editor is much faster and more intuitive than in a spreadsheet. (Large preview)

Here we have a list of names that we need to convert into email addresses — we’d also like to make them all lowercase and then sort them alphabetically. This can be done with a few keystrokes.

Using a text editor to quickly manipulate lots of text in Sublime Text (short video).

Once you paste the list in, Cmd + Shift + P brings up the Command Palette (fancy term for a searchable menu that gives you all the available functionalities). You can basically type in this menu what you want to do, pretty much anything you can do to text is available here. If it’s not, there’s likely a plugin or an extension that you can find.

We’re able to change the case and sort the lines in a matter of seconds — then pressing Ctrl + Shift + arrow keys adds cursors, then whatever we type gets added to every line — in this case, we’re turning the names into email addresses, but your wild imagination could find myriad other ways to use this.

You might be saying — well I can do this in Excel or Google Sheets, which is true, but I have found that it is a lot quicker to handle these types of things in a text editor. You avoid having to write formulas and select things with a mouse.

Which Code Editor Should I Use?

I’m a designer — so of course, my answer is “it depends”.

  • If you’re new to these concepts, I would recommend getting a free trial of Sublime — it continues to be a very lightweight app and does not consume too many system resources. You can customize Sublime’s key bindings (fancy word for hotkeys) and extend its built-in functionality with plugins.
  • If you’ve been using Sublime, Atom, or another editor — I’d recommend checking out VS Code as well. The team at Microsoft has really done an excellent job making it a powerful, yet easy-to-use text editor.

Personally, I use both editors — Sublime is lightning quick and opens in a fraction of a second allowing me to easily paste and manipulate text. But when I want to get some more serious work done, I use VS Code. It’s difficult to top the all-in-one package that VS Code provides — a vibrant plugin and extension ecosystem, powerful command palette, and hyper-customizable interface means you can really make it your own. Not to mention the fact that Microsoft is very incentivized to ensure that it’s a first-class experience for developer productivity.

Conclusion, And What’s Next?

In this first article, you will have learned the basics of the terminal, a few productivity hacks to get you started, and should have a better idea of what code editor to choose. In the next part, we’ll continue with the topics of version control, HTML and CSS, and an introduction to engineering principles.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
1-git-hmtl-css-engineering-principles
25 Mar

How Should Designers Learn To Code? Git, HTML/CSS, Engineering Principles (Part 2)

by TBSCategories: News

How Should Designers Learn To Code? Git, HTML/CSS, Engineering Principles (Part 2)

How Should Designers Learn To Code? Git, HTML/CSS, Engineering Principles (Part 2)

Paul Hanaoka

Literally, tomes have been written on version control. Nevertheless, I will start by sharing a brief explanation and other introductory content to whet your appetite for further study.

Version control (not to be confused with version history) is basically a way for people to collaborate in their own environments on a single project, with a single main source of truth (often called the “master” branch).

I’ll go over today is the bare minimum you’ll need to know in order to download a project, make a change, and then send it to master.

There are many types of version control software and many tools for managing and hosting your source code (you may have heard of GitLab or Bitbucket). Git and GitHub are one of the more common pairs, my examples will reference GitHub but the principles will apply to most other source code managers.

Aside:

Collecting Data, The Powerful Way

Did you know that CSS can be used for collecting statistics? Indeed, there’s even a CSS-only approach for tracking UI interactions using Google Analytics. Read a related article →

Your First Contribution

Before doing these steps, you’ll need a few things set up:

  1. A GitHub account,
  2. Node and NPM installed on your computer,
  3. A high tolerance for pain or a low threshold for asking others for help.

Step 1: Fork (Get A Copy Of The Code On Your GitHub Account)

On GitHub, you will fork (fork = create a copy of the code in your account; in the following illustration, the blue, orange, red, and green lines show forks) the repository (repo) in question.

By creating branches off of the master, it’s possible for multiple people to contribute to different areas of a project and then merge their work together. (Large preview)

You do this by navigating to the repo in GitHub and clicking the “Fork” button, currently at the top right-hand corner of a repo. This will be the “origin” — your fork on your GitHub account.

As an example, navigating to https://github.com/yourGitHubUsername/liferay.design should show your fork of the Liferay.Design repo.

This is victorvalle’s GitHub fork. (Large preview)

Step 2: Clone (Download The Code To Your Computer)

In your terminal, navigate to where you’d like to store the code. Personally, I have a /github folder in my /user folder — it makes it easier for me to organize it this way. If you’d like to do that, here are the steps — after typing these commands into your terminal window, press the ↵ key to execute:

cd ~/             ## you'll usually start in your root directory, but just in case you don't this will take you there mkdir github      ## this creates a "github" folder — on OSX it will now be located at users/your-username/github cd github         ## this command navigates you inside the github folder

Now that you’re in the /github folder, you will clone (download a copy of the code onto your computer) the repo.

clone https://github.com/yourGitHubUsername/liferay.design

Once you enter this command, you’ll see a bunch of activity in the terminal — something like this:

Cloning into 'liferay.design'... remote: Enumerating objects: 380, done. remote: Total 380 (delta 0), reused 0 (delta 0), pack-reused 380 Receiving objects: 100% (380/380), 789.24 KiB | 2.78 MiB/s, done. Resolving deltas: 100% (189/189), done.

Step 3: Install (Get It Running On Your Machine)

Navigate into the /project folder. In this case, we’ll enter cd liferay.design. Most projects will include a README.md file in the /root folder, this is typically the starting place for installing and running the project. For our purposes, to install, enter npm install. Once it’s installed, enter npm run dev.

Congratulations! You now have the site available on your local computer — typically projects will tell you where it’s running. In this case, open up a browser and go to localhost:7777.

Step 4: Commit (Make Some Changes And Save Them)

A commit is a collection of changes that you make; I’ve heard it described as saving your progress in a game. There are many opinions on how commits should be structured: mine is that you should create a commit when you’ve achieved one thing, and if you were to remove the commit, it wouldn’t completely break the project (within reason).

If you aren’t coming to a repo with a change in mind, a good place to go is the ‘Issues’ tab. This is where you can see what needs to be done in the project.

If you do have an idea for some change, go ahead and make it. Once you’ve saved the file(s), here are the steps required to create a commit:

git status                                         ## this will print out a list of files that you've made changes in git add path/to/folder/or/file.ext                 ## this will add the file or folder to the commit git commit -m 'Summarize the changes you've made'  ## this command creates a commit and a commit message

Tip: The best recommendation I’ve ever seen for commit messages is from Chris Breams’s “How To Write A Git Commit Message”. A properly formed Git commit subject line should always be able to complete the following sentence: “If applied, this commit will [your subject line here].” For more info on commits, check “Why I Create Atomic Commits In Git” by Clarice Bouwer.

Step 5: Push (Send Your Changes To Your Origin)

Once you’ve made some changes on your computer, before they can be merged into the master branch (added to the project), they need to be moved from your local to your remote repo. To do this, enter git push origin in the command line.

Step 6: Pull Request (Ask For Your Changes To Be Merged Into Upstream)

Now that your changes have gone from your fingers to your computer, to your remote repository — it’s now time to ask for them to be merged into the project via a pull request (PR).

The easiest way to do this is by going to your repo’s page in GitHub. There will be a small message right above the file window that says “This branch is X commits ahead repo-name:branch” and then options to “Pull request” or “Compare”.

Clicking the “Pull request” option here will take you to a page where you can compare the changes and a button that says “Create pull request” will then take you to the “Open a pull request” page where you’ll add a title and include a comment. Being brief, but detailed enough in the comment, will help project maintainers understand your proposed changes.

There are CLI tools like Node GH (GitHub also recently released a beta of their CLI tool) that allow you to initiate and manage pull requests in the terminal. At this point you may prefer to use the web interface, and that’s great! So do I.

The ‘Pull request’ and ‘Compare’ options will appear once your fork has diverged from the upstream repo. (Large preview)

At this point, we have three repository references:

  1. upstream: the main repo that you’re tracking, often it’s the repo that you forked;
  2. origin: the default name of the remote that you clone;
  3. local: the code that is currently on your computer.

So far, you have #2 and #3 — but #1 is important because it’s the primary source. Keeping these three things in-line with each other is going to help the commit history stay clean. This helps project maintainers as it eliminates (or at least minimizes) merge conflicts when you send pull requests (PR’s) and it helps you get the latest code and keep your local and origin repositories up-to-date.

Set An Upstream Remote

To track the upstream remote, in your terminal enter the following:

git remote add upstream https://github.com/liferay-design/liferay.design

Now, check to see what remotes you have available — enter git remote -v into your terminal, you should see something like:

origin and upstream are the most common labels for remotes — ‘origin’ is your fork, ‘upstream’ is the source. (Large preview) 
origin   https://github.com/yourGitHubUsername/liferay.design (fetch) origin    https://github.com/yourGitHubUsername/liferay.design (push) upstream  https://github.com/liferay-design/liferay.design (fetch) upstream  https://github.com/liferay-design/liferay.design (push)

This will allow you to quickly get the latest version of what is upstream — if you haven’t worked in a repo in a long time and don’t have any local changes that you want to keep, this is a handy command that I use:

git pull upstream master && git reset --hard upstream/master

GitHub Help is a great resource for this and many other questions you might have.

HTML And CSS: Starting With Semantics

On the web, there is an endless supply of resources for learning HTML and CSS. For the purposes of this article, I’m sharing what I would recommend based on the mistakes I made how I first learned to write HTML and CSS.

What Are HTML And CSS?

Before we get any further, let’s define HTML and CSS.

HTML stands for HyperText Markup Language.

Hypertext:

“Hypertext is text displayed on a computer display or other electronic devices with references (hyperlinks) to other text that the reader can immediately access.”

— “Hypertext” on Wikipedia

Markup Language:

“…a system for annotating a document in a way that is syntactically distinguishable from the text.”

— “Markup Language” on Wikipedia

In case you also don’t know what a lot of those words mean — briefly put, HTML is the combination of references (links) between documents on the web, and tags that you use to give structure to those documents.

There’s an HTML5 tag for pretty much any basic element — otherwise you can always use a div! (Large preview)

For a thorough introduction to HTML and CSS, I highly recommend the Introduction to HTML and CSS first steps, both on the Mozilla Developer Network (MDN) web docs. That, along with the excellent articles that websites such as CSS Tricks, 24 Ways and countless of others provide, contain basically everything you’ll ever need to reference with regards to HTML/CSS.

There are two main parts of an HTML document: the <head> and the <body>. – The <head> contains things that aren’t displayed by the browser — metadata and links to imported stylesheets and scripts. – The <body> contains the actual content that will be rendered by the browser. To render the content, the browser reads the HTML, provides a base layer of styles depending on the types of tags used, adds additional layers of styles provided by the website itself (the styles are included in/referenced from the <head>, or are inline), and that is what we see in the end. (Note: There is often also the additional layer of JavaScript but it’s outside of the scope of this article.)

CSS stands for Cascading Style Sheets — it is used to extend the HTML by making it easier to give documents a custom look and feel. A style sheet is a document that tells the HTML what elements should look like (and how they should be positioned) by setting rules based on tags, classes, IDs, and other selectors. Cascading refers to the method for determining which rules in a sheet take priority in the inevitable event of a rule conflict.

“‘Cascading’ means that styles can fall (or cascade) from one style sheet to another, enabling multiple style sheets to be used on one HTML document.”

— Cascade — Max Design

CSS often gets a bad reputation — in sites with lots of style sheets it can quickly become unwieldy, especially if there aren’t documented, consistent methods used (more on that later) — but if you use it in an organized fashion and following all the best practices, CSS can be your best friend. Especially with the layout capabilities that are now available in most modern browsers, CSS is not nearly as necessary to hack and fight as it once was.

Rachel Andrew wrote a great guide, How To Learn CSS — and one of the best things to know before you start is that:

“You don’t need to commit to memorizing every CSS Property and Value.”

— Rachel Andrew

Instead, it’s far more vital to learn the fundamentals — selectors, inheritance, the box model, and most importantly, how to debug your CSS code (hint: you will need the browser developer tools).

Don’t worry about memorizing the syntax for the background property, and don’t worry if you forget about how exactly to align stuff in Flexbox (the CSS Tricks Guide to Flexbox is possibly one of my top-10 most visited pages, ever!); Google and Stack Overflow are your friends when it comes to CSS properties and values.

Some code editors even have built-in autocomplete so you don’t even need to search on the web in order to be able to figure out all the possible properties of a border, for example.

One of my favorite new features in Firefox 70 is the inactive CSS rules indicator. It will save you hours of time trying to figure out why a style isn’t being applied.

Kids these days have it so easy! (Large preview)

Semantics

Let’s start with semantic code. Semantics refers to the meanings of words, semantic code refers to the idea that there is meaning to the markup in any given language.

There are many reasons why semantics are important. If I could summarize this, I would say that if you learn and use semantic code, it will make your life a lot easier because you will get a lot of things for free — and who doesn’t like free stuff?

For a more complete introduction to semantic code, see Paul Boag’s brief blog post on the topic.

Semantics gives you many benefits:

  1. Default styles
    For example, using a headline tag <h1> for the title of your document will make it stand out from the rest of the document’s contents, much like a headline would.
  2. Accessible content
    Your code will be accessible by default, meaning it will work with screen readers and will be easier to navigate with a keyboard.
  3. SEO benefits
    Semantic markup is easier for a machine to read, which makes it more accessible to search engines.
  4. Performance benefits
    Clean HTML is the foundation for a high-performing site. And clean HTML will also likely lead to cleaner CSS which means less code overall, making your site or app faster.

Note: For a more in-depth look into semantics and HTML, Heydon Pickering wrote “Structural Semantics: The Importance Of HTML5 Sectioning Elements” which I highly recommend reading.

Engineering Principles And Paradigms: The Basics

Abstraction

There are tons of applications, tangents, and levels we could explore over the concept of abstraction — too many for this article which is intended to give you a brief introduction into concepts so that you are aware of them as you continue to learn.

Abstraction is a foundational engineering paradigm with a wide variety of applications — for the purposes of this article, abstraction is separating form from function. We’ll apply this in three areas: tokens, components, and the Don’t Repeat Yourself principle.

Tokens

If you’ve used a modern design tool for any length of time, you’ve probably encountered the idea of a token. Even Photoshop and Illustrator now have this idea of shared styles in a centralized library — instead of hard-coding values into a design, you use a token. If you’re familiar with the concept of CSS or SASS variables, you’re already familiar with tokens.

One layer of abstraction with tokens is to assign a name to a color — for example, $ blue-00 can be mapped to a hex value (or an HSL value, or whatever you want) — let’s say #0B5FFF. Now, instead of using the hex value in your stylesheets, you use the token value — that way if you decide that blue-00 is actually #0B36CE, then you only have to change it in a single place. This is a nice concept.

Tokens for colors in the Lexicon Alerts component helps keep things DRY. (Large preview)

If you take this same paradigm of abstraction and go a layer further, you can token-ception — and assign a variable to a functional value. This is particularly useful if you have a robust system and want to have different themes within the system. A functional example of this would be assigning a variable like $ primary-color and map that to $ blue-00 — so now you can create markup and instead of referencing blue, you’re referencing a functional variable. If you ever want to use the same markup, but with a different style (theme), then you only need to map $ primary-color to a new color, and your markup doesn’t need to change at all! Magic!

Components

In the past 3-4 years, the idea of components and componentization has become more relevant and accessible to designers. The concept of symbols (pioneered by Macromedia/Adobe Fireworks, later expanded by Sketch, and then taken to the next level by Figma and Framer), is now more widely available in most design tools (Adobe XD, InVision Studio, Webflow, and many others). Componentization, even more than tokens, can separate the form of something from the function of it — which helps to improve both the form and the function.

One of the more notable early examples is Nicole Sullivan’s media object component. At first glance you might not realize that a whole page is essentially composed of a single component, rendered in different ways. In this way, we can re-use the same markup (form), modifying it slightly by passing in options or parameters, and styles — and have it provide a variety of value (function).

Don’t Repeat Yourself

DRY (Don’t Repeat Yourself) is one of my favorite principles — creating things that can be reused over and over is one of the small victories you can have when coding.

While you often can’t (and arguably shouldn’t) strive to apply the DRY principle 100% of the time, every time — it’s at least beneficial to be aware of this so that as you’re working, you can consider how you can make whatever you’re working on more reusable.

A note on the Rule of Three: A corollary to the DRY principle is the rule of three — essentially, once you re-use (copy/paste) something three times, you should rewrite it into a reusable component. Like the Pirate’s Code, it’s more of a guideline than a hard and fast rule, and can vary from component to component and from project to project.

CSS And Styling Methodologies: Atomic vs. BEM

There are a lot of different ways to organize and write CSS code — Atomic and BEM are only two of the many that you’re likely to come across. You don’t have to “pick” a single one, nor do you have to follow them exactly. Most of the teams I’ve worked with usually have their own unique blend, based on the project or technology. It is helpful to be familiar with them so that over time, you can learn which approach to take depending on the situation.

All of these approaches go beyond “just” CSS and styling, and can often influence the tooling you use, the way you organize your files, and potentially the markup.

Atomic CSS

Not to be confused with Atomic Web Design — atomic (perhaps more aptly referred to as “functional”) CSS, is a methodology that essentially favors using small, single-purpose classes to define visual functions. A few notable libraries:

  1. Atomic CSS by Steve Carlson;
  2. Tachyons by Adam Morse;
  3. Tailwind CSS by Adam Wathan.

What I like about this method is that it allows you to quickly style and theme things — one of the biggest drawbacks is that your markup can get pretty cluttered, pretty fast.

Check John Polacek’s article on CSS-tricks for a full introduction to Atomic CSS.

BEM

The BEM philosophy is a great precursor to a lot of the modern JavaScript frameworks like Angular, React, and Vue.

“BEM (Block, Element, Modifier) is a component-based approach to web development.”

— BEM: Quick Start

Basically, everything that can be reused is a block. Blocks are comprised of elements, something that can’t be used outside of a block, and potentially other blocks. Modifiers are things that describe the status of something or the way it looks or behaves.

Personally, I like the theory and philosophy of BEM. What I do not like is the way that things are named. Way too many underscores, hyphens, and it can feel unnecessarily repetitive (.menu, .menu__item, etc).

Recommended reading: BEM For Beginners written by Inna Belaya

Thank U, Next(.js)

After you have sufficiently mastered these topics, don’t worry, there is still plenty to learn. Some suggestions:

  1. Functional and object-oriented programming
    We touched on it lightly, but there’s plenty more to learn beyond CSS.
  2. Higher-level languages and frameworks
    Typescript, Ruby, React, Vue are the next things you’ll tackle once you have a strong grasp of HTML and CSS.
  3. Querying languages and using data
    Learning about GraphQL, MySQL, REST APIs will take your coding ability to the next level.

Conclusion: Designers Who Code != Software Engineers

Hopefully, this article has shown you that learning to code isn’t as difficult as you may have previously thought. It can take a lot of time, but the amount of resources available on the internet is astounding, and they’re not decreasing — quite the opposite!

One significant point that I want to emphasize is that “coding” is not the same as “software engineering” — being able to fork a repo and copy/paste in code from Stack Overflow can get you a long way, and while most, if not all, software engineers that I know have done that — you must use your new-found skills with wisdom and humility. For everything you can now access with some engineering prowess, there is that much more that you don’t know. While you may think that a feature or style is easy to accomplish because — “Hey, I got it working in devtools!” or “I made it work in Codepen.” — there are many engineering processes, dependencies, and methods that you probably don’t know that you don’t know.

All of that is to say — don’t forget that we are still designers. Our primary function is to add business value through the lens of understanding customer or user problems and synthesizing them with our knowledge of design patterns, methods, and processes. Yes, being a “designer who writes code” can be very useful and will expand your ability to add this value — but we still need to let engineers make the engineering decisions.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Further Reading

  1. Coding Bootcamps vs. Computer Science Degrees: What Employers Want and Other Perspectives (Kyle Thayer)
  2. How To Start Using Sketch And Framer X (by Martina Pérez, Smashing Magazine)
  3. Introduction To Linux Commands (by Paul Tero, Smashing Magazine)
  4. Become A Command-Line Power User With Oh My ZSH And Z (by Wes Bos, Smashing Magazine)
  5. A list of the common cmd.exe and Unix commands that you can use in PowerShell (Microsoft Docs)
  6. regular-expressions.info (by Jan Goyvaerts)
  7. regexone.com (learn regular expressions with simple interactive exercises)
  8. Batch Resizing Using Command Line and ImageMagick (by Vlad Gerasimov, Smashing Magazine)
  9. Shortcuts And Tips For Improving Your Productivity With Sublime Text (by Jai Pandya, Smashing Magazine)
  10. Visual Studio Code Can Do That? (by Burke Holland, Smashing Magazine)
  11. Why version history is not version control (by Josh Brewer)
  12. Modern Version Control With Git (by Tobias Günther, Smashing Magazine)
  13. “Hello World” (a GitHub step-by-step guide)
  14. How to Install Node.js and NPM on a Mac (by Dave McFarland)
  15. How to Install Node.js and NPM on Windows (by Dejan Tucakov)
  16. Why I Create Atomic Commits In Git (by Clarice Bouwer)
  17. How to Write a Git Commit Message (by Chris Breams)
  18. Semantic code: What? Why? How? (by Paul Boag)
  19. Structural Semantics: The Importance Of HTML5 Sectioning Elements (by Heydon Pickering, Smashing Magazine)
  20. Designing for Performance: Chapter 4. Optimizing Markup and Styles (by Lara C. Hogan, O’Reilly Media)
  21. The media object saves hundreds of lines of code (by Nicole Sullivan)
  22. Let’s Define Exactly What Atomic CSS is (by John Polacek, CSS Tricks)
  23. BEM For Beginners: Why You Need BEM (by Inna Belaya, Smashing Magazine)
  24. Javascript for Cats: An Introduction for New Programmers
  25. Roadmap.sh: Frontend Developer
  26. Functional Programming vs OOPS : Explain Like I’m Five
  27. Why, How, and When to Use Semantic HTML and ARIA (by Adam Silver, CSS Tricks)
  28. HTML Semantics (an eBook by Smashing Magazine)
  29. The Fundamentals – HTML + CSS (on Syntax.fm)
  30. Cascade and inheritance (westciv.com)
  31. CSS Tricks (by Chris Coyier)
  32. Getting Started With CSS Layout (by Rachel Andrew, Smashing Magazine)
  33. Introduction to HTML (MDN web docs)
  34. CSS first steps (MDN web docs)
  35. JavaScript First Steps (MDN web docs)
  36. 24 Ways (by Drew McLellan)
Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
24 Mar

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

by TBSCategories: News

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

Paul Hanaoka

As a designer with many years of experience, I often encourage my colleagues and reports to pick up some coding skills. While many are open to the idea, others balk at the notion. I usually hear some variation of “I didn’t study design to become a developer.” Although this is a valid concern, I’d like to emphasize two points: a better understanding of the materials usually leads to better outcomes, and there is an important distinction between “coding” and “software engineering.”

This two-part series of articles should be useful for any designers out there who’d like to gain also some coding skills.

Understanding The Raw Materials

Contrary to what some may think, design isn’t about creating beautiful mockups, it’s about delivering an intuitive, functional experience to the end user. That simply can’t be done without an understanding of the building blocks of a solution. An architect isn’t going to be very good at her job if she doesn’t understand the materials her plans demand and a designer isn’t going to be very good if he doesn’t understand the materials that make his designs come to life — the code. Experience with coding helps designers understand what’s possible and what’s not and whether or not their designs will be able to effectively perform their desired functions.

I also reassure my colleagues that knowledge of coding doesn’t mean one has to become an engineer. The two refer to different, though related, skill sets. As Kyle Thayer, a PhD candidate at the University of Washington recently wrote, the field of computer science (or engineering) is about giving students “an overview of the scientific field of computing”:

“The purpose of a Computer Science degree is to give students an overview of the scientific field of computing. While this includes some programming, programming is done primarily for the purpose of learning about other areas (e.g., operating systems, algorithms, machine learning, human-computer interaction). A CS degree is a good first step into the academic field of computer science.”

— Kyle Thayer

By contrast, coding simply means becoming familiar enough with a given programming language to complete a task. Asking someone to learn basic HTML or JavaScript does not necessitate their becoming a full-stack software architect. Despite what some might think, forking a repo and copy/pasting Stack Overflow answers in does not make you a software engineer — but it can increase the value you bring as a designer to a product development team.

What About “Low Code”?

Some may say that we’re entering a low code future where designers (and developers) are able to build applications through drag-and-drop functionality and a GUI (graphical user interface). So taking the time to learn a programming language isn’t “worth it.” The emergence of tools like Webflow, Modulz, FramerX, UXPin, etc., seems to support this line of reasoning. And this can be very true for many applications — it’s easier than ever to create a site or app without a single line of code. However, if you don’t understand the underlying principles, you will be capping the value you can deliver with a low code application.

Logos and screenshots showing the code behind tools developed by companies like Modulz, Studio.Design, FramerX, and others.
Modulz, Studio.Design, FramerX, and other apps — there’s still a lot of code in there… (Large preview)

We’re also not yet at the point where you can build enterprise-scale applications with low code platforms. As designers we have to work in the world we live in, not the one we imagine is coming.

That being said, everyone brings a unique blend of skills to the table. Knowledge of code is not an absolute necessity and it should just be encouraged, not required.

Where To Start?

There is an endless amount of tools, languages, schools, guides, and other resources available for anyone who has access to the internet — so where to begin? An important disclaimer — I am by no means an expert, or anything close to a software engineer — and the following are insights from my personal experience, not a guaranteed path to success.

Many of the designers/developers I know have usually started hacking HTML and CSS templates on sites like MySpace, Geocities, Tumblr, Neopets, or others. Now that I have sufficiently dated myself, for anyone starting out today, I would recommend beginning in your friendly command-line interface (CLI) shell.

The Terminal: An Essential Tool

The go-to application for Hollywood directors whenever there’s a computer hacker on the screen, the terminal is simply an interface that allows you to execute actions via a text input rather than the graphical user interface (GUI) that most people are accustomed to. I’ll let real developers explain the intricacies and technical how-to, but for our purposes it’s good enough to know that familiarizing yourself with the CLI is beneficial for a number of reasons.

The terminal gives you access to your computer’s file and folder structure — the same way that you click through Finder or Explorer, you navigate using your keyboard in the terminal. It definitely takes some time getting used to, but developing your mental model in this area is foundational to working in code.

Like a lot of designers, I am using the macOS environment (formerly known as OS X), but the following applies to other *nix operating systems (Linux, Unix), and also to Windows PowerShell. While there is a lot of overlap between different modern operating systems, there are some differences that I will do my best to highlight.

Note: For a more complete introduction to the terminal, I recommend reading Paul Tero’s article, “Introduction To Linux Commands”.

Regular Expressions

A key feature in a CLI is the ability to use regular expressions (regex) in your commands. Think of regex as boolean search operations (using quotation marks to search for exact phrases or the minus sign to exclude words) on steroids — they allow you to define a pattern in a string of text so that you can perform some action on the output. Here are some real-world examples:

  1. If you have a long list of phone numbers in a variety of formats, you could define a script that would give you a consistent output based on a regular expression — e.g.: (###) ###-#### for the U.S. phone numbers format.
  2. If you want to quickly rename a group of files to a specific case — from kebab-case to CamelCase or anything in between.

I highly recommend watching Wes Bos’ Command Line Power User series — or at the very least his intro video which will give you a good idea about a few essentials commands that you can use.

Here are some basic terminal commands* to help you getting started:

  1. cd stands for “Change Directory”, type this and then a file or a folder path to go — note that you can type a folder name but it needs to be inside your current folder to go to it.
  2. ls lists the files and folders in your current folder.
  3. pwd stands for “Print Working Directory” — this will list out where you currently are in your computer.
  4. mkdir and a folder name will create a folder in your working directory.
  5. using cd with .. takes you one level up — if you’re in /users/username/documents/2019 and you enter cd ../.. you’ll end up in /users/username.
  6. Bonus tip — hitting the Tab key will autocomplete as you type a folder/file path.

Note: The following will work on the Windows command line (cmd):

  • cd, cd .., mkdir, Tab key for path autocomplete (ls and pwd won’t work).

The more modern Windows command line (Windows PowerShell) supports all of them:

  • cd, cd .., ls, pwd, mkdir, and Tab for path autocomplete.

For a complete list of commands available in PowerShell, check this Microsoft’ Help page “Using Familiar Command Names”.

Mass-File Management

You can manipulate files and folders en masse via the terminal — here are a few ideas:

  1. You can create three years of folders with subfolders for each month in a single command — using mkdir -p and {list-of-years}/{list-of-months} will create folders for each year with subfolders for each month. Use your imagination, I’m sure you can put this to good use!
  2. You can quickly clean up your desktop by using mv Screen\ Shot* Screenshots — this will move all of your files that start with “Screen Shot” to a folder named “Screenshots”.
A screenshot of a terminal window showing the commands and output of a folder creation script.
Create 36 folders on your computer with a single line of code! (Large preview)

Note: These two examples will most likely only work in *nix environments — but the theory still applies. And Windows PowerShell is also a very powerful command line tool, you just need to learn its features and specific commands.

Scripting And Maintenance

Now that we have a glimpse into the power of regular expressions and the options available in the terminal we can start combining those things into scripts. One very simple, yet powerful and commonly used script is Mike G’s file renamer:

criteria=$  1  re_match=$  2  replace=$  3  for i in $  ( ls *$  criteria* );   do      src=$  i      tgt=$  (echo $  i | sed -e "s/$  re_match/$  replace/")      mv $  src $  tgt  done

What this script allows you to do, is define the scope (criteria), define what you’d like to change (re_match), and what you’d like to change it to (replace) — and then execute it.

There are countless other scripts that you can create beyond creating and renaming files — Vlad’s Batch Resizing script is an excellent example of the time-saving capabilities that you can create using bash scripts.

Advanced Tips And Tricks

Something I have found over the years is that regularly resetting my computer and reinstalling the operating system helps it stay relatively clutter-free and prevents the slowdowns everyone experiences after years of digital detritus that accumulates on harddrives. For many, the prospect of wiping a computer and re-setting everything back at best sounds like a few days of work, and at worst an impossible nightmare that you may never recover from.

But it doesn’t have to be — by using a few command-line tools, once you’ve backed up, wiped, and reinstalled your OS, you can install not only your list of favorite apps, but also fonts in a matter of minutes using Homebrew. (Homebrew is for Mac and Linux only. For Windows, try Chocolatey which is a solid alternative.)

If you’re interested — we’ve created an easy-to-follow setup guide to get your computer in good shape for most development. Our guide is for macOS, but Owen Williams has written a solid guide for Windows as well.

If you don’t have the time for Wes’ entire series of tutorials about the command line — at the very least I highly recommend the following stack:

  1. Oh My ZSH
  2. zsh-autosuggestions
  3. zsh-syntax-highlighting
  4. z-jump-around

Choosing A Text Editor

There are many options when it comes to choosing a code editor — Sublime Text and VS Code (Visual Studio Code) are the two I have the most experience with and am currently using.

Sublime Text was one of the earlier text editors that became popular with front-end developers — it was the gold standard up until a few years ago. Features like multiple cursors, a powerful package manager, and highly customizable shortcuts that allowed you to quickly navigate in and between files and folders. Not to mention it was an incredibly lightweight and fast application which made it an easy choice.

VS Code (Visual Studio Code) came on the scene around 2015, it took a while for people to switch from Atom and Sublime, but VS Code has established itself as many developers’ favorite editor. In addition to pretty much all of Sublime’s features, VS Code differentiated itself with a built-in terminal and tight integration with Git. In addition, Visual Studio Code has a rich plugin ecosystem that allows you to extend and customize your environment to your heart’s delight.

All that is to say — you don’t need to be a developer to appreciate the features of a good code editor. I have found many uses for it in my daily work; two, in particular, are the ability to use multiple cursors, and using regex to find-and-replace text across folders of files. Let’s take a closer look at both.

Editing With Multiple Cursors

Picture your typical word processor — that blinking vertical line that shows where the text you’re entering will go? Now picture the ability to add more than one cursor to this window so that whatever you type will appear wherever there is a cursor!

This might not be blowing your mind just yet — so here’s an example that shows a few ways that an advanced text editor can help you create everyday efficiencies in your workflow.

A screencap showing a list of names being manipulated and turned into a list of email addresses.
Mass-editing in a text editor is much faster and more intuitive than in a spreadsheet. (Large preview)

Here we have a list of names that we need to convert into email addresses — we’d also like to make them all lowercase and then sort them alphabetically. This can be done with a few keystrokes.

Using a text editor to quickly manipulate lots of text in Sublime Text (short video).

Once you paste the list in, Cmd + Shift + P brings up the Command Palette (fancy term for a searchable menu that gives you all the available functionalities). You can basically type in this menu what you want to do, pretty much anything you can do to text is available here. If it’s not, there’s likely a plugin or an extension that you can find.

We’re able to change the case and sort the lines in a matter of seconds — then pressing Ctrl + Shift + arrow keys adds cursors, then whatever we type gets added to every line — in this case, we’re turning the names into email addresses, but your wild imagination could find myriad other ways to use this.

You might be saying — well I can do this in Excel or Google Sheets, which is true, but I have found that it is a lot quicker to handle these types of things in a text editor. You avoid having to write formulas and select things with a mouse.

Which Code Editor Should I Use?

I’m a designer — so of course, my answer is “it depends”.

  • If you’re new to these concepts, I would recommend getting a free trial of Sublime — it continues to be a very lightweight app and does not consume too many system resources. You can customize Sublime’s key bindings (fancy word for hotkeys) and extend its built-in functionality with plugins.
  • If you’ve been using Sublime, Atom, or another editor — I’d recommend checking out VS Code as well. The team at Microsoft has really done an excellent job making it a powerful, yet easy-to-use text editor.

Personally, I use both editors — Sublime is lightning quick and opens in a fraction of a second allowing me to easily paste and manipulate text. But when I want to get some more serious work done, I use VS Code. It’s difficult to top the all-in-one package that VS Code provides — a vibrant plugin and extension ecosystem, powerful command palette, and hyper-customizable interface means you can really make it your own. Not to mention the fact that Microsoft is very incentivized to ensure that it’s a first-class experience for developer productivity.

Conclusion, And What’s Next?

In this first article, you will have learned the basics of the terminal, a few productivity hacks to get you started, and should have a better idea of what code editor to choose. In the next part, we’ll continue with the topics of version control, HTML and CSS, and an introduction to engineering principles.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
19 Mar

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

by TBSCategories: News

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

Paul Hanaoka

As a designer with many years of experience, I often encourage my colleagues and reports to pick up some coding skills. While many are open to the idea, others balk at the notion. I usually hear some variation of “I didn’t study design to become a developer.” Although this is a valid concern, I’d like to emphasize two points: a better understanding of the materials usually leads to better outcomes, and there is an important distinction between “coding” and “software engineering.”

This two-part series of articles should be useful for any designers out there who’d like to gain also some coding skills.

Understanding The Raw Materials

Contrary to what some may think, design isn’t about creating beautiful mockups, it’s about delivering an intuitive, functional experience to the end user. That simply can’t be done without an understanding of the building blocks of a solution. An architect isn’t going to be very good at her job if she doesn’t understand the materials her plans demand and a designer isn’t going to be very good if he doesn’t understand the materials that make his designs come to life — the code. Experience with coding helps designers understand what’s possible and what’s not and whether or not their designs will be able to effectively perform their desired functions.

I also reassure my colleagues that knowledge of coding doesn’t mean one has to become an engineer. The two refer to different, though related, skill sets. As Kyle Thayer, a PhD candidate at the University of Washington recently wrote, the field of computer science (or engineering) is about giving students “an overview of the scientific field of computing”:

“The purpose of a Computer Science degree is to give students an overview of the scientific field of computing. While this includes some programming, programming is done primarily for the purpose of learning about other areas (e.g., operating systems, algorithms, machine learning, human-computer interaction). A CS degree is a good first step into the academic field of computer science.”

— Kyle Thayer

By contrast, coding simply means becoming familiar enough with a given programming language to complete a task. Asking someone to learn basic HTML or JavaScript does not necessitate their becoming a full-stack software architect. Despite what some might think, forking a repo and copy/pasting Stack Overflow answers in does not make you a software engineer — but it can increase the value you bring as a designer to a product development team.

What About “Low Code”?

Some may say that we’re entering a low code future where designers (and developers) are able to build applications through drag-and-drop functionality and a GUI (graphical user interface). So taking the time to learn a programming language isn’t “worth it.” The emergence of tools like Webflow, Modulz, FramerX, UXPin, etc., seems to support this line of reasoning. And this can be very true for many applications — it’s easier than ever to create a site or app without a single line of code. However, if you don’t understand the underlying principles, you will be capping the value you can deliver with a low code application.

Logos and screenshots showing the code behind tools developed by companies like Modulz, Studio.Design, FramerX, and others.
Modulz, Studio.Design, FramerX, and other apps — there’s still a lot of code in there… (Large preview)

We’re also not yet at the point where you can build enterprise-scale applications with low code platforms. As designers we have to work in the world we live in, not the one we imagine is coming.

That being said, everyone brings a unique blend of skills to the table. Knowledge of code is not an absolute necessity and it should just be encouraged, not required.

Where To Start?

There is an endless amount of tools, languages, schools, guides, and other resources available for anyone who has access to the internet — so where to begin? An important disclaimer — I am by no means an expert, or anything close to a software engineer — and the following are insights from my personal experience, not a guaranteed path to success.

Many of the designers/developers I know have usually started hacking HTML and CSS templates on sites like MySpace, Geocities, Tumblr, Neopets, or others. Now that I have sufficiently dated myself, for anyone starting out today, I would recommend beginning in your friendly command-line interface (CLI) shell.

The Terminal: An Essential Tool

The go-to application for Hollywood directors whenever there’s a computer hacker on the screen, the terminal is simply an interface that allows you to execute actions via a text input rather than the graphical user interface (GUI) that most people are accustomed to. I’ll let real developers explain the intricacies and technical how-to, but for our purposes it’s good enough to know that familiarizing yourself with the CLI is beneficial for a number of reasons.

The terminal gives you access to your computer’s file and folder structure — the same way that you click through Finder or Explorer, you navigate using your keyboard in the terminal. It definitely takes some time getting used to, but developing your mental model in this area is foundational to working in code.

Like a lot of designers, I am using the macOS environment (formerly known as OS X), but the following applies to other *nix operating systems (Linux, Unix), and also to Windows PowerShell. While there is a lot of overlap between different modern operating systems, there are some differences that I will do my best to highlight.

Note: For a more complete introduction to the terminal, I recommend reading Paul Tero’s article, “Introduction To Linux Commands”.

Regular Expressions

A key feature in a CLI is the ability to use regular expressions (regex) in your commands. Think of regex as boolean search operations (using quotation marks to search for exact phrases or the minus sign to exclude words) on steroids — they allow you to define a pattern in a string of text so that you can perform some action on the output. Here are some real-world examples:

  1. If you have a long list of phone numbers in a variety of formats, you could define a script that would give you a consistent output based on a regular expression — e.g.: (###) ###-#### for the U.S. phone numbers format.
  2. If you want to quickly rename a group of files to a specific case — from kebab-case to CamelCase or anything in between.

I highly recommend watching Wes Bos’ Command Line Power User series — or at the very least his intro video which will give you a good idea about a few essentials commands that you can use.

Here are some basic terminal commands* to help you getting started:

  1. cd stands for “Change Directory”, type this and then a file or a folder path to go — note that you can type a folder name but it needs to be inside your current folder to go to it.
  2. ls lists the files and folders in your current folder.
  3. pwd stands for “Print Working Directory” — this will list out where you currently are in your computer.
  4. mkdir and a folder name will create a folder in your working directory.
  5. using cd with .. takes you one level up — if you’re in /users/username/documents/2019 and you enter cd ../.. you’ll end up in /users/username.
  6. Bonus tip — hitting the Tab key will autocomplete as you type a folder/file path.

Note: The following will work on the Windows command line (cmd):

  • cd, cd .., mkdir, Tab key for path autocomplete (ls and pwd won’t work).

The more modern Windows command line (Windows PowerShell) supports all of them:

  • cd, cd .., ls, pwd, mkdir, and Tab for path autocomplete.

For a complete list of commands available in PowerShell, check this Microsoft’ Help page “Using Familiar Command Names”.

Mass-File Management

You can manipulate files and folders en masse via the terminal — here are a few ideas:

  1. You can create three years of folders with subfolders for each month in a single command — using mkdir -p and {list-of-years}/{list-of-months} will create folders for each year with subfolders for each month. Use your imagination, I’m sure you can put this to good use!
  2. You can quickly clean up your desktop by using mv Screen\ Shot* Screenshots — this will move all of your files that start with “Screen Shot” to a folder named “Screenshots”.
A screenshot of a terminal window showing the commands and output of a folder creation script.
Create 36 folders on your computer with a single line of code! (Large preview)

Note: These two examples will most likely only work in *nix environments — but the theory still applies. And Windows PowerShell is also a very powerful command line tool, you just need to learn its features and specific commands.

Scripting And Maintenance

Now that we have a glimpse into the power of regular expressions and the options available in the terminal we can start combining those things into scripts. One very simple, yet powerful and commonly used script is Mike G’s file renamer:

criteria=$  1  re_match=$  2  replace=$  3  for i in $  ( ls *$  criteria* );   do      src=$  i      tgt=$  (echo $  i | sed -e "s/$  re_match/$  replace/")      mv $  src $  tgt  done

What this script allows you to do, is define the scope (criteria), define what you’d like to change (re_match), and what you’d like to change it to (replace) — and then execute it.

There are countless other scripts that you can create beyond creating and renaming files — Vlad’s Batch Resizing script is an excellent example of the time-saving capabilities that you can create using bash scripts.

Advanced Tips And Tricks

Something I have found over the years is that regularly resetting my computer and reinstalling the operating system helps it stay relatively clutter-free and prevents the slowdowns everyone experiences after years of digital detritus that accumulates on harddrives. For many, the prospect of wiping a computer and re-setting everything back at best sounds like a few days of work, and at worst an impossible nightmare that you may never recover from.

But it doesn’t have to be — by using a few command-line tools, once you’ve backed up, wiped, and reinstalled your OS, you can install not only your list of favorite apps, but also fonts in a matter of minutes using Homebrew. (Homebrew is for Mac and Linux only. For Windows, try Chocolatey which is a solid alternative.)

If you’re interested — we’ve created an easy-to-follow setup guide to get your computer in good shape for most development. Our guide is for macOS, but Owen Williams has written a solid guide for Windows as well.

If you don’t have the time for Wes’ entire series of tutorials about the command line — at the very least I highly recommend the following stack:

  1. Oh My ZSH
  2. zsh-autosuggestions
  3. zsh-syntax-highlighting
  4. z-jump-around

Choosing A Text Editor

There are many options when it comes to choosing a code editor — Sublime Text and VS Code (Visual Studio Code) are the two I have the most experience with and am currently using.

Sublime Text was one of the earlier text editors that became popular with front-end developers — it was the gold standard up until a few years ago. Features like multiple cursors, a powerful package manager, and highly customizable shortcuts that allowed you to quickly navigate in and between files and folders. Not to mention it was an incredibly lightweight and fast application which made it an easy choice.

VS Code (Visual Studio Code) came on the scene around 2015, it took a while for people to switch from Atom and Sublime, but VS Code has established itself as many developers’ favorite editor. In addition to pretty much all of Sublime’s features, VS Code differentiated itself with a built-in terminal and tight integration with Git. In addition, Visual Studio Code has a rich plugin ecosystem that allows you to extend and customize your environment to your heart’s delight.

All that is to say — you don’t need to be a developer to appreciate the features of a good code editor. I have found many uses for it in my daily work; two, in particular, are the ability to use multiple cursors, and using regex to find-and-replace text across folders of files. Let’s take a closer look at both.

Editing With Multiple Cursors

Picture your typical word processor — that blinking vertical line that shows where the text you’re entering will go? Now picture the ability to add more than one cursor to this window so that whatever you type will appear wherever there is a cursor!

This might not be blowing your mind just yet — so here’s an example that shows a few ways that an advanced text editor can help you create everyday efficiencies in your workflow.

A screencap showing a list of names being manipulated and turned into a list of email addresses.
Mass-editing in a text editor is much faster and more intuitive than in a spreadsheet. (Large preview)

Here we have a list of names that we need to convert into email addresses — we’d also like to make them all lowercase and then sort them alphabetically. This can be done with a few keystrokes.

Using a text editor to quickly manipulate lots of text in Sublime Text (short video).

Once you paste the list in, Cmd + Shift + P brings up the Command Palette (fancy term for a searchable menu that gives you all the available functionalities). You can basically type in this menu what you want to do, pretty much anything you can do to text is available here. If it’s not, there’s likely a plugin or an extension that you can find.

We’re able to change the case and sort the lines in a matter of seconds — then pressing Ctrl + Shift + arrow keys adds cursors, then whatever we type gets added to every line — in this case, we’re turning the names into email addresses, but your wild imagination could find myriad other ways to use this.

You might be saying — well I can do this in Excel or Google Sheets, which is true, but I have found that it is a lot quicker to handle these types of things in a text editor. You avoid having to write formulas and select things with a mouse.

Which Code Editor Should I Use?

I’m a designer — so of course, my answer is “it depends”.

  • If you’re new to these concepts, I would recommend getting a free trial of Sublime — it continues to be a very lightweight app and does not consume too many system resources. You can customize Sublime’s key bindings (fancy word for hotkeys) and extend its built-in functionality with plugins.
  • If you’ve been using Sublime, Atom, or another editor — I’d recommend checking out VS Code as well. The team at Microsoft has really done an excellent job making it a powerful, yet easy-to-use text editor.

Personally, I use both editors — Sublime is lightning quick and opens in a fraction of a second allowing me to easily paste and manipulate text. But when I want to get some more serious work done, I use VS Code. It’s difficult to top the all-in-one package that VS Code provides — a vibrant plugin and extension ecosystem, powerful command palette, and hyper-customizable interface means you can really make it your own. Not to mention the fact that Microsoft is very incentivized to ensure that it’s a first-class experience for developer productivity.

Conclusion, And What’s Next?

In this first article, you will have learned the basics of the terminal, a few productivity hacks to get you started, and should have a better idea of what code editor to choose. In the next part, we’ll continue with the topics of version control, HTML and CSS, and an introduction to engineering principles.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
19 Mar

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

by TBSCategories: News

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

Paul Hanaoka

As a designer with many years of experience, I often encourage my colleagues and reports to pick up some coding skills. While many are open to the idea, others balk at the notion. I usually hear some variation of “I didn’t study design to become a developer.” Although this is a valid concern, I’d like to emphasize two points: a better understanding of the materials usually leads to better outcomes, and there is an important distinction between “coding” and “software engineering.”

This two-part series of articles should be useful for any designers out there who’d like to gain also some coding skills.

Understanding The Raw Materials

Contrary to what some may think, design isn’t about creating beautiful mockups, it’s about delivering an intuitive, functional experience to the end user. That simply can’t be done without an understanding of the building blocks of a solution. An architect isn’t going to be very good at her job if she doesn’t understand the materials her plans demand and a designer isn’t going to be very good if he doesn’t understand the materials that make his designs come to life — the code. Experience with coding helps designers understand what’s possible and what’s not and whether or not their designs will be able to effectively perform their desired functions.

I also reassure my colleagues that knowledge of coding doesn’t mean one has to become an engineer. The two refer to different, though related, skill sets. As Kyle Thayer, a PhD candidate at the University of Washington recently wrote, the field of computer science (or engineering) is about giving students “an overview of the scientific field of computing”:

“The purpose of a Computer Science degree is to give students an overview of the scientific field of computing. While this includes some programming, programming is done primarily for the purpose of learning about other areas (e.g., operating systems, algorithms, machine learning, human-computer interaction). A CS degree is a good first step into the academic field of computer science.”

— Kyle Thayer

By contrast, coding simply means becoming familiar enough with a given programming language to complete a task. Asking someone to learn basic HTML or JavaScript does not necessitate their becoming a full-stack software architect. Despite what some might think, forking a repo and copy/pasting Stack Overflow answers in does not make you a software engineer — but it can increase the value you bring as a designer to a product development team.

What About “Low Code”?

Some may say that we’re entering a low code future where designers (and developers) are able to build applications through drag-and-drop functionality and a GUI (graphical user interface). So taking the time to learn a programming language isn’t “worth it.” The emergence of tools like Webflow, Modulz, FramerX, UXPin, etc., seems to support this line of reasoning. And this can be very true for many applications — it’s easier than ever to create a site or app without a single line of code. However, if you don’t understand the underlying principles, you will be capping the value you can deliver with a low code application.

Logos and screenshots showing the code behind tools developed by companies like Modulz, Studio.Design, FramerX, and others.
Modulz, Studio.Design, FramerX, and other apps — there’s still a lot of code in there… (Large preview)

We’re also not yet at the point where you can build enterprise-scale applications with low code platforms. As designers we have to work in the world we live in, not the one we imagine is coming.

That being said, everyone brings a unique blend of skills to the table. Knowledge of code is not an absolute necessity and it should just be encouraged, not required.

Where To Start?

There is an endless amount of tools, languages, schools, guides, and other resources available for anyone who has access to the internet — so where to begin? An important disclaimer — I am by no means an expert, or anything close to a software engineer — and the following are insights from my personal experience, not a guaranteed path to success.

Many of the designers/developers I know have usually started hacking HTML and CSS templates on sites like MySpace, Geocities, Tumblr, Neopets, or others. Now that I have sufficiently dated myself, for anyone starting out today, I would recommend beginning in your friendly command-line interface (CLI) shell.

The Terminal: An Essential Tool

The go-to application for Hollywood directors whenever there’s a computer hacker on the screen, the terminal is simply an interface that allows you to execute actions via a text input rather than the graphical user interface (GUI) that most people are accustomed to. I’ll let real developers explain the intricacies and technical how-to, but for our purposes it’s good enough to know that familiarizing yourself with the CLI is beneficial for a number of reasons.

The terminal gives you access to your computer’s file and folder structure — the same way that you click through Finder or Explorer, you navigate using your keyboard in the terminal. It definitely takes some time getting used to, but developing your mental model in this area is foundational to working in code.

Like a lot of designers, I am using the macOS environment (formerly known as OS X), but the following applies to other *nix operating systems (Linux, Unix), and also to Windows PowerShell. While there is a lot of overlap between different modern operating systems, there are some differences that I will do my best to highlight.

Note: For a more complete introduction to the terminal, I recommend reading Paul Tero’s article, “Introduction To Linux Commands”.

Regular Expressions

A key feature in a CLI is the ability to use regular expressions (regex) in your commands. Think of regex as boolean search operations (using quotation marks to search for exact phrases or the minus sign to exclude words) on steroids — they allow you to define a pattern in a string of text so that you can perform some action on the output. Here are some real-world examples:

  1. If you have a long list of phone numbers in a variety of formats, you could define a script that would give you a consistent output based on a regular expression — e.g.: (###) ###-#### for the U.S. phone numbers format.
  2. If you want to quickly rename a group of files to a specific case — from kebab-case to CamelCase or anything in between.

I highly recommend watching Wes Bos’ Command Line Power User series — or at the very least his intro video which will give you a good idea about a few essentials commands that you can use.

Here are some basic terminal commands* to help you getting started:

  1. cd stands for “Change Directory”, type this and then a file or a folder path to go — note that you can type a folder name but it needs to be inside your current folder to go to it.
  2. ls lists the files and folders in your current folder.
  3. pwd stands for “Print Working Directory” — this will list out where you currently are in your computer.
  4. mkdir and a folder name will create a folder in your working directory.
  5. using cd with .. takes you one level up — if you’re in /users/username/documents/2019 and you enter cd ../.. you’ll end up in /users/username.
  6. Bonus tip — hitting the Tab key will autocomplete as you type a folder/file path.

Note: The following will work on the Windows command line (cmd):

  • cd, cd .., mkdir, Tab key for path autocomplete (ls and pwd won’t work).

The more modern Windows command line (Windows PowerShell) supports all of them:

  • cd, cd .., ls, pwd, mkdir, and Tab for path autocomplete.

For a complete list of commands available in PowerShell, check this Microsoft’ Help page “Using Familiar Command Names”.

Mass-File Management

You can manipulate files and folders en masse via the terminal — here are a few ideas:

  1. You can create three years of folders with subfolders for each month in a single command — using mkdir -p and {list-of-years}/{list-of-months} will create folders for each year with subfolders for each month. Use your imagination, I’m sure you can put this to good use!
  2. You can quickly clean up your desktop by using mv Screen\ Shot* Screenshots — this will move all of your files that start with “Screen Shot” to a folder named “Screenshots”.
A screenshot of a terminal window showing the commands and output of a folder creation script.
Create 36 folders on your computer with a single line of code! (Large preview)

Note: These two examples will most likely only work in *nix environments — but the theory still applies. And Windows PowerShell is also a very powerful command line tool, you just need to learn its features and specific commands.

Scripting And Maintenance

Now that we have a glimpse into the power of regular expressions and the options available in the terminal we can start combining those things into scripts. One very simple, yet powerful and commonly used script is Mike G’s file renamer:

criteria=$  1  re_match=$  2  replace=$  3  for i in $  ( ls *$  criteria* );   do      src=$  i      tgt=$  (echo $  i | sed -e "s/$  re_match/$  replace/")      mv $  src $  tgt  done

What this script allows you to do, is define the scope (criteria), define what you’d like to change (re_match), and what you’d like to change it to (replace) — and then execute it.

There are countless other scripts that you can create beyond creating and renaming files — Vlad’s Batch Resizing script is an excellent example of the time-saving capabilities that you can create using bash scripts.

Advanced Tips And Tricks

Something I have found over the years is that regularly resetting my computer and reinstalling the operating system helps it stay relatively clutter-free and prevents the slowdowns everyone experiences after years of digital detritus that accumulates on harddrives. For many, the prospect of wiping a computer and re-setting everything back at best sounds like a few days of work, and at worst an impossible nightmare that you may never recover from.

But it doesn’t have to be — by using a few command-line tools, once you’ve backed up, wiped, and reinstalled your OS, you can install not only your list of favorite apps, but also fonts in a matter of minutes using Homebrew. (Homebrew is for Mac and Linux only. For Windows, try Chocolatey which is a solid alternative.)

If you’re interested — we’ve created an easy-to-follow setup guide to get your computer in good shape for most development. Our guide is for macOS, but Owen Williams has written a solid guide for Windows as well.

If you don’t have the time for Wes’ entire series of tutorials about the command line — at the very least I highly recommend the following stack:

  1. Oh My ZSH
  2. zsh-autosuggestions
  3. zsh-syntax-highlighting
  4. z-jump-around

Choosing A Text Editor

There are many options when it comes to choosing a code editor — Sublime Text and VS Code (Visual Studio Code) are the two I have the most experience with and am currently using.

Sublime Text was one of the earlier text editors that became popular with front-end developers — it was the gold standard up until a few years ago. Features like multiple cursors, a powerful package manager, and highly customizable shortcuts that allowed you to quickly navigate in and between files and folders. Not to mention it was an incredibly lightweight and fast application which made it an easy choice.

VS Code (Visual Studio Code) came on the scene around 2015, it took a while for people to switch from Atom and Sublime, but VS Code has established itself as many developers’ favorite editor. In addition to pretty much all of Sublime’s features, VS Code differentiated itself with a built-in terminal and tight integration with Git. In addition, Visual Studio Code has a rich plugin ecosystem that allows you to extend and customize your environment to your heart’s delight.

All that is to say — you don’t need to be a developer to appreciate the features of a good code editor. I have found many uses for it in my daily work; two, in particular, are the ability to use multiple cursors, and using regex to find-and-replace text across folders of files. Let’s take a closer look at both.

Editing With Multiple Cursors

Picture your typical word processor — that blinking vertical line that shows where the text you’re entering will go? Now picture the ability to add more than one cursor to this window so that whatever you type will appear wherever there is a cursor!

This might not be blowing your mind just yet — so here’s an example that shows a few ways that an advanced text editor can help you create everyday efficiencies in your workflow.

A screencap showing a list of names being manipulated and turned into a list of email addresses.
Mass-editing in a text editor is much faster and more intuitive than in a spreadsheet. (Large preview)

Here we have a list of names that we need to convert into email addresses — we’d also like to make them all lowercase and then sort them alphabetically. This can be done with a few keystrokes.

Using a text editor to quickly manipulate lots of text in Sublime Text (short video).

Once you paste the list in, Cmd + Shift + P brings up the Command Palette (fancy term for a searchable menu that gives you all the available functionalities). You can basically type in this menu what you want to do, pretty much anything you can do to text is available here. If it’s not, there’s likely a plugin or an extension that you can find.

We’re able to change the case and sort the lines in a matter of seconds — then pressing Ctrl + Shift + arrow keys adds cursors, then whatever we type gets added to every line — in this case, we’re turning the names into email addresses, but your wild imagination could find myriad other ways to use this.

You might be saying — well I can do this in Excel or Google Sheets, which is true, but I have found that it is a lot quicker to handle these types of things in a text editor. You avoid having to write formulas and select things with a mouse.

Which Code Editor Should I Use?

I’m a designer — so of course, my answer is “it depends”.

  • If you’re new to these concepts, I would recommend getting a free trial of Sublime — it continues to be a very lightweight app and does not consume too many system resources. You can customize Sublime’s key bindings (fancy word for hotkeys) and extend its built-in functionality with plugins.
  • If you’ve been using Sublime, Atom, or another editor — I’d recommend checking out VS Code as well. The team at Microsoft has really done an excellent job making it a powerful, yet easy-to-use text editor.

Personally, I use both editors — Sublime is lightning quick and opens in a fraction of a second allowing me to easily paste and manipulate text. But when I want to get some more serious work done, I use VS Code. It’s difficult to top the all-in-one package that VS Code provides — a vibrant plugin and extension ecosystem, powerful command palette, and hyper-customizable interface means you can really make it your own. Not to mention the fact that Microsoft is very incentivized to ensure that it’s a first-class experience for developer productivity.

Conclusion, And What’s Next?

In this first article, you will have learned the basics of the terminal, a few productivity hacks to get you started, and should have a better idea of what code editor to choose. In the next part, we’ll continue with the topics of version control, HTML and CSS, and an introduction to engineering principles.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
18 Mar

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

by TBSCategories: News

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

How Should Designers Learn To Code? The Terminal And Text Editors (Part 1)

Paul Hanaoka

As a designer with many years of experience, I often encourage my colleagues and reports to pick up some coding skills. While many are open to the idea, others balk at the notion. I usually hear some variation of “I didn’t study design to become a developer.” Although this is a valid concern, I’d like to emphasize two points: a better understanding of the materials usually leads to better outcomes, and there is an important distinction between “coding” and “software engineering.”

This two-part series of articles should be useful for any designers out there who’d like to gain also some coding skills.

Understanding The Raw Materials

Contrary to what some may think, design isn’t about creating beautiful mockups, it’s about delivering an intuitive, functional experience to the end user. That simply can’t be done without an understanding of the building blocks of a solution. An architect isn’t going to be very good at her job if she doesn’t understand the materials her plans demand and a designer isn’t going to be very good if he doesn’t understand the materials that make his designs come to life — the code. Experience with coding helps designers understand what’s possible and what’s not and whether or not their designs will be able to effectively perform their desired functions.

I also reassure my colleagues that knowledge of coding doesn’t mean one has to become an engineer. The two refer to different, though related, skill sets. As Kyle Thayer, a PhD candidate at the University of Washington recently wrote, the field of computer science (or engineering) is about giving students “an overview of the scientific field of computing”:

“The purpose of a Computer Science degree is to give students an overview of the scientific field of computing. While this includes some programming, programming is done primarily for the purpose of learning about other areas (e.g., operating systems, algorithms, machine learning, human-computer interaction). A CS degree is a good first step into the academic field of computer science.”

— Kyle Thayer

By contrast, coding simply means becoming familiar enough with a given programming language to complete a task. Asking someone to learn basic HTML or JavaScript does not necessitate their becoming a full-stack software architect. Despite what some might think, forking a repo and copy/pasting Stack Overflow answers in does not make you a software engineer — but it can increase the value you bring as a designer to a product development team.

What About “Low Code”?

Some may say that we’re entering a low code future where designers (and developers) are able to build applications through drag-and-drop functionality and a GUI (graphical user interface). So taking the time to learn a programming language isn’t “worth it.” The emergence of tools like Webflow, Modulz, FramerX, UXPin, etc., seems to support this line of reasoning. And this can be very true for many applications — it’s easier than ever to create a site or app without a single line of code. However, if you don’t understand the underlying principles, you will be capping the value you can deliver with a low code application.

Logos and screenshots showing the code behind tools developed by companies like Modulz, Studio.Design, FramerX, and others.
Modulz, Studio.Design, FramerX, and other apps — there’s still a lot of code in there… (Large preview)

We’re also not yet at the point where you can build enterprise-scale applications with low code platforms. As designers we have to work in the world we live in, not the one we imagine is coming.

That being said, everyone brings a unique blend of skills to the table. Knowledge of code is not an absolute necessity and it should just be encouraged, not required.

Where To Start?

There is an endless amount of tools, languages, schools, guides, and other resources available for anyone who has access to the internet — so where to begin? An important disclaimer — I am by no means an expert, or anything close to a software engineer — and the following are insights from my personal experience, not a guaranteed path to success.

Many of the designers/developers I know have usually started hacking HTML and CSS templates on sites like MySpace, Geocities, Tumblr, Neopets, or others. Now that I have sufficiently dated myself, for anyone starting out today, I would recommend beginning in your friendly command-line interface (CLI) shell.

The Terminal: An Essential Tool

The go-to application for Hollywood directors whenever there’s a computer hacker on the screen, the terminal is simply an interface that allows you to execute actions via a text input rather than the graphical user interface (GUI) that most people are accustomed to. I’ll let real developers explain the intricacies and technical how-to, but for our purposes it’s good enough to know that familiarizing yourself with the CLI is beneficial for a number of reasons.

The terminal gives you access to your computer’s file and folder structure — the same way that you click through Finder or Explorer, you navigate using your keyboard in the terminal. It definitely takes some time getting used to, but developing your mental model in this area is foundational to working in code.

Like a lot of designers, I am using the macOS environment (formerly known as OS X), but the following applies to other *nix operating systems (Linux, Unix), and also to Windows PowerShell. While there is a lot of overlap between different modern operating systems, there are some differences that I will do my best to highlight.

Note: For a more complete introduction to the terminal, I recommend reading Paul Tero’s article, “Introduction To Linux Commands”.

Regular Expressions

A key feature in a CLI is the ability to use regular expressions (regex) in your commands. Think of regex as boolean search operations (using quotation marks to search for exact phrases or the minus sign to exclude words) on steroids — they allow you to define a pattern in a string of text so that you can perform some action on the output. Here are some real-world examples:

  1. If you have a long list of phone numbers in a variety of formats, you could define a script that would give you a consistent output based on a regular expression — e.g.: (###) ###-#### for the U.S. phone numbers format.
  2. If you want to quickly rename a group of files to a specific case — from kebab-case to CamelCase or anything in between.

I highly recommend watching Wes Bos’ Command Line Power User series — or at the very least his intro video which will give you a good idea about a few essentials commands that you can use.

Here are some basic terminal commands* to help you getting started:

  1. cd stands for “Change Directory”, type this and then a file or a folder path to go — note that you can type a folder name but it needs to be inside your current folder to go to it.
  2. ls lists the files and folders in your current folder.
  3. pwd stands for “Print Working Directory” — this will list out where you currently are in your computer.
  4. mkdir and a folder name will create a folder in your working directory.
  5. using cd with .. takes you one level up — if you’re in /users/username/documents/2019 and you enter cd ../.. you’ll end up in /users/username.
  6. Bonus tip — hitting the Tab key will autocomplete as you type a folder/file path.

Note: The following will work on the Windows command line (cmd):

  • cd, cd .., mkdir, Tab key for path autocomplete (ls and pwd won’t work).

The more modern Windows command line (Windows PowerShell) supports all of them:

  • cd, cd .., ls, pwd, mkdir, and Tab for path autocomplete.

For a complete list of commands available in PowerShell, check this Microsoft’ Help page “Using Familiar Command Names”.

Mass-File Management

You can manipulate files and folders en masse via the terminal — here are a few ideas:

  1. You can create three years of folders with subfolders for each month in a single command — using mkdir -p and {list-of-years}/{list-of-months} will create folders for each year with subfolders for each month. Use your imagination, I’m sure you can put this to good use!
  2. You can quickly clean up your desktop by using mv Screen\ Shot* Screenshots — this will move all of your files that start with “Screen Shot” to a folder named “Screenshots”.
A screenshot of a terminal window showing the commands and output of a folder creation script.
Create 36 folders on your computer with a single line of code! (Large preview)

Note: These two examples will most likely only work in *nix environments — but the theory still applies. And Windows PowerShell is also a very powerful command line tool, you just need to learn its features and specific commands.

Scripting And Maintenance

Now that we have a glimpse into the power of regular expressions and the options available in the terminal we can start combining those things into scripts. One very simple, yet powerful and commonly used script is Mike G’s file renamer:

criteria=$  1  re_match=$  2  replace=$  3  for i in $  ( ls *$  criteria* );   do      src=$  i      tgt=$  (echo $  i | sed -e "s/$  re_match/$  replace/")      mv $  src $  tgt  done

What this script allows you to do, is define the scope (criteria), define what you’d like to change (re_match), and what you’d like to change it to (replace) — and then execute it.

There are countless other scripts that you can create beyond creating and renaming files — Vlad’s Batch Resizing script is an excellent example of the time-saving capabilities that you can create using bash scripts.

Advanced Tips And Tricks

Something I have found over the years is that regularly resetting my computer and reinstalling the operating system helps it stay relatively clutter-free and prevents the slowdowns everyone experiences after years of digital detritus that accumulates on harddrives. For many, the prospect of wiping a computer and re-setting everything back at best sounds like a few days of work, and at worst an impossible nightmare that you may never recover from.

But it doesn’t have to be — by using a few command-line tools, once you’ve backed up, wiped, and reinstalled your OS, you can install not only your list of favorite apps, but also fonts in a matter of minutes using Homebrew. (Homebrew is for Mac and Linux only. For Windows, try Chocolatey which is a solid alternative.)

If you’re interested — we’ve created an easy-to-follow setup guide to get your computer in good shape for most development. Our guide is for macOS, but Owen Williams has written a solid guide for Windows as well.

If you don’t have the time for Wes’ entire series of tutorials about the command line — at the very least I highly recommend the following stack:

  1. Oh My ZSH
  2. zsh-autosuggestions
  3. zsh-syntax-highlighting
  4. z-jump-around

Choosing A Text Editor

There are many options when it comes to choosing a code editor — Sublime Text and VS Code (Visual Studio Code) are the two I have the most experience with and am currently using.

Sublime Text was one of the earlier text editors that became popular with front-end developers — it was the gold standard up until a few years ago. Features like multiple cursors, a powerful package manager, and highly customizable shortcuts that allowed you to quickly navigate in and between files and folders. Not to mention it was an incredibly lightweight and fast application which made it an easy choice.

VS Code (Visual Studio Code) came on the scene around 2015, it took a while for people to switch from Atom and Sublime, but VS Code has established itself as many developers’ favorite editor. In addition to pretty much all of Sublime’s features, VS Code differentiated itself with a built-in terminal and tight integration with Git. In addition, Visual Studio Code has a rich plugin ecosystem that allows you to extend and customize your environment to your heart’s delight.

All that is to say — you don’t need to be a developer to appreciate the features of a good code editor. I have found many uses for it in my daily work; two, in particular, are the ability to use multiple cursors, and using regex to find-and-replace text across folders of files. Let’s take a closer look at both.

Editing With Multiple Cursors

Picture your typical word processor — that blinking vertical line that shows where the text you’re entering will go? Now picture the ability to add more than one cursor to this window so that whatever you type will appear wherever there is a cursor!

This might not be blowing your mind just yet — so here’s an example that shows a few ways that an advanced text editor can help you create everyday efficiencies in your workflow.

A screencap showing a list of names being manipulated and turned into a list of email addresses.
Mass-editing in a text editor is much faster and more intuitive than in a spreadsheet. (Large preview)

Here we have a list of names that we need to convert into email addresses — we’d also like to make them all lowercase and then sort them alphabetically. This can be done with a few keystrokes.

Using a text editor to quickly manipulate lots of text in Sublime Text (short video).

Once you paste the list in, Cmd + Shift + P brings up the Command Palette (fancy term for a searchable menu that gives you all the available functionalities). You can basically type in this menu what you want to do, pretty much anything you can do to text is available here. If it’s not, there’s likely a plugin or an extension that you can find.

We’re able to change the case and sort the lines in a matter of seconds — then pressing Ctrl + Shift + arrow keys adds cursors, then whatever we type gets added to every line — in this case, we’re turning the names into email addresses, but your wild imagination could find myriad other ways to use this.

You might be saying — well I can do this in Excel or Google Sheets, which is true, but I have found that it is a lot quicker to handle these types of things in a text editor. You avoid having to write formulas and select things with a mouse.

Which Code Editor Should I Use?

I’m a designer — so of course, my answer is “it depends”.

  • If you’re new to these concepts, I would recommend getting a free trial of Sublime — it continues to be a very lightweight app and does not consume too many system resources. You can customize Sublime’s key bindings (fancy word for hotkeys) and extend its built-in functionality with plugins.
  • If you’ve been using Sublime, Atom, or another editor — I’d recommend checking out VS Code as well. The team at Microsoft has really done an excellent job making it a powerful, yet easy-to-use text editor.

Personally, I use both editors — Sublime is lightning quick and opens in a fraction of a second allowing me to easily paste and manipulate text. But when I want to get some more serious work done, I use VS Code. It’s difficult to top the all-in-one package that VS Code provides — a vibrant plugin and extension ecosystem, powerful command palette, and hyper-customizable interface means you can really make it your own. Not to mention the fact that Microsoft is very incentivized to ensure that it’s a first-class experience for developer productivity.

Conclusion, And What’s Next?

In this first article, you will have learned the basics of the terminal, a few productivity hacks to get you started, and should have a better idea of what code editor to choose. In the next part, we’ll continue with the topics of version control, HTML and CSS, and an introduction to engineering principles.

Anything Amiss?

There’s a good chance that something in this post was obscure, obtuse, and/or obsolete and I’d love the opportunity to make it better! Please leave a comment below, DM me, or @mention me on Twitter so I can improve.

Smashing Editorial (mb, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us