Skip to main content

The Conversion: UI / UX Plan - Trip Creation

Application user interfaces usually design themselves. Instructional information goes at the top of the pages as well as any string filters. Distinctive filters are located along the left or right side.  Lists are displayed in a table with the most important columns on the left and least important on the right.  Remove and delete options are almost always on the far right such that the user will not accidentally click on the icon.

User experience (UX) gets a bit more tricky. Should we always prompt before deleting something?  Should the columns be sortable? Do we save the filter information so the user doesn't have to enter it in again? After a user modifies data, what kind of feedback should they get? Lots of questions can be asked - but the answer to each one generally means more coding and more maintenance. My biggest consideration when creating the UX is the technical aptitude of the user. That said, over the past few years, especially with the near complete migration to working with JSON data, I've been able to patternize user feedback, both in the data and display.  I still have a ways to go, but it's in the forefront of my programming mind instead of an afterthought. 

Creating TRIPS


This is what the TRIPS application currently looks like for users. The left side of the application uses a tree control (when they were all the rage) that lists the trips the user has access to.  For me, since I am an administrative user, I see all the trips.  As you can see, the list is a mess with no rhyme or reason as to it's ordering, though without looking I believe it's by the trip date.

To the left of the tree is where data entry occurs. There are tabs at the top of the panel to help users navigate to a informational area of the page such as the Overview, Participates, Sponsors, Activities, and Waivers.  The final tab is Notifications which allows the user to create and send emails to the participants of the trip.  

While this design has survived the test of time, mostly due to lack of competition, it certainly can be improved upon.  But now, seven years more experienced, I see some issues.  

First, the tree view panel is not collapsible.  After the user clicks on a trip, the panel persists and winds up being wasted space.  If the user had to move quickly from trip to trip, then this design may be ideal.  But it's unlikely they would ever need to do that.  And if they did, we would analyze why and provide them with a more specific UI.

Secondly, the data entry panel is collecting data for a few tables at the same time with only one save point.  From a UX standpoint, this can be problematic. If an error occurs, the user may have to enter everything in again. 

Thirdly, there isn't enough validation feedback to the user.  For example, when the user fills out the travel dates and times, the system doesn't check to see if one date is greater than other and warn the user.  It would be quite impossible to return before you left.  This creates a headache if the Returning Arrival date is not filled in because a trip will not be displayed for a participant if that date has already passed.  That means the participant can't fill out the required information in preparation for the trip.  Which then leads to a help desk ticket...most of you probably know the drill.

The New Plan

All of my applications have a landing.html page with a corresponding landing.js controller which is displayed with the user hits the application. This page is also the default route. For this project, it makes sense that the landing page contains the list of trips relevant to the user.  The list should be filterable by trip name so that in longer lists, the trip can be found quickly.  Column information can include the trip name, number of participants, trip type, destination, departure and return dates.  

The trip name will be a link to the next route which will be trip/:id.  This page, the user can create and edit the trip.  Emergency contacts, departure and arrival dates and times, and additional options will not be available until the trip has actually been created in the database.  And each one of those items will get their own save button.

Now let's depart and see where we end up after some coding.


Labels:

Comments

Post a Comment

Popular posts from this blog

The Conversion: MAIN.CFM

Within the current development pattern I have for our portal system, the main.cfm is the starting point for an application. For the most part, this is really boilerplate and serves to get the application off the ground. The way the portal works is that the user lands on the main menu page and provide with a menu of options. Each option is called a function and is assigned a unique id. When the user clicks on a menu option, the page is reloaded with the function id. The process checks to see if the user is actually allowed to have access to the function. It then accordingly looks up the path and displays the page via a . In the case of the TRIPS application, the included file is the main.cfm page for the application. So far the project looks like this: we have the folder structure defined with no files aside from the main.cfm. The main.cfm contains a few javascript includes, the overarching controller for the application as well as the route viewer. The next blog post will foc
Post a Comment
Read more

The Conversion: Trips for Keeps - Part 2

Ack! A few days off work and then updates to other applications that needed to be made has delayed more work on TRIPS. But we're back and ready to continue. In the last post , we started to build out the trip.html template and it's corresponding controller. The dataService was updated with an abstraction that would allow a CFC method to be called and data to be passed.  This post will focus on retrieving that data from the dataService to the CFC method. Before we get started, I thought it would be kind of cool to keep a count of the number of lines of code for the project.  I'm not sure if it will provide any insight, but it might be nice to compare the line count to the number of lines in the Flex application.  Rather than posting the counts on each blog post, I have created a separate post tracking the line count per post . In review, let's take a look at the dataService code that's going to call the Coldfusion function to save the trip information. this.p
Post a Comment
Read more

The Conversion: Introduction

While working as the senior level developer for a small liberal arts college, I've had the luxury of deciding the technology to be used internally for custom applications. When I first started, the college was using Coldfusion 7, HTML, and many MS Access databases. Over the course of the past 11 years, we've moved to Oracle, are on CF11, and utilizing AngularJS / Angular for our front ends.  Coldfusion is still doing the heavy lifting in interfacing with Oracle. During those 11 years, we also found ourselves developing Adobe (now Apache) Flex applications.  Flex was a great tool - easy to develop in and fairly easy to deploy when Flash was ubiquitous. But Flex was not great on mobile platforms.  Hence our move to Angular due to the idea that we wanted to give our users a rich web experience. So over the course of the past two years, we've been either retiring Flex applications altogether due to the direction that some departments have taken (read outside vendor); or ret
Post a Comment
Read more