User Tools

Site Tools


updates:important-recent-changes-explained-by-our-ceo

Recently we have changed a lot of user interface in Leon, but the good news is that almost all major changes which affect daily usage of the application have been implemented. We are aware that some of you may have negative impression that we have done all of this without announcing much in advance, which caused a lot of troubles on your side. We would like to apologise for all of the inconvenience produced by these changes.

In this article we would like to let you know why we did all of this and why we strongly believe it will improve Leon's user experience in the near future.

These changes were necessary to ensure compatibility with the new Leon, which is coming in big steps now and to allow much improvement in Sales module that is going to be delivered shortly.

After analysing how Leon is used, we decided to make it in “one shot” - in the shortest possible period, not extending it over our standard release cycle. We announced these changes in a series of red links inside the application to ensure they will get the audience. Unfortunately, it couldn't be done slower or with wider consultation because one change affected other areas and once one was done, application required to do further changes as soon as possible. All stages “in between” would be unstable from the database structure's perspective.

At the moment we are focusing on making sure that there are no more glitches due to these changes. Airport Directory problem has been fixed and there should be no more major problems with it. We will shortly add possibility to add handling agent by you without asking us for this. We just need about 3 weeks for this to be completed. Our new Airport Directory is ready to accept custom handlers, we just didn't manage to make the user input for it yet. For the time being, please send your request about adding handler to support@leonsoftware.com

3.14 release of Leon has been the biggest release in Leon history. This was also the reason why we had to introduce so many 'live' changes. We have introduced completly new Airport Directory, new Handling Request features and much improvements to the OPS side of the new interface plus what is VERY important and cannot be seen - we have prepared database structure for further application growth and speed improvement (this is now our big concern - we want to make Leon faster for users).

At the very beginning of Leon, we were relying on the data structure which we called 'operation'. Operation is always series of legs but it is clearly visible that it means different things to different departments. For Sales - operation is a trip - series of legs sold to a particular customer (sometimes you call it job, sale, deal, etc.). For OPS operation is a series of legs performed on one aircraft in a single day. For maintenance operation counts as all legs between aircraft is released from home base and is back. So far our operation was the 'OPS' version of all of those mentioned above. This caused many problems with the interaction between Sales and OPS. I know that many of you got used to split/merge operations and got proficient in omitting this problem but the main problem is that later on, all other departments - Accounting, Cost Control, etc. have problem to reference to the same data. This was also the main reason why our Sales module is far from being perfect. We are aware that Sales module is now the key - soon all our hands will be on this module and since we have introduced these changes, it will be possible.

We have made this 'operation' error many years ago because at the very beginning Leon was mainly an OPS tool - we looked from OPS perspective. But more and more customers stared to use Leon and Sales departments were pushing us to do major improvement there and we wanted to fulfill these requirements.

All starts in Sales. Sales is the department which creates quotes and then adds trips to the scheduling software. For this reason, trip must be always related to the sales unit, so we have

SWITCHED OPERATION TO TRIP WHICH IS NOW FROM SALES PERSPECTIVE, NOT OPS.

This of course created many problems we had to address and we have addressed all of them over the recent month. Many areas in the application were based on the OPS operation philosophy so we had to change:

  • Adding flights from Planned Flights view. We know it works too slow and we wanted to simplify the code. It was very confusing that you have one series of legs in the first tab and could have completely other one in 'Quotation' window. We have trip now and it is all the same. Quoting is always related to your customer who at the end produces TRIP. For this reason we have changed this window and ALL NEW trips have the same legs as quotations. We didn't change past quotes,because it would affect your past data. The changed interface provides you with a clear relation, i.e. legs in a trip equal legs in quotation. Another thing is that editing trips from planned flights view is TOO SLOW and until the end of September, we will offer you a better, faster window. Read more here.
  • Printing documents from Flights List view. OPS was printing these documents by clicking on the operation number. But this produced documents for an entire operation (which for the time being was the 'OPS' operation so it was OK). After we have changed the operation to trip, printing documents for an entire trip for the crew didn't make sense so we had to introduce another way of printing them. Now OPS can select particular legs they want to print and this way it is much more flexible. We have introduced this change as the first one weeks ago.. Read more here.
  • Marking legs as changed. So far it was the flight order number which was red after any change. However, after introducing trips, this number was red on all legs in the trip, which made it very difficult to track particular changes. For this reason we have introduced the 'changed' mark to the first column highlight. Now this column is green (new) or orange (changed). Read morehere.
  • Handling requests - this function was always not ideal in Leon. Handling agents blamed us for the fact they didn't receive inbound and outbound times. For this reason we had to completely rewrite the entire module to make it work better and be integrated with new Leon. Read more here.
  • Saving journey logs. So far it was only possible to save entire series of legs after an operation was completed. When it was during one day, it was OK but since now trips can be in multiple days, it was not possible to save journey log progressively. We had to change it. Read more here.
  • Split/Merge - this was introduced mainly to allow OPS and Sales to workaround the problem, which was the fact that operation was not for an individual customer. Operators handled it in two ways - one group was creating operations as they would be trips (across multiple days) and then OPS had to chunk these operations into smaller pieces to be able to work with them. This way, the original grouping was destroyed and we couldn't use the trip data later (and for this reason quotation was totally independent from trips). The second group was creating operations already from OPS perspective and putting the same quote number in different operations to track the trip. Also split/merge was used to change aircraft registration inside the trip. We are now quickly solving this issue and in a few days you will be able to edit aircraft PER LEG. Splitting and merging trips will not be possible in the future because we would need to split and merge quotations in the same time (those two will represent the same legs). Splitting quotes makes a lot of trouble because each quote has its own unique number, unique customer, unique price, etc. Read more here.
  • Moving empty leg between trips - If we treat trips as sales units then often there is a triangle route, i.e. 1 - empty leg (a/c positioning to pick up pax), 2 - pax leg, 3 - empty leg (return to base). Empty legs are constantly being sent to broker platforms and when such empty leg has been sold, it needs to be moved to new trip. The function of moving legs between trips has been added for this purpose and acts instead of previous split/merge. It is not possible to do it from OPS screen because OPS don't manipulate trips (sales units). The function is available in Planned Flights view on the edit screen. Read more here.
  • We had to address the requirement of assigning different aircraft registrations in one trip. Sometimes a/c is AOG and this should not be the reason to split trips (this is still the same trip, just a/c needs to be replaced). For such cases now you modify aircraft both in Planned Flights view and in Flights List view.
  • Together with colour change (green ↔ yellow) you have complained about empty legs visibility. This had been changed to blue. Also we will make options (yellow) less visible because we heard complaints that this colour is to distracting.
  • And soon one more change. Many of you have been complaining about colour change in planned flights view. Now option is yellow and confirmed flights are green. And still there are many arguments that it is not intuitive. We of course will not revert to the previous version ;) Instead of this colour chaos, we have been proposed to create other, more intuitive logic and this logic is as follows:

ALL ACTIVITIES BEING NOT CONFIRMED WILL BE THE SAME COLOR BUT WITH STRIPES.

Please see the example below:

ZZZ.png

Before we implement this change, I would like to know your feedback. Please direct it to my email: pczubilinski@leonsoftware.com with the email subject 'colours'. If the idea is accepted, we would introduce the same rule for reservations.

I am sure all this changes will soon prove its usefulness. Thank you for your patience, understanding and support.

Pawel Czubilinski CEO, Leon Software pczubilinski@leonsoftwre.com

updates/important-recent-changes-explained-by-our-ceo.txt · Last modified: 2016/08/30 13:06 (external edit)