Posts About ZURB
We don't have to look far for new opportunities here at ZURB. Sometimes they arrive at our doorstep, even from as far away as the Emerald Isle of Ireland.
It's with great pleasure that we introduce you to our newest ZURBian, an Irish import who loves a challenge. Everyone say hello to …
John Leenane, Business Development and Partner
John may have originally come from across the pond, but he's been in the Bay Area for about 14 years. He's worked with companies, big and small (read: startups). He recently founded two companies of his own, but once his path led him to ZURB, there was no turning back.
John's our newest Partner and Business Developer. And he's already gotten his hands dirty, opening up new opportunities for ZURB. He's focused on growing our business and finding new ways to bring ZURB to the next level. As part of our Connections Team, he'll continue to foster relationships, both new and old, sharing our mission of "Design for People" to anyone within earshot. And he can't wait to do so:
I'm really excited about helping all of us at ZURB, our community and all the companies we work with to reach their potential.
Not to worry, he's not all business. John knows how to have a bit of fun. He's a snowboarder, a windsurfer and a concert goer. These days, however, most of his spare time is spent with his wife and four boys — the latter which provides its own unique fitness regime.
Everyone please welcome John to the ZURB team!
Not too long ago we gave our Playground page a brand-new responsive polish. The Playground is one of the last ones we made responsive. And when we finally released its update, something horrible happened — our search ranking evaporated until nothing was left.
When launching a new product or a redesign, we usually mind our Ps and Qs. We have a laundry list of things that we check, double check and, sometimes, triple check. Since Playground gets a ton of search traffic, we tripled-checked all the SEO things we knew, such as:
- URLs and redirects
We even fixed a number of things broken in the previous site. But that due diligence didn't seem to be enough. Week after week, we watched in horror as our search ranking dropped and dropped and dropped to nothing. We didn't even rank for some of our more well-known Playground pieces, such as Orbit and Reveal. What the heck was going on? Where did we end up going wrong? Was there something we missed? We were scratching our heads.
Whittling Down the Problem
First, we combed Google Webmaster Tools, which showed no errors. Bing and Yahoo still worked as expected. The problem was only in Google (read: the only one we care about). To figure out what happened, we went through all of the things that we could've messed up:
- Duplicate URLs
- Broken URLs
- Bad redirects
- Content being loaded via AJAX
- WWW vs. no subdomain
- Page load time
- Invisible text
- Service disruptions
- Bad robots file
- All of this stuff here from Google
We did all these things. And like we said earlier, we had even fixed most of them with the redesign. We even reached out to Google to figure out what happened, and they finally gave use a short response explaining the problem:
Thank you for your email.
It appears that you're serving Googlebot a different content type than you're serving to regular users. This is preventing Google from correctly interpreting your site. If you use the Fetch as Google tool in Webmaster Tools, you'll notice that Googlebot sees pages like http://zurb.com/playground/ajax-upload with "Content-Type: application/zip; charset=utf-8". Googelbot is unable to interpret the content type of your page which is preventing your page from being crawled properly.
What does that mean? Well, the root cause of the problem was that our server was setting a content-type that Google didn't like, so they stopped indexing our pages. All browsers were either not getting this content-type, or just ignoring it and figuring out to us the right one. If you knew exactly what to look for in webmaster tools, you could ferret out that Google was getting this content-type. But no error was reported anywhere. In fact, the page was indicated a "success".
Eventually, the problem was fixed with the correct content-type on our back end code. Everything was back to normal within a week. And Google gave us a curt response to our questions about why this happened in the first place. We asked how do we get the content reindexed now and why webmaster tools didn't show this crawl error.
It might take some time for Google to start reindexing URLs on your site depending on a number of factors like how often Google is able to crawl your site. These pages most likely did not show in Webmaster Tools as crawl errors because the pages were live and able to be crawled returning an HTTP 200. However, when Google tried interpreting the data on the page, it was unable to convert the file type and may have chosen not to index a page that did not have any content on it.
A Cautionary Tale
But this isn't about the solution or the resolution. This is a warning. You can't just launch something and not pay attention to your traffic. You might find out something horrible went wrong, long after it's occurred.
We always look ahead to new ideas, new events, and new ways to help people make great products. But as we close out 2013, we also stop to look back — and what a view it is. This was the year we brought into sharp focus our educational efforts with the launch of ZURB University, a better strong Foundation, new apps and improved ones. So let's take a look at 2013 ...
1. We Acquired Forrst
The design and developer community Forrst joined our family in January. We acquired this feedback community because we wanted to help people iterate through their work and learn from helping others. We saw an opportunity to build upon what founder Kyle Bragger started and make Forrst a place of active learning.
2. The Smartest Foundation Yet!
3. Teaching Product Design Through ZURB University
We began holding live, online Product Design training sessions in April. We felt, and still do, that it's crucial for every business to understand product design, especially with the proliferation of mobile devices. We've poured our 15-year experience into each of the ZURB University classes. We've held more than 30 webinars so far, held several in-person workshops and even sent our designers abroad to help hundreds of people learn our approach to better product design.
4. Creating a Library Resource for Product Designers
Education as a product designer is ongoing. There are always new things to learn. And we're happy to share our what we've learned, whether it's through a new Playground piece, a new pattern or an interesting factoid. Over the years, we've built several resources for designers, but they'd all been their own separate ventures. With ZURB University, we organized some of our properties — including Playground, ZURB Word, Pattern Tap, Friday 15, Design Quips and Behaviors — into one Library resource. There are also weekly product design lessons. This resource helps product designers learn the many facets of product design under one umbrella.
5. So Long Painful Images Loads on Small Devices
Images in responsive web design have long stymied designers. Many have proposed solutions, but none quite fit every need. In May, we tackled the problem and released Interchange, our solution for sending the right images to the right browsers. This new technique inspired people to design sites that look great across any platform while saving bandwidth and time for end users. So much so that we took this and baked into the next version of Foundation with some additional changes (see number 8).
6. Beating the Clock for ZURBwired
In August, we worked with nonprofit Rebuilding Together Peninsula to create an entire marketing campaign during our sixth ZURB Wired. They learned from our 15 years in a marathon 24-hour sprint. We do this every year to help nonprofits learn the benefits of design thinking and not getting stuck in details. The philosophy behind Wired is that anyone can learn product design to break through barriers and create something wonderful.
7. A Mobile-First Forrst
Eight months after we acquired it, we unveiled the new Forrst site. The focus of the redesign was to make it easier for Forrsters to give contextual feedback and truly make Forrst a place of active learning.
The new mobile-first design makes it easier for designers and developers to give constructive critiques on the go. Notable-style comments help people give contextual feedback on every screenshot. Versions, our most recent feature, helps people see the progress of each post over time. The end result: people can iterate through projects with outside opinions that provide new insight.
8. The Fastest Foundation Yet!
A new Foundation blasted off in November. The fastest version of our popular framework ever was also the most downloaded at launch. Foundation 5 brought a whole new game with Interchange, which can now work with any type of content, improved speed overall. We also switched from Zepto to jQuery 2 for greater compatibility with the web design world. Designers and developers can now spend more time designing and developing than reinventing grids and UI components, making it even faster for them to use..
9. Strengthening the Foundation Community
We also placed an emphasis on faster learning with Foundation 5. Along with that, we launched a new forum for Foundation users to discuss issues, get help, and swap tips. This gives designers a central venue to learn about the CSS framework from each other. Since launching, we've had more than 550 posts!
10. Launching Ink, Our Responsive Email Framework
We introduced Ink, a responsive design framework for email, in November. We built upon our previous responsive email templates, but this time we created an entire responsive framework not just another series of templates. Why? Because frameworks give you a consistent code structure and styling that makes it easier to modify layouts in the long run. Better than just a single template, Ink allows designers to build complex layouts tailored to their needs.
It wasn't easy to create a framework that works across any email client, but we found a way to create a mobile-, tablet-, and desktop-friendly framework that makes emails look great, even on Outlook. We learned so much from developing Ink that we started an online course to share our experience with others.
2014 ... and Onward!
This was the year we strengthened our education services. From Foundation 5 (faster product development) to Forrst (smarter iterations) to University (formal design education), we've dedicated ourselves to building a learning organization that helps us and others improve their design skills. But our work doesn't end with the year — you can count on more resources and services to further your design education in 2014!
On the first day of ZURBmas, a ZURBian gave to me … an hour-glass with cards. OK, we won't bore you with our caroling. But it's pretty amazing to see our annual gifts get into the hands of our customers and friends who've supported us over the years. And wouldn't have been able to get them there without the entire team helping and applying a flexible process. And the last part is what got us over humps in the project.
This year's gift was based on Friday 15, which are creative challenges that our entire team does every Friday afternoon. We started doing these fun exercises a while ago to hone our product design and problem-solving skills. It's become part of our culture and allows members of the team that don't usually work together team up (pun intended). While we had a concept, we needed to approach the problem of creating something special the same way we'd do for any project. Having that process made us get the gifts out the door in a tight (really tight) timeline.
On the 1st Day of ZURBmas, Build a Prototype
We got the idea to make a card set because we spend a lot of time playing card games after work. But would the idea fly? With sharpie and paper in hand, we whipped up a back-of-the-napkin sketch to estimate costs. Having a ballpark cost allows for better-informed decisions and helps manage the iterative process. It allowed us to answer: was the concept technically feasible? Did it meet our goals? How would our customers interact with the card set?
Prototyping also helped figure out these questions, including what exactly we needed to order, and costs. We constructed two prototypes: 2×3 (playing card size) and 4×6 (a bit bigger than an index card). Having something physical allowed us to investigate different ways of constructing the cards. We got a feel for how the cards felt in someone's hands. The winner: the playing card-size set. The 2×3s fit nicely between the fingers and was much easier to flip through. With that decision made, we could now make other decisions — like the design and who was going to be on our ZURBmas list!
On the 2nd Day of ZURBmas, Get Everyone Invested
Sending out an annual gift takes an entire team. But to get the elves into the workshop, they have to be invested. Storytelling was key to this. We had to tell the team the story of ZURBmas. They needed to understand the why of sending gifts — the benefits to ZURB, to themselves, and to the customers. And that was important to help the team visualize the end goal — getting the gifts in the hands of our recipients. Or else they might not give a Dickens. (See what we did there?)
We started telling the story of this year's ZURBmas gifts with the leads, then spread out to the rest of the team, like concentric rings when you plunk a pebble in a pond. This also allowed us to get feedback on the concept as well as on the prototype, and the designs for the card set, the greeting card and everything else. With the team onboard, we were able to divide the labor because no one person can do the holiday list, order the materials, create the designs and then box everything up for some 1,000 people. And the more people involved, the more we were able to open up problems.
Jingle Bells, Jingle Bells, Timeboxing All the Way
The timeline for this project was tighter than Santa's suit after he's had a few Christmas cookies. Starting in November, we had to ship everything by Dec. 13. And our sled hit a bump in the frost with our mailing list. We had to open up the problem and having others involved helped get us to a better answer.
For instance, our mailing list. It was collected from various sources: our clients, our close friends and those who signed up for our monthly newsletter. Not everyone was going to get the 15-minute hourglass. We had to decide who was going to get that or get the card set. We enlisted our Connections Team and our accountant to help divvy up the list, and our leads and interns contributed by pruning it of old or out-of-date addresses. Having those folks participate in the list allowed us to explore why only one group would get the hourglass/cards while others would get a card-set and a special holiday ZURB sticker. Our solution: clients, customers and close friends would get the former while everyone else would get the latter.
We took a similar approach when it came to figuring out the vendors for printing the cards. Creating burndown lists the entire team on target. And as the old adage goes, two heads (or many, in this case) are better than one when it comes to solving problems.
Let's Build a Gingerbread House
But that wasn't the only problem we opened up. We explored what else we could do to make ZURBmas special, especially for those who weren't getting the hourglass and those not on our holiday list. After exploring different concepts, we came up with the idea of creating an interactive game related to the "Gingerbread Tower" Friday 15 challenge.
'Twas the Night Before ZURBmas …
… And all through the house the ZURBians were packing. Having solved the project's problems, the entire team spent the last few days before our shipping deadline stuffing boxes and envelopes or filling out customs shipping forms. That's because they were invested. Like we said, they got the story of ZURBmas and wanted to be part of it. And they were all excited to see people tweet out pictures of the gifts they got. And we wouldn't have been able to sell that story or get the gifts in their hands without a flexible process. It allowed us to load up the sleigh, hitch up the reindeer and deliver the gifts to all our good friends and customers.
And with that, we want to wish a Happy Holidays!
Conventions tend to turn invisible. Like ninjas, they blend into the background. We blithely accept that privacy policies, for example, are long blocks of indecipherable, dull, gray text. They don't encourage people to understand what tapping that "I agree" button actually commits them to. As a result, few people read fine print thoroughly.
Not just write policies, but to build fabric, and build culture and build passion, and build architecture and engineering behind human rights."
Don't be Afraid to Suggest Outlandishly Creative Ideas
Michelle said most agencies took the traditional route to learn project scope, asking questions about format and branding requirements. They talked about typography for pages of text, and gave professional — though standard — presentations about making the policy more digestible for people. We took a different approach.
"Pirates or ninjas?" Our first question to Michelle set the tone for our relationship and, as we learned, helped define the project.
Our design process always begins with opening up problems, exploring opportunities, and focusing on the concepts that stick before closing down on solutions. Long before we touch code or Adobe products, we reach for sharpies and paper. So we explored many ideas that we could pitch to Michelle. Such as:
- What if we presented the policy as a video?
- What if we offered "legal" and "human" modes?
- What if we arranged the policy in Q&A format?
- What if we formatted the policy as a storybook?
Half-jokingly, we threw a ninja into the presentation. "A comic ninja who explains the legalese — wouldn't that be hilarious?" Maybe it would be too flippant. McAfee was a serious company, after all, and privacy isn't a trivial subject. But the ninja stayed. Why not?
To our surprise (and her delight), Michelle loved the ninja idea most.
New Ideas Need Extra Development
This format was the first of its kind, and by risking something new, we had to discover new conventions. So we took an extra week to second-guess the ideas and test assumptions. Several iterations later we settled on a storybook-like format. It was easy for users to learn and — most importantly — approachable.
The more we riffed on the concept of a fictional privacy ninja, the more unusual — yet plausible — our ideas became. The project became more than a single document. We explored:
- A "build your own ninja" tool
- The option for users to choose a character to defend their rights — super hero, ninja, or security guard
- Using the ninja as content, not decoration. More infographic, less clip art in the margin.
Versions of the ninja became less cartoony, more realistic. But in the end we opted for our original simple cartoon that almost didn't make it into the presentation.
Unusual Ideas Need Support Before and During Iteration
While Michelle loved the unorthodox idea, we wondered how to propose it to others. How would they take it? Once again, we found that wondering about rejection was needless worry.
When Michelle presented the ninja idea to her boss, she was careful to explain that the "cartoons" were a means of communication, not a means of making the policy seem childish.
She also took the idea to the Federal Trade Commission. She said companies preemptively telling the FTC, "I"m taking a risk," was unusual. In this case, it worked. The FTC had never seen anything so creative in a policy — and they liked what they saw.
Michelle returned to McAfee with outside acceptance. The risk of a cartoon ninja — an afterthought and half-serious cartoon — was paying off.
Risks Pay Off in Unexpected Ways
Originally, we agreed that concepts and mockups would be our final deliverables. But later McAfee asked us to build out a working prototype storybook. Over two weeks we created a single-page microsite with animated, jQuery-based "pages." At the time, no one else had created reliable animation for the particular look we wanted, so the project's lead engineer took a risk and wrote his own.
Part of taking risks in design is knowing when they're appropriate. Storybook or not, the policy was a legally binding document. The legal team was adamant on certain phrasing. But while the legal text remained essentially the same, our new format organized it into easily digestible chunks. Graphics showed what text meant. And the ninja illustrations made the document approachable.
It pays to question assumptions. Even if the ninja hadn't panned out, it got us thinking. By suggesting "crazy"'ideas, we were able to open up the problem, break away from convention, and deliver something unique. You never know when a bad idea will lead to a great one. Like ninjas, great ideas don't appear unless you're willing to risk looking for them.
Design is iterative. And much of product design is iterating on someone else's ideas. Strictly speaking, successful products are built (and innovated on) using patterns that have proven to be successful in other places — say, traditional marketing. And as it turns out human motivations work in similar ways online and off.
There's an almost unlimited wealth of research and data about human psychology, behavioral tendencies and intricacies. It's widely available to curious designers everywhere. And that's the challenge — it's literally "everywhere." The research is scattered across hundreds of resources and only the bravest of design souls are ready to dig through it.
Reining in the Research
If not brave, we're definitely zealous. We set out to collect psychological motivators in a resource library and, like much of everything else we do, make it available to anyone in search for product design literacy.
We call them Design Triggers.
We've spent about a year collecting materials for this newest addition to ZURB University Library. It turned into a unique collaboration between three product designers, each with a perspective on what the library needed to convey.
- A designer with a Masters in Human Computer Interaction fleshed out the library's taxonomy, making it easy to navigate.
- An engineer with a Masters in Applied Anthropology made sure our evidence was sound.
- A Design Lead at ZURB was making sure we provide valuable and tangible advice and product design examples.
Making Triggers Make Sense
So here we were with a ton of really useful information, goodies that we wanted to share with the community, but not a great way to go about it. We had an epiphany after interviewing a few of our own ZURBian designers. They reminded us what we already knew — the best place to start a design concept is with a goal. That gave us the spark we needed to create a complete taxonomy around design goals and triggers.
We outlined a couple dozen goals designers may need to tackle in their interface, for example:
Showcase a New Product
We then highlight a set of triggers that can be applied to achieve this said goal. Triggers are tied to each goal through user scenarios to help designers explore ones suited best for their use case.
Demonstration, Conceptual Metaphor, Storytelling, Familiarity, Keywords
Each trigger has been meticulously researched. The evidence comes from sources in behavioral psychology, cognitive linguistics and consumer psychology, so designers can feel confident speaking to the value of each motivator in their next presentation.
The act of learning indirectly through watching and imitating others is called Observational Learning in psychology ...
Then, to give designers a starting point of applying a trigger, we outline some suggestions on how to use each trigger in product design.
Frame the demonstration from the viewpoint of the user and give a variety of examples, showing both what they should and should not do. Make the examples visual and interactive …
We take showcase libraries one step further by explaining why a particular example works, describing how a trigger is applied in real world.
"How to" from Indochino
Users are shown exactly how measurements are done with this service.
Triggers, examples and design goals all come together to give designers the background they need to make smart product design decisions and have the facts to back them up.
Another Tool in Your Arsenal
Being a product designer, among many other things, means understanding how users make decisions. That's what makes Design Triggers a really exciting addition to the ZURB University Library.
Unlike a design trend that may change in less than a year, triggers can provide decades of value. Be it skeuomorphism or flat design, providing the right hooks at the right time will create a meaningful experience for customers. Customers don't care if their achievement badge has a gradient or not, they are just excited to earn one.
Achievement is one of the better known motivators and is one of the design triggers we're starting this resource library with. Be on lookout for more triggers and design decision ammunition continuing to stream in and see how you can start pulling the strings of your customers' motivations with Design Triggers.
After hearing that song a lot at ZURB HQ, we've finally learned what the fox says. He says he's glad to be our newest ZURBian. Without further ado, let us introduce you to …
Alex Fox, Designer
Our newest ZURBian is an industry-hardened design cowboy from Dallas, Texas. So of course he loves good music, better barbecue and harbors a reputation for awesomeness.
As far back as Alex can remember, his life has revolved around technology. The many ways that devices enrich our day-to-day lives has always fascinated him. The best part for Alex — design is at the forefront of it all. For the past five years, he's sailed the high seas of agency life as a designer in print, web and everything in between. That experience helped him craft his arsenal of design skills.
Design has always been a huge part of my life. Even as a wee lad, I had a deeply profound passion for building new and interesting things. As I grew, so did my passion for design. Legos became logos, web apps and so much more.
When Alex's not mashing keys, he enjoys exploring the various eats and activities in the Bay Area. So please everyone welcome Alex!
We've been talking a lot about frameworks lately, whether it's a responsive front-end one like Foundation or an email one like Ink. One of the advantages of a framework is that allows product designers to worry less about building across devices and spend more time improving their skills. After all, for a designer, there's always a new skill to learn or improve on.
For our team of product designers, the skill to keep pushing has been visual design. Our projects have always had a simple set up: one designer, one design lead. Since each designer owns the whole project from start to finish, they owned the visual exploration phase as well — until about a year ago. That's when we decided to spice things up and split the exploration between three designers, giving the team an opportunity to learn from each other. Which incidentally allowed us to show a greater variety of options to our clients. Everybody wins.
It was a great idea. We saw a big increase in the overall level of visual design skills here. Though to be fair, the improvement was mostly evident among the designers who volunteered themselves the most.
Now we're iterating on this process again. To see how we can level up the entire team. We're mixing a bit of the old with the new — putting the pressure back on project's designer to own the majority of the exploration process, but giving fellow designers an opportunity to inject a bit of creative spark into it.
Clients always want options. Distinct, viable, amazing options. Creating distinct, awesome options is hard. Many designers tend to fall into their own comfort-style and getting out of it means to challenge your skills. It's difficult. And absolutely necessary for the first exploration pass.
Our new approach has the project's designer creating six to eight quick-and-dirty layouts — we call them directions — in about three hours. This pushes the designer to think in broad strokes, keep moving and not fixate on details that don't create value. In the end, each direction must have a unique point of view, a story.
We found that when a design direction doesn't tell a story, it becomes impossible to defend and get buy in from stakeholders. When the only distinction between options is the color of the top-bar or header font, you can find yourself in a debate over personal taste versus what the visual says about the product or user you're designing for.
Bit of Healthy Competition
Somewhere deep inside every designer just wants validation that he's good designer. We want to see how another designer solves the same problem (and gauge our solution against theirs — we know you do that too). We saw that when we pitted designers against each other, they pushed themselves hard to design something the others would admire.
We also noticed work getting better overall. Our visual design rockstars were teaching others their craft without even realizing it. Simply by explaining their process and how they made design choices — typography, color, imagery, all the little details that make a design unique — they were influencing how less experienced designers tackled their next project.
From the first exploration of six-to-eight directions, we pick the three most promising and divvy them up between three designers. They are asked to iterate on the direction, not start from scratch. Why? Because the story has to hold up after they're through with it! After a day or so of work, we reconvene and review the work. We talk about it, are brutally honest with each other about what works and what doesn't. Then we go back to make it better.
Dishing It Out and Taking It
We have become super adamant about using design terms and principles when giving each other feedback. We can't just say "This typeface doesn't work." We have to say why. This forces us give concrete reasoning for our feedback — maybe the font is illegible or doesn't complement some of the iconography — that actually gives the designer something to work with!
By looking at each other's work and critiquing it, designers started seeing their own layouts in a new light. After you comment on someone's margins a couple dozen times, you start paying attention to yours. It's just natural.
Plus, giving each other feedback has given us ammunition for presenting work. We have trained each other to validate design decisions and preempt questions the viewer (say, a client) may have. We have fun practicing these skills too. During our weekly design team scrums we often play a feedback game, changing up the rules every time, like:
- Two teams take turn giving feedback on a layout. Team who uses the most design terms wins!
- Paired up designers have to give feedback together. One person starts and the other has to finish their thought.
- Break designers into two teams. One has to defend the design, the other has to tear it apart.
- Designers randomly pick flashcards with design terms, which they have to use in their feedback.
Hey, we like to have a bit of fun with our work. Well — a lot of fun.
It's Not Always Talent. A Lot of It is Just Practice.
If we had learned anything from changing up our visual exploration process is that designers can have tremendous growth by practicing visual design skills. That's because design is not art. Design is solving problems through a visual language. And you can get really good at solving design problems by tackling a lot of them, and often.
The only way you can improve — well, just about anything — is to get feedback, iterate and get feedback again. Being open to other designers' opinions and practice actually makes you a better designer — we've seen it work wonders in the last six months. We have a super passionate, committed team. We encourage and push each other. And every single project is upping the ante on the one before.
The response to our Foundation 5 launch has been incredible. Over the first 36 hours, we had 190k visitors to our properties and 800k pageviews. The average time on Foundation was seven minutes. We reached 180 countries and territories in that time. Keep in mind, this is an open-source code project! It's amazing to be part of a project that millions of designers and engineers use on a daily basis.
What We Learned From Foundation
We've learned quite a bit about frameworks over the course of five Foundation releases. The first, and most valuable, is that creating something of value takes time. Lots of time. Foundation is now over two years old and we've committed and removed thousands of code bits. We've answered countless emails. Since April alone, we've answered over 3,000 cases via email. The ZURB team has been incredible and stepped up to support the community. And that's just email support. We've made over 5,000 code commits with the help of the community, toured the globe speaking at events and hosted lots of meetups for our fans.
The second thing is that we can provide even more value by creating revenue streams that support its growth and ensure its success (all the while continuing to keep the project open for the millions worldwide that depend on Foundation). Projects like Drupal, Wordpress, Ruby on Rails, and Node are examples of open-source projects that have companies who are heavily invested in the code and community. Based on our experience, we believe most companies would prefer to use an open-source framework and pay for services, instead of managing a costly solution of their own.
HTML and CSS Still Rule
With the proliferation of devices over the last couple years, companies understand that they need to create products that meet the growing demands of users — sitting in front of a desktop computer won't be the primary use case for customers. Heck, looking at a phone may not be either. iOS and Android are exceptional platforms that companies will need to invest in, but the open web will continue to be a huge part of what users expect as well.
HTML is now over 20 years old and CSS is not much younger. Technologies have come and gone, but these two have continued to survive. With more "dumb" and smart devices emerging, we're firm believers that companies will depend on these proven technologies for their visual interfaces. Which means that companies need a way to manage how they produce their interfaces across all these devices.
Front-End Frameworks to the Rescue
It was clear when we developed Foundation that we needed a way to standardize our coding approach across our company. As early as 2007-08, we were starting to standardize our approach to make it easier for everyone on our team to contribute to a project. Standardization and speed were two huge benefits. Our style guide also encouraged best practices.
By early 2011, we had built the first version of Foundation and collected a lot of feedback. It was clear this was huge for people who built applications and websites. But with mobile growing, we knew that our framework had to be responsive. Foundation 2 was the first responsive framework. We followed this up by introducing Sass, semantic markup, and a mobile-first approach in the next versions. We learned a lot — what to do and not to do when it comes to standardizing our approach. Creating a code base wasn't just about the code, it was an operational problem that required getting people to accept a solution. Now that frameworks exist, it's much easier to get a team onboard with the concept.
It's clear from our experience that companies need a framework for their front-end development. It's simply too costly and painful for companies not to have a standard. Whether it's a custom implementation, pattern library or pulled code from an open-source framework, it really doesn't make much sense to hand code everything. And yes, we understand the purists will shout out. But we believe the need for most people to create front-end code may not even exist in the not-so-distant future.
Providing a Professional Solution
Creating a framework can be a costly endeavor, it makes sense to adopt an open-source solution for most companies. Open source is a choice many companies make, but that's an argument that you either believe in or not.
With our latest release, we're making it easier for companies to invest in the Foundation framework as part of their development stack. Our Foundation Business group is now providing support, training, consulting and products to support these companies. As part of this effort, we're also supporting our new responsive email framework, Ink.
We understand that for many companies making technology decisions aren't easy, but for those companies who are already invested in Foundation or want to make the switch from their own set-up, we're giving companies the peace of mind that they're not going alone. If your company is interested, please check out our Foundation Business site to see how we might be able to help you.
The final countdown to the release of Foundation 5 has already begun around ZURB HQ. And we can't wait to hear what y'all think. Whether it's via email, tweet or Github, we enjoy hearing from those using our framework. We also love it when we can meet face-to-face like at our Foundation meetups. Which is why we're really excited that next year we'll be going on a World Tour. We'll meet with our global audience and learning how they use Foundation to solve product design problems.
For two months in 2014, we'll pack our bags and jetset to 15 or more international locations, such as Melbourne, Buenos Aires, London and Munich. We're taking product design on the road so that we can go where our customers are. And with the global attention Foundation has garnered since its initial release in 2011, we could no longer sit still in our comfy chairs from little ole Campbell anymore.
Something Magical Happens When Meeting in Person
Airbnb's Joe Gebbia told us a fantastic story once about the importance of meeting your customers. One day, Y Combinator's Paul Graham took a look at the plans for Airbnb and told Joe and his fellow founders that it wasn't going to work. Then he asked them a simple question, "Where is your market?"
The founders said New York. Paul then gestured wildly and said, "Your users are in New York and you're here in Mountain View. What are you still doing here?" So Joe went to New York and met with his customers, learning more about his own product than he could've learned sitting in Mountain View.
Meeting other product designers, whether individuals or large teams, gives us more opportunities to learn about the problems their trying to solve. We also want to learn how Foundation fits in people's workflows. And we've found over the years that when we go speak somewhere and meet people sparks even more ideas on how to improve our products. Magic happens when you can directly see how your customers use your tools.
On the Road Learning
We built Foundation and our product suite to help others build better products that work faster on any device. One aspect of our latest Foundation release is faster learning. We've rewritten the docs with more detailed and new code examples, a new Getting Started guide and a forum to get help from other Foundation users. Why? Because learning is very much who we are. It informs everything we do.
One of the reasons we're going on a World Tour is to have a product design exchange with other companies. We want to learn how other people practice product design, and show them how we approach it. We're also game for on-site product design training, including tips on Foundation, as part of our ZURB University efforts. Or if we want, we can tackle a practice three-day project that accomplishes design goal using our Design Process.
We'll also host meetups for both Foundation and our new responsive email framework, Ink. We'll chat about where we're going next and give tips on using our frameworks.
Want Us to Come to Your Town?
We've got a handful of cities already on our hit list, and we're looking for a more. We'd love to drop in. Tell us a bit about your company and the type of event you're interested in, so we can start planning our time together.
- Page 1 of 25
- Older Posts »