Let’s collaborate on how virtual event platforms (and their associated experiences) should evolve. I’ve set up a wiki on PBworks that will allow all of you to chime in with your thoughts. Here’s the link to the wiki – I invite you all in, to add your thoughts and make edits:
Be part of a collaborative blog posting
http://allvirtual.pbworks.com/How-Vendors-Should-Evolve-Their-Virtual-Event-Platforms
To edit the wiki page, you’ll need to register for a free account with PBworks. Suggested ways to participate:
- Edit any of the existing material
- Add new paragraphs or sections
- Delete existing material (although I’d rather you re-write existing material than delete it outright)
Below, I’ve posted the current text of the wiki page. If you have thoughts on this topic, be sure to visit the wiki and chime in! Based on the amount of activity this week, I may choose the publish the final version of this post here on this blog. All contributors will be acknowledged. If you do not wish acknolwedgement, simply skip the inclusion of your name in the list (bel0w).
Lastly, if you’d like to contribute, but would rather not use a wiki, leave a comment below and I’ll apply your comment(s) to the wiki (with proper acknowledgement).
Initial Draft – Visit the wiki to add your thoughts
To evolve their platforms for enhanced experiences and broader adoption, virtual event platforms should consider the following:
Make it easier to experience
Most virtual event platforms are easy to use – on a first-time visit, users tend to grasp the overall user experience and can figure out where to go (and how). That being said, for wide scale adoption, virtual events needs to be as easy as Facebook. That is, our grandmothers need to be able to access the site and figure things out. On Facebook, grandmothers can update their profile, read their “friends” posts and write updates to their Walls. Can a grandmother login to a virtual event, update her profile and participate in a group chat? We’re not so sure. Similarly, navigation and interactions need to be easier. Most virtual events are intuitive to navigate (e.g. Lobby, Auditorium, Lounge, etc.) – but may not be so intuitive with regard to message boards, chat, blogging, rating, etc.
Make it easier to find
The typical “location” of a virtual event is quickly becomin outdated – microsite with registration page, with no ability to experience the event prior to completing all mandatory registration fields. The registration page serves as a “wall” not only to potential attendees, but to search engines as well. Virtual event platforms need to move “outside the wall” and expose their technology on Facebook, on blogs and on publisher web sites. Platforms should widen their distribution via widgets, embed code and application programming interfaces (API’s). Facebook is not limited to Facebook.com – it has Facebook Connect, Facebook Open Graph and much more. Virtual events platforms, on the other hand, seem to be restricted to “VirtualEventPlatform.com”
Make the experience available on more devices
Most virtual event platforms support Windows, Mac and Linux. They need to support more platforms, especially mobile. On the mobile front, it’s important to consider iPhone/iPad, Android, BlackBerry, Symbian, Windows 7 Phone and WebOS (listed in our order of importance). To start, we don’t believe the entire virrual event experience needs to be “ported” to mobile devices -rather, vendors should determine the most critical features for attendees and exhibitors – and prioritize based on importance. For instance, chat is an important element of virtual events, so why not make a mobile app that allows exhibitors to staff their booth via their smartphone.
Make the platform more adaptable and flexible
Related to our point about mobile support, platform vendors have important decisions to make regarding the development platforms. Virtual event platforms today are based on Flash, Silverlight, Java and JavaFX. Are those the “right” platform technologies for the future – or, should platforms move in the direction of HTML5? Does a combination off HTML5, Javascript and Ajax create a more adaptable and flexible platform? What do we “lose” by shifting away from Flash, Silverlight, etc.? And what are the mobile implications with the chosen direction? All good questions for the platform vendors to consider.
This article was developed collaboratively via PBworks. Contributors to this article include:
- Dennis Shiao, Blogger at “It’s All Virtual”
- <YOUR NAME HERE>
