This is a guest post from Krister Ungerboeck, the CEO of Ungerboeck Software International.

The most successful event planners have started using mobile technology to more quickly connect with customers and meet their needs. New mobile applications can drive business to their websites and help them provide better service. Yet, current mobile technology has several deficiencies that make it not only expensive to implement, but it also limits the types of devices that can access a particular app.

HTML5 coding aims to change all of that. By developing websites and applications using HTML5, marketers will be able to interact with all mobile users, regardless of the device they are using. This brings many benefits to event planners and others in the industry.

Better Connection Between Companies and Customers

HTML5 will allow for more interaction between users and websites through more dynamic interactive apps. This means that companies harnessing HTML5 technology will have a better opportunity to connect with their clients through mobile applications. For instance, a company can create a virtual personal assistant to help their customers plan events. Event planners that provide such a service to their clients will likely convert them to repeat customers.

Immediate Access for Users Across Platforms

HTML5 is compatible with all devices and operating systems, giving every customer with a mobile device access to the app and thus increasing its effectiveness as a marketing tool. Instead of creating an app that can only be used by a certain mobile device type (Android, iPhone, etc.), creating an app with HTML5 ensures that every customer has access, no matter what mobile platform they have.

Better Linking Capabilities

One of the primary problems with native apps is the difficulty of deep linking from a specific part of the app to another. Linking in apps and on mobile web devices is almost non-existent, yet it can be a valuable tool for marketing. HTML5 allows linking to be integrated into apps as easily as on a traditional website, which provides many more opportunities for the events industry to use mobile apps.

Search Engine Inclusion

Creating a traditional app for your company is valuable for your business because it keeps your organization connected with your clients through their mobile devices; however, it doesn’t provide any visibility for your site with search engines. The major search engines do not crawl through these apps, so they do not help drive organic traffic to your website. In order to get that traffic, you need a secondary HTML version of the content contained in the application. You can bypass that extra step with HTML5 apps, as the HTML code is already contained within the app. For example, when a user uses Google as their mobile browser and your app is HTML5 based, it will be ranked higher in search results because Google can understand the code.

HTML5 is still relatively new in the world of mobile apps, but it appears to have a strong future. Those event planning companies that want to make their mobile apps as accessible as possible to all potential customers should embrace this new platform when creating mobile applications to connect with customers.

Editor’s Note: As someone who has attended conferences that developed native iPhone and Android event apps, the benefits of HTML5 are very intriguing. App development is much more expensive, especially for a short duration event. HTML5 is likely a faster and cheaper application development option.

This is a guest post from Krister Ungerboeck. Krister is the CEO of Ungerboeck Software International, a trusted provider of comprehensive event management software solutions.

Related articles

• Sencha Unveils Sencha Touch: The First HTML5 Mobile Application Framework (prweb.com)
• Mobile Development Job Trends – February 2012 (regulargeek.com)
• What are the Best Tools For Mobile Application Development? (doctorfox.wordpress.com)

Why a new language for web development?

Henri: This a very good question, as many developers appreciate the comfort of a well-known programming language. So, to rephrase it just a bit: Why a new language, and not a framework? Because the things Opa do are easier for developers than what a framework on an existing language can provide. For instance, the typed “power rangers” of Opa is a unique language feature that makes strong static typing easy to use for everybody.

You can write in Opa:
x = { field: y, another: z }
a = { field: b }

Then write a function that accesses x.field or a.field, with type-safety and without prior annotation or definition. This alone makes a new language worthwhile! And although it may look simple to implement, it’s a very complex problem since it breaks type principality. We see frameworks as an intermediate step between two generations of a language: one that is too generic and doesn’t quite match the domain, and one that was designed for this domain, but doesn’t exist yet at the time the framework is started.
And we made Opa that new generation for web development.

How does Opa work?

Henri: Opa is basically two things: A compiler that does many things and a runtime platform. The compiler mostly:

1. Type checks the code for the whole application
2. If typing is correct, identifies which parts of the application run on the server, and which parts run on the client (we call this step: “slicing”)
3. Translates all client-side code from Opa to JavaScript
4. Compiles all server-side code from Opa to native code
5. Generates a standalone application binary by putting together the runtime platform as a library, the native code of the app, and the client-side resources (including the generated JavaScript).

The runtime platform performs the tasks of a web server, an application server, include the standard library of Opa (which you can consult at http://doc.opalang.org/api) and even has its own database engine. For the latter, Opa also has a very advanced support for MongoDb which makes it the preferred database for production-grade Opa applications.

What does the typical application developer need to do differently?

Henri: The only thing you have to learn to develop in Opa is the Opa language itself. All aspects (front-end code, back-end code, database code) are written in Opa and there is almost no configuration left to do. Compared to writing JavaScript and especially Ajax calls (or continuations by hand with Node.js) and Tomcat/Java, Opa is much easier.

Why are Actors (and your reference to Erlang) important?

Henri: Erlang is a fantastic example of why new programming languages bring fresh air. The actors model is an essential part in modern (social) web applications. All the “real-time” web features, and client-to-client communication in general is programmed easily with actors. Web chats, games, social sharing applications, etc. rely on these features. In Opa, we make it simpler than ever:

1. Define the types of messages: type message = this (or that)
2. Create the actor: instance = Network.network(message) Network.cloud(“name”)
3. Program the behavior of messages received: Network.add_callback(callback, instance)
4. Send messages: Network.broadcast(message, instance)

You can create as many actors as you want, between clients and servers, different servers, or different clients.

If static typing is so good, why not just move to Java on the server?

Henri: The typing system of Opa is more advanced than that of Java, and the core of the language is tailored for the web application features. For instance, Java will only get closures in Java 7 while this has been a key feature of Opa since the early prototypes 5 years ago. That said, Java has a vibrant ecosystem and it would make sense to support the JVM as one the platforms for Opa. The same Opa application could be then compiled either to its current native backend, or the JVM. It’s a complex task – but we are looking for contributors in that space to make things happen faster!

How does someone get started? Interesting links, documentation and tutorials?

Henri: There are more and more links and tutorials about Opa on the web. But as a general resource, I’d suggest to start from http://doc.opalang.org which hosts a manual, the API documentation and a handy reference card. Adam Koprowski and I are now busy writing the forthcoming book “Hands on Opa” that will be published by O’Reilly this summer!

What is the one thing (or 3 things) that make Opa stand out for web development?

Henri: It’s always hard to sum up such an amount of work in one thing. But I’d say it’s that we refined the approach of what a web application programming language should be to an unprecedented extent. Try it out and make your own opinion!

Related articles

• Web And Scripting Programming Language Job Trends – February 2012 (regulargeek.com)
• Have you tried Opa? (sitepoint.com)
• One Web App = One Language (opalang.org)
• The Official Rackspace Blog – Opa Aims to rethink Development for the Cloud (rackspace.com)

Why is software localization important?

The very nature of software applications means they can usually be accessed, bought and downloaded regardless of geographic location. The World Wide Web provides potential access to a truly global market but a monolingual application is one with limited appeal.

To a certain extent, English remains the lingua franca of the business and online world but the fact remains that the majority of the global population speaks no English at all. Of those that do, many speak it as a second language and multilingual users prefer to use applications in their own native language. Imagine a French student who speaks passable English. If your English language application has a specific appeal and no French language equivalent exists, he might well decide to use your application. If there a rival application of similar function and quality that is also available in French however, he is far more likely to go for that.

Localization and the simship model

Localization (often abbreviated in computing circles to L10n, with the 10 representing the number of letters between the “L” and the “n”) is simply the process of adapting a piece of software for use in another locale. Essentially, this means releasing a number of separate products with each tailored for use within its own target market.

These individual localized apps certainly don’t have to be designed independently however. The source code largely remains the same but linguistic translation will often be required and certain cultural and legal issues such as copyright and taste may also have to be addressed.

Building flexibility into the design should allow you to adapt the app subsequently without too many problems. At the time of initial release you might only want a single version, with the option to produce localized versions when circumstances and market research dictates. There are various issues that can be partially catered for during the design and development stage. Some written languages or scripts tend to take more space on the screen for example and areas with fixed dimensions such as dialog boxes can be sized to allow a subsequent expansion of text.

Alternatively, you may wish to release several versions simultaneously. The simship (simultaneous shipment) model is common within the gaming industry and, given that successful apps can tend to go viral, spreading by virtual “word of mouth,” it can be a tremendous asset to have localized versions ready to go at the same time.

Internationalized apps

Internationalization (also known as i18n for the same reason localization is L10n) takes things a step further, with a single application able to cater to users in different languages.

The most common method is to have a language selection option the first time a user accesses the application. This then serves as a portal to the relevant user interface and content. This is not the only solution. It is possible to have multiple languages present on the same screen for example but this tends to be a messier and more confusing way of doing things.

Issues of translation

Linguistic translation is not the only issue to think about but it is perhaps the most important. Good quality translation is integral to the quality of a localized, multilingual or internationalized app and the services of native speaking translators will usually be required. Automatic translation programs can be great tools under certain circumstances but they are prone to contextual mistakes and should never be solely relied upon.

The user interface (UI), input and display are all obvious areas for translation but other aspects such as product documentation and online help files will also need to be addressed.

What about graphics?

Some images work more or less universally while others may have different connotations in different areas. An envelope is generally recognized as a symbol for mail while a thumbs up sign can mean “okay” in the western world but is more likely to mean ‘man’ or ‘male’ in Japan and is an obscene gesture in Thailand and Iran. Additionally, some images that may be perfectly acceptable in one culture can cause offence in another.

In addition to translating the text and making sure any images are culturally relevant and sensitive, you should also ensure that the formats for currencies, units of measurement, time and dates are all correct for the target market. In the US, for example, the date is expressed in the Middle-endian fashion (month/day/year) but most of the rest of the world uses the Little-endian format (day/month/year).

There is a lot to consider when it comes to developing localized and multilingual software applications. Given the potential benefits in terms of opening up new markets and sales, however, it is a process that is more than worth the effort.

This was a guest post from Christian Arno. Christian is the founder of Lingo24, a leading translation service provider across Europe, Asia and the Americas. Launched in 2001, Lingo24 has worked its way to becoming the web’s favorite translation company, working with more than four thousand translators and clients in over sixty countries. Follow Christian (@l24ca) and Lingo24 (@Lingo24) on Twitter.

Related articles

• The Multilingual Web (blogs.adobe.com)
• Dynamic Language Delivery for Adobe’s Mobile Applications (blogs.adobe.com)
• Niklas Laxström, language engineer and Wikimedian (wikimedia.org)

First, let’s look at the basic job trends from Indeed:

In the past 9 months or so, it looks like Android demand has overtaken iPhone demand. I found this quite surprising, regardless of how the trends were moving, so I did a little more digging. Adding the iPad demand to the iPhone demand did not change the trend much at all. Adding iOS to the trend line changed everything, with the orange line following the same trend as the Android trend, but about 50% higher. I may need to include the iPad and iOS demand with the iPhone in the next update. You can see that Blackberry is in the midst of a solid decline, with its peak back around December 2010. Symbian does not look to have grown, and is in a slight decline as well. Windows Phone is slowly growing, along with PhoneGap. WebOS is already in a steady decline and may not exist much longer than 2012, based on the news we all keep hearing.

Now, let’s take a look at the short-term trends from SimplyHired:

Interestingly, the short-term trends look almost nothing like the Indeed trends. The iPhone was along the same trend as Android until July 2011 when it started a dramatic rise. Android is gaining nicely, with the Blackberry trend being flat. The others are clustered at the bottom with only the Symbian decline being obvious. Oddly, you really cannot see any demand for Windows Phone or PhoneGap, which is much different than the Indeed trends.

Lastly, we take a look at my favorite graph, the relative scaling from Indeed, which shows trends based on job growth:

Obviously, this graph is difficult to read due to the flattening caused by the iPhone trend, and generally makes it useless. So, what does it look like without the iPhone?

Now that is a little more interesting. We know that iPhone demand, as well as iPad and iOS, is continuing to grow like a weed, but removing it from the graph shows some interesting information. WebOS had a great peak around February 2011, and looks to be quickly descending. Android and Windows Phone are showing solid growth, and look like they could be solid contenders. PhoneGap is showing strong growth, especially when you consider that it is not operating system specific. The benefit of PhoneGap growth is that people can more easily develop for different platforms, and more adoption means more apps on both iPhone and Android. Blackberry and Symbian barely register on this graph, which basically means they are losing the mobile battle.

Obviously, iPhone and iOS development is still showing strong demand, but Android really is a solid competitor. Windows Phone is also showing some interesting signs, though I would still focus on iPhone development and Android development. The PhoneGap growth is definitely something to watch over the next year as well. The other contenders should be watched but for different reasons. Blackberry, WebOS and Symbian are all showing very negative signs which means developers are not targeting these platforms.

Related articles

• Traditional Programming Language Job Trends – February 2012 (regulargeek.com)
• NoSQL Job Trends – February 2012 (regulargeek.com)
• Web And Scripting Programming Language Job Trends – February 2012 (regulargeek.com)
• Official Wikipedia Android App Uses PhoneGap (i-programmer.info)

First, we look at the trends from Indeed:

MongoDB demand is clearly outpacing the other tools at this point. Cassandra continues with a very positive trend, though it continues to lag behind MongoDB. There was a slight dip for almost all of the tools starting about 9 months ago, but there has been a significant rebound. HBase and Redis both have solid positive trends, even if they are not gaining as rapidly as MongoDB or Cassandra. However, both HBase and Redis have seen a lot of positive blog attention lately, so demand could grow more quickly in the near future. CouchDB is still growing, but does not have the pace of the leading tools. This trend could actually flatten due to the recent confusion around the product direction. Apache is trying to steward it forward, but only time will tell. Riak growth in the past year has been good, and it is trying to break out of the lower pack. SimpleDB and Voldemort have fairly flat trends which is not good in this crowd of tools. They could be marginalized very quickly. Hypertable is not really showing any demand, and this could be the last time it is included in this list.

Now, let’s look at the short term trends of SimpleHired:

SimplyHired’s short-term trends show some differences than the Indeed trends. MongoDB may be leading, but it is not far ahead of Cassandra. HBase and Redis show similar trends to those on Indeed. CouchDB has a flatter trend here, though it is outpacing the last few tools. Riak is showing some positive signs over the past few months, but not enough to really outpace SimpleDB. SimpleDB demand has dropped significantly over the past 8 months, though there is a slight upturn towards the end of 2011. Voldemort demand is not showing a positive trend, staying flat for most of 2011, and Hypertable demand barely registers. Overall, the SimplyHired trends are just not as positive as the Indeed trends.

Now, let’s look at the relative growth from Indeed:

The first thing you should see on this graph is the growth since the middle of 2009. Another notable item is that MongoDB is showing 80,000% growth. So, the scale of this graph is totally confusing, although it does point to the rapid growth in demand for NoSQL skills. Redis has 45,000% growth which means it should be watched over the course of the next year. At this growth rate, it could quickly grow into a major challenger to MongoDB and Cassandra. HBase is also growing rapidly at 20,000%, and Cassandra growth trails a bit sitting around 13,000%. The “laggards” of the group are CouchDB at 5000%, Riak showing similar growth, SimpleDB around 2500% and Voldemort showing slight positive growth. Hypertable is either hidden or just not growing much at all. In either case, that is a terrible sign for a tool in a rapidly growing segment.

MongoDB is starting to distance itself in terms of demand, which is interesting given that Cassandra is backed by Facebook. Redis is starting to gain in demand and is definitely a tool to watch this year. HBase continues to grow partially due to its Hadoop heritage as well as gaining some interest on its own. Riak and CouchDB are products to watch, but for different reasons. Riak was showing growth that might pull it out of the lower tier, but it has not been able to distance itself yet. CouchDB has had major messaging issues with Couchbase going its own way, and Apache trying to clean up the mess left behind. With the Apache brand, CouchDB could still show demand, but this is definitely a critical year for the tool. The other tools are quickly falling into “also ran” status.

As always, if there are other NoSQL tools that should be included, please let me know in the comments.

So, here are the trends from Indeed.com:

JavaScript demand still outpaces the other languages, but the growth in the past year has been much slower. There is a jump in the past month or two, but we need to see the trends in 6 months to see if this is sustained growth. PHP, Python and Ruby are all showing solid positive trends. Groovy does seem to be growing but still lags a good amount behind the others. Erlang is showing some demand, but trails all other languages in this profile.

Now, let’s look at the short-term trends from SimplyHired.com:

SimplyHired shows very little growth in JavaScript over the course of the past 18 months, with some highs and lows in between. PHP, Python and Ruby are pacing each other, but also have not show much growth in the same period. Groovy demand is low compared to the others, so it is hard to tell if it has grown much. Erlang demand barely registers on this graph.

Lastly, we have the relative trends for job growth from Indeed.com. This shows an interesting perspective of the job trends, comparing percentage growth as opposed to percentage of all postings.

By showing relative growth, this graphs shows what companies are starting to use or where trends could be headed. Groovy and Erlang did not show much demand, but they are growing significantly. Granted, when there is little demand for a language, large growth is difficult to put into perspective. So, if there is 4500% growth, that could mean there was 1 job and that grew to 45 jobs. That is huge relative growth, but it will take some time before this effects the demand when compared to JavaScript and PHP. Interesting, Ruby growth is still fairly high and it is starting to level off. Python, PHP and Javascript do not show huge relative growth, but JavaScript and PHP have been in high demand for a long time so 100% growth (or greater) is a large number of jobs.

Interestingly, the trends have flattened a bit in the past year, when I would have expected these languages should be growing. I would say that HTML5 growth is affecting the other languages, but even JavaScript is not showing the results of this. Obviously, we need to watch these trends to see if HTML5 starts to have an affect. The growth of Groovy and Erlang is interesting, but with such comparatively low demand it just means we need to keep an eye on the trends for those languages. The one thing that concerns me is the lack of recent growth overall. I am not sure if this is due to the economy, but most of my reading points to the idea that all of these languages should be growing. These are definitely trends that need to be watched closely.

Related articles

• RedMonk Programming Language Rankings: CoffeeScript and Java Make Gains (readwriteweb.com)
• What Happened To The 9 Programming Languages To Watch in 2011 (regulargeek.com)
• Traditional Programming Language Job Trends – February 2012 (regulargeek.com)

First, here is a look at the job trends from Indeed.com:

Most of the job trends seem to have gone flat in the past year. Objective-C is showing solid growth and C# is actually showing a slight upward trend. You may wonder why this is happening and in the past I had guessed that this was economy related. Given the activity I have seen in the past year, I am starting to think that the growth in jobs is not happening in these traditional languages as much. There is huge growth in mobile development, especially with Objective-C leading the way in iOS development. You may think that Java should increase given its ties to Android, but Java is starting to slowly decline in the enterprise, so mobile growth is just offsetting this decline. Perl shows a slightly declining trend, but it is not sustained enough yet to really have comments about.

Now, let’s look at SimplyHired’s short term trends:

SimplyHired’s trends are fairly similar to Indeed, but there are some differences. First, Visual Basic looks like it is in decline, which would make sense. Objective-C does not show the same type of growth as the Indeed trends, only gaining slightly. All of the others look fairly steady in the past few months.

Finally, here is a review of the relative scaling from Indeed. This provides an interesting trend graph based on job growth:

Objective-C continues to grow like a weed, with some minor dips every few months. C# growth is solid, hovering around 100% for the past 3 years. Visual Basic and C++ continue to show no growth. Perl and Java are still showing signs of life, but growing at 25% is not very significant.

What does all this mean? First, it is clear the iOS development is hot as is all mobile development. It will be interesting to see if Java can get some sustained growth with the rise of Android developmnent. From the trend perspective, Perl should be watched to see if there is a significant decline over the next year. C# will likely continue its growth as a replacement for C++ and as a language for Windows Phone development. Lastly, Visual Basic really looks like it may finally disappear over the next few years.

UPDATE: For those of you looking for Ruby, Python, Groovy, JavaScript, PHP or Erlang, please look at the February 2012 Web and Scripting Job Trends.

Related articles

• What Happened To The 9 Programming Languages To Watch in 2011 (regulargeek.com)
• Giving Thanks To Arcane Programming Languages (regulargeek.com)
• Analysis of job trends on Twitter suggests iPhone and iPad developers in strong demand in 2012 (prweb.com)

When we talk about social networking, even from a corporate and business angle, we are almost always talking about public social networks such as Facebook and Twitter. These networks allow people and businesses to join freely and interact freely. For a company, the public nature of social networking exposure is a highly desirable one, as a business’ Facebook profile can act as a brochure, marketing source, communications outlet, and white pages guide all rolled into one.

But, increasingly, companies are turning to a different kind of social network, an internal one, with the aim of accomplishing a different set of goals. With an internal network, a business is trying to foster communication between employees, not between the company and its consumers. It is further trying to establish a secure forum for open and honest discourse, not simply to advertise and promote the business. The objectives are undoubtedly very different ones, but the basic concept is the same. An internal social networking site, after all, acts as a sort of Facebook application that is specifically programmed for company employees.

Many companies have already begun using internal social networks. With the arrival of several new and highly-heralded social software applications, IBM Connections perhaps being foremost among them, this trend can only be expected to continue and accelerate in coming years. So, what are the benefits of having an internal social network? And what are the drawbacks or challenges? Let’s take a quick look:

The Benefits of Having an Internal Social Network

• Boosts corporate ingenuity. Employees can propose changes or ideas, and others can vote on them, meaning that great conceptions can come from anywhere in the corporation.
• Improves company cohesiveness. Having an internal social network provides a relaxed and communicative environment for employees, even while at work. This has been shown to boost overall cohesiveness, which in turn strengthens worker motivation.
• Satisfies workers. Workers overwhelmingly support the implementation of an internal social network. While many choose not to use it, others feel more satisfied, engaged, and content with their position within the company after taking part.
• Creates a one-stop communication shop. Employees with complaints, managers planning a meeting, or departments coordinating with each other can achieve tremendous efficiencies by using an internal social networking application. This application, after all, can be used for business as well as more frivolous uses.
• Enter the cloud. Cloud computing has taken off in recent years, and many companies are working to get on board. Having a web-based social networking application can help employees facilitate that transition.

The Drawbacks of Having an Internal Social Network

• Identity management. When asked to list a challenge of internal networks, companies that have switched over routinely note that managing the profiles and identities of employees can be a very difficult task, especially in the early going. The challenge is even greater when a company has several subsidiaries or different entities spread out over multiple countries.
• Technical challenges. Along similar lines, establishing and maintaining a network involves considerable time and effort on a technical level. Many companies, however, choose to outsource these services. Doing so saves time, but can add up quickly in costs.
• Security and monitoring. On an internal social network, employees may discuss a wide range of matters that the company would not want publicly disseminated. This means that the utmost security precautions must be taken in order to insure that the network is consistently and reliably secure. Furthermore, along these lines, the company needs to establish a monitoring policy. What can and cannot be said over the internal network? Who will determine and deal with issues of inappropriate conduct? Even in a professional environment, such challenges arise with surprisingly regularity.
• Productivity losses. A very real concern of those against internal social networks is that these networks only reduce employee productivity without provide any offsetting corporate gains. If employees spend all their time chatting with a co-worker across the office, they are only less likely to accomplish their work.

These are the major pros and cons of internal social networks. It is probably safe to assume that such networks will only become increasingly common in the coming years. Even so, it is important that a company carefully weighs the benefits and the drawbacks before implementing a network. While there are a good number of possible arguments for and against getting an internal social network, all these factors should ultimately be considered in light of the individual company’s needs.

This is a guest post from Samantha Peters. Samantha is a blogger who enjoys writing for tech and career blogs covering a topics such as social media within the workplace. You can find Samantha at TheTechUpdate.com, and on Twitter and Facebook.

Related articles

• Why Internal Social Networks Usually Fail (socialfresh.com)
• Solidifying the Social Media Bubble (regulargeek.com)
• A Look Back And A Look Ahead At 2012 (regulargeek.com)
• Employees on Social Networks: To Be or Not To Be… (socialmediaexplorer.com)