Q&A with CleanSlate Senior UI/UX Consultant, Ronnie Fenwick

Ronnie Fenwick is CleanSlate’s Senior UI/UX Designer. His job consists of the planning, design, and execution of user interfaces and user experience designs. He can be found coordinating interface production with clients and other developers, working through UI/UX issues, developing features, and designing internal marketing executions. We asked him a few questions about his current work at CleanSlate, where he sees the future of UI/UX consulting, and advice he has for others in his field.

Q: What makes you excited about working for CleanSlate? Tell me something about a recent project you’ve been working on.

A: At CleanSlate, I appreciate the variety of different projects and technologies I get to use on any given day. We were recently engaged with a client to build out a medical sales app. It is a greenfield project with only a name. It has been very rewarding to see the excitement from that “First Look Feeling” as the brand took shape, and then the app come to life. I really get a sense of satisfaction helping others realize their software dreams.

Q: What advice do you have for someone entering your field right now? What are the most important hard and soft skills?

A: Be prepared to never stop learning. The whole industry changes technologies and tastes every few years. A good designer can work in their natural style; a great designer can work in any style. Learn a few extra skills such as front end development, motion graphics or copywriting. If you know how to build sites it will make you a better UI designer, and I would start there.  

I would say the most important hard skills are being a master at design software, staying current on new and emerging UI/UX patterns and learning how to effectively communicate visually. One of the biggest soft skills I developed over time is helping your client solve business pain points with UI/UX executions. Often times they come to you with a redesign or even a greenfield project, but what you are really solving are operations issues, or customer experience issues more so than just making a great interface. You need to learn how to ask the right questions, follow your instincts and be able to communicate effectively with a diverse roster of internal and external stakeholders.  

Q: What do you think the future of UI/UX consulting looks like?

A: I think the future of UI/UX looks really good. With the ubiquity of technology in our lives and the current climate of the pandemic, I think everyone realized just how important eCommerce is to the future of business. Additionally I think it has never been more clear how a good UX/UI strategy and execution is to users adopting your software into their daily lives or buying from a store online. For the last 15 years, often times your first impression to a customer has been via a digital medium. I have always believed this is one of the most important factors to finding success online, but it has not always had good representation in the project scope. However, I think the larger market in general has caught up to this thinking. I can see it in the emphasis put on UI/UX in the last 6-7 years, versus what it looked like in the earlier part of my career.

Q: What was/is your favorite quarantine activity?

A: I love to golf. I get to be outside enjoying nature, getting some exercise, and I can maintain a safe distance from others while doing it.

Q: What is your favorite thing to do to relax in your downtime?

A: I enjoy hanging out with my family, playing golf and riding my motorcycle.

AWS Webinar: Cloud Migration Strategies

AWS Webinar: Cloud Migration Strategies

Migrating out of the data center and into the Cloud can transform your business, but it’s critical to approach your migration strategically and with the right resources and tools.

To learn how to migrate to the cloud with confidence, please join the leadership team from AWS, cloud assessment specialists CloudChomp and Advanced Consulting Partner CleanSlate for an informative webinar.

We will discuss:

  • Economics of moving to the cloud
  • How to gain more visibility into current on premise assets and cost (TCO)
  • How to determine the costs to run current workloads in AWS
  • What is Return on Investment (ROI) to migrate
  • Hear from our clients – case study

Careful planning ensures you can meet migration goals, optimize your TCO and benefit from the many AWS services at your fingertips. So, please join us for this exciting and informative webinar!

 

REGISTRATION IS CLOSED

 

August 13th, 2020

12:00 – 1:00 PM ET

On-demand viewing of live event will be available after the event

Featured Speakers

Douglas Gallagher

 Business Development Manager

 AWS

 

Chris Seitz

Director of Cloud Services

CleanSlate

David Pulaski

CEO

CloudChomp

CleanSlate Technology Group Achieves AWS Partner Network Advanced Consulting Status

Milestone demonstrates the company’s ongoing commitment to drive business value leveraging AWS expertise for clients in the Midwest Region

CleanSlate, a full-service cloud transformation agency, announced today that it has achieved Advanced Consulting Partner status in the Amazon Web Services (AWS) Partner Network (APN). Reaching the Advanced tier status requires the demonstration of expertise and successful delivery of AWS solutions. CleanSlate joined the AWS Partner Network in 2018 and has since experienced exceptional growth in the delivery of AWS cloud-based services. Advanced Partnership tier designation is also a recognition of CleanSlate’s commitment to client success and satisfaction by obtaining the full value from their AWS investment. CleanSlate’s Chief Operating Officer Chris Konow stated, “While we are excited about this achievement and the growth of our company, we are even more excited to receive exceptional feedback from our clients regarding the delivery of modern AWS cloud solutions.” 

The cloud is having measurable effects on businesses who are choosing to embrace the digital transformation. For example, some researchers are predicting as much as 20-30% improvement in time to market. CleanSlate has seen similar significant results – including a cloud implementation which resulted in 80% reduction in time to provision infrastructure environments using AWS services. Cloud transformation requires AWS expertise and experience – a big part of what CleanSlate brings to clients. “Our team of consultants are a top-notch group of certified engineers, architects and consultants. Every day I am excited to see the innovation and advanced technology we are providing our clients with AWS solutions. And our team is growing, which is also very exciting as well. Together with AWS, we will continue our commitment to improve our clients’ business by leveraging AWS and cloud transformation.”

 

Additional Resources 

About CleanSlate TG 

Founded in 2000, CleanSlate is a privately held consulting company headquartered in Indianapolis, Indiana. CleanSlate’s dedicated practices specialized in the delivery of Cloud, Enterprise Integration, and Salesforce consulting services. Our mission is to provide a clear pathway for client success by combining strategy, solutions and technical expertise. This approach makes it easy for our clients to adopt leading edge cloud solutions in a manner that accelerates business outcomes.

 

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.