Why Maintaining A List of Supported Browsers and Versions Is Important

Why Maintaining A List of Supported Browsers and Versions Is Important

All browsers are not born equal.

While most people have preferences for one browser over another based upon look-and-feel or specific pieces of functionality.  Those same people probably feel that all browsers are inherently the same on a foundational level.  Unfortunately, that’s just not the case: Internet Explorer is different than Edge who is different than Chrome, Firefox, Safari, etc. They are built upon different underlying code. For example, Safari uses Webkit, Chrome uses Blink, Firefox uses Gecko, IE uses Trident, and Edge uses EdgeHTML.

These foundational differences in how each browser was developed means that the experience that each user has when visiting the Innovation Portal will be situationally based upon the browser they use. The site may look beautiful in Chrome and Safari while it looks terrible in Edge. This situation is exacerbated when you start to include different versions of each browser.

Versions Matter, Too!

The individual versions of each browser that particulars use to access your site can present a WIDE variety of user experiences. To see this for yourself load a new Internet Explorer browser, hit F12, and select the “Emulation” tab. Under the “Mode” section you can change the “User agent string” to various versions of Internet Explorer. Select an old version (e.g., IE 6, IE 7, etc.) and navigate to your favorite web page. Many, such as CNN, will include a warning that your browser is out-of-date and the entire user experience will most likely be different than what you are used to seeing.

So what? The importance of maintaining supported browsers and versions is multi-purposed. On the one-hand, it allows you to focus your development process time and effort to providing your users a meaningful experience within the context of how they interact with your site. If a majority (or even plurality) of your users hit your site with a single browser and are all within the last couple major releases of that browser then you can direct your development processes to ensure that you meet your users with the experience that they have come to expect for the Innovation Portal. Conversely, you do not want to spend time and effort chasing a browser or version that is only used by a tiny fraction of your entire user base. Your development dollars are better spent providing most of your users with an increased experience.

Secondly, browsers are constantly being updated to ensure that they are safe and secure while providing enhancements that improve usability. By keeping your site’s code fresh and in line with these newer releases your site can take advantage of these improvements. This reduces the amount of “technical debt” that you could incur by letting your browser supportability lapse several major releases which could hamper user adoption.

I was told there would be no math…

As a matter of “comparison shopping”, the current global market share of browsers are:

– Chrome 52.5%
– Safari 28.36%
– Firefox 5.26%
– Internet Explorer 5.1%
– Edge 3.39%
– Samsung Internet 1.84%

Similarly, the current North American market share of browser versions are:

– Chrome 63.0 27.73%
– Safari iPhone 17.76%
– Chrome for Android 17.48%
– Safari iPad 5.17%
– Internet Explorer 11.0 4.47%
– Firefox 57.0 3.31%

Click here to learn more about CleanSlate and how we can keep you out of “technical debt” and on top of your web game!

A RESTful Interface With a Wide-Open Contract

A RESTful Interface With a Wide-Open Contract

I remember first hearing about RESTful API design at a Gartner Application Architecture, Design & Integration Summit back in 2008. I recall thinking how practical the idea was, leveraging GET, POST, PUT, PATCH, and DELETE to communicate with an API server.

It wasn’t until a couple years later that I started seeing RESTful APIs at client engagements. All of them seemed to follow the standard RESTful API design, making it easy to build client applications against the back-end API services built upon REST.

Well…all except for one.

A Different Design
As part of an application conversion project, I was told that there was very little work to do on the API side of the solution. My focus was to replace a legacy client framework with something more responsive.

When I started looking at the legacy code, I noticed that one single endpoint continued to be utilized over and over again. Basically, there was a single REST end-point, which was configured as a POST and required the client to provide a query that will be accepted by the end-point, executed and then returned with a standardized, but very generic response.

Here is an example:
var data = {
entityName:’CustomerVO’,
orderByAscending:’name’,
where: [
[‘dateDeleted:date’, ‘is’, null]
]
});
$http.post(‘//api.myapp.com’, data);

In the simple example above, the API is being asked to locate CustomerVO objects, which do not have a value for the dateDeleted attribute. The results would be ordered by the name attribute in ascending order.

The response would then be structured as follows:
{
“data”: [{
“id”: 1001001,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “ABC Company”
}, {
“id”: 5003003,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “Beta Company”
}, {
“id”: 3002002,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “Zeta Company”
}]
}

Only three records were located, and they were sorted by the name field.

This approach reminded me of a Seinfeld episode where (Cosmo) Kramer’s telephone started ringing as a result of Moviefone customers seeking show times in their area. Evidently, the number of Moviefone was very close to Kramer’s telephone number. So, instead of letting people down, he attempted to ask the caller to use their touchtone phone to type in the first three characters of the movie they wish to see. Unable to translate the touch-tone sounds into a title via a couple of guesses, Kramer finally announced in a robotic voice, “why don’t you just tell me the movie you selected?”

You can watch the clip here.

To me, instead of having a standardized manner to obtain a list of items for a given resource, the RESTful API is acting like Kramer almost to say, “why don’t you just tell me what data you want me to return.”

Brilliance or Insanity?
What I never really found out is if this design was brilliant or a less than ideal approach to meet the needs of the customer’s API.

On one hand, it was kind of neat to be able to place the control in the hands of client – empowering them to obtain whatever data was required. With this open access to the back-end data store, client-side developers do not have to wait for the back-end developer to release new end-points which provide access to the much-needed data.

However, the other hand is heavily weighted down with challenges with this approach.

For starters, there seem to be some significant security vulnerabilities with the approach – especially in cases where sensitive data could be exposed. A good rule of thumb is to not expect the client to maintain the same security levels – even if the client is internally facing. After all, some simple analysis of the network connections in order to determine the parameters of the POST request being used. From there, common tooling (such as Postman), could help the curious customer gain access to additional data.

With everything flowing through a single end-point, the potential for scalability issues also exists. As the POST-based requests for data increase in size, the response time is likely to also increase – yielding performance concerns. Compounding the issue would be the increases associated with additional clients of either the same application or a related application – leveraging the wide-open contract-free API.

Finally, nature of the response differing based upon the request seems like it would be a concern. Along the same lines, the support team may find it difficult – if not impossible – to make changes to the API without breaking every client utilizing the service. Of course, a new version of the API could be released, but at that point maybe it would make sense to convert to a more traditional RESTful API.

Conclusion
When I first encountered this API, the design caught my attention. In my mind, I wondered if this was a similar scenario to when everyone believed the earth was flat. That, all along, we the RESTful API developers were using an approach that was mythical, at best.
After giving this idea some additional thought, I believe that the challenges I noted (I am sure there are others) far outweigh the way-cool benefits of being able to “just tell the API what data you want it to return.” Still, this article gave me the opportunity to link back to a comical segment of one of my favorite situation comedies back in the 1990s.

Have a really great day!

Being Smart About Your UI/UX Design

Being Smart About Your UI/UX Design

The electronic age has certainly made life simpler.

Even before we found the need to be connected, electronic devices have become a supplement to our daily lives. The simple word processor and spreadsheet on the way-overpriced home computers helped make communication easier to read and reduced errors with pencil and paper computations.

With our connected world, just about everything we used to do can be completed (in one way or another) using an electronic device. Earlier this week, our family searched the web-sites of a couple grocery stores (and Amazon, of course) to see who had a particular type of icing that was going to be used on a cookie cake. Performing the search from home saved us the time and money (gasoline mostly) of driving around to reach our goal. With a newborn baby in the house, both time and money savings are always appreciated.

The success of being able to provide a need or service electronically requires some type of user-interface. In modern Information Technology (IT) applications, this is often referred to as user interface (UI) or user experience (UX) design. While it might be hard to believe for some, the UI/UX design is equally as important as the actual need being met. Some argue the UI/UX design might even be more important.

Below are three scenarios I have encountered of cases where the UI/UX design probably wasn’t the highest priority in the overall goal of meeting the application.

The Original Links – Golf Game

Growing up a fan of playing electronic games, I was super excited when the idea of PC-based games started to gain momentum. I had invested in a pretty nice computer that I was using for school and could not wait to allocate some of my entertainment budget toward playing games. At this point of my life, I was still enjoying a round of golf – both for the time outside and the challenge of doing my best at the game. So being able to golf virtually (especially during the winter months in the midwest) was something I was looking forward to evaluating.

The original Links game series was called “Links: The Challenge of Golf” (you can play it using your browser here) and the game was incredible (for the time). Since this was before computers had dedicated video cards, the CPU was used to handle every aspect of the game. So, it took several seconds for those picturesque golf scenes to render on computers back in those days. Players didn’t really care about the lag, since this was awesome … and compared to nothing else available at the time.

However, one thing that always bothered me was UI decisions within the game. When you bought the game, it came with only one course: Torrey Pines – South. Each time you started a new round, the game would always prompt you to select a course, as shown in the screenshot below:

When this screen arrived, it was common to jokingly ask, “which course do you want to play? Torrey Pines … or err … Torrey Pines.”

What I never understood is why the development team wouldn’t put in a feature to check to see if any other courses existed, before making the user select from a single select list. Especially since the game only shipped with one course and other courses were provided at a later date … for an additional cost.

I have seen this same type of logic years later, where a dynamically generated pick-list has only one option and an option is required to continue. If the field is required and there is only one option, why not go ahead and preselect that option?  The savings the development team would save on making this default selection not only saves the end-user time but also provides a more positive UI/UX experience.

When Using Grids – Mock Up Using Grids

A great deal of projects are using web frameworks (like Bootstrap) to supplement the design of a web application that can provide a responsive application across multiple end-user devices. A core aspect of the responsiveness is the CSS Grid Layout technique, which divides the <div> into as many as 12 equally spaced columns. Within each <div> another set of 12 can be added (and so on) with a goal to meet the needs of a majority of user interfaces.

Below, is a simple example of a basic grid row.

Grid systems have been a part of nearly every web-based client interface I have worked on since 2013.

The one challenge I have seen is with the UI/UX team not recognizing our decision to use a CSS Grid Layout. Instead, the UI/UX team provides 2D screen mockups using their preferred graphic design tool. For the most part, the elements depicted in the 2D screen sample can be rendered into the grid system without any issues. However, there are times when quirky CSS is required to meet the design – which can be a challenge to support across multiple screen resolutions or devices.

Most of the time, accommodations can be made to update screen designs to represent reality. However, it would be nice if the UI/UX team had a clear understanding of CSS Grid Layouts and it would be even nicer if their tooling allowed them to mock up the screens using the same frameworks that were ultimately utilized by developers. Otherwise, the disconnect will often require re-work costing the project team unexpected expenditures and potential timing delays in meeting their goal.

Actually Quitting Phone Apps

Mobile devices have certainly seen their share of great and not-so-great UI/UX experiences. I believe a good portion of the bad UI/UX designs are due to the fact that the work was completed by an individual without much experience in front-end design. This could probably be traced back (in most cases) to the boom of mobile applications and a flooded market of individuals attempting to cash in on the wave.

However, I have seen a couple applications that have been developed by major corporations which lack one major feature: the ability to easily quit the application. Two applications that come to mind for me are the UnitedHealthcare (UHC) Motion application and the iHeartRadio application.

I initially downloaded the iHeartRadio application so that I could continue listening to an over-the-air program while I worked on the lawn after my drive home. What I noticed at the time was that there was no way to quit the application. I could stop the broadcast from playing, but the application remained open and at the taskbar on the top of my screen. To close that version of the iHeartRadio application I had to force quit the application – which was crazy!

Currently, the iHeartRadio app includes an Exit App option, buried inside the Settings screen:

I use the UHC Motion application about twice a month to sync my daily steps for Health Savings Account purposes. The application provides an easy way to review my steps for the day (as shown below) and for the month, but it lacks the ability to easily exit the application. Instead, I must hit the back button on my mobile device what appears to be a million times before the application closes.

If I check the settings there is a Log Out option, but I don’t think that I want to log out … especially since that action does not close the application either.

In both cases, how hard is it to place an exit/close option on the main screen or to require only a single press of the back button?

Conclusion

The importance of a good UI/UX design is equally as important as the product or service being provided by the application. I think it is important for development teams to understand cases where:

  • Default selections can be set, cutting down on predictable functionality that is required.
  • The UI/UX and developers share common tooling.
  • Applications include the basic functionality to minimize end-user frustration.

These are just three examples of how common sense and collaboration can lead to a much better user experience.

So you want to be a software developer.

Being a software developer is a pretty great job for a lot of reasons. One of the biggest is the constant change of pace—one minute you’re working on a basic programming task; the next, you’re tackling an incredibly complex problem. It keeps you on your toes, and you never know what to expect.

Some days you’ll be mowing down a project with new features every couple of hours, and the next thing you know you’re working on an application-breaking bug for the next three weeks.

The point is, it can get crazy. If you’re one to give up easily, it might not be for you.

But for those with the right amount of grit, hunting down solutions to development problems can be immensely gratifying. Whether you get your answer from a developer with 20 years’ experience or from a ninth-grader on stack overflow, there’s always a solution for your problem—and it’s always rewarding to find them.

For me, the best part of being a developer is that feeling of utter victory you get when fixing an issue or building a new feature. This job is pure problem-solving, and it provides a huge feeling of accomplishment. It’s a daily challenge, but you never stop learning—and it doesn’t hurt that working as a software developer increases your skillset and value to just about any employer.

CleanSlate is a place where you’re surrounded by experienced developers in an environment built for productivity. With food and drinks, a basketball hoop, a pool table, and other great perks, you’ll find that our workplace is geared towards the employee’s comfort and enjoyment. While this might not be true of all development shops, many have this type of laid-back, relaxed atmosphere, and it’s a great perk of the job.

Another perk that many developers enjoy is flexibility. Here, you can come into work and leave whenever you prefer—you can basically make your own schedule so long as you get your work done. You can even work from home in many cases. It’s easy to see why CleanSlate was named one of the Best Place to Work in Indiana in 2017!

At the end of the day, being a software developer is a great job with a lot of responsibility and flexibility. In addition to making your own schedule, it’s up to you to decide when an application is stable and finished. Of course, when something goes wrong after you’ve released it, there’s nobody to blame but you—which makes it incredibly important to do excellent, careful work.

Then again, if you’ve been a software developer for long, you already know that no matter how careful you are, issues inevitably pop up with applications. But hey, that’s why they keep us developers around, right?

Want to learn about employment opportunities at CleanSlate? Check out our careers. And if you have any questions about becoming a software developer, contact us anytime!

The growing need for API lifecycle management.

The growing need for API lifecycle management.

With the use of application program interfaces (APIs) becoming more common in recent years, companies are experiencing an increasing need for API lifecycle management services. API lifecycle management has three basic components:

  • Design: Focuses on the typical development lifecycle, building upon features the RAML specification provides
  • Implement: Handles the testing and validation of the API
  • Manage: Takes care of securing, deploying, monitoring, and managing the API

Working as a freelance writer and zone leader for DZone.com, I recently created and published the following RefCard about API lifecycle management, which you can download as a PDF at the bottom of this page. The RefCard covers topics including an explanation of APIs, interface modeling, interface contracts, API security, RAML, API versioning, and more.

CleanSlate has a long history of API development and a great understanding of API lifecycle management. We’re available to assist your organization with architecture, design, development, deployment, support, or whatever your API needs might be. Contact us today to find out more.

DOWNLOAD THE REFCARD