So I really dropped the ball on blogging about the Travel System project or anything else for that matter. Planning for our annual user group conference began to take over any free time. Then updates to other application; then break; then yada, yada, yada.
But the TRIPS application made it out of development into pilot during the later part of the fall semester. All users were notified during that time the existing would be retired and were given the opportunity to use the new system. Because the data structure did not change, it was a very smooth transition. Whatever data was entered into one system, it was available in the other. The old Adobe Flex-based application was retired when we came back from break in early January. Thus far, I haven't heard any user complaints other than some uncertainty on how to use the new system. But we will see once the spring semester gets into full swing.
So what does it look like? Prior posts have described the development paradigms and some hints at the UI/UX. Therefore, I am not going to go into any coding specifics with this post. The intent here is to give you an idea of what the application looks like.
The trip detail page is divided into sides. The left side contains the general trip information and the trip participants. Each of the areas are likely to be the most dynamic in height depending on how verbose the user is in entering information and the number of participants. After a trip is set up, it's likely the left side of the page that the user will access most often.
The right side of the page can also grow depending on the number of stops and the detail of the trip activities. However, once the information is entered into those blocks, it is unlikely to change.
Each section of the application is organized via a list group into areas that make sense. General Trip Information, Participants, Stops (Arrivals and Departures), Activities, Sponsors, Waivers, and [Miscellaneous] Options.
Each block has an edit icon in the upper right corner of the page. I've used this UI/X in recently developed applications for the same user base, thus lending a degree of familiarity with the system. The Trip Participants doesn't have an edit option because it is the most utilized area of the application. The image below demonstrates editing the Trip Activities block.
Modifying a the Trip Participants requires knowing the name or id of the person. As the user enters text into the Name / ID field, the list is filtered down to those entries that match.
Throughout the application, there are trash can icons which indicate the ability to delete an entries whether it's a participant (as in the image above), activity, stop, etc.
In addition, users can edit the Content Body and Additional Information sections. But they should know some basic html before doing so.
But the TRIPS application made it out of development into pilot during the later part of the fall semester. All users were notified during that time the existing would be retired and were given the opportunity to use the new system. Because the data structure did not change, it was a very smooth transition. Whatever data was entered into one system, it was available in the other. The old Adobe Flex-based application was retired when we came back from break in early January. Thus far, I haven't heard any user complaints other than some uncertainty on how to use the new system. But we will see once the spring semester gets into full swing.
So what does it look like? Prior posts have described the development paradigms and some hints at the UI/UX. Therefore, I am not going to go into any coding specifics with this post. The intent here is to give you an idea of what the application looks like.
The trip detail page is divided into sides. The left side contains the general trip information and the trip participants. Each of the areas are likely to be the most dynamic in height depending on how verbose the user is in entering information and the number of participants. After a trip is set up, it's likely the left side of the page that the user will access most often.
The right side of the page can also grow depending on the number of stops and the detail of the trip activities. However, once the information is entered into those blocks, it is unlikely to change.
Each section of the application is organized via a list group into areas that make sense. General Trip Information, Participants, Stops (Arrivals and Departures), Activities, Sponsors, Waivers, and [Miscellaneous] Options.
Each block has an edit icon in the upper right corner of the page. I've used this UI/X in recently developed applications for the same user base, thus lending a degree of familiarity with the system. The Trip Participants doesn't have an edit option because it is the most utilized area of the application. The image below demonstrates editing the Trip Activities block.
Modifying a the Trip Participants requires knowing the name or id of the person. As the user enters text into the Name / ID field, the list is filtered down to those entries that match.
Communication
One of the most important aspects of TRIPS is the ability to communicate with the Trip Participants. This is done via an interface that allows the user to select the information they want in the message and build upon those options.
The user can use the Population option to fill in the To addresses. The content section contains the text that was entered on the trip detail page. Clicking on the plus icon adds the text to the content body, while the minus icon removes the content. From a coding perspective this is handled via Javascript. Once the email has been built, the user clicks Send. They are offered a confirmation message and then the server sends the email.
The End. Finally.
That's it for the TRIPS application. Hopefully you enjoyed the posts and garnered something from them. In the future, rather than blogging about a specific application, I will probably stick to development concepts and / or specific algorithms.
All the best,
Terry
Terry
Comments
Post a Comment