A local Oswego counseling practice gets a website

Heather Rice CounselingMy wife, who is currently in grad school studying mental health counseling, is logging practicum hours with a local practitioner. Their old site was in Wix and had terrible SEO value and wouldn’t properly display on mobile phones. To remedy this, I whipped up a WordPress theme using Bootstrap v3, and gave them a fresh new site to build their practice off of. The site features a blog, which will educate the community on topics relating to mental health. Heather Rice, who offers counseling services in Oswego, NY, now has a simple new website built on WordPress that can grow with her business.

 

SUNY Oswego’s 2014 Annual Report

2014 Annual Report

I’m super proud of what our team at work was able to accomplish in the midst of a Drupal build/migration, as well as our day-to-day tasks. The writing is top-notch and dives deep into the happenings of SUNY Oswego over the past year.

The primary designer of the project was Kelli Ariel, who had a large part in deciding how the site looked. I took the lead on the front-end development. Since I was so involved in the front-end code and design, that’s mostly what this post will be about.

What did this project take to build?

It was about a month of throwing around ideas, designing, coding and Slack conversations. Our process usually involved Kelli coming up with a quick mock-up of what certain parts of the site would look like, then she’d pass those mocks to our Slack channel, some brief discussion would ensue with our team and then I’d code it to work on the web. It worked pretty well for us and allowed us to get a lot done in a short period of time.

Design, development, and content were all intertwined throughout the project. This helped quite a bit. The primary writer, Julie Blissert was very flexible to work with. We were able to get a content structure formed in the early part of the process so design and development could go on, even though the content was still in the process of being written. For example, by structuring the content, I mean the blocks that you can hover over on the site were defined as having:

  • A headline
  • Optional subhead
  • ~325 characters of content on hover

hover-blocks

Without designers, developers, and writers working together to define things like that, a project can get unnecessarily messy.

Development tools:

  • Bower to manage libraries
  • Grunt to build, minify, and concat files to cut down on requests and file size
  • Git for version control

Libraries used:

  • jQuery
  • Waypoints
    • Used to lock in the sticky horizontal navigation
    • Used to fire an event when you hit the bottom of the page. This would then slide out the ‘next’ arrow near the footer.
  • CountUp.js
    • Used in the number panels to count up our statistics
  • Chart.js
    • Used on the Facts and Figures page to build the charts
  • Bootstrap’s grid system
  • Modernizr for feature detection

Fun features

Theme Color Cupola Card

Theme Color

With support for theme-color in the newest versions of Android, it allows web developers to customize their site’s appearance within the Android OS. For example, I was able to change Chrome’s title bar to be in line with our brand colors. I was also able to add our signature cupola icon to the ‘card’ when the user looks at all open apps.

It’s little things like this that are invisible to most users, but adds to the experience.

Sticky Header

On every page, whether you are on a mobile device or a desktop computer, the navigation will ‘stick’ to the top of the view port, allowing users easy navigation to other sections of the site. It seems particularly useful on mobile devices since it can be cumbersome to scroll all the way back to the top of a long page in order to reach the navigation again.

Scrolling Meter

Our web technical lead, Rick Buck pushed for the addition of the scrolling meter, which gives the user a subtle sense of orientation while reading the page. While scrolling down the page, a small green bar will appear under the navigation that shows how far down the page you are. When the bar reaches the end of the screen, you’re at the bottom. This can give users the ability to know where they are on the page with a quick glance.

scrollingmeter

 

 

Migrating to Drupal

At work, we’re migrating a 10,000+ page site with 300+ editors to a single Drupal installation. At first, the task is extremely daunting, but if you learn to embrace the confusion, stick with it, and plan accordingly, a task as massive as this is absolutely doable and even rewarding!

I started a “Drupal Migration” category on my blog to document our journey to the promise land in hopes that it will help others in the same situation. I’m going to be talking in ideals here, but know that it’s basically impossible to stick to these absolutely. If you make an honest effort, gains will be had, even if you don’t execute perfectly. I’m going to go over where we’re currently at in this journey.

Work hard. Don’t be an asshole. Share what you know.
Brad Frost

Define the problem

Moving to a new CMS for no reason is a great recipe for pain. You need to have clear goals if the project is going to be a success. Some people on your team will be behind the goals more than others, and that’s absolutely fine — that’s life. As long as you know what you’re working towards, you can control the parts of the project that’s within your grasp.

In our case, our main goals for migrating are to have:

  • Reusable, structured content
  • A better editing experience (we’re migrating from Ingeniux)
  • Improved content quality
  • An updated look and feel

I’ve read articles on how people + process + technology is the magical equation for a successful IT related project. It’s naive to try to solve all three on your own. Establishing who is in charge of each of these areas will make the project go much smoother. Plenty of teams complete projects without balancing these three criteria, but I bet they have a few more grey hairs afterwards. The focus of most of these posts will be on technology and process, although I’d be willing to bet I touch on people as well.

Plan it out

Let’s clear something up right away. Drupal is not like WordPress. It’s not a CMS that you can slap a theme on and instantly have a site. It’s not like Webydoo, Wix, Weebly, or any other drag and drop website builder. It’s so much more than that. It can handle anything you throw at it, but you have to have a plan and understand how it works. This takes time. If you’re 2 weeks away from a deadline and you want to jump into Drupal and whip up a complex site, you’re going to have a bad time.

Since that’s out of the way, let’s talk about planning. When you’re migrating to Drupal, you’re not just shoveling content over from your previous CMS. If that’s your plan, you’re doing it wrong! I’d assume you want to move to Drupal in order to take advantage of how Drupal handles structured content. What you’re really doing is building a data layer for your entire organization. It’s so much more than a CMS.

Drupal and content strategy go hand in hand. Being able to think abstractly about your content will ensure you get the most out of Drupal. For example, in the context of a University website, what is a department page? What does that piece of content consist of? If you want to pull information in from other areas of your site, mapping out the structure of your content is absolutely vital. Nail it down, have meetings, have arguments, just figure it out. In our base case, we decided departments consist of:

  • A featured image
  • Positioning statement
  • List of degree programs
  • List of faculty
  • Student opportunities
  • Outcomes
  • List of events
  • List of announcements
  • Contact information

Items listed in bold refer to separate pieces of content which all consist of their own pieces. For example, abstractly, a faculty member might consist of:

  • Photo head shot
  • Full name
  • Title
  • Research interests
  • Department
  • Office hours

I could go on, but I hope you see my point. If you can think abstractly about the different pieces of content on your site, Drupal can help you weave this information together into something useful. I’d highly recommend reading Palantir’s Plan or Perish blog post. They do a fantastic job of explaining the importance of planning.

Helpful resources

Dare to fail

Unless you are a Drupal expert, it is very likely that your first try will be less than ideal. Drupal is a powerful, yet complex system. Give yourself time to learn the platform. Make mistakes. Break shit. Learn what doesn’t work. Acquia has a free development tool that allows you to mess around with Drupal on your local machine before committing to a live site. It’s much better to break stuff in a development environment than in production. The more times you fail, if you learn from it, the closer you are to succeeding.

Reach out for help

Drupal has a robust community of professionals that, in my experience, have been super helpful. To avoid a RTFM response, I’d recommend playing around locally and learning the ropes before reaching out to the community. Not because they won’t try to help you, but because there’s certain concepts that you learn about Drupal only after experiencing it first hand. Drupal.org is kind of a mess, but there’s lots of very useful information there. Take the time to learn.

Once you have a decent understanding of how some popular modules work, reach out to the community for clarification of how to reach your goals. I’d recommend having a good grasp of how the following modules function before you can really benefit from the community’s help:

  • Ctools
  • Views
  • Panels
  • Context
  • Organic Groups
  • Page manager
  • Am I missing any?

As I said earlier, Drupal is complex, but learning basics about the system will reap major benefits when you go to implement your site. Also become familiar with the following Drupal concepts:

  • Entities
  • Nodes
  • Contextual arguments (within Views)
  • Relationships (within Views)
  • View modes
  • Theme layer basics

Helpful resources

I’ve recently re-discovered the treasure trove that is IRC. IRC is where a lot of community members hang out, talk about Drupal, and help people with questions. I’ve had some great success in asking questions in #drupal, #panopoly, and #drupal-support channels. I’d highly recommend downloading an IRC client for your computer – or use KiwiIRC if you want to try it out – and logging into Freenode.

Wrapping up

That’s currently where we are in the process. We’ve hammered out most of the project requirements, got our hands dirty in a Drupal development environment, thought abstractly about our content, and gotten involved in the community. You may be thinking that’s a lot of work for still not having a live production site.

I’d agree that it’s a lot of work, but I’d rather measure twice and cut once.

Using automation tools to deal with rem support in older versions of IE

We all know the wonders and joys of working with older versions of IE, namely < IE9. While I see a lot of sites are kind of throwing their hands up in the air when it comes to legacy IE support, I think its necessary to at least make sure your content is accessible. It’s a little irresponsible to throw up a message saying “Sorry, your browser is old. Download Google Chrome”. At the very least, you could serve them a print style sheet so they could read the content. While IE8 is dying a slow death, it still has a good amount of users.

I’ve been using rems in conjunction with ems now to give myself a consistent spacing unit when coding a website. As with all handy CSS properties, IE8 doesn’t support it so we have to look elsewhere. You could either a) Write pixel fallbacks before each time you use a rem.

h1 {
  font-size: 48px; /* for < IE8 */
  font-size: 3rem; /* for newer browsers */
}

IE will ignore the rem part but will pick up on the

font-size: 48px;

If this works for you that’s fine, but I’d rather have a script automate this process. That’s where grunt and rem_to_px comes in handy. My current grunt task is set up like so:

rem_to_px: {
  options: {
    baseFontSize: 16,
    removeFontFace: true,
  },
  dist: {
    src: ['source/css/style.css'],
    dest: 'public/css/ie/'
  }
},

The task will create a stylesheet where I told it do in

dest

that is the same filename as what is declared in

src

. This stylesheet will only contain rem to pixel substitutions. Then, in my HTML it’s simple to drop in a conditional statement to check if the browser is less than IE8. If so, I’ll include the stylesheet created by the grunt plugin.

<!-- link to the normal style sheet -->
<link rel="stylesheet" href="public/css/style.css">

<!--[if lte IE 8]>
<link rel="stylesheet" href="public/css/ie/style.css">
<!--[endif]>

Think systems, not pages

People are used to thinking about the web in terms pages. Most modern CMSes can make pages, but if you’re using them properly what you’re actually creating is a system of interconnected content. That’s a whole lot more awesome than pages. That’s the difference between creating structured content vs. having unstructured pages. Structured content allows you to:

  • Filter or sort only the content you need
  • Syndicate content across a site
  • Have more control over the markup/style of the content
  • Create consistency for all pieces of a particular content type (e.g. events, announcements)

Structured content has many pros, but it takes a little while to get used to this paradigm. People used to editing pages might not be used to thinking in terms of systems. This is a pretty minor problem because once the power of structured content is seen, most people understand the value in it. At work, we’re shifting from a model of pages to structured content because of a CMS switch to Drupal.

A paradigm shift is needed to really utilize and harness the full potential of a CMS like Drupal. What makes Drupal special is the ability to easily create structured content. Oswego’s current CMS allows you to create unstructured pages. This means that all content is dumped into 1 area, which has many limitations. Some of which include:

  • The system isn’t aware of a “type” of content, because everything is a page
  • Unable to filter/sort content
  • Markup and data is intertwined and not easily teased apart

This presents a problem if you want to sort all your event pages or list faculty members by department. If your events and faculty profiles exist as pages and not as structured content, these types of things are not easily possible. As an example of what can be done with structured content, watch this video for a few minutes starting from 11:00 in. I would recommend watching the entire video because it really hammers home how to think in systems.

Structured content can help an organization do all sorts of neat things like sorting and filtering while unstructured pages lock the content in so it can only exist within the page it was created in. Structured content can be displayed on any number of pages and any number of styles. It can also be updated once and changes can be seen everywhere that content is referenced. This can save so much time and effort if you’re duplicating content the old fashioned way (copy & paste).

Thinking in systems is initially more difficult because it involves more planning. Once the system is built, it will provide a lot less work to users who are tasked with editing their content.

Think of this example use case that happens daily. A department wants to make an event. So they create a new page for the event, and use the WYSIWYG (what you see is what you get) editor to paste in their content from a Word document. The user enters a photo for the image, a start date and an end date. Life is good now because there’s a page for the event. Now the user needs to add a link on their home page to this event. So the user checks their home page out of the CMS and adds a link to this upcoming event. This event should also be listed on the “Events” page within the department, so the user checks that page out and adds a link to the event.

If that wasn’t enough work, the user’s boss came and said “Hey, we switched the name of this event from XYZ Event to ABC Event, update the website for me.” That’s a legitimate request, making sure content is up to date and relevant should be high on anyone’s list of priorities. After the boss’ request, the poor user now must check out 3 pages and change the title of the event in 3 different pages (event page, home page, event listing page). This is a huge waste of time and it doesn’t have to be like this.

There is a better way

Luckily, if you think in systems, not pages, then this type of scenario will be a thing of the past. In a system, you have structured content that you can filter and query. With pages, you have disparate files that have no relationship between each other. Wouldn’t it be nice to update the event title in one place and have that propagate to all places where that event is listed? With proper planning this is absolutely doable and will save lots of time and headaches.

Drupal will allow us to do things like this and much more, but proper planning is required. With proper planning, you can utilize Drupal to be so much more than a CMS. What you’re really creating is a data layer for the organization. In the back end, you’ll have all your announcements within structured content types. Same with faculty profiles, events, student testimonials, etc. No longer are the just a page. Within this paradigm lies a whole new world of possibilities for organizations and I can’t wait to see where it brings us at Oswego.

Drupal 7 – Creating a template suggestion for a node’s view mode

After watching this video, the relationship between nodes, views, and view modes really started clicking for me. I decided to try and provide template suggestions for all my node types and their view modes. This simple code in template.php did the trick.

function THEME_preprocess_node(&$variables, $hook) {
  $variables['theme_hook_suggestions'][] = 'node__' . $variables['type'] . '__' . $variables['view_mode'];
}

Obviously you’ll want to replace THEME with your theme’s machine name. What this does, for every node type is create a template suggestion. So if there was a node type / content type for Programs in a typical University website and you created an “illustrated_list” view type to display programs in a list, a template suggestion called node__program__illustrated_list would be automatically created for you. Creating a file called node--program--illustrated-list.tpl.php would allow you to create the custom styling every time that view mode is used on that node. Wonderful!

Relevant StackExchange thread

Thoughts on my 2014

2014 has come to an end and it’s time to look ahead to 2015. 2014 was my first full year in a professional environment. I wrote my first jQuery plugin. This was also the year I really sunk my teeth into CSS preprocessors, automation, and version control to supplement my front end development.

Working for a full year doing web development has been a great experience. I used to think the hardest thing in programming was what to name your variables, but it turns out that – for me – it’s communicating your ideas. Because of this this, I want to blog more in 2015. I think it’ll help me understand my thoughts a little more. The ability to communicate technical ideas clearly to a non-technical audience is a skill I need to sharpen.

I dove into jQuery a little more thanks to videos by Paul Irish. This knowledge allowed me to write my first jQuery plugin. It’s nothing super amazing or technical, but it was a neat exercise in learning something new. Looking at example code of jQuery plugins made me feel uncomfortable at first, but as I stuck with it and kept reading, it started to gel together enough for me to write something that works.

This is the year I started using LESS as my CSS preprocessor of choice. I keep reading a lot about Sass, but haven’t tried it out yet because LESS does everything I need. LESS solves many problems I was tired of dealing with while writing plain CSS – namely lack of variables and mixins. The idea of compiling a few .LESS files into 1 CSS file seemed to make more organizational sense to me, so I never looked back.

Another addition to my workflow in 2014 was embracing front end tooling. I used to have no issue importing 9 non-minified .js files in the footer of a site. I used to FTP all my files manually every time they were updated. I used to download external libraries by just going to the library’s website, downloading the zip, then extracting it to my project. Now, I use grunt tasks to concatenate and minify my scripts and CSS. I use rsync to transfer my project to staging or production servers. I use bower to manage my site’s dependencies, allowing me to quickly download and update external libraries. These things used to seem advanced and scary to learn, but since I’ve gotten to know these tools, I can’t imagine working without them.

Finally, 2014 was the year I started using version control. Git tutorials and YouTube videos really helped me understand how important it is to a developer’s workflow, how it works, and how to use this powerful tool to manage your projects. Gone is the fear that something irreversible will happen to my project. I can rest assured knowing each version is backed up on my local repo and in the hosted repo (I like using BitBucket).

TL;DR – My workflow changed a lot for the better in 2014, and I got the chance to learn more about jQuery plugins (and as a side effect I now understand JavaScript and jQuery better). Looking forward to 2015, I hope to learn as much or more.

To Bootstrap, or not to Bootstrap?

Front end frameworks are great time savers for getting your project up and running quickly, but is the time you save setting up the project wasted when it comes to customizing the design?

At a conference earlier this year, I got the opportunity to meet Brad Frost, which was super awesome. I told him at the time I used Bootstrap in my front end development and he said something that got me thinking. He said that in his experience, front end frameworks (like Bootstrap, Foundation, etc) get you about 80% of the way, then you spend the last 20% fighting them while you customize it to not look like Bootstrap.

I could certainly relate to this. Where I work, there’s usually a designer on projects who drives what the website will look like. Very very often, the designer would come up with a very doable design, but it couldn’t be replicated in Bootstrap without heavy customization. I could get a quick prototype up, but it would take a considerable amount of customization before it was production ready in the eyes of the designer. By the time we were done, very little of Bootstrap’s styles were even visible, but they were still there in the code.

I saw this and it made me think about what Brad said. I was essentially using Bootstrap as a base, then customizing it so much that you couldn’t really tell it was Bootstrap. I might as well be writing it my way from the start, instead of hacking Bootstrap’s styles. So instead of hacking Bootstrap’s styles, I started compiling my own stylesheet only using the Bootstrap LESS files I need. Now, there is less of me fighting with Bootstrap and overriding styles. I only use their utility classes, vendor prefixes, grid, and scaffolding LESS files now and it gives me the quick start I want when doing a project, but allows for massive customizations without fighting against Bootstrap’s styles.

This is currently working pretty nicely for me. I could see myself in the future having my own grid system, mixins, etc that I take with my from project to project, but right now the Bootstrap ones are working great.

Walls Come Tumbling Down – Rethinking Workflow

Original Transcript

Worse still are the expectations that static visuals set in the minds of clients, particularly when designers use them as a method to get sign-off for a design. I often wonder, is the fact that so many web pages are fixed-width and centered, a direct result of clients signing off fixed-width design visuals?

I would even go so far and say that when you demonstrate a design as a static image, you are reinforcing a mistaken notion that a web page will be a facsimile of a frozen image. And when you demonstrate a design or ask for sign-off on a frozen image, you immediately leave yourself open to the problems that often come when you later implement that design.

We all know that it is impossible today for a design to render exactly the same in every browser or device.

You need only look at the different ways that Gecko and Webkit and Opera anti-alias text. The browser landscape is more diverse today than it ever has been before.

I know that many designers and developers understand that it’s neither practical, economical or desirable to attempt cross-browser pixel perfection, but what about the clients and managers that we work for? They still often subscribe to the outdated notion that you should strive for pixel perfection.