Posts About Foundation
Posts About Foundation
Mutation, it is the key to our evolution. It has enabled us to evolve into the dominant species on the planet. This process normally takes thousands and thousands of years. But every few hundred millenia, evolution leaps forward. - Professor X (Marvel's X-Men Comic Book Series)
Oscar Isaac as "Apocalypse" in 'X-Men: Apocalypse.' 20th Century Fox Film
Following along the history of the Marvel Universe, there was a long period of time with no change in the world of Mutation... the DOM Events Level 3 spec deprecated Mutation Events but there were no major changes from 2000 until the arrival of the DOM Events Level 4 spec in 2013, where Mutation Observers were introduced.
As with the proliferation of observed Mutants in Marvel's universe during WW2, the re-instigation of the Browser Wars in the early 2010s resulted in the rapid spread of Mutation Observers throughout the web ecosystem. First showing up in Safari, Chrome and Firefox in early 2012 (before the public spec was drafted!), they rapidly arrived in iOS Safari (January 2013), Opera (July 2013), Internet Explorer (October 2013), and Android Browser (December 2013). They are now widely enough spread that we are able to more or less count on their presence throughout the web, and they have been added to Foundation in the 6.3.0 release.
Foundation's First Mutants
The first steps towards the true integration of Mutation Observers were submitted as a pull request by Corey Snyder on August 18, 2016. This pull request started out simply by creating the infrastructure we need to take advantage of this new capability throughout the framework. By adding a data-mutate attribute and some automatic listeners and triggers, we began to lay the groundwork for our Mutant future. Like Professor X setting up Xavier's School for Gifted Youngsters, this utility gives us the ability to begin teaching ALL of our Foundation components how to work with and understand Mutations.
Building and Distributing Cerebro
Patrick Stewart as "Professor X" in 'X-Men.' 20th Century Fox Film
The primary use case for Mutation Observers is for elements that need to understand something about their children (the elements they contain) in order to properly render or behave. For example, the Equalizer component depends on understanding the sizes of all of the different sub-elements that it is equalizing. Prior to utilizing Mutation Observers, if those sub elements changed, the Equalizer component would break, unless you as a user manually told it to reinitialize. What the [data-mutate] attribute allows for is to have the Equalizer component AUTOMATICALLY notice when those subcomponents change and reinitialize itself to adjust. This is kind of like the Cerebro machine used by Professor X - adding a [data-mutate] attribute amplifies the abilities the Equalizer component already has and gives it the ability to be instantly in touch with changes happening in its children.
Many components such as Equalizer, Tabs, Interchange, Toggler, and Responsive Navigation have already benefited from the Mutation Observer infrastructure and in doing so have cleaned up and resolved many long-standing bugs. As we get deeper into this shift, one can imagine new possibilities of automatic adjustments and interacting components.
However, with great power there is great responsibility - it takes time, energy, and care to teach someone to use Cerebro - and simply slapping a 'data-mutate' attribute onto a component may cause more problems than it solves. Many of the components that will eventually benefit from understanding Mutation Observers still need work to make it happen. There's a catalog of ongoing efforts underway here, you can watch the progress or even jump in and help make it happen.
You Too Can Take Advantage of Mutation Observers
Cast of 'X-Men: Apocalypse.' 20th Century Fox Film
One of the awesome things about integrating Mutation Observers into the Foundation Triggers utility is that it makes it much easier for YOU to take advantage of Mutation Observers. Simply add a [data-mutate] data attribute to any element in your page, and the Foundation Utilities will set up observers on the children of that element, triggering a 'mutateme.zf.trigger' event on any structural or stylistic change. With this infrastructure in place, Mutation Observers can finally follow Mutants out of the shadows, and into the key roles of society (aka application) where they can do the most good.
Check out the new Foundation 6.3 update to learn more about Mutation Observers and all of the other cool new features!
Holiday season has arrived and that usually means one thing' more gifts than you can shake a handlebar mustache at! The Foundation team, Yetinauts, and a whole lotta contributors have been hard at work on a huge update to Foundation that is stuffed to the brim with new goodies you're going to go nuts for. The best part? It's available for you to download today, whether you've been naughty or nice. You don't need to shake the box, we'll tell you exactly what's inside:
- A new, bulletproof off-canvas: 6.3 includes an all new off-canvas implementation that adds features and improves performance over the existing version. Open from the top, bottom, side, you name it. It's even backwards compatible so you don't need to change any markup. Thanks for your hard work Brett Mason!
- Cards!: After lots of debate and iterations we have added Cards to Foundation 6. Card based designs are perfect for responsive sites and make it easy to display a ton of information without overwhelming your users (as long as you use them correctly). Another awesome contribution by Brett Mason!
- Responsive Accordion to Tabs: Tabs work great on larger screens but can be a mess on mobile. With this new update, you can switch your UI based on screen size from tabs to responsive accordions for a better experience on mobile. It's a breeze to implement and provide an awesome experience for your users. Thanks to designerno1, for this one!
- Mutation observers: Foundation is the most advanced framework in the world for a reason. We're always looking to include awesome technologies that will help you develop faster. Mutation observers work behind the scenes and automatically detect DOM changes and triggers updates in components. This saves you manually having to Reflow elements to trigger changes in things like reveal modals, sticky bars, equalizer, and more. Shoutout to Corey Snyder for putting this one together!
- Deep linking to Tabs: Deep linking has become one of the hottest topics on the web within the last few years and absolutely critical for eCommerce sites and mobile apps. Have specific content in tabs and want to send users to it? Now you can in 6.3 thanks to ahebrank.
- Print Styling: Traditionally, printing a responsive webpage is very difficult. Foundation typically would only show the mobile screen, other frameworks throw up their hands, and you'd have to spend hours setting up a custom print stylesheet. In 6.3, you can specify exactly which breakpoint you want your print page to mirror, and Foundation will figure out the rest. Shout out to Andy Cochran for adding that!
- Vertical Rhythm: Foundation has always made it easy to manipulate the sizes of your different types of headers and text, but to create strong vertical rhythm on a site you need more than this. With 6.3 the configuration of typography sizing, line height, and margins are all accessible in a single compact setting. Kudos to Karl Anders!
- Flexbox Helpers:We've been using #FLEXBOX more and more recently, and getting more and more excited about using it for UI. In 6.3 we've added a bunch of new helpers that make Flexbox more accessible and easier to prototype with.
Yep, we're ending the the year with a bang, our biggest update since Foundation for Sites 6 was launched last year. It's also a fitting way to cap off Foundation's 5th birthday celebration. Thanks to all who contributed, Foundation is still the most advanced front-end framework in the world. We couldn't have done any of this without our awesome community of Yetinauts and contributors. So tear into the new Foundation for Sites 6.3 update today and let us know what you think!
The new Transformers movie trailer just dropped to a surprising amount of fanfare. Regardless of how you feel about Michael Bay's metal clanking movie pantheon, you have to admit that at least the concept of robots beating the snot out of each other is pretty cool. In the series, a set of shape changing robot-beings invade earth and entangle humans in their battles in search of universal domination. In the web world we're fighting a similar battle, the proliferation of devices that have led to the rise of a set of shape changing components, entangling designers in their own search for universal domination.
Like Transformers, responsive components change their size and shape to fit into different circumstances and devices. But how do you make sure you're using them effectively and not just creating a loud, metallic mess? Key to winning the battle is a deep understanding of the makeup of your 'troops', knowing the key factors to consider and the components you can call upon to step up and fill their roles.
Assessing the Battlefield - Key Factors of Responsive Components
When considering responsive components, the elephant (or Dinobot) in the room is space, but there's a multitude of space-related factors to consider.
- Vertical Space - how much will you need to scroll, can you make something take less height by shrinking an image, or splitting a list into multiple columns?
- Horizontal Space - Large numbers of columns are challenging to display within a mobile device, resulting in a desire to create interfaces that make sense when you stack components or align them vertically.
- Clickable Space - On mobile devices, while you have less space to play with, you actually want clickable items to take up MORE space, because fingers on a touch screen are less precise than a mouse.
Your Transformer Army - Common Responsive Patterns
Just as the Transformers have different specialties and are called to duty in ways that match their abilities, different components also have specialties. As mobile-first design has become more and more of a standard, we've begun to develop common, reusable patterns that function well responsively and can be used as parts of your design tool chest.
The first of these is cards. Cards are the Bumblebee of Responsive design - small, able to fit into many situations, but often overused and can get into trouble. Cards are by their nature incredibly easy to make responsive - they form an atomic unit that can be expanded or laid out side by side as screen size permits, but also fit naturally within a mobile environment. Just be careful not to overuse.
Another extremely common pattern for a responsive component is in site navigation. This is a place where not only the content layout matters, but interaction patterns are super important. Dropdown menus feel extremely natural in desktop environments, but are clunky and hard to navigate on a small, touchscreen device. In contrast, drilldown menus have been a part of iOS native navigation since the beginning, and feel completely natural in a mobile environment. An extremely common pattern for a responsive navigation component is now to use a top bar containing a set of links that have dropdown navigation on large screens, switching over to have a top bar hamburger icon that taps open either a drilldown menu or scrollable 'mega menu'. These menu patterns are like the Constructicons - relatively weak in isolation, but super similar and when their powers combine they create a super-powerful component.
A final pattern we want to highlight is for hiding and displaying content. Sometimes, you have just too much content to handle, and you need to throw something powerful at it. In the Transformers, this is when Optimus Prime gets called in - he's relatively vanilla but can handle situations that no one else seems to be able to deal with. In the responsive web world, this is when you want to use accordions and tabs. On large screens, it is common to have tabs-based interfaces to allow you to navigate between different content blocks or images, but on a small screen fitting both the tabs and the content all on screen is challenging. Designers have learned to switch their tabs for accordions on mobile to keep the hide/show controls directly adjacent to the content being shown, making it much easier to navigate on a small screen. This responsive 'accordion-tabs' pattern has been growing in popularity and is starting to show up in many different situations where you're trying to manage large amounts of content in a small space.
Responsive Components in Foundation 6.3
While navigation has been reasonably well handled in Foundation 6 via responsive menus and the off-canvas component, we have not had a built in responsive accordion/tabs solution, and we have not had a cards component. Until now. Foundation 6.3 (due to ship December 15, check out the release candidate here) will include BOTH a responsive accordion tabs component and a cards component.
The cards component, while very 'foundational', makes it easy to start building responsive cards within Foundation without having to spend a bunch of time building up the basic component structure.
The responsive accordion tabs component follows the model of our responsive menus, allowing you to use the exact same markup to generate an accordion at one screen size, shifting seamlessly into tabs at another. This will dramatically improve the ease of implementing this common design pattern. Optimus Prime has arrived. ;)
The Future of Responsive Components
There are a few technologies on the horizon that are going to dramatically shift our ability to build powerful responsive components. Currently we create components that are responsive based on screen size using media queries, but the coming of element queries will allow the creation of components that are responsive based on the space allotted to them rather than the full screen size. This alone will dramatically improve the ease with which we'll be able to integrate responsive components throughout the web.
Cards within design layouts have gained immense popularity over the last several years. Companies like Google, Facebook and Twitter who have millions of users that use their products every day have leveraged this popular UI component within their interfaces. Not surprising since, cards are a perfect response to the rise of responsive design. They're self contained units that can be moved, shuffled and mixed with different content types. They respond easily on different screen sizes, from single columns on mobile devices to multi-column on larger devices, and can move independently around the web.
At ZURB we've found cards to be a great solution within our client work and have been keeping close tabs on their use around the web. Google has written pretty in depth about their usage within their Material Design framework as well as some great content from teams like Intercom. From our 100+ card based projects the last couple years we have, however noticed some pitfalls when designing with them. Here we'll cover 5 of the most common mistakes we see designers make with card based UI:
1. Large visual gaps from different content lengths
In a perfect world, our content would be as neat and tidy (and consistent) as it is in our Sketch files, but real world content isn't perfectly uniform. Titles are longer, descriptions vary and (as much as Apple wishes) names aren't always 4 letters long. When cards are placed in a grid at larger screen sizes we can often see large gaps that interrupt flow. This isn't to say whitespace is frowned upon, but inconsistent whitespace can limit the density and make it difficult to scan cards.
There are three things we ask our designers to consider when this issue arises. First we look to see if the data makes sense when truncated. Will titles or descriptions still make sense when data is capped at a specific character count? Will the user be losing vital info? Secondly, we see if cards will make sense in a masonry layout. This works if content doesn't need to be tediously scanned, but instead when users can just peruse the content. Lastly, we see if we can shift content inside the card to make it work on one column on all device sizes. This allows cards to be as short or tall as needed and often allows us to keep information dense within the site.
2. Too many cards visible at once
It's always tempting to want to use the entire space of your screen, especially when building something like a dashboard or web app where users may appreciate seeing it all at a single glance. This, however, can become an issue with cards as too many cards within a grid, or on screen at any given moment can become overwhelming and can cause users to strain when scanning.
Much like text line length, we want to think about how much content a user can reasonably take in at any given moment and how far a user's eye can scan horizontally over the screen before it loses it's place. We suggest setting a max-width on your cards container to limit this content overload and while there's no magic number for how many cards across is too many, some basic user testing may help you discover this for your own use case.
3. Too many actions at various areas of the card
One of the most valuable things about cards is how well they work as bite sized chunks of content that are gateways to additional info or actions that users can take. This means that it's sometimes tempting to pack cards with tons of actions in every area of the card. A gear in the top left, or a trash can on the top right may seem like a good use of space, but turning every aspect of the card into a link can be be more confusing than helpful to your user.
This link overload is often at the behest of a client or project owner and it can sometimes be easier just to add the actions rather than fight the battle. We encourage our designers to think through what actions are necessary on any given level and to potentially group the actions by importance or type. This allows us to unify the few key actions to their easily found spot at the bottom of each card.
4. Overloading cards with content
Cards do a great job of breaking down large amounts of data into small digestible bits. They are especially fantastic for getting a quick snapshot of a project, a document, or a news story, but can sometimes tempt us to continue piling on content. Adding an Image, a button, a description, a chart, or a graph can seem like a helpful way to give users everything they're looking for, but more often it ends up overloading their ability to focus.
Outlining your primary content, secondary content and tertiary content is a great way to keep the card focused and allow users to take action to see more content. To do this we must know who is using our product and why they're coming to this page. We can then help rule out outliers and trim our card data to the minimum users need to see before they choose to take action and drill down.
5. Forcing a visual when one isn't needed
We've all seen pretty Dribbble shots with amazing photography, illustrations or icons in the header of a card. This makes the card feel visually striking and can split up some of the typographic content, but sometimes our cards' purpose doesn't have a visual that is part of the cards' primary reason for being. We leave a gray place holder in the wireframes and assume we'll figure out it's purpose when we start visual explorations.
When our designers add an image onto a card we often ask for the 'why'. Why does this need an image or an icon? Does this help the user better find content they're looking for, or will it simply become visual noise as users leave the default icon? This is usually a symptom of poor understanding of composition and needing an image or icon to balance out the cars, or separate the content. A great way to combat this is to do some typographic explorations and work with content order and hierarchy till the cards look balanced and clear.
Play Your Cards Right
Card design has been a welcomed force on the web and the ZURB team has been embracing them in our design work for years. We've explored them in websites and web apps in every industry from finance to biotech and have always found them to be a flexible part of a well oiled design. We've even noticed that In recent months as our designers have been coding within Foundation 6 that there has been an increase in projects with card components built from the ground up. While there's nothing wrong from coding a component from scratch, the team has taken the most solid use cases for cards and has added them into the forthcoming Foundation 6.3. This means cards will be even easier to use in your next project, but just make sure you're not falling into any of these pitfalls while using them.
We're testing out Cards in the Foundation 6.3 Release Candidate now with a full release coming December 15th!
Today Foundation turns five years old. What started out as an internal styleguide so our team could build websites faster and easier has transformed into powerful front-end framework that thousands of brands and millions of people use every day. But how did this happen? It wasn't luck. It wasn't being at the right place at the right time. It wasn't chance.
Looking back on the last five years, the reason Foundation has earned the trust and respect of the world's most brilliant designers, developers, brands and companies is simple. Foundation has never been afraid to take the lead, to go against the grain and to be the first. And in doing this, Foundation has pushed the web forward. It's influenced the way people and companies have thought about problems, and made it easier for more people around the world to experience everything the internet has to offer.
This innovation would have not have been possible if it weren't for the efforts of the 880 Foundation contributors, including the Yetinauts, who together with the ZURB team have put in over 12,360 commits and countless hours of their time to make the framework what it is today.
So as we celebrate five years, we'd like to highlight five ways Foundation changed everything:
1. It was the first open source framework to be responsive
Inspired by the work of Ethan Marcotte, Foundation was the first open source framework to be fully responsive. In a time when most people were developing for fixed pixel widths, Foundation's innovative grid system made it easy for designers and developers to dive into responsive web design and learn its concepts. Soon after, other frameworks followed our lead and went responsive as well, increasing the number of responsive sites being built each year. Now, responsive web design is the defacto standard for any brand, company or individual looking to build a site for the modern web. We're thrilled to have helped many designers and developers learn the concepts and best practices of responsive web design through Foundation.
2. It was the first to be semantic
One of the biggest steps forward for the web in the last five years has been the move towards semantic markup with HTML5, allowing for alignment between what people perceive in a web page and what software like a web crawler or text reader can identify. Adoption, however, was slow - especially because to take advantage of frameworks, one had to be using tons of structural and non-semantic css anyway. Foundation's semantic approach with Sass allowed developers to build truly semantic websites and applications while still taking advantage of all the power of a responsive web framework.
3. It was the first to be mobile-first
First coined by our good friend Luke W, Mobile First is an approach the focuses on progressive enhancement by starting with the smallest screens first. With, roughly, 80% of the screen size taken away when you start with mobile first design, you have to think deeply about how to utilize your space and ensure the core values you want to present to users is in the forefront without flooding with superfluous amounts of filler. Then, as you develop for larger screens and devices with more power, you progressively add features and enhance your site. Prior to this approach, developers focused on large screens first, and mobile screens as an afterthought, leading to poor and near unusable performance on devices with smaller screens and less processing power. Foundation helped popularize the mobile first approach and get designers and developers around thinking differently just in time as the mobile internet exploded in popularity.
4. It was the first to be constructed with Sass
The flexibility, power, and extensibility of SCSS are part of what have taken front-end web development from being a 'hack it together' project relegated to junior engineers and amateurs and turned it into a true engineering discipline. By rebuilding with Sass and exposing the build process to everyone, Foundation helped give designers and developers the power to truly make the framework their own, taking it from an immutable 'theme' to be plugged in and layered on top of and into a true customizable framework, ready to create any possible design.
5. It was the first to have accessibility built in
Foundation played a huge role in helping teach designers and developers learn the method sand best practices of responsive web design, and version 6 is doing the same for accessibility. We firmly believe that the web is for everyone, and so every component in Foundation for Sites 6 was rewritten from the ground up to meet accessibility standards and help educate users of Foundation how they could make their websites more a11y friendly. This is new territory for many web developers, and thousands are learning these best practices through using Foundation.
Help Build the Future
It's incredible to look back over the last five years and see the impact Foundation has had on the industry. It's even cooler to think about all the new 'firsts' Foundation will achieve as we continue to focus on the future.
Learn more about where Foundation's been, where it's going, and how you can get involved:
Foundation for Emails 2 modernized email design by taking some of the best practices of modern web development and bringing them to email. For web developers, it was a godsend, they could finally use the tools and workflows they were used to. But for many others, seeing things like Npm and Gulp is intimidating and doesn't help make email development any easier to tackle. We think everyone can and should be able to create responsive HTML emails, even if they don't have a strong web background. That's why we've built Slinky, a new way to build emails right in your browser.
Slinky makes it easy to code up a custom responsive email using just your web browser and our lightning-fast Inky Templating language. With CodePen's slick interface, all you have to do is write up your markup in either Inky or vanilla HTML and then inline. This code takes the Inky language and makes it into one slick HTML file you can import into any email service! No terminal commands, nothing to install, and no uploading. You'll be slinging beautiful, responsive, HTML emails in the cloud in no time.
Using the power of Foundation for Emails 2 and the Inky templating language, Slinky makes it easy to dive into the world of HTML email development. Check it out on the Playground page and sling some responsive emails!
Update: We released 2.2.1 shortly after this release to add in more Ruby scaffolding
We're stoked to announce that Foundation for Emails 2.2 - codename Bismarck, has been released into the wild! There's so much about this release to highlight so we'll focus on the biggest parts. We've got new implementations, juicy features, and time saving bug fixes. Since we launched Foundation for Emails 2.1, we've seen a huge jump in excitement and involvement on GitHub with contributions. We were going to release a 2.1.1 with bug fixes but instead we skipped ahead to 2.2 from 2.1 because there were so many great features jammed into this release!
The most important part of your email is not the code, it's crafting the right message that connects and engages people. The less you have to worry about coding your emails, the more you can focus on your messaging.
A Gem of a Workflow
The highlight of this release is the Ruby versions of Foundation for Emails and Inky. So many people have told us they love the concept of using Inky markup in their workflow but couldn't because they're in a Ruby environment. Well, now you can! Inky-rb and the Foundation for Emails gem now easily integrates into your Rails Asset Pipeline. Now you can use Foundation for Emails CSS along with clean Inky markup to build emails in your environment. Maybe it's just our bias, but we think combining Inky-rb with Premailer might just create the best email development environment for apps ever. ;)
New Features from the Sea of Contributors
There are tons of other great features in this release from over 30 contributors. Most of the features and fixes will help make emails less of pain, saving you from throwing your laptop across the room and flipping your table. There's too many to list here so here's some of our favorites:
- Get that visual treatment you're looking for by vertically aligning content in columns and source ordering columns. HTML attributes can now be passed to rows and columns thanks to Brandon Barringer - commit
- Create more controlled and compelling layouts across devices with different height spacers for the large and small breakpoints. Awesome update from Ethan May - commit
- Raise your open rates, click thrus and reduce spam complaints by including a preheader. This capability has been added to the default layout along with styles to visually hide it - commit and commit
- In case your audience opens your emails in browsers, Buttons and Menu Items can now get attributes thanks to Clement Paris - commit and commit
<hr>'s are notoriously hard to style in most versions of Outlooks. Now
<hr>'s can be styled across every email client thanks to Brandon Barringer - commit
- Hugo Giraudel and Rafal Proszowski simplified Sass code across 10 different files making it easier to read and contribute!
These are just a few of the awesome updates to 2.2 - check out the release notes to see more the of the changes!
From the conversations on Twitter, the Forum, and GitHub, it's obvious there's a ton of energy and excitement about where Foundations for Emails is going. We hope you see the potential here: how much it helps us spend less time coding the emails and more time on messaging and connecting with our audience. So go grab Foundation for Emails 2.2 and if you're in a Ruby environment, get the new gem. If you're working on something you're proud of or have any suggestions for Foundation for Emails, let us know in the comments below!
Foundation for Emails Meetup on July 14th
On July 14th, 2016 at 6:30PM, we're having people over our place to have some pizza, drinks and geek out about emails. We'll be sharing how to code up an email scaffold in just 10 minutes and talk a little about how you can use Foundation for Emails in your Rails asset pipeline. If you're in the area, come meet the team and be sure to bring your laptop!RSVP FOR THE FOUNDATION FOR EMAILS MEETUP
Let's be honest. People are messy. Organizations are incredibly dumb. Code can look like spaghetti. Given those facts, it's absolutely amazing that anything of significance (or even functioning) can be built by people from around the world that have never met. Yet here we are, almost five years into this Foundation product, today releasing Foundation for Sites 6.2.2. It's incredible to see over 12000 commits by 1000+ contributors. How in the world does this all work?
Given that we were not professional open source coders, the whole thing was a tad intimidating when we embarked on this journey in 2011. But we've learned a lot these past 5 years, and we're more excited than ever about the ways the community is contributing to Foundation's future. We've examined what's helped grow Foundation and narrowed it down to three things.
Here are the elements of success:
Have A Strong Opinion
This may sound counter intuitive, but the way you keep a vibrant open source project is by saying 'no' more than you say 'yes.' How can that be? Because strong opinions guide the growth of a project, attract like minded contributors and keep the quality level high. Foundation has always been more than a tool for us, it's a philosophy, a point of view. We have a clear mission here at ZURB, to change the way people design connected products and services, and Foundation is one the ways we're helping transform organizations.
Our vision for Foundation is not simply to create tools for implementation, but rather to create a shared language for designers and developers to communicate about what they are creating. This vision helps shape which contributions we accept and which we don't. As a product design company, we're constantly dreaming of new ways to push the limits of what the web can do, and we use Foundation day in and day out to make those dreams a reality.
Tools Matter Less Than Collaboration
As a technical product, we're selective about the tools and services we use to develop Foundation. The development process all flows through Git, a revision control tool that was created by Linus Torvalds, the creator of Linux, and specifically optimized for the problems that arise when managing a large software project with hundreds or thousands of contributors. Building on top of that, we use Github, giving us a web-based hub for our source code.
But the really important part is the collaboration these tools enable. Github helps us issue reports and have conversations that are rooted in the code. Slack and email help us have bigger conversations and involve the whole team. And the Foundation Forums put us in direct contact with users around the world. There's a misconception that software development is carried about by isolated nerds wearing headphones, eyes fixed on screens, and saying little to each other. The nerd part is true, granted, but development of something as big as Foundation is a very communication intensive endeavor and requires all kinds of interactions to be a success. While tools are important, it's the interactions that they foster that carry the most value.
Project Inspired (Not Project Managed)
Foundation has it's roots in our internal styleguide, and is used every single day in all of our client work. We absolutely depend on it, it has to work. You can imagine how hard it was for us to let go and open it up to the world. But you know what it? It made Foundation better! This is not to say we didn't have a few bumps in the road.
When we started opening up the Foundation development process more to the community, quite bluntly we had no idea how to update our processes to facilitate community development. We accepted pull requests on a rather haphazard basis, but mostly we continued to manage development and issue fixing mostly in-house. And you know what? Project managing sucks!
We realized that instead of project managing, we needed to share our goals with the community, provide a few guidelines, and let these brilliant developers run with it. We set up some contributing guidelines to get us all on the same page and christened a new team of superhero devs, the Yetinauts, to lead the way. We're proud to be able to say that our last 2 releases have been over 80% community driven.
Five years into this, and Foundation remains the leader of the pack, advancing not just frameworks forward but the web as a whole. It was difficult to 'let it all hang out', but moving development out into the open was the best decision we could have made. With your help, we're upping the ante even further. You can start by talking in the Foundation Forum, dig into the Foundation for Sites outstanding issues, or get involved with Foundation for Emails 2. This is your chance to help change the future of the web.
Foundation for Emails 2 has already changed the email workflow for thousands of people with a revamped CSS codebase, Inky markup to ditch tables, and a powerful workflow to stay D.R.Y. It makes coding HTML emails, well, easy. Today we are releasing Foundation for Emails 2.1 which further optimizes your workflow and speeds up coding. There are a couple new Inky components and more ZURB Stack magic to simplify your HTML email development and make you an email pro.
Beefing Up the ZURB Stack
Testing is a very necessary but time consuming process. Tools like Litmus exist to speed testing up so you can test many devices and email clients at once, but you still have to zip your images and send your email to Litmus for testing. But, what if you don't use an email service provider? How would you send the email to Litmus? Not to mention your images still need to be hosted.
To solve these problems, Foundation for Emails 2.1 introduces loads of helpful new features. The ZURB stack can now tie into your existing Litmus account and with a single command inline your code, optimize it (compress your HTML and images) and send it off to Litmus for testing. If you have an Amazon S3 account, the ZURB stack will replace your images with hosted ones so that they can be tested on Litmus. Foundation for Emails 2.1 helps you save even more time testing and preparing your emails so you can spend more time improving your product. Whether you have no email workflow or want to upgrade your existing one, Foundation for Emails has your back.
Huge, huge shoutout to Dan Van Brunt, @iDVB on GitHub and Twitter for setting this up and getting it across the line for this release! Give him a shoutout!
Just want to say thanks again for allowing me to help contribute foundations for email. I loved working with ink in the past so being able shape future of email development is pretty awesome.- Dan Van Brunt
Expanding Inky's Features
Everyone we've talked to has had wonderful things to say about Inky and Foundation for Emails 2. Coding a responsive email template in ten minutes is no longer wishful thinking, but full blown reality! Foundation for Emails 2.1 brings two much needed new Inky components that speed up coding even more.
New Spacer Inky component: Vertical spacing between email clients is not as simple as it sounds, in fact, it's consistently inconsistent. Versions of Outlook don't respect margin and padding the same and
<br>'s are different all over the place. Plus who wants to see
<br><br><br> all over the place?
<spacer> component takes care of this. It works the same on all devices and email clients saving you time and headaches down the road!
The size is the height in pixels of vertical spacing you need.
Thanks to Antonin Cezard, @acezard on GitHub for the Pull Request to add this into Inky!
At first I had a custom jade+gulp workflow but when I saw you released V2 I switched to your stack. This type of tool is too hard to maintain alone so, glad to contribute in a long lasting project. I definitely look forward to make some more PR's in the future.- Antonin Cezard
New Wrapper Inky component: The
<wrapper> component was also added to allow the creation of full width rows, targeting elements in section and adding background colors. These new components save you time not only coding but also in testing.
Making beautiful fluid width headers is now a reality:
All the starter templates have been refreshed with these new components.
In addition to developing the framework, the Foundation team has spent the last several months crafting our ZURB Responsive Email Masterclass. It's loaded with everything we've learned on responsive email design and development so our students can approach any email design challenge. We're continuing to add content to the course so our students keep up with the latest best practices, techniques and workflows.
The Big Picture
We're super excited about the reception that Foundation for Emails and Inky have gotten, and want to talk a little bit about where they are going. We see a future where Inky becomes the standard for how emails get written, anywhere and everywhere. This involves integration into all of the different environments where people are sending emails (the much-requested rails integration is coming soon), and making it easy to extend Inky so that everyone can build their own custom open source and proprietary email components.
Email development should be just as simple as web development, where you can easily integrate open source components, extend those components with your own custom styles, and create your own custom pluggable elements. Just like a company builds up a library of custom, pluggable modules of code and components, they should be able to create a set of custom, pluggable inky tags that make generating brand-coherent, beautiful emails as easy as can be.
We're starting the discussion of what that should look like today: Please join the conversation in the Foundation Forum
It's time. Foundation for Emails 2, the successor to Ink, has landed ashore! When Ink first launched in 2013, it made HTML email development suck less by giving developers a full responsive grid and set of components that worked right in any email client - even Outlook. Ink was the first product to take email best practices and create a framework out of them. Since then, companies of all shapes and sizes - Airbnb, Vice, Express, the Golden State Warriors - have been using Ink to easily produce great email campaigns. Now, with Foundation for Emails 2, we're streamlining email development workflow even more.
We've put a lot of work into making Foundation for Emails feel familiar to the millions of designers and developers who already use Foundation for Sites. Whether it's building with the grid, using Sass variables, or developing in our ZURB Template-inspired email developer, you'll feel right at home.
Here's what's hot in version 2:
A Sass codebase. Fans of Sass can now access a full settings file, giving you complete control over the visual styles of the framework. The component and variable names all have direct analogues to ones in Foundation for Sites, making it feel instantly familiar.
A full email development workflow. When Foundation for Sites 6 launched, we unveiled the ZURB Template, an all-in-one workflow for making static sites. We've done the same for HTML emails now with the ZURB Email Stack. Write HTML and Sass, compress images, and inline emails all in one starter template!
Inky, a simpler way to write HTML emails. Ink streamlined the process of writing HTML code for emails, but you still had all those tables to deal with. Who needs 'em? The ZURB Email Stack includes Inky, a new templating language that converts simple HTML tags like
<columns> into full table syntax.
Get Started Now
Much like with Foundation for Sites, we've got two ways to get started writing HTML emails with Foundation for Emails. The basic CSS download includes everything you need to get started right away: a boilerplate HTML file, the Foundation CSS, and twelve pre-made email templates to get you going. We've got a full tutorial that covers the whole process, from downloading to making a grid to inlining.
For fans of Sass, the ZURB Email Stack gives you access to a powerful build system with everything you need to develop HTML emails. And if you have the Foundation CLI on your computer, you can already install Emails projects! Like with the CSS version, we've got a full tutorial for the Sass version that explains how the ZURB Email Stack works.
Foundation is a community effort'we couldn't do it without viewers like you. If you run into a bug with the framework, report it on GitHub so we can help you out. Or, if you're not afraid to sail the stormy seas of HTML email yourself, submit a pull request and make your mark on the codebase!
We've also got a milestone for version 2.0.1, so you can see what's next for Foundation for Emails. Hope to see you around!
New ZURB Master Class: Responsive Email
We've compiled all of our knowledge and insights on responsive HTML emails in a new online video course! Master responsive email by learning how to rapidly design and develop responsive emails that are on-message and display well on just about every screen, browser, and email client out there ' even Outlook.
- Page 1 of 8
- Older Posts »