This is a guest post blog from one of our DPCalendar users who wanted to integrate Airbnb into Joomla. It's a step by step tutorial how to connect these two systems using the iCal plugin available in the DPCalendar Standard version. With DPCalendar it is possible to present a single calendar view of a users holiday rental website with the popular Airbnb accommodation rental site, this article explains the steps involved in getting it up and running.
It is assumed at this point you have read and followed our instructions for getting started and have created your local calendar. It is also assumed you have a presence on the Airbnb website and have access to the user admin section. It is also worth understanding the different types of calendars is use, we will be using both a local native view and a subscribed view see here.
There are 2 steps involved in providing a single calendar view to both sites
After this step you will have a combined view of your DPCalendar calendar and Airbnb calendar within Joomla, which will refresh from Airbnb whenever a user loads your Joomla page. Lets assume we have setup our local DPCalendar and it has a title of "Local Calendar1" and we know how to create an event and for that event to be viewed on our site either by using a menu item or perhaps the mini module, what we now want to be able to do is to overlay that view with the content from the corresponding Airbnb calendar.
First we need to logon to our Airbnb admin area and take a copy of the Uri which we will need when we setup our Ical plugin.
You will then be provided with a Uri which you can now cut and paste into your Ical plugin settings.
Now we can go back to out Joomla site and open up the DPCalendar Ical plugin and proceed as follows.
We now have a link setup from the Joomla site to the Airbnb site, now we can add the calendar feed to our local calendar. In this example I'm using the mini calendar module, but the same applies using the menu item calendar display.
At this stage we now have a single view on our Joomla site of our local calendar AND the Airbnb calendar, the view of the Airbnb calendar will be refreshed when a user loads the page on our Joomla site, we now want to reflect any changes made to the DPCalendar back to the Airbnb calendar to complete the integration.
The steps to be performed are essentially the same steps as above, but instead of exporting from Airbnb, we now want to import.
First we need to obtain our DPCalendar Uri for our local native calendar, there are 2 options to find this:-
Now that we have our Uri, we can logon to our Airbnb admin area and copy the Uri into the calendar import setting.
Simply paste your Uri into the Calendar Address (URL) field, give your Calendar a name e.g. DPCalendar1 and press the Import button, the Airbnb calendar will now synch with your Joomla site and continue to do so automatically every few hours.
An entry exported from DPCalendar will appear on the Airbnb admin view as shown.
And on the front end guest view.
We now have a 2 way flow between our Joomla site and Airbnb, but there are some points worth remembering.
The advent of Web applications has an interesting effect on the venerable 4Ps of the traditional marketing mix concept (Product, Price, Place, Promotion), in that the single website (or mobile app) can be all 4 things at once. The problem is, of course, that having a single item perform multiple roles simultaneously can be tricky to handle.
For instance, a Web application’s product offering is often itself the service (or the set of services) which a particular website is offering, and hence has to be fully functional. However, newcomers to the site may not necessarily understand all the dimensions of that service, and will need to be taught how to navigate the application’s features. At the same time, the website also has to attract its target market by showcasing all the benefits of the service(s) as compared to its competitors. And above all, users have to be encouraged to sign up for the service.
So how should this juggling act be resolved? One of the more common user design (UX) patterns in use out there is called gradual engagement. In essence, gradual engagement is designed to slowly (but immediately) immerse a prospective user into interacting with the web application, by guiding the user through using the application with plenty of tooltips and helpful hints, while delaying the sign-up until towards the end. The idea is, as the name suggests, to gradually engage the user with your product or service in such a way that when the sign-up page is reached, it is seen as an almost organic and natural part of using the service – and by doing so, lowering the prospective user’s barriers towards the process.
Gradual engagement as a UX pattern has been around since the mid-to-late 2000s, and has seen a great deal of success in many scenarios. It has also been viewed with concern, because it could be seen as a form of bait-and-switch tactic if implemented incorrectly. Here are some factors to consider whether or not your website can deploy a form of gradual engagement:
Your web or mobile application is far more likely to benefit from using gradual engagement if it focuses on delivering a single service (e.g. Twitter), or a small set of closely-related services (e.g. Windows Central), instead of being a portal to an umbrella of not-necessarily-similar features (e.g. Microsoft Live).
Gradual engagement works well when your prospective users can see immediate results from using your web application. This allows you to build rapport quickly with them and increases their engagement with the application. It does not matter whether the ultimate fulfilment of the application comes later (e.g. online shopping), as long as the process is seen to have immediate effects (e.g. items are added to a shopping cart, which can be edited without navigating away from the main shopping page).
The easier you make it for your prospective users to get started doing what they came to you to do, the easier it will be for them to continue onwards and stay engaged with your service. Providing helpful hints and tips on the salient features of your application as they progress through will help, as will an analysis on the application’s design itself.
Many mobile games that are free-to-play (especially endless runners) use the process of gradual engagement to encourage players to keep playing and bring them on board the gaming experience. Only later, once they’ve started to enjoy the game, are they introduced to the in-app purchases or sign-in features. Which other Web or mobile applications have you seen use gradual engagement?
One of the most requested feature for DPCalendar was a more enhanced ticketing workflow. In DPCalendar 5.3, we completely revamped the former attending functionality into a fully featured booking and ticketing workflow. Additionally we refactored the payment gateways to be based on Omnipay, which allows us to implement new payment gateways faster. With over 50 cases solved, working hundreds of hours on the next generation of DPCalendar, we are very proud to publish DPCalendar 5.3 to to the public! Read on about more information of the new features.
If the user books now an event, a whole process is started to trigger payment gateways and create tickets. More notifications E-Mails (eg. to the author) are sent out with important information embedded into the mail content, the ticket is attached as PDF and the event can be imported from the mail into the mail app of the attendee. Multiple tickets can be booked and the prices are reflected directly on the booking mask.
To get a quick overview about the status of the tickets of an event, the author or the admins have a direct link to the tickets, where they can see who has paid and who not. If the author wants to invite some registered users and invite button allows to send out invitations to individual users or whole user groups. The booking is getting the state invited and the user has the possibility to decline or accept the invitation.
The ticketing system is made the way that also none registered users can book seats for events. This means that the contact to the attendee is almost lost after the booking is made. To turn your attendees into followers of your site, we implemented the concept of gradual engagement. This means that after the booking is done, DPCalendar is offering to create an account on your site, to turn the visitor into a user immediately.
After the booking is done and the tickets got paid (if needed), the attendee is getting access to the tickets itself. The attendee can change the address on the ticket and the reminder time before the event happens. Below the details a QR code is displayed. Is the ticket printed out, the guard on the event can scan it and if logged into the web site, the ticket will be marked as checked in. This means if a second visitor is coming with the same ticket, the entrance is not allowed. Additionally a ticket is getting a seat number to easily identify the place the ticket belongs to.
If an event has a price set, then the visitor needs to do a payment. Payments are implemented through Joomla plugins which can be configured in the Joomla plug in manager. We supported till now manual (wire) payments, Paypal or Stripe for credit card payments. Additionally we implemented 2checkout as new payment gateway. The visitor will be redirected directly to the 2checkout site for safe payments. After the payment is done an invoice is sent to the attendee. On the new booking menu item, the user can download later the invoices again as PDF file if needed.
This is only the beginning of a bigger change in the attending/booking feature of DPCalendar. In 2016 we have plans to introduce multiple prices per event, add more payment gateways and to introudce new views like a resource view. Stay tuned for more cool features to come!
Beside that we fixed tons of minor bugs and did some small enhancements for a new experience for the Joomla calendar and event manager. The following list represents the full changelog of the new 5.3 version:
Kind regards
Allon Moritz aka laoneo
Founder of Digital Peak
The aim of DPFields is to be simple to use, low learning curve and seamless integrated. So we thought what should we do next. After some interesting discussions on the Joomla Day Germany and valuable feedback from the Joomla community we are proud to ship version 1.1.0 of DPFields with some amazing new stuff. The main new feature is that fields can be categorized and the output of a field is now rendered in layouts. Read on for more details about the new features.
When you edit an article, the custom fields of DPFields have been shown in a tab with the name "Fields". Now the admin can create "Field Categories" and assign the custom fields to these categories. On the edit mask of the article (or any other component which is integrated into DPFields), are tabs shown with the name of the category instead of the generic Fields name.
To keep backward compatibility if the field is not attached to a category, then the generic name is used as tab name.
The fields have been rendered in their own layout file, which could be easily overridden by the site admin. But the value itself was already set. Now is the value of a field prepared in it's own layout file, which can be overridden in the template. This allows the administrator to directly interfere into the process before a field is rendered. Additionally you can create layout overrides on a per type basis. This means you can just override the SQL custom fields.
To illustrate the power of that new feature, we will give you an example. If you have an image gallery plugin installed which creates an image gallery out of images in your site which do have a specific class name, then you can create an override of the imagelist layout as described here and give it the classname the gallery plugin needs.
DPFields renders the custom fields on the front end automatically during some Joomla event hooks. Which event is now not hard coded anymore, it can be defined in the system plugin settings. You can define that the fields should rendered directly after the title, before or after the description or not at all. Why not at all? If you want to integrate the fields into the description of the article, then you can add some easy to learn mustache code into the description and the fields will be rendered under your control. For not so techie people DPFields provides an editor button, which allows to search for custom fields and to directly enter them into the description.
Beside that we fixed some minor bugs and did some small enhancements for a new experience for Joomla custom fields. The following list represents the full changelog of the new 1.1 version:
Kind regards
Allon Moritz aka laoneo
Founder of Digital Peak
Since the beginning of DPCalendar, custom fields was high on the priority list of features to support. But somehow we wanted to do it right and Joomla was not ready for it. Now we have it! DPFields integrates seamless into DPCalendar (and DPCases, articles, users and modules). Defining your custom fields is now as easy as 123. But we did also some more interesting things in DPCalendar 5.2.
With DPFields we have created an extension suite which integrates seamless custom fields into DPCalendar. Just install DPFields as described here and you will see a new menu item called fields in the DPCalendar sidebar on your Joomla back end. The fields will be rendered on your Joomla front site. You can event customize the output of the fields, render them inside the event description or handle them completely in your layout override. All of that is described here.
You can even define custom fields for the attendee form and locations.
And now comes the burner, it is FREE of charge!!
It is now possible to cache external events (Google calendar, iCloud, Facebook, MS Exchange) in the database beside the Joomla cache. This enables to use the full SQL power while fetching the events. Additionally the server admin can set up a cron job to sync the external events in the back ground. Like that the events will never being fetched during a page request, which will dramatically improve the page speed and the user experience. You will find more details in the cache article on our knowledge base.
Locations are an important part of an event management extension. So we have improved the location management and maps all over DPCalendar. When loading external events, then the locations are imported into the DPCalendar Location Manager this allows the admin to do some adjustments when the locations are displayed for events like from your Google calendar or iCloud account. Additionally it is now possible to show a map on the list and blog view with the events. The markers of the events on the map are not reflecting the color of the event itself for better identification.
The event details view shows now extended location information like the full address, description and custom fields information of the location itself.
One of the strong features of DPCalendar was, is and will ever be the seamless integration into Joomla. On the back end it looks like the article manager and on the front it uses the Bootstrap commands as every extension does, to fully leverage the mobile friendly aspect of your template. Joomla has introduced a smarter sidebar on the back end in Joomla 3.3. With DPCalendar 5.2, we set the minimum required Joomla version to 3.3 to fully integrate into the Joomla sidebar.
Nowadays almost every web site is connected to Facebook page and a Twitter account. Since a couple of releases we do support Twitter auto updates. Now we have the same for Facebook pages. You can define for every Facebook page which native events should publish status updates on the page timeline.
Some small improvements were made all over DPCalendar you would like. For example when you create an event on your Google calendar from within DPCalendar, the correct timezone is set. Or the images of the event can be set now also on the front form. This are only some of the enhancements in this new version.
The following list represents the full changelog of version 5.2:
Best Regards
Allon Moritz aka laoneo
Founder of Digital Peak
