Front-end developer ramblings ☕️ 🍕 😀
Happy New Year to all my family, friends, acquaintances, co-workers, people I have done business with (and anyone else not covered by those categories).
May your 2018 be filled with not only the completion of personal and professional goals, but with contentment with who you are and where you are in this life.
2017 marked the first year in our new home. We got it (mostly) decorated and have loved having guests over to enjoy some dinner, games and conversation.
This post is one of my favorites to write every year because it allows me to look back on the year and evaluate what I’ve learned and determine where I’ve made progress.
This is the year that I spent a lot of time reading and working on a design system. I’ve spent a bit of time thinking about the challenges in implementing and maintaining a design system, and even wrote a few blog posts about design systems.
Jeremy Keith linked to one of my blog posts, calling out my Venn diagram as similar to how he thinks about how design system, pattern libraries, and style guides all fit together. This simple thing was a huge boost to my confidence as it sent a signal to me that I’m thinking about these things the right way.
I feel as if we made significant progress in our organization to implement a system of components. However, an unseen (yet ultimately positive) circumstance arose that temporarily halted progress on the design system, which was an accessibility complaint.
After this holiday vacation, one of my top priorities is going to be completing a design system that we can build on for years to come.
I crammed so much accessibility knowledge into my head this year because of a complaint we had filed against us by OCR (Office of Civil Rights), which claimed that our website was inaccessible.
While the situation was at times stressful, in hindsight I view it as an incredibly positive experience for a lot of reasons:
As part of our organization’s commitment to accessibility, I was sent to WebAIM training in beautiful Logan, Utah. The training was highly valuable as it clarified a lot of the misconceptions I had about accessibility and solidified my understanding of when to use ARIA attributes vs HTML5 elements when it comes to accessible markup.
While working on design systems, I’ve experimented with a lot of templating languages. These are a delight to use because they fit in perfectly with component based design and allow for rapid front-end prototyping. Throughout the year I stumbled on 3 different templating languages that I got the opportunity to play with.
Pug — Thanks to CodePen, I’ve learned how Pug templating works. CodePen’s new Projects feature is an amazing tool to use when prototyping.
Twig — At work, the current version of our pattern library is in PatternLab which uses Twig to template components. This has allowed me to learn the ins and outs of Twig and get up to speed with it quickly. It is such a good fit because as our organization eyes moving to Drupal 8, learning Twig will prove to be a good investment of time.
Handlebars — I use Assemble.io to build certain custom designed, special projects which use Handlebars to template out partials and layouts.
This isn’t a technical achievement, but it’s note-worthy nonetheless. While sometimes I wish I could focus on the tech part of my job 100% of the time, it is necessary to be competent in writing and communicating in order to be truly effective and successful in your career.
This year marked the first time I’ve taken a serious look into governance policies, which our organization sorely needs. I like to think I helped get the ball rolling on that initiative by creating some drafts of policy documents that I shared with my superiors who see the policies as a necessity are now using their status to get buy-in and carry the project across the finish line.
I’ve made some previous posts about design systems, which are all the rage in 2017. We are still working through the creation of one at my organization. One of the core parts of design systems are principles.
These principles ideally shape the future of design for an organization. The most important thing that I keep coming back to when thinking about how to create interfaces is to be inclusive.
This is the most important design principle you can have as an organization. Convincing people that it is important can take a lot of work and often times you will be fighting an existing culture that says “If it works on my computer then its good.” A lot of people don’t stop to consider all the other ways people can be accessing their site/content.
If your creative team is well versed in inclusive design principles, then it’s easy: Hand over design authority to your creative team. Are you reaching as many people as you can? If your superiors look at your creative team as tools that will do what they say and create what they want then it is incredibly difficult to design inclusively.
The problem with this approach is that often times the stakeholders who are “driving the bus” so to speak, are not well versed in performance, accessibility, and usability — all three of these areas are vital to being inclusive.
It’s nice that the site works on your high speed, wired internet connection, but how does it perform with spotty WiFi or on 3G speeds? Are you able to access the site in these situations?
I think this is what a lot of people think of when talking about being inclusive. Is your site designed and developed in a way that takes into account WCAG 2.0 (the de-facto standard for accessibility guidelines)? Complying with these guidelines helps everyone, not just those with disabilities. Microsoft has done a phenomenal job at explaining that disabilities are not personal health conditions, but rather mismatched human interactions.
Usability is closely related to performance and accessibility. If the site isn’t performant and accessible then it isn’t usable. On top of that, ensure your site is following agreed upon UI patterns to ensure a consistent experience across your site.
This is not a complete or exhaustive list by any means but it seems to me that keeping these three areas in mind will go a long way in ensuring that your site is inclusive.
In one of our sites, we post email communications that were sent out as all-campus announcements on our website.
The problem is, our basic web template does not look like an email template.
So I thought, “I wonder if I could just load a separate set of tpl.php files based on the content type.” Spoiler alert: I could.
I wanted a solution that didn’t require hacking my original theme. I wanted to leave the current theme untouched and simply provide new html.tpl.php and page.tpl.php for this specific content type (presidential_email).
This step is technically optional. If you don’t have a local or dev environment then you don’t need to package your content type in a feature. But for those of us who have to push code through dev -> stg -> prod, features is the best route so you don’t have to rebuild the content type on each environment.
Create your content type in your local environment. Add fields to your liking. Now export that content type using Features.
I typically use the “Generate Feature” functionality under Advanced Options, but you can do whatever you want. Generate Feature allows me to write the code directly where I want to. In this case, it was sites/all/modules/custom.
Go to your sites/all/modules/custom directory and you should see a folder in the path you specified with your content type exported into a Features module.
Add your hooks to your modulename.module file to really get cookin’!
hook_theme
In your hook_theme implementation, you want to specify the new tpl files you want to use. In my case, I want this module to override html.tpl.php and page.tpl.php for the presidential_email content type.
/**
* Implements hook_theme().
*/
function presidential_email_theme($existing, $type, $theme, $path) {
$theme = array();
$theme['html__presidential_email'] = array(
'render element' => 'content',
'base hook' => 'node',
'template' => 'html--presidential-email',
'path' => drupal_get_path('module', 'presidential_email') . '/templates',
);
$theme['page__presidential_email'] = array(
'render element' => 'content',
'base hook' => 'node',
'template' => 'page--presidential-email',
'path' => drupal_get_path('module', 'presidential_email') . '/templates',
);
return $theme;
}
Create your templates folder and files
In your created module folder, add a templates folder. The above functions are telling Drupal to look in yourmodule/templates for html–presidential-email.tpl.php and page–presidential-email.tpl.php.
hook_css_alter
Depending on your use case, this could be optional. In my case, I didn’t want ANY of the typical CSS to be loaded because I wanted to use inline styles created by the MailChimp template. To achieve this, my hook_css_alter looked something like this:
/**
* Implements hook_css_alter().
*/
function presidential_email_css_alter(&$css) {
$node = menu_get_object();
if ($node && $node->type == 'presidential_email' ) {
foreach ($css as $k => $v) {
if (!strpos($k, "navbar")) {
unset($css[$k]);
}
}
}
}
Essentially, this code checks to see if the current node is a ‘presidential_email’ and then loops through all the CSS files, unsetting them all unless it’s necessary for the navbar (I still want it to look presentable while logged in).
Last but certainly not least, this method only works if you have auto-generated template suggestions based on node type. For instance, consider my template_preprocess_html and template_preprocess_page functions (replace template with your theme name).
You could also put these in your .module file changing ‘template’ in the function name to your module name.
/**
* Implements template_preprocess_html().
*/
function template_preprocess_html(&$vars) {
$node = menu_get_object();
if ($node && $node->nid) {
$vars['theme_hook_suggestions'][] = 'html__' . $node->type;
}
}
/**
* Implements template_preprocess_page().
*/
function template_preprocess_page(&$variables) {
if (isset($variables['node']->type)) {
$nodetype = $variables['node']->type;
$variables['theme_hook_suggestions'][] = 'page__' . $nodetype;
}
}
I wrote these at different times in my Drupal career but they do the trick. A content type of “presidential_email” will now produce template suggestions for html–presidential-email.tpl.php and page–presidential-email.tpl.php.
With this in place, the module will now load templates in the module’s template folder when the presidential_email content type is being displayed. Worked well for my simple use case!
Here are some tools and methods for running an accessibility audit on your site. This can be a little bit easier if you already have a design system or component library in place, but it isn’t necessary to gain some insights into how your site can be more accessible.
The way I usually do it is I first run some automated accessibility checkers, then I do some manual testing. I’ll unpack what this means below.
Note: most of this information is a summary of the W3C’s WCAG site, which is the authority on recommendations regarding web content accessibility. The content on that site can be a little dense so hopefully this provides a good summary and jumping off points.
One thing that is important to remember when using automated tools is that they are not perfect. Just because your site “passes” an automated check doesn’t mean that it is accessible. Also if your site has errors, that doesn’t necessarily mean that it is inaccessible.
Web accessibility evaluation tools can not determine the accessibility of Web sites; they can only assist in doing so.
–Source
That being said, it is still quite valuable to run automated checkers on your sites because they can assist in catching errors before manual testing takes place.
One of the more popular automated checkers is WAVE by WebAim. This site allows you to enter a URL and then get a live preview of your site with highlighted accessibility issues in there. It certainly isn’t perfect because it can report some false positives, but it’s a great way to catch obvious issues and contrast errors.
Here is where the “real” accessibility testing comes in. I say “real” because these methods are actually emulating how users with disabilities actually use your site. Manual testing also can help find gaps in your automated testing.
A basic principle of WCAG 2.0 recommendations is that your site should be operable using nothing more than a keyboard. Give it a shot. Run through your site using your keyboard by pressing tab. Many users with limited motor control rely on keyboard navigation to navigate web sites.
Reading up on the tabindex attribute can provide enough know-how to make your site way more accessible.
I’m on a Mac so it was quite eye-opening for me to browse sites using the built in Voiceover functionality that comes with all Macs. Using Voiceover shed some light on accessibility principles that I never really understood properly.
For example, we all know the basic rule-of-thumb that alt text is good to use on images. But when using Voiceover, alt text can actually hinder understanding of certain elements such as images with text over them.
Consider this simple image block:
This image block has alt text of “Student at computer,” which most accessibility novices would assume is a good thing. However, Voiceover reads this element as “Link, Online MBA ranks highest in state student at computer.” This is less than ideal because it is actually less meaningful than if it had alt=””. In situations like this, screen readers tack on alt text to the text that is in the element. By using alt=”” in these situations you can be sure that screen readers will obtain the true meaning of the element.
This is a great example of something that can only be caught using manual testing.
This was a very brief overview of some tools, resources, and techniques to test your site against WCAG 2.0 accessibility recommendations.
To take it to the next level, there is no substitute for reading the WCAG 2.0 site and browsing through the quick reference provided by the W3C on how to meet the recommendations.
Happy auditing!
SUNY Oswego recently switched from a legacy install of Expression Engine to integrating with the rest of our web platform and using Drupal hosted by Acquia to “re-design” our new News site. Hopefully this post will help others thinking of migrating to Drupal and provide some helpful tips if you’re already in the process of doing so.
Even though our old news site was in Expression Engine, the power of it being a PHP/MySQL app wasn’t fully utilized.
Now, this is through no fault of our office, it just hasn’t been looked at in a very long time. The old site worked well enough for what we needed so we left it alone until an opportunity presented itself to give it a little update.
As a result, the homepage was consistently static. Photos and images were dumped into one WYSIWYG text blob which meant it was difficult to display teaser photos or do anything that is possible with structured content.
Photo captions were placed at the bottom of the articles, separated from their photos. Tagging had no specific function other than creating a word cloud that kinda looked cool. Categories weren’t maintained and difficult to browse by. Finding a list of just all news ordered by date was a hard task to complete.
In order to move forward and utilize Drupal to the fullest extent, we planned out content types, audited our workflow, and looked for areas that could be improved as we moved into Drupal.
First we sat down and looked at what kind of content was being created. We had a few different content types that were regularly published. News story, People in action, and Spotlight. All of this content was published using one content type and tags to differentiate them in the system.
For the new news site, we now have the same three as before, plus a new Media mention content type. I separated each piece of content into different content types. This allows us to style the content differently and add different fields depending on what the content type needs. The content types are:
When we looked at our analytics of the old site, it wasn’t surprising to find that a large portion of our traffic was when something was shared to Facebook or Twitter. This made the decision easy to invest some resources into:
The Drupal metatag module was a YUGE help in making sure that our teasers looked good when shared on social media. If you’re using Drupal, this module is a no brainer.
Another must-have module is the Google news sitemap module. This ensures your articles and content are in a format that is easily consumable by Google. This allows our news stories to be indexed by Google news.
Last but certainly not least, massive improvements were made to the editorial experience. Drupal gives a site maintainer/developer a tremendous amount of control over the editorial experience, which I tried to leverage as much as possible to make the site easy to update and maintain.
I’ve referenced this technique in another post and I can’t recommend it enough for improving the editorial experience. By cloning some administration views, we gave editors a super easy way to look at all content of a certain type. This helps reduce cognitive load, making editors more efficient.
I can’t tell you how many times I’ve logged into Drupal with a task in mind, and by the time I figure out which admin area I need to go to, I’ve forgotten what I was doing. Small shortcuts like this technique can reduce these errors and make people’s lives a little better.
One of the tasks that our news team needs to do is to switch out our featured story once or twice a week, depending on what is happening on campus. I tried to make this as painless as possible, understanding that our writers are not web people. They’re writers. They shouldn’t need to be a web genius to change the featured news story.
Using a combination of views and nodequeue, I added a column to the “News Stories” content tab that allows our senior editor to simply click a link to make that story the featured story on the home page.
For each of the different types of content, guidelines were developed to ensure that the content would look great once no matter where it is syndicated or in what context it is used.
To help editors know what character count they are at for the summary, I wrote a small module that counts characters for the summary field. As you can see from the screen shot, even the greatest technical solution is at the whim of people and process.
A major feature of this news site is now the ability to syndicate news stories from the news site to academic department and college sites through the use of tags and AJAX.
We worked on a list of tags for editors to use that would allow them to syndicate a piece of content to a particular site based on what it was tagged. When implementing, I ensured the field had auto-complete in the add/edit form so we could reduce the number of slightly duplicate tags (for example, Physics department / Physics Department).
As with any technology-related project, there are three components that lead to a successful product. People, process, and technology. People and process are vital, and also the most variable.
Sitting down with people to talk about their process is incredibly helpful when building the technical solutions. Often times when the technical team sits down to discuss process, the people who are closest to the process can’t really nail down what it is. That’s where it’s our job to ask questions and try to figure out how things work. This is absolutely necessary if we’re going to turn around a specific, concrete system that the process fits in.
It’s certainly a challenge and it’s never going to be perfect. People change and processes change. Good communication and trust between teams is the only way to get as close to the ideal as we can.
For this iteration, I think we did a really good job. The site is leaps and bounds better in regards to surfacing the latest goings-on at SUNY Oswego. Also, the editor experience is much better as pointed out by our writers who actually use the system (win!).
As a front-end developer at a University, I can see first hand why design systems can be such an integral part of an organization’s communication (and marketing) strategy. This post aims to explain the reasons why large organizations, including higher education, can benefit from having a robust design system in place.
At the University I work at, there are talented designers spread all over campus working for various departments. The offices and departments that are fortunate enough to have a designer working for them utilize their designer’s talents to make flyers, PDFs, and web sites. These designers all have their own style, their own tone, and their own voice. Certain departments use Arial and Helvetica for their typography on print pieces while other departments use Whitney and Sentinel.
It doesn’t take a branding expert to see why this is problematic. All parts of the communications and marketing stakeholders need to be rowing in the same direction in regards to branding.
For most other offices and departments, there are no designers on staff. This means that someone who isn’t necessarily trained in web or design is now responsible for the office’s web site or flyer design. Often times there aren’t enough tools available for this person to create a nice web site and what ends up happening in some cases is that it becomes easier to create a Word document or InDesign file and put a link to that on their site. Or content is simply copied on to the website from a Word document.
I don’t blame offices and departments around campus for doing the best they can with the limited resources they have, but there’s got to be a better way…
It’s often easier to blame your web editors or departments for being difficult to work with or not technically capable. In higher ed, we seem to think we’re a little special. We think we have such a unique situation that no industry solutions could possibly work. Often times this leads to a web team trying to support all their institution’s web sites and all the sites look a little different and are structured a little differently. This leads to an apathetic web team who is constantly putting out fires.
To be fair, I can understand the apathy because it can seem like a dauntingly huge problem to solve. However, this doesn’t seem like a sustainable solution for the long term. There needs to be a process, a plan, in place that allows for quickly building a branded website within the organization. It needs to be so easy that an intern, administrative assistant, or anyone really whose job isn’t web. If it doesn’t work for them, the website will fail because these are the people who are updating the website.
What if there was a way to empower existing designers in the college to all be on the same page? What if we provided tools to web editors in departments that don’t have a lot of technical literacy to make their jobs as easy as possible?
The first step to answering this question is to get your ducks in a row and build a design system.
This is what we’re attempting to discover at work and it’s a pretty fun process! To learn more about what a design system actually is, check out my post on the matter.
After a design system is in place, developers can integrate components into whatever CMS you’re using. If the developers are any good, they can also help craft editorial experiences that empowers non-technical users to create on-brand components using your CMS.
In my organization, we’re trying to implement an integrated marketing plan which will be helped along greatly by a sound design system. In order to implement this properly, a shared vocabulary needed to be created so we could be sure we were referring to the same thing. In this post I do my best to explain the terms style guides (editorial and visual), pattern libraries, and design systems.
A design system forces your organization to think about people and process before a technology solution is introduced.
I think there is a lot of confusion over what exactly a design system is. In my handy Venn diagram, I’ve included what I think a design system consists of. Note that the size of the circles don’t correspond to importance.
Principles are your organization’s foundational ideas that your editorial style guide, visual style guide, and pattern library will live by. These are the ideas that ideally should be running through your organization and be expressed in the style guides and pattern library.
For our design system, I’ve taken this area a bit further and aim to include our main governance policies for our most strategic sites and marketing assets. Most of the principles will be abstract concepts, but some specificity certainly can’t hurt and can provide the organization with a public facing place to review web policies. This is especially important for large, decentralized organizations.
Editorial style guide is exactly what it sounds like. It’s the preferred editorial style for web writing. Including things like whether to use AM/PM or a.m./p.m. when referring to time as well as agreed upon vocabulary for the institution make an editorial style guide useful. If some sites are using “dorms” and some sites are using “residence halls” to describe on-campus housing, a standard should be picked and added to the editorial style guide. Overall voice and tone is also an important piece of an editorial style guide.
Visual style guide is what most designers would call a “branding guide” back in the day. Well crafted branding guides would typically include some editorial guidelines, including voice and tone, whereas a visual style guide only focuses on the core visual pieces of an institution. Items like logo usage, colors, color combinations, typography, and spacing are pillars of a visual style guide. These are the areas of the brand that won’t often change and should be referred to often. To use Brad Frost’s analogy of the store front/workshop, this is the store front. The pattern library is the workshop.
Pattern library is where all the components that are available live. Ideally these patterns are created using the core tenets of the visual style guide such as proper spacing, typography, and colors. A pattern library is far more dynamic than the visual style guide. The web is never finished, new needs are always being created, and therefore new patterns may need to be created to serve those needs. Pattern libraries are where designers can go for inspiration and download code samples. Pattern libraries are where the rubber meets the road in your design system.
You may notice in my Venn diagram above, that I have the visual and editorial style guides overlapping with the pattern library. It is because it’s impossible to completely separate patterns from visual style and editorial style.
Your pattern library is a place where stakeholders can see the fruits of the design system in action. If there are strong editorial and visual guidelines, a pattern library can really shine and stakeholders can see components that can be used across the organization that comply with the brand.
My wife and I just got a new puppy and are crate training him. We’d love to know how he’s doing if we’re not there so I decided to look into some DIY pet-cam solutions. Using the IP webcam app for Android and Ivideon cloud streaming service, I was quickly able to get up and running with a perfect solution that allows me to check up on my pet when I’m not there.
What you’ll need
Make an Ivideon account. Head over to ivideon.com and sign up. Follow the steps to create your account.
Download the IP webcam app to your phone. Open the app and find “Connection Settings” > Cloud streaming.
It should say “INACTIVE” at the beginning (see above). Tap this and then tap “Ivideon account” to connect to Ivideon.
After you connect to your Ivideon account, the app will present you with a message that it was successful. You may think that you’re done, but you’re not! There’s one more important step.
The final step is to enable the server on the IP webcam app which will start broadcasting your stream to Ivideon. Scroll all the way to the bottom to find this.
Once your server has started, you can login to your Ivideon account and see your camera!
Protip: Turn off your screen to prevent hard core battery drain.
Go to invideon.com/my and select your camera. Now you can watch your stream!
I never thought this would be something I’d be writing about but it’s actually super exciting. This has been a major bane when trying to dev on my Windows machines. A lot of developer tools installation instructions walk you through some terminal commands, then the Windows people are all commenting at the bottom trying to figure out what additional steps need to be taken to make it work on Windows. This is crazy, and I’m glad Microsoft recognized this was a problem and included a bash prompt on Windows 10.
When I first installed it and launched it, I didn’t quite get it. I was in a ~ home directory but it wasn’t my Windows home directory which I kind of expected. I was in the home directory of this Ubuntu VM that has been booted to provide a bash prompt. I searched around and found that if you want to access your Windows home folder through the bash prompt, you’d have to:
cd /mnt/C/Users/<USER NAME>
Ok, now I can do an ll command there and see all my files, just as I’m used to when working with Linux and Macs. Pretty exciting!
Now, I don’t want to cd to my Windows home every time I login. To get around this, I edited my .bashrc file with an alias. The .bashrc file is in the home (~) folder of the Ubuntu VM.
alias home='cd /mnt/C/Users/jfitz/Workspace' home
This sets an alias for home so anytime I want to go back to this directory I can just type “home”. It also executes so that when bash starts up I’m already in my Windows home directory.
I tried to install create-react-app via npm and got the following error.
npm ERR! Linux 3.4.0+
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install" "-g" "create-react-app"
npm ERR! node v7.4.0
npm ERR! npm v4.0.5
npm ERR! path /usr/lib/node_modules
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall access
npm ERR! Error: EACCES: permission denied, access '/usr/lib/node_modules'
npm ERR! { Error: EACCES: permission denied, access '/usr/lib/node_modules'
npm ERR! errno: -13,
npm ERR! code: 'EACCES',
npm ERR! syscall: 'access',
npm ERR! path: '/usr/lib/node_modules' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.
Turns out, this is a permissions issue that can be easily rectified.
sudo chown -R $(whoami) ~/.npm sudo chown -R $(whoami) /usr/lib/node_modules sudo chown -R $(whoami) /usr/bin
It would be absolutely bonkers if you could launch Windows apps from the bash terminal. So say I’m in my Workspace folder, I’d be able to open up Sublime text or PHP Storm from the bash terminal. I looked into this situation and there is an issue thread on Github. This comment is pretty promising:
The project definitely has its issues, but its very promising to see Microsoft trying to make this work. I think we’re another year or two off from having a super solid *nix development environment in Windows.