daniel thai

Apologies for the failed attempt at a newsworthy headline, but maybe the following will make up for it. Over at exis web some research was conducted to evaluate the efficacy of the hamburger icon as a universal menu/navigation identifier on mobile websites. As a front end dev, I've seen the icon use in all sorts of mobile projects and I've even used it myself. But, as it turns out, it may not be the best choice if you want users to easily find your mobile nav. What the folks at exis found was that out of the four options provided to their testing base of 50,000 visitors (more demographics info in the article), the hamburger icon was the third most preferred. The most preferred option was the word "MENU" with a border around it (signifying a button), the second most was the word "MENU" with a hamburger icon, both of which were wrapped with a border and oddly in last place was just the plain ol' word "MENU". Now you might say that this seems as obvious as heck, but from a practical standpoint it's a good thing to know that we shouldn't be defaulting to the hamburger icon when designing or building a mobile interface. It seems that the hamburger icon is probably best deployed when its space is at a premium or maybe if the site being built is not based on English language content, so maybe "MENU" wouldn't be appropriate. The article also noted that recent research from the Nielsen Norman Group showed that users have widely established that the magnifying glass icon is a signifier of search functionality, but have not yet made similar connections with the hamburger icon for menu or site navigation functionality. Same goes for the map-marker (tear drop shaped) icon that is used on Google Maps. Interesting stuff (if you're a UX nerd like me)! All of this may change in the next couple years though as exposure to these icons may be increasing. I think the biggest point of influence will be our mobile devices. Nowadays, we come in contact with Android or iOS interfaces even more than our desktop options. The more these icons are used, the more we'll adapt to them although possibly at the expense of some user frustration. Question is: is the hamburger worth it?

Back when I was a Business Analyst, I had run the gamut with requirements gathering. I lost count of the number of times when spec meetings for web projects would make me want to pull my hair out. Part of that is due to who your stakeholders or subject matter experts are, but despite this, many headaches can be remedied by implementing a more structured approach to gathering specs. My biggest headaches often came when determining UI requirements. At my last company, there was a heavy reliance on high fidelity mock ups in full colour with real images and realistic UI elements. This was a "home run" approach to requirements gathering - trying to determine layout, interactions, colours and everything else in one go. This drove me nutssssss.

Enter: wireframes! Wireframes are great for "phasing" design decisions and working down from broad requirements to more precise ones. Using wireframes or prototypes greatly improved my quality of life as a BA and I'm really glad this was introduced into our workflow at HackerYou this week.

We started off the bootcamp entirely with a code focus in order to get us ramped us as quickly as possible and to reinforce good habits. This was great and I've learned more than ever, but I often found myself stalling on the weekly projects. Why? Because I was using the home-run approach! I was trying to design everything in the browser all at once and it was way too much. I forgot all about wireframes and phasing out the design process into stages.

Our design-focused week has been good reminder of techniques and tools to simplify the design process. Going forward I will try to follow these general stages when taking on a new project:

Create a lo-fidelity prototype (sketched wireframes). This will roughly determine the layout and where content will reside.

Create a medium-fidelity prototype (boilerplate wireframe). Taking the proof of concept one step further and also determining how the layout will be responsive.

Create a style guide (hardest part!!!).

For my week 2 project, I decided delve into some jQuery because it's just so much fun to add some cool affects to nav and scrolling functionality.

I haven't gone too crazy (yet), but so far I've used sticky.js, smooth scroll and a bit of Parallax to get my nav and background to do some cool things.

I have a good excuse though: week 1 was just too awesome :) Week 1 of what you ask? Well, HackerYou's front-end development bootcamp that's what! I should have started blogging earlier, but there were too many big changes. Leaving my job, moving, getting ready for the course, but now I come with both perspective and excitement in my blogging as I've gone through an immense first week in the course.

Web development was always an interest and hobby of mine, but for reasons I've yet to fully understand, my career path veered onto a somewhat unsatisfying parallel path (I was a Business Analyst). Long story short, I learned a lot, realized some stuff and said to myself "Hey, let's give this 'doing what you love' stuff a real shot eh?"

Fast forward to HackerYou, I am really loving everything we''ve been learning thus far (Jared has caught me yawning too many times, but I assure you that it is only because I've been mind-blasted with far too much awesome stuff and my consciousness just can't keep up). HTML5, CSS3 plus a bit of responsive design has been covered so far and I've had too many "Damn that's awesome!" moments to count. One of my biggest learning goals coming into the course was figure out the "right" ways to do things and I've certainly had to break some bad habits in a short period of time. So enough rambling and onto some lists (because lists are awesome) of noteworthy (rambly) things after 6 days in the course.

Things I've Learned:

The Box Model is a Box Full of Crap. Border-box is the truth. In my personal forays into learning CSS, the box model has always been a source of blood-boiling frustration. It made no logical sense to me how it worked and I did toil with it long enough to understand how the properties relate together, but boy am I glad for border-box. So fricken glad. Why I never came across this in the various tutorials I used is beyond me. Which brings me to my next point... Resourcefulness is a superpower all devs must possess and harness. Googling! I was once told by a manager in my early career that I shouldn't Google things I didn't know how to do in Excel and that I should just know it, do it and not waste time. This manager sounds like a crazy person and they pretty much were, but so far I've seen that the dev world embraces resourcefulness in way that I can very much appreciate. I can't remember if it was Brenna or Wes that said it, but basically the dev world feeds off of people learning from the work of others. Being open about what you know and don't know is really key and being able to figure out what you don't know by referencing the masses of amazing work/knowledge out there is also (super) key. Repeat yourself? NEIN!!! Sure, not an absolute rule, but I wish Emmet had a counter on saved keystrokes. Coding in the past has always been a repetitive task chock full of human error for me. I loved coding, but it drove me nuts having to repeat stuff over and over. Emmet has changed all that. Thank you HackerYou for exposing me to Emmet. Efficiency is something I can really appreciate. Wes did a calculation today and it a stupid number of hours (something like 16 hours?) we would be saving from using Emmet snippets/shortcuts instead of typing out a particular small piece of commonly used code. My next goal is working on the efficiency of my CSS selectors because oftentimes I take a longer path to selecting my target element than necessary.

I can't believe one full week is already in the books. Time is FLYING by and I am learning a TON.

Our week 1 project (one page website of your choice) was completed this weekend as well and I must say, everyone did some awesome work. I wasn't lying when I said that every project had something I could learn from - whether it be technical/functional, design-related or a resource that someone used. Some super talented people in this cohort and I hope to learn a lot from them. The biggest challenge I had was making design decisions. I spent way too much time fiddling with layouts and changing my mind, but I have a better idea of how my mental process should work now. I will get my site online in the next couple of days and will post a link.

Until then.