During the Liferay 6.2 development cycle many of you participated in BugSquad and the Community Beta programs in order to provide valuable feedback and bug reports. This worked really well and we got a lot of positive feedback from over 70 participants in the program - so guess what - we're doing it again for Liferay 7!

Liferay 7 Community Expedition

In keeping with Jorge's adventuring theme, let me be the first to introduce you to the Liferay 7 Community Expedition! The goal is to make sure Liferay 7 meets your needs, and the rest of the community, with the quality and consistency you'd expect. This time around the program will be hosted on the Liferay Developer Network which should give us a great-looking site, better coordination and better personalization. This expedition, should you accept the challenge, will take you on a journey from our current Milestones through the final release of Liferay 7 and possibly beyond. You'll experience firsthand the awesomeness going into Liferay and see why everyone is so pumped up for this major release. We will focus on major feature areas like Web Content Management, Staging, Collab & Doc Management, Business Productivity, UI Infrastructure, Administration, Dev Tooling, and much more! Check out the signup form when joining for more information about what we'll focus on for the next Milestone.

Joining the Expedition

By this point I know what you are thinking: "How can I help!". I'm glad you asked! As you know, we are doing a preview/milestone release of Liferay 7 every 2 months. We need your help to review the development of Liferay 7, try out the new features, hunt for bugs, and give your feedback on which Liferay relies so heavily. So here's what to do:

Sign up for the expedition. This lets us know who you are and more importantly lets us know what your interests are so we can customize your experience and get to know you better. Once you sign up, we'll send you more details.

When the Milestone is released, expedition organizers (new recruit but experienced Liferay guy Jamie Sammons and myself) will send a detailed list of what's new in the Milestone, and what to focus on, along with specific instructions about how to use the Milestone. Download the Milestone and read the instructions.

After trying out the Milestone, provide feedback on the Expedition Site (more information on this site after you sign up!).

If you run into problems, or have questions, don't despair! Expedition leaders (many of our community and engineering experts) will be identified for each release that will be more than happy to assist.

All participants that contribute to the release will receive a small gift for contributing (that's me over there --> modelling the 6.2 shirt!), to proudly show you were part of the Liferay 7 release. You'll also learn a lot about the release, and get to know many core developers in the community, establish lasting relationships with others in the community, learn a little, and perhaps share a little. It's going to be a lot of fun! And best of all, we are starting the expedition NOW! Liferay 7 Milestone 4 is out soon (this week or next) so there is no time to waste. Sign up for the Expedition and keep watching your Inbox, and thank you for helping to make Liferay 7 an amazing and revolutionary platform for our entire community! We look forward to your involvement in Milestone 4 and beyond!

This release is particularly noteworthy. Why is that? Well, if you attended DevCon in Germany last year, you probably don't remember it, but I promised you a regular 6-month community maintenance release cadence, starting with the 6.2 CE GA3 release on January 15th. Mind you, this presentation was over 2 months ago. Guess what today is! Yep, it's January 15th. We actually hit the promised date (pause here for applause). And you can expect another 6.2 CE release this summer, in mid-July. This will continue until the next major release (Liferay 7). This year we're going to do some really fun things in the community around the 7 release, so stay tuned for more info on that (or watch the video in its entirety).

Now, back to the topic of this post. This update corrects many issues found by our open source community and customers since the GA2 release (10 months ago). Our community and Liferay's continuous testing teams contributed to finding and fixing these bugs. Want to know more? Read on!

Release Naming

Following Liferay's official versioning scheme, this release is Liferay Portal 6.2 CE GA3. The internal version number is 6.2.2. Future CE releases of 6.2 will be designated GA4, GA5, .. and so on (assuming they are needed to fix issues, which is not always the case). See below for upgrade instructions from 6.2.x, 6.1.x, 6.0.x, and 5.x.

Downloads

You can find the 6.2 CE GA3 release on the usual liferay.com downloads page. If you need additional files (for example, the source code, or dependency libraries), you can find them on SourceForge as well.

Known Issues

One of the things you get with a regular release cycle is the peace of mind of knowing that releases don't have to be held up by minor issues - it can get fixed in the next release, and no one should have to suffer delays because of really minor issues. There are a couple of items we found during testing that were deemed not to be "showstoppers" and will likely be fixed in the next release.

Our community has been instrumental in identifying the areas of improvement, and we are constantly updating the documentation to fill in any gaps. Check out Rich's blog for more detail on how you can get involved.

Support Matrix

Liferay recently published the official compatibility matrix for 6.1 and 6.2. This is the official support matrix for our Enterprise Subscription customers, but it's a pretty good reference for CE as well. If you're wondering where Java 8 support is at, it's expected in the next release (we don't typically add new supported platform software in a maintenance release, and Java 8 wasn't ready when 6.2 was).

Liferay Marketplace

Most Liferay-authored Marketplace plugins were updated to support 6.2 GA1 when it was first released, and remain compatible with this updated GA3 release.

If you are a Marketplace Developer, and have authored a 6.2 CE GA1- or GA2-compatible app, you should ensure your app continues to work with this 6.2 CE GA3 release. It is Liferay's aim to remain compatible within a given release family, so in the unlikely event that your app works with GA2 but NOT GA3, you will need to make any necessary changes and re-submit, and let the Marketplace team know about any incompatibilities you discovered. Chances are you will have nothing to do (since you declared compatibility with 6.2.0+, which includes 6.2.2).

Bug Reporting

As always, the project continues to use issues.liferay.com to report and manage bug and feature requests. If you believe you have encountered a bug in the new release (shocking, I know), please be cognizant of the bug reporting standards and report your issue on issues.liferay.com, selecting the 6.2.2 CE GA3 release as the value for the Affects Version/s field.

Upgrading

Good news for those of you on 6.0 or prior! Liferay introduced the seamless upgrade feature with Liferay 6.1. Seamless upgrades allow Liferay to be upgraded more easily. In most cases, pointing the latest version of Liferay to the database of the older version is enough. There are some caveats though, so be sure to check out the Upgrading Liferay information on the Liferay Developer Network for more detail on upgrading to this release.

Getting Support

Support for Liferay 6.2 CE comes from the wonderful and active community, from which Liferay itself was nurtured into the enterprise offering it is today. Please visit the community pages to find out more about the myriad avenues through which you can get your questions answered, and check out the new Liferay Developer Network for technical resources during your Liferay journey.

Also note that customers on existing releases such as 6.0 and 6.1 continue to be professionally supported, and the documentation, source, and other ancillary data about these releases will remain in place.

What's Next

Of course we in the Liferay Community are interested in your take on the new features in Liferay 6.2 and the updates in this GA3 release. Work has already begun on the next evolution of Liferay, based on user feedback and community ideas. If you are interested in learning more about how you can get involved, put on your participation hat and dig in.

As I mentioned earlier, we will start doing regular open source releases of Liferay Portal every 6 months, until the next major release. So if you find bugs in this or previous releases, and want to up their priority to get them fixed, be sure to use JIRA and vote for your favorite issues!

Kudos!

This release was produced by Liferay's worldwide portal engineering team, and involved many hours of development, testing, writing documentation, translating, testing some more, and working with the wider Liferay community of customers, partners, and open source developers to incorporate all sorts of contributions, both big and small. We are glad you have chosen to use Liferay, and hope that it meets or exceeds your expectations!

In addition to Liferay's engineering staff, a special thanks goes to the many open source developers who volunteered their time and energy to help with the release, whether it was bugfixing, idea generation, documentation, translations, testing, or other contribution that helped to improve this release. Check out the Community Contributor Hall of Fame and be sure to thank them if you run across them in the community (or add your name if you have contributed and are not listed).

Today Liferay Cloud Services enters a new phase of its beta program - and now invites all of our community to participate in the Liferay Cloud Services Beta. If you'd like to try it out (and promise to give your feedback!), visit liferay.com/cloud-services and click "Get Started" to sign up (it's super easy!), install the agent on one or more servers, and see what LCS can do for you.

What is Liferay Cloud Services?

Liferay Cloud Services is a new online platform that offers tools and services that will help our customers suceed on Liferay projects. Specifically, LCS allows you to set up projects that represent your Liferay deployment(s), add and manage users and their roles, manage fix packs on EE, and monitor your Liferay deployment's health via metrics dashboards. The best part: we can easily add new services without impacting existing services. It's all on the cloud!

What's New

Since launching the first LCS limited beta, the team has been busy listening to your feedback and making several improvements including:

Show each individual portlet load time

Ability to sort pages and portlets by average load time to easily find the slowest ones

Ability to download all available fix packs with a single click

Ability to configure/modify proxy connection settings

More robust client and better error management

Ability to invite (and reject) users to your projects

Ability to update project names

Fixed many issues reported by our awesome beta testers

Compatibility

Liferay Cloud Services is compatible with Liferay Portal 6.2 CE+EE and 6.1 GA3 CE+EE. It also works with on-premesis or cloud deployments, so we can target the maximum number of kinds of deployments.

Providing Feedback

Joining the beta program and providing feedback is the best way to steer the product direction to best suit your needs. The LCS team values all feedback, and it's easy to give: just click on "Feedback" within the dashboard. Easy!

What's Next

Currently LCS offers health services: per-portlet statistics, JVM analytics, and patch management. The team is investigating adding more services based on customer and community feedback! So get involved in the Beta today and see what it can do for your Liferay deployments and let us know what you want to see using the Feedback link! Just visit the landing page and click "Get Started"!

Wow. Just.. WOW. It's Liferay's 10th anniversary, and I've been blessed to be able to be a part of it the last several years, including this year. A big round of applause goes to you and our entire community for your work and achievements this year! It's been an interesting year for us, both in terms of technology and community. If you attended any online or in-person events this year and heard our community leaders talk, you have a head start on witnessing some of the cool stuff we are doing as we transition Liferay to an even more ultra-cool and modern web platform.

And the best part? Not only is it happening in open source, it's becoming even more accessible to you via our community and is right there in front of you waiting for you to dig in and help complete the journey with us! It's really easy to sit back, watch, and consume, but it's much more rewarding personally and professionally when you get involved. One of those rewards is one I strongly believe in, which is recognition amongst peers that you are helping to make a difference. So, to that end I was honored to be able to present this year's 2014 Community Pulse Awards to those organizations and individuals that are helping shape Liferay for the future!

Liferay Pulse Award: Community Contributors of the Year

This award is given to individuals (not employed by Liferay or its partners) that volunteer their time and effort to make Liferay and its community better. This year, extra marks were given for well-rounded participation and contribution in different areas, as well as for value given through non-liferay.com venues (e.g. personal blogs, stackoverflow.com, and others).

In no particular order, I present to you our Liferay Community Contributors of the Year for 2014!

Bijan Vakili (USA)

Bijan is the de facto IRC channel maintainer and longtime community member - setting up a very useful log, and also developed a very cool set of open source Marketplace apps which connect Liferay admins directly to IRC to get questions answered from right inside Liferay!

Dave Nebinger (USA)

If you hang out on our forums at all, you probably know Dave - one of the most prolific contributors to our forums, with an impressive 1700+ posts this year alone and 56 solutions (as voted by those who asked!). He's also a 2-time winner of the quarterly Top Contributor award and is in the chase to become top poster of all time.

Nagul Meera (India)

Nagul is also a heavy contributor to our forums and wiki, with over 600 posts and comes in 3rd place in the answer-to-post ratio, and maintains a great blog on technical tips and tricks for Liferay.

Denis Signoretto (Italy)

Denis had a well-rounded contribution track this year, with contributions across many areas including the forums and wiki, as well as contributing an good amount of bug reports, 25% for which he contribution code solutions!

Krzysztof Gołębiowski (Poland)

Krzysztof is our #2 answer-to-post ratio (308/14) and also contributes around the community, including bug reporting and code contributions, and is active in the Poland user group, and unknowingly contributes in other ways (making sure Liferay supports his name!).

If you see these folks in our community, be sure to congratulate them on a job very well done this year!

Liferay Pulse Award: Community Excellence

Liferay's growth and success over the last several years has be in no small part due to our awesome worldwide network of partners. The Community Excellence Award is given to those in our partner community who demonstrate a unique and valuable dedication to our open source community. Companies here have spent their own time and resources to make our community better, which of course benefits everyone, so we recognize them here and thank them for their dedication to growing Liferay and its community.

EMEA

ACA-IT (Belgium)

ACA has been a big supporter of our community this year, sponsoring (and contributing to!) events and has begun to document their Liferay chops in an excellent series of blogs on Liferay and other technologies in which they have expertise. ACA has also contributed 2 very useful apps to the Marketplace, heads up the Belgium User Group, and we value their continued presence in our community!

Componence (Netherlands)

Once again we find Componence on our list, due to their continued support of our Dutch Liferay community - including actively managing the Netherlands user group, sponsoring events (as well as organizing events within events), active contributors to our forums and Liferay Dutch translations and several utility apps on the Marketplace.

SMC (Italy)

SMC founded and continues to lead the Italy User Group, and was one of the first Liferay partners ever, so it is no surprise they are committed to our community. SMC also contributed to our Italian and English forums, and is the organizing sponsor of this year's Italy Symposium which begins today in Rome! They also developed a liferay.com forums app for iOS/Android for you to participate in our forums, several outstanding Marketplace apps, and contribute to the Liferay Calendar feature and Mobile SDK.

Americas / APAC

Cignex Datamatics (USA)

Cignex is a long time contributor and repeat winner of Community Excellence. They have "doubled down" on their community contribution and it shows - several individuals have been recognized as quarterly top contributors and they are heavy participants on our forums, blogs, and sponsor Liferay events worldwide.

Permeance Technologies (Australia)

Permeance continues to be a big open source contributor, authoring a set of 8 really useful apps on the Marketplace (I use the Log Viewer on a daily basis in our cloud infrastructure), and graciously contributing their source code to our community and showing us how to do apps right. They also routinely break Liferay as part of their training and support roles, file bugs, and work with Liferay to fix it so you don't have to!

Rivet Logic (USA)

This is Rivet Logic's first win for Community Excellence - the entire team has stepped up their game this year through road shows, event sponsorship, and they have also authored the most number of apps by a single company across the entire Marketplace - 18 of them - all free and open source. Their track record in our community helps all of you - and helps them as well, which is what community is all about. Hear their story.

Savoir-faire Linux (Canada)

XTIVIA (USA)

XTIVIA is ever present in our community, and has shown their passion for it through their contributions to our forums and community meetups (both offline and in person), spreading not only their passion but their knowledge of Liferay through these efforts. They lead the Austin, SoCal, and Denver user groups, sponsor events, and have contributed a handful of unique and useful Marketplace apps. Their recognition as Liferay's North America Partner of the Year I hope was in part due to their community excellence, and we look forward to 2015 with the team!

Please join me in congratulating all of these individual contributors and partners. They, along with the rest of our community, are what make my job so rewarding and what I believe makes Liferay stand out above all as an example of open source and community at its best. Great job everyone! I am very happy to see all the enthusiasm and passion for open source and for Liferay, and I look forward to seeing what we can accomplish in 2015 and beyond.

A community challenge for you

Liferay's worldwide conferences generate quite a bit of data, and I am challenging the community: Take this data, and do something more interesting than a boring list of speakers and rooms. Get creative with the data (it's super-easy to digest, see the example code from my first post). Have some fun and show us how creative you can get!

What's In It For Me?

You'll win one of these:

Gratitude from our community and recognition from your peers that you are indeed a rockstar hacker (and a small gift from Liferay), or

A Tesla1

Not sure which one will be given away yet. We're still working out the details.

The Details

Liferay holds many events throughout the year, and there is a lot of data associated with them. Hundreds of speakers, sessions, and activities across global venues means a lot of data, and in a previous blog post I challenged you to take our open data stream and do something interesting with it. In that post, I documented the data related to sessions, speakers, rooms, maps, activities, sponsors, etc, and gave some example JavaScript you can copy/paste into your browser's developer console to see just how easy it is. And it's all available to you and your creative minds!

Now it's time to look at some even more interesting data: iBeacons!

If you've attended some of our recent Liferay conferences (or you're planning on attending future events), you've probably heard of iBeacons. We've been using them in several events to showcase Liferay as a mobile engagement platform and to provide value to attendees by engaging them with location and time-sensitive notifications (e.g. when walking out of a breakout session, you'll receive helpful followup information about related sessions, and a plea to provide feedback).

The way it works is pretty simple: the Liferay Events mobile app knows about these little Bluetooth transmitters we hide throughout venues (if you look around, you might spot them!). When you walk into or out of range of each beacon, or linger in a given area, the app knows what you're doing and will provide interactive notifications to you based on your movement.

But there's more -- the app also periodically records (anonymous) data regarding how many devices are within range of each beacon. Although this makes Olaf's tinfoil hat buzz with doubt and uncertainty, you (and Olaf) can rest assured we do not record anything private or identifying - it's totally anonymous.

And the best part -- the data is open for you to browse, process, and have fun with. And therein lies this challenge: channel your inner analytic/visualization geek, hook up to the data, and show everyone something interesting! It doesn't have to be enterprise-grade, bulletproof, fully cooked, or ready for deployment into production. But if it's interesting and fun, I'll do my best to show off your creation in our community.

Don't forget, the agenda/speakers/sessions/rooms data is already documented. What follows a description of the iBeacon data.

The iBeacon Data

iBeacon data can be retrieved using a JSON endpoint and specifying the event for which you want data (and optionally a time of day filter to reduce how much data you want or do realtime monitoring). You can also retrieve data for a past event or a current event (e.g. for a realtime dashboard). The event specifiers for 2014 that might have data:

The first example should give you 3239 results, the second about 600, and the third about 6 results. Note that some events do not yet have any data, because the event has not yet taken place. But you can use prior events for testing purposes!

The result object is always a JSON object that has a status code (stat) to indicate success or not. The code is either ok (meaning success), or something else (indicating failure). So check the stat code before doing anything else. E.g. here's an error:

{
"stat": "error: something is horribly wrong"
}

And here's what success looks like:

{
"stat" : "ok",
"size" : <size of result set>,
"from": <earliest timestamp of result set, or specific "from" time if you gave one>,
"to": <last timestamp, or specific "to" time if you gave one>,
"resultSet": <JSON ARRAY OF RESULTS>
}

At this year's Spain Symposium and North America Symposium (which begins in about 294,682 seconds from now), I'm going to be holding a session on 21 Ridiculously Simple Ways to Contribute to the Liferay Community. In a related development, I've recently heard from several of you recently that you'd missed some interesting news items that happened, and didn't know how best to avoid missing stuff, so as a companion to my talk, I thought I'd also list the Top 10 Even More Ridiculously Simple Ways to Follow the Liferay Community! So here they are:

Subscribe to the Community Blogs. This is probably my favorite, because the most important stuff gets posted here all the time.

Setup a Google Alert for Liferay. There are some amazing community members, journalists, and random people that create great content about Liferay, and they aren't always posting to the blogs on this site.

This blog is part of a series of entries documenting how we are using iBeacons and Liferay to better engage our audiences at events throughout the year. [Part 1] [Part 2] [Part 3]

In Part 1 I introduced the concept of using iBeacons for Audience Engagement and reviewed knowing your audience and the physical space. In Part 2 we took a step down and covered more technical details about beacon programming and management. In this third and final installment we'll discuss how we use Liferay to manage beacon configuration, some anti-annoyance strategies, and a comparison of iOS to Android when it comes to beacons.

With all of your newfound knowledge about how iBeacons work, let's talk about how to integrate them into the Liferay Portal platform.

Liferay Integration

There are many variables to consider when designing an app that will interact with Bluetooth beacons. How many different spaces and times you want to support, the physical size and layout of the space (your local user group meetup, or the World Cup?), what kinds of interactions you wish to have, how crowded the space will be, how many beacons you can get your hands on, and a whole lot more. This means that your beacon configuration is most likely going to be changing a lot, and in some cases will be unknown until you are actually present to do setup. So no hard-coding of beacon identifiers or region names or anything of the sort is allowed!

In addition, as we previously discussed, beacons are pretty dumb - they simply emit a unique code over and over again (you know, like... a beacon). The interesting stuff happens when your app responds with unique and engaging content.

So, your app needs to be able to reconfigure itself on the fly by reading dynamic beacon configuration from a network location and serve unique and engaging content based on user behavior in the field. Of course we would use Liferay, as it does this really well!

We needed to massage the data coming out of the DDL a bit (for example, we add a UUID to every returned record to use for internal record keeping in the app, which by default is not present, and we also wanted the date format to be consistent), so we created a very simple plugin on top of the standard DDL service which returns the data from the DDL in a friendlier format using remote JSON web services (if you want to learn how to do this, don't miss tomorrow's dev.life session!).

For Liferay events, each event typically gets a separate Site on liferay.com (we call them 'microsites'). Here's the DevCon microsite. Within each microsite lives the data for the event (as discussed in the DIY blog), including beacon configuration described below.

We designed 4 different dynamic data lists to hold the beacon config for each event to support the kinds of interactions we described in part 2 of this blog. Basically, the 4 lists provide beacon region definitions, event definitions, and forms to fill out for certain kinds of interactions.

1. The Beacon Regions List

This list defines the set of beacon regions for a given event. For example, in the Benelux Solutions Forum we had 5 different regions. As you know, each region is defined with an identifier, and one or more of Beacon UUID, Major, and Minor. So that's the schema for this dynamic data list:

name - A human-readable identifier that shows up in the app (but is otherwise unknown to the beacons)

beacon_uuid - The hardware UUID of all beacons in this region

beacon_major - The hardware major number of all beacons in this region (or blank to represent any major number)

beacon_minor - The hardware minor number of all beacons in this region (or blank to represent any minor number)

muted - a flag that allows event staff to selectively turn off a region for any particular reason

2. The Beacon Region Events List

This list defines the things that can happen based on region actions such as entering or leaving one of the above defined regions. This turned out to be the biggest list compared to the others, because most interactions are based on region entry/exit (which is the only thing your app can detect when it's backgrounded or quit entirely). We had a particularly strong desire for this application to NOT be annoying, so most of the elements below are designed to STOP the app from doing anything! Only those events deemed most worthy make it through the gauntlet of checks represented by the below. So each possible interaction is defined with this schema:

region_name - A textual description of the region for which the action should occur (this name shows up in the app as well)

on - A 'select' field to define the kind of event for this region - entry or exit.

initial_delay - How long to wait after entry/exit before the notification is shown. This allows you to delay the notification (e.g. waiting 10 minutes after entering the Cafe before offering a discounted drink ticket). It also works with the cancelable flag below to avoid transient events and NOT trigger interactions in certain situations.

repeat - How many times to repeat this specific notification. No sense in repeating most messages, right? Maybe 1-5 times, but more than that and people get annoyed.

min_repeat_period - How long to wait before repeats. If you have a repeating message (e.g. a "Welcome to the sponsor expo, sign in to get your prize" kind of interaction, you would get annoyed if you got that every time you walked in!)

cancelable - A flag to indicate that a delayed notification can be cancelled if the user reverses their behavior. See Death Row below.

message - the initial message to display (and we have string substitution, for example $SESSION_TITLE and $SPEAKER_NAME so we can show dynamic messages, based on the agenda and time of day)

actions - the options to present. Each notification consists of the message and an optional set of actions the user can take. For example, in a "Welcome to the event" message you might want to offer a quick link to the registration desk map, a link to the agenda, or a link to checkin on Foursquare or Twitter, or a form to fill out to register for something. We invented our own simple list syntax here to encode a list of actions into a String, which identifies different kinds of actions (take the user to a specific screen in the app, load a web page, show a document or form, create a tweet that the user can edit and send, etc).

preferences_gate - We created this to allow logic to be introduced as part of the gamification design. Preferences can be programmatically set based on user behavior (e.g. filling out a form, finding a mystery object, or completing a game quest), and those preferences can then be checked later on using this field to avoid showing the wrong notification, or duplicate notifications for game elements that have already been completed.

start_date/start_time/end_date/end_time - A way to avoid interactions at certain times of the day. For example, you don't want to show a "Come join us after today's sessions for happy hour!" if happy hour took place yesterday.

All of these configurations are designed to filter the interactions to only those that really should show up. In addition, the app also hard-codes a global event frequency limit, so even the most "chatty" event staffers can be thwarted in their plan to fill your notification tray (see below for more detail on anti-annoyance)

3. The Individual Beacon Events List

In addition to region-wide events (entry/exit) we also want some interactions to take place within the context of a specific beacon. The schema is virtually identical to those for region-wide events, but in this case you define the action to occur based on proximity to a specific beacon:

region_name - The name of the region in which the person must be in for this event to occur. Because beacons can be in multiple logical regions at a given time (remember the overlapping regions?), we wanted some actions to only occur relative to a specific region.

beacon_major/beacon_minor - Since this event is specific to a specific beacon, you need to identify it here!

on_proximity - How close you have to get to the beacon before triggering the interaction. It's a multi-select field for immediate, near, or far, or any.

The rest of the schema is identical to the schema for Region Events.

4. Beacon Forms

One of the interactive features of the Liferay Events app is the ability to present forms to the user as part of a region or beacon trigger. We used this as part of a "mystery guest" game where attendees would walk around to each sponsor booth and be presented a form, and if they entered the right values they'd be entered into a drawing for a prize. The form is submitted to a special game server which evaluates the answers and returns results (a simple Liferay web service). So in the above event definitions, there is an "Actions" field and one of those actions is to present one of these forms.

form_id - The identifier for the form (referenced from the actions list above)

title / subtitle / sub-subtitle / intro - These are textual elements at the top of the form (introductory text for describing the purpose of the form)

form - The form itself. The syntax here is out of scope for this blog, but it basically allows you to define the fields of the form itself (text fields, text areas, sliders, multi-select fields, etc).

content_url - If present, this is a URL to a piece of web content on Liferay to display at the top of the form. Useful for marketing collateral!

preferences_on_success - Remember the preferences_gate defined for beacon events? If you successfully fill out the form, these preference_on_success flags are "set". If you fail the form, the preferences_on_fail preferences are set.

repeat - How many times to repeat the form. You might only want some forms fill-out-able once.

That's it! Using the above configuration, event staff can create the iBeacon interaction they desire, while avoiding annoyance as much as possible.

Avoiding Annoyance

Each time the app thinks it wants to engage you with an iBeacon notification, it has to pass through a gauntlet of anti-annoyance checks to try to ensure you only get the messages you really should get, without being annoying. If any of these "fail", then nothing happens:

Has it been long enough since your last notification? No? Fail.

Are you currently busy with a previous notification (e.g. are you in the middle of filling a form?) Yes? Fail.

Have you seen this notification enough times already? Yes? Fail.

Has it been long enough since you last saw this particular notification? No? Fail.

Is it the right day or time of day to show this notification? No? Fail.

Have you told us not to show notifications from this location? Yes? Fail.

Are all of the possible actions you could take as part of this notification invalid at this time? Yes? Fail.

As you can see, there are many types of anti-annoyance configuration elements (e.g. minimum repeat times, date/time filters, etc) and some built-in logic (e.g. global speed limit) that means you can't get flooded with beeps or vibrations every 10 seconds. It is highly recommended in your applications to avoid annoying users, because they will just get irritated and possibly tell all their friends about it.

Death Row - or how to deal with transient events

Imagine if you set up a "Welcome to the event!" message that shows when attendees first arrive at your event, and you also have a "Goodbye - thanks for attending!" message that should show when attendees leave your event. Now, imagine an attendee arrives at your event, and they get the welcome message. So far, so good. Now, imagine that before the opening keynote they have to make a pit stop at the WC, which is in the basement. While in the WC, your app no longer detects any beacons because you didn't put any there. When the attendee walks out of range of the beacons and into the WC, the app will think that they left the event and issue the "Goodbye" message, and they'd get rather confused and think they entered some kind of time warp to the end of the day. Further, when they return from the WC they might get the "Welcome!" message again! That's not going to do.

So instead of blanketing a space with hundreds of beacons to ensure 100% coverage, the app has a built-in death row. By adding a 15 minute delay (for example) to the "goodbye" message AND setting the cancelable flag , when the attendee goes to the WC, the "Goodbye" message is queued to trigger in 15 minutes, as usual. When the attendee returns from the WC, the "Goodbye" message (which hasn't yet been triggered) is put on a software Death Row. If the attendee remains in the event, the "Goodbye" death sentence is carried out before the timeout expires, and the Goodbye message is "killed" (i.e. not shown). However, if the attendee then turns around and really does leave the event, the Goodbye message is "pardoned", taken off death row, and is allowed to occur after the specified delay.

This is akin to the "double bouncing" effect in electrical circuits. When a switch is closed, there is a momentary bouncing of the electrical signals as the two parts of the switch come together to complete the circuit. This can cause lights to flicker, or multiple forms to be submitted on a website, so logic is needed to wait until the switch is "really" closed with purpose, and this maps perfectly to this scenario - as attendees often "bounce" between indeterminate states (are you in the WC? Or in the event? Are you actually walking into a breakout session, or merely passing by?). Beacon-enabled apps should ensure that user actions (such as walking into a room) are intentional and not transient.

Security

The app deals with data that isn't very sensitive, so if it is compromised, bridges won't fall and lights won't go out. But as a good practice we employed several basic security measures to protect overall integrity:

Uses HTTPS everywhere

Signed requests when writing data back to web services

OAuth for external sites (e.g. Twitter, Facebook)

Does not require login; usage is completely anonymous

The event app records a list of beacons your device can see every few minutes while the app runs, and passes this back Liferay, using another simple web service creating using Liferay's ServiceBuilder framework (see Privacy section below for details).

Android vs. iOS considerations

First the software: The app itself is written using Titanium Appcelerator, a hybrid app platform that cross-compiles JavaScript apps to native languages for iOS, Android, Blackberry, and Windows phones. From there, the native SDKs are invoked to create truly native apps that are then uploaded to the various app stores. Titanium does a good job at providing parity between the different platforms, sometimes sacrificing OS-specific features in order to maintain parity, but plugins (called modules) can be written and plugged in to provide access to native APIs. Titanium itself does not know about iBeacons, so we ended up using an open source library for iOS, and for Android we wrote a custom module which wraps around Radius Networks' Android beacon library.

As for the hardware: Both Android 4.3+ and iOS 7.0+ support Bluetooth LE, on which iBeacons are based, but you also need hardware that implements it, such as an iPhone 4S or later, Galaxy S3/S4/S5, Nexus, and many others. There are other differences noted below that we discovered during the last several months, that might help you understand what to expect. We've tested across about 10 different Android devices (out of a possible 8,423 devices) and 7 different iOS devices:

Accuracy - winner: iOS. We can confirm reports that iOS does a better job of reporting closer-to-reality proximity information (it also smoothes the data for you).

Sensitivity - winner: Android - it can "see" for miles and miles and miles. We think it's because of the built-in smoothing of data in iOS and dealing with transient detection, which is not present (or just not as robust) on Android, which just tells you like it is, without any sugar coating (and we like it that way)

Programming Model - winner: iOS. When we started this project, there were no free/libre/open source Titanium modules for interacting with iBeacons on Android, so we wrote one instead, using the awesome Radius Networks' beacon Library. iOS' LocationServices also seemed a more natural and higher-level abstraction than Android's lower-level Bluetooth APIs.

Debuggability - winner: Android. Open source. 'nuff said.

Backgrounding support - winner: Android (Barely). All you have to do when your app goes into the background is throttle down the Bluetooth LE scanning rate, but otherwise your app continues to run as it was written. With iOS, you have to do this ridiculous song and dance with a separately-scoped background "service" and seriously reduced feature set. Yeah, we know it is supposed to make multitasking better and keep app developers from crashing/killing your phone. But still, it's difficult to get the dance right between foreground and background. What makes iOS really nice here is even if your app is hard-closed, it is awoken when iBeacons are detected. But even that presents its own challenges.

Robustness/lack of befuddling crashes and weird stack traces: Tie. Both produced the occasional wtf moments, but there wasn't a clear bias from one or the other for "Sharepoint moments".

Power consumption - winner: iOS, but it might have been because we had tired batteries on Android. More rigorous test is probably needed.

Overall winner: "It Depends". It depends on which of these are more important to you. But iOS+Android make up like 99% of the market, so if you just target one or the other, you'll be missing out.

Privacy

When iBeacons first emerged, they got a pretty bad rap, when phrases thrown around like "Marketing tools for the NSA". As in most cases, reality is much different than the fantasyland of the mass media, and iBeacons don't in and of themselves cause you to be tracked and reported to the authorities if you cross a double yellow line on the highway or steal toiletries from a hotel room. But they also don't prevent it :)

What does pose a danger are irresponsible (or malicious) app developers coupled with unsuspecting owners of smartphones who click on every link they see on Pinterest and give their private data to anyone that asks. This danger has existed since the mists of antiquity, it's just easier to do on a bigger scale now.

By default the Liferay Events app sends mostly-anonymous data about iBeacons back to our servers. The "mostly" bit is due to the fact that it also includes an "identifier", but that ID is associated with the installation of the app, not the person or the device. If you re-install the app, it gets a new ID. We feel this is a good way to it, and respect the privacy of the user. Oh and you can also switch off Bluetooth. Or uninstall the app!

Future Enhancements

There are a lot:

Integration with liferay.com services (e.g. being able to log in, and link your event activity with your online profile)

Detection of nearby interesting people, not just objects, and getting you to talk to them

Auto-registration (pre-register in the app, and then when you walk up to the registration desk, the app emits a QR code that is scanned to confirm your presence)

Rewards for attending certain types of sessions or tracks

Pattern recognition for sessions, in order to suggest other, related sessions or people

Realtime analytics, trendspotting

Wrapping Up

Computers and electronics in general continue their march toward smaller, faster, cheaper, more efficient, and more approachable footprints. Along with those advances comes new ways to apply them to solve problems that were historically difficult or impossible. And we are just getting started with mobile devices and apps, which open up a whole new class of applications that benefit not just the technically elite but also those that have until now been economically or socially disadvantaged.

iBeacon is one example of this, and in this author's opinion is a stepping stone to a really cool future involving location-aware computing and better, more personal engagement with our devices. Of course there will be missteps along the way and there are plenty of risks (privacy or lack thereof, securing transactions between moving people and things, EM radiation and interference, safety while operating heavy machinery, Skynet-type takeovers, and more), but this author is also optimistic that we can and will solve these issues. It's an interesting future! Thanks for reading!

Today Liferay announced the winners of the 2014 Liferay Marketplace App Contest! This year, we were super excited to see what our community could dream up, and you did not disappoint. The review team witnessed an unmistakeable and significant increase in overall app quality this year, so it was even more difficult to pick the winners. A big thank you goes to each of you who took the time to create and submit your apps to the contest, because without you, we'd never see the variety and creativity of apps that a big community of awesome people can produce. Ok, enough babbling, onto the results!

The Grand Prize Winners

This year, with the introduction of paid apps, we judged across two different axes: commercial/non-commercial and free/paid, which resulted in 4 different categories and 4 grand prize winners (and 4 runners up). This allows those with less available resources (i.e. people, time, and money) to still compete and win! Apps were judged for their creativity and usefulness, ease of installation/setup, user interface, user experience, Liferay integration, and completeness of solution. Here are the grand prize winners for 2014:

If you are building apps that integrate with all the things social, this app implements the most boring and complex part of that integration, and exposes a simplified interface for your app's customers to connect your app with their preferred social networks. It acts as a proxy between your app and any OAuth-based social network (like Twitter, LinkedIn, etc). OAuth is complex and difficult to get right, so this app does the magic for any number of external networks with which you wish to integrate, and does so securely within the Liferay platform!

Visioneo is a complete reporting application, allowing you to embed high quality reports into Liferay. Using the popular Open Source BIRT Eclipse designer, you can create powerful reports containing charts, data tables, cross-tables, images, grids, multiple pages and many other things from your own datasources (including Liferay itself!). There are two versions available: a Community Edition (CE) and a Professional Edition (PE). The Professional Edition includes enhanced Liferay integration through reports permissioning and document integration.

Tori is a discussion forum portlet with a fantastic user interface and experience. Features like real-time notifications and in-page navigation make it easy and comfortable to use. Also included are real time notifications, a re-use of Liferay's forums backend (and is therefore a drop-in replacement), enhanced SEO and page indexing, custom badging, and much more. With a fast and fluent in-page navigation pattern and integrated analyics, Tori Forum is a great alternative front to the built-in message boards!

Vahtie is a powerful survey and feedback management solution for organizations to do employee, customer and research insight. It's designed to support large scale organizations natively on Liferay platform. It's proven and tested in production and it's currently being used by organizations with tens of thousands of users. It's a turn-key solution to a problem that pretty much every company or organization has - how to improve business based on feedback from those that use whatever it is that your company or organization produces.

Each Grand Prize app will be on display at an upcoming Liferay Conference - if you're interested in learning more about them and meeting the developers and companies behind these apps, check out our upcoming events listing to see if there is an event nearby that you'd be interested in attending!

The Runners Up

This app implements a social announcements platform, using categories and vocabularies from Liferay. Users can create and manage announcements of varying purpose across multiple different sites, and includes support for adding rich media, workflow for announcements, native integration with Liferay's asset management framework, support for social activity streams, comments/likes/views, and uses Liferay's out of the box UI to provide a pleasing experience with virtually no changes.

Social Login for Liferay is a plugin which enables users to login to Liferay using their preferred social networks, including support for the most popular social networks like Google+, Facebook, Twitter, LinkedIn, and even includes support for Microsoft network login. It is OAuth2-based, and uses AlloyUI components to give users a great mobile and desktop experience when logging into your portal.

This plugin uses a visual geographic map to visualize the location of content such as blog and wiki posts, forum threads, users, and any other asset type in the Liferay platform. Implemented as a standard AlloyUI/JavaScript component, you can add multiple maps to a page, and link it to other built-in asset presenters such as Liferay's Asset Publisher. Administrative controls allow you to selectively enable or disable different asset types, and choose which mapping service and layers to use (e.g. OpenLayers/OpenStreetMap, Google Maps, Bing, and others). Paid plugins are also available to change the way the data is presented.

Intelligus TeamWorXX is a web-based collaboration and social networking suite, which leverages and extends the social and collaboration features of Liferay. TeamWorXX is aimed at helping groups of users work together effectively and share knowledge online. Used by over 250,000 users worldwide, Intelligus TeamWorXX is a feature rich web collaboration platform that hosts the UK's largest platform for public service collaboration. Intelligus TeamWorXX lets your users manage everything from searching all visible groups, members and content, to contributing ideas, posting announcements and creating polls.

... In Closing

This year we saw a huge increase in app quality during the contest: initial setup, UX, Liferay integration, you name it. Every single app in the contest was useful and I think shows the power of a community of people finding new and creative ways to use Liferay technology to solve real issues. Well done everyone!

Liferay hold many events throughout the year (10+ this year alone), featuring keynotes, workshops, expert speakers, onsite and offsite events, and multiple venues around the world. The data associated with past, current, and future events includes huge agendas, many speakers, rooms, activities, maps, locations, analytics during the event, and much more.

Finding an effective way to aggregate and display all that data for attendees (on multiple devices) is a challenge! We have websites and mobile apps that are designed for displaying this data, but there are things some folks want and others do not, so we are challenging you, the community: do it yourself and make it better than ours, and show everyone what you made!

We're opening up the data stream for our community, and want to see what kinds of new and interesting things you can do with the data. Think dynamic maps. Floating faces. Wordles. Mind maps. Semantic content analysis magic. Mashups with social media. Interactive websites. Ways to connect the dots that no one else thought of. The data is simple, and your creativity is unending, so show us what you can do! (BTW: Technically, the data has been open, just undocumented!)

What's in it for me?

You'll gain respect, love and admiration from our community. Not enough for you? We will also show everyone your creations at the upcoming symposiums and DevCon this fall and tell everyone you are a rockstar!

How do I participate?

Simple - create something awesome using the data feed (see below for details on the format and meaning of the data), and tweet the result (pics, screenshots, videos, links) using the #DIYLiferay hashtag. Also, feel free to blog, forum-post, and anything else you want to use to get the word out. We want to see what you did!

There is a lot of data - you don't have to use all of it. Just pick the stuff you want to use, and ignore the rest. Even just the speaker headshots could be used for some rotating awesome 3D sphere of heads. Also, I tried to describe everything in excruciating detail below, but may have missed stuff, but the names and content should be pretty straightforward, and you can check out the data feed and compare it to the microsite and mobile app to see how the data is used there, to give you some idea on how to use it for your own purposes.

Since the event data changes constantly, you should include the following statement prominently in your solution: "This presentation of Liferay Event data was created by [Your Name Here]. Please note that all data is subject to change and Liferay's official event data can be found at http://liferay.com/events"

Liferay Events Data Feed Details

All event data are stored internally on liferay.com in Dynamic Data Lists, and can be downloaded as individual JSON documents using Liferay's built-in JSONWS service. We layer on a plugin (which will eventually make its way to the Marketplace) to do some post-processing of the returned documents for easier usage in the mobile app.

What code do I need to write?

You can use any language or framework that can retrieve and parse content (so basically, any language!). See the end of this post for working code that you can quickly try out to see how things work. But the main workflow is:

Get a list of events in JSON

Get data about a specific event in JSON

Do something awesome with the data

General guidelines

All dates are represented in format YYYY-MM-DD or HH:MM and are assumed to be in the local event timezone unless otherwise noted.

Boolean values are represented by the strings 'true' and 'false' - you will need to convert these to real booleans in your chosen language if desired.

Some items are themselves are strings that represent JSON documents and must be parsed as such again, in code. For example, you might find a string like "{\"foo\": \"bar\", \"baz\": 3}" and you would need to parse this to programmatically access it (e.g. using JSON.parse()).

Some items are lists of name/value pairs, e.g. a=b,c=d and may contain whitespace (including tab characters!) that should be trimmed. That means you should parse 'a=b,c=d' the same as ' a =b , c = d'. Also, colon-separated lists like 'a:b:c,d:e:f' is the same as ' a: b : c ,d: e :f '. Recommendation: use String.trim(). Enjoy!

Every record returned via a JSON endpoint will have a UUID associated with it named uuid. This is sometimes used to relate two items together, e.g. agenda items have a list of speakers represented as a list of uuids, which can be used to get the right speaker record via the uuid (assuming you have already retrieved the list of speakers).

I suggest you download and cache all event data for a given event at once, and store them internally (possibly using hashtables for quick lookup based on things like uuid). If you only download half the data, you might not be able to de-reference certain pointers (like speaker UUIDs). That's what the mobile app does (and periodically refreshes data once every 30 minutes while the app is running).

Step 1: Getting the list of events

As we have many different events throughout the year, the first thing to get is a list of events, using the following endpoint (notice the hard-coded ddlRecordSetId value - this is your key to the kingdom and should never change for the event listing):

event_type_dict: translations for select options for sponsor levels, session types, and agenda filter names. Format: comma-separated name=value pairs. E.g. "diamond=DIAMANT,gold=Gold" means the level with key "diamond" should be displayed as DIAMANT (German translation of Diamond) and key "gold" should be displayed as Gold.

event_tz: number of hours ahead or behind GMT (negative numbers indicate ahead, e.g. France is -2 in summer, can be used to correct for phones that are set to a different timezone than the event itself to calculate 'local event time' based on device time.

latitude: Decimal degrees of latitude for event location (approximate, used for the 'pick the closest location' button in app)

location_label: Name of location (usually a city name, e.g. Paris or Boston)

logo: the logo to use to represent the event. This string is an embedded JSON document which can be used to construct the final URL to the logo, format is: {"groupId": gid, "uuid":uuid, "version":version}. You can parse this with JSON.parse(). The final URL can then be constructed: https://www.liferay.com/documents/[groupId]/[uuid]

news_type: ddlRecordSetId of the list of news to show user, can periodically check this to see if there is breaking news (see news item below)

ordered_sponsor_levels: the order and size of the sponsor logos on the Sponsors screen. Format: comma-separated list of [name:logos-per-row:size] triplets. For example diamond:1:large,platinum:2:small means that Diamond-level sponsor logos should be shown at the top, 1 per row, and 'large' size, where Platinum-level sponsors are shown 2 per row, and a smaller size. Size can be large or small. Names of sponsor levels are used in the sponsor list, and the display name can be found in the event_type_dict.

randomize_sponsors: 'true' or 'false': whether to randomize order of individual logos within each sponsor level.

register_url: the URL for people to register to attend.

session_survey_questions: A list of questions to ask when survey feedback is given. The format of this is beyond the scope of this challenge :)

start_date: when the event begins, used to order on the 'event select' screen. format YYYY-MM-DD

start_time: when the event begins, used to order on the 'event select' screen. format HH:MM

survey_questions: A list of questions to ask when event feedback is given. The format of this is beyond the scope of this challenge :)

upload_photosetid: the Flickr.com photoset id used to upload and retrieve pictures from the event [see below for details]

uuid: unique identifier for this particular object

As new events come online, they will appear in this list. And past events are here as well, in case you wish to test with past event data to fine-tune your app!

The metadata_types element

Each event has a metadata_types field. This is the key to drilling down and getting event-specific data (like agendas, speakers, etc). The format of this element is a comma-separated list of name:ID pairs. For example agenda:12323423,activities:23423243,... You use these IDs to retrieve data of a particular type for a particular event, for example: https://www.liferay.com/skinny-web/api/jsonws/skinny/get-skinny-ddl-records?ddlRecordSetId=35246557 just as you did for the event list. The elements in the metadata_types list include:

agenda: A giant list of all agenda items for the event that appear on the microsite and mobile app

activities: A list of onsite and offsite activities (e.g. community meetups, social hours, etc)

contacts: A list of initial contacts to populate the 'Contacts' screen for the event

galleries: A list of photo galleries to show on the 'Gallery' screen for the event

maps: A list of maps to show on the 'Maps' screen for the event

rooms: A list of rooms used at the event (used to map agenda items to physical rooms)

speakers: A list of all speakers (used to generate pics, biographies, etc)

sponsors: A list of the sponsors of the event, for the 'Sponsors' screen

Each type of data is explained below. You will also find elements for beacon_forms, beacon_individual_events, beacon_region_events, and beacon_regions: These are related to our iBeacons feature at events, and will be covered in part 2 of this blog post.

Step 2: Fetch data about an individual event

Once you have fetched the list of events above, you can then use the metadata_types object for an event to access details about the specific event, using the ddlRecordSetId's in the metadata_types field for that event. For example, the agenda for France Symposium is 35246557. You should fetch all data (agenda, speakers, rooms, etc) for a given event at once, because some elements reference other elements (e.g. an agenda item lists speakers by their uuid, which can be looked up in the speakers data for the event).

Fetching The Agenda

The agenda is the most complicated of all the event data types. Here's the France Symposium agenda. Note that all agenda items are represented here, including breaks, after-parties, registration, etc. Some elements may not have all fields filled out (e.g. there are no speakers for the 'Breakfast' agenda item, and no video URLs either). The format is the same as above, with the following elements:

custom_css_class: ignore this, not the droid you are looking for

date: Day of the session, format: YYYY-MM-DD

display_in_mobile_app: whether to display in mobile app or not (some items are not)

display_on_live: whether to display on microsite or not (some unfinished items are not, and you should ignore these)

download_label: Slide download URL (only active after event)

download_url: Session replay URL (only active after event)

enable_notes: Whether to enable 'personal notes' field in app (e.g. "Lunch" is not enabled for this)

enable_ratings: Whether to enable the session to be rated (e.g. "Afternoon Break" is not rateable)

end_time_hour: When the session ends (it's actually a JSON array with a single element representing the hour of end - don't ask why)

end_time_minutes: When the session ends (it's actually a JSON array with one element representing the minutes of end time - don't ask why)

room_uuid: The UUID of the room element that in which this session takes place

speakers_uuid: A comma-separated list of speaker UUIDs for the session. You can look up speaker details via the UUID and the speaker list below.

select_category: If present, then this is a JSON array representing a list of categories to which this session belongs. E.g. all Mobile-related talks would have mobile as a category, or perhaps mobile, responsive. These are free-form tags that are used on the website and mobile app to allow attendees to only show certain kinds of sessions. The display name of the filters can be found in the event_type_dict dictionary for the event.

sponsors_uuid: A comma-separated list of sponsors that are sponsoring the session (e.g. for sponsored after-parties, etc)

start_time_hour: When it starts (again, a single-value JSON array)

start_time_minutes: When it starts (again, a single-value JSON array)

survey_questions: The list of questions to ask when rating the session. Out of scope for this challenge!

Fetching The Maps

address: The physical address of the place. Don't try to parse it, just use it as input to some map service like google. Also, for room maps, there's no address.

icon: A small thumbnail representing the location.

image: A bigger image representing the location.

name: The name of the place (is used in the Activities list to generate a link to this map)

phone: If you want to call/text the location, use this phone number.

show_map: For items that don't have an actual address (like a room in a venue), this is 'false', and the mobile app won't generate a dynamic google map.

uuid: A unique identifier for this map. Is used elsewhere (e.g. in the agenda's room_uuid element) to reference this map.

Fetching The Contacts

In the mobile app, there is a Contacts screen with a default list of contacts, that can be added to at certain events that have QR codes printed on badges. Here's the France Symposium contacts list. Elements:

blog: Their blog pointer

city: The city in which they do business

companyname: Name of company

country: Name of country

facebook: Their facebook page

firstname: Their given name

googleplus: Their Google+ page

lastname: Their family name

linkedin: Their LinkedIn page

phone: Their business phone number

picture: Their image (again, a JSON object that must be parsed to construct an image URL)

readonly: Whether they can be deleted. 'true' or 'false'.

state: Their state/region

street: Their street address

twitter: Their twitter page

url: Their company's URL

uuid: A unique identifier for this contact

youtube: Their YouTube page

zip: Their postal code

Fetching The Galleries

In the mobile app, there is a Gallery page with different tabs for different events. Generally, the gallery in position 1 is the gallery representing the current event that is being brosed. Here's the France Symposium gallery list. Elements:

rateable: Whether pics in this gallery can be rated (thumbs up). Generally only the current event's pics can be rated.

title: The title of the gallery (appears on tabs)

uuid: A unique identifier for this gallery entry.

During the event, attendees are encouraged to take pics and upload them with the mobile app, and the pics go to Flickr. You can retrieve a listing of all the pics from Flickr using the photosetid and Flickr's REST web service (you have to have an API Key, and follow their docs closely to do this). This listing you get back from Flickr also includes a direct photo URL for each photo, so you can make pretty pictures dance.

This will generate an alert popup for our events by retrieving the listing and parsing it out:

Another Example

This one is a bit more complicated, it retrieves all of the events, looks for our North America Symposium entry, then retrieves its agenda and looks for sessions that are categorized as mobile sessions, and shows its details in another annoying popup.

Over the weekend you may have have noticed our community blogs page got a makeover! There are several new additions and changes to the page which we hope will make your liferay.com blogging experience better and more informative, and make it easier for you to not only keep up with what's going on but to contribute your ideas in a more structured/categorized way.

Highlighted Bloggers

First, I wanted to thank all of you who have contributed to your blogs on liferay.com!

Since opening up liferay.com blogging to our entire community in 2013, we have been thrilled to see how our community has responded, with lots of informative entries and quality content.. but the very coarse categorization (Staff vs. Community) isn't enough, can be confusing for staff, and the sheer number of posts showing up in each of these buckets means that you get a big flat list of tons of blog entries, some really good, and some that could have used more polishing before publishing

To help you with choosing what to read, the new main blog landing page is now a curated list, showing you the "best of the best" (as decided by our editorial staff and feedback from the community on specific posts). As a reader, it should be the first thing you follow/subscribe to! The same list of highlighted blogs will also appear on the right side of the community landing page.

You can still follow all of our community's blog posts by clicking on the All tab, which will work as before and show a reverse chronological list of all blog posts. We hope that you find value in the curation and are motivated to produce high quality posts that show up here!

How do I get highlighted?

It's really easy (well, easy to understand, a bit harder to execute) - just publish quality content that is easy to read, informative, and does a good job at reaching your intended audience. You might want to read through the Blog Guidelines at the bottom of the Content Policy page for some tips about writing quality posts. If you do it enough, your readers will respond, and our curation department will most definitely recognize you and highlight you or your blog posts, or both!

Non-highlighted posts will continue to show up on the All category (and of course, your personal blog page!).

Categories

Not everyone is interested in technical blogs, or blogs about Liferay the company, so we've enabled Categories (using Liferay's built-in categories feature of course!). Categories allow blog authors to mark their posts to be in a particular category, causing it to show up on the specific sub-page of the All tab. You can also subscribe/follow individual categories using the RSS links at the bottom of each tab. We started small: Company posts relate to Liferay the company (such as Zeno's recent post about his Liferay Brazil office experiences), whereas Technical posts are (you guessed it) more technical in nature, like Srikanth's recent post about Service Builder. The General category is for posts that don't fit in the other categories.

As an author, you will be required to specify a category (with the default being General). Be sure to choose wisely! Only staff members will be able to pick the Company category. This will help your readers pick the posts they are most interested in. If you have suggestions for more categories, let us know in comments (yeah, there are tons of possibilities here, but the simpler the better, for UI and UX!).

Also note that your past posts aren't automatically categorized - if you want them to appear in the proper category, you will need to Edit them and select the right category on the Edit screen.

Most Active Bloggers

There is also a new link on the left navigation area under Blogs - Most Active Bloggers will show you the most active bloggers by number of posts in the past 6 months, regardless of whether they have produced any highlighted blogs. Readers who want to keep up to date in the community can find out exactly who is contributing on liferay.com blogs using this page. The page also features easy RSS feed links for each individual author.

Note that this list only shows bloggers from liferay.com - if you had your external blog listed previously, it will be returning very soon, so stay tuned!

Updated Look & Feel

The blogs pages also has a new look, with rounded pictures, crisper fonts, more category and subject lozenges, and new icons for views and comments. We hope you like the look of the new page, along with the new features and new curated lists.

How do I post a blog?

Everyone who has an account on liferay.com can publish blog posts. To publish a blog, visit your profile page by logging in, clicking your profile picture at the upper right, and choose Account and then click Profile at the top next to your profile picture (or, if you know your screen name, just type in liferay.com/web/{screenname}/profile into your browser's address bar).

Once on your profile page, look for the Blog link on the left, and click on it, and click the Add Entry button to draft a new entry using Liferay's built-in WYSIWYG editor. If you do not see a Blog link, you will need to request a blog (this is an additional anti-spam measure, as long as your account is in good standing you will get a blog!). Happy blogging!

I'm not sure if I've said it enough -- our community is awesome! Each of us comes from different geographic places, cultural backgrounds, and Liferay experiences and we bring that collective story together through software by developing contributions, cool apps, and ultimately learning through sharing. And in that spirit I'm happy to announce a new initiative for our developer community: dev.life Community Developer Sessions!

2 weeks from today will begin a regular series of online hangouts designed for you, the Liferay Developer. Don't worry, these won't be boring slide presentations, but instead will each be unique and interactive hands-on coding sessions with a small, focused goal that each of us can achieve during the session and can then take home for later. Think of it like a mini-"workshop/hacking session" with a small, well-defined goal, led by your fellow developers from around the community. You won't find intro to portlets or here's my fully baked project - good luck kinds of sessions here. You will however learn something new every 2 weeks.

Specifically, these will be 60-90 minute hangouts every 2 weeks using Google+ Hangouts and YouTube, along with interactive features like a dedicated IRC chat room for Q&A, online collaborative coding whiteboards, Q&A and more. Simply show up with your mind (and your development environment) and start hacking! We are all stuck behind a monitor and keyboard most of the day, so this gives us all a chance to “get out there” and get more personal with our community and meet and engage with others in the world of Liferay and teach small things that can lead to larger things later on. And best of all, it's totally free (as in beer).

To give you a taste of what's coming, here are some example sessions (some of which are already on the calendar):

It's a big experiment that I hope you will enjoy and participate in. The first session is on July 29 at 1400 GMT (that's 0400 HAST, 0700 PDT, 1000 EDT, 1600 CEST, 1700 EEST, 1930 IST, 2200 CST, 2300 JST, 0000 AEST, and so on...) where we'll go over the typical dev environment one might use, how to use the collab tools, and introduce the upcoming sessions. As we go along we might change the tools, but the spirit of the sessions will remain the same. Following the first session, we'll do one every 2 weeks at about the same time of day. We have about 10 sessions in the pipeline so far (the next 3 sessions are on the upcoming sessions page).

How to Participate

To participate, check out http://liferay.com/community/dev.life and join us on July 29. On the site you'll also find a list of upcoming sessions (along with any prerequisites for each session), a calendar to which you can subscribe, and more information about the sessions. Each session will be broadcasted via Google+ and YouTube, but you need only visit the home page to join the session (there is an embedded YouTube stream and IRC chat on the page). You should also join IRC (specifically, the #liferay-dev-life channel for use during the session, and #liferay for general community chat) to join in the online chat in parallel to the hangout, as useful links and other information will be given, and you can directly interact with others.

These sessions are geared toward Liferay Developers, and so you should also have your preferred development environment set up and ready to go if you intend to participate (and I highly recommend you do - you'll learn quite a bit more when forced to do things vs. passively watching!)

Calling all Developers

This is an ambitious effort to undertake, and your fellow community members would be super-appreciative to see what you're working on or what you've achieved with Liferay. Why not lead your own session? If you're interested, email me at james.falkner@liferay.com with your ideas - everything development-related is welcome, but please no sales pitches or theoretical physics papers :) These are real world tasks with real results, buddy! And you'll get a small gift in return for your efforts!

So get fired up for dev.life, be sure to read the prerequisites for each session and get your toolbox ready to rock. It should be fun!

This blog is part of a series of entries documenting how we are using iBeacons and Liferay to better engage our audiences at events throughout the year. [Part 1] [Part 2] [Part 3]

In Part 1 I introduced the concept of using iBeacons for Audience Engagement and reviewed knowing your audience and the physical space. In this entry, we'll cover more technical details about beacon programming and management, and what we learned in Amsterdam and Paris. First off, let's explore how devices "listen" for beacons.

Beacon Identification

As we discussed previously, each iBeacon you put in a space continuously emits a Bluetooth LE signal, that contains data that uniquely identifies the beacon. Your app must be coded to enable beacon listening, and then provide code (callbacks) that is called when beacons are detected. In addition, devices must have turned on their Bluetooth radio and the user must have explicitly given the app permission to use the incoming data (this varies by device - for example on iOS the user must grant the Location Services permission, and on Android the user must grant the permission during app installation).

Beacons are uniquely identified with 3 pieces of information: UUID, Major, and Minor. Your app must know of these identifiers and be coded to respond in various ways when beacons are detected. These identifiers are part of the Bluetooth LE signal sent by each beacon. It's important to understand this - the beacons themselves aren't sending any "real" content (no web content, no credentials, no Java or HTML or JavaScript or PHP or Assembly code or pictures of your cat). It's up to your app to detect the presence of beacons and respond appropriately.

Beacon Regions and Region Monitoring

Suppose you have 100 beacons placed in various places at a venue (hotel, grocery store, football stadium, etc). In one large room, you might have 5 beacons to cover the entire space. To detect when the user has entered that room, your code would need to scan for all beacons at all times, and then if one of those 5 beacons were detected, your app would know the person has entered the room. When you can no longer detect any of those 5, then the person has exited the room. Your app would have to remember that a person entered a room so that it can also know when they exit (and what happens if one enters your room, and then restarts your app?) In addition, some beacons might be part of multiple and physically overlapping places to which you wish to respond. For example, at the Liferay France Symposium, the Registration Desk beacons were also in the Rotonde room, for which we had separate events. In a football stadium, Section 232 might be part of both the East and North seating area.

Coding for all that detection logic for each of your 100 beacons would quickly get tiresome, so some smart designers introduced an abstraction to help deal with the complexity. In this case, the abstraction is known as a Beacon Region. A Beacon Region is defined in software only - beacons themselves don't "know" they are "part of" a region. Only your app and device "knows" of these regions, and your app can be notified when the device "enters" or "exits" a region without you having to explicitly code for each individual beacon. This is known as Region Monitoring and is what occurs most of the time during your beacon-powered app's lifecycle.

One thing to keep in mind - even though your app will only get notified on entry or exit of a region, additional logic in your app can set you up to respond to things like "person has been in this region for XX minutes" or "person has gone from region A->B->C->A" and that sort of thing. It can be useful for better engagement (more on this later).

Beacon Proximities and Ranging

In addition to monitoring and responding to Region entry/exit events, your app can also be notified of its proximity (how close you are) to each individual beacon. Thanks to real world physics, the proximity isn't all that accurate - you can't know for certain that you are exactly 1.233 meters away from a beacon, due to multiple sources of interference and the frequency of broadcasts. iBeacons designers also knew this, and introduced 4 "zones" in which a beacon might be. The immediate zone is (from our testing) about 1m away or less. The near zone is about 1-5 meters. The far zone is 5m or further, until you reach the unknown zone which is usually a temporary zone just before the beacon becomes undetectable (and this also where you end up if you dig too deeply in Minecraft). This again is a software abstraction to help your code be simpler. Beacons don't "know" which zone they are in, no do they do anything different due to an approaching person or device.

Proximity detection (also known as Ranging) is also much more expensive in terms of energy consumption (i.e. drains your battery faster), because the hardware must scan for beacons frequently to get a somewhat accurate reading on each one. So you don't typically want your app continuously ranging for nearby beacons. In fact, some devices like the iPhone do not let your app do ranging when it is in the background for this reason. In the Liferay Events app, we only turn on ranging when the app is in the foreground and you have positively entered a region.

During ranging, your app will receive reports of each detected beacon, and in some cases reports of "boundary crossings" (e.g. when you go from near to immediate for a given beacon, and you want your app to do something special). Each beacon's hardware broadcast strength can be set by an administrator, and that setting is included in the packets sent over the air in the Bluetooth broadcast, so the beacon software in devices can do fancy math to calculate an approximate distance based on the power setting and the actual strength of the signal received. For example, if you crank the broadcast power to maximum on the beacon itself, but then the actual received signal is fairly weak by a device, then you can kind of know you're pretty far from the beacon.

Foreground vs. Background

From early testing we discovered most people don't run your app and walk around staring at the screen waiting for popups, looking like Dr. McCoy with a tricorder. Should be obvious, but sometimes you get blinded by the awesomeness of new tech and forget about how people really get along with it. So in reality, for your app to be engaging it has to provide value even when the app is in the background, or it is quit entirely.

For example, iOS allows monitoring but does not allow ranging when the app is in the background or quit entirely, so if all your app does is respond to ranging events, it's not going to be very interesting to most people, because it's not going to do anything while backgrounded/locked/quit. You need to combine region events with proximity events, and we did exactly this for the Liferay Events app. Again, people don't attend our events just to play with an app or their phone, they are there to learn about Liferay, attend sessions, and meet people, so most of the time their phone is in their pocket and not top of mind.

iOS 7.1 introduced a new feature that allows your app to receive beacon event messages even if the app is hard-closed. Again, only beacon monitoring works in this case, so your app should use region monitoring to ensure your users can be engaged even if the app is backgrounded or closed.

How we configured our beacons for events

So now that you understand how beacons work at a slightly lower level, let's talk about how we used them at our events. As part of this experiment, we decided to start small and feature the following types of engagements to engage both business and technical attendees:

Venue information and workflow - for example, a welcome message on arrival to the venue, with directional maps to the registration desk and WC, and a quick way to check in on social media, or some reminders to pick up name badges, or discounts at the cafe.

Sponsor Engagement - Interactive sponsor and partner marketing, including lead generation (e.g. "fill out our form for more info" or QR code scanning)

Speaker Engagement - Information about upcoming sessions occurring in the area you are in, or getting feedback from attendees as they leave a session

Gamification - Rewarding attendees by making them go to places (like a scavenger hunt) or using the app as a "virtual railpass" to force them to visit with and engage sponsors

Analytics - we wanted to (anonymously) see how people moved through the venue, to see if elements of the event (e.g. sponsor booths, hands-on demos, different food areas) were effective or not.

To support all these types, we defined several beacon regions (one for each discrete room that we wanted to act on) and also a venue-wide region encompassing all beacons (so we could show welcome messages even for those who snuck in through the back door.) We also used individual beacon proximities and ranging for certain triggers, such as when you approached a sponsor's booth, you'd get interactive and engaging content, or when you approached a "mystery guest", you got a trigger to engage in a game (more on gamification later).

Beacons are not super-expensive, ranging from USD 5 [reportedly] - USD 30 each. At typical Liferay events we can have up to 5 or 6 different rooms, and we also wanted to support sponsors, so we ended up needing around 20 beacons (a few more than absolutely needed, for backup purposes). You will also lose some, unless you hide them really well or lock them in a box.

Liferay Portal Solutions Forum Benelux 2014 Configuration

This event took place in a somewhat compact venue (Pakhuis De Zwijger), with the registration area, sponsor area, and main speaking room all within about 50m of each other. We configured the following beacon regions and individual beacons:

So any beacon with the UUID of B9407F30-F5F8-466E-AFF9-25556B57FE6D would be considered in the "Venue" region (and we had entry/exit triggers setup for entering or exiting the Venue, e.g. "Welcome" and "Goodbye" with links for event surveys, social media, etc). Any beacon with a UUID of B9407F30-F5F8-466E-AFF9-25556B57FE6Dand a major of 2 would be considered in the Expo region (this is where the sponsor booths were). Further, each sponsor booth had a beacon dedicated for it, using B9407F30-F5F8-466E-AFF9-25556B57FE6D for the UUID, a major value of 2, and a minor value starting at 0 and going up (we had 6 sponsors). If you're wondering, that special UUID is simply the default UUID of Estimote Beacons, the vendor from which we sourced the beacons.

The main hall (Grote Zaal) was a large space, so we used two beacons placed on either side of the room, up high, to cover the entire room, and this worked pretty good (each were configured with a major value of 1). The other areas were served with 1 beacon each.

We also featured a "mystery guest" game. The goal of the game was to engage attendees through a game, while at the same time forcing them to engage with the sponsors at the event. To play the game, attendees had to find a special person who was secretly carrying a beacon. When you got close to this person, the app would respond and ask you a question, to which only the mystery guest had the answer. Upon learning the answer (and typing it in correctly), you could then proceed to each sponsor booth, and on approaching the booth, you would get more notifications with marketing messages from the sponsors and a form to enter your info, along with the answer to another question (the answer would be found by talking to the sponsors, forcing attendees to engage!).

We then configured the app and Liferay to support the following beacon notifications

There are many details about how these worked and were configured in Liferay - more on that in the next post!

What we learned in Amsterdam

Attendees aren't there to play with your app. We didn't get nearly as many people engaged with the mystery guest game as we'd hoped. About 20% of the attendees began the game, but only about 2% actually finished the game (visited all the booths, entered all the answers correctly). It took quite a bit of effort to complete the challenge, and there was limited time (the event was only a 1-day affair). So the lesson here is don't make things too hard to use! Perhaps at DevCon we may do something more technically difficult yet interesting, but for the two events we've had so far, they just weren't that into it :)

There are many Android devices :) We knew this up front, but were unable to purchase and test all 8,432 Android devices the app supports, so we found several glaring bugs on certain devices (which were fixed either during or shortly after the event). Lesson: Test on as many devices as you can. Ask your friends and colleagues to test the app. Use simulators with reduced memory footprints and weird device types.

Beacon ranging is useful, but cannot be relied upon for initial engagement, since it is disabled when the app is backgrounded/locked/quit.

Liferay France Symposium 2014 Configuration

This venue (Shangri-La Hotel) was a little more spread out, offering a bit more breathing room and chances for engagement. The crowd was also more technical (the first day's sessions were entirely technical). The beacon configuration here was similar to Benelux, but we had several more regions to support the additional areas, and we converted the beacon proximity events for sponsors into beacon region events (so that they worked even when phones were backgrounded/locked/quit).

What we learned in Paris

For the France Symposium, we decided to make the game part much easier to "complete" and took out the mystery guest element entirely, which proved to be too much "game for the game". Instead, we did a simple scavenger hunt (We had a Beacon region named Trésors cachés) - we hid 4 beacons in various places, and when you got close to one, you were given a hint as to where it was, and if you found it, you could enter your information for a chance to win a prize. We gave away all 10 prizes that day, and people were generally more engaged (the analytics data also revealed this fact - we had about 30% more attendees using the app and looking for secret beacons than we had at Benelux).

We also finally decided that any engagement actions in the app must begin through region monitoring, because that is what works when the app is closed or the device is locked (which is like 90% of the time for most people). So, for example, the Trésors cachés game began through beacon region monitoring (as opposed to only relying on beacon ranging and proximity to find the beacons, which would not work when the phone was locked/backgrounded/quit). The other events (entering/exiting breakout rooms, getting notified of upcoming sessions, visiting booths) were also triggered by region monitoring vs. ranging. So people are much more likely to engage with your app and your content if they can get notified when they're not explicitly staring at the screen.

And finally, we learned a hard lesson in upgrading - our beacon vendor decided a couple of days before the event to update the app I was using to program the beacons to require login and that each beacon be associated with the account used to order the beacons. This is great because previously, anyone could re-program your beacons and mess with yo stuff. But not so great when the beacons weren't properly linked to my account. So 2 hours before the France Symposium began, as I sat down to program the individual beacon UUIDs/Majors/Minors, I found that I could not! After several frantic emails to their HQ in Poland, their customer service reps were able to fix the issue - so that's +1 for Estimote.

Coming up next...

That's it for this entry. In the next entry I'll discuss:

How the Liferay Events app integrates with Liferay Portal

What kinds of beacon actions are good for different audience types, and how to not annoy people

During development I found a lot of technical resources for iBeacons, but little or no research on how to apply it in engagement applications. What kinds of triggers are useful for different audiences? How often should my phone buzz in my pocket? How to avoid annoying people and having them uninstall your app and complain on Twitter? What about privacy?

This series of blog posts will attempt to document what we've done and what we've learned about getting over the hype of the new technology and really thinking about how it can deliver on its promises, without being annoying or just "fluff".

What is an iBeacon?

An iBeacon is a small Bluetooth LE transmitter that continuously sends out a unique code up to about 50m. When sprinkled throughout a space, these beacons can be "seen" by devices capable of receiving the transmissions and can trigger location-aware events like notifications, automatic app navigation, and other kinds of events. As each iBeacon transmits a different code, the app can respond differently based on the user’s location, providing location awareness and contextual engagement possibilities.

You may have heard of them already - several companies are using them in retail stores and other public places, including Apple, Macy's, Fluwel's Tulpenland, Major League Baseball, and more. These companies provide engaging content depending on where their audience is at the moment, making the experience more enjoyable while at the same time developing a closer relationship to customers. It's effective outdoors and indoors where there is often no way to receive GPS signals from satellites. It's cool, but can be creepy, so keep reading...

You got iBeacons to work - congratulations! Now what?

Making iBeacons work at it's lowest level is pretty straightforward - there are some really good blogs and even ready-made libraries (like this one we developed for Titanium) for various mobile and desktop operating systems and the APIs for talking to iBeacons are pretty straightforward (you turn it on with one API call, then it calls your callbacks when various beacons are detected or un-detected). But true benefit comes not just from the technology, but also in understanding human behavior and and applying it to your specific situation.

For our use case, we wanted to provide additional value for attendees, sponsors, and event staff, as well as show off Liferay (of course!). To that end, our goals specifically were:

To showcase Liferay’s flexibility and power to integrate with bleeding-edge technology and show how it can be used to more fully engage Liferay users through a combination of mobile and desktop features.

To provide great value to attendees by giving them location-aware contextual information and interactive features to help them get the most out of their investment in attending, without being annoying.

To provide great value to potential event sponsors to help them drive booth traffic, and be able to interactively engage with attendees for awareness, metrics, and lead generation.

To provide great value to Liferay event staff for pre-planning, realtime, and post-event metrics to measure effectiveness of the agenda, venue layout, special events, and other items associated with the event.

Knowing Your Audience

This is the most critical part of any effort to engage an audience - you have to know your audience. In this case, Liferay has held different kinds of events with different kinds of audiences over the years, and we're constantly learning new things about what drives people to attend and what they're looking for. Why do people attend?

To learn more about past, present, and future Liferay technology and overcome business and technical challenges

To network with other companies and people with the same real world problems

Attendees come from a broad spectrum of business and technical knowledge, vertical industries, and professional roles, so it's important to understand exactly the kinds of people you expect to engage before doing so. For example, a more business-oriented professional will seek information on ROI, ability for Liferay and its community to support a specific business need, and contacts from similar professionals with the same role (e.g. CTO-to-CTO encounters). A more technical-oriented attendee wants to know specifications, architectural best practices, upcoming features, wants to attend workshops, and wants to understand how Liferay and related software will work in their technical environments.

So how does this knowledge translate into iBeacons? Well, for starters, understand this: attendees aren't there to play with your app! They can do that at home. They are physically there (and spent money to be there) because of the above reasons, which involves person-to-person exchanges. No amount of clever smartphone notifications can replace intimate contact with experts or tell them why their Liferay deployment is slow. However, mobile apps and iBeacons can be an effective tool to help them get the most from their investment in your technology and your event, giving supporting information about the venue and sessions, or suggesting which sessions to attend, or encouraging them to visit sponsor booths using gamification. And to be honest, there is still a certain "coolness"/newness factor that exists with iBeacons which will wear off eventually. But in summary, there are many ways to engage, so you need to know your audience and decide what you think they will want.

One other thing to consider: iBeacons are relatively new, and not every device supports them, so don't assume all of your audience will be able to use them. In particular, it requires Bluetooth 4.0, found only on newer iOS and Android devices. So, for example, we can't (yet) replace the paper surveys and "railpass" games that we typically have at events with iBeacons, as not everyone would be able to participate.

Knowing the Physical Space

Before deciding exactly what you want your app to do, consider the typical space in which they (and your beacons) will be. For our purposes, the main consideration is the overall size of the venue and number of rooms. At it's lowest level, iBeacons transmit an EM signal at a frequency of about 2.4GHz. These signals can be attenuated or blocked entirely by metal and concrete, other 2.4GHz signals (think microwaves and cordless phones), and water. And ideally your space will be filled by lots of moving buckets of water (a.k.a. attendees), so that can present challenges.

In the ideal case, you can place iBeacons in each of your discrete areas (breakout rooms, main hall, entrance, cafe, etc) with no signal overlap. This provides the most possibilities with location awareness, because you'll be able to accurately detect and respond to movement (or lack thereof) into, within, and out of those areas. Of course, this never works in practice, because most buildings and rooms are square, whereas the Bluetooth signal emanating from each beacon is spherical. Round peg into a square hole, that sort of thing. But you can get close by placing beacons in strategic spots, using walls and other blockers to try to contain the signal to the areas in which you want them, and adjusting the signal strength. Walk around the venue beforehand, and see what you've got to work with. For example, here's the quick & dirty diagram from the Benelux Symposium:

We ended up using two beacons turned "all the way up to 11" to cover the Grote Zaal space, and placed them in the rafters. The rest of the areas were served by a single beacon each, and then we had individual beacons for each sponsor booth as well. We had plenty of "overlap" and the potential for attendees to get flooded with notifications, so there is a lot of code to deal with that. We also wanted to re-use it for different events and audience types, so there are lots of configuration options for the app. More on the technical side of things in a future post!

After you place your beacons, walk around with any 3rd-party iBeacon detector app and see what it sees. Also, code in a "debug" easter egg into your app, to make your app report what it "sees". There is one in the Liferay Events app (press and hold your finger on the Gallery title bar, then return to the main screen, and you'll see it!) →

What we learned is that even though the Benelux space was more compact than I'd envisioned, it was still possible to map out discrete locations and serve them with iBeacons by placing the beacons in strategic (and hidden) spots and tuning and broadcast power to suit the space. Assume you will have overlap, and that people will do unexpected things such as walking into and out of a space quickly, detecting beacons through what you consider impermeable walls, or lingering in a "Lagrange Point" between two overlapping beacons :) If your app is to be effective, you must consider these kinds of behaviors.

In the next few posts we'll get into more technical detail, including:

Today we are announcing an open Beta of Liferay Cloud Services! If you're interested in participating, check out the landing page - you won't be able to miss the big form on the right (there are only 50 slots left - hurry!).

What is Liferay Cloud Services?

"Liferay Cloud Services is a new online platform that offers tools and services that will help our customers suceed on Liferay projects." That sounds great, right? So, for example, you have 10 Liferay servers in your farm - do you know if they are all up to date? Do you want to manually go through each one and update them? What if one is running low on memory - wouldn't it be great to get an alert on your mobile and correcting the issue instead of receiving an angry customer call an hour or two later?

LIferay Cloud Services will do all that - and more! The more: Fix Pack Management, Metrics, Dashboards, and Alerts. I won't ruin the surprise here, so please check out the Beta landing page to see more information about these. The best part is we can easily add new services without impacting existing services. It's all on the cloud!

Availability

Liferay Cloud Services will be available for systems running on 6.1 CE/EE GA3 or later (and of course 6.2 CE/EE GA1 or later). And yes, my community brothers and sisters, it is also available for Liferay CE (although limited, still very useful, otherwise I wouldn't be blogging about it here!) It also works with on-premesis or cloud deployments, so we can target the maximum number of kinds of deployments.

Beta Program

This beta program is intended find issues (what??), and get real feedback from real customers using it in an as-close-to-real-as-possible way. It also gives our community a way to interact directly with the product team(s) at Liferay, before it is finally launched. We learn a lot about our products from you, we rely on you to tell us what to fix, what to improve upon, and how to best meet your goals. In short, we cannot be successful without you, so we really need your help! The beta is a great way to do this, so I highly recommend you sign up. There are only 50 spots total, if you're interested, you should move quickly!

What's Next

The good news: it's a cloud-based service, and the team is looking at a range of new features to offer to you - not only health services, but also processing services (e.g. offline video transcoding), more analytics, and others. So get involved in the Beta today and see what it can do for your Liferay deployments!

If you're in or around Amsterdam next week, we're having a community meetup prior to the Benelux Solutions Forum event and you're all invited! Join our local community of rockstars for some knowledge sharing, and drinks in the center of town at the Café The Flying Dutchman [map], May 19 (Monday) starting at 20.30! The entire community is invited (you don't have to be attending the event the following day).

There is no agenda or set presentation, but there will be plenty of great conversation and interesting characters from our Dutch community, along with myself and a motley crew of Liferay'ers from around the world. Looking forward to seeing everyone!

If you're planning on attending, please let us know how many you will be in the comments below, to give us some idea of how many of us will be there!

As part of my community party planner role at Liferay (aka community manager), I try to get out and meet many of you at industry and Liferay conferences and other events. I think it's really important in this webified world that we keep the human touch at least a little! At our events I get to learn about new cultures and make new friends, learn how people are using Liferay and getting along in our community, and try to contribute back a little through knowledge sharing on what I've learned over the last couple of years.

Next week I'm attending the first ever Liferay Benelux Solutions Forum in Amsterdam, and wanted to let you know about some of the awesomeness in store for you, and encourage you to check it out if you can make it!

First, I'm happy to go to the home pitch of one of our most active and influential user groups, the Liferay Netherlands User Group, housing many of our community rock stars, indicative of the selfness nature of our Dutch Liferay community and surrounding regions. When people like this come together, it makes for one of the best places to come to learn more about our community, and about Liferay. It reminds me of an experience I had last year at another Liferay event (actual picture over there on the right), where a couple of engineers from Liferay and other companies sat together with a customer for 15 minutes and figured out a perplexing issue on a production Liferay server -- during one of the breaks. That would have normally taken countless emails, IMs, and phone calls. It happens all the time at Liferay user group meetups and official conferences such as this one when sharp people get together, and I haven't yet seen the Dutch disappoint!

It's also one of our first "big" events of 2014, with what looks to be some fantastic speakers, and I can't wait to see the first official roadmap presentation of the year (no pressure, Ed!), hopefully with some details on what lies in store for the future of Liferay, version 7 and beyond. Also featured at the Solutions Forum will be the return of the Expert Exchange discussion groups, in the style of the World Café. It's speed dating with basically every other attendee on various focused topics related to getting the most out of Liferay as your audience engagement platform. I loved this style of event last year, and learned some interesting ways our customers and community are engaging their own communities of partners, employees, and customers.

On a more technical level, I've had the privilege to work on some exciting new technology we'll be demoing at the Benelux Solutions Forum, using Liferay and iBeacons. We're going to sprinkle several of them throughout the venue and in conjunction with our Liferay Events mobile app [iOS | Android] you'll receive localized and contextually-aware messages and helpful hints throughout the event (with a few surprises thrown in for good measure, none of which involve tracking your every move! I value privacy as much as you!). We'll also demo how the whole thing works, from the Bluetooth transmitters, through the mobile environment, and into Liferay as the core engagement platform, hopefully spurring you to think and ask about how you can get more out of your investment in Liferay.

Finally, the venue itself (Pakhuis De Zwijger) has a lot of history (ok, not as much as the city itself, but you get the idea). It used to be a cold storage facility that fell into disrepair in the late 20th century, and was planned to be demolished to make way for a new bridge over the nearby haven only to be brought back to life thanks to some innovative dutchies, and is now a "Cultural meeting place, multi-arts center and gallery, with multimedia studios" (and soon to be acquiring a few strategically-placed iBeacons). A bridge through a building! Nice one.

PS: I'm also dropping in on the Vaadin crew later next week after the solutions forum, for a Liferay+Vaadin developer hangout. More on this later, but be sure to sign up if you are into great user experiences and awesome portal platforms, with a great developer community behind it all. How can you say no to that?

If you're in or around the L.A. area next week, we're having a community meetup during Gartner's "Portals, Content, and Collaboration" event and you're all invited! Join me and several others for some technical and non-technical presentations/discussions, knowledge sharing, and free drinks/food in downtown L.A. at the Caña Rum Bar [map], May 5 (Monday) starting at 8pm! The entire community is invited (you don't have to be attending PCC) and Xtivia and Solea have graciously decided to sponsor it, making it all that much more fun and exciting :)

Registration and participation is free. We're going to do a few short presentations to get things started, and I would love to see any of you in the area drop by and say hi, discuss or ask anything you like, and hopefully learn a few things about Liferay in the process from our community leaders and experts. Our fearless presenters will discuss:

The Multimedia Blog Journey

Liferay.com Nuggets of Wisdom

5 Common Trends in Liferay Implementations

We'll also be giving away T-shirts and books and a few other goodies. So if you're in the area, be sure to sign up and I will see you next week!

It's back! To celebrate and reward our outstanding community of Marketplace developers, I am happy to announce the opening of the 2014 Liferay Marketplace App Contest! Last year, we had over 70 submissions and many winners (so many that we had to extend the review period an extra week). We saw some really great and innovative apps, and also saw a nice bump in Marketplace activity in general. Last year's winners saw an average of 7x increase in downloads and 2000+ views! So while the prizes are nice, the increased visibility (and bragging rights) are even sweeter. So we're doing it again.

Contest Timeline

April 16: Contest Open

August 8: Last day for submitting apps

August 25: Winners announced

That gives you around 4 months to complete and submit apps for the contest. Note that apps that were already on the Marketplace as of December 31, 2013 are not eligible to be entered into the contest, except for those apps submitted last year that did not win anything (giving our previous contestants a chance to improve and re-submit!).

What can I win?

This year, we have 4 categories: Community/Free, Community/Paid, Commercial/Free, and Commercial/Paid. In each of those categories, there is a chance to win a grand prize (a paid trip to a Liferay Conference, plus other benefits), or a runner-up prize (US $300 gift cards, plus other benefits). See the contest page for more details and official rules.

Why should I enter the contest?

Besides the great prizes offered, your apps will be listed in various places ("Featured Apps", contest follow-up, and at future events) which has historically been shown to greatly increase your apps visibility and subsequent downloads and activity. Not only that, you will forever be recorded in the annals of Liferay history as an awesome app contest winner, and can even make tee shirts about it. Woo!

So how do I compete?

Remember, you have until August 8, 2014 at 11:59pm US/Pacific to enter, so be sure to check out the Marketplace Developer Portal for everything you need to get started. Don't forget, even after you submit the app itself to the Marketplace, you still need to fill out the contest entry form!

We've seen a lot of great apps this year in the Marketplace (I happen to use several on a daily basis, and I am immensely grateful to the developers of those apps). I can't wait to see what our community can do this year!

The Liferay Mobile SDK makes it super-easy for mobile developers to integrate mobile apps with Liferay Portal, by taking care of common tasks like authentication, exception handling, parsing responses, and exposing Liferay's JSON web services in their preferred mobile app development environment (e.g. Objective-C interfaces for iOS developers, Java interfaces for Android, and potentially others in the future). Custom objects and their web services (created via Service Builder) can also be accessed through the Mobile SDK just as easily as core services.

The Liferay Mobile SDK is compatible with Liferay Portal 6.2 and later. The Mobile SDK's official project page gives you access to the SDK releases, provides the latest SDK news, and has forums for you to engage in mobile app development discussions. Bruno Farache also did an excellent blog post for the beta release earlier this year with some working code examples and technical discussion.

Download and Install

There are two ways to get and use the Mobile SDK:

Liferay IDE / Developer Studio / Eclipse Plugin (for Android apps)

For Android developers, Liferay provides the Liferay Mobile SDK Eclipse plugin for you to use in developing your mobile Android apps. It's powerful Mobile SDK Builder generates libraries that enable your app to communicate with Liferay Portal and with the custom portlet services deployed on your Liferay Poral instance. Check out the Developer Guide for details on how to install the plugin into your environment.

Manual Installation (iOS / Android)

For Android and iOS developers, manual installation is pretty simple: download a JAR or ZIP file and import it into your project, either in Eclipse, XCode, or other development environment. The Developer Guide contains details on how to install the SDK into virtually any mobile development environment.

Versioning

Due to the close relationship between the Mobile SDK and Liferay itself, the Mobile SDK follows a similar release version scheme, and each release works with both CE and EE. Multiple Mobile SDKs can also be used in parallel (e.g. to support multiple major Liferay releases in a given app) thanks to the versioning present in the package namespaces.

Source Code

Contributing

Contributions are the lifeblood of our community, and as an open source project, the Mobile SDK is no different. The process for contribution to the SDK is the same process used for Liferay itself. Simply fork the repository, make your contribution, and issue pull requests to the project lead(s). It's a great way to get involved and to give a little back to our community!

Documentation

The Mobile SDK's official documentation lives in the Liferay Developer Guide, covering everything you need to know, including detailed guides for installation and development in both Java (Android) and Objective-C (iOS and XCode) and will be updated as necessary as new features are added or changed.

Getting Support

If you are using Liferay Community Edition, visit the project site or check out the Mobile SDK Forums to find out more about the myriad avenues through which you can get your questions answered.

Bug Reporting

Like other Liferay projects, the Mobile SDK project uses issues.liferay.com to report and manage bug and feature requests. If you believe you have encountered a bug in the new release (shocking, I know), please be cognizant of the bug reporting standards and report your issue on issues.liferay.com, selecting the Mobile SDK Project and 6.2.0.1 release as the value for the Affects Version/s field.

Feature Requests

If you have a great idea for the next Mobile SDK, be sure to file a Feature Request through the JIRA project or on the Ideas Dashboard (they both go to the same place!). If you have the time, consider contributing your amazing new idea to the project, we in the community would love to see what you've done!

This update corrects several issues found since the GA1 release in late 2013 found by our community and Liferay's continuous testing teams. Want to know more? Read on!

Release Naming

Following Liferay's official versioning scheme, this release is Liferay Portal 6.2 CE GA2. The internal version number is 6.2.1 (i.e. the first update release of 6.2). Future CE releases of 6.2 will be designated GA3, GA4, .. and so on (assuming they are needed to fix issues, which is not always the case). See below for upgrade instructions from 6.2 CE GA1, 6.1.x, 6.0.x, and 5.x.

Downloads

You can find the 6.2 CE GA2 release on the usual downloads page. If you need additional files (for example, the source code, or dependency libraries), visit the additional files page.

Source Code

As Liferay is an open source project, many of you will want to get at its guts. The source is available as a zip archive on the downloads page, or in its source code repository on Github. Many community contributions went into this release, and hopefully many more in future releases! If you're interested in contributing, take a look at our contribution page.

What's New / Changed?

This update fixes many issues, but here are some of the more important and/or popular ones that you may be interested in:

Support Matrix

Also, Liferay recently published the official support matrix for 6.1 and 6.2, which lists the exact versions of software that Liferay is supported with. You no longer have to wonder which exact version of GNU Hurd you can run Liferay on (Hint: The Hurd is not supported :) ).

Liferay Marketplace

Most Liferay-authored plugins were updated to support 6.2 GA1 when it was first released, and remain compatible with this updated GA2 release.

If you are a Marketplace Developer, and have authored a 6.2 CE GA1-compatible app, you should ensure your app continues to work with this 6.2 CE GA2 release. It is Liferay's aim to remain compatible within a given release family, so in the unlikely event that your app works with GA1 but NOT GA2, you will need to make any necessary changes and re-submit, and let the Marketplace team know about any incompatibilities you discovered. Chances are you will have nothing to do (since you declared compatibility with 6.2.0+, which includes 6.2.1).

Also, Marketplace developers should be sure to check out the new Marketplace Developer Portal, and get access to a one-stop shop of resources for... well, you get the idea. It's for app developers. Go there and learn.

Bug Reporting

As always, the project continues to use issues.liferay.com to report and manage bug and feature requests. If you believe you have encountered a bug in the new release (shocking, I know), please be cognizant of the bug reporting standards and report your issue on issues.liferay.com, selecting the 6.2.1 CE GA2 release as the value for the Affects Version/s field.

Upgrading

Good news for those of you on 6.0 or prior! Liferay introduced the seamless upgrade feature with Liferay 6.1. Seamless upgrades allow Liferay to be upgraded more easily. In most cases, pointing the latest version of Liferay to the database of the older version is enough. There are some caveats though, so be sure to check out the Upgrading Liferay chapter of the Liferay User Guide for more detail on upgrading to this release.

Getting Support

Support for Liferay 6.2 CE comes from the wonderful and active community, from which Liferay itself was nurtured into the enterprise offering it is today. Please visit the community pages to find out more about the myriad avenues through which you can get your questions answered.

Also note that customers on existing releases such as 6.0 and 6.1 continue to be professionally supported, and the documentation, source, and other ancillary data about these releases will remain in place.

What's Next

Of course we in the Liferay Community are interested in your take on the new features in Liferay 6.2 and the updates in this GA2 release. Work has already begun on the next evolution of Liferay, based on user feedback and community ideas. If you are interested in learning more about how you can get involved, visit the Liferay Community pages and dig in.

Kudos!

This release was produced by Liferay's worldwide portal engineering team, and involved many hours of development, testing, writing documentation, translating, testing some more, and working with the wider Liferay community of customers, partners, and open source developers to incorporate all sorts of contributions, both big and small. We are glad you have chosen to use Liferay, and hope that it meets or exceeds your expectations!

In addition to Liferay's engineering staff, a special thanks goes to the many open source developers who volunteered their time and energy to help with the release, whether it was bugfixing, idea generation, documentation, translations, testing, or other contribution that helped to improve this release. Check out the Community Contributor Hall of Fame and be sure to thank them if you run across them in the community!