Why Gmail is Great – It’s Software Developed With the End-User in Mind

Technology in our daily lives is ever-expanding, so it should follow that software development companies are absolutely booming – in fact, MarketLine states that the global software market is expected to grow to a whopping $357 billion dollar industry by 2015, which is quite a boost from the $265 billion total from 2010. Companies already deep in this industry will certainly want an edge over their competition, and there’s no better way to gain the trust of their customers than building great software.

When you think examples of truly magnificent software, what springs to mind? For me, Gmail takes the cake – a simple yet intuitive piece of software that makes the mundane task of writing and organizing e-mail truly effortless. Every aspect of the software is designed to be as easy-to-use as possible, while providing the ability to use a wide array of features. Many times it’s difficult to strike a balance between simplistic design and power, but Gmail hits the nail on the head.

tabs

One thing separating Gmail from the other e-mail services out there is their recent implementation of category tabs. I have to admit, when this feature was released, I wasn’t thrilled – my knee-jerk reaction was something along the lines of “Why complicate things by dividing my inbox? Why fix what’s not broken?” Oh, how young and foolish I was – this feature has quickly become one of my favorite aspects of Gmail, allowing me to quickly jump to different categories. Do I want to check out all of my social media updates? One click of the “Social” tab will do that! How about any promotional e-mails outlining that day’s sales? You guessed it, just hit the “Promotions” tab. Additionally, you don’t even have to specify which e-mail is sorted under which tab – Gmail does it automatically. Brilliant!

If you’ve ever mentioned attaching something in Gmail, and then completely forgot to attach it, you’re greeted with the following message:

attachfiles

This likely didn’t take much time to develop at all, yet has likely saved many people from looking foolish (first-hand experience here). While it isn’t likely to make or break which e-mail service you choose, these details really impresses you when you need them.

It’s this kind of usability that gives me confidence in Google’s software – I’d be more willing to try software that they develop, since I’m comfortable with the kind of work they do from prior experience. On the flip-side, had my Gmail experiences been full of frustration or lacked the features that I’ve come to expect, maybe I’d check out alternatives – in fact, it was my frustration with Yahoo!’s services that led me to leaving it behind in the first place. The bottom line – usability matters, and if you aren’t able to put out simple software with powerful features, your customers will find someone else who can.

Mirth Connect – Not Just HL7

Mirth Connect is an open source application used for healthcare data integrations, specifically designed for HL7 interfaces. It is widely used for transfer of health data between two parties in an order to results cycle. But what happens when you need to transfer data to another party who isn’t using an HL7 interface? Limiting your inbound/outbound capabilities to only the HL7 format may prevent adding new customers. But, adding a second interface/solution may not be worth the cost of adding the new customer. The need to invest in a second solution is resolved by the different Connector Types available within Mirth Connect.

In this post, I am going to show you an example of how to interface HL7 data to a Web Service. We implemented this back in 2012 for a client. Our client had an existing HL7 interface and was receiving HL7 orders, processing the claim, and sending back HL7 results. They had a potential customer also looking for an electronic data transfer. However, they were not using HL7 formatted data. The potential customer used an application that received data via a secured SOAP request. Because this was a single client, it was unlikely that building a separate interface specifically for the integration would be the best business decision. So, we explored the possibility of using existing functionality (Mirth Connect) to send data to this web service.

Mirth has the ability to transform data between multiple formats. In this case, we were able to use the JavaScript writer to take the necessary data points (via Source Transformers) and complete the proper SOAP request. While Mirth Connect offers a Web Service Connector Type, we found the best flexibility in the JavaScript writer, where you can customize all the functionality and you are not limited by the default behaviors of the template.

Check out our example below, and find more information on Mirth Connect here: http://www.mirthcorp.com/products/mirth-connect

// open a connection to the Web Service
var url = new java.net.URL("https://testinterface.com/Document.asmx");
var conn = url.openConnection();

// set the connection Timeout
var connectTimeout = 30000;

Here we are returning the XML from our Source tab under the Transformers. This isn’t the only way to do it, but this worked best for us and our current solution.

var messageString = messageObject.getEncodedData();

You could also do something like this, where you build out the Request XML and use Transformer variables that you include as XML Node Text

var messageString = "<SOAP:Body><Patient>" + messagePatient + "</Patient><MRN>" +  messageMRN + "</MRN></SOAP:Body>"

conn.setConnectTimeout(connectTimeout);

Here we needed to use Request Headers, which we found easier to setup in the JavaScript writer than the Web Service Connector.

conn.setRequestProperty("ID", "123");
conn.setRequestProperty("USERNAME", "ALGONQUIN");
conn.setRequestProperty("PASSWORD", "PASSWORD");
conn.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
conn.setDoOutput(true);

// Write our XML data to the Web Service URL
var outStream = conn.getOutputStream();
var objectStream = new java.io.OutputStreamWriter(outStream);
objectStream.write(messageString);
objectStream.flush();
objectStream.close();

var inStream = new java.io.BufferedReader(new java.io.InputStreamReader(conn.getInputStream()));

Consistency is Key!

A successful software development project is one that maintains consistency.

Whenever I visit a site or application that lacks consistency, it makes me uncomfortable. If each page acts differently from the others, it can end up confusing the user and feeling and looking poorly developed and unprofessional. A good development coding standard can help ensure a high level of consistency throughout an application and, once in place, these standards need to be followed. In the end, a good developer needs to make sure his/her final output reflects the standards and is built in a consistent, user-friendly way.

Another reason to adhere to a consistent, standard approach when developing a new application? Without it, the ongoing maintenance of the application will become cumbersome. If five developers are all coding differently, in their own style, you’ll eventually end up with an application that won’t lend itself to easy maintenance and might not function properly in the long run.

Remember, software often ends up being maintained by people who weren’t involved in the initial development of it! If you’ve ever been responsible for the upkeep on an application that was built with little adherence to quality standards, you know—it’s no fun! If the cost to upgrade or improve an inconsistent application becomes too high, it could force the client in a different direction.

I remember supporting an old ASP 3.0 application that was generally using the same connection information in a standard configuration file but had a few forms using hard coded values for the connection information. I couldn’t understand why, all of the sudden, some of these were breaking when my database information changed. This should have been a quick change to the configuration file, but turned out to be a pain!

When building front-end user interfaces, make sure you’re putting on your “end user” hat before you start working. When building out forms, do so in a consistent manner. If you have grids with search results on a screen, make sure all those grids are reporting the same data, and the same options, in the same way. Make sure all dates are displayed in the same format. All numeric/monetary fields should display consistently. Buttons with the same underlying logic should have labels that are consistent so the user can understand, from screen to screen, that button does the same job or accomplishes the same function. Make sure your form controls are organized in a pleasant manner—one that’s easy on the eyes and that can be tabbed through quickly. If it’s a data entry screen that users will be spending hours on each day, make sure the controls are aligned and sized properly allowing users to keep their focus on one part of the screen and providing a better overall user experience.

Before you start developing, take a look around! Review some of the screens in the system—there should be a common theme to the user interface; follow the same approach. Take a look at messaging and make sure you’re reporting information to end users in the same way. It won’t take long to get familiar with the site and then, once you start building your new feature, you’ll have a good context as to what it should look like. When you’re done developing, the new feature should look like existing ones.

One last note when testing your development—people still use IE! Do some browser testing to make sure your site is looking good and functioning well in the major browsers. If you’re only developing and testing only in your personal favorite, you’re not doing a full test. Sometimes, there are specific client requirements for the system you’re working on, so be sure you know what they are before you start. Some internal applications are written strictly for IE. Are there mobile requirements for this application? If so, be sure you’re testing those as well.

In the end, making sure your software development is done in a consistent matter is better for everyone in the long run. It will ensure the end product looks and feels like a well thought-out, professional piece of work!

Why Software Developers Make Good Spouses

 I often envy my wife because she married a software developer. She doesn’t realize how lucky she is! Come to think of it, I think everyone married to a software developer should applaud themselves for their wonderful choice.

Why am I being so boisterous about the idea of software developers as an ideal spouse?   I can give you thousands of reasons but, unless you’re a developer yourself, you probably won’t have the patience to read them all. So, I narrowed it down to the top 5:

 1.  They don’t mind being nagged:    

Developers like to build alerts into their software. Alerts to call them, text them, or interrupt them with a popup message.   They want to be alerted when something goes wrong, when something unusual happens, or simply, when the software completes a step. They build these alerts because they care and they love to be told when something needs to attention. So, if you are married to a software developer, nag away. If you are looking for a suitor and would like someone who won’t mind being nagged, narrow your search to developers only.

 2.  They like being told when they are wrong:  

Developers always like to trap for errors. They don’t rest until their software takes care of every possible error. They also make sure they log every error that occurs. No, it’s not that they love their mistakes. As I mentioned above, they just want to know if something went wrong so they can attend to it. If you have uncontrollable urges to tell people when they’re wrong, you should definitely look for a software developer as your life partner. Even if you’re just a casual observer who happens to have a keen eye for spotting mistakes, you should only look for software developers when searching match.com

 3.  They want to keep improving:

Developers love to release new and improved versions of their software. They feel obligated to add new features and improve existing functions and they usually release these new versions on a self-imposed cycle. If there’s nothing to improve, they’ll find something, even if it’s just updating the “look and feel.” Wouldn’t you love to have a spouse who wants to keep improving? Improving how they behave; improving how they look? It’s like marrying a “6” on a scale of 1 to 10 and watching them become a “10” in few years. How could you resist a prospect like that?

 4.  They know how to use all the new electronic gadgets:

Developers don’t shy away from switching to the latest smart phone. And they don’t hesitate to buy that new smart TV or replace that old computer. You can have the latest and the greatest gadgets just because you married a software developer! You’ll be the coolest kid in your group of friends! Go ahead…Brag about having all your music and videos in “the cloud” and being able to access them from your phone, tablet, home computer, work computer, TV, and even your new multi-function wrist watch. You’ll be as tech savvy as you want (and then some) with a software developer as your significant other. Are you one of those people who wanders around looking for an available computer you can check email or Facebook on? Stop wasting your time and marry a developer already. You’ll be connected, informed, and up to date, 24×7.

 5.  They can think…And they actually like to:

Don’t you just cringe when talking to someone who uses blunt phrases in response to your well-worded, profound statements? It’s the worst! If you like responses that are well thought-out, fully explained, and logical then you should limit yourself to only conversing with software developers. They’ll always give you precise, detailed answers and will be able to quote facts to support their opinions! Developers love Googling for answers (of course, we do…Google was built by developers!). If you overhear someone at a party proudly brag that their spouse “knows it all” you can bet they’re married to a software developer!

Live happily ever after…

I’m sure you can now can see what a wonderful life that awaits you if you choose to spend yours with a software developer. If you’re young, eligible, and smart, don’t settle for a boring business person, banker, fashion designer, athlete, or super model–find yourself a software developer and you’ll live happily ever after. Just ask my lucky, lucky wife!

Project Management & Relationships

Very often our blog contributors post great articles about things like managing expectations, solving problems for our clients, and gathering requirements from a client. All of the articles touch on topics that are very relevant to the work we do as consultants every day and one of the key aspects of doing each of these things well and, in turn, being good consultants, is to develop strong relationships with our clients.

Learn About the Key Players

When setting out on a project, one of my goals is to gather the requirements of the software that we’re being engaged to build. Beyond that, we need to understand who the decision makers are. These are often the people that we’ll being dealing with regularly to get things accomplished and make sure the project doesn’t stall due to indecision or missed deliverables. From the smallest task that requires a simple yes/no answer to a very important meeting to discuss a pivotal system process, as Development Managers, we’ll regularly engage the key decision makers to get all the necessary tasks completed.

As part of building a relationship with the parties involved in a project, we’re always trying to understand how our software will help their business. Clear communication is important to any project and we’ll often need to go the extra step of learning the company or industry-specific terminology that our clients use on a day-to-day basis. This helps us understand requests and communicate with each client most effectively.

Another important thing to learn about key parties for a project: what forces are driving their requests, decisions, and actions? From the start, we need to try to find what will make the project run smoothly and what could potentially hold the project back. Key questions here will cover topics like target dates, project budgets, and critical processes. These questions and their answers will help us do exactly what many of our other blog posts talk about–gather requirements, manage expectations, solve problems–all of which are crucial to the success of a project.

Row With, Not Against, the Third-Party Stream

What if your project requires you to work with someone in addition to your client? As a software development team, we regularly find ourselves in situations where we’re required to work with other vendors on tasks like integrating with other systems, adding/modifying code that isn’t ours, or working in an environment that we don’t have control over. These things can present potential hurdles, but we strive to do the best we can to navigate these waters because that’s what will make for the best possible experience and solution for our clients.

Much like when you’re building a relationship with a client, you’ll want to find and engage the key players of any third-party vendor and learn how best to work with them. Some of the best ways to ensure a friendly and professional relationship that meets the needs of your client and their project include:

  1. Asking early and often – If our development team needs something from a third party, whether it be access to a system or knowledge of existing code, we’ll do our best to get ahead by asking questions again and again, as soon as we know we’ll need the assistance.
  2. Understanding that third party teams have schedules, too – People often overlook the fact that other teams are fighting to meet their own deadlines outside of the project you’re working on together. We find the best way to stay on top of external deadlines is to repeatedly ask for tentative completion dates or turn-around timeframes from our co-vendors, so we can align our own goals and expectations and help better manage the goals and expectations of everyone involved in the project.
  3. Smiling – It sounds cheesy, but it can help. If you’re getting resistance from an outside party, do your best to smile when pushing for the answers you need. The best case scenario is that you establish a genuinely friendly relationship with your co-vendor but even if you don’t, getting the answers and info you need in a pleasant manner is always going to make it easier for you to work together successfully. And always remember to keep your client in the loop if you’re waiting for answers or status updates from another vendor.

Does Your Client Look at Your Development Team as a Partner?

As a developer, I often find myself in conversations about how people use applications, even outside of business hours! I frequently get the same feedback from friends/family that I do from new clients–they feel like the people who work in development (or “IT”) abandon them as quickly as possible. In developing good relationships with your client, make an effort to communicate that you’re “with them” on their project. The difference in saying something as minor as “We’ve accomplished” vs “I’ve accomplished” can have a big impact on that feeling. At Algonquin Studios, we take pride in being with our clients and doing the kind of relationship-building work discussed above gives us an extra sense of pride in what we’re able to accomplish. And, we hope that shows in all of our interactions with our clients.