Today will be my last day as Web Developer in WNET’s Interactive Engagement Group, just two weeks shy of my two year anniversary. Monday, August 1, will be my first day as Documentation Editor at Joyent.
I had been thinking about my next move for a while – I suppose you could call it the two-year itch, the one that young professionals seem to get early in their careers. For the first time in my life, I was being actively recruited by various organizations looking for front-end developers (or back-end engineers, for which I was not the right fit). Recruitment is a funny thing. It’s nice to start practicing what it will be like when you put yourself out there for new positions, as well as potentially open an opportunity that you may not have come across otherwise.
Joyent came to me through a more old-fashioned method: in-person networking. Instead of a recruitment email, it was me sitting at the hotel bar after the first day of O’Reilly’s Velocity Conference and talking to a potential new friend about ourselves and our goals for the conference. I did a good enough job convincing this gentleman that I believe in the importance of documentation for developers, so much so that it sent me down a path of phone calls and interviews about a role they were just creating for someone just like me.
This was originally written and posted on the Interactive Engagement tech blog for WNET.
I’ve learned a lot since I started working at IEG in August 2014, from building better WordPress themes via MVC to the ins-and-outs of git (how I got by before, I’ll never know). The greatest tool that I’ve embraced in my tenure is Sass. For those unfamiliar, Sass is a CSS preprocessor which takes giant complex stylesheets and neatly organizes them into tiers. There are so many features which will make your development process cleaner, faster, and happier.
Responsive web design is a buzz word that we are very familiar with at IEG. All of our modern sites fit that bill (we do have some that are quite old), and you can see it in action with the resize of your browser. The excess design falls away, the menu becomes a hamburger (which, has its own problems), sidebars slink below the content. But just because it fits a certain width parameter, doesn’t mean it works for mobile.
I just finished rebuilding the site for MetroFocus, a multi-platform news program focusing on the New York region. I got to a point where I was happy with the design, with the responsiveness, and we sent the site to our app developer to do some testing. He came back with incredibly insightful feedback when it came to thinking about actually using the site on a mobile device. The header and menu took up too much precious real estate and disappeared from view on scroll. The hamburger was small and surrounded by un-clickable (or, un-touchable) white space.
While the site looked good on a narrow browser, it wasn’t user-friendly for smartphones. I took his notes and spent a long time on my smartphone, clicking through and trying to think beyond “does this look good” and “is it broken” to thinking about the user’s experience on their phone. I can’t be spot on for every device and every situation, but we came to a place that is 100% better across the board.
I’m so thrilled to announce that a show I stage-managed for FringeNYC, The American Play, was selected for the Fringe Encore Series. This means, we get to do our show in an Off-Broadway space, a HUGE honor for all of us.
I said goodbye to Michigan State’s theater program five years ago. I quit acting and designing costumes, except for a final tour of a children’s show that allowed me to get my minor. I never thought that when I moved to New York, I’d end up working on shows, let alone one that was so incredible. It has been a taxing but very rewarding experience.
This post was originally written and published on the IEG technical blog.
Often when we create our WordPress themes, they come with a small theme options page built using the Settings API. This page could have inputs for everything from social media handles to uploading a new logo or picking a homepage layout. Having these options makes it easier for non-developers to make important changes to their websites, or give it minor refreshment.
Here’s a pretty straightforward example of how we use it on Chasing the Dream. Administrators can update the links for social media icons, enter the unique Google Custom Search Key, pick a homepage grid, and even update the footer text.
Having a theme options page is a good way to set global options, such as a font or accent color. Instead of having to find all of the places within the CSS every time a client wants to try a different shade of blue, instead they can have the power to update it themselves.
Back in October of 2014, I had a bit of a dry spell at WNET. There weren’t as many new projects coming in, and I was still green to the way our more complex web properties work. Instead of sitting around and reading the various internet news aggregates, I decided to attack a problem I knew about even before starting my job that August.
The Interactive Engagement Group (IEG) website was a flat, two-page piece of brochure ware. It was built to appease the powers-that-be, but was in no way indicative of the type of amazing work that the department was capable of doing. I wanted to take this project head on and lead the way to a beautiful, responsive, and informative website that would not only show off what we could do, but show off the expertise of our team. To do this, I needed buy-in from my boss, head of the technical team, and from the head of our department.
To Get Buy In, I Came Prepared
Though I talked about why I thought it was important with my boss and with the developer team, I knew I would need a lot more than a “good idea” to get department funding to build the site. I put my professional writing skills to work and wrote a content strategy.