Rants, raves, and geeky nonsense!

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?

Network Neutrality and the Idiocracy of Politics

| Posted | Comments |

Normally, this blog is reserved for posts about technology, the internet, and stuff about my career. Writing about politics just isn't something I like to do anymore. Not that I don't have any political opinions. I do (boy, do I have political opinions!). I just feel that politics today is so polarized that it makes debate darn near impossible. However, some recent talk regarding the topic of "net neutrality" gave me pause. As such, I felt the need to write here my stance on "net neutrality" along with my opinion on recent political discussions surrounding it.

Earlier this month (November 2014), President Obama released a statement about his plan for a free and open internet. What Obama outlined is the general consensus that most of us within the tech community feel, that ISP's and other internet-based companies should follow some basic, common-sense rules:

  • No blocking. If a consumer requests access to a website or service, and the content is legal, your ISP should not be permitted to block it. That way, every player — not just those commercially affiliated with an ISP — gets a fair shot at your business.

  • No throttling. Nor should ISPs be able to intentionally slow down some content or speed up others — through a process often called “throttling” — based on the type of service or your ISP’s preferences.

  • Increased transparency. The connection between consumers and ISPs — the so-called “last mile” — is not the only place some sites might get special treatment. So, I am also asking the FCC to make full use of the transparency authorities the court recently upheld, and if necessary to apply net neutrality rules to points of interconnection between the ISP and the rest of the Internet.

  • No paid prioritization. Simply put: No service should be stuck in a “slow lane” because it does not pay a fee. That kind of gatekeeping would undermine the level playing field essential to the Internet’s growth. So, as I have before, I am asking for an explicit ban on paid prioritization and any other restriction that has a similar effect.

The thing is, none of this is new, nor is it a topic something that should lend itself to any political ideology. Folks within the tech community have been talking about this for a good few years now and the consensus is clear: keeping networks fair and open is necessary to the continued success of the internet. Any political discussions that go against this is more or less the equivalent of political suicide and yet, as we'll see in a moment, politicians still insist on playing sides for political gain.

All President Obama did was wrap the message up and use the power of the Presidency to get the message out loud and clear. The problem is that he did it right in the big middle of a mid-season election. Not only that but did it in a time where partisan politics is at an all time high. As John Gruber of Daring Fireball points out, the issue has become so polarized along party lines. In no time, politicians like Senator Ted Cruz take to the internet in opposition to President Obama's statement:

“Net Neutrality” is Obamacare for the Internet; the Internet should not operate at the speed of government.

Gruber's response says it all:

That’s just word soup. The only similarity to the Affordable Care Act is that Obama supports it. There may well be a rational, reasoned argument against Net Neutrality, but Republicans aren’t making it, and neither are the cable companies or cellular providers. Be wary of the side that can’t express their argument in clear, plain, unambiguous language.

Indeed, politicians like Senator Cruz need to watch what they say and how they say it...otherwise, you get the ire of the tech community and end up looking like a jackass (ex. the Dear Senator Ted Cruz post on The Oatmeal).

None of this solves the problem of "net neutrality". In fact, all it does is allow deep pockets to keep throwing money at it in an effort to make it harder for proper legislation to get passed to curb the problem. Meanwhile, businesses and consumers continue to pay higher costs for the internet services they receive compared to what other countries pay. In many areas, businesses and individuals have little choice on which ISP they can use. In other words, many ISP's have a monopoly on internet services in various parts of the country.

As outlined on The Verge in an article appropriately titled "The Internet is Fucked", zero competition, a weak FCC, and no "net neutrality" is a recipe for disaster. The only way to really solve it is to do what we did with electricity and phone service: turn the internet into a utility. Turn it into a utility and you end up solving most of the problems associated with "net neutrality" and ISP monopolies. So, say it once...say it twice...say it loud and clear:


Retailers Are Disabling NFC to Block Apple Pay

| Posted | Comments | ,

Rite Aid and CVS are dropping support for Apple Pay in favor of another solution called CurrentC. I'm in complete agreement with John Gruber on this one. Prioritizing access to customer data over a good customer experience is a bad, bad idea! Compared to how Apple Pay works, CurrentC is a step in the wrong direction and is bound to fail.

Presentation at Big Design Conference

| Posted | Comments | , ,

This past weekend, I had the honor and privilege of being one of the speakers at the Big Design conference. I gave an updated version of my presentation on the User Experience of Comic Books. The response to my presentation was amazing! Lots of folks from the audience had some great questions and comments during the Q&A portion of the presentation. I'm ecstatic and overwhelmed with joy! It's a great feeling to know that I can contribute to other people's education on user experience design!

The rest of the conference was absolutely amazing! Lots of fantastic presentations; many from folks that I know. Many of the presentations were incredibly inspiring. In fact, a few of them gave me some ideas towards my next presentation! ;)

Along with that, a good number of presenters expressed interest in presenting at Refresh Dallas, a little organization for which I'm the organizer for. If you missed the Big D conference and would like to see a few of the presentations you missed, check out Refresh Dallas on Meetup!

For those that requested a copy of my presentation, you can find it on SlideShare.

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