To be consistent with my “what I’ve been up to” style of blogging I wanted to talk about the benefits of creating a functional test framework and what that framework might look like.

If you’re like me then you probably think that automated functional testing using Selenium is really cool. If you aren’t like me, but automated functional testing is a necessary evil in your position, then simplifying your interaction with the entire experience should be really cool. In either case, creating, employing, or utilizing a framework for your functional tests can drastically improve your testing in a way that benefits the entire team.

Computer with magnifying glass and gears

The Order to Things

A member of our team explains functional testing like this; instructions sent to a man who lives in our server, who carries out those instructions on his computer in the exact manner in which they were sent to him. This really isn’t that far off. One of my largest pain points in writing functional tests was that sometimes I would ask this unnamed guy masquerading as computer hardware to click on an element I expected to be on page, but forgot to tell him to wait for it to show up. In fact, I found that there were usually always a certain set of steps and protocols that I should always follow when performing the simplest of actions.

For a click, I need to wait until my element exist on the page, then I need to move my mouse to that element, I need to wait for it to be in a clickable state, and I need to perform the click itself. While I can easily handle this in the test itself, it probably isn’t the easiest place to manage it. Instead, I can setup this sequence as a method in a framework, and call to it in the test. This works well for a couple reasons. The first being that in my test I only need to write one line of code instead of 4. Secondly, with this action handled in the framework I never accidentally forget a step. By doing this I am making my test easier to write, easier to read and I am ensuring consistency across the scope of potential actions.

public static void Click(IWebDriver wd, By by)
                WaitActions.WaitUntilElementExist(wd, by);

                var element = wd.FindElement(by);

                FindActions.MoveToElement(wd, element);

                WaitActions.WaitUntilElementClickable(wd, element);

            catch (Exception ex)
                throw ex;

Don’t Make Me Repeat Myself

This idea of repeatable code extends beyond the steps to perform basic actions in tests. In our functional test infancy we handled most things at the test level. The framework aims to handle most of that work upfront, so the focus can shift to writing the test instructions themselves. The framework handles things like setting up the driver or Eyes for Applitools, in addition to addressing the different actions we can take in our tests.

Another measure along those lines is taking sections of the application that are tested repeatedly and moving them out of the individual tests so that they can be called upon in multiple tests when needed. When we need to update any of these sections, we can do it in one place. If a header on the site changes, we do not have to update every test that interacts with the header, but rather reference the portion of the project that handles interacting with the header.

public void CheckHeader(IWebDriver wd)
            var header = FindActions.FindVisibleElement(driver, By.ClassName("header-inner"));

            var logo = FindActions.FindVisibleElement(driver, By.CssSelector(".logo-inner img"));

            var topNavLinks = FindActions.FindVisibleElements(driver, By.CssSelector(".mobile-nav .dropdown"));

            var secondLevelLinks = FindActions.FindElements(driver, By.CssSelector(".dropdown-menu li"));

Batteries Included

Another cool feature of this framework is that it was made into a NuGet package that can be included in any projects at our company. If I want to create a new functional test solution to go with my existing webapp, I can simply pull in the package and hit the ground running. The NuGet package has all the references it needs already included. The setup of my driver and other essential classes have already been handled in the framework. I can immediately start writing tests. If I focus on the repeatable pieces of my application and create those methods in my best test, I can gain a good bit of test coverage on my application with relatively little overhead.


Simplicity for Adoption

What I hope proves to be the largest benefit of creating the framework is promoting adoption throughout the team because of its simplicity. Team members who were unfamiliar with testing, or more specifically, testing with Selenium and the nuance associated with that, will be able to test simply and reliably with little overhead. Before, we were asking a test developer to understand the finer points of Selenium and how it interacts with the browser to create effective tests. Now, creating a test should translate much more simply into what interacting with the application feels like in real world terms – find this element, click this button, type into this search bar.

Simplifying how testing is done and lowering the barrier to entry on who can create tests should allow for more testing. Troubleshooting and understanding tests should be much easier for developers that interact with the test after they have been created or product owners trying to understand what kind of coverage they have on the application.

Do Less. Get More

A functional test framework will allow your company to do less work and get more from it. The framework ensures that tests follow the required protocols with more consistency and less overhead. The framework reduces the amount of work and shortens the time required to get a test project up and running. Finally, simplicity in testing can promote adoption throughout the team, leading to more team members creating tests and ultimately more testing as a result. Having a framework in place is essential to any functional test program.

So it has been a full year since you purchased your Sitefinity license and now you aren’t sure if you should keep your subscription active. Take a look at these benefits and I am sure you will see that it is worth the investment.

Continued Sitefinity Technical Support

If you renew your subscription, your technical support package will be automatically extended for another year giving you access to a dedicated team of Sitefinity engineers with guaranteed response times.

Technical Support Representative

New Features and Improved usability

You can be among the first to explore new product releases, betas, service packs and complimentary modules. You will have a say in the product roadmap, and your feature requests will be treated with higher priority.

Product Updates and Lower Cost Support

The Sitefinity subscription is the most cost effective way to stay abreast with the latest technology. Product updates are released several times per year including new features and enhancements to the product. With the license subscription, the latest product releases will be available for download directly from your account and you will be able to upgrade your project at your convenience, thus eliminating the cost of purchasing new licenses.
Money Jar

Bug Fixes

Bugs are fixed on a weekly basis and the fixes are released usually on Fridays two to four times per month. The goal with these weekly hotfixes is to help customers and partners address important issues for specific use cases without having to wait for the next service pack or major product update. The weekly hotfix builds are available to customers who have access to the official product release that precedes.

Wrench fixing softward bugs

Discounts on additional modules

When your subscription is active you will have access to preferential upgrade terms and special discounts for other Telerik products. Customers with active subscriptions are also eligible for special services like free domain alias licenses.

The Takeaway

All Sitefinity licenses include a one-year subscription, which guarantees access to new releases, product updates including new features, bug fixes, and technical support. After the first year, the subscription renewal is the most cost-effective option to stay abreast with the latest technology and get technical support which is key to keeping your online presence fresh and effective.

The Agile development methodology was formalized in 2001 and has become the leading process for software creation. Developers love the flexibility it gives by not requiring that everything be figured out up-front. But as a client, how can you feel comfortable signing a contract without already knowing exactly what you will get?

First some background

Classic software development involves a sequential process:

  • Requirements – define the problem and solution in complete detail.
  • Design – create the blueprint to implement the requirements.
  • Construction – build the system based on the design.
  • Testing – confirm what was built works as specified in the requirements.
  • Implementation – launch!

This process is commonly referred to as “waterfall” because the output of each phase flows into the next.

Waterfall Software Development Lifecycle diagram

At first glance this seems like a very reasonable approach. The requirements represent a complete description of the work that will be provided, and serve as the contract between the client and the development company. Expectations are clear and both parties are on the same page.

Why wouldn’t we always want to do that?

The problem is that software is intangible and complex. Words on a page don’t always capture and communicate the essence of what is desired. Even a very clearly stated requirement can be interpreted and built 100 different ways, and it is likely that at least 95 of those won’t be satisfactory. The result is a well-repeated (though somewhat mythical) response from the client:

It’s just what I asked for…. But not what I wanted.

How is Agile different?

Agile was created to address shortcomings in the waterfall process that occur when developing a complex software system.

The principle difference with Agile is that it is a very iterative and interactive process. Agile projects are broken down into short mini-phases called “sprints” – At Mercury our sprints are 2 weeks. The entire requirement-design-construct-test-deploy cycle happens within each sprint. The goal is to have demonstrable results to review with our clients every sprint and get feedback.

Agile software development lifecycle illustration

Imagine with the waterfall process if a fundamental assumption was made during requirements, but during testing was proven to be false. The project is nearly complete and potentially months of work must be revisited. By doing small incremental feature development, we prove out our assumptions quickly and can change direction as needed.

Change Happens!

Change is the enemy of the waterfall project. Imagine we are building you a web application, and 80% through construction an event occurs in your business that suggests changing course would be beneficial. By now you can see the devastation this brings to the project. This ends with a difficult conversation on change requests and costs.

OK I get it… so what’s the answer?

First let me put you at ease, because by now you may be thinking where I am headed is to ask for a blank check with no understanding of where we are going.

With Agile you still need a vision. At the beginning of the project we need clear understanding of some high-level questions:

  • What problem are we trying to solve?
  • What goals do you want to achieve?
  • What approach will we use to solve your problem?
  • How will we define success?

With this framework, Mercury can define a solution by creating a set of “user stories” which describe in your language both the functionality desired and the benefit. Here is an example story related to workflow in a hypothetical cash disbursement system.

As an Employee Supervisor
I want to review pending disbursements and approve or deny them
So that I can confirm their accuracy prior to generating payment.

This statement tells us not only what you want to accomplish, but who cares about it and why. What we don’t do is try to define every single field, button, and click in the process at this point – we don’t know enough yet. Doing so is frankly a waste of your money because it is almost guaranteed to require revisiting later when we do know more.

We then take this collection of stories and estimate time and effort, which of course translates into dollars. With your approval, we will begin work towards meeting your goals with a budget to work against.

Every two weeks we review our plan and select the features that will provide you with the most value that can be delivered in the next two weeks. When complete, we demonstrate these features, get feedback from you, and then plan for the next sprint.

Agile Scrum Board

The key advantage agile provides us is the ability to course correct after every sprint. Once we start delivering features you can see and touch, you can quickly see where we are headed. This gives us the opportunity to adjust as we go, instead of getting to the end and realizing we are in the wrong place.

It’s all about value!

Agile also gives you – the client – control over the process. If you want to add something new, we can do that! If you want to do that but not change the budget, you get to pick what we take out. Or maybe the new idea adds so much value you are willing to add it on top, but you get to decide.

You also have the option of eliminating features as we make progress. Maybe you thought we needed to build out some reports, but now that you are seeing the lookup screen come together you realize they won’t be needed. The good news is since those were prioritized lower, we haven’t spent any time (i.e. your money) on those features yet, and you can easily cut them from the project.

Project completion

When we get to the end of this process we may end up with something that looks quite different from what we originally envisioned. Ideas were revised and features were cut in favor of others that were added. But by focusing on the overall goals of the project instead of rigidly holding to a narrowly defined requirements document, we will end up with a superior product that was created collaboratively and truly provides the value you wanted.

Teacher pointing to chalkboard

If you are familiar with professional service companies specializing in Web Development or Digital Applications, then you are undoubtedly aware of the pressures and day-to-day struggles that come with meeting the demands of clients. Contrary to social folklore, the customer is not ALWAYS right, however they should always be HEARD. Instead of arguing and potentially losing a client, here are some helpful actions meant to prevent you or your company from constantly battling over the same ground.

The basis for these guidelines is Education. Educating your clients isn’t difficult, however it is an essential part of any successful project and following these guidelines can certainly improve the working relationship you have with clients. It is very important to note: this Education needs to take place before the project begins and even before pen touches paper. Trying to implement these recommendations after work has begun is asking for serious trouble.


Setting a solid foundation for a new project means forging reasonable/attainable expectations with your client. Promising too much or too little is easy to do. It is imperative that you make your presence and views on important topics known from the start. The client needs to know and more importantly understand that hiccups can and will occur causing inevitable delay or push back of other requests. Of course, you and your team do your best to minimize these mishaps, but we are all human and software is challenging! Setting these expectations with the client ties heavily into the next key point.

People communicating via headset and computer with speech bubbles


Before you get red-faced, I’m not implying you talk with the client daily and in turn get loads of requests and feedback while not getting any actual work done. Communication in this sense refers to meetings or demos you set up and speaking to the client ensuring they know that feedback needs to be thorough with explicit details on what they require. The C-word also refers to you as the designer/developer reaching out for questions and concerns along the way. There is no need to wait until interim meetings when something pressing is hindering you from delivering the highest quality product.

Man presenting to a group of people


Sometimes this is the most difficult guideline to handle with finesse. You are trained, certified, college educated, and/or have designed and developed for years; one or more of these things qualify you to do your job and do it well. Clients have opinions and some are much more vocal about them than others. Establishing your credibility is fundamental in getting the client to understand you are not injecting your personal styles for the sake of it. A few ways to soften the edges and effectively guide them is to show some solid research or data that backs up your decisions, or give examples of other sites or books that use your design and function well. Also, when demoing to a client, don’t just click through the process, take time to explain in detail WHY you did these things.


Nothing is worse than hearing “I just don’t like that”, or “Could you try something different?”. Educating the client and nicely pressing them to continually provide meaningful input until the project is complete is highly beneficial for both parties. It is vital to take the time at the beginning of a project to really listen (and ask questions) about what the client is looking for in a website which in turn could help circumvent the need to teach this lesson at all.

Two men in suits shaking hands


The main reason a document outlining the work to be completed and the terms in which they are handled is drafted and signed is to protect both parties. Sounds simple enough, but often work is shoved in to a workload that was never discussed during contractual meetings. Without question there are exceptions and new items that arise during a lengthy project but be sure to stand firm on variations from the agreed upon terms. Reading the contract out loud to the client and conversing about all questions/concerns is a necessary practice in establishing a firm base for success. Some key things to highlight in your detailed contract should be:

  • Intended work hours
  • Milestones/Phases for the Project
  • Payment rules
  • Requirements for Feedback
  • Overall budget with overtime costs

It can be a wonderfully pleasant task to create a beautiful website for a new or established company. Everyone can be on the same page and the budget can be effortlessly adhered to and the client can receive everything they wanted. For the imperfect scenario (basically 99.999% of them), you can follow these 5 guidelines to hopefully prevent World War III. Educating the customer has been and always will be the smartest way to provide effective and fruitful client services throughout any project.

WebJobs and Function Apps, or Azure Functions, are both services in Azure to run triggered or scheduled tasks. I have worked on setting up WebJobs before and then started hearing/reading about these Azure Functions in various blog posts and meetups. Between the information from these sources and recently studying for the Developing Microsoft Azure Solutions exam made me interested in a comparison of the two services and cases where one solution may be preferred over the other.

In this post I make an assumption on basic knowledge of creating Web Apps and navigating the Azure Portal.

Cost and Storage

Money Bag

One of the first things when suggesting an implementation, other than “How long will it take?”, is “How much will it cost?”.

Creating a Web Job is free as long as you have an existing App Service Plan. Running web jobs does consume resources so you will need to keep track of the usage and scale your service plan up or out accordingly.

Function Apps can use an App Service Plan or a Consumption Plan. You can see the details of pricing on the pricing page but it allows you to only pay for resources while the app is running.

One additional cost of selecting a consumption plan is a storage account. You can use an existing account or one will be created by default when the Function App is created and pricing is handled separately from the Function app.

The consumption plan also includes a free grant of the first 400,00 GB/s of execution and 1 million executions. So depending on the execution time of your code all you will pay for is storage.

Set Up

Both WebJobs and Function Apps support similar languages – C#, F#, Powershell, bash, php, python and javascript. I have only worked with C# projects so far but it might be an interesting challenge for a future post to create some in other languages. Very recently support for precompiled functions has been announced which means you can publish a class library as a function app opposed to requiring a Function project type which is not pre-compiled.

WebJobs are a related to an App Service and can be deployed along with the web app they are paired with or uploaded to the Azure Portal as a zip file. For a C# console app this would be the web deploy package. You can have multiple WebJobs in a single App Service.

Azure portal webjob setup

WebJobs can be run continuously, triggered (for example as a webhook) or set to run on a schedule. The schedule for a WebJob is set in the portal when uploading the zip file or in a settings.job file in the project. The schedule is set using a cron expression.

Function Apps are their own resource in Azure listed under App Services.

For a small side track – in the screenshot below you will notice that both the Function App and Web app are assigned to a different App Service Plan. Didn’t I just make the point previously that Function Apps used a Consumption plan and not an App Service plan?


Going into the App Service Plan you will notice that this plan’s Pricing Tier is set to Consumption where the App Service plan that my Web app is tied to is set to Free.

App service plan overview menu


Function Apps have a unique feature that you can edit the code directly in the browser. When starting up a Function App you are given various ways to create the application – starting from a pre-made or blank template, starting from source control or downloading a publish profile to deploy from Visual Studio.


Both WebJobs and Function Apps have been integrated with other Azure and 3rd party services. Function Apps are built on top of WebJobs so any triggers that WebJobs support Function Apps will, too. For example you can have a WebJob or Function App trigger based on actions in an Azure DocumentDB, Azure Storage, Twilio, Event Hubs and many more.

Additional Considerations

One point to consider when making a decision between Function Apps and a WebJob is that Function Apps have some limitations on time and memory usage. Function Apps apply a 1.5GB max memory and a 5 minute max execution time. Like many things this will probably change over time but for now it is something that requires consideration.

Use Cases

Now that we have gone through and compared some of the features of each service, when would you consider using each one? Outside a couple requirements it really is dependent on the project and your preference.

Consider using WebJobs when:

  • Long running task
  • High resource consumption tasks
  • You have a Web App that is closely related to the task you need completed
  • This is where your skill set lies

Consider using a Function App when:

  • Short running tasks
  • Low resource consumption tasks
  • The task is not closely related to an existing application hosted in your Azure account
  • You want the in browser editing capabilities

These are just my opinions – every project is different so use your knowledge of the project and requirements to make the best decision for your project.

One of the challenges I have made for myself at work is, over the next few months I plan to take a look at some of our services and WebJobs that are existing and see if there are any benefits to switching to a Function App.


SharePoint is an industry standard platform for creating a company intranet, but the out of the box styling leaves something to be desired. Even a well-designed site can fail to engage employees if it isn’t visually appealing. In this blog, I will explore several options SharePoint offers to customize the user experience, and explain the pros and cons of each approach.

For this discussion, I will consider each approach within the context of these factors:

  • Design – how much flexibility does this approach have in creating the desired branding?
  • Effort – how time consuming is the approach and what skills are required?
  • Admin – what implications are there for the future maintainability of the site?

SharePoint WYSIWYG page editor

Colored table displaying Design, Effort and Admin pros and cons
At the low end of the spectrum is using SharePoint’s CMS editor. This allows SharePoint users to easily update text, content, images, and links. Users that have used a CMS such as WordPress or Sitefinity will be comfortable with this solution and can generate pages and content with no technical skills required.

There are two downsides to this approach. First, since content is manually put on the page it is static and requires updating anytime that data should change. This increases the admin time necessary. The remaining methods all rely on SharePoint content to allow the pages to be dynamic.

Second, the out-of-the-box options for styling are limited to what you can do within the WYSIWYG. This approach risks producing inconsistent branding across the site, as each editor makes styling decisions on a page-by-page basis.

SharePoint List WebParts and CSS styling

Color coded table displaying Design, Effort and Admin pros and cons
Leveraging SharePoint content items and exposing them through WebParts is typically seen in many organizations. This approach scores high in both the effort and admin categories. Creating new content types and using WebParts is something business users can easily learn how to do. WebParts are designed to expose the underlying content types which allows the page to be dynamic. The SharePoint List WebPart also allows custom views to be created by admin users to fine tune what data is displayed as appropriate for the context.

To apply branding to pages built this way, SharePoint allows for the CSS to be adjusted. This gives you a limited amount of control over the visual appearance of the site. Company brand colors can be applied, fonts can be adjusted, and similar tweaks can be applied.

The advantage of this approach is that once the CSS styling has been applied, users can continue to use the standard SharePoint editor and WebParts. Any new list created on a page will automatically pick up the styling. This also allows designers to ensure more consistency in branding across the site.

I still score this one red for design because the options available for modification through CSS are limited. A designer with any aspirations of using artistic license will quickly run into the boundaries of this approach.

Overall this is well suited for a SharePoint site where ease of administration is a key factor.

SharePoint Content Search WebParts (with display templates & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
Content Search WebParts allows designers to extend the previous approach while gaining access to significantly more styling options.

Using this approach, designers effectively create their own WebParts that are connected to SharePoint content lists and add them to the site. These custom controls give the designer access via display templates to control the HTML markup that is rendered. The level of effort has increased as this method requires more web design skills than before, but in exchange you get a much more visually pleasing result.

Another advantage of this approach is that with a little training, site admins can learn how to leverage these content search parts. Once they are created, non-IT admins can reuse these controls elsewhere on the site. The pages continue to remain dynamic since the components are still connected to the SharePoint lists.

The obvious question is why the yellow coloring for administration then? Mercury has found through our experience that these components rely on behind-the-scenes indexing that SharePoint does to make the data available to the control. This means that when a new item is added or modified in SharePoint, it will not be immediately visible on the control. Once the SharePoint index process picks up that content and puts it in the index, then it is available for display. In the real world, we have seen this take anywhere from a few minutes to almost 24 hours depending on the site. We have found that even a short delay can cause frustration for admin users who can’t see the immediate impact of their changes.

SharePoint API (with JS & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
For a truly custom branding experience, leveraging the SharePoint API is the way to go. This gives the site designer full control over the markup and allows for the creation of a site that approaches a full custom web page experience in appearance. Additionally, the API is not subject to the SharePoint Index limitations in the previous approach, so content changes are immediately reflected on the site.

From an effort perspective, this is the most complex approach and requires the same set of skills required to do true web development. Of course if the goal is a highly branded site the additional effort will be worth it to produce the desired results.

The drawback with this approach is that business user admins are more limited in their ability to change the site. Future changes to page layout or content types would require changing the code that renders the page. The admins no longer have the ability to reuse the components as they do with the content search web parts. On the plus side this also ensures that the integrity of the site design is maintained.


If you were waiting for the approach that had all 3 boxes green, I’m sorry to disappoint you. As with all implementation discussions, there are always trade-offs. Before selecting an approach, you need to consider your goals for the site, the amount of branding desired, how much budget and time you have available, which skillsets you have at your disposal, and the level of flexibility in making changes. Armed with those answers, my hope is that this discussion will help guide you to select the appropriate approach.

As a relatively new architect-level hire at Mercury, I have spent a large amount of time exploring code bases that are new to me. In that exploration, I have come across a variety of source code peculiarities and problems related to issues with naming conventions. These are fairly rare situations and as such can take a while to diagnose and get to the true root problem. As a whole, naming schemes can vary greatly between organizations, with some of the bigger names like Microsoft contributing their recommendations on best practices. The issues I will describe below are specific to situations in Mercury’s development process, but might help to identify possible pitfalls in yours.

Case Sensitivity Differences in .NET Framework

The .NET framework allows development in VB.NET as well as C#, with interesting differences in case sensitivity. C# is a case-sensitive language, which means that it can recognize the difference between the following methods:

void myFunction()
void MyFunction()

This is definitely not a best practice programming-wise, and coworkers might frown upon your decision here, but according to the framework, this is allowed. However, VB.NET is case-insensitive, meaning that it cannot allow the same methods with the only difference being capitalization. This also applies to parameters in a method signature, namespaces and properties.

Where this could cause conflicts is when introducing compiled code into your solutions. For example, if you are working in a VB.NET solution and you introduce a NuGet package which was initially developed in C# with two methods that vary only in name capitalization, you are going to face compilation errors.  It is not always easy to track down what that NuGet package might be doing, so keep this case in mind.

Variable names in JavaScript

Similar to the above, it’s important to realize that JavaScript is also a case-sensitive language, it identifies a difference between the following variables:

var myName()
var myname()

This is something that you can potentially come across when working in either a vanilla JavaScript project or while using a JavaScript library such as jQuery. It’s more likely that you will come across this situation when using a full JavaScript framework, such as AngularJS or ReactJS.

Especially if you are integrating with a webservice of some kind, you could face issues with the naming convention coming from the service versus the binding used in the framework. In our case, we were integrating with a WebAPI service which we had developed, and we had specified the following naming for the output from our WebAPI:

config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = 
new CamelCasePropertyNamesContractResolver();

This says that, regardless of how the naming convention is utilized in our WebAPI project models, the output is going to be such:


The issue in our AngularJS application was that we were reading most properties correctly, with the camelCase formatting, and a very large application was working 95% as intended. Later we noticed that one of the columns in our database was always null. Backtracking the problem, from the models through the WebAPI layer and into the AngularJS application, we discovered that we had improperly capitalized the binding in this way:


Because JavaScript is case-sensitive, this created a new property to our JSON object:

 var model = {
            AccidentallyCapitalizedFirstLetter: "",
            accidentallyCapitalizedFirstLetter: ""

Whatever was entered into our application on the front-end was never properly bound back to the WebAPI for saving to the database, and this information was perpetually lost. We had discovered a very small mistake, with a large effect which wasn’t easy to determine while debugging through a missing data issue.

Confusing Third Party Namespaces

Sometimes the naming issues you run into aren’t your fault or even in your control: we have faced several instances of plugins and third party tools which are nearly identical in name to other tools, sometimes differing by only one letter. Sometimes the plugin is named such that it seems like it would be supported by a major corporation, but in fact it’s one developer trying to exploit the similarity. One non-development example is the court case of Nissan Motors vs. Nissan Computer, two different entities with claims to the same name.

In our case, we ran into an issue relating to Microsoft and a SDK they provide to access their cloud-based APIs. In 2014 a version 2.0 was released for what they called the ‘Microsoft Azure Graph API Client’, a tool to access Azure Active Directory and a few other Azure resources in code. This SDK was made available via NuGet, Git and Microsoft’s site.

In 2016 Microsoft released a new tool, this time called the ‘Microsoft Graph API Client’. This incredibly similar name is a tool replicating the complete set of functionality of the Microsoft Azure Graph API Client, with some additional features of being able to access Office365 and the rest of Microsoft’s suite of cloud tools. Both of these tools are currently supported, and because of the cross-over between functionality, it’s very likely that either or both will come up when doing any form of web search.

If your architecture is currently setup to support one of these versions of the Microsoft SDKs, then it’s likely that you want that specific library instead of the first one to come up from a search. This could become even more confusing when a newer developer is tasked with extending some functionality and chooses to add a new library to the existing stack because closely named projects introduce ambiguity.

Apache Hosted URLs

Probably one of the most interesting, and hard to solve issues, that came up as part of a naming-related problem, was related to an Apache hosted application. In this case, we were using a set of testing tools, and in code we would reach out to those tools with a standard HTTP-based web request. During the lifecycle of these testing tools we had consistently been working with a naming convention like this:

With this approach, we had never run into any issues that we could notice, and we were initiating functional testing using this location across dozens of different projects. Considering that our approach was a successful one, we looked into refactoring our testing solution into a NuGet package. This is where we started to run into errors.

Specifically, in our NuGet package we defined static classes to initiate the connection to the testing application. Our implementation of this library would simply define a test, and the results of this were coming back with the connection being denied. This was surprising, especially given that we could go back into an older application immediately after and have a test work successfully.

With some debugging of the network, we determined that the URL above was giving a 301 response, it was redirecting to the correct URL:

Since the Apache host is case sensitive, it wasn’t responding to the two URLs as the same destination, and instead was redirecting from the capitalized case to the lower case. The static class implementation was not handling the redirect, whereas our previous implementation did follow the redirect and get the response from the new route.


These issues nearly all turned out to be minor problems in code, but each gave different indications as to what failed. They all started out as some different symptom, either database oriented or networking related. Starting from an assumed problem, it was surprising to see how much of an effect capitalization could have, beyond just making everything a bit more confusing. In the case of third party naming conventions, I’ve learned to be very clear in my documentation, to include links, and to not trust external libraries to always follow sensible conventions.


At the end of 2016 I embarked on a goal to develop an in-house framework for Mercury to use on our internal websites and web apps, as well as client projects. This blog post is geared toward front-end developers looking to make their own framework, and in this post, I’ll talk about approaches I took and lessons I learned during development of the Mercury UI Framework.

Why Another Framework?

At Mercury, we utilize Bootstrap quite often. Many of our client sites use it under the hood. We’ve also dabbled with Foundation, and there are many more out there. The advantage to using a framework is quite obvious:

  • A well-architected UI layer
  • Lots of components
  • Nice documentation
  • Browser testing for free
  • Large ecosystem with examples, tutorials, and add-ons

While we’ve become experts at using Bootstrap, customizing it (tip: use the SASS version!), and extending it, over time I’ve found it lacking in areas and stagnant in new features. Version 4 has been promised for a long time now, but has yet to appear in its final form. After taking a look at the early alpha code, I also felt like it wasn’t pushing itself far enough (there are good things coming, though – flexbox first CSS, refactored cards components, and more). Better responsive components, like tabs and tables? Nope. An off-canvas nav? Nada. Mega menus? Zilch. So, I decided to create a framework that offered more while keeping the things we use most often.

Mercury UI Framework - Components 2

Plan Ahead

Browser Support

Before setting out creating a framework, the first thing you should do is plan what browsers you need to support. This will help inform approaches and effort once you start writing code. At Mercury, we support the latest two operation system and the latest two browsers. That means Windows 8.1, Windows 10, macOS 10.11, macOS 10.12, iOS 10, iOS 9, Android 6, and Android 7 for operating systems on desktop and mobile devices. For browsers, support includes IE11, Edge, Chrome, Firefox, Safari 9 & 10, Safari iOS 9 & 10, and Android Browser. As of late 2016, that covers about 95% of OS’s and browsers in the USA.

Identify Features

The next step in planning is to identify the features you want to build. For my framework, I wanted to create something on par with Bootstrap, but take it further too. This meant including:

  • Accordions
  • Alerts
  • Badges
  • Bands
  • Buttons
  • Button groups
  • Cards
  • Dropdowns
  • Grids
  • Heroes
  • Input
  • Input groups
  • Mega menus
  • Modals
  • Off canvas navs
  • Pagination
  • Tables
  • Tabs – Horizontal
  • Tabs – Vertical
  • Toolbars
  • Tooltips

I also know I wanted to have good documentation with code snippets to copy and paste, as well as a Kitchen Sink of one screen with all components that could be the basis of a projects’ style guide. The table component I created offers 3 different approaches to making tables friendly for small screen devices. Both tab components (horizontal and vertical) change to accordions as well for better mobile usability. I also wanted to make sure I provided breakpoint classes to turn on and off styling, if needed.

Mercury UI Framework - Brand Colors

While identifying features, it’s also a good point to brainstorm how you can make your framework unique. What feature(s) can I include that will set it apart from the rest and make somebody want to use it? How can I provide value for myself, my coworkers, my peers, and for clients? Where can I make things easier and better? Where can I save time for the things I do day to day?

Lastly, identify what you don’t need to create. For the Mercury UI Framework, I made the conscious decision to not include a rotator (also known as a carousel or slider). Much has been written about their poor accessibility, and because there’s more than enough plugins out there, I kept a rotator component off of my features list.

Create A Timeline

After choosing features, the next step is to create a timeline and estimate how much time you’ll need to complete it. The actual time it takes will be different depending on the skill level of the person writing the code, so this should be different for everybody. Also, finding a good MVP (minimal viable product) point for an alpha release is a good idea – you can always have more feature releases in the future. Make sure your timeline includes:

  • Research
  • Building the framework
  • Refactoring
  • Testing (Applause, manual, etc.)
  • Bug fixes
  • Dogfooding (using what you build)
  • Documentation
  • Testing the documentation
  • Setting up hosting, environments, etc.
  • Pipeline creation
  • Code quality analysis (SonarQube, linting, etc.)
  • Code reviews by peers
  • More testing, bug fixing, and refactoring time

Research Best Practices & Industry Trends

Even if you’re a seasoned front end developer, you should take some time to research. In my opinion, you’ll want to target where the industry is going, not where it is now or where it’s been. Is CSS Grid viable yet, or should I stick with Flexbox? What about responsive type? Should I use LESS or SASS? How can Gulp help me? Utilize resources like CSS-Tricks, Sitepoint, Smashing Magazine, and Codepen to gain inspiration and novel approaches. Collect these links and decisions somewhere, like a OneNote or text document, that you can refer back to later. While not everything made it into the Mercury UI Framework, doing this research will inform the code you write. Some decisions, like using the lobotomized owls selector for global margins, will impact the whole framework. Make sure to refer to Can I Use to make sure you’re providing support for the browsers you chose.

Make It Themeable

The framework I created is meant to be used by front-end developers who have the skills to use SASS, so the approach I took was simple: use SASS variables to theme the basic look and feel of the framework, such as colors, border styling, and sizing of elements. I also utilized SASS maps so that developers could easily add or remove breakpoints and alternate colors for components. If you have the time or need, you could go wild and create a theme generator like some frameworks offer. I’d recommend also keeping your CSS code specificity as low as possible so that other developers can easily override your styles with their own without accruing technical debt.

Make It Easy To Use

If you want other people to use your framework, you’re going to need to create good documentation that has examples, code snippets, and explains your architectural decisions. You’ll probably also want a roadmap with where you’re going with future versions, a place for keeping track of bugs, and several ways for people to get your code (repo, direct downloads, etc). One lesson learned is that documentation takes just as long as writing the framework code – don’t leave it until the end! Try and document your work as it’s completed so that othing is left out or forgotten.

Hold A Code Review

If you’re the only one developing a framework, it’s a good idea to get an outside perspective to make sure your decisions and your code make sense to somebody else via a code review (also known as the number of WTF’s per minute). Another set of eyes and a different brain can help you point out confusion, poor code, or generate ideas for improving your framework. You can hold a code review with a coworker, a developer of a different discipline, or a development manager. If you want a truly outside opinion, find a peer via a front-end development Meetup group. Make sure to follow up a code review with actual action, such as refactoring or creating more documentation.

Test It

This may seem obvious, but sometimes designers and developers cut corners by skimping on testing. Be honest with yourself and really put your framework through its paces by testing it thoroughly. This includes browser testing, functional testing, code analysis, linting, and dogfooding your own work. At Mercury, we’ve adopted Applause for testing our websites and apps, and the Mercury UI Framework was run through this service just as any other project. It helped uncover 70+ issues that I was able to correct, giving piece of mind that the code I wrote would hold up on production sites and apps. Your timeline created earlier should include a healthy amount of time for testing and fixing bugs exposed during that process, as well as multiple rounds of testing if you undergo extensive refactoring during development.


If there’s one thing I want to impart in this blog post, it’s that creating a framework is a lot of work. I hope my time spent can help somebody else looking to do the same. By structuring the process into different segments, you’ll be better armed to complete your framework project and produce a better product as well. Also, remember that you’re never really done with a framework, or any development project for that matter. New needs and ideas arise, browser support changes, bugs will be exposed, and you’ll feel the need to refactor your work.

If you’re interested in checking out the Mercury UI Framework, visit the documentation for the site at (pretty URL coming soon).

As web developers, we strive to provide the highest fidelity interface and experience for users of our sites and applications as possible. From the use of responsive web design, SASS, CSS3, Flexbox and JavaScript frameworks we exercise every technique and option to bring the latest to our users. With great power comes great responsibility and that means dealing with FOIT, FOUT and providing the perception of performance to our users.

I’m Too Old for This S*!%

Back in the day, Mercury’s late-90s sites and applications utilized “system fonts”, no CSS (it just didn’t exist) and even rudimentary nav image rollovers were done with inline JavaScript. In short, life was simple.

But with the addition of custom font faces (@font-face) in CSS3 and the growth of JavaScript which added sophistication and separation of CSS documents we could build truly beautiful and sophisticated interfaces. What used to look like:

      <title>Hello World</title>
   <p>Hello World</p> 

now looks like:

    <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
    <link rel="apple-touch-icon" href="apple-touch-icon.png" />
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png" />
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png" />
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png" />
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png" />
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png" />
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png" />
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png" />
    <meta name="msapplication-TileImage" content="/windows-8-tile.png"/>
    <link rel="stylesheet" href="main.css" />

    <script src="/modernizr-custom.js"></script>
    <script src="/jquery-3.0.0.min.js"></script>
    <script src="/jquery-migrate-1.4.1.min.js"></script>

    <title>Hello World</title>


with even more HTTP requests in the associated CSS sheets:

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.woff2') format('woff2'), /* Most current browsers */
       url('webfont.woff') format('woff'), /* Recent/modern browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */

HTTP Requests and the Damage Done

As you can see, there’s a price to be paid for web fonts – additional HTTP requests separate from the HTTP request for the web page markup. Font files can be tardy in the chain of HTTP requests because of their size, an effect more pronounced on slow network connections or mobile connectivity – and simply because they come AFTER the initial page request.

An inconvenient truth web designers must deal with every day is to decide whether to show page text before the needed font files arrive, or wait for the font files, showing nothing until the text is ready to render with the required web fonts. Now we have to wrestle with things like FOIT and FOUT.

So What Is FOUT?

FOUT stands for “Flash of Unstyled Text”. FOUT is what happens if web page designers decide to display the page in full before font files arrive. FOUT is actually a special case of FOUC – Flash of Unstyled Content – in which the browser renders the entire web page briefly with default browser styles because the markup has loaded but the CSS sheet that dictates layout of the page has not. After a short time (often less than a second) when the CSS sheet does load the whole page re-flows to take on the layout defined by the CSS. This can be very disorienting to the user and at times give the impression of a broken website.

With FOUT, sooner or later page text will re-arrange into a new form when proper custom fonts have completed their download and the browser re-renders associated page text. Text often pushes around and across lines; at times this is a subtle change if the custom font is close to a default system font or can be extreme if the font is considerably different in composition. Oftentimes the page designer will try to select a “system font” that can be styled to be similar in size, weight, kerning and leading so that when the real font loads the page doesn’t shift that much.

What Is FOIT?

FOIT stands for “Flash of Invisible Text”. FOIT is the phenomenon users get when the page designer chooses to render the layout of the page but wait to place visible text until the custom fonts have loaded. From an information consumption standpoint, this leaves the page unusable for a short time; this design choice can make sense if the fidelity of information presentation is more important than quickest possible consumption. Many consider FOIT to be less jarring than FOUT since the page doesn’t not “change shape at any point” and proponents feel that users are used to waiting for images to download.

How Does Perceived Performance Fit Into the Discussion?

To a significant extent, FOUT and FOIT are not completely avoidable with modern web development technologies and user experience expectations. What is in our control is the use of mitigating techniques to make websites and applications have the appearance of a high level of performance. The term “Perceived Performance” is a measure of how quick a user thinks your site is – and that can often be as important as its true speed.

User Experience with progress bar loading

If you can get enough of a page to load quickly enough that the user can begin to accomplish what they came to your site for, they are typically indifferent to actual time it takes to download all assets. An example is a technique often implemented on long pages of continuously scrolling news stories – if the user can begin to read the first story or two in proper form before the entire page and associated files have downloaded, they consider the page downloaded and usable. By the time they scroll down the page for additional content the remaining material has loaded in the time they spent reading the first story, leaving the user with a high perception of performance.

What Can We Do About FOIT and FOUT?

Frankly, neither FOIT nor FOUT is optimal – what can we do to mitigate the problem?

Critical FOFT

Yes – this is another F-word: Flash of Faux Text. Zach Leatherman initially advocated for the use of a tiny “subsetted” font file (it contains only upper and lowercase characters from A-Z in the “normal” weight) followed by a separate request for the full font file (punctuation, non-alpha characters, different weights etc.). With this technique, the user will then see a quick “flash” between system font and web font much sooner which will be followed by a minor flash when the remainder of the web font loads. This technique is not foolproof but is a major leg up on unchecked FOIT/FOUT.

Critical FOFT with Data URIs

An extension on the Critical FOFT approach in which an inline “data URI” of an encoded set of basic glyphs is included in the page markup (the initial request). Since this request is inline it is blocking (doesn’t wait for later HTTP requests) in that the page will not render until this encoded font has been downloaded along with the rest of the page markup. Here is an example:

@font-face {
font-family: "font-name";
src: url(data: font/opentype;base64,[paste-base64-font-data-here]);
font-style: normal;
font-weight: normal;

Use of this technique is not perfect as it will result in a FOIT only in older/downline browsers/devices. Among other resources, Font Squirrel’s webfont generator will provide base 64 output for this purpose.

Further Reading

Use of either variation of Critical FOFT will significantly improve the perceived performance of your web pages and greatly reduce manifestations of both FOIT and FOUT. However, there are plenty of other approaches (more being invented every week) and F-words – I highly recommend Zach Leatherman’s post at

A lot of women in tech, including myself, don’t like to spend a lot of time talking about being a woman in tech. The topic is controversial, usually uncomfortable, and comes with a negative connotation similar to “oh boy, what is she complaining about now?” Fortunately when you’re like me and work with a company that doesn’t just employ women in IT but empowers them, you can feel confident to speak on an issue that still persists.

Women with computer chip in the background
For an industry that greases the wheels of human progress, it seems counter-intuitive to see such social regression. More and more women have entered the workforce in recent decades, but they’re falling out of techie jobs or appear to be disinterested in entering the area to begin with. Dare I pose the question…Why?

There are a variety of reasons, some of which include:

  1. Education Pipeline
    Not enough women are enrolling in IT degrees such as computer science. For example, only 18 percent of US university computer science (CS) graduates in 2013 were women.
  2. Recruiting and Hiring
    Unconscious gender biases drive the pattern of hiring a man over a woman in the field. Perhaps the same unconscious gender bias that drives parents to discourage women from taking interest in the mathematical or scientific subjects that grooms them for a computer science degree.
  3. Pay and Promoting
    There still is not a single country in the world where women are paid equally to their male counterparts. The US female web developer makes 79 cents to the dollar men make for the same job. In 2009, Dell paid almost $10 million to settle a gender discrimination lawsuit from its employees over equal pay.
    Couple all of that with the fact that women run just 3.6 percent of Fortune 500 companies (and we think that’s a remarkable achievement!)
  4. Retaining
    In the US a quarter of women with IT roles feel stalled in their careers. In 2014, it was recorded that nearly 50% of women in IT roles leave within the first year due to issues with promotion and the hostile, brogrammer culture.

It’s disheartening to admit that still being very young in my career as an IT professional, I’ve witnessed or experienced all of those firsthand. Taking away the textbook and statistics, what’s it like being an IT professional from her perspective? Cue the finger snaps from my female readers.

The most common challenge is the dichotomy between being blocked for being too aggressive versus knocked for not being aggressive enough. Plenty of women, myself included, feel they have to walk a constant tightrope in monitoring and adjusting their professional behavior so that they can succeed, or even be taken seriously, in ways that most men probably couldn’t even dream of.

  • Analyzing whether your email was concise or curt.
  • Gauging if/when you should back down (or even participate) in an office debate.
  • Determining if/when to cut in with your idea during a meeting.

All of these hesitations are out of fear that we’ll damage one of the male egos in the room, and God forbid, the one that can influence our pay or promotion. Such actions are frowned on for women, and usually praised as confidence and leadership for men.

To bridge the gap, it won’t just take action from our male colleagues (though I have a to-do list for them as well.) We have to be an active participant in our own uprising, and stop the behavior that permeates this brogrammer / male-dominant culture. Starting with something as simple as our professional writing, stop giving in to the societal pull to sound less direct than you’d like out of fear of seeming pushy, bossy, or, worst of all, shrill. No more of these:

  • “I’m sorry…” – We have to stop apologizing for asking people to do things, particularly when it’s something that’s part of their job.
  • “I may be wrong but . . .” – Don’t lessen the impact of what you say before you say it.
  • “Does this make sense?” – Trust that what you wrote makes sense. Don’t openly question in email whether or not your thinking is sensical.
  • “Just…” – We need to stop using this word as a way to weaken a request or our opinion.

As for our day-to-day office interactions, 

Avoid being too easily offended. There is a line to be crossed, but don’t take yourself or the office too seriously.

Play to your strengths, even when they are stereotypes, whether it’s listening, emotional aptitude, or empathy. These are all good qualities in a leader.

Get a Sponsor. Start building relationships with your boss and other senior leaders from the beginning, and pay particular attention to cultivate those relationships with the individuals who believe in you and publicly support you—they are going to be your best advocates.

As for the men out there, changing women’s roles in the workplace can’t happen without a change in behavior from their male colleagues and partners.

Be an Advocate. If you see female colleagues get interrupted in meetings, interject and say you’d like to hear them finish. Openly ask women to contribute to the conversation. Look for opportunities to acknowledge women when their ideas are implemented, both publicly and to higher ups. Women are less likely to toot their own horns, so help make sure your colleagues get the credit they deserve.

Recruit & Promote Women. Know that some of the most promising candidates won’t come to you: Men will apply for jobs when they meet 60% of the hiring criteria while women wait until they meet 100%. So go after them, finding qualified candidates using LinkedIn and references. Make sure you’re helping to give the women who are already a part of your organization an opportunity to rise.

Share the Office Housework. Changing gender stereotypes about duties isn’t just for the home front. Don’t fall into the trap of expecting women to take on stereotypical support roles like note taker or party planner.

Above all, understand that your actions can help set the tone for other men in the office. Be aware of your subtle biases when it comes to gender. You may not realize it about yourself – or others who work with you.

The truth is…if women start gaining more ground in the workforce, it doesn’t mean men have to lose out. The zero sum game mentality, implying someone always has to lose — which has also permeated our marketplace, in more areas than this — has got to go. If we tackle issues like diversity, innovation, businesses with strong, robust strategies, and overall value creation should skyrocket.