Post pobrano z: Shopify VS WooCommerce – Best eCommerce Solution for WordPress
Are you thinking about setting up an eCommerce website? Are you familiar with WordPress? Do you want to be able to set up the website on your own? If your answer is yes to all these questions, then things just got a little less complicated for you. You want to know how to make a […]
The post Shopify VS WooCommerce – Best eCommerce Solution for WordPress appeared first on Web Resources Depot.
Post pobrano z: Wall Street Fearless Girl by State Street
Fearless Girl, a bronze sculpture on Wall Street commissioned by State Street Global Advisors, has won three Grand Prix awards at Cannes International Festival, for PR, Outdoor and Glass Lion categories. The Fearless Girl sculpture, fashioned by Kristen Visbal, depicts a Latina girl looking at the well-known Charging Bull statue in Bowling Green Park, in Manhattan. Fearless Girl was commissioned by investment firm State Street Global Advisors (SSgA) as an advertisement for an index fund which comprises gender-diverse companies that have a higher percentage of women among their senior leadership. The plaque below the statue states, “Know the power of women in leadership. SHE makes a difference,” with “SHE” being both a descriptive pronoun and the fund’s NASDAQ ticker symbol.
The Fearless Girl campaign was developed at McCann New York by global creative chairman Rob Reilly, chief creative officer (North America) Eric Silver, chief creative officer Joyce King Thomas, managing director Devika Bulchandani, co-chief creative officers Tom Murphy and Sean Bryan, senior art director Lizzie Wilson, senior copywriter Tali Gumbiner, chief production officer Nathy Aviram, executive producer (innovation) Christine Lane, senior integrated producer Deb Archambault, design director George Katz, design director David Mashburn, head of communications strategy David Broad, director of social and mobile Gemma Craven, strategy director Kevin Kim, executive account director Peter Bracegirdle, account supervisor Molly Vossler, junior producer Doug Harrison, senior project manager Steven Marchione, chief communications officer Jeremy Miller, brand communications director Neena Koyen, senior editor Nathan Troester, content creators Brett Berman and Eric Perini, executive music producer Eric Johnson and music producer Dan Gross.
Artist was Kristen Visbal at Visbal Sculpture, Inc.
Production was by Traction Creative (Bryan Roberts) and SWP, New York, (Stuart Weissman).
Photography was by Federica Valabrega with retoucher Kris Chu at Swell.
Filming was by director of photography Jack Shanahan and assistant camera Jeff Clanet. Music was produced at Copilot Music + Sound by composer Naren Rauch and executive producer Jason Menkes.
Post pobrano z: Adobe Alternatives: Broadening Our Horizons
I’ve been using Adobe software in earnest since they acquired Macromedia back in 2005, (I miss you Fireworks), and in that time I’ve done some awesome things with their software. During many periods I’ve relied on it to make a living, and it has served me well.
However, despite how familiar and comfortable virtually anyone in creative professions is with Adobe software, it’s always a good idea to know as much as possible about all the tools at your disposal. With a little exploration you might find there is a tool out there that is perfect for the specific tasks that form part of your daily workflows.
In this series we’ll be exploring the alternative software that occupies the same space as some of the most beloved Adobe applications. We’re keeping the focus on low or no cost applications so trying out some new toys won’t break the bank–everything will either be fully free, have a functional free version, or a price tag of less than $100. Because, let’s be honest, sometimes we’re just at a point in our careers where we need options that are going to be gentle on our hip pockets.
This is far from the first time someone has put together a list of alternatives to Adobe software, but in my experience a list alone is not helpful enough. For a given project you don’t just need any old application. You need an application with tools honed for the particular kind of work you need to do.
The image editing tools you need when doing photo manipulation are different from those you need when doing digital painting or pixel art. The video editing tools you need for a quick video on your YouTube channel are different from those you need for your short film or your motion comic. What really matters is the specifics of where applications are strong, what they specialize in, and any unique features they may have.
As such we’re breaking this series into six specialty groups. They are:
I have personally tried out every single application you’ll read about in this series, and I will endeavor to give you as much pertinent information on each as I can fit into the articles. As you go through this series you might find there’s an application you know to be great that isn’t in the list. If it’s under our series price cap of $100 and not included, it’s more than likely just because I haven’t personally tested it. As such, please do go ahead and shout out in the comments about programs you’ve discovered so other people can learn more about the options available to them.
Up first, alternatives to Photoshop for working with photo manipulation and raster-based design. Thanks for joining me, and I hope to connect you with some of your new favorite software!
Post pobrano z: Breaking the wall / Niveau copie, c’est un peu Raid?
 |
 |
| THE ORIGINAL? Abus Security Locks – 2014 Source : Behance Agency : Leche (Chile) |
LESS ORIGINAL Forte Security Doors – 2017 Source : Cannes Lions SILVER Agency : Circus Grey (Peru) |
Post pobrano z: What Does a Well-Documented CSS Codebase Look Like?
In the front-end community, there is a lot of attention related to documenting JavaScript. That’s not so much the case with CSS. Often times I feel like lost when I join a project with minimal or no CSS documentation.
Even though CSS is relatively easy to write, it can be quite hard to maintain. The specificity, the global scope of everything, and the lack of guidance can easily lead to inconsistency, code duplication, and over-complication.
I’ve long been curious what a really well-documented CSS codebase looks like. Here, I’ll share my experience, along with the expectations I have towards my vision of well-documented stylesheets.
It surprises me where I hear people say that commenting CSS is not that important. I imagine none of them have had to deal with 10,000+ line stylesheets! Often I’ve struggled with what HTML results in what specific style. Without having a solid context about the development decisions taken, debugging efforts increase. WTFs per minute increase exponentially too.
Many times I’ve spent hours to figure out what the developer intended, why she didn’t do it the another way, why is this layout seemingly so complex. There is much pain buried in these „why” questions.
So, here we go! Let’s examine the 4 big signs of a well-documented CSS codebase.
There are likely things as part of our CSS code base like third-party libraries, mixins, or other tools. Looking in the package manager’s dependencies list doesn’t give a lot of context why the decisions were made to add these things, what they do exactly, and how we’re using them.
It would be good for everyone to know why a certain library or tool was introduced. Imagine, for example, that a third-party library was introduced only to solve what has become an obsolete CSS issue. If we had context like that, we could make more informed decisions.
There sometimes can be quite a few third-party libraries in a project. Have you ever spent a bunch of time on web searching each one figuring out what it even is? It can be quite a challenge to know or to keep track of what each exactly does.
A well-documented codebase would include a description for each dependency. Perhaps you could the comment tweet-length (140 characters) explaining why it is there. That would give anyone else in the code base a head start on why something is there.
I like adding these descriptions right in the place where I @import them.
Good coding conventions result in consistent, readable, and unambiguous source code. They standardize the structure and coding style of an application so that you and others can easily read and understand the code.
It’s important to know if there are any project-specific naming conventions or methodologies in place (like BEM, OOCSS, SMACSS, or ACSS). I’ve seen cases where a certain methodologies principles are applied but the actual rules followed are modified based on the preferences of the developers involved. So an indication how strictly we must follow the methodology principles would be good to leave in a well-documented code base.
This brings up the larger issue of CSS style guides. A naming convention is just one choice as part of a complete styling strategy. Other parts might be:
All this makes up a complete CSS style guide. Having a shared vocabulary like this I’d consider a strong plus towards consistency.
Most scalable projects follow some type of architecture in terms of ordering styles. In a well-documented codebase, the fundamental principles that the project follows when structuring and sectioning styles should be mentioned.
I was first inspired to explore CSS architecture by watching Harry Roberts’s talk about managing CSS projects. Here’s Harry:
CSS architecture seems to be somewhat in vogue right now. It’s something you’ve no doubt heard mentioned numerous times over the past year or so, and with good reason: UIs (and the teams that build them) are getting bigger and more complicated than ever before.
There are a number of aspects of CSS which make it troublesome. It’s declarative, meaning there is no logic or control flow to tell other developers much about the state or construction of the project. It operates in a global namespace, meaning we get collisions, leaking styles and inadvertent regressions. It utilizes inheritance, making everything somewhat interdependent and brittle. Finally, the unavoidable specificity model can cause problems when selectors fight each other for prominence.
Therefore, he introduces a concept for architecting CSS called ITCSS. If you are working on a project of reasonable scale, chances are someone already defined similar principles or ideas that aim to resolve these problems. So in a well-documented codebase, I would expect to see them written somewhere.
One could tell if the architecture is explained well enough if you can answer the following question: Where should new styles or stylesheets be added?
A common pattern is to separate the logical modules into CSS components (or „blocks” according to BEM). Some of them might be re-usable, some may not, but the important thing is that they are the building blocks of our project. Therefore, describing what they are should be a top priority in a well-documented codebase.
Ideally, you should arrange and group them, name them, and establish rules between them to generate an overview of all components. A well-described CSS component doesn’t only include information about what the component does but also has other valuable intel like example HTML markup and the context in which it’s meant to be used. Going one step further brings up the issue of Pattern Libraries. A pattern library is a collection of reusable components that can be used together to create a website. With modular, component-based architecture becoming a trend, they can bring huge value.
The goal of a pattern library is to show what can be built with existing patterns (components). But let’s take a look at what additional information can be displayed alongside each pattern also. Vitaly Friedman shared a good summary on how taking the pattern library to the next level looks like. He states that focusing on components isn’t good enough:
One of the main problems with pattern libraries is that, while they provide an overview of components, they often leave a lot open to interpretation. Components can be combined in a variety of ways, consistently and inconsistently. It’s great to be able to see what button variants and iconography are available and what kinds of tables and pricing tags one may use, but what if you need to design or build an interface that contains all of these components at once — and perhaps another that doesn’t yet exist in the library?
A list of modules alone wouldn’t convey any context or any specifics on how the modules should (and should not) be used.
Based on Vitaly’s post and Brad Frost’s anatomy of a pattern in a pattern library, here are a few ideas I can imagine each of our patterns (components) could have, despite the usual unique name, code sample and a description of the component’s purpose. Basic (fundamental):
… and here are a few more advanced:
… the list goes on and on to whatever makes sense for your specific use-case.
A well-documented CSS codebase enforces consistency, boosts maintainability, and helps the team to build a shared vocabulary. It is a prerequisite for efficient CSS design and development. Moreover, based on my experience, it inevitably leads to better performance. I strongly believe that these are the signs of the professional execution of a project.
If you have thoughts, please feel free to add them in the comments below, so together we can come closer to better documentation practices.
What Does a Well-Documented CSS Codebase Look Like? is a post from CSS-Tricks
Post pobrano z: Connect: behind the front-end experience
Some fantastic behind-the-scenes stuff about Stripe’s design work by Benjamin De Cock. Absolutely everything is clever and using very modern techniques.
Plus one I’d never seen before:
Connect’s landing page uses the new Intersection Observer API which provides a much more robust and performant way to detect the visibility of an element … The
observeScrollhelper simplifies our detection behavior (i.e. when an element is fully visible, the callback is triggered once) without executing anything on the main thread.
Direct Link to Article — Permalink
Connect: behind the front-end experience is a post from CSS-Tricks
