Ch-Ch-Ch-Changes: Happy New Year 2016!

| Posted | Comments | , , , , , , , ,

So, here we are with a new year upon us. Time to reflect on the previous year, what we've learned, and what has changed. As a web designer and developer, quite a bit has changed since the beginning of last year.

For starters, I've adopted a new CMS platform called Statamic and have made it my go-to CMS for smaller sites that don't have a ton of complex content requirements and relationships. The interesting thing about Statamic is that it's a flat-file system, meaning that it doesn't use a database. This makes Statamic inherently more secure compared to the likes of <ahem!> WordPress. Granted, there are other flat-file systems out there that are worth considering (ie. Grav, Kirby, Pico, and others) but I ended up coming back to Statamic, especially after the version 2 beta was announced. I'm looking forward to seeing how I can leverage Statamic as a worthwhile alternative to more popular platforms. I have ideas on how to do it. Just a matter of putting a plan in place and going for it.

I continue to use SilverStripe as one of my CMS platforms of choice, especially for projects that have complex content requirements with lots of relationships. SilverStripe closed out the year by released a stable 3.2 version of the CMS and framework. Like Statamic, I'm looking forward to finding better ways to leverage how I market SilverStripe to my clients.

For front-end design, I still continue to use Bourbon as my go-to Sass library for projects that require a heavy amount of design customization. I still use Twitter Bootstrap for some projects but I'm also looking forward to checking out the new version of Foundation (version 6). I built a few sites on previous versions of Foundation and found Bootstrap to be easier to deal with. However, I'm very curious about this new version so I'll be checking it out to see if they improved some of the quirks that made previous versions weird to work with.

I've also adopted the use of Pattern Lab on one project. So far, the experience has been quite positive and my partners seem to really like it as well. It was a little weird and quirky to work with at first but, once I found my groove, I found that it can really improve your workflow and process. The whole Atomic Design methodology is quite interesting and presents a better way to approaching the whole content-first/mobile-first way of thinking. Creating a whole design system with modular components feels like a much better approach compared to what I had been doing for sure.

Another big change is switching from Sublime Text to Atom as my code editor of choice. This wasn't an easy choice. I've been using Sublime Text for some time now and really liked it for it's speed and flexibility. Honestly, there was really no need to switch. The main reason I switched is...well...I was greatly concerned with the lack of progress with the Sublime Text 3 Beta. I had been using the version 3 beta for nearly two years and, in that time, it just felt like new versions were being released at less and less frequency. At the time of this writing, the last beta 3 release was released in March 2015. I'm not the only one with concerns about the longevity of Sublime Text. Reading the posts on the Sublime Forum reveals that a lot of developers are just as concerned as I am. As such, I felt it was time to jump ship and find another text editor that is similar to Sublime Text but offers more support and more frequent updates. Atom most certainly fits that bill and, while it's not a 100% carbon copy of Sublime Text, it definitely gets the job done.

Last year was certainly an interesting year for continued learning and reading.

I started learning more about different javascript frameworks and libraries, completed one project using Knockout and started some online learning on Ember. This year, I plan on learning more about React which I think will be a good alternative to Knockout for projects that don't need a heavy handed framework like Ember but a simple library that can snap into any page on a website.

I've read some of the books by A Book Apart and plan on finishing all of them in the first quarter of this year. I'll also be revisiting a few books that have received new editions: Hardboiled Web Design: Fifth Anniversary Edition and Adaptive Web Design Second Edition. Also, after seeing Star Wars: The Force Awakens (If you haven't seen the movie...shame on you! What's wrong with you?), I have a renewed interest in reading more novels and plan on catching up on all the latest Star Wars books. Hope to read at least one book every two weeks.

Perhaps the biggest change for me is realizing that I have to take my business to the next level. 2015 was an interesting year for Soulcraft Group. I'm continuing to work with some great partners and establish more relationships with wonderful clients. But with that comes change in terms of how I approach my business. I started off wanting Soulcraft Group to be more or less a network of different companies and people all coming together to accomplish the same goal: to design and build online solutions for small to mid-sized businesses with an emphasis on quality. While that is still true, I've also come to the conclusion that I need to market Soulcraft Group for what it really is, namely me. Once I came to that realization, it became clear how I need to market my little company: as a full-blown marketing and design agency. My partners will continue to be a part of the way I market my company. While I'm good at web design and development, I'm terrible in other areas like online marketing, social media, video production, and other things that I suck at. You can expect a modest update to my site and how I market my services.

So, that's it for the year! Looking forward to the new year with exciting things to come! :)

Why I Killed Google Apps

| Posted | Comments |

Today, I decided to completely do away with Google Apps for my primary domains. The reasons are numerous but, for sake of brevity, I’ll list my top 5 reasons with a bit of detail for each.

I’ve been meaning to look at alternatives to Google Apps for some time now. I don’t really use many of Google’s apps except mail, calendar, and contacts. Most of what I do use is tied to my Gmail address so it really doesn’t do me much good to keep my domains on Google Apps anymore. That could be reason enough but, honestly, there are a number of things that made me want to do away with Google Apps and seek out alternatives:

1. IMAP is wonky and ssslllooowww!

Google’s IMAP implementation isn’t exactly to spec so many email clients and apps have problems with it. Heck, Apple has been fighting with it for the past two years trying to get performance issues squared away with the default Mail application in Mac OS X. On top of that, it’s slow as molasses and sometimes takes forever to bring up new mail. Performance and reliability are the two things that I expect the most out of the online services I use…especially email. Which is why I’m having a hard time understanding why Google, one of the biggest internet providers, isn’t as fast and reliable as it should be.

2. Spam protection not as good as Gmail

Since switching to Google Apps, I’ve noticed that spam protection is a bit hit and miss compared to Gmail. With Gmail, I rarely had any legitimate email land in the Spam folder. With Google Apps though, it always seems like the same email ends up in the Spam folder no matter what I did. I tried updating the spam settings in Google Apps several times, adding email addresses to a “legit" list, but they kept landing in Spam anyways. Kinda frustrating to say the least. Why is there such a discrepancy between how spam protection works between Gmail and Google Apps?

3. Quirky calendar behavior

I typically use a combination of the default Apple Calendar apps (OS X and iOS) and Fantastical for all my calendaring needs. For the most part, integration with Google calendars works but with some quirks. On occasion, I’ve had problems moving an event from one calendar to another, which results either in an error or the event getting stuck on a specific calendar. I’ve also had problems with invites where the same invite keeps showing up in the Calendar inbox and can’t be dismissed. Both issues were rather annoying and, when they happen, about the only solution is to delete the event and recreate it.

4. Privacy concerns

This is a rather mild complaint but one that I’m still a bit concerned about. Many folks online have raised concerns about how Google uses information about activity and data use with Google apps. Their passive approach to parsing keywords and text in email for better ad placement is one thing. But what about the data they collect on our activity within all the different Google-based applications? Are they selling this data? Personally, I’m less concerned about anyone knowing what I do online than I am not know whether a company is selling this information without my knowledge. Transparency seems to be the big issue here and, while it’s a minor gripe, it’s still one that has a bit of weight in my decision to not use Google Apps.

5. Lock-in

Something tells me that Google will likely do away with IMAP (and POP) altogether in favor of dedicated apps using Google API’s. Same applies to Apple’s calendar apps which might not be playing nice with the Google API’s. Again, this may not necessarily be Apple’s fault. My guess is that Apple may be trying to maintain a standardized approach using CalDAV with the Calendar apps but, just like IMAP, Google’s implementation is rather quirky causing some issues with certain features. Granted, IMAP, POP, and even CalDAV are pretty old standards so it would be understandable if Google did away with them in favor of a more modernized approach. However, doing so will greatly narrow the software solutions businesses have in using Google Apps. As such, I would imagine many businesses will migrate away from Google Apps if this happens to avoid any sort of lock-in.

So, what did I end up doing?

Well, for starters, I switched to FastMail for email. So far, I’m impressed with the speed and responsiveness of their servers. I can definitely tell a difference between using FastMail and using Google Apps. It’ll be a while before I know how well spam protection works but my first impression is good.

For calendar and contacts, because I’m in an all Apple environment, I decided to stick with iCloud. Syncing is pretty stable and almost instant. Invites are also more stable and just work as expected. Right now, I don’t have need of any business solutions but in the future, if I do, I’ll likely just use FastMail to share calendars and contacts between multiple users.

For file syncing, I’m currently sticking with Dropbox. I tried Google Drive but just found that it doesn’t work well for syncing data with apps like 1Password and TextExpander. I considered switching to iCloud Drive but found that there still isn’t any apps that allow for browsing your files like you can with Dropbox. Plus, unlike Dropbox, iCloud Drive doesn’t appear to allow you to share files and folders with others in a collaborative way, which is critical for most of the projects I work on. What I’ll likely end up doing is keeping Dropbox for basic business use and using iCloud for personal stuff.

For documents (notes, spreadsheets, presentations), I rarely used Google except for the occasional spreadsheet. Most of the documents I create tend to be within Apple-based apps like Page and Keynote. For notes and text-based document, I mostly use Evernote. I’m also considering the use of Markdown documents for the creation of web content in an effort to speed up the process of converting semantic text to HTML. Most of these documents end up in a folder that gets synced up through Dropbox for easy sharing and backups.

I’ll still maintain my Gmail account, which I’ve had forever, but will keep a fairly low profile with it. It’ll primarily be used for Google+, YouTube, and that sort of thing. One thing I should look into is updating my Google profile and see if I can turn off certain settings in an effort to maintain greater anonymity. I’m sure there are features that can be turned off but, like Facebook, they’re probably buried under 9 million different sub levels of settings.

Suffice to say, I’m glad I switched away from Google Apps. The upside is that I can pick and choose which solutions are the best for me while maintaining a level of privacy that I’m comfortable with. Along with that comes a nice boost in performance which, when it comes to productivity, is always a good thing. Like they always say, “time is money”, right?

Assemble Static Site Generator

| Posted | Comments | ,

For about a week or so, I've been playing around with Assemble a Node-based static site generator that works for Grunt.js and Yeoman. So far, I have to say that I'm impressed. So impressed in fact that I ended up dropping Middleman, a Ruby-based solution that I had been using for the past year.

I've been wrestling with my web design workflow for a good year now and decided to revisit the tools I use for generating website prototypes. For the better part of this year I've been using a tool called Middleman to develop website prototypes. There are a number of static site generator solutions out there, many of which even have GUI's (i.e. Cactus, Hammer, Mixture). Sure, it may not have a GUI and requires knowledge of the command-line and Ruby, but what separated Middleman from the rest was the sheer amount of flexibility it brings. The thing that attracted me the most was the ability to use bits of Ruby to do pretty much anything I could think of inside of templates. That and the ability to use local data from JSON or YAML files to loop over data sets. The extensibility of it is just powerful and it really has helped to speed up the design and development of websites within my workflow.

Lately though I've been running into a few issues with Middleman. As much as I like it, the problem is that it's a Ruby app and, frankly, I'm not much of a Ruby developer. Also, Middleman has certain dependencies that conflict with some of the other frameworks I use. For instance, I use Bourbon and Bourbon Neat quite a bit, both of which use Compass and Sass. The problem is that Bourbon requires that a Sass gem of 3.3 or higher be installed, which conflicts with Middleman's own requirements. You can force Middleman to accept higher version of both Sass and Compass but I'm concerned whether I'll run into compatibility issues later one. This made me think that perhaps a Ruby-based solution isn't the way to go. Granted, if I was a Ruby developer this would be a non-issue.

After a bit of research, I decided to revisited Assemble, a solution that I briefly looked at some time ago but didn't give it much thought. Boy, am I glad I did!

Call me stupid but I always thought that Yeoman was more geared for web application development rather than website development. Because I spend most of my time designing and developing website I figured Yeoman would be overkill and never gave it much thought. But if you really look at the three core tools of Yeoman (Yo, Grunt.js, and Bower), you realize that it's not overkill at all. Yeoman simply isn't just for web applications. In fact, you can keep it as simple and slim as you want. Let's look at each of the tools...

Whether you're starting with a simple HTML5 boilerplate or using a framework like Zurb Foundation or Twitter Bootstrap, Yo is more than capable of scaffolding out an environment for simple web projects. There are official generators for just about every framework out there. If there isn't one, you can easily create one of your own for scaffolding out your own projects.

Grunt.js is just a task runner but a very powerful one at that. It's the tool that automates your workflow. It can handle everything from running a simple local server, compiling your SASS and CoffeeScript files, optimizing images, to building out your project.

Finally, you have Bower, a package management tool that speeds up the management of the various web application libraries you're likely to use. Just about every major framework and library can be installed and managed through Bower and makes updating them a breeze!

Throw Assemble into the mix and you end up with a very, very powerful environment for prototyping websites. Assemble does everything Middleman can do...and then some! And, unlike Middleman, the only dependency it has is Grunt.js. That's it!

As for templating, Assemble uses Lo-Dash templates for configuration and metadata and Handlebars templates for content. The syntax for both aren't hard to learn at all and offer a lot of flexibility. There's not a whole lot you can't do within templates.

Suffice to say, it looks like I'll be sticking with Yeoman and Assemble for the time being. At least until something better comes along! :D

A Lesson in Password Management

| Posted | Comments | ,

With the recent news of the Heartbleed Bug, I have begun resetting all my passwords for online accounts. In the process of doing so, the thought occurred to me that many folks have no idea how to properly manage their passwords. I’ve seen situations where many of my family members, friends, and clients use the same passwords over and over again for just about every account they have online…even for important accounts like their email, banking, and social media; accounts that, if hacked, would reek holy havoc on their digital life. If this is a problem for you too then hopefully this blog post will point you in the right direction in remedying this issue.

The key to keeping your online accounts secure is having strong passwords. However, even that isn’t always enough because a website can still get hacked if there is a vulnerability in the software. The main problem with the Heartbleed Bug is that you end up being vulnerable regardless of whether you have a secure password or not. The good news is that most of the major sites have already updated their servers with a security patch to fix the Heartbleed Bug (see The Heartbleed Hit List). Even then, there are thousands of other sites that haven’t been fixed yet. If you are unsure whether a website is effected by this bug, your best bet would be to simply notify the site owner and ask them, especially if this is for an online account that is important to you.

Aside from any vulnerabilities, the best way to protect yourself is to do the following:

  1. Use strong passwords
  2. Always use a unique password for each account
  3. Routinely change your passwords at regular frequencies

All of this may seem daunting. After all, what does a strong password look like? If you have to use unique passwords on every account, how are you going to remember them all? Not only that, but changing passwords take a lot of time, especially when you have to come up with all those unique passwords and record them for safekeeping, right? That’s where a good password management tool comes into play.

While there are a number of good password management applications, my favorite is 1Password by AgileBits. One of the reasons I like it is that, along with managing website passwords, it can handle other tasks such as storing credit card information, filling out registration forms, generating strong passwords, and more. And, because it’s cross-platform (Mac, Windows, iPhone, iPad, and Android) you’ll have access to all of your secure information wherever you go. It’s truly the Swiss Army knife of passwords and other secure information. With 1Password, you don’t have to remember all your passwords. The application handles all your secure information by storing it in a highly encrypted database that can’t be accessed unless a person knows the password to the database, thus the reason for the name of the application. You only have to remember the one password required to access your 1Password database.

If you’ve never used a password management program like 1Password, learning how to use it and getting comfortable with it might seem a little hard, which is completely understandable. Fortunately, AgileBits has plenty of online documentation and tutorials on their website. Along with that, ScreenCastOnline recently posted a free tutorial on how to use 1Password.

Because 1Password comes with a password generator, creating strong passwords is easy. Most sites will let you know what the password requirements are, which you can adjust the 1Password password generator to accommodate for. For sites that have little or no restrictions, I tend to crank up the password length all the way to 30 and set it to include at least three number and three special characters. The 1Password generator will give you an idea on how strong the password is with the strength meter.

Remember, the whole point of this application is to help you generate passwords that can’t be hacked easily. Let the program do the work for you and generate as complex of a password as possible that still adheres to the requirements of the site you’re generating it for. When creating a new online account or changing a password, try to use a different password for each account. The reason is that, if a hacker knows one password, they could potentially hack any account you have that uses the exact same password. Better to err on the side of caution and simply generate a different password for each online account.

I personally try and change the passwords for all my important accounts at least once a year. To aid in knowing which accounts to concentrate on, I created a number of folders in 1Password to help organize accounts by importance. I have a folder called ‘Accounts’ for all my important accounts like email, banking, shopping, and other accounts with highly sensitive information. This is the one folder that, when a major security issue occurs, I address first. Along with that, I have other folders separated by business, personal, clients, organizations, and miscellaneous. I always change the important stuff in ‘Accounts’ first followed by personal and business accounts.

I won’t lie, changing all your passwords can take time. However, a tool like 1Password greatly helps in cutting down time spent changing passwords. If you concentrate on the most important ones first then you can change others over time. 1Password does have tools that allow you to target accounts that have really old passwords. Once you get the hang of it, you’ll find managing passwords and other secure information with 1Password a piece of cake.

Got any other useful tips for managing passwords? Leave a comment in the comment section below! :)

GhostLab: Bringing love back to website testing

| Posted | Comments |

Every now and then a tool gets released that completely blows me away; something so useful that I just had to buy it immediately. Today, that tool is GhostLab. GhostLab is a simple Mac application that makes synchronized testing for websites easy. If you're on a Mac and you're a web developer, this is one of those apps that you have to take a look at.

Any web developer will tell you that one of the biggest pain points in designing and developing a website is cross-browser testing. It's even more painful when you throw mobile browsers in the mix. Third-party services like BrowserStack offer great solutions to help with this but tend to be hindered a bit by a cumbersome workflow. Sometimes you just want to get in and test something quickly prior to any rigorous testing with services like BrowserStack. That's where GhostLab come in handy.

GhostLab blew me away based on three core features:

Any Site. Any Client.

When it comes to the websites you want to test, GhostLab doesn't care where it is. It can be static files sitting in a folder, a local IP or web address, or any external website. As long as you can get to it locally, GhostLab can test it. Just drag in a folder or URL and GhostLab will set it up so that you can test it. It's that easy. GhostLab has it's own built in server so all it's really doing is tunnelling all the traffic from whatever site your testing through it's own server. By doing so, GhostLab is able to bypass any of the complexity surrounding most workflows when it comes to cross-browser testing. It even works with virtual machines and emulators. As long as the browser you're on can access the GhostLab server then you're good to go!

Synchronized Testing

Imagine being able to open a website within multiple browsers and have it detect scrolling, clicks, reloads, and form inputs from no matter which browser instance you're using. Yep! GhostLab does it! I use CodeKit when developing sites and whenever I make changes to my code CodeKit will automatically refresh my browser window for me. What's neat about this is refreshing that window will also refresh any other browser that's running the same GhostLab site. That's a nice little bump in my productivity.

Another useful feature is the Workspace feature. Usually when I'm testing my code for a responsive design, the chrome and buttons in my browser get in the way of viewing how a site might look at a given screen size. With GhostLab, I can fire off an Open Workspace command and the site will open up into three different chromeless windows sized at three different mobile breakpoints. Very, very handy! Only thing I haven't been able to figure out is how to create and/or update a workspace.


This is the killer feature for sure! I can't tell you how annoying it is not having proper inspectors in Internet Explorer much less the absence of them in mobile browsers. GhostLab solves this by utilizing weinre, an open-source remote debugger. I looked at weinre in the past and thought about adopting in but getting it to work was a royal pain. With GhostLab, weinre is built right in so no setup or configuration required. This gives you a Webkit-like inspector for any browser. I personally hate the web inspector in Internet Explorer and prefer the Webkit inspector so having this feature available is a huge time saver for me!

I typically test using a few different virtual machines. I have a couple of Windows VM's for testing different versions of Internet Explorer and other Windows-based browsers. I have the iOS Simulator that I use to test iOS devices. And I have the Android SDK for testing Android-based tablets and phones. Usually, I have to test each of these one at a time and, without inspector abilities or synchronize testing, the process of debugging can be tedious at best. With GhostLab in the mix though, the workflow couldn't be any easier! Not only do I have the power or synchronized testing but full inspection and console access to boot! I'll likely still use BrowserStack for more thorough testing but for a basic testing workflow I don't think you can beat GhostLab. Check it out!