Javascript. The Language to Learn.

Welcome to 2017.

The first application I ever wrote utilized JavaScript; it was a hybrid mobile application that was built on the jQuery Mobile Framework (start the boos). It was a great framework for it’s time as it accomplished what I wanted it to do even though I didn’t have a clue what I was doing. Fast forward five years later and JavaScript frameworks have become so far advanced that jQuery Mobile, which was amazing 5 years ago, is not even in the discussion when talking about front end frameworks + mobile. While the frameworks have changed, I can assure you of one thing… JavaScript is the past, present, and future of web and mobile applications.

I’m a strong advocate of moving databases to APIs. For multiple reasons, I like the idea of having the back-end being responsible for giving me the data that I need and the front-end manipulating what is shown on the page.

  1. By moving to an API backend it doesn’t matter what type of front end you use thus making it more adaptable.
  2. You can utilize React, Angular, Ionic, etc and it really doesn’t matter.
  3. You can build once, using the aforementioned frameworks, and utilize on every device; even mobile.

In regards to the web, JavaScript is a lot easier for developers to learn and is more widely utilized than native languages. In todays day, native applications are just a minuscule faster than JavaScript and is arguably not even noticeable. A few years back and this would certainly not be the case, no discussion. The internet is everywhere, internet speed is absurdly fast ( and going to get faster) even if you aren’t connected to WiFi. Even natively built web applications (hence “web”) still have to connect to the internet to be able to do anything. Unlike having to write native code + whatever front end code you need for the desktop version; imagine writing something once and having the portability to move that existing code wherever you want and — not having to rewrite everything — and it still work; welcome to JavaScript in 2016.

In the coming years you will see more web applications being as an API only. You will see the value of JavaScript developers skyrocket for the very simple reasons outlined here. If you were to learn one language for the web, make it JavaScript.

Investigating Software from an IA Perspective

Last night my wife and I were up late investigating a piece of software that could potentially be utilized in her salon and spa. It claims to do everything from marketing, online booking, point of sale, client tools, reports, automation of all varieties, provides a unique mobile app, sms appointment reservation & confirmation, and many more.

To any software developer the immediate reaction is “wow, what a massive piece of software”. To the information architect, you’re immediate reaction is “how in the world?”

How in the world can you offer such complex services and claim such tooling in one app, is it even usable? Luckily for me I have quite a bit of expertise in both software development and information architecture (IA) leading to my next concern…

What are the reviews saying?

– “I spent over 60 hours over the space of about 6 months trying to get it set up.”

– “Slow, unintuitive, more bugs than a decomposing body and customer service that is shockingly bad.”

– “There is so much that I get a little overwhelmed.”

These are just a few of the poor reviews I found, there’s actually many more but these were the most concerning from an IA stand point.

  1. Why does it take anywhere near 60 hours to get a piece of software setup? There should always be a walkthrough, whether its a full on tutorial or a simple guide/checklist to get things moving.
  2. I’ll avoid the “slow” and “more bugs than a decomposing body..” and focus on the keyword at hand, “unintuitive”. That is the most hated word in IA. That would should never be used and will never be used in any project you ship.
  3. It’s understandable there’s a lot of content; they promise that in their features. Though, no user should feel overwhelmed. It’s easy to say but it’s a lot to actually address because you don’t know the threshold for an end user to feel overwhelmed. You can however, mitigate.

Addressing all of these in one fail swoop: User Testing.

User Testing would have exposed these three areas before the software was even launched. In IA, you have not done your job if you haven’t exposed your logic flow to the uneducated. By that, I mean people who have never experienced, or been predisposed to, your software/website.

The easiest approach to this is to find test subjects of different ages, technological skill set, etc. and have them answer the basic questions to which the application addresses.

For an application as such:

  1. How would you make an appointment for a client?
  2. How would you create a product?
  3. You have a customer who wants to purchase a product, how would you sell that item to them?
  4. How would you run any simple report you wish?

Those are basic questions for such a software, but are essential for any end user to be able to complete.

This isn’t some rocket science. It’s just doing your due diligence as a software provider, developer, service provider and more importantly an Information Architect.

P.S. Inspiration for writing this article from Lindsey Gaff’s article on Design & IA. Check it out here.

Bounce Rate Poor? Doesn’t mean you’re failing.

About 6 months ago I was viewing analytics for a website that I created in mid 2015, as a freelance job, for my mother-in-law who owns a local salon here in Tallahassee, FL. The bounce rate was unbelievable. In fact, it was sitting in the 39%, which is almost in the “excellent” range as far as bounce rate is concerned with correctly functioning sites. It was great.

Then, like any normal person would do, we decided to change the home page up. I wanted a new, updated design that reflected the modern web; since, you know, the web changes every few months it seems. So we moved forward, we implemented the designs, and it looked amazing. It was modern, sleek, and was presumed to do exactly what we wanted; drive more sales.

However, a month after implementing this design I decided to view the bounce rate again thinking we would have dropped more points. Boy was I wrong. In fact, something inconceivable happened, we had gone up to 44% on the bounce rate. I couldn’t understand it. I’m sitting here looking at an amazing home page, viewing the analytics, and seeing something just doesn’t doesn’t add up based on my many years of schooling and developing.

At this point I was in denial. How could something go from amazing to “okay” when implementing something that I was sure would help the business. This is when the wheels in my head started spinning. What is affecting bounce rate? it’s when someone views one page and then doesn’t view another from within the site. Or, views one page and “clicks” away from your site.

The latter seemed like a possibility in this case. The salon utilizes a software that manages their booking of appointments that is on a site other than the one I created (this is when things start to “click”). I further implemented more analytics, specifically a service called “crazy eggs” on this site and ran these analytics for a 3 week period, gathering as much information as I could.

Once the 3 week period was up I was astonished. I grouped the crazy egg analytics with what Google Analytics was showing me and I about lost my mind. Google Analytics was showing a 44% bounce rate still; meanwhile crazy eggs was showing 2300 views in the 3 week period with 510 people clicking “book now” or some other button that would take them to the booking software. When running the amount of views/clicks + the google analytics it became quite apparent that my bounce rate wasn’t telling the full story. In fact, I wanted people to click the “book now” buttons or the “purchase now” buttons; that was the original intent of the redesign in the first place. Grouped with the bounce rate, and accounting for the people who pressed the buttons I wanted them to; my bounce rate is actually 32% (in the near perfect percentage).

On first glance, the bounce rate for my site shows an underperforming site. However, when grouped with further information and more analytics it proves otherwise. The point is, bounce rate doesn’t tell the whole story. In fact, it may not tell the story at all.

P.S. I don’t get paid to endorse CrazyEggs or Google Analytics but I would definitely consider utilizing both services if you want to find the true story your website has to tell.

Rails vs. Laravel

Ruby on Rails is currently my preference for an MVC framework. In my experience as a programmer, Rails developers are some of the most skilled and most passionate web developers in today’s industry. Like many Rubyists, I can’t quite put my finger on all of the reasons why Rails wins for me.

I, like many Ruby converts, started in PHP. Before starting at Whiteboard, I had barely heard of Ruby on Rails; in school, I was primarily taught PHP.

After starting at Whiteboard, Rails has permeated conversations around the office for the better part of a year and half, and in that year and half I have grown to love it. The separation of concerns Rails offers through basic MVC is a breath of fresh air for me.

Despite these personal affinities, I think Laravel will gain and eventually eclipse the popularity of Rails.

The Scope of the Debate

This debate is over the popularity of Rails versus the popularity of Laravel. Not Rails vs. PHP.

Ruby (and, for web, Rails) solved the issues of overreach that have caused nightmares for PHP developers. PHP’s lack of strict purpose has lead it to become a cluttered, discombobulated collection of mismatched tools that few can wield properly.
Ruby on Rails was released in 2005 and was the first largely successful MVC web framework (post-dating Spring, a relatively lesser-known Java MVC framework). PHP didn’t have a popular MVC framework until 6 years later in 2011, when the first commit was made to the Laravel source code by Taylor Otwell.
The sheer number of PHP developers is massive, likely due to the fact that LAMP stacks are easily accessible and cheap, and much easier to get running than an average Rails server (though solutions like Heroku challenge that assumption). What’s more, the rate of new projects using Ruby has been on a relatively sharp decline over the past couple of years. PHP, on the other hand, is on the rise. While Ruby (and, arguably by proxy, Rails) is still winning out, PHP isn’t leaving the scene any time soon.

I believe that the powerful concepts introduced by Rails that are carried on by Laravel will propel it as a more popular MVC framework for web, above Rails, in the coming years.

Changes in PHP

The final area to focus on is that of the PHP language. Despite PHP’s history of sloppy structures and strange tools (like the highly web-specific nl2br function), PHP is changing constantly. Great new features like PDO change the fundamental nature of PHP, and even though some of those old oddities still remain in the language, powerful, clean code is now accomplishable with PHP. For example, PHP has also introduced real classes, offering true object oriented constructors. This specifically makes Laravel a natural match for the language, as it relies heavily on object orientation. Of course, by preferring object orientation over unorganized declarative-style programming, PHP developers also benefit from much more concise and maintainable source code then the stringy mess of yesterday’s PHP projects.

My Verdict

I haven’t jumped ship from Rails for Laravel… yet. But I do have an intense curiosity with the future development of Laravel. If Laravel can accomplish the community-driven culture and craft-consciousness of the Ruby community, it has the opportunity to naturally not only surpass Rails, but to become one of the web’s the most valuable and widely-used MVC frameworks.

One File Per Media Query

I’m tired of it. I sift through code all day and I have to deal with stupid media queries. Yes, it’s probably the greatest invention since sliced bread, but really people? Come on. We’ve adopted a new principle while simultaneously making it more difficult on ourselves. Through one LESS file I will see 23 media queries; oh, you think that’s not a lot? I’ve encountered easily 60+ in one file. It drives me absolutely nuts when I’m editing a query in the LESS file, going to Chromes developer tools only to find there’s ANOTHER media query addressing this issue in the SAME FILE. REDUNDANCY. It’s absolutely ridiculous. Trust me, I’m just as guilty of it as the next person but it begs the question; why are we sitting on our hands and accepting this? Sure you build the site once and you think you’re done with it, sure you may never see that code again; but what if? What if you do have to go in and edit that code, not just on a bi-monthly basis, or monthly basis, but on a regular basis. Why give yourself the headache when you can compile all the code in a separate CSS file?

Next time you start building a website, build it with this new principle in mind; one file for desktop, one file for your tablet breakpoints, one file for your mobile breakpoints. PUT ALL OF YOUR CODE addressing those breakpoints in the given file. This will save you time, this will save you effort, this will save load time on mobile devices, and most importantly this will save your sanity. Three media queries. I digress.

The Greatest Lesson

While sitting at lunch a few days ago with my co-workers and bosses, the conversation of an apocalyptic doomsday came about; much like the movie World War Z. Now, of course we were just hypothetically speaking, but one of my co-workers mentioned how they would like to invest in land and fence it off such as a fortress to protect anyone from getting in. They mentioned, in due time that they would have such property. In the course of the conversation, one of my bosses brought up the keen fact that there are only two finite resources. One being land, the other being time.

The definition of finite means to have limits or bounds. You cannot produce more time; therefore it is considered a finite resource. I cannot replicate May 28th, 2008; when I graduated high school. Nor, can I replicate October 16th, 2012; the day I quit my job working for the Florida Senate. These moments are etched in time, they are not capable of being replicated nor can I add on to the days to change them. I couldn’t give my grandpa more time to live, or surely I would’ve done so. Time comes, time goes, and there’s nothing you can do to stop it.

When I quit my job on October 16th, 2012 I made a conscious decision to do so in order to begin an IT Managed Services and Web Development company with my brother. Together we made quite a team. Together we were both quitting steady jobs to pursue what both of us truly wanted to do. Between October 16th, 2012 and August 30th, 2013 we made a lump sum of $500 between the both of us.

I can think of only handful of people who would consider that a success, and every single one of them are under the age of 5. Rightfully so, most everyone beyond the kindergarten level would consider our venture a failure. Surely I have ideas now about how to go about things differently, but to me, that time brought about an intrinsic value that can’t be replicated elsewhere. For the first time in my life, I failed at something that I truly tried at, that I undoubtedly wanted.

Throughout this venture I learned about failure, I learned about celebrating the small successes, the thrill of going into peoples office, people who were once in your shoes, people more successful than I, and trying to convince them of something I couldn’t’ even convince myself of. I had never worked for a web development company; I merely had a Bachelor of Science degree from Florida State. I didn’t have the 6 years of experience to show for. Time was not on my side.

What makes this a success though, what makes this venture not a failure, is that we sped up time and we did what most everyone is afraid to do. In those 10 months, we aged 10 years. In those 10 months we learned what 16 years of schooling couldn’t teach. We went for our goals. In those 10 months, we were truly happy.

The fact is people are so comfortable to have a steady paycheck that they will sacrifice their happiness for stability. They’ll sit there at their desk job that they don’t want to be at and day in and day out they’ll utter the words “one day”. One day I’m going to do this, one day I’ll have that, one day things will be different.

That one day is never going to come unless you finally make it happen. Time is a finite resource. You only have the time you are given and there’s nothing you can do to prevent that.

On October 16th, 2012 I decided I had done enough time. On that day I took control of my time and it lead me on a whirlwind 10 months that I wouldn’t change for anything. It ultimately lead me to where I am now, working for who I work for now, doing exactly what I love. I may be back on that steady paycheck, but I’m on a steady paycheck doing exactly what I want to be doing. I could’ve stayed in that job and just kept uttering “one day” but I didn’t; and at that moment I made time start working for me.

My challenge to you now, is to make time work for you. If you’ve had something that you just “need more time for”, whatever it may be, stop what you’re doing and make it happen now.