About a month ago I hired a freelance front-end developer to code around twenty pages for Uncover – both marketing pages and pages behind a login. Interestingly enough, I hired this person via Twitter. While I didn’t vet him extensively – not asking for references, previous projects or code samples – we did speak on Skype for a solid hour, going over his experience and my requirements. After negotiating a budget, we got to work the very next day.

When hiring freelance front-end developers, I always have two concerns: (1) is their code going to be well-written, and (2) will they be pixel perfect when it comes to replicating the PSD files? More often than not when working with freelance front-end developers, I’ve found that you rarely find both capabilities in anyone under $80/hour. As Uncover is a bootstrapped company, I was looking to pay $40/hour for this job, knowing perfectly well that I’d be working with someone more junior at that price. My hope was that the person would produce well-written code and that I could project manage my way to pixel perfect.

As my new contract front-end developer began to deliver coded pages, it was clear that his code was up to snuff. Maybe a few small convention issues here and there, but ultimately those are matters of opinion in front-end development. The bigger issue – as I had foreseen – was that there were far too many mistakes on the pixel perfect side of the job. When I looked at these coded pages alongside our PSD files, there were obvious mistakes such as spacing issues, font sizing problems, and missing components, All easily spotted when comparing the two files side-by-side.

Having to fix the mistakes

I was working remotely with this front-end developer, so he would push changes to our GitHub repository for me to look at and review. I’d then load the pages that had been delivered side-by-side in my browser with the png file we had outputted from Photoshop. It became very clear when switching between the two where the differences were.

I would then reply to the front-end developer’s email with a list of changes that sometimes included screenshots of obvious mistakes. As I mentioned above, I anticipated some of this happening because of the low hourly fee, but not to this extent and not repeatedly. Some errors were blatant and definitely should not have been overlooked. Others were subtle but stood out when you tabbed quickly between the mockup and the completed HTML/CSS. I was hoping that I would see fewer mistakes going forward as more pages were delivered, but this wasn’t the case.

Luckily, the person I was working with was more than happy to fix things as I compiled lists of changes for each page. Even though with all said and done it wasn’t all that big a deal for me to create these lists, I would still implore all front-end developers to focus their attention on pixel perfect development. When you are being handed a PSD file that has been carefully styled and spaced, it’s your job to slice and dice it perfectly. The designer chose 30px spacing rather than 40px spacing for a reason. I shouldn’t have to go through each page with a comb to find mistakes.

How you can prevent mistakes

The biggest way to prevent mistakes as a front-end developer is to keep learning and continuing to practice. You can keep learning by taking advantage of Treehouse lessons and staying abreast with the latest conventions through following Hacker News, browsing Stackoverflow, reading Reddit and other notes on the craft.

As a person who learned to program in the past two years, I know what’s helped me the most in continuing to practice. Take any PSD files you can get your hands on and work on developing the front-end for them. One of the best lessons I received on front-end development when I was first starting out was when one of my friends gave me the PSD files of their website and I had to go through them and rebuild the HTML/CSS using Bootstrap. It was very helpful to him because his codebase was quite out-of-date and using Bootstrap would help with that; and it was very helpful for me as I got to learn while doing.

While practice will help you learn how to prevent mistakes, the best thing you can do is to review your code before handing it in. Just as writers write rough drafts and then edit them, code requires editing as well. You may have fudged something to get you by while you were getting a handle on the project, but it’s important to go back and fix things before delivering the work.

It’s not nitpicking if you want to be great

It may sound like I’m being picky, but mismatches of this kind taint the quality of the completed work. The work you do as a front-end developer is a reflection of the finished product (i.e., the pages) that you produce. Any errors or omissions reflect poorly on the job you did – even if you got 99% of the way there – and your employer will not be pleased to see anything but pixel perfect work.

Front-end developers have two responsibilities, and if you want to be great in that field then you need to care about both of them:

1. The quality of the code needs to be excellent and modular. If you code the designs so they’re not extensible, then you’re making it very difficult for other people to work from the code you’ve written. Part of programming excellent code is to be up-to-date on the new ways of doing things. Programming languages and conventions are ever-changing, and it’s important to keep up.
2. The other responsibility is to deliver back pixel perfect code in relation to the design. Anything short of that is failing to deliver great work.

I’ve worked with many front-end developers over the years – both freelance and full-time – and you can easily spot a great one based on their attention to detail, which is required for both (1) and (2) above. I’m still very happy with the front-end developer I hired and I would hire him again, but I hope he learns — and others do too — that pixel perfect front-end development matters as well as great code.

The post Pixel Perfect Front-end Development Matters appeared first on Treehouse Blog.

About a month ago I hired a freelance front-end developer to code around twenty pages for Uncover – both marketing pages and pages behind a login. Interestingly enough, I hired this person via Twitter. While I didn’t vet him extensively – not asking for references, previous projects or code samples – we did speak on Skype for a solid hour, going over his experience and my requirements. After negotiating a budget, we got to work the very next day.

When hiring freelance front-end developers, I always have two concerns: (1) is their code going to be well-written, and (2) will they be pixel perfect when it comes to replicating the PSD files? More often than not when working with freelance front-end developers, I’ve found that you rarely find both capabilities in anyone under $80/hour. As Uncover is a bootstrapped company, I was looking to pay $40/hour for this job, knowing perfectly well that I’d be working with someone more junior at that price. My hope was that the person would produce well-written code and that I could project manage my way to pixel perfect.

As my new contract front-end developer began to deliver coded pages, it was clear that his code was up to snuff. Maybe a few small convention issues here and there, but ultimately those are matters of opinion in front-end development. The bigger issue – as I had foreseen – was that there were far too many mistakes on the pixel perfect side of the job. When I looked at these coded pages alongside our PSD files, there were obvious mistakes such as spacing issues, font sizing problems, and missing components, All easily spotted when comparing the two files side-by-side.

Having to fix the mistakes

I was working remotely with this front-end developer, so he would push changes to our GitHub repository for me to look at and review. I’d then load the pages that had been delivered side-by-side in my browser with the png file we had outputted from Photoshop. It became very clear when switching between the two where the differences were.

I would then reply to the front-end developer’s email with a list of changes that sometimes included screenshots of obvious mistakes. As I mentioned above, I anticipated some of this happening because of the low hourly fee, but not to this extent and not repeatedly. Some errors were blatant and definitely should not have been overlooked. Others were subtle but stood out when you tabbed quickly between the mockup and the completed HTML/CSS. I was hoping that I would see fewer mistakes going forward as more pages were delivered, but this wasn’t the case.

Luckily, the person I was working with was more than happy to fix things as I compiled lists of changes for each page. Even though with all said and done it wasn’t all that big a deal for me to create these lists, I would still implore all front-end developers to focus their attention on pixel perfect development. When you are being handed a PSD file that has been carefully styled and spaced, it’s your job to slice and dice it perfectly. The designer chose 30px spacing rather than 40px spacing for a reason. I shouldn’t have to go through each page with a comb to find mistakes.

How you can prevent mistakes

The biggest way to prevent mistakes as a front-end developer is to keep learning and continuing to practice. You can keep learning by taking advantage of Treehouse lessons and staying abreast with the latest conventions through following Hacker News, browsing Stackoverflow, reading Reddit and other notes on the craft.

As a person who learned to program in the past two years, I know what’s helped me the most in continuing to practice. Take any PSD files you can get your hands on and work on developing the front-end for them. One of the best lessons I received on front-end development when I was first starting out was when one of my friends gave me the PSD files of their website and I had to go through them and rebuild the HTML/CSS using Bootstrap. It was very helpful to him because his codebase was quite out-of-date and using Bootstrap would help with that; and it was very helpful for me as I got to learn while doing.

While practice will help you learn how to prevent mistakes, the best thing you can do is to review your code before handing it in. Just as writers write rough drafts and then edit them, code requires editing as well. You may have fudged something to get you by while you were getting a handle on the project, but it’s important to go back and fix things before delivering the work.

It’s not nitpicking if you want to be great

It may sound like I’m being picky, but mismatches of this kind taint the quality of the completed work. The work you do as a front-end developer is a reflection of the finished product (i.e., the pages) that you produce. Any errors or omissions reflect poorly on the job you did – even if you got 99% of the way there – and your employer will not be pleased to see anything but pixel perfect work.

Front-end developers have two responsibilities, and if you want to be great in that field then you need to care about both of them:

1. The quality of the code needs to be excellent and modular. If you code the designs so they’re not extensible, then you’re making it very difficult for other people to work from the code you’ve written. Part of programming excellent code is to be up-to-date on the new ways of doing things. Programming languages and conventions are ever-changing, and it’s important to keep up.
2. The other responsibility is to deliver back pixel perfect code in relation to the design. Anything short of that is failing to deliver great work.

I’ve worked with many front-end developers over the years – both freelance and full-time – and you can easily spot a great one based on their attention to detail, which is required for both (1) and (2) above. I’m still very happy with the front-end developer I hired and I would hire him again, but I hope he learns — and others do too — that pixel perfect front-end development matters as well as great code.

The post Pixel Perfect Front-end Development Matters appeared first on Treehouse Blog.

Anchor links¹ may have a target attribute which controls what happens when that link is clicked. One of the possible values of that attribute is _blank, which tells the browser to open a new window (or tab, if that's the user's preference) when that link is clicked.

This used to be "invalid" in HTML (maybe only XHTML?) but people used it anyway since it worked. It's now perfectly valid in HTML5. But are there good reasons to do so?

A Bad Reason: Because you like it that way.

Like it or not, target="_blank" is a change in default behavior. Links opening within the same page is the default behavior (as if the link had target="_self" on it).

Perhaps you've developed a personal taste for opening all links in new windows/tabs. That's wonderful for you, but it is safe to assume most users are most comfortable with the default behavior. And thus less comfortable with your forcing of a different behavior.

If it's an internal tool just for you, do whatever you want. If other people use the site, leave it be.

It is also worth noting that users can force a link to open in a new window/tab by [Meta Key]-clicking a link. That means both behaviors are available to them for links. That also means that if you like opening new tabs, you can, and you don't have to impart that behavior on anyone else.

By using target="_blank", only that behavior is available.

A Bad Reason: Just because you want users to never leave your page.

Branding branding branding! Eyeballs baby. Metrics. ENGAGEMENT.

Other sites should have normal-style links, but our site is special. Our site is more important and should never be left behind.

A Bad Reason: "Internal" links and "External" links are different.

We'll have "internal" links (links that point to our own site) behave normally, but "external" links (links that point to other sites) open in a new window/tab.

This is related to the above two reasons, only perhaps worse. You understand that normal style links are ideal, but if that means a user leaves your site, you're willing to break that ideal.

I've heard from a lot of people that this is "a convention." As in the way it's supposed to be done. It's not.

A Bad Reason: The link is to a PDF

Or any other type of non-web resource. Why should that be so different? You can still use the back button to come back from it. If you want to help users download it without actually opening it, that's a worthy UX goal but can be approached differently. For starters, using the download attribute.

A Bad Reason: My client wants it that way

I get the "I don't want to pick this fight" thing, since we only have so much energy. But it's weird this has to be a fight at all. If they don't trust you with this, what do they trust you about?

I might approach it like this:

The default behavior is for links to open normally. There are some reasons why we might want to break that behavior, and we can go over those, but for most links we don't. We don't want to force our desires on users and potentially frustrate them for such a small thing. We want our users to feel good about us.

And hopefully your calm and educated approach will help your client feel good about you.

A Bad Reason: It's on an infinite-scroll page

Infinite scrolling is tricky. It can be good UX in one sense because it can deliver content without interruption. It can be bad UX if not handled well. Coming "back" to an infinite scroll page should take you to where you left off in most cases. Handling that tricky problem is your job. Just forcing links to open in new tabs so that problem never comes up is avoiding your job.

A Good Reason: There is user-initiated media playing

For instance: music, video, a podcast...

The user started it. Moving pages would stop it. At that point, either have links open in new tabs or ask them if they are sure they want to leave the page. At that point you are trying to do right by them and have them not leave their place.

We've covered this idea before here. If the media is playing, handle links in a special way. When the media isn't playing, links are in their normal state.

Although as I say that, I check YouTube, and they don't bug you about it² when changing videos.

A Good Reason: The user is working on something on the page, that might be lost if the current page changed.

Perhaps a user is writing something. Or arranging something. Doing any kind of work. Clicking a link and changing pages can be a heart-pounding, awful moment on the web. Did I just lose everything I was doing?

Even if you do something to ensure they don't lose that work, putting someone through that panic may as well be avoided.

I think of CodePen where users are often writing code. We do several things to help:

• Links that go to other pages that are explicitly "learn more" style links (e.g. [?]), that you only see while interacting with the editor, open in a new tab.
• Normal links (e.g. links in the footer) have normal behavior, but we detect if you have unsaved changes in the editor and prompt you to save them before you leave.
• If you do leave to another site (or your browser crashes), we save the state of the editors in localStorage so you don't lose work.

Checkout is another case here. Of course you don't want to lose customers during their checkout process. A link to something like "shipping information" should be openable without them losing their place in checkout.

"Reading an article", in my opinion, doesn't qualify here. Since it's (generally) so easy to get back to (most browsers even scroll down to where you were), there is no risk of real loss, and readers are really skimmers anyway.

A Good Reason: Some technologically obscure point

I'm building an email where people in Outlook Kangaroo 2009 Enterprise Edition need to open it but links need to have target="blank" on them otherwise they open in the sidebar viewing panel and ...

Fine.

Tech

In case you have to...

• Finding internal links
• Finding external links
• HTAccess to help with auto-downloading

Forcing user to verify they want to leave page:

window.onbeforeunload = function() {
      return "Two buttons will be below this message asking if user wants to stay on this page or leave.";
    }

Drama

I realize I've been pretty opinionated here. This is one of those topics where everyone has an opinion. Feel free to share those opinions of course but lets keep things cool and focus on situations, solutions, and data if we can.

¹ <form>s can have target="_blank" too. I would think it's a more uncommon use case, but the same type of thinking in this article would hold true.

² If you choose another video you go right to it. But in that case I wonder if that was a UX choice or an advertising choice. If you're half-way through a video, click to another video (say by accident) then click the back button right away, your place is lost. Perhaps having as little friction transitioning from video to video is important for them, but it would be nice if they offered a bit of help there. Perhaps a small arrow beneath the timeline that was like a "You've watched this video this far before" link.

When to use target=”_blank” is a post from CSS-Tricks

Anthony T. Browder  is  an author, publisher, cultural historian, artist, and an educational consultant. He is a graduate of Howard University’s College of Fine Arts and has lectured extensively throughout the United States, Africa, Caribbean, Mexico, Japan and Europe, on issues related to African and African American History and Culture.

      Mr. Browder is the founder and director of IKG Cultural Resources and has devoted 33 years researching ancient Egyptian history, science, philosophy and culture.

     He has traveled to Egypt 49 times since 1980 and is currently director of the ASA Restoration Projectwhich is funding the excavation and restoration of the 25^th dynasty tomb of Karakhamun in Luxor, Egypt. 

     Browder is the first African American to fund and coordinate an archeological dig in Egypt and has lead five archeological missions to Egypt since 2009. His archeological work in Egypt has been acknowledged by former President Mohamed Morsi, the Minister of Tourism and various Ministers of the Supreme Council of Antiquities.

    Mr. Browder’s three decades of study have lead him to the conclusion that ancient Africans were the architects of civilization and developed the rudiments of what has become the scientific, religious, and philosophical backbone of mankind. It is from this framework that IKG has concentrated its research and disseminated its findings.

      Through IKG, Mr. Browder sponsors lectures, seminars, cultural field trips of Washington, D.C., publishes his research, and has conducted study tours to Egypt, West Africa, South Africa and Mexico since 1987. He has been featured in 5 documentaries and has produced dozens of DVD’s of his numerous lectures.

      He is the author of six publications (including the best sellers, From the Browder File and Nile Valley Contributions to Civilization) and the co-author of four publications, including two written with his daughter, Atlantis Tye. 

 All of Mr. Browder’s publications, DVD’s and documentaries are currently being used in classrooms around the world.

 “Tony” describes himself as a chronicler of facts and information relative to the positive portrayal of the worldwide African experience.

From phages to phylogenies, bacteria to the biosphere, molecules to mice, and everything in between, The Helix covers current happenings in the Department of Biological Sciences at UMBC.  Initially, a new spotlight on a project in our research labs will be posted biweekly. Reports on department-sponsored seminars given by outside scientists will be posted periodically.  

Science works best when results are shared, supported, and critiqued in a community.  The goal of The Helix is to promote communication across labs, perhaps facilitating heretofore unconsidered collaborations.  A second goal is to inform those outside the department about all the amazing things happening here.  Questions and comments are strongly encouraged.  Perhaps all a research project needs is the perspective of an outsider to make its next leap forward.  

By communicating up-to-date information about projects online, there is no excuse for not knowing what's going on in the department.  Students and faculty can peruse the posts on their own time and follow up with in-house researchers and/or outside speakers if a topic sparks their interest.  

If you would like your project to be featured in The Helix, please contact me at sarah54@umbc.edu.  I will visit your lab to conduct an interview, and you will have the chance to review my report before it is posted.  I created The Helix to help the department communicate better about current research, and it will also help me reach my career goal of becoming a science writer/journalist.

Please enjoy, share with others, and contribute to the conversation!  The first reporting post should be up soon!    

--Sarah Hansen, Biological Sciences graduate student