Episodes
Tuesday Mar 01, 2016
Tuesday Mar 01, 2016
Today’s Secret Sauce comes from one of our talented web designers Ashley Cyborski, who is a champion of designing in the browser. Not only is the method a major part of the design process here at Palantir.net, a deeper understanding of code and how it relates to design can allow web designers to push the limits of what their designs can – and probably should – do.
We'll be back next Tuesday with another episode of the Secret Sauce and a new installment of our long-form interview podcast On the Air With Palantir next Thursday, but for now subscribe to all of our episodes over on iTunes.Transcript
AM: Hi again everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick tip on some very small thing you can do to help your business be much more awesome.
I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from one of our talented web designers Ashley Cyborski, who is going to champion the benefits of designing in the browser.
AC: Hey everyone, My name is Ashley Cyborski and I’m a designer here at Palantir.
A major part of our design process for projects is designing in the browser. At first, I was a bit reluctant to learn code. It sounds kind of intimidating, but doing so has made me happier with my designs and much more efficient in my work.
Now, I’m a strong believer of working in the medium. As a web designer, it is important that we understand the medium and tools used to create our designs. Some people think that working in code will limit their creativity, but I’ve had the very opposite experience. Understanding the basics of CSS, HTML, and some JS [JavaScript] give me an understanding of what is possible. A deeper understanding allows me to push those limits and really flex my creativity on the web.
I’ve written a post about this topic that you can find on our blog, but I want to go through a few of the reasons that I think designing in code is something that every web designer should at a minimum dabble in.
First, your designs will be more accurate, and more realistic. Have you ever comped up a design in Photoshop, only to have your developer push back and say “this is too hard to do” or “it’s impossible” or that you need to modify various pieces so that the designs will work? If you are the one writing the HTML and CSS, you will be able to implement these harder bits. Creative thinking, which we all practice, extends to code. I’ve found that I’m able to code out some interesting bits that have stumped my development team. When you are invested in the designs, you are invested in getting the details right. You don’t have to worry about passing it off to someone else who maybe has different priorities.
Additionally, you can design with real content. Not that you can’t do that in Photoshop, but you don’t have to adjust the whole page when you change one little thing. There’s no need for random little boxes to measure the distance between list items or titles. Just type the value once and it remains consistent throughout your design. You can easily explore how various title lengths work, or how a news item looks with or without an image. And you don’t have to shift other things around on the page. They just shift on their own.
You are able to realistically see how things adjust responsively. There is no need to create two or even three comps to show a tablet view or a mobile view. You can show it more realistically in the browser, how it shifts within a single comp.
The real highlight though is when a client comes back with feedback. You only have to make that change in one spot, rather than in two or three static comps.
Secondly, all these little pieces give your clients a better understanding of the final design as well. Before, I often found that clients struggled to understand how a site might change as it adjusts to different viewports. But if you use code, they are seeing it as it actually is. The colors are rendering properly, as are the fonts. They can see how hover states work, and you can implement simple animations to show them things without having to provide a vague explanation that can be hard to understand.
Third, you will be more efficient once you master the code. Initially, it may slow you down a bit because you are learning, but once you get a basic understanding, you can create one comp that communicates responsive design, you can implement changes without having the page break apart. and you can set up basic styles that you can reuse consistently, and adjust in one spot.
These are all things with basic HTML and CSS that will increase your efficiency. But once you have mastered those, you can begin to add more tools such as a templating systems or things like sass, compass, postcss, or gulp that will increase your efficiency and improve your workflow.
Designing in the browser doesn’t just increase your efficiency, but it increases your team’s efficiency as well. You are shortening and combining two steps of the process. Not only are you not creating as many static comps, but you are shortening the process of translating those comps into code. And since you are the ones implementing the design, it shortens the design QA process.
This leads to the fourth benefit to designing in the browser, you can communicate better with your developer. Since you are implementing behaviors in your code, you don’t have to describe an interaction or animation, because you already made it. By writing the code, you have left little room for interpretation, so there will be less translation error between the design and development phases. You can add additional comments in your code that your developers can follow. You and your developers are now speaking the same language. There is no need for an interpreter which can ultimately lead to better cross team collaboration throughout the entirety of the project.
You’ve already heard from Carl [Martens] in a previous podcast about design systems, and designing in the browser helps to maintain and truly utilize the benefits of a design system during the process. The fifth benefit is the ability to create reusable code. This code can be as small as a single class, or as large as an entire component. You can reuse existing components to craft them into additional, new components that maintain the base styles of your system.
All of these benefits come together to make you more efficient, but the real benefit is to your clients. I spoke about how they are viewing their designs in code, as they will ultimately end up, giving them better understanding of the process and their final product. But your efficiency saves them time, which translates to either a smaller budget, or more features in their final site.
So how does designing in the browser fit into your process? For me, I usually start with some design discovery and exploration, maybe create some wireframes, and static comps using my tool of choice. Only from there do I move into the browser. I’ve found that you need to get some initial buy-in before you get into the code. My static comps tend to be desktop comps, and when I code them, I begin to make them responsive. As a team, we have improved the process by including a living styleguide with our prototypes. We break each page out into its components and document these along with their elements. This is a tool for our clients after we hand over the site, and for our developers as they implement the site into additional templates.
Learning to design in code can greatly improve your process and final product. So where should you get started? There are many resources online, from instructional posts and videos, to tutorials. I’ve found the best way to learn is to get your hands dirty. Take one of your existing designs and attempt to recreate it using HTML and CSS.
All you really need to get started is some type of text editor. I use Sublime Text. Create one document for your HTML, name it index.html. Add a doctype to the top and a head tag and body tag. You can check online to find how to do that. Create another doc named styles.css. Use a link tag to connect the two together, and drag the index.html file into your browser.
Within the body tag, write something simple like, “hello world.” You should see it in your browser. Within the body section, you can start to write your HTML, and on your styles.css page, you can begin to write your styles. You can style an element with a class or just style the element itself. Just get the initial coding bit out of the way first, and worry about best practices later.
I can’t really describe that feeling of accomplishment when you’ve been working to code something and you finally get it to look right in the browser. It is really awesome!
I really think that learning the basics of designing in code can help to improve your process and increase your efficiency. Your clients will really appreciate it as well. I hope I’ve encouraged you to give it a chance!
Thanks.
AM: Thank you Ashley, and thank you all for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!
Tuesday Feb 23, 2016
Tuesday Feb 23, 2016
Our Director of Professional Services Ken Rickard joins the Secret Sauce podcast today to tell us a little more about our consulting services.While we take on epic, end-to-end projects often, we also find that some clients don't need the long-term services. Instead, they need strategic help with a specific challenge, or perhaps require staff augmentation – in particular with Drupal projects – for a limited time.What works and what doesn't with such engagements? We always structure consulting engagements to ensure the work we perform adds the most value to your team and organization, based on a frequency (often weekly) that ensures your goals are being met.Need a helping hand? Let's schedule a time to talk.TRANSCRIPTAM: Hi, welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Ken Rickard, our Director of Professional Services, who is going to give a quick plug about our consulting services.KR: Hi, I’m Ken Rickard. I’m the Director of Professional Services here at Palantir. Today we’re going to talk a little bit about our consulting services. As you may know, we’re a full-service web strategy design and development firm, but we also do smaller engagements where some of our clients need strategic consulting to supplement the staff that they already have. In particular with Drupal projects, what we find in a lot of cases is clients that have existing staff who are very talented and very skilled, but don’t have a lot of direct Drupal experience. What we can do in that case is rather than do a big bundle of upfront training, what we put together is a consulting package, where you get to work with one of our experts during the life of your entire project. And it’s a very simple arrangement in which we spend a few days getting to know each other, getting the project plan together, and in particular structuring the build of the project so that you don’t have to learn all the parts of Dupal first. So we can start with some content modeling, then you move on to building out content types. Then you start layering in Views and Panels, and all the other things that make a site functional and exciting.During this whole engagement, instead of contracting us or someone else to go out and build it, your staff is doing the work. And what we’re doing is having an expert guide you through that. So we do this with check-in meetings. We set these up as two simple meetings a week. Generally on Monday . . . first thing Monday morning we get together, we meet for about a half hour and review what are your goals for the week: are you trying to build out Events? Are you trying to build out Single Sign On integration with an LDAP service (which is a very typical thing for our university clients)?As consultants, we walk through the problems and the challenges you’re trying to solve that week. We point out opportunities that you might have overlooked, we point out solutions that might already exist in the marketplace, and we look to the pitfalls that you might run into, such as, “if you try to do it this way you may run into this problem.” Or, “if you use this module, it may prevent you from doing this other feature that you’d like.”That helps you plan out your week. It also lets us ask, “is there anything we need to do to supplement you this week? Do you need any additional research done? Do you need us to review any specifications?” or things like that.Then we meet later in the week, on a Thursday or a Friday for about an hour, and review the work you’ve completed. It’s peer review. It’s the chance to walk through and see, “did it function the way you expected? Did you run into any unexpected bugs? If so, how do we troubleshoot those?” Because what we find the value to this consultation is . . . I would say 90% of the time your team is going to get it right. They’re going to have the right answer. But there are two things: number one, they may not know that they have the right answer, and that’s really discouraging. It puts the project at risk and it puts the team in a very bad position because they are just uncertain. It’s very hard to move forward confidently when you are uncertain, so we can come in and help provide that level of certainty. The second piece is in the 10% of cases where they don’t get it right the first time, it’s generally because they’ve either misunderstood a fundamental concept that’s not well-documented or is peculiar to Drupal, or because they’ve run into a very deep structural bug that needs expert analysis. So we’ve done several of these engagements with small clients and with large clients, and they are very very effective capacity builders. The other thing that they give you is a safety net, because if it does turn out that the project is bigger than your team can handle, we have someone positioned to step in and say, “ok, here’s what you’re going to need to complete this project,” and we can then ramp up a team to assist.We’ve had great success with this approach with a variety of clients, and we’d love to work with you on it. Thank you.AM: Thanks for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net.
Tuesday Feb 16, 2016
Tuesday Feb 16, 2016
This time we're joined by Palantir.net Engineer Kelsey Betham who tells us all about exporting features in drupal, including why and when you should, and how doing so could be a huge benefit should something go horribly wrong with your site. The full transcript of the episode is below.We'll be back next week with another episode of the Secret Sauce hosted by Account Manager Allison Manley, but for now subscribe to all of our episodes – including our monthly long-form interview series called On the Air With Palantir – over on iTunes.TranscriptAM: Hello and welcome to The Secret Sauce, brought to you by Palantir.net. This is a super short podcast, just a few minutes every week, that offers a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Kelsey Betham, one of our fantastic engineers, who is going to talk about exporting your features in drupal.KB: Hi. I’m Kelsey Bentham and I’m going to tell you about why should should export all of your features. This seems like the sort of thing you don’t need to do after you launch your site. But you’d be wrong, because at some point or another someone else is going to have to set up your site. Whether it’s because they are fixing a bug, or they are learning how it works, they’ll need to know what’s going on. And if you don’t keep your features up to date and exported, the only place that information will exist will be in your database. And there’s a chance that something, somewhere, will go horribly wrong, and you want to have it backed up in as many ways as you can manage. And you can backup your features by going in through the Drupal Admin interface. You can log in with a user that has the appropriate permissions to update your features. Go to the “Configuration” menu on your Drupal site and go to “Features.” Here you will find a helpful list of all of your features and their current status: whether they be up to date with your database, or in some way different. If you have the Diff Module installed you can also check to see exactly how the code differs from the database. You’ll want to check on this to see exactly what’s changed and be able to verify that all the changes that have been made are changes that you actually want to keep. Once you verify that all the changes you have are ones that you should have, you can go and click on the “Recreate the Feature” button. This will allow you to export the feature to exactly where it is, but updated with all your current configurations.Doing this sort of thing will help in the long run because it makes it much much easier to ramp people up on projects, as well as keeping anyone outside of the immediate project team aware of exactly how things are working at any given time. Thank you very much for listening, and I hope that you keep all of your features updated in the future!AM: Thanks for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Have a great day!
Thursday Feb 11, 2016
Thursday Feb 11, 2016
Giving feedback on how someone works isn't always easy, especially when it comes to your colleagues. Nor is it easy to receive it. But this act is very important for a number of reasons when done tactfully and constructively.Our Director of Operations Colleen Carroll talks about what works and what doesn't when both giving and receiving such feedback – not to mention the filters to consider when doing so – and the positive impact cultivating a culture of feedback can have for your internal teams. After all, it comes from the desire to improve something. How could your organization benefit from such a culture?Look for this interview-style format monthly on the second Thursday of the month, with accompanying short form installments that provide tips, resources, and other quick information via our Secret Sauce podcast every Tuesday.Want to learn more about how we cultivate a culture of feedback at Palantir.net? We're all about sharing.And do you like what you hear, and are you a client or partner of Palantir interested in being on the podcast? Let us know!
Tuesday Feb 09, 2016
Tuesday Feb 09, 2016
Wouldn't it be nice to have a butler on hand to help streamline things? Well, in this case we're not talking about a person who comes and waits on you, but rather an impressive and integral front-end development tool developed internally at Palantir.net to help automate some of our work.Butler does a lot of things and has plenty of features, which our Front-End Developer Lauren Byrwa talks about in this week's short-form podcast called The Secret Sauce. Things like:Gulp integrationCompiles your Sass and rebuilds your prototypeMoves your prototype into Drupal 7 or Drupal 8Refreshes your browser so you can see updates simultaneously in multiple placesPlenty of optimization options, too, so you know where exactly the performance issues are coming fromThanks for listening, and look for our long-form podcast On the Air With Palantir this Thursday!
Tuesday Feb 02, 2016
Tuesday Feb 02, 2016
Account Manager Allison Manley lets Senior Designer Carl Martens take the lead this week, as he explains the importance of thinking about Web sites in terms of design systems rather than pages, and goes on to talk about the benefits produced by taking this approach. We've seen design system thinking make a huge impact for our clients time and again because it creates a truly modular, extensible system onto which they can build for years to come as their organization's needs and goals evolve.We'll be back next week with another episode of the Secret Sauce, but for now subscribe to all of our episodes – including our long-form interview series called On the Air With Palantir – over on iTunes.
Tuesday Jan 26, 2016
Tuesday Jan 26, 2016
In this installment of the Secret Sauce, Project Manager Tom Jones discusses the helpful exercise known as Like, Wish, Wonder. It can help your team overcome groupthink and stay engaged during a project kickoff.So grab a post-it note and marker, and start answering some important questions: what do you like about your current site, product, workflow, etc? What do you wish it could do? And then what do you wonder about it? The wonder is more challenging, and looks toward future goals. Take a listen, let it sink in, and consider it for your next kickoff.We'll be back next week with another episode of the Secret Sauce, but for now subscribe to all of our episodes – including our long-form interview series called On the Air With Palantir – over on iTunes.
Wednesday Jan 20, 2016
Wednesday Jan 20, 2016
This is the first in our weekly bonus podcast that deals with shorter tips and resources that will help you with some straightforward facet of your web project. It's a compliment to our monthly, long-form podcast On the Air With Palantir.That's why we call it the Secret Sauce.Some episodes will focus on strategy, design, metrics, or other such topics, while others will be more technical in nature. Whatever the focus, we want these to be useful for you, so we draw from our real world experience.This time around Allison Manley lets Larry Garfield take the mic to talk about Drupal 8, how you can prepare for it properly, and how the changes in this new version push us toward a content strategy approach. While applicable to anyone considering Drupal 8, this particular episode is mostly technical in nature and geared more toward site builders and developers.Look for the Secret Sauce bonus podcast released weekly on Tuesdays.
Wednesday Jan 13, 2016
Wednesday Jan 13, 2016
We're very excited to kick-off our new podcast called On the Air with Palantir, and welcome you to listen to our first episode with Andy Gradel and Christine Fagan from Main Line Health System (new site not yet launched).In this episode, our resident podcast veteran Allison Manley discusses the project, the importance of analytics data and developing a sound strategy, user-tested decisions, design, platform challenges, and much more with our stellar client stakeholders.Look for this interview-style format monthly on the second Thursday of the month, with accompanying short form installments that provide tips, resources, and other quick information via our Secret Sauce podcast every Tuesday. We'll update our iTunes link above once it goes live there.Want to learn more about our services, and how we drive success through strategy and design for our clients? We're ready to help.And do you like what you hear, and are you a client or partner of Palantir interested in being on the podcast? Let us know!