Tech Roots » CSS/HTML/JavaScript http://blogs.ancestry.com/techroots Ancestry.com Tech Roots Blogs Tue, 21 Apr 2015 00:10:15 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.2 Stop using anchors as buttons!http://blogs.ancestry.com/techroots/buttons-vs-anchors/ http://blogs.ancestry.com/techroots/buttons-vs-anchors/#comments Tue, 02 Sep 2014 21:21:12 +0000 Jason Boyer http://blogs.ancestry.com/techroots/?p=2700 Semantic buttons and links are important for usability as well as accessibility. Hyperlinks indicate a URL change, whereas buttons are used to perform an action. I thought this post up in response to a question asked on Stack Overflow over 5 years ago. Which one should you use? <a href="#" onclick="doSomething()">Do Something</a> <a href="javascript:void(0);" onclick="doSomething()">Do… Read more

The post Stop using anchors as buttons! appeared first on Tech Roots.

]]>
Semantic buttons and links are important for usability as well as accessibility. Hyperlinks indicate a URL change, whereas buttons are used to perform an action. I thought this post up in response to a question asked on Stack Overflow over 5 years ago.

Which one should you use?

  1. <a href="#" onclick="doSomething()">Do Something</a>
  2. <a href="javascript:void(0);" onclick="doSomething()">Do Something</a>
  3. <a href="javascript:doSomething()">Do Something</a>
  4. <a href="" ng-click="app.doSomething()">Do Something</a>

Answer: None of those!

All elements in HTML (except for <div> and <span>) have a semantic meaning. This semantic meaning is interpreted by browsers, screen readers, and SEO crawlers. Browsers use this semantic value to properly display the elements and to bind interactions. Screen readers also use this semantic value to bind additional different keyboard shortcuts and interactions. Lastly, SEO crawlers use this meaning to measure importance of content and define relationships.

The above examples are using the <a> element to solely perform a JavaScript action. This is incorrect, as the semantic meaning of an <a> element as defined by the W3C is as follows:

The <a> element represents a hyperlink.

A hyperlink is “a link from a hypertext file or document to another location or file.1“. Since those examples are not linking to another location, they are incorrect.

So what is the correct element to use when its sole purpose is to perform a JS action? That would be the <button> element.

The <button> element with a type attribute whose value is "button" represents a button with no additional semantics.

I feel that this documentation could be slightly improved to imply that a “button” means the element should be “clickable” or “interactive.” Applying these definitions, the correct answer would be marked up like so:

<button type="button" onclick="doSomething()">Do Something</button>

Semantic buttons provide a cross-browser focusable area and indicate an interaction is expected. If you read no further than this, please only use an <a> element if you can answer yes to this question:

1. Does the element change the URL?

If it does not, please use the <button> element. Now for some further explanations:


Why is it so commonplace to use the <a> element to perform JS actions?

The <a> provides some key benefits:

  1. It is styleable.
  2. It is focusable (you could tab to it)
  3. It provides cross-browser support for :hover, :active, & :focus states

Way back in the day, the <button> element only provided the latter two benefits. It was impossible to style it consistently cross-browser (just think of trying to style some of the new HTML5 inputs cross-browser). This has long been remedied. At Ancestry, we created a generic “.link” class to style a <button> exactly like a text link, when needed. This allows us to use the proper HTML markup and retain control of the appearance. The CSS is similar to this:

.link { -webkit-appearance:none; background:none; border:0; -webkit-box-shadow:none; box-shadow:none; color:#03678B; cursor:pointer; display:inline; font-size:inherit; margin:0; padding:0; text-align:left; text-decoration:none; }
.link:active,
.link:hover,
.link:focus { color:#03678B; text-decoration:underline; }

This resets the styles for all our supported browsers and gave us the flexibility we needed in the markup to use the proper <button> element rather than the <a>.

One note about using the <button> element – Don’t leave off the [type="button"] attribute. The default type of a button in most browsers is a submit. This means without the [type="button"] attribute/value pair, users could accidentally submit a form.


What about using the <a> as a named target?

Hyperlinks can link to sections of content in a document, as well as external links. Again, way back in the day, markup like <a name="myRegion"></a> was the only cross-browser way to link to a section on the page. All modern browsers (even back to at least IE7) allow you to link to any section that has the id attribute.

Old way:

<a href="#my-section">Go to my section</a>
...Content...
<a name="my-section"></a>
<div>My section content</div>

Better way:

<a href="#my-section">Go to my section</a>
...Content...
<div id="my-section">My section content</div>

Simply use an id attribute on the containing element of the region you want “linkable.” Don’t use an empty <a name="my-section"></a> element.


Are there any reasons you would bind a JS action to an <a>?

Of course! A common one is a hyperlink that also fires off a tracking pixel. Something like the following:

<a href="http://www.ancestry.com" onclick="fireTracking('clicked home link');">Home</a>

In the case of single page apps, you definitely need to prevent the browser from navigating away from your page, but you should still use an <a> element since the result would be changing the URL. For example:

<script>
function doPushStateStuff(newPage) {
	// pushState magic here
	return false
}</script>
...
<a href="page-2" onclick="doPushStateStuff('page-2');">Page 2</a>

This actually brings up the other key rule for <a> elements:

  1. Users should always be able to open links in a new tab (middle-click or right-click to select “open link in new tab”)

I loathe single page apps that do not allow opening pages in a new tab. It’s a huge usability issue as it prevents users from using your site in their normal routine.


In summary:

  1. Semantic buttons (<button type="button">) should be used when an element’s sole purpose is to perform a JavaScript action.
  2. <a> elements should only be used when changing the page URL and should always be openable in a new tab.
  3. You should never write html like this: <a href="#" onclick="doSomething()">Do Something</a> or this <a href="javascript:void(0);" onclick="doSomething()">Do Something</a>

Note: Use Unobtrusive JavaScript rather than onclick attributes. They simply shortened the examples.

The post Stop using anchors as buttons! appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/buttons-vs-anchors/feed/ 0
Core Web Accessibility Guidelineshttp://blogs.ancestry.com/techroots/core-web-accessibility-guidelines/ http://blogs.ancestry.com/techroots/core-web-accessibility-guidelines/#comments Wed, 13 Aug 2014 22:08:39 +0000 Jason Boyer http://blogs.ancestry.com/techroots/?p=2655 How do you ensure accessibility on a website that is worked on by several hundred web developers? That is the question we are continually asking ourselves and have made great steps towards answering. The approach we took was to document our core guidelines and deliver presentations and trainings to all involved. This included our small… Read more

The post Core Web Accessibility Guidelines appeared first on Tech Roots.

]]>
How do you ensure accessibility on a website that is worked on by several hundred web developers?

That is the question we are continually asking ourselves and have made great steps towards answering. The approach we took was to document our core guidelines and deliver presentations and trainings to all involved. This included our small team of dedicated front-end web developers but also the dozens of back-end developer teams that also work within the front-end. This article will be the first in a series going in-depth on a variety of web accessibility practices.

Our following core guidelines, though encompassing hundreds of specific rules, have helped focus our accessibility efforts.

A website should:

  • Be Built on Semantic HTML
  • Be Keyboard Accessible
  • Utilize HTML5 Landmarks and ARIA Attributes
  • Provide Sufficient Contrast

Our internal documentation goes into detail as to why these guidelines are important and how to fulfill each requirement. For example, semantic HTML is important because it allows screen readers and browsers to properly interpret your page and helps with keyboard accessibility. Landmarks are important for they allows users with screen readers to navigate over blocks of content. Contrast is important because people need to be able to see your content!

Do our current pages meet all of these requirements? Nope. That’s why we’ve documented them so that we can provide structure to this effort and have measurable levels of success.

We have been learning a lot about accessibility during the past few months. The breadth of this topic is amazing. Lots of good people in the web community have made tremendous efforts in helping others learn. W3C’s Web Accessibility Initiative documentation and WebAIM’s explanations are definitely worth the time to study.

In my following posts, I will outline many of the rules with practical examples for each of our core guidelines. Some of the items that I’ll describe are:

  • Benefits of Semantic HTML
    Should all form elements be wrapped in a form element? Do I need to use the role attribute on HTML5 semantic elements? How do decide between these: <a> elements vs <button> elements, input[type="number"] vs input[type="text"], <img> elements vs CSS backgrounds, and more.
  • Keyboard Accessibility 101
    Should I ever use [tabindex]? Why/when? How should you handle showing hidden or dynamically loaded content? Should the focus be moved to popup menus?
  • HTML5 Landmarks
    Why I wish landmarks were available outside of screen reader software. Which landmarks should I use? How do I properly label them?

Web accessibility is the reason semantic HTML exists. Take the time to learn how to make your HTML, CSS, and JavaScript accessible. If you’re going to take the time to create an HTML page, may as well do it correctly.

The post Core Web Accessibility Guidelines appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/core-web-accessibility-guidelines/feed/ 0
Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Communityhttp://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/ http://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/#comments Thu, 20 Mar 2014 18:27:12 +0000 Mitchell Harris http://blogs.ancestry.com/techroots/?p=2099 Utah Code Camp 2014 came and went this weekend. More than 850 people attended and with more than 70 sessions, it was the largest code camp in Utah history. Thanks to Pat, Craig, Nate, and Kerry  of Utah Geek Events for putting it all on. Ancestry.com participated in a pretty big way. In addition to the… Read more

The post Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Community appeared first on Tech Roots.

]]>
Utah Code Camp 2014 came and went this weekend. More than 850 people attended and with more than 70 sessions, it was the largest code camp in Utah history. Thanks to Pat, Craig, Nate, and Kerry  of Utah Geek Events for putting it all on.

Ancestry.com participated in a pretty big way. In addition to the many Ancestry.com employees in attendance, we had three speak.  Bressain Dinkelman presented a session titled, “Yes, You Belong Here,” about the Imposter Syndrome in the tech world, and how to overcome it. Craig Peterson presented a session titled, “High Performance Web Services with Apache Thrift.” I presented a session called, “Making Your Own Domain Specific Language,” and also was called in last minute pinch to  hit speak on RavenDB for a presenter that got pneumonia.

WP_20140320_001

 

In addition to employees attending and speaking at the event, Ancestry.com also sponsored the event. Did you find our spot next to the elevators on the first floor? We were handing out T-Shirts, hand sanitizer, pens, candy, and evangelizing how great it is to work here.  We’re proud to be a sponsors to of Utah Code Camp, and hope for another great camp next year.

The post Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Community appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/feed/ 0
Video Q&A with Lead Engineer at Ancestry.comhttp://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/ http://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/#comments Fri, 21 Feb 2014 01:14:53 +0000 Melissa Garrett http://blogs.ancestry.com/techroots/?p=1974 Jeremy Pollack, a lead engineer at Ancestry.com, answers questions on the technical backend of AncestryDNA in a video interview with InfoQ. The interview took place after his presentation with Bill Yetman on scaling AncestryDNA using Hadoop and HBase at QConSF in 2013. Check it out!

The post Video Q&A with Lead Engineer at Ancestry.com appeared first on Tech Roots.

]]>
Jeremy Pollack, a lead engineer at Ancestry.com, answers questions on the technical backend of AncestryDNA in a video interview with InfoQ. The interview took place after his presentation with Bill Yetman on scaling AncestryDNA using Hadoop and HBase at QConSF in 2013. Check it out!

Jeremy P

The post Video Q&A with Lead Engineer at Ancestry.com appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/feed/ 0
Creating a Completely Accessible Navigation Bar in HTML, CSS, and JShttp://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/ http://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/#comments Mon, 27 Jan 2014 10:30:20 +0000 Jason Boyer http://blogs.ancestry.com/techroots/?p=1859 Recently, I volunteered to prototype a new global navigation bar for the core Ancestry.com website. This was a huge opportunity for some drastically needed improvements, not only for the code behind the header, but more importantly, the accessibility of the navigational items. Even though we’re early on in this process of creating an accessible navigation… Read more

The post Creating a Completely Accessible Navigation Bar in HTML, CSS, and JS appeared first on Tech Roots.

]]>
Recently, I volunteered to prototype a new global navigation bar for the core Ancestry.com website. This was a huge opportunity for some drastically needed improvements, not only for the code behind the header, but more importantly, the accessibility of the navigational items. Even though we’re early on in this process of creating an accessible navigation bar in HTML, CSS, and JS, I wanted to share some of our goals and challenges and gather any additional insight others may have to offer.


True or False?
Accessibility is only relevant to projects designed for the blind.


False! So false. This is actually one of the most common misconceptions that I’ve come across with new web developers. Accessibility means ensuring that all users are able to experience your product in a way that works for them.

The main navigation bar on a website is one of the most important areas that needs to be accessible. If users can’t navigate your site, guess what – they are not going to use it! In order to cater to your users, you have to know who your users are. Our users at Ancestry.com vary greatly by age and technical skill. After digesting our user stats, we focused in on four key areas of accessibility:

  1. Keyboard accessible navigation – Keyboard accessible navigation is crazy helpful for people with dexterity issues. Moving and clicking a mouse on a tiny 16×16 pixel icon can prove to be very difficult. This also helps our power users that want to improve their workflow by navigating with access keys.
  2. Touch device capable – More and more of our users visit the site through touch enabled devices, including phones, tablets, and even desktop computers. Unbeknownst to many developers though, if you have dropdown menus that are triggered by hovering over an anchor element, many users will never be able to access those secondary menu items.
  3. Mobile users with smaller screens – Given that most mobile devices are touch-enabled, this is still a different group of people due to the screen resolution. A surprising amount of our users (growing daily) are now navigating on devices with screens smaller than 768 pixels wide.
  4. Assistive technology friendly – Users with sight disabilities rely on screen readers and other assistive technologies. We strive to keep this in mind when building pages, but honestly, our current support of assistive technologies is quite low. We’d love to improve this effort, starting with this new header.

Of course there are other reasons for updating our current header (such as code cleanup, standardizing styles, performance improvements, easier access to most visited pages, better use of screen width, and overall simplification), but I’m going to focus on how we’re trying to improve the four points above.

Before we dive into the details for each of the four areas, take a look at the two different variations:


Keyboard Accessible Navigation

If you try to navigate the current Ancestry.com header through key presses, you’ll quickly notice that you cannot access the submenus, which contain some of our most visited links. This newer version had to fix this.

Task #1 was to make sure that someone could use the “tab” key to make it through the entire list of navigation links. Initially, this wasn’t all that difficult. I only had to make sure the markup was semantic, in the correct order, and no autofocusing-elements on page load. Then, thankfully, most web browsers do a decent job taking you from one link to the next.

The challenge came when we added in the drop down menus. They are handled by a global “callout” widget that moves the contents of the callout into a new element that is a direct child of the element. This is done to avoid any possibility of z-indexing issues that we had dealt with previously. However, in this case, it complicated the task of being able to tab to each navigational link since the DOM structure is changed when the callout opens. We got around this by adding custom keyup events detecting the arrow and bracket keys. This actually created an additional benefit of being able to more quickly focus on the link that you needed (instead of pushing tab fifteen times, you can now push it four times and then push the down arrow once). So even though our goal was to be able to tab all the way through, we feel the solution we’ve found with the arrow or bracket keys is even better.

Task #2 was to make it even easier to jump to the most used pages (such as a user’s tree, Search, DNA, etc.) through the use of access keys. Web access keys are shortcut keys to certain pages or parts of a page.

The challenge with access keys is that all software programs like shortcut keys! This causes lots and lots of potential conflicts. The best recommendation for access keys that I’ve found was from the UK government, albeit over 11 years old. On a side note, here is an awesome read about access keys and keyboard accessibility article by WebAim.

Other than the letter “S” for skipping navigation, they recommend using numbers for your main links. Our main links are different than theirs, so this represents our current implementation on the new header:

  • alt + s   Skip navigation
  • alt + 1   Home
  • alt + 2   User’s tree
  • alt + 3   Search
  • alt + 4   DNA
  • alt + 5   Resources
  • alt + 6   Shop
  • alt + 7   Quick Lookup
  • alt + 8   Messages
  • alt + 9   Hints
  • alt + 0   Account

In order to make our users aware that these access keys exist, we would simply put a hidden link at the end of the page that is shown on focus. Users who navigate with the keyboard would be able to find our access key definitions page.


Touch Device Capable

If you visited our site a year ago on an Android or Windows touch device, you could not access the submenus in the main navigation bar. Those devices trigger the hover and click event at the same time, rendering submenus shown by hover as completely useless. The hover would occur, instantly followed by the click, which closed the hover dropdown, and then proceeded to the clicked link. A simplified version of the markup was like the following:

<div class="linkWithDropdown">
	<a href="/a/"">Place A</a>
	<ul class="dropdown">
		<li><a href="/b/">Place B</a></li>
		<li><a href="/c/">Place C</a></li>
		<li><a href="/d/">Place D</a></li>
	</ul>
</div>

And the relevant CSS like so:

.dropdown { display:none; }
.linkWithDropdown:hover .dropdown { display:block; }

iOS devices did not have the same issue as they required a tap to trigger the hover (which opened the menu) and another tap to trigger the click event. This behavior was actually fortunate for this current scenario but causes issue in other use cases.

Our fix for this case was to remove all CSS hover styles applied to those elements on touch-enabled devices. This made the first finger tap on all devices trigger the click event. We then stopped the event from changing the page, stored a flag marking that it was open, and then listened for the next finger tap. On the second finger tap, it would then fire the click event again and allow you to go to that page. Basically, we disabled the iOS device tap behavior, made it consistent with Android, then added custom code to mimic the disable iOS behavior, but in a cross-device-compatible-sort-of-way.


Mobile Users with Smaller Screens

Ancestry.com was first built as a desktop experience, assuming a browser with a screen width of 1024 pixels. This was true for the large majority of our users 10 years ago, but is far from accurate today as more and more people are visiting our site from mobile devices. These smaller devices, such as the iPhone, are capable of rendering a desktop experience on their tiny little screen, but result in a far from optimal experience. Enter responsive web design (RWD).

The main goal of RWD is to display the same information to a user, no matter what device they’re on, in the easiest to use format possible. When it comes to navigation, it’s a poor experience to try and click on a tiny, zoomed-out, 10×8 pixel link to get to a page. In my opinion, (formed from many others’ research) links on touch devices should never be smaller than 44×44 pixels. This makes clickable areas much easier to tap. RWD has now been a hot priority at Ancestry.com for well over a year now. We’ve made huge leaps forward, and this new header is no exception. It is fully responsive, meaning it has a fluid layout and adapts its visual layout according to the screen width that is available to it.


Assistive Technology Friendly

This category covers those who use screen readers, screen magnifiers, and other assistive software. Even though this is currently a miniscule amount of our users, I see it as a high priority item. I come from an educational background, where the fact that all people deserve an equal right to learn was engrained into me. The desire to meet this goal has transitioned nicely to the frontend web development role that I’m now in to help all people access the content that a website delivers.

Semantic HTML5 markup is now used to assist in proper categorization of DOM elements. The new header uses the <nav> element as its outer wrapper, <a> elements only when changing a URL, and <button> elements for performing javascript actions. Here is the basic markup of the new header:

<nav class="nav" id="nav">
	<a accesskey="2" href="/tree/boyer/">Boyer Family Tree</a>
	<ul class="navSubMenu" id="navTrees">
		<li><a href="/tree/boyer/">Boyer Family Tree</a></li>
		<li><a href="/tree/nielson/">Nielson REAL Family Tree</a></li>
		<li><a href="/tree/start/">Start a tree</a></li>
	</ul>
	<a accesskey="3" href="/search/" id="navSearchTrigger">Search</a>
	<ul class="navSubMenu" id="navSearch">
		<li><a href="/search/">Search All Records</a></li>
		<li><a href="/search/census/">Census & Voter Lists</a></li>
		<li><a href="/search/birth/">Birth, Marriage & Death</a></li>
	</ul>
</nav>

Top-level links are direct children of the <nav> element. Submenus are visually hidden by default, but still available to be read by screen readers. Many callout and tab plugins hide content with CSS via the display property. This can be bad for accessibility as there may not be a way for people using screen readers to find that hidden information. That’s why, rather than setting the display property on those submenu <ul> elements, we use the following CSS:

.navSubMenu,
.screenReaderText  { height:1px; line-height:2em; margin:-1px; opacity:0; overflow:hidden; pointer-events:none; position:absolute; width:1px; }

Another best practice is to provide users a way to skip the navigation. This is done by placing this HTML as the first item in the <nav> element:
Skip Ancestry.com navigation

Our header is included in a lot of different locations, following several different page layout patterns. We cannot assume that our main content is wrapped by an element with the ID of “skipped-nav,” so we add one directly after the main <nav> element. It’d be better to just wrap your main content with a unique ID, but that wasn’t a plausible solution for us. Relevant HTML:

<div id="skipped-nav"></div>

Keep in mind that there are some issues with “skip to content” links in Chrome and Internet Explorer, causing it to fail to focus on the “skipped-nav” element after the navigation. There is a JS workaround for this issue shown in the demo (go here and search for the function “fixSkipLink”).

We have learned a lot during this effort and feel we are getting closer to releasing this responsive, accessible, awesome, new global navigation bar, but we are still very much open for feedback. Since we built it as a Google Chrome plugin – you can try it yourself. If you’re not in Chrome, open it. If you’re in IE, I’m sorry.

Become a power-user and try only using your keyboard to navigate. I think alt+7 will be a favorite shortcut for a lot of users. Please keep in mind that the plugin is a prototype, so there are some bugs in it. Once you’ve played with it for a while, please complete this super short survey to let us know what you think. Since we’re involving users and others early on in the process, we are still very open to suggestions.

The post Creating a Completely Accessible Navigation Bar in HTML, CSS, and JS appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/feed/ 0
API Performance Monitorhttp://blogs.ancestry.com/techroots/performance-and-stability-dashboard/ http://blogs.ancestry.com/techroots/performance-and-stability-dashboard/#comments Wed, 15 Jan 2014 07:00:37 +0000 Anders http://blogs.ancestry.com/techroots/?p=1415 My team has been tasked with providing a dashboard for some of our product teams that enables them to aggregate various monitoring systems, logs, metrics, and other forensic tools into one place. While provisioning this dashboard, we discovered we needed a tool that could hit an endpoint, run code against the response, record the results, and… Read more

The post API Performance Monitor appeared first on Tech Roots.

]]>
My team has been tasked with providing a dashboard for some of our product teams that enables them to aggregate various monitoring systems, logs, metrics, and other forensic tools into one place.

While provisioning this dashboard, we discovered we needed a tool that could hit an endpoint, run code against the response, record the results, and do it all on a scheduled basis.

I was assigned to build this tool, which, thanks to modern technologies, only took a couple of days and is now a simple, lightweight node.js server.

One passes in a request object (with the url, method, headers, url parameters, etc.), an interval (e.g. 30000 ms), and a script to run against the response.  The server schedules the task with the interval given, performs the request, compiles and runs the script against the response, and records the results in SQL Server.

We inserted a dozen or so scheduled tasks, and it has been executing flawlessly for the last two weeks.

For example, here is a graph of the response time of one of our servers over the last hour:

Image 2

At some point, a response time of over 800 ms was recorded.  Sometimes a request can just take a long time and there can be a lot of reasons for it – but if it only happened once, it’s usually not worth taking the time to triage.  It is, however, at least worth checking to see if it did only happen once, so here’s a full week:

Image 3

There are spikes of ~150ms, but nothing anywhere close to a full second. It appears to be an isolated incident, so we’ll chalk it up to gremlins and move on.

With this tool available to us, it’s simple to track response times, uptime, downtime, errors, and anything else we deem interesting.

Tools like these save us a lot of time by keeping an eye on things while we’re busy with other priorities, freeing us up to work on adding new features, polishing existing functionality, and removing bugs from the code base.

The post API Performance Monitor appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/performance-and-stability-dashboard/feed/ 1
Open Source Developmenthttp://blogs.ancestry.com/techroots/open-source-development/ http://blogs.ancestry.com/techroots/open-source-development/#comments Tue, 26 Nov 2013 09:27:23 +0000 Liam Molloy http://blogs.ancestry.com/techroots/?p=1568 At Ancestry.com, we have many developers whom contribute to open source projects. Today I want to talk about an open source project I have been involved in, along with one of my team members Shane Burke. As contributing to open source projects is not directly related to the day to day development work at Ancestry,… Read more

The post Open Source Development appeared first on Tech Roots.

]]>
At Ancestry.com, we have many developers whom contribute to open source projects. Today I want to talk about an open source project I have been involved in, along with one of my team members Shane Burke. As contributing to open source projects is not directly related to the day to day development work at Ancestry, it provides an opportunity to give back to the community and allows developers to think outside the box, as well as contribute to something they are passionate about. Both Shane and I work on this project in our spare time.

FooBar football is an opensource collectable card game (CCG) based upon football. It is inspired by Magic The Gathering, Football Manager, FIFA Ultimate team, Match Atax and a host of other games.

Over the next few months, I plan to write a series on what the game is and how it is being implemented. Here is a quick overview:

  • GitHub used for version control
  • AppHarbor used for hosting
  • C# used for match engine development
  • Angular JS used for client development

GitHub

For version control, we use GitHub. GitHub is a web-based hosting service for software development projects that use the Git revision control system. GitHub offers free accounts for open source projects. In our day-to-day environment Shane and I use Microsoft’s team foundation server for version control so contributing to this project has allowed us to learn something new.

You can check out the current state of the project on our GitHub page:

FooBar football project on GitHub.

FooBar football project on GitHub.

Player card screen

Player card screen

Move simulator screen

Move simulator screen

 

The post Open Source Development appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/open-source-development/feed/ 0
CSS Woeshttp://blogs.ancestry.com/techroots/css-woes/ http://blogs.ancestry.com/techroots/css-woes/#comments Tue, 20 Aug 2013 08:00:03 +0000 Anders http://blogs.ancestry.com/techroots/?p=979 I’m not a Front End Developer, but I often find myself writing, tweaking and adjusting style-sheets to make a particular element look just right, fix layout bugs and deal with cross-browser issues. Most often I will find someone else that has already done what I want to do and look at how they’ve styled a given… Read more

The post CSS Woes appeared first on Tech Roots.

]]>
I’m not a Front End Developer, but I often find myself writing, tweaking and adjusting style-sheets to make a particular element look just right, fix layout bugs and deal with cross-browser issues.

Most often I will find someone else that has already done what I want to do and look at how they’ve styled a given element.

This is hard because for any given element there are hundreds of computed styles, so finding the crucial style differences between the element I’m styling and the element I want it to look like, is a little like finding a needle in a haystack (particularly for someone who isn’t a CSS wizard).

Thus, I wrote a tool to point out the differences for me: http://elementcomparer.aws.af.cm/

As an [overly-obvious] example, if I was working on the front page of Ancestry.com, and couldn’t figure out how to make a couple of buttons look the same, I would click on:

Image 004

And then click on:

Image 005

And inspect the differences:

Image 006

In this case, I can tell that I just need to add a few classes to the first element, let’s try ‘orange’ and ‘lrg’:

Image 007

Problem solved. I wish it was always as easy as just adjusting a couple of classes…

Clearly, this is a contrived example, but I use it all the time for more complex styling issues, and I’ve passed the tool along to my front-end developer friends here. I can only imagine the complex CSS styling issues they have to deal with.

There are likely bugs and browsers the tool doesn’t work in yet, but please give it a try and leave some feedback below.

The post CSS Woes appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/css-woes/feed/ 0
Hiring: First Test Then Assesshttp://blogs.ancestry.com/techroots/test-then-assess/ http://blogs.ancestry.com/techroots/test-then-assess/#comments Thu, 25 Jul 2013 19:50:54 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=927 Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the… Read more

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the onsite interview to complete coding tests, it’s worked best for us to email our assessment to potential candidates and allow them to complete and return it on their own time frame before scheduling an interview. This helps avoid wasting everyone’s time by bringing in people who aren’t qualified to handle the technical requirements of the position.

Our assessment test provides candidates with a layered .PSD (PhotoShop) file, as well as a simple list of requirements to consider:

  • Pixel-perfect quality level (Mac and Windows)
  • All text to be real text
  • Optimize page and improve performance where possible
  • No inline styles unless absolutely necessary
  • All containers must be vertically expandable
  • Cross browser compatibility
  • Utilize latest technologies (CSS3, HTML5, responsive design, etc.)

pixel_perfect

An experienced developer should be able to code the page in a few hours, which is enough of a time commitment to filter out those that aren’t truly interested in the job. The page also contains a wide variety of front-end challenges including a modal overlay, a form, multiple images, customized buttons, unordered lists, and overlapping elements. We can compare the code structure, CSS styling, and choice of JavaScript frameworks used in meeting the assessment’s requirements, which allows us to evaluate each candidate on a level playing field prior to scheduling an interview. We can also look at how they optimized their code to consider performance, requests, and load time of the page.

Our team reviews the tests and gives each assessment an overall rating from 1 to 10, with candidates scoring a 7 or better being considered worthy of an interview. That way, we’re only meeting with the best of the best and can more easily make a decision on who would be the best fit for the position and team. In addition, the assessment serves as a talking point during the interview, allowing the candidates to walk us through their thought process and providing us a chance to ask questions and give feedback about the coding choices they made.

In the end, when candidates are given a coding test comes down to personal preference and what works best for you and your team. Some might prefer to meet candidates first, then assess their technical skills to see if they can do the job. For our team, finding out whether they can do the job before ever meeting them in person has proven successful and allowed us to assemble a talented group of 18 front-end developers in just a few short years. If you’re interested in potentially being one of them, check out all of our current job openings at Ancestry.

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/test-then-assess/feed/ 0
Make your next UI library with an HTML APIhttp://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/ http://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/#comments Wed, 19 Jun 2013 22:36:09 +0000 Mitchell Harris http://blogs.ancestry.com/techroots/?p=683 Things are changing in the front end web world. Among those changes are HTML APIs.  Here’s the problem. You’ve made a webby-UI widget that is really cool. It’s so cool, that other people want to re-use it. How do you expose your widget so that other people can use it? In the old world, you… Read more

The post Make your next UI library with an HTML API appeared first on Tech Roots.

]]>
Things are changing in the front end web world. Among those changes are HTML APIs.  Here’s the problem. You’ve made a webby-UI widget that is really cool. It’s so cool, that other people want to re-use it. How do you expose your widget so that other people can use it? In the old world, you provided a Javascript API that clients would call, passing in the element. See jquery-ui, code mirror, or anything using Backbone or written as a jQuery plugin. For one or two UI widgets, we tolerate it. But if your page uses a lot of UI widgets, it’s misery. Backbone style misery.  The problem here is that view is being described in Javascript rather than HTML.  If you don’t think that’s extremely hard work, imagine generating ALL of your html using document.createElement.

 

The new world is better. It uses HTML APIs in the HTML itself. For example, Radian, which is powered by AngularJS allows you to specify plots and graphs in HTML, such as:

<plot height=600 aspect=1 stroke="none" marker="circle" axis-x-label="Age" axis-y-label="Height">
<points x="[[fam.age]]" y="[[fam.height]]" fill="[[mfpal(fam.sex)]]" marker-size="[[30*sqrt(fam.salaryhr)]]">
</points>
</plot>

Simply plunk this stuff down in your html, include the right script, and AngularJS + Radian + D3 do their magic.  I’d like to see more of these. I’d like to see accordions useable using <accordion>, and a calendar using a <calendar>.
AngularJS is a fantastic start for creating HTML APIs, but it isn’t the only way. On Ancestry.com’s Surname page we use an HTML API to define the svg graphics. Enter your surname, then view the source. You’ll see two odd looking tags:

 

<div id="surname-origin" context="surname.origin" surname=Harris options='{"limit": 3, "circleSpacing": 30}'></div>
<div context="surname.choropleth" surname=Harris id="surname-choropleth"></div>

 

Why do it this way? When other teams at Ancestry.com want to use our graphics they just include the tags on the page, and our HTML does the rest.

 

The Web world is getting more declarative. Join it. The next time you write a UI visual component, make it a tag.

The post Make your next UI library with an HTML API appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/feed/ 0