Written by Tribalogic Administrator
We've started using a new support system, which allows us to grant our clients and members of the public access to check out their support tickets, and to browse and submit to forums. We'll also post regular updates about new features, system maintainence, etc.
The forums are there to educate and help people with our software, so its a good place to look for "Solutions" and "Tips and Tricks."
Written by Robin Morris
The Edinburgh Address have launched their new web site, based upon Tribalogic technologies in partnership with Rental Reserve.
Written by Tribalogic Administrator
The last release we ended up releasing a fair few changes earlier than we intended. This was all mainly fallout due to our office move which meant we had to suspend one of the bigger changes to the booking system until the following week (as our scheduled office downtime on the Friday following the release would have meant that fixing any issue that arose would have been pretty tricky!)
So the big change to the booking system was rolled out a little late and one of our core developers Gerome is off on a two week holiday, and therefore less major changes happened this time around.
One feature that has been implemented is to allow Group Managers to create other Group Managers. This is quite useful but will probably be subject to change as we overhaul the whole user and authentication system in the next few months (that's the current plan at any rate!).
Numerous incremental improvements were made to the new mapping UI, including the use of miles vs. km (brand preference) and ordering the search results by distance. Some tweaks still need to be done there (to accommodate other ordering preferences - distance kinda overrides them all right now!).
We also made use of the new import mechanism deployed last time round to import several sets of data for various customers. We also added some new geographic regions to our Tribalogic database, which allows us to support customers in America and Russia.
Written by Tribalogic Administrator
After several years in the South Side of Edinburgh, the Tribalogic team boldly strutted over to the prestigious West End to begin a new chapter in Rutland Square. The office comprises the second floor of a Georgian Townhouse. The extra rooms give us great flexibility as far as meetings and working in teams go, and after working in a basement for so many years, the natural daylight is lifting our hitherto sun-starved souls.
Most importantly, we are now based in a location that couldn't really be more central, and we're sure that clients coming to Edinburgh to visit us will appreciate it its location and surrounding facilities.
See below for the new address - phone no. remains the same - 0845 86 212 86
Written by Tribalogic Administrator
One new feature that went out was a preview version of the new interactive search interface. This interface will allow the user to pick a very specific geographic area in which to search via the Google Maps API. This interface can be activated via a layout but for preview purposes it can also be activated via the showsearch=1 GET argument.
It essentially adds an extra link next to the map which will freeze out the rest of the page and allow for a user to drag the map to the location they want to search in. A ring of a pre-defined list of radii is drawn over the map to aid the area selection.
In addition a list of place names from http://www.geonames.org/ has been imported and can list the nearby locations as well as providing a search interface to allow a user to enter a place name. The geonames.org data is pretty nice. It show all sorts of interesting things (for the first time I know where some of the offshore locations mentioned in The Shipping Forecast are!!), so the hardest thing is actually filtering out the stuff that people wont use! The search matches and nearby locations are display in order of "best match" and proximity to the centre of the map respectively. Using the population information in the geonames database we can show the results in a tag cloud format with more populated areas shown larger. This allows people to find the most likely/best known locations more easily.
The UI stuff was all implemented using jQuery with some Ajax callbacks to do the geoname queries. Moving the map code over to jQuery, despite the time delays to get going, was definitely worth while. All the data is stored as MySQL geometric types to allow for fast searching.
The new interface works pretty well but is still undergoing some tweaks.
The booking system under went another major architectural change in our ongoing efforts to make the system more flexible and powerful. The rather rigid underlying system of how rules apply to rates (and thus how extras, legals and other "applied" items) has been totally overhauled. In order to maintain backwards compatibility only minor surface changes are visible, but this change is a major step forward and will pave the way for discrete discounts and other time critical extras.
Previously all discounts, extras, payment profiles, reservation profiles etc. applied to rates which had a defined rate period. If you booked half way through a rate period, the applied item could not vary. Now the applied items can vary independently of rate periods which means there is no need to define unnatural/unnecessary rate periods (i.e. when the rate doesn't actually change from one rate period to the next!) just to have fine grained application.
Further changes to the booking system are coming up, including the discrete application of extras (i.e. an extra that only applies for a portion of the time the whole booking spans). The biggest problem here will be the GUI changes in order to present this to the user in an appropriate way. A flag will enable the old behaviour.
Some additional work has gone in to allowing various regional information to be extracted from the search and injected into page titles and meta tags. Several preferences allow for titles on listing pages to be changed when region data is present (with a fallback title for when it is not).
The Booking Search system introduced a few releases back now has it's usage tracked. New reports will be written to allow this data to be extracted.
Accommodation listings can now be hidden from search results. This allows those operating the system to hide a particular item (perhaps if sold?) and reactivate it later. The sale status of "sold" used to hide such items from the listing, but we had requests from user that showing their sold properties was often a good marketing ploy. The new controls now offer full flexibility.
We also deploy a (for now) internal tool that we can use to perform Bulk Uploads. In the past, any data load required us to write (or modify) a script to perform the necessary work. As we expand and take on more clients the need for a generic interface has increased. We really should have done this a while ago but better late than never. We will keep this as an internal tool for now but a public version for our clients will be available at some point in the future.
A major change in this release related to the complete rework of the Javascript support in the directory. Some legacy code still remains that uses the Prototype and YUI libraries, but this will be phased out shortly. jQuery has been selected as the client-side javascript library of choice due to its wide range of plugins and its active community following. All websites now include both Prototype and jQuery to avoid conflicts while prototype is phased out. In addition to these structural changes, all the mapping code has been fully rewritten to be based on jQuery and more specifically the jMaps jQuery plugin. Tribalogic has contacted the author of the jMaps plugin and are planning on working together to add new features as part of our ongoing development.
By adopting jQuery, Tribalogic will be able to rapidly deploy rich client-side features in the future.
A second major improvement in this release concerns the Online Booking Platform. As clients demanded more flexiblity in their pricing models, Tribalogic has improved the "Extras" system to be able to cope with more supplements and subsidies. Over time this capability has come to replicate and surpass the functionality offered by the "Rate Adjustments" system. Rate Adjustments are three fold: Adjustment, Relative Adjustment and Discount. The first two affect the "Rates" in the system. The third is an additional item included on a booking. A discount is very similar to and Extra and this release sees this consolidation completed with support for Discounts transparently merged with Extras. Internally all run-time code to calculate what discounts to add to a booking has been removed. During consolidation, all Discounts specified in the Rate Adjustments Information Record are transparently mapped to Extras. The user experience and the pricing is unaffected but the code is now simplermore efficient. Newer models of automatic pricing (e.g. based on how many people are in the party) can now be added to "Discounts" which was not possible previously.
All users using the old formats should be completely unaware of this change.
In addition to these internal changes, we now have the ability to specify an extra (e.g. a discount) based on a "Yield Profile" rule: namely offer a discount if the person books within a certain period of holiday uptake: e.g. Book a holiday for this weekend and get a 10% discount!
While Tribalogic has always been proud of the capabilities of our Booking System, we appreciate we have had a problem in the past relating to publicly available documentation. We acknowledge this failing and have embarked on a fresh drive to ensure that all documentation is up to date and available to those who need it. In addition to this we will begin a program of deprecation of (i.e. removing support for) older versions of our APIs. The previous lack of documentation meant that we really just had to continue supporting older code, but with this new focus on documentation, we will begin a program lasting approx. four to six months during which period we will help clients implement the latest versions and allow them time to deploy updates to their clients. While we will attempt to ensure we do not create unnecessary API churn, we will use this opportunity to create a fresh basis for moving forward.
A number of smaller incremental bugfixes were also included in this update including:
Written by Robin Morris
Written by Robin Morris
© Copyright Tribalogic Ltd. 2025
Registered in Scotland SC315153 | VAT Number: 898 0878 47