Sandstorm Blog

Cache clearing menu

At Sandstorm, we do a lot of website maintenance. That can mean many different types of things like development of new site components, updating old content or creating new content. With each of these different types of work there is a popular issue that can cause panic: he or she forgets to clear his or her caches after making the updates.

Nothing changed. Is the site broken?

If you’ve ever maintained a website, or maybe just updated content on one, you may have come across a situation where it looks as though your edits didn’t save. This ultimately leads into what seems like a broken website, but turns out (after consulting a developer) that you just need to “clear your cache”.

What is “cache”?

Like most people, myself included, when this first happens you are probably wondering what in the world is a “cache”. Google will tell you that it is “a collection of items of the same type stored in a hidden or inaccessible place,” but that makes me even more confused. In layman’s terms, cache is a save file that allows web pages to load faster.  

When you arrive at a website, your browser takes elements of that page and saves them locally into “cache”. This way, the next time you decide to visit that specific page, your browser is going to remember how it looked the last time and, instead of downloading those pieces again, it will use what is stored in the cache to build the page. This results in a great performance boost. Unfortunately, it can, at least appear to, be a nightmare for content editors who don’t understand why their changes are not showing up on the live site.

It’s an easy issue to address

Even with this knowledge, I still come by this simple issue every so often (so don’t feel bad if you do, too). What you should remember is to clear your browser’s cache, refresh the page and see if your edits are now in place (this is particularly easy on a Drupal site). If your changes are not there after that, then you can run frantically to your local developer or IT department. Assure them that you did clear your cache, and this may actually be a real bug.

This blog was posted by on December 31.
Kyle Lamble

About the Author

Kyle Lamble

Kyle is your stereotypical bluehat hacker, by day, who wants you to upgrade your browser to support his love for cutting edge web development techniques. By night, he is a curator and publisher of art. Co-founder of Loosey Goosey Art, Kyle spends much of his off time helping artists find their inner potential.

A Friendlier Drupal Admin

At Sandstorm, we put a lot of care into ensuring our front end website interfaces look PERFECT. We match the designs to pixel perfection from IE8 to iOS8. But we don't stop there. I wanted to take a moment to highlight some of the unsung successes in the user administration side from the past year for our Drupal web development projects.

Drupal admins can be a little overwhelming to site administrators, so we've been flexing our muscles to pare down and improve the interface for our clients. Here are three things I thought worthy of giving you a little peek under the covers!

Slimmer Admin Menus

A standard Drupal admin menu:
Our sleek pared down menu for client admins:

 

The Editable Fields Module

We value efficiency, and when data needs to be fixed across multiple nodes we are usually able to solve such problems with things like Views Bulk Operations. But sometimes there's no way around the need to touch every node. Sometimes a human mind has to make a decision about every one of a specific content type. Sad, but true. So when that happens, the Editable Fields module is our friend.

Here's a custom Drupal Admin view that lets our content administrators quickly and easily edit multiple nodes without navigating from page to page:

 

Highly Configurable Blocks

Sometimes there is a user experience design pattern on a site that justifies something really special. The designs for CNS.org called for highly configurable blocks.

Here are some examples of the many variations of this design pattern on just one page:

And here you can see the controls used to create these variations.

Site administrators are able to edit these blocks in real-time, clicking checkboxes on the left and watch the block preview update on the right! This is a very large site, so this UX design pattern had to be flexible enough to do different jobs on hundreds of different pages.

We wanted to strike a balance between flexibility, efficiency, and consistency. This was a lot of fun, and would obviously be overkill for many situations, but when it's called for, it's very rewarding for the Drupal web developers and content admins.

One Final Tip

Sometimes it makes sense to theme Drupal's administration pages, and sometimes it just makes infinitely more business sense to use one of the default themes like Seven for the admin. One compromise we recommend is developing your own version of your favorite default theme and use that as a starting point. Don't feel like you have to brand it like the rest of the site. The Administration pages need no decoration, but it is important to use your own version so that you at least have stylesheets that you can jump in and edit where need be. This preserves the efficiency of a default theme while providing the flexibility to make customizations.

This blog was posted by on December 19, 2014.
Andrew Jarvis

About the Author

Andrew Jarvis

Andrew lives in Bucktown with his wife and three cats in various states of hairlessness. When he's not at Sandstorm doing front-end development he is passionate about creating 3D art.

this file was posted under: 
Our “Yes, and” Philosophy with Responsive Web Design Concepts

I am extremely proud of the caliber of designs our team created in 2014.

One project in particular stands out to me. The client has been really fantastic about giving us a lot of freedom with creative. Freedom is great, because it lets you try new things and really think outside the box. However, opportunity to explore always comes with a little risk. If we’re too far out of the box, will the client be disappointed?

We met to present responsive web design concepts. Embracing Sandstorm’s “Yes, and” philosophy, we had one web design concept that was polished and on strategy. The other web design concept pushed the creative.

We unveiled the first concept to a lot of head nods, but when they saw the user experience design from the second, their eyes lit up and they leaned in. The client turned to us and said “I don’t know what I expected, but I didn’t think you’d knock it out of the park, and you did.”

So this year, I’m proud to be working with a team that pushes the envelope and tries new things, and to get to work with clients who are willing to think a little differently, too.

This blog was posted by on December 18, 2014.
Kellye Blosser

About the Author

Kellye Blosser

Kellye’s unique approach involves a delicate balance of left and right-brained thinking. She most recently hailed from the corporate video world. Here at Sandstorm, she’s excited to bring strategic, innovative thinking to every project.

Andy
Engineering Custom Technical Solutions in Drupal

I really enjoy engineering technical solutions. When one of our clients told us that their Single Sign-On (SSO) vendor would not be ready for site launch, I jumped at the opportunity to help build an alternative method. Instead of authenticating users using the third party system with a contributed Drupal module, we would need to switch gears and authenticate against their existing in-house system. To do, so we developed a custom Drupal module that authenticated users, created their Drupal user account, and brought over the necessary user specific data fields.

This approach used a centralized authentication site that passes a token back to the requesting site, which is then verified for validity. Ultimately implementing this solution allowed the client’s multiple systems to share one login method and keep users logged in while navigating between them.

I particularly enjoyed solving the problem and ultimately coming to the client’s rescue. We’ve launched their site, which you can read about in Emily’s post, and have this added knowledge to help our clients in the future.

 
This blog was posted by Andy on December 16, 2014.
Andy Cullen

About the Author

Andy Cullen

Someday I'll need a real bio, but for now I'm busy creating awesomeness for our clients!

Emily Kodner
Neurosurgeons Designing Websites?

Looking back at 2014, one of my favorite website projects was cns.org, the responsive website for the Congress of Neurological Surgeons built in Drupal.

Why was it my favorite? Because they were strategic and truly embraced user-centered design.

A focus on user needs

User-centered design takes the subjectivity out of the decision-making process. We didn’t have to define user needs because we had talked to users firsthand. And, as it turns out, neurosurgeons are some of the most direct and decisive users that we’ve ever interviewed.

Because we interviewed stakeholders, we knew the organization’s priorities and were able to strike the right balance between business needs and user needs (hint: you can’t meet the first without meeting the second).

Navigation designed by users

Who better to organize the navigation than the users themselves? We asked CNS members to sort cards (each corresponding to a page on the site) into groups and create labels for the groups they made. Those labels became our navigation. Best practices can tell us how many menu items to have or how flat or deep to make the navigational structure, but only users can really tell us how to intuitively group and label pages and sections.

User tested designs

A neurosurgeon’s time is particularly hard to come by. To ensure we had adequate participation in our usability study, we took our wireframe prototype to the CNS Annual Meeting where we had a captive audience. This was a great opportunity to identify potential stumbling blocks and to allow users to weigh in on areas where there had been internal debate.

We love making great user experiences, and we are able to make the best experiences when we talk to users early and often. That’s why this was one of my favorite projects of 2014.

This blog was posted by Emily Kodner on December 11.
Emily Kodner

About the Author

Emily Kodner

Emily is our Senior Director of Client Delivery. She consults with clients, leads projects and works alongside our team of creatives and developers to provide solutions to complex business challenges.

Drupal Development: Relationships and Contextual Filters in Views 3

In Drupal, I’ve encountered a common problem: setting up a view to pull content that relates to the node the view is on at that moment. In this post I’m providing a few quick-reference guides to this Views problem.

Before we start, a few assumptions:

1) The view in question is a block display. Otherwise none of what I’m about to say will make sense, as the “View Is Here” indicator relates to what node the block display is on.

2) Your content has a Node Reference field.

3) In these examples, I describe the referenced node as a “Parent” and the node making the reference a “Child”. (This is an arbitrary distinction since the node reference field could just as easily be called “Child Node,” but this is less likely since “Parent” to “Child” is more frequently one “Parent” yielding many “Children.”)

We’ll cover the following views:

  • Pulling fields from the node it’s on
  • Pulling fields of a “Parent” node by node reference
  • Pulling fields of “Child” nodes by node reference
  • Pulling fields of “Sibling” nodes by node reference

View pulling fields from the node it’s on:

Here’s an easy one. You want a view to return information about the node the block display is on.

For example:

Let’s say we have an online grocery store. When a customer is on the product page for Oranges, we’d like a view that shows fields from that particular product. We’d like the fields to appear in the sidebar, and while this wouldn’t normally be done with Views, it’s important to do this first step to build on later.

This looks like:

What’s happened here?

This contextual filter orients the view to the page it’s on. It basically says, “Show content that has [Content: NID] values that match [Content ID from URL].”

[Content ID from URL] is another way of saying “this page’s NID”, so the only result is the current node.

Note that this can be achieved more efficiently with proper templating and modules like CCK Block.

Pulling fields of a “Parent” node by node reference:

Now, let’s say you want to pull fields from the node that the page you’re on is referencing.

For example:

The grocery store has two content types: Product (Oranges), and Food Group (Fruit). He’d like to show information about the Food Group on the Product page.

At the bottom of the Oranges page, the Nutritional Benefits of Fruit are displayed–this is not a field on the Oranges node, but it’s parent, Fruit.

This looks like:

The first step is the same, orient the view to the node you’re on. Then add a relationship to the node reference field.

You will want to use the relationship for any additional fields, otherwise they will be pulling from the node you’re on.

What’s happened here?

Like the last example, the contextual filter says “Show content that has [Content: NID] values that match [Content ID from URL]“, but by using the Relationship, we’re telling the view to look at the referenced node for this information.

Pulling fields of “Child” nodes by node reference:

This time it’s the reverse, instead of pulling information from the node the current node is referencing, we’re pulling from nodes that reference it.

For example:

When you’re on the Fruit page, we want any item that has Fruits selected as its Food Group (node reference) to be displayed.

Now, you might think this would be easily accomplished by creating several displays of the same view, filtering by content type Product, and filter those by a different Food Group content type for each display. That’s the brute force method. For five or six Food Groups it might be fine, but if your example has hundreds of possible referenced nodes, you will have to use a contextual filter.

This looks like:

What’s happened here?

Unlike the previous examples, we’re not choosing NID as the Contextual Filter; we’re choosing the Node Reference field itself. So, this time the contextual filter is saying “Show content that has [Node Reference Field] values that match [Content ID from URL],” i.e. nodes that reference this node.

Pulling fields of “Sibling” nodes by node reference:

At first glance this may seem simple. This is a behavior usually associated with Taxonomy (i.e. “related content”), and there are a lot of built-in solutions for this kind of View when working with taxonomies. What if the relationship is defined by something else, such as in our example, Node Reference? Then you need to build it from scratch.

First, you need to ask, “what is this node referencing?” then “who else references this?”

For example:

Oranges, Banana and Mango all have the Fruit node selected in the Node Reference field. So, we would like Bananas and Mangos to show up in the sidebar when you’re on the Oranges page.

This looks like:

What’s happened here?

The first relationship sends the view through the Node Reference field to the referenced node. Anything that uses this relationship will now point at the referenced node. In other words, the first relationship says “that references X,” and the second, being reversed, says “that is referenced by X”.

We still need to orient the view, this time to the node we are referencing.

All the parts come together to read: “Show content [that is referenced by] content [that references] [Content ID from URL] using the [Node Reference Field]“.

Put these Views tips to work!

These four examples should cover all the basic scenarios of pulling content that relates to the page you’re on. I expect many of you, like myself, will use this post as a quick reference for setting up complicated views in your Drupal development. I hope it gives you a better understanding of Views and make expanding the Advanced tab a little less intimidating.

This blog was posted by on September 12.
Andrew Jarvis

About the Author

Andrew Jarvis

Andrew lives in Bucktown with his wife and three cats in various states of hairlessness. When he's not at Sandstorm doing front-end development he is passionate about creating 3D art.

Responsive Web Development earns Drew and Alma a sweet treat

This morning the Sandstormers were greeted by a very welcome surprise from Sweet Sensations Bakery. This assortment of scones, cupcakes, and, my personal favorite, coffee was a thank you gift from our partner .orgSource. We recently developed their brand new responsive site (all made in Drupal). Take a look at their site on your desktop, tablet and smartphone. We’re really proud of it, and we’re glad that .orgSource is, too!

Thank you to Sherry, Tara and the rest of the .orgSource team for this thoughtful gift and the opportunity to develop your new responsive site. Congratulations!

This blog was posted by on July 10.
Will Biby

About the Author

Will Biby

Will wears many hats at Sandstorm. From writing web content to executing social media strategies, he is quick to act and insistent on a job done right. Will enjoys writing, so expect to hear from him often on the blog.

Top 7 Responsive Sites from 1996 (Yes, 1996)

1996 was a crazy time. Everyone was shouting “Show Me the Money!” or using a Fargo, ND accent. We were just meeting Kato Kaelin and teaching our friends the “Macarena”.

It was a huge year, the U.S. hosted the centennial Olympic Games in Atlanta, and Star Wars was back in theaters for the first time since its original release. And oh yeah, people started using the internet more and more. Sure it was on Mosaic and Netscape browsers, but the World Wide Web was in more households than ever. The sites were amazing by 1996 standards, and well... “interesting” by 2013 standards.

Exhibit A:

Accidentally responsive?

There is one thing that was happening that no one anticipated, many websites from ‘96 are tablet responsive. What? I thought this was a new thing that only recently started happening.

Well, it just recently started happening on purpose. Many of the sites in ye olde ‘96, were built using HTML tables — which meant that they were adjustable based on the size of the browser window. So, with a small window you would have compact content and on a larger window everything was more spread out. In effect, the site was “responsive” to your large (or small), hot, CRT monitor. (Note to our hipster friends, do not make giant, heavy monitors hip again. Thanks.)

Are we saying to build using tables? No. Not at all. It’s just fun to see how things from the past relate to modern technology.

Trends tend to repeat themselves, and a lot from 1996 has come back again. Game of Thrones was first published then and now it’s a phenomenon. Tupac (1971-1996? R.I.P.) was “revived” at Coachella last year as a “hologram.” So, building sites that are adjustable based on screen size is back, too (just for different, more portable screens).

We’re reviving a few website gems that are excellent examples of “antique responsive”. (There’s also a wealth of great examples on the Wayback Machine, too.) Enjoy.

7. VH1.com (circa 1996)

6. Beavis and Butthead Do America

5. CNN: OJ Simpson Trial

4. Dole/Kemp ‘96 Campaign

3. CNN: 1996 Year in Review

2. Space Jam

1. Lego.com  (circa 1996)

 

[Bonus: This site is not “responsive,” but it’s a great period piece of the era. 1996 Internet World Exhibition]

What will we think about sites from today in 17 years? Which will still be around?

This blog was posted by on May 30, 2013.
Will Biby

About the Author

Will Biby

Will wears many hats at Sandstorm. From writing web content to executing social media strategies, he is quick to act and insistent on a job done right. Will enjoys writing, so expect to hear from him often on the blog.

Mobiletanious responsive development on multiple devices and screen sizes.

I’d like to go on the record and claim the next catch phrase in UX and user experience design....Mobiletaneous!

Mobiletaneous is the art and discipline of building experiences for multiple screen sizes simultaneously, as opposed to starting from the mobile or desktop version. This a slight spin on the recent design trend “Mobile First” which was popularized by design guru Luke W. (Luke Wroblewski).

This is not to take anything away from the “Mobile First” philosophy. I’ve read “Mobile First”, practiced the mobile first methodology and extolled its virtues. There is no denying the expansive growth in mobile use, and the shift from desktop to mobile is indisputable. Any organization not focusing on their mobile experience is missing the boat.

Mobile First

However, as we’ve been designing and building for varying screen sizes, we’ve found it most useful to consider all screen sizes simultaneously. This applies to both the user interface design and front end development phases. It is particularly helpful when breakpoints for mobile, tablet and desktop screens are needed.

Mobiletaneous

This approach ensures designs for all screen sizes are getting the attention and consideration needed, rather than prioritizing one over the other. Because at the end of the day, the most important screen size to design for is the one your user is using.

We’ve learned this is a more efficient way to develop responsive designs. It’s no surprise it requires more time (and budget) to design and build responsive experiences, but we’ve found the mobiletaneous approach to be the most efficient.

So our interpretation of the “mobile first” philosophy is slightly different. We believe your mobile experience is crucial. So is your tablet and desktop experience. That’s why we’re on the leading edge of the mobiletaneous movement.

This blog was posted by on May 23, 2013.
Michael Hartman

About the Author

Michael Hartman

As Sandstorm's Technology and Usability Director, Michael leads our developers and usability researchers in creating web sites and applications—both desktop and mobile—that embody our favorite blend: intuitive user experience and dynamic Drupal development.

Happy New Year From Sandstorm

Sandstorm is ringing in 2013 by inviting you to collaborate for a cause. Scroll through our interactive New Year's Greeting. At the end, choose a charitable organization, and Sandstorm will give them a contribution.

We love how well parallax scrolling fits the theme of collaborating for a cause. Your participation begins before you even vote for a charity—it starts the moment you start scrolling. Your movement down the page activates snowflakes and triggers year-end greetings. So travel with us through the seasons and learn about our accomplishments in 2012. You'll be part of the experience in motion and part of the collaboration to give back. You'll even get to see a cameo from the SkiFree guy (sans the yeti).

Check out the greeting and choose a charity at the bottom!

This blog was posted by on January 11.
Karen Boehl

About the Author

Karen Boehl

Karen does a little bit of everything – webmaster, social media manager and search engine optimizer. She can most often be found on Twitter, in the Usability Lab, or happily buried in the Drupal admin menu.

THIS FILE WAS POSTED UNDER: 
this file was posted under: 

Pages