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.
Working with node and npm
I tried to install create-react-app via npm and got the following error.
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.
I’m familiar with the concepts of REST but have never done anything in practice before. I decided I wanted to end that and start messing with the JSON API in Drupal 8. It was surprisingly easy to get going with because of the incredible resources out there. In this multi-part series, I’m going to explore how to use Drupal 8 as a data back-end for a React app.
JSON API Drupal Playlist by Mateu Aguiló Bosch
This video series is an excellent job of succinctly explaining how the JSON API can be used to make basic requests to Drupal.
Postman is amazing
In the series, Mateu is using a tool called Postman (free!), that makes managing REST requests really easy. This is amazing for testing out your API before you hook it up to an application.
Using Postman, for requests that require authentication, you can set up basic authentication (which uses your Drupal username and password) for easy testing purposes.
The examples below were all run with Postman. I decided it would most likely be useful to someone if I showed how I POSTed data to a content type using the JSON API.
Potential gotcha
Make sure in your request headers, you are specifying the Content-Type as application/vnd.api+json. This is according to the JSONAPI spec. Not doing so will throw a 422 Response from the server.
My app use case
I’m building a workout routine React application. The main idea is that users have Routines which contain Timed Tasks (could be yoga postures, jumping jacks, whatever). The Routines hold references to the Timed Tasks. The user can create a Routine of Timed Tasks, and then “play” through the routine, which will prompt the user to perform a workout action.
Timed Task content type
Title
Body
Task Setup
Minutes
Seconds
Task Duration
Minutes
Seconds
Task Rest
Minutes
Seconds
Routine content type
Title
Body
Timed Task entity reference
Now, lets use Postman to test some basic REST calls that I’m sure my React app will have to make.
Examples:
Local site url: http://drupal-8-3-0.dd:8083
Adding TimedTask content
POST -> http://drupal-8-3-0.dd:8083/jsonapi/node/timed_task
The core of the TimedTask is structured nicely for me to use in a front end framework like React.
Now, I want to be able to store a collection of these TimedTasks in a collection known as a Routine. A Routine will consist of many TimedTasks that can be rearranged.
I added 3 more Timed Tasks and noted their UUIDs in the response.
ad4a8609-1b98-436c-9efd-fc9fe91ad908
390de987-11b2-47b4-a692-3c160bccab0a
760a6c82-b0f1-4b2a-93d4-140061e878a9
6548f256-a518-491a-8bba-d469778a3722
Now, lets add these as entity references to a Routine content type.
POST -> http://drupal-8-3-0.dd:8083/jsonapi/node/routine
Using Postman, I helped validate the basic API structure that my React app will use. Next, I’m going to look into how we can hook this up into a React application.
Vimeo by far provides the best hosted video embed service out there by far, in my opinion. This post explains how to change the behavior of a Vimeo embed to skip to a given timestamp when the user plays the video. We’ll use data attributes to store the start time in the HTML.
Why would I want this?
In my situation, the college I work at runs a robust news site that often times includes videos. In that context, we format our videos to include an opening branding screen, then a brief intro paragraph to orient people to the video they are about to watch. This works great for the news site, but what if we come across a situation where we want to skip that intro and go right into the video?
Vimeo Player JavaScript API to the rescue
The Vimeo Player JS API allows developers to easily interact with their Vimeo embeds. The directions on including it are pretty straight forward, they even offer a CDN hosted version to include:
So, to access this Vimeo embed, in my JavaScript file I do something like:
if ($('div.video').length) {
// Loop through all the videos
$('div.video').each(function( index, value ) {
// Grab the Vimeo player already on the page
var vPlayer = new Vimeo.Player($(this).find('iframe')[0]);
// Set a flag to determine if the player has been paused yet
var pause = false;
vPlayer.on('play', function() {
// If the player has not yet been paused, start it at
// the specified time indicated in data-start-time
if (!pause)
vPlayer.setCurrentTime($(value).attr('data-start-time'));
});
vPlayer.on('pause', function() {
// Set the pause flag to true. Setting this prevents
// the player from starting the video at
// the 'data-start-time' instead of just
// continuing the video where it was paused.
pause = true;
});
});
}
Limitations
There’s nothing to stop people from rewinding back to the beginning and watching the intro if they choose, so if you’re trying to use this method to cut some video, it won’t work.
This also assumes you have the means to add data attributes to your HTML to store your start times. If you don’t have access to your HTML, you might need to rethink your approach.
The Paragraphs module has been super helpful to developers and site builders who want to provide content editors with a solution to create amazing looking sites without having to know HTML.
I’m currently using Panels/Panelizer and Fieldable Panels Panes in the Drupal build at work to allow content editors to create the pages they want. Panels overall is great but I’ve come across situations where the In-Place Editor is buggy and/or creates confusion for users. The editing experience is a little wonky for them because between the node edit form and the In-Place Editor, there’s too many ways to skin a cat.
So, with our new department sites roll-out, I’m trying something new and moving away from Panels and going all in with Paragraphs. An immediate roadblock I ran into was How do I embed a View in my paragraphs page?
Viewreference module + Paragraphs
After asking around in Drupal IRC, a nice fellow pointed me in the direction of Viewreference. Once I came across this module, things started falling into place.
At a glance
Install module
Create a Paragraph bundle called “Embed view”
Add a Viewreference field to the bundle
Viola! Embed your views.
Install module
drush en viewreference -y
or download, unpack and upload to your module’s folder.
Create a paragraph bundle called “Embed view”
Add a view_reference field to the bundle
Now you can embed Views within a Paragraph bundle!
This is becoming one of my favorite things to do around the time of each new year. It’s a great opportunity to look back at the past year and take inventory of what has been done and reflect on what could’ve been better.
2016 was the year of some Drupal deep-diving. I learned a lot about some Drupal 7 modules including Panels, Paragraphs, and especially Features. Since I manage a 140 site multisite at work, being an expert at Features is absolutely critical to consistently deploy functionality across those sites.
I went to Acquia Engage again in Boston this past year and met some really nice people from MediaCurrent.
I worked with a very talented art professor at the college and implemented a WordPress theme based on a class design for our local children’s museum.
2016 is the year I stepped up my freelance work and have considered starting a side-business out of it. I don’t have kids so I have free time in the evenings. I love this work as well, so why not?
I didn’t dig into front-end frameworks as much as I wanted to this year, but I still think that’s coming.
Outside of technology, my wife and I bought our first house which made the last quarter of the year fly by.
Here’s a few things I’ve learned along the way to make Drupal a little more editor friendly. When appropriate, I will show how these improvements fit in with Nielsen’s ten usability heuristics.
Make admin/content work for your editors
Recently I was explaining to a client how to edit pieces of content on their site. The site contains a fielded taxonomy term called Insitutions that is used to categorize the Programs content type. As I was explaining to the client how to edit taxonomy terms I realized that it sounded ridiculous. To edit every other piece of content I tell the client to go to admin/content. For this piece of content, however, I was telling them to dive into the depths of a Drupal admin interface.
For Drupal developers or people who have worked with Drupal for years, I don’t think they realize how strange this is because to them it makes sense. I admit, to me it makes sense too. However, we build Drupal sites for content editors, who are sometimes not Drupal experts. I think that is very important to keep in mind.
Here’s what I did to make this area work for me: Clone the default administration views to create tabs of different types of content.
After cloning the View, edit the view name to your liking. For example, for the Events tab, I made the View name Administration: Events.
First, disable the System view and click +Add to create a page display. Under Path, be sure to set it to /admin/content/<type of content here>. Under Menu, create a tab and give it an easily recognizable name. Now, configure the view so that it shows the appropriate exposed filters and content. Example:
Note on access/permissions: I’ve found that if you set the Access rules of the view to a Role or Menu system path, then anonymous users will be able to access your view if they know the URL. They won’t be able to actually perform any operations, but it’s still not ideal to expose it to anonymous users.
Repeat the cloning process until all your content that you want to be easily accessible are represented in tabs.
Example:
Now when editors login to the site, if they click on “Content” in the admin nav bar, they have direct access to everything that is needed for them to edit the content on their site. No more wondering “Where was it that I edit Institutions?”
Consistency and standards This creates some standards and consistency in the interface. There is now a standard that editable content be available within the admin/content interface. This is comforting to users because they no longer have to explore Drupal’s admin menu if they simply want to make a change to a piece of content.
Recognition rather than recall By putting all the tabs in one area, the user no longer has to remember information as they click through the interface. This allows the user to recognize what it is they need to edit, rather than trying to recall how to edit Institutions, Events or Programs.
Match between system and the real world According to Nielsen, “The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms.” When trying to edit an Institution, words and phrases like Structure, Taxonomy, and List terms are hardly speaking the user’s language. They know they have a piece of content to edit and will be looking for ways to edit it within a list of content. By providing tabs to directly edit taxonomy terms within admin/content, editing content within Drupal becomes a little less scary to novice editors.
I wrote down some ramblings about this subject a while back after first reading about it through @mrmrs on Twitter. The idea of single function CSS classes was weird and seemed unnatural at first, but I was very intrigued. I considered this idea around the same time I was realizing that, at work, I basically keep creating variations of the same designs over and over. Thus bloating our CSS file and wasting time developing components that were pretty much previously completed. Then a lightbulb went off. 💡
We were in the middle of a project at work and I decided to try something. I’d create a bunch of “helper” classes that would perform single functions on an HTML element. For instance, .text-center would align the text in the center of the element. .container-800 would create a container that was 800px wide. I created about 20 or 30 of these classes and tried to come up with rules that I routinely use when creating BEM or SMACSS style components.
The result? Incredibly fast iteration! I could piece together these classes in HTML to make interfaces in our CMS so quickly that I couldn’t deny there is some real value in this.
Another result: people who work on my team can no go forth and build awesome interfaces without necessarily needing to know about SCSS, preprocessors, etc. It lowers the barrier for entry and helps groups work together faster.
It makes designer and developers speak the same language. “I think there should be a little more padding on this container” can now be remedied by the designer or the developer by modifying the padding class on the element. If the designer doesn’t know CSS or any of the tooling the developer uses, it is still possible for the designer to change the interface to their liking. This is so powerful.
If you’d like to check out a library that has created tons of these “helper” classes already, look into Tachyons. It’s a wonderful concept and library.
No one comes to a site because of the design. They come for the content or the service, like booking air travel. The design should encourage them to stay, offering a wonderfully easy-to-understand and even delightful way to interact with that content or service. Bad design can certainly bury good content, but you can’t design a “premium experience” and pour crap content into it with any expectation of success.
I think this is a little scary for people who design and make websites, because it demotes the importance of how a site looks.
This is my favorite website. I visit it almost every day. It’s not responsive. It’s not optimized for iPhone. It looks blurry on a Retina display. It doesn’t use the latest HTML5/CSS3 framework. It doesn’t have a thoughtful vertical rhythm. The fonts are nothing special. It is neither skeumorphic nor flat. It doesn’t have its own favicon. It doesn’t have a native app or Twitter or Instagram. It doesn’t use AJAX or SCRUM or node.js or Sinatra. It doesn’t have an API or an RSS feed or VC funding. It hasn’t been featured on a prominent tech blog or won an award.
It tells me the soups of the day.
Freely distributed information that’s relevant to the person reading it. That’s web design.
I’ve gotten incredibly invested in projects before and become so enamored with how I implemented a certain design pattern or how clever a design element was, only to see it met with a tepid response from users. This is typically what happen when you put the cart before the horse. The design could be incredible but if it’s not useful to the user, who cares? The user doesn’t look at your website the same way the person who made it does.
The user is looking for helpful content or a helpful service. They’re not there to look at how it was implemented or how it looks. The only people who do that are other designers and developers.
Most successful web projects start with great content. Design serves to highlight the content. So if all this is true, why do so many meetings quickly move into design?
This is something Monteiro also touches on repeatedly in his books, but we — people who design and create websites — all share some guilt for allowing this to happen. The people who move the conversation towards design before a) purpose of the site is settled and b) engaging content is developed simply don’t know that they’re trying to derail the process.
It’s our job to remind them what is important. It’s our job to prioritize content over design. Ideally, a great content strategist can work with the client and help tease out what is most important to be shown and developers can focus on building a great technical foundation.
So everyone who is reading this, go forth into your next meeting and remind people of the solid foundation that web projects should be built on: a purpose, something useful to the user, and great content to support it. Once those things are decided, the design will follow.
This post is heavily inspired by the article referenced in the above tweet. If you haven’t already read it, stop what you’re doing and go read it. Every once in a while you come across a post that challenges your assumptions and makes you take a step back and evaluate your process.
I know a little bit about maintaining large CSS code bases. At my current job, we have a 140 site network of Drupal 7 sites for the college. We also have a few WordPress installs and some other sites and static pages in the mix.
Maintainability is something I strive for. There are also some issues with maintaining CSS for large sites that haven’t been addressed until now.
With all the different naming conventions out there, you’d think we’d have nailed it by now. The truth is, CSS is still a mess.
Preprocessors and build tools have brought us a long way, but what if that is the wrong place to focus?
What if you could open up your text editor and build the interface you want without writing a single line of new CSS?
I could open up Sublime Text and write some fancy mixins and Sass functions that really are clever and then make some new classes for my components, but why? Chances are I’ve written CSS that does all of those things already.
I’m not very interested in what I can do with css. I’m interested at this point in what I can help groups of people do with css. –mrmrs
This brings me to why I’m so interested in the concept of one class, one function.
When working with a giant network of sites with distributed authorship, you learn real quick that you can almost never come up with a solution that everyone will like. Certain groups want slight variations to components that you built. Things come up.
What if we threw a bunch of lego bricks at them and said “Here’s all the tools you need”?
Consider the following HTML:
<div class="card card--red">
<h2 class="card--headline">Headline</h2>
<p class="intro">Here is some test text</p>
</div>
Without looking at the CSS for this, can you imagine what it would look like? I’m guessing you would know it looks something like a card and maybe it has a red background? Other than that, it would be difficult to tell what is happening here. Are there any clues about fonts, padding, borders, or text styling?
Now, consider this HTML:
<div class="bg-red padding-2rem border-1px">
<h2 class="sentinel italic font-large">Headline</h2>
<p class="whitney drop-cap">Here is some test text</p>;
</div>
You’ll notice a couple differences right off the bat. There are more CSS classes, yes. But you can also get a much better idea of what the HTML will do. It is semantically clear.
Benefits of this approach include rapid interface development without having to write a line of CSS. Once you come up with all your “utility” classes, you’re free to construct your interface using classnames in HTML.
Also, it allows a broader group of people to benefit from your CSS. People who may not be comfortable with CSS can now in plain English, add classes to their markup which does one thing without having to worry about side effects.
Let me be clear: I don’t think this is a substitute for writing some abstract classes. I think there is still a need to write classnames that don’t map directly to a function (ex: .header-top, .footer, etc) but the point is that a majority of the CSS functionality will be easily exposed in the form of plain English utility classes.
I think this has the potential to help large sites with lots of CSS and lots of people who use the CSS. I’m interested in giving this a try at my organization. When I do, I will most certainly report back here with my findings.
It seems like just yesterday I was writing my thoughts on 2014 and 2013. This year marked a couple accomplishments. It was a busy year full of graduate coursework, freelance projects, and full-time work.
In 2015 my title changed from “Associate Web Developer” to “Front-end Developer” which was more apt at the time because a majority of my day was spent working with HTML/CSS/JavaScript.
Our office undertook a giant project of migrating CMSes. We went from using a vendor’s product to building our own CMS using Drupal and the Panopoly distribution. It’s been quite the undertaking but offered lots of opportunity for growth.
Being a front-end guy, adjusting to Drupal was a little challenging. I was used to WordPress where templating seemed to make a little more sense. I found that in order to do proper front-end work with Drupal, you need to understand PHP well enough to manipulate data using Drupal’s hooks and preprocess functions. In 2016, looking into decoupling Drupal is extremely appealing because of the front-end freedom it provides. No longer will the front end be entangled with a giant monolithic system. I look forward to seeing what is possible.
I did a technical review for Packt Publishing on a book about Bootstrap.
I completed 9 credits of my master’s degree in Human-Computer Interaction.
Began working with a network of 140+ Drupal multisites. I deploy theme, module, and configuration (via Features module) to these sites. I also run updates on them and customize functionality when necessary.
Went to Cornell University for DrupalCamp in April.
Went to Acquia Engage in Boston in October.
Dusted off my Java skills and prototyped a yoga routine app to help with my yoga practice.
Next year I would like to focus more on creating a real pattern library for the site at work. Identifying and designing some more reusable components will be key to have a robust pattern library that faculty and staff will want to use.
Also, 2016 will be the year that I really sink my teeth into some front-end libraries. I’ve begun Wes Bos’ React for beginners course that has proven to be a solid introduction to React. I’d like to
build a simple React app of my own
implement a REST architecture
consume/write data to Drupal
build an Angular2 app
finish YogaRoutine
I’ve spent some of 2015 reading about these frameworks, now it’s time to actually do it. I’ve been slowly dipping my toes into the waters of front end frameworks and I think it is finally time to take the leap into it and try to build something with them on my own.
