Setting the Right Boundaries for Your Web Design Clients

/0 Comments/in /by

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/CTPUzX4yrl4/

Providing awesome customer service should be among the top goals of any freelance web designer. Too often we hear about those who never respond to client requests or are otherwise difficult to deal with. Usually it seems we hear these stories from new clients that have come to us after a “bad experience” with another designer.

Of course, most of us will go out of our way to make a client happy. Even if it means leaving our comfort zone or bending our own rule – we make the best effort that we possibly can.

But as you gain experience, you start to realize that there is an incredibly fine line between pleasing clients and becoming a human doormat. This is when you need to take a step back and assess what, if any, boundaries you have put in place. What, you don’t have boundaries? Well let’s take care of that right here and now.

Knowing Where to Draw the Line

Figuring out which kinds of boundaries you need to put up can be difficult. While you don’t want to be taken advantage of, you also don’t want to come off as either aloof or unwilling to help. To find the right answer, you have to look within yourself.

Boundaries are a very personal thing and chances are that yours won’t be the same as mine. As our personalities are different, so are the “lines in the sand” that we draw. But in general, you’ll want to consider the following scenarios:

Clients Who Expect You to Work Outside of Normal Business Hours
This one is a symptom of the always-connected world we live in. Many businesses now have a culture that permits after-hours communication between team members. Therefore, we’re expected to be ready and available whenever someone needs us. It doesn’t matter if you’re on vacation, at your child’s athletic event or just trying to watch your favorite show.

It’s understandable that not everyone is keen on doing this. In my career, I’ve often responded to non-emergencies after hours and have found that it’s usually something that causes more stress than it’s worth. I end up thinking about whatever subject the client contacted me about and it becomes near impossible to relax.

On the other hand, some people don’t necessarily mind a few quick emails after hours. So it’s up to you to decide how you feel about this kind of expectation. You can either cheerfully reply to messages at the dinner table or you can let it wait until the next business day. A solid compromise might be to reply by saying “Thanks for your note. I’ll get back to you on this first thing tomorrow”. If a client can’t accept that you have a life outside of work, then too bad for them.

Clients Who Expect You to Work Outside of Normal Business Hours

Clients Who Keep Changing Their Mind
We’ve all dealt with clients who flip-flop on various parts of the web design process. Maybe they keep switching colors, suggesting different fonts or even layouts. It can be maddening to a designer who is on a tight deadline or juggling multiple projects.

Some of this can be classified as just the normal back-and-forth of a project. But there can come a point where you are repeatedly asked to change the same thing over and over again. This can be especially frustrating when it comes to the more complex parts of a website.

One of the toughest things I’ve dealt with in this area are times when a client has asked for some sort of functionality that requires a lot of research and development – only to trash it afterwards. It can feel like a colossal waste of time.

The best solution here is to set your limits in writing. Somewhere in your contract, mention that you’re happy to make revisions. But also note that repeated or lengthy changes may lead to extra costs. It may not completely save your sanity, but could provide you with some extra cash for your trouble.

Clients Who Keep Changing Their Mind

Incessant Phone Calls or Emails
There are times when clients will need to reach out to you and you should welcome them to do so. But like anything else, there are some people who will take advantage of your willingness to help. All of the sudden you’re being asked advice on things that are at best vaguely related to their website. Or maybe they assume you’re excited to have them bounce every idea in their head off of you while getting some free access to your expertise.

This puts you in a bit of a no-win situation. You certainly don’t want to continue to provide this person with unlimited free support regarding their poodle’s skin condition. But it’s not particularly easy to say something without causing offense.

Personally, confrontation isn’t my thing. So I look for alternatives whenever possible. I don’t typically recommend this type of behavior, but here it goes. If the calls or messages really are too much and often unrelated to your business relationship with a client – let them sit for awhile. Let your phone go to voicemail and allow emails to sit in your inbox for at least a few hours.

When you do finally get back to them, tell them that you’re sorry for the delayed response and that you’ve been incredibly busy. If you’re not available the minute they have a thought in their head, they might just forget the whole thing. If they still won’t leave you alone, then it might be time to be a little more firm in your response.

Incessant Phone Calls or Emails

Chronically Late Payers
Ah, there’s nothing like the feeling of hustling to get a client’s “must-have” request done in record time and then waiting six months to be paid. Perhaps there’s no other situation that will make a freelancer feel more used and unappreciated.

This may also be the easiest of all boundaries to set. If a client is consistently behind in paying, they are not worth rushing around for. When you run into someone who is always hard to get a hold of when it’s time to pay an invoice, tell them that you can’t spend your time working on projects that you may not receive payment for.

Better yet, add a clause to your contracts that specifies late fees or even a refusal of service if a client is several months behind. If someone’s not paying you, why deal with them at all?

Chronically Late Payers

It’s Up to You

The thing about setting boundaries is that you have to be the one to both enact and enforce them. Because, while you can declare that you won’t stand for certain client behavior, it doesn’t mean much if you don’t actually follow through. It’s tough to do, but also quite necessary.

The more your business grows, the more you’ll need to stand up for yourself and your interests. Do it now, before it’s too late!


50+ Sites to Download Free Sound Effects for Almost Everything

/0 Comments/in /by

Original Source: https://www.hongkiat.com/blog/download-free-sound-effects/

Best websites to download different kinds of music, sound effects, vocals, and audio snippets etc. for free.

The post 50+ Sites to Download Free Sound Effects for Almost Everything appeared first on…

Visit hongkiat.com for full content.

Typographic Illustration for ESPN NEXT

/0 Comments/in /by

Original Source: http://feedproxy.google.com/~r/abduzeedo/~3/jmJs15SbvPc/typographic-illustration-espn-next

Typographic Illustration for ESPN NEXT

Typographic Illustration for ESPN NEXT

abduzeedo
Apr 19, 2018

Pablo Olivera recently had the privilege to work with ESPN The Magazine on their NEXT Feature. The project included a typographic Intro Illustration a flat logotype of the Intro type and some custom letters which later turned into a font.

The feature is about up coming and young star athletes, the next stars of their specific sports. The intro piece needed to have a futuristic feel to it so we used 3D type with LED styled lighting inner strips.

The sports featured included Football, Baseball, Hockey and Basketball. I used line illustrations from each of the sports respective playing field/court to surround the type.

The custom font took its styling form the intro type, keeping the inline and geometric angles to tie the feature together nicely. The font is a case alternative font allowing the Inline version or the solid version to be used by lower case or uppercase.

Typographic Illustration

For more information about Pablo Olivera check out:

INSTAGRAM
FACEBOOK
DRIBBBLE  

Typography
illustration


Clean Code with ES6 Default Parameters & Property Shorthands

/0 Comments/in /by

Original Source: https://www.sitepoint.com/es6-default-parameters/

Creating a method also means writing an API — whether it’s for yourself, another developer on your team, or other developers using your project. Depending on the size, complexity, and purpose of your function, you have to think of default settings and the API of your input/output.

Default function parameters and property shorthands are two handy features of ES6 that can help you write your API.

ES6 Default Parameters

Let’s freshen up our knowledge quickly and take a look at the syntax again. Default parameters allow us to initialize functions with default values. A default is used when an argument is either omitted or undefined — meaning null is a valid value. A default parameter can be anything from a number to another function.

// Basic syntax
function multiply (a, b = 2) {
return a * b;
}
multiply(5); // 10

// Default parameters are also available to later default parameters
function foo (num = 1, multi = multiply(num)) {
return [num, multi];
}
foo(); // [1, 2]
foo(6); // [6, 12]

A real-world example

Let’s take a basic function and demonstrate how default parameters can speed up your development and make the code better organized.

Our example method is called createElement(). It takes a few configuration arguments, and returns an HTML element. The API looks like this:

// We want a <p> element, with some text content and two classes attached.
// Returns <p class=”very-special-text super-big”>Such unique text</p>
createElement(‘p’, {
content: ‘Such unique text’,
classNames: [‘very-special-text’, ‘super-big’]
});

// To make this method even more useful, it should always return a default
// element when any argument is left out or none are passed at all.
createElement(); // <div class=”module-text default”>Very default</div>

The implementation of this won’t have much logic, but can become quite large due to it’s default coverage.

// Without default parameters it looks quite bloated and unnecessary large.
function createElement (tag, config) {
tag = tag || ‘div’;
config = config || {};

const element = document.createElement(tag);
const content = config.content || ‘Very default’;
const text = document.createTextNode(content);
let classNames = config.classNames;

if (classNames === undefined) {
classNames = [‘module-text’, ‘default’];
}

element.classList.add(…classNames);
element.appendChild(text);

return element;
}

So far, so good. What’s happening here? We’re doing the following:

setting default values for both our parameters tag and config, in case they aren’t passed (note that some linters don’t like parameter reassigning)
creating constants with the actual content (and default values)
checking if classNames is defined, and assigning a default array if not
creating and modifying the element before we return it.

Now let’s take this function and optimize it to be cleaner, faster to write, and so that it’s more obvious what its purpose is:

// Default all the things
function createElement (tag = ‘div’, {
content = ‘Very default’,
classNames = [‘module-text’, ‘special’]
} = {}) {
const element = document.createElement(tag);
const text = document.createTextNode(content);

element.classList.add(…classNames);
element.appendChild(text);

return element;
}

We didn’t touch the function’s logic, but removed all default handling from the function body. The function signature now contains all defaults.

Let me further explain one part, which might be slightly confusing:

// What exactly happens here?
function createElement ({
content = ‘Very default’,
classNames = [‘module-text’, ‘special’]
} = {}) {
// function body
}

We not only declare a default object parameter, but also default object properties. This makes it more obvious what the default configuration is supposed to look like, rather than only declaring a default object (e.g. config = {}) and later setting default properties. It might take some additional time to get used to it, but in the end it improves your workflow.

Of course, we could still argue with larger configurations that it might create more overhead and it’d be simpler to just keep the default handling inside of the function body.

Continue reading %Clean Code with ES6 Default Parameters & Property Shorthands%

Wacom Cintiq Pro 32: hands on review

/0 Comments/in /by

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/jY2rWNRR7OI/wacom-cintiq-pro-32

If you've have the chance to use one of Wacom’s large-format pen displays, you'll know why these drawing tablets are used in studios around the world. 

Wacom’s previous flagship model, the Cintiq 27QHD, provided artists with an impressive 27 inches of screen space at a resolution of 2,560 x 1,400 pixels. As the push for Ultra High Definition content increases, however, artists are beginning to need more resolution and screen space than ever before.

Step up the Wacom Cintiq Pro 32. It isn't yet on sale – but we got our hands on the latest model in Wacom’s Cintiq family to give it a spin…

The best cheap Wacom tablet deals 2018
Wacom Cintiq Pro 32: specs

The Wacom Cintiq Pro 32 features a 4K UHD display spanning an impressive 32 inches, with a resolution of 3,840 x 2,160 pixels. With four times the pixels of a standard 1080p display, the Cintiq Pro 32 provides plenty of work space, allowing users to display important toolbars without eating into that precious screen space.

Wacom Cintiq Pro 32: display

Unlike the Wacom Cintiq Pro 24 (another new release) and previous generation Cintiqs, which came in touch and non-touch variants, the Wacom Cintiq Pro 32 comes with touch functionality as standard. Despite the larger screen, the Cintiq Pro 32 is only 8.5cm wider and 4cm taller but uses a smaller bezel, meaning more screen space without taking over too much desk.

Both Cintiq Pro models come with Wacom’s Pro Pen 2, featuring 8,192 levels of sensitivity, plus tilt-response for a more natural and virtually lag-free drawing experience. The displays also come with the ExpressKey Remote, a controller that houses the buttons and touch ring commonly found along one edge of the earlier Cintiq models.

The separation of this remote from the main body of the display allows for seamless switching between left and right-handed modes, and the non-slip backing means the remote can be placed anywhere on the face of the device, with magnetic strips down either side to hold the remote in place when the display is positioned vertically.

Person using a Wacom Cintiq Pro 32 to illustrate

8,192 levels of pressure sensitivity and unparalleled tilt recognition means that every stroke is naturally precise

In order to rotate the display more freely, the optional Ergo Stand is required. This allows the display to be set vertically like a standard monitor, and horizontally at standing height or desk level. Out of the box, the back of the display features two fl ip-out legs to support the device at a 20-degree angle to the desk.

Reducing glare

When used in a bright studio environment, glare may present an issue. Compared to the 27QHD, which has a more reflective screen coating, the Pro 32 has taken steps towards solving this issue with an etched glass screen that diffuses those harsh reflections. 

This is also helped by turning off room lighting and using a desk light, or by using the Ergo Stand to angle the device away from the light source.

Connectivity

Towards the rear of the display, there is a panel which can be removed to reveal the various ports and sockets used to connect your display to your work machine. These include:

1x HDMI 1x DisplayPort 1x USB Type-C 1x USB 3.0 1x Power socket

With four times the pixels of a standard 1080p display, users to display important toolbars without eating into precious screen space.

Glen Southern

Located around the side edges of the display are four USB 3.0 ports, with two on either side for device connectivity such as charging the ExpressKey Remote. There is also a 3.5mm headphone jack on the left side and a SD card VERDICT slot at the right, both located under the USB ports. 

At the top edge of the display is the power switch and LED power indicator. On the top left above the screen, there is a series of touch buttons that enable you to call various functions from your machine such as the on-screen keyboards, access Wacom settings or enable and disable the touch function.

Extra space

There is also a button that enables toggling between the display input mode for the device which was absent from the 27QHD, meaning cables no longer have to be swapped between machines. In the studio, we have a USB-C enabled laptop plugged in via the included USB-C cable, with a workstation plugged into the display through a USB 3.0 and DisplayPort cable. This means machines can be swapped with the press of a button and with no rummaging around under the desk. 

The use of the USB-C for this generation greatly reduces cable clutter, as both the display signal and USB connectivity can be run through one cable. Unlike the Cintiq MobileStudio Pro, the Pro 32 does not feature any external USB-C ports, which will be welcomed by those who are unprepared to upgrade all of their devices to USB-C.The Cintiq Pro 32 offers a large screen size, with the resolution perfect for displaying UHD content.

The extra space is also ideal for users who require specific toolbars and custom user interface layouts without limiting canvas or viewport size. Additionally, there is also the option to transform your Cintiq Pro into a powerful standalone creative pen computer with the Wacom Cintiq Pro Engine PC module.

The Wacom Cintiq Pro 32 is due to ship in Spring 2018.

This article was originally published in issue 233 of 3D World, the world's best-selling magazine for CG artists. Buy issue 233 here or subscribe here.

Also read: The best cheap Wacom tablet deals


Which Podcasts Should Web Designers And Developers Be Listening To?

/0 Comments/in /by

Original Source: https://www.smashingmagazine.com/2018/04/podcasts-web-designers-developers/

Which Podcasts Should Web Designers And Developers Be Listening To?

Which Podcasts Should Web Designers And Developers Be Listening To?

Ricky Onsman

2018-04-18T13:45:00+02:00
2018-04-18T13:58:52+00:00

We asked the Smashing community what podcasts they listened to, aiming to compile a shortlist of current podcasts for web designers and developers. We had what can only be called a very strong response — both in number and in passion.

First, we winnowed out the podcasts that were on a broader theme (e.g. creativity, mentoring, leadership), on a narrower theme (e.g. on one specific WordPress theme) or on a completely different theme (e.g. car maintenance — I’m sure it was well-intentioned).

When we filtered out those that had produced no new content in the last three months or more (although then we did have to make some exceptions, as you’ll see), and ordered the rest according to how many times they were nominated, we had a graded shortlist of 55.

Agreed, that’s not a very short shortlist.

So, we broke it down into five more reasonably sized shortlists:

Podcasts for web developers
Podcasts for web designers
Podcasts on the web, the Internet and technology
Business podcasts for web professionals
Podcasts that don’t have recent episodes (but do have great archives)

Obviously, it’s highly unlikely anyone could — or would want to — listen to every episode of every one of these podcasts. Still, we’re pretty sure that any web designer or developer will find a few podcasts in this lot that will suit their particular listening tastes.

Getting workflow just right ain’t an easy task. So are proper estimates. Or alignment among different departments. That’s why we’ve set up ‘this-is-how-I-work’-sessions — with smart cookies sharing what works well for them. A part of the Smashing Membership, of course.

Explore features →

Smashing TV, with live sessions for professional designers and developers.

A couple of caveats before we begin:

We don’t claim to be comprehensive. These lists are drawn from suggestions from readers (not all of which were included) plus our own recommendations.
The descriptions are drawn from reader comments, summaries provided by the podcast provider and our own comments. Podcast running times and frequency are, by and large, approximate. The reality is podcasts tend to vary in length, and rarely stick to their stated schedule.
We’ve listed each podcast once only, even though several could qualify for more than one list.
We’ve excluded most videocasts. This is just for listening (videos probably deserve their own article).

Podcasts For Web Developers

Syntax

SyntaxWes Bos and Scott Tolinski dive deep into web development topics, explaining how they work and talking about their own experiences. They cover from JavaScript frameworks like React, to the latest advancements in CSS to simplifying web tooling. 30-70 minutes. Weekly.

Developer Tea

Developer TeaA podcast for developers designed to fit inside your tea break, a highly-concentrated, short, frequent podcast specifically for developers who like to learn on their tea (and coffee) break. The Spec Network also produces Design Details. 10-30 minutes. Every two days.

Web Platform Podcast

Web Platform PodcastCovers the latest in browser features, standards, and the tools developers use to build for the web of today and beyond. Founded in 2014 by Erik Isaksen. Hosts Danny, Amal, Leon, and Justin are joined by a special guest to discuss the latest developments. 60 minutes. Weekly.

Devchat Podcasts

Devchat PodcastsFourteen podcasts with a range of hosts that each explore developments in a specific aspect of development or programming including Ruby, iOS, Angular, JavaScript, React, Rails, security, conference talks, and freelancing. 30-60 minutes. Weekly.

The Bike Shed

The Bike ShedHosts Derek Prior, Sean Griffin, Amanda Hill and guests discuss their development experience and challenges with Ruby, Rails, JavaScript, and whatever else is drawing their attention, admiration, or ire at any particular moment. 30-45 minutes. Weekly.

NodeUp

NodeUpHosted by Rod Vagg and a series of occasional co-hosts, this podcast features lengthy discussions with guests and panels about Node.js and Node-related topics. 30-90 minutes. Weekly / Monthly.

.NET Rocks

.NET RocksCarl Franklin and Richard Campbell host an internet audio talk show for anyone interested in programming on the Microsoft .NET platform, including basic information, tutorials, product developments, guests, tips and tricks. 60 minutes. Twice a week.

Three Devs and a Maybe

Three Devs and a MaybeJoin Michael Budd, Fraser Hart, Lewis Cains, and Edd Mann as they discuss software development, frequently joined by a guest on the show’s topic, ranging from daily developer life, PHP, frameworks, testing, good software design and programming languages. 45-60 minutes. Weekly.

Weekly Dev Tips

Weekly Dev TipsHosted by experienced software architect, trainer, and entrepreneur Steve Smith, Weekly Dev Tips offers a variety of technical and career tips for software developers. Each tip is quick and to the point, describing a problem and one or more ways to solve that problem. 5-10 minutes. Weekly.

devMode.fm

devMode.fmDedicated to the tools, techniques, and technologies used in modern web development. Each episode, Andrew Welch and Patrick Harrington lead a cadre of hosts discussing the latest hotness, pet peeves, and the frontend development technologies we use. 60-90 minutes. Twice a week.

CodeNewbie

CodeNewbieStories from people on their coding journey. New episodes published every Monday. The most supportive community of programmers and people learning to code. Founded by Saron Yitbarek. 30-60 minutes. Weekly.

Front End Happy Hour

Front End Happy HourA podcast featuring panels of engineers from @Netflix, @Evernote, @Atlassian and @LinkedIn talking over drinks about all things Front End development. 45-60 minutes. Every two weeks.

Under the Radar

Under the RadarFrom development and design to marketing and support, Under the Radar is all about independent app development. Hosted by David Smith and Marco Arment. 30 minutes. Weekly.

Hanselminutes

HanselminutesScott Hanselman interviews movers and shakers in technology in this commute-time show. From Michio Kaku to Paul Lutus, Ward Cunningham to Kimberly Bryant, Hanselminutes is talk radio guaranteed not to waste your time. 30 minutes. Weekly.

Fixate on Code

Fixate on CodeSince October 2017, Larry Botha from South African design agency Fixate has been interviewing well known achievers in web design and development on how to help front end developers write better code. 30 minutes. Weekly.

Podcasts For Web Designers

99% Invisible

99% InvisibleDesign is everywhere in our lives, perhaps most importantly in the places where we’ve just stopped noticing. 99% Invisible is a weekly exploration of the process and power of design and architecture, from award winning producer Roman Mars. 20-45 minutes. Weekly.

Design Details

Design DetailsA show about the people who design our favorite products, hosted by Bryn Jackson and Brian Lovin. The Spec Network also produces Developer Tea. 60-90 minutes. Weekly.

Presentable

PresentableHost Jeffrey Veen brings over two decades of experience as a designer, developer, entrepreneur, and investor as he chats with guests about how we design and build the products that are shaping our digital future and how design is changing the world. 45-60 minutes. Weekly.

Responsive Web Design

Responsive Web DesignIn each episode, Karen McGrane and Ethan Marcotte (who coined the term “responsive web design”) interview the people who make responsive redesigns happen. 15-30 minutes. Weekly. (STOP PRESS: Karen and Ethan issued their final episode of this podcast on 26 March 2018.)

RWD Podcast

RWD PodcastHost Justin Avery explores new and emerging web technologies, chats with web industry leaders and digs into all aspects of responsive web design. 10-60 minutes. Weekly / Monthly.

UXPodcast

UXPodcastBusiness, technology and people in digital media. Moving the conversation beyond the traditional realm of User Experience. Hosted by Per Axbom and James Royal-Lawson from Sweden. 30-45 minutes. Every two weeks.

UXpod

UXpodA free-ranging set of discussions on matters of interest to people involved in user experience design, website design, and usability in general. Gerry Gaffney set this up to provide a platform for discussing topics of interest to UX practitioners. 30-45 minutes. Weekly / Monthly.

UX-radio

UX-radioA podcast about IA, UX and Design that features collaborative discussions with industry experts to inspire, educate and share resources with the community. Created by Lara Fedoroff and co-hosted with Chris Chandler. 30-45 minutes. Weekly / Monthly.

User Defenders

User DefendersHost Jason Ogle aims to highlight inspirational UX Designers leading the way in their craft, by diving deeper into who they are, and what makes them tick/successful, in order to inspire and equip those aspiring to do the same. 30-90 minutes. Weekly.

The Drunken UX Podcast

The Drunken UX PodcastOur hosts Michael Fienen and Aaron Hill look at issues facing websites and developers that impact the way we all use the web. “In the process, we’ll drink drinks, share thoughts, and hopefully make you laugh a little.” 60 minutes. Twice a week.

UI Breakfast Podcast

UI Breakfast PodcastJoin Jane Portman for conversations about UI/UX design, products, marketing, and so much more, with awesome guests who are industry experts ready to share actionable knowledge. 30-60 minutes. Weekly.

Efficiently Effective

Efficiently EffectiveSaskia Videler keeps us up to date with what’s happening in the field of UX and content strategy, aiming to help content experts, UX professionals and others create better digital experiences. 25-40 minutes. Monthly.

The Honest Designers Show

The Honest Designers ShowHosts Tom Ross, Ian Barnard, Dustin Lee and Lisa Glanz have each found success in their creative fields and are here to give struggling designers a completely honest, under the hood look at what it takes to flourish in the modern world. 30-60 minutes. Weekly.

Design Life

Design LifeA podcast about design and side projects for motivated creators. Femke von Schoonhoven and Charli Prangley (serial side project addicts) saw a gap in the market for a conversational show hosted by two females about design and issues young creatives face. 30-45 minutes. Weekly.

Layout FM

Layout FMA weekly podcast about design, technology, programming and everything else hosted by Kevin Clark and Rafael Conde. 60-90 minutes. Weekly.

Bread Time

Bread TimeGabriel Valdivia and Charlie Deets host this micro-podcast about design and technology, the impact of each on the other, and the impact of them both on all of us. 10-30 minutes. Weekly.

The Deeply Graphic DesignCast

The Deeply Graphic DesignCastEvery episode covers a new graphic design-related topic, and a few relevant tangents along the way. Wes McDowell and his co-hosts also answer listener-submitted questions in every episode. 60 minutes. Every two weeks.

Podcasts On The Web, The Internet, And Technology

The Big Web Show

The Big Web ShowVeteran web designer and industry standards champion Jeffrey Zeldman is joined by special guests to address topics like web publishing, art direction, content strategy, typography, web technology, and more. 60 minutes. Weekly.

ShopTalk

ShopTalkA podcast about front end web design, development and UX. Each week Chris Coyier and Dave Rupert are joined by a special guest to talk shop and answer listener submitted questions. 60 minutes. Weekly.

Boagworld

BoagworldPaul Boag and Marcus Lillington are joined by a variety of guests to discuss a range of web design related topics. Fun, informative and quintessentially British, with content for designers, developers and website owners, something for everybody. 60 minutes. Weekly.

The Changelog

The ChangelogConversations with the hackers, leaders, and innovators of open source. Hosts Adam Stacoviak and Jerod Santo do in-depth interviews with the best and brightest software engineers, hackers, leaders, and innovators. 60-90 minutes. Weekly.

Back to Front Show

Back to Front ShowTopics under discussion hosted by Keir Whitaker and Kieran Masterton include remote working, working in the web industry, productivity, hipster beards and much more. Released irregularly but always produced with passion. 30-60 minutes. Weekly / Monthly.

The Next Billion Seconds

The Next Billion SecondsThe coming “next billion seconds” are the most important in human history, as technology transforms the way we live and work. Mark Pesce talks to some of the brightest minds shaping our world. 30-60 minutes. Every two weeks.

Toolsday

ToolsdayHosted by Una Kravets and Chris Dhanaraj, Toolsday is about the latest in tech tools, tips, and tricks. 30 minutes. Weekly.

Reply All

Reply AllA podcast about the internet, often delving deeper into modern life. Hosted by PJ Vogt and Alex Goldman from US narrative podcasting company Gimlet Media. 30-60 minutes. Weekly.

CTRL+CLICK CAST

CTRL+CLICK CASTDiverse voices from industry leaders and innovators, who tackle everything from design, code and CMS, to culture and business challenges. Focused, topical discussions hosted by Lea Alcantara and Emily Lewis. 60 minutes. Every two weeks.

Modern Web

Modern WebExplores next generation frameworks, standards, and techniques. Hosted by Tracy Lee. Topics include EmberJS, ReactJS, AngularJS, ES2015, RxJS, functional reactive programming. 60 minutes. Weekly.

Relative Paths

Relative PathsA UK based podcast on “web development and stuff like that” for web industry types. Hosted by Mark Phoenix and Ben Hutchings. 60 minutes. Every two weeks.

Business Podcasts For Web Professionals

The Businessology Show

The Businessology ShowThe Businessology Show is a podcast about the business of design and the design of business, hosted by CPA/coach Jason Blumer. 30 minutes. Monthly.

CodePen Radio

CodePen RadioChris Coyier, Alex Vazquez, and Tim Sabat, the co-founders of CodePen, talk about the ins and outs of running a small web software business. The good, the bad, and the ugly. 30 minutes. Weekly.

BizCraft

BizCraftPodcast about the business side of web design, recorded live almost every two weeks. Your hosts are Carl Smith of nGen Works and Gene Crawford of UnmatchedStyle. 45-60 minutes. Every two weeks.

Podcasts That Don’t Have Recent Episodes (But Do Have Great Archives)

Design Review Podcast

Design Review PodcastNo chit-chat, just focused in-depth discussions about design topics that matter. Jonathan Shariat and Chris Liu are your hosts and bring to the table passion and years of experience. 30-60 minutes. Every two weeks. Last episode 26 November 2017.

Style Guide Podcast

Style Guide PodcastA small batch series of interviews (20 in total) on Style Guides, hosted by Anna Debenham and Brad Frost, with high profile designer guests. 45 minutes. Weekly. Last episode 19 November 2017.

True North

True NorthLooks to uncover the stories of everyday people creating and designing, and highlight the research and testing that drives innovation. Produced by Loop11. 15-60 minutes. Every two weeks. Last episode 18 October 2017

UIE.fm Master Feed

UIE.fm Master FeedGet all episodes from every show on the UIE network in this master feed: UIE Book Corner (with Adam Churchill) and The UIE Podcast (with Jared Spool) plus some archived older shows. 15-60 minutes. Weekly. Last episode 4 October 2017.

Let’s Make Mistakes

Let’s Make MistakesA podcast about design with your hosts, Mike Monteiro, Liam Campbell, Steph Monette, and Seven Morris, plus a range of guests who discuss good design, business and ethics. 45-60 minutes. Weekly / Monthly. Last episode 3 August 2017.

Motion and Meaning

Motion and MeaningA podcast about motion for digital designers brought to you by Val Head and Cennydd Bowles, covering everything from the basic principles of animation through to advanced tools and techniques. 30 minutes. Monthly. Last episode 13 December 2016.

The Web Ahead

The Web AheadConversations with world experts on changing technologies and future of the web. The Web Ahead is your shortcut to keeping up. Hosted by Jen Simmons. 60-100 minutes. Monthly. Last episode 30 June 2016.

Unfinished Business

Unfinished BusinessUK designer Andy Clarke and guests have plenty to talk about, mostly on and around web design, creative work and modern life. 60-90 minutes. Monthly. Last episode 28 June 2016. (STOP PRESS: A new episode was issued on 20 March 2018. Looks like it’s back in action.)

Dollars to Donuts

Dollars to DonutsA podcast where Steve Portigal talks with the people who lead user research in their organizations. 50-75 minutes. Irregular. Last episode 10 May 2016.

Any Other Good Ones Missing?

As we noted, there are probably many other good podcasts out there for web designers and developers. If we’ve missed your favorite, let us know about it in the comments, or in the original threads on Twitter or Facebook.

Smashing Editorial
(vf, ra, il)

Sharing Code Between Projects: Lessons Learned In The Trenches

/0 Comments/in /by

Original Source: https://www.smashingmagazine.com/2018/04/sharing-code-between-projects/

Sharing Code Between Projects: Lessons Learned In The Trenches

Sharing Code Between Projects: Lessons Learned In The Trenches

Jonathan Saring

2018-04-25T14:40:51+02:00
2018-04-25T13:20:26+00:00

About a year ago, we came to a crossroad that changed the way we build software today. Like many other teams, we were working on a few things at a time, developing different projects for our web and mobile applications, with shared ingredients in the form of common Node.js code between our back-end repositoriess and microservices, and common React UI components with some slight visual and functional differences between our apps.

As our team grew and code lines multiplied, we began to realize that with every passing day we were writing the same code over and over again. Over time, it became harder to maintain our code base and develop new features with the same speed and efficiency.

Finally, we decided to find a solution that would enable us to share and sync common components of code between our projects. Here is what we learned along our journey, which eventually gave birth to Bit.

Sharing code components between projects

Code components as building blocks. (Large preview)

What if there was a web conference without… slides? Meet SmashingConf Toronto 2018 ?? with live sessions exploring how experts work behind the scenes. Dan Mall, Lea Verou, Sara Soueidan, Seb Lee-Delisle and many others. June 26–27. With everything from live designing to live performance audits.

Check the speakers →

SmashingConf Toronto 2018, with Dan Mall, Sara Soueidan, Lea Verou and many others.

Common Code In The Wild

While Git is great for collaborating on a single repository, sharing code between multiple projects can be more challenging than we think.

To get started, we looked into our own code base to learn how many times we duplicated our own integration to our user service. The unbelievable result was no less than 86 instances. After the initial shock, we started thinking that this must also be happening elsewhere.

Code shared in multiple projects

Using the same code in different places. (Large preview)

We asked some friends working in a few different organizations of various sizes to run a simple copy-and-paste detection on their code base, looking for duplicates of code longer than 100 lines. The result blew us away: On average, more than 30% of their code base was duplicated.

Finally, we decided to look deep into the open-source projects on GitHub, checking for both duplications and re-implementations of a simple isString function in the 10,000 most popular JavaScript GitHub projects.

Amazingly, we found this function was implemented in more than 100 different ways and duplicated over 1,000 times in only 10,000 repositories. Later studies claim that over 50% of the code on GitHub is actually duplicated. We realized we were not the only ones facing this issue.

Looking For A Solution

Before building Bit, we looked for a tool that would help us turn the smaller components that our apps are built from into building blocks that could be shared between our projects and synced across our code base. We also wanted to organize them and make them discoverable for our team. Here’s a short summary of what we learned.

A Micro-Package Arsenal With NPM

At first, we considered publishing all of our UI components, utility functions and smaller modules as packages to NPM. This seemed like the obvious solution for modularity for our software’s building blocks. However, we quickly learned that this solution came with huge overhead.

Trying to publish a few files from our project to NPM forced us to split our repository and create new ones just to share this code. When dealing with hundreds of components, this meant having to maintain and make changes across hundreds of repositories.

We would also have to refactor our code base, removing the newly created packages from their original repositories, boilerplating the packages in the new repositories and so on.

Even then, we had now a simple way to organize these packages and make them easily discoverable to our entire team. Another major problem was the coupling between the packages and the owners of their origin repositories, which made it nearly impossible for other people to quickly make updates to the packages while working on their own projects.

This kind of overhead was too much for us to handle. So, we quickly decided to look for a better way to share our code.

Lerna Monorepos

The next option we came up with was to use Lerna in order to refactor our code base into a few multi-package repositories, often referred to as “monorepos”.

The Hydra of Lerna

Lerna multi-package repository. (Large preview)

The upside of this solution was that it would allow us to maintain and publish all our packages from a single repository. However, this option, too, came with a set of drawbacks, particularly when working with smaller components.

Choosing this option meant we would still have to effectively keep multiple packages with multiple package.json files, multiple build and test environments and a complicated dependency tree to handle between them. Updating these packages must also go through the main repository, still making it hard to modify these package from other projects when working with a few separate monorepos.

For example, take the popular Material-UI React UI library. Even though it uses Lerna to publish five different packages from the same repository, you would still have to install the entire library to use each of its components. Making changes would still have to go through that project as well, and discoverability for these component didn’t improve.

Monorepos can be great for some cases (such as testing or building a project as a whole) and can definitely work for some teams. However, refactoring your entire code base just to share common code between projects while still having to struggle with the issues mentioned above made us drop this option as well.

Shared Libraries

This option was quickly dropped, too. In a lot of way, it resembles using a CD-ROMs instead of an iTunes playlist. First, it made no sense to force an entire library of React components and an entire utility library and so on on each of our projects.

Secondly, every project using it would be tightly coupled to the development of this library, making it impossible to adjust its components for each project. This becomes most painful when sharing common Node.js code between our microservices, which would now be coupled to the library.

Thirdly, discoverability within the library is bound to be poor and would involve a lot of work with its documentation and usage in different edge cases.

Because it makes very little sense to couple and slow down our development, we try to minimize the use of these libraries as much as possible. Even popular JavaScript utility libraries such as Lodash are working hard to make their smaller components independently available via NPM.

Git Submodules

Finally, we turned back time and looked into working with Git submodules.

You there. You're thinking about using a Git submodule. DON'T. Just don't. It's not worth it, ever.

— Jeremy Kahn (@jeremyckahn) December 16, 2012

Git enables you to make one repository a subdirectory of another repository, creating a single working tree for the entire project, so that a repository can utilize code from another repository.

As for many other teams, this solution did not last for us. First, submodules only work on the master branch, which causes problems for rapid development. Secondly, submodules increase coupling between projects, which makes it hard to work on cross-repository assignments. Finally, a submodule repository is oblivious to its own nesting and the existence of dependent repositories.

After trying these different solutions, we realized that it shouldn’t be this complicated. There really should be a simpler way to organize, share and develop components of code from different projects. So, we decided to build it, and called it Bit.

Building Bit

Our vision for a solution was simple: turn our components and modules into building blocks that can be easily isolated from any project, organized in the cloud and used in any project.

Bit sharing workflow

Isolate, share and organize your reusable code. (Large preview)

When building it, we set a few guidelines for what we needed from the project.

Make it seamless to isolate and share code components from any project, without having to create new repositories or manually configure build and test environments and dependencies for each component.
Enable two-way development, so that each component could be changed and updated from any project, while changes would be synced across our code base.
Make it simple to organize and share our components, while making them discoverable for our entire team with useful visual information.

After hard work and extensive research, in 2017 we released the first version of Bit to GitHub.

How It Works

Bit’s workflow is made of three simple steps:

The first is to simply tell Bit which components of code you would like to share from your project, and it will immediately start tracking them in all of the projects you share them in.
You can then tag a version for these components so that Bit automatically defines and locks their dependency tree for both file and package dependencies, and creates an isolated environment for each component to build and test in isolation.
Finally, you can share the components to the cloud (or your own remote server), where they will be organized, will be made discoverable and can be installed with NPM or Yarn like any other package.

You don’t have to create new repositories, split your code base or refactor a single line of code.

Now comes the really cool part. You can also use Bit to import the components into other projects for further development. Because Bit tracks your components between projects, you can simultaneously develop them from different repositories and sync changes across your code base.

This fast and distributed workflow means you won’t be tied by ownership issues, and you can actually develop the shared code and update changes from any of your team’s projects.

Let’s see an example.

Example: Bit With React UI Components

A React Hero component with Bit

A React Hero component with Bit. (Large preview)

For this example, let’s pick a common use case: syncing React UI components between apps. Although designed to be reusable, achieving such reusability can be challenging.

Let’s take an example React app on GitHub. It contains eight reusable React UI components and one global styling component. As you can see, Bit was added to the repository (see the bit.json and .bitmap files) to track these components — but not a single line of code was changed in the repository. From there, the components were shared to the corresponding scope on Bit’s free web hub.

As you can see, each of the components is now available to any developer to install with NPM or Yarn or to import into their own projects for further development.

All of the components are organized and can be shared with your team and searched for via a search engine. They are presented with visual rendering, build and test results (you can use premade external build and test environments or create your own), and come with auto-parsed docs so that you can make an informed decision on which components to use.

Once it’s changed from a different project, you can update the component’s version in the scope (which works as a remote source of truth) and sync changes between different repositories.

A short tutorial for React is available for the example project.

Conclusion

Sharing code between projects is vital to building software faster, while making your code base simpler to maintain and develop over time. As more of our applications are built using reusable components such as React and Vue UI components, Node.js modules, simple functions, GraphQL APIs and more, turning them into building blocks for different projects becomes more rewarding.

However, the overhead of splitting repositories, refactoring projects, and modifying components from different projects can make it hard to effectively collaborate and share your code. These are the lessons learned from our own journey towards simple and effective code sharing, making it simpler to share, discover and collaborate as a team while building with our common LEGO bricks.

Bit is an open-source project, so feel free to jump in, suggest feedback or ask anything. Just remember that, at the end of the day, sharing code is always about people and about growing a collaborative culture where people play together to build great things.

Smashing Editorial
(rb, ra, al, yk, il)

An Introduction to Gulp.js

/0 Comments/in /by

Original Source: https://www.sitepoint.com/introduction-gulp-js/

Developers spend precious little time coding. Even if we ignore irritating meetings, much of the job involves basic tasks which can sap your working day:

generating HTML from templates and content files
compressing new and modified images
compiling Sass to CSS code
removing console and debugger statements from scripts
transpiling ES6 to cross-browser–compatible ES5 code
code linting and validation
concatenating and minifying CSS and JavaScript files
deploying files to development, staging and production servers.

Tasks must be repeated every time you make a change. You may start with good intentions, but the most infallible developer will forget to compress an image or two. Over time, pre-production tasks become increasingly arduous and time-consuming; you’ll dread the inevitable content and template changes. It’s mind-numbing, repetitive work. Wouldn’t it be better to spend your time on more profitable jobs?

If so, you need a task runner or build process.

That Sounds Scarily Complicated!

Creating a build process will take time. It’s more complex than performing each task manually, but over the long term, you’ll save hours of effort, reduce human error and save your sanity. Adopt a pragmatic approach:

Automate the most frustrating tasks first.
Try not to over-complicate your build process. An hour or two is more than enough for the initial setup.
Choose task runner software and stick with it for a while. Don’t switch to another option on a whim.

Some of the tools and concepts may be new to you, but take a deep breath and concentrate on one thing at a time.

Task Runners: the Options

Build tools such as GNU Make have been available for decades, but web-specific task runners are a relatively new phenomenon. The first to achieve critical mass was Grunt — a Node.js task runner which used plugins controlled (originally) by a JSON configuration file. Grunt was hugely successful, but there were a number of issues:

Grunt required plugins for basic functionality such as file watching.
Grunt plugins often performed multiple tasks, which made customisation more awkward.
JSON configuration could become unwieldy for all but the most basic tasks.
Tasks could run slowly because Grunt saved files between every processing step.

Many issues were addressed in later editions, but Gulp had already arrived and offered a number of improvements:

Features such as file watching were built in.
Gulp plugins were (mostly) designed to do a single job.
Gulp used JavaScript configuration code that was less verbose, easier to read, simpler to modify, and provided better flexibility.
Gulp was faster because it uses Node.js streams to pass data through a series of piped plugins. Files were only written at the end of the task.

Of course, Gulp itself isn’t perfect, and new task runners such as Broccoli.js, Brunch and webpack have also been competing for developer attention. More recently, npm itself has been touted as a simpler option. All have their pros and cons, but Gulp remains the favorite and is currently used by more than 40% of web developers.

Gulp requires Node.js, but while some JavaScript knowledge is beneficial, developers from all web programming faiths will find it useful.

What About Gulp 4?

This tutorial describes how to use Gulp 3 — the most recent release version at the time of writing. Gulp 4 has been in development for some time but remains a beta product. It’s possible to use or switch to Gulp 4, but I recommend sticking with version 3 until the final release.

Step 1: Install Node.js

Node.js can be downloaded for Windows, macOS and Linux from nodejs.org/download/. There are various options for installing from binaries, package managers and docker images, and full instructions are available.

Note for Windows users: Node.js and Gulp run on Windows, but some plugins may not install or run if they depend on native Linux binaries such as image compression libraries. One option for Windows 10 users is the new bash command-line, which solves many issues.

Once installed, open a command prompt and enter:

node -v

This reveals the version number. You’re about to make heavy use of npm — the Node.js package manager which is used to install modules. Examine its version number:

npm -v

Note for Linux users: Node.js modules can be installed globally so they’re available throughout your system. However, most users will not have permission to write to the global directories unless npm commands are prefixed with sudo. There are a number of options to fix npm permissions and tools such as nvm can help, but I often change the default directory. For example, on Ubuntu/Debian-based platforms:

cd ~
mkdir .node_modules_global
npm config set prefix=$HOME/.node_modules_global
npm install npm -g

Then add the following line to the end of ~/.bashrc:

export PATH=”$HOME/.node_modules_global/bin:$PATH”

Finally, update with this:

source ~/.bashrc

Step 2: Install Gulp Globally

Install Gulp command-line interface globally so the gulp command can be run from any project folder:

npm install gulp-cli -g

Verify Gulp has installed with this:

gulp -v

Step 3: Configure Your Project

Note for Node.js projects: you can skip this step if you already have a package.json configuration file.

Presume you have a new or pre-existing project in the folder project1. Navigate to this folder and initialize it with npm:

cd project1
npm init

You’ll be asked a series of questions. Enter a value or hit Return to accept defaults. A package.json file will be created on completion which stores your npm configuration settings.

Note for Git users: Node.js installs modules to a node_modules folder. You should add this to your .gitignore file to ensure they’re not committed to your repository. When deploying the project to another PC, you can run npm install to restore them.

For the remainder of this article, we’ll presume your project folder contains the following sub-folders:

src folder: preprocessed source files

This contains further sub-folders:

html – HTML source files and templates
images — the original uncompressed images
js — multiple preprocessed script files
scss — multiple preprocessed Sass .scss files

build folder: compiled/processed files

Gulp will create files and create sub-folders as necessary:

html — compiled static HTML files
images — compressed images
js — a single concatenated and minified JavaScript file
css — a single compiled and minified CSS file

Your project will almost certainly be different but this structure is used for the examples below.

Tip: If you’re on a Unix-based system and you just want to follow along with the tutorial, you can recreate the folder structure with the following command:

mkdir -p src/{html,images,js,scss} build/{html,images,js,css}

Step 4: Install Gulp Locally

You can now install Gulp in your project folder using the command:

npm install gulp –save-dev

This installs Gulp as a development dependency and the “devDependencies” section of package.json is updated accordingly. We’ll presume Gulp and all plugins are development dependencies for the remainder of this tutorial.

Alternative Deployment Options

Development dependencies are not installed when the NODE_ENV environment variable is set to production on your operating system. You would normally do this on your live server with the Mac/Linux command:

export NODE_ENV=production

Or on Windows:

set NODE_ENV=production

This tutorial presumes your assets will be compiled to the build folder and committed to your Git repository or uploaded directly to the server. However, it may be preferable to build assets on the live server if you want to change the way they are created. For example, HTML, CSS and JavaScript files are minified on production but not development environments. In that case, use the –save option for Gulp and all plugins, i.e.

npm install gulp –save

This sets Gulp as an application dependency in the “dependencies” section of package.json. It will be installed when you enter npm install and can be run wherever the project is deployed. You can remove the build folder from your repository since the files can be created on any platform when required.

Step 4: Create a Gulp Configuration File

Create a new gulpfile.js configuration file in the root of your project folder. Add some basic code to get started:

// Gulp.js configuration
var
// modules
gulp = require(‘gulp’),

// development mode?
devBuild = (process.env.NODE_ENV !== ‘production’),

// folders
folder = {
src: ‘src/’,
build: ‘build/’
}
;

This references the Gulp module, sets a devBuild variable to true when running in development (or non-production mode) and defines the source and build folder locations.

ES6 note: ES5-compatible JavaScript code is provided in this tutorial. This will work for all versions of Gulp and Node.js with or without the –harmony flag. Most ES6 features are supported in Node 6 and above so feel free to use arrow functions, let, const, etc. if you’re using a recent version.

gulpfile.js won’t do anything yet because you need to …

Step 5: Create Gulp Tasks

On its own, Gulp does nothing. You must:

install Gulp plugins, and
write tasks which utilize those plugins to do something useful.

It’s possible to write your own plugins but, since almost 3,000 are available, it’s unlikely you’ll ever need to. You can search using Gulp’s own directory at gulpjs.com/plugins/, on npmjs.com, or search “gulp something” to harness the mighty power of Google.

Gulp provides three primary task methods:

gulp.task — defines a new task with a name, optional array of dependencies and a function.
gulp.src — sets the folder where source files are located.
gulp.dest — sets the destination folder where build files will be placed.

Any number of plugin calls are set with pipe between the .src and .dest.

Continue reading %An Introduction to Gulp.js%

Famous logos redesigned as fonts

/0 Comments/in /by

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/XFYT2HoHg9Q/famous-logos-redesigned-as-fonts

A good logo design often depends on a good typeface. If you get it right, the perfect font choice can become synonymous with a brand. To show how a strong identity can remain recognisable even when you swap out the brand name, designer and teacher Emanuele Abrate has been conducting a series of interesting logo experiments.

In his experiments, Abrate has swapped out the names of brands like Adidas and YouTube for the names of the fonts they use. Speaking to Co. Design, he revealed that the project came about as he struggled to identify the typeface in a logo. "Every time I see a logo, I wonder how it was conceived, how it was designed, what kind of typeface was used and why."

The results will make you double-take. In most cases, our eyes have become so used to the font styles and logo graphics that we'll just glaze over when looking at a design that looks recognisable enough. Take a look at them by scrolling left to right with the arrow icons in the gallery below.

Related articles:

The rules of responsive web typography5 typography trends for 201850 top typography tutorials

Continuous Learning of Your iOS App Using App Center

/0 Comments/in /by

Original Source: https://www.sitepoint.com/continuous-learning-ios-app-using-app-center/

This article was created in partnership with Microsoft. Thank you for supporting the partners who make SitePoint possible. App development is an iterative process, the work you do on version 2 of an app is largely based on the things you learned from building and releasing version 1. In order for your development efforts to […]

Continue reading %Continuous Learning of Your iOS App Using App Center%