GLBL 409 - Special Topics in Global Studies - Geopolitics

Dr. John Short (PUBL)

Wednesday, 4:30-7:00

Lecture

3 credits

Grading:  regular, no pass/fail

Cap:  20; Waitlist:  3

Description:  An introduction to the study of geopolitics and the state of contemporarygeopolitics.  Geopolitics is the study of power relations between empires and states.  It explores the meaning, contestation, construction, and maintenance of the political organization of space. The course traces the evolution of geopolitical thought from Mahan and Mackinder through Kennan and up to modern popular writers such as Robert Kaplan, who argues that a nation’s position on the world map is a primary determinant of conflict.  We will also examine an emerging critical form of geopolitics, which looks at the social construction of political spaces, exposes the material interests involved in the narratives used to explain these spaces, and explores the spatial construction of social identity.

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