Design a new base template from scratch to allow for better diversity and creativity in OnPoint's user interfaces while improving on UX
October, 4th 2016 - Employment at OnPoint and analysis of the base package begins
Client: OnPoint Digital Skills: Adobe XD, Photoshop, HTML5, CSS, JS
At OnPoint Digital, I redesigned the existing templates used for our eLearning Management Software, used by companies such as JP Morgan Chase, to provide more consistent design language, better accessibility, easier access to content, better responsive design, and arguably better visual design. This was in an effort to revitalize an aesthetic that was with the company for the previous 5-10 years, and introduce new template candidates to the portfolio of templates available to customers. My newly designed template is now the premier standard used in all RFPs and used in most client portals.
Reference Package Study
Left Nav Slide Treatment
When things move on screen, the eye will detect those movements first before anything else. Secondary to movement, size, color, and shape changes are the next element changes that will draw the eye.
Currently, when expanding the left nav menu, this is the result:
Practically the entire screen will move, almost as if you were scrolling horizontally. This detracts significantly from what the left navigation menu is trying to do: allow for quick, easy access to major parts of the UI. This is because of the amount of things on the screen that are moving. It doesn’t allow the eye to actually focus on the real change: the left nav opening.
If this first experience was an exit on a highway, there would be no off-ramp. It would be a 90 degree turn you take going 70 mph that dumps you off on the street. Not so much fun when you are a passenger in the car.
What the highway should have is a gradual turn that gently transfers the driver from going straight down the highway, into a pleasant curve that allows for the driver to see what’s up ahead and figure out where he is going next.
A very subtle animation is included to allow for a few frames of motion instead of an abrupt pop-in like the current functionality. This also helps sells the idea that it is a “drawer” that is always present and will pop it’s head in when it’s needed, not just barrel through your interface.
Often times, mockups will have action buttons that match company branding and/or other colors on the UI.
Here you can see that both the completion filters and the action buttons hold the same visual weight in terms of color. Both are considered “primary” actions and the only differentiator is the size and placement of the buttons, along with the filter’s toggled “enabled” status in the case of Not Attempted.
First, let’s tackle the action buttons. The action buttons are by far the most commonly used buttons in our UIs. It’s important that when they are being used that their state is clear at all times.
There are three main states: normal, hover, and active. Currently, our normal state is a saturated orange and includes a bevel effect using borders. Hover changes the color to a dark purple and loses the bevel. Active is the exact same as hover. Providing an experience that visually maps to a user’s expectations of how an element would work will keep a user focused on the interactions he is making and not distracted by unexpected changes in an element.
In the case of three filter toggles, there is no confusion as to which button is pressed: it’s always the odd one out. However, when there are only two options, there must be some clear differentiator to ensure the user that one is selected over another.
By beveling the sides when hovered but keeping the button flat when normal, an illusion is created that makes the user feel as though the button is responding to the presence of the cursor. Another way to do this would be to make the button actually “float” with a little box-shadow and by lightening the button slightly.
A method to differentiate between toggled states is through a simple color (and styling) change between the states in order for the user to see a difference at a glance.
In this mockup, you can determine which button is being pressed because there are visual cues built into the active state that makes the eye read the colored button as being “filled”.
What this also allows is the visual emphasis of the filter buttons to be lowered, while they are important to the functionality of the page, do not need to hold the same amount of attention as the action buttons do at any given moment. The only important filter button is the active one, so ensuring that it still stands out is important, but should be second in line to the action buttons.
From here, let’s break down how to fulfill all of our requirements for this set of filter buttons. Begin by making the buttons shades of grey or white as in a wireframe. This will de-emphasize their presence on the screen, but the white space and contrasting grey will help keep it legible at a glance. Additionally, you could see how even just making the unselected buttons white would allow for the buttons to be sized-down considerably, allowing for dropdowns and other filter options to be added to the row.
By simply adding a 1px border around the buttons and setting the button’s background the same as the surrounding background color gives you the “un-filled” bubble look, which is a very common convention (we even use it in our completion status icons!)
If one insists that the filter buttons must match the primary or other branding colors, the best alternative would be to follow the above design, but instead replace the grey with the intended color, and the border colors to match. This is not ideal, as it draws too much emphasis.
The best solution is to disassociate the filters from the primary color since it is not the primary action, and knock it down to the secondary color, in this case, purple.
This will keep the visual interest of the UI by including a color, but maintain the separation of the primary action from secondary actions all while indicating clearly which filter option is selected.
When it comes to mobile, there is no hover state, so the difference between button states is binary. With the methods described above, the same buttons will work both on web and mobile.
Wrapper Height and UI Real Estate
Currently our UIs are designed to match the most common screen resolution of 1366×768 which is common amongst small business laptops like the Dell Latitude and other similar small, typically 13” or 14” screens. Conversely, Apple’s smallest laptop, the 12” MacBook (not the Pro) from 2015, their first update to the series since 2010, still has a native screen resolution of 2304x1440. The Pro series of MacBooks seem to be more common among professionals, and even the 13” MacBook Pro has had a native resolution of 2560x1600 since 2012. And this is just talking about laptops, let alone desktop monitors. A native resolution of 1920x1080 on desktop monitors have been extremely common since 2012, and screens are only getting larger. The point here is that while the most common screen size is 1366x768, this is an average taken from a much scope that is much larger than our user demographic.
Because of the nature of eLearning software, our UIs are very content driven, meaning a lot of information is presented at any given time.
We can measure how much space is used by analysing how many pixels take up various parts of the interface. I’ve broken down two websites into five sections: Content, Navigation, Top/Bottom Margins, Gutter (left and right margins), and the browser/OS interface. Since the browser and OS always takes up the same amount of space no matter what the website is, we can eliminate that selection of pixels. It normally takes up roughly 12% of the total screen real estate.
You can see that on OPUI, the left and the right gutters are a respectable size and take up about 35% of the total webpage. While this appears to be large, it is accepted to include a gutter, as it is best to have all of or the majority of the webpage’s content in direct view, which should be the center ~2/3rds of the webpage, which is used by content and navigation. This leaves us with almost 14% of the webpage being used by the top and bottom margins. Together, the navigation and content fill 1250x750, which is very close to our previously mentioned average screen size of 1366x768.
What including the top/bottom margin is doing is essentially putting a frame of unusable space on a screen that we already know is likely larger than the average screen height of 768 pixels.
Consider this screenshot of an old Youtube video. In video production, when the aspect ratio of a video is different than that of the player, you will gain a section of black, called a letterbox if the player aspect ratio is taller than the video aspect ratio is wide, or a pillarbox if the player aspect ratio is wider than the video aspect ratio is tall. A letterbox effect is much more common than a pillarbox since screens tend to be getting wider more than they grow tall, making the video stretch to the full width before it reaches the top and bottom edges. The problem is, sometimes video editors will include a letterbox in their videos that have an aspect ratio that is more square than a lot of video players to make the video look stylish. When the video gets loaded into the player, the video appears to have both a letterbox and a pillarbox, even though the video looks as if it could scale up more to fill the player. This is not an enjoyable experience, and I know that I would not want to be watching my puppy running on the beach on a screen 14% smaller than it has to be. I paid for the full screen, and by George I will use it. By including this top and bottom margin standard, we are essentially adding a letterbox to our UI instead of letting the webpage use the full real estate of the browser, much like our poor puppy in the video.
On pages that are content heavy, such as catalogs, games, search results, forums, and even the home page, it is a better experience to allow the user’s screen of choice to dictate the amount of room the content will fill, rather than the UI holding back.
Finally, there are UI tricks that can be pulled from Facebook, LinkedIn and even the OnPoint website. By extending the top navigation bar beyond the width of the content and to the width of the screen, the UI creates this sense of being much larger than it really is. It makes the webpage feel as though it has presence on the monitor, much like it does when it’s viewed at the average screen resolution of 1366×768.
Using these principals, here is what OPUI can transform into. This is certainly a UI that is far more contemporary and enjoyable to look at on a modern screen.
Nesting Content Navigation
With the introduction of Curriculum, there are now two kinds of content that act as grouping elements or containers for content. Skill Profiles will hold any kind of assignable content, such as Nuggets, Courses, Assessment Sets, etc. Curriculum will hold Skill Profiles as well as individual pieces of assignable content. In addition to these two kinds of content container, the hierarchy is another way to group content, and has the added benefit of being an easy way to further categorize learners into subgroups of learning.
These kinds of groupings create nested content. Content within groups within groups. In the past, we’ve used a few different ways to display these nests of content. In most cases, navigating into a Skill Profile or Curriculum will cause a page flip, often creating breadcrumbs near the title bar for easier back-navigation. Sometimes a collapsing container is used, like in the current base package’s Learning Paths page.
Existing UI Breakdown
In order to create a better user experience, it was important to dissect the existing template. This will help get a better understanding of the information architecture, as well as the elements that form the interface.
Wireframes and Development
It was important to the clients and leadership to provide multiple templates in which an interface could be built from. The primary goal was to provide a new way to navigate, as well as introduce new methods to display content. Development began by first sketching designs for pages and components, creating wireframes, then mid-fidelity mockups.
Based on the wireframes above, the following prototype was developed to give an idea of some simple interactions, the layout of components, and animations the template could feature.