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)

And all this business about apps is a real spoiler for suspension of disbelief. I’m clicking a link, expecting to learn more about what I was reading (that was certainly the author’s intent) but instead I get an ad for an app. If I seriously consider it, I’ve lost my train of thought. If I actually take the detour and install it, I’ve lost bigtime. The best way to minimize the loss is hit the Back button and skip it. But that’s a loss too. I clicked the link for a reason. And that was thwarted.

The main concept here is that if you provide links in your mobile application, then you should be linking to some information about the topic you were reading, not an advertisement for a different app. By itself, this complaint seems to be a bit of a stretch. However, he follows with another post a few weeks later that really explains his issue:

Every time around the loop, since then, the Internet has served as the antidote to the controls that the tech industry would place on users. Every time, the tech industry has a rationale, with some validity, that wide-open access would be a nightmare. But eventually we overcome their barriers, and another layer comes on.

Basically, Dave is seeing these mobile apps as trying to kill the web. If the app is trying to control interactivity by only supplying a “walled garden”, similar to what Facebook is doing, then the user really loses the power of the web. The core idea of linking gets lost in this scenario. However, what if the web is more than just links?

Prior to the last few years, people were very document-centric and reading HTML pages from a PC. Now, we have mobile devices that allow you to use the web whenever you want no matter where you are. We also had web applications that did not allow you to take your information elsewhere or integrate with other applications. Now, many applications use your Twitter or Facebook login in order to authenticate, and then post statuses or even create events in Facebook.

In order to support all of this integration, the web is evolving. The web is no longer just HTML. Last summer, I wrote about the rise of the API:

As the web evolves, much of that evolution will be powered by application APIs. Some of the APIs will be application specific, like the Twitter API, and others will be more generic like the various semantic web standards. All of these available APIs allow programmers to create more interesting applications, and potentially a new API layer on top of what already exists. What this means in the long term is that we are finally getting to the point where the semantic web had hoped to be, linking data between various applications and hopefully doing something interesting.

A web of links can be limiting when looking at applications. When looking at reading a news story, links make sense, but reading articles is only part of the web. By looking at the data available, we are starting to create a more interactive and informative web. Sarah Perez at TechCrunch thinks this could be moving towards a web of apps, but that post is more focused on mobile apps. As I said previously, mobile apps tend to be limiting in their own ways.

Think about the possibilities of using the various APIs that are available. I am not just talking about the social network APIs, I am talking about things like Freebase, a huge collection of data, or even data aggregator/providers like Gnip and DataSift. Using these services, developers can build interesting applications using data from various sources without worrying about what the Twitter API looks like.

These types of services provide a level of abstraction that developers are used to. First, you get the core APIs, then you start abstracting those APIs into something easier to use. Once concerns about low-level APIs are removed, developers can focus on being more productive with the new abstraction layer and start solving real problems. Once developers focus on real problems, that is when the real fun begins.

So, is the web just a bunch of links or are we finally getting a layer of abstraction on top of all of the web applications. This layer of abstraction is a normal evolution for developers, and we just need to ensure this is translated into more interesting applications.

Related articles from RegularGeek:

• Twitter Should Cut The SMS Cord
• A Look Back And A Look Ahead At 2012
• Plus Or Like, Choose Your Sharing Weapon

First, here are the comments I had on each language:

1. Lua – The language is seeing some good activity on GitHub and StackOverflow. It has a solid Tiobe ranking, but more importantly, jobs for Lua are becoming available. The relative trend for Lua is a great indicator that it is ready to go mainstream.
2. R – With data analysis and big data becoming a part of every web startup, languages catering to the data crowd will become popular. The job trend data will be the most interesting part to watch here.
3. Clojure – While not popular within the Tiobe index, it is popular in some programming circles. In particular, its job trend growth is showing that it could be posed for a big year of adoption.
4. Go – Only Tiobe really shows this as a popular language. It is not ranked well in the Dataist Tier, and job trends are not very reliable yet. However, with a parent of Google it may not need purely organic growth.
5. Erlang – This has been around for a few years and has decent trends all around. With the continued growth of real-time technologies like XMPP (eJabberd specifically), PubSubHubbub and others, 2011 could be a year where it becomes the next Python.
6. Scala – This is one of the interesting trends. Scala has a very good showing in the Dataist Tier, but is not really ranked in the Tiobe index. With the solid job growth trends and popular adopters (i.e. Twitter), Scala could gain a serious amount of acceptance.
7. Groovy – More than anything, I believe Groovy missed its window of opportunity. It is a solid scripting language with decent job growth trends, but how can it differentiate itself from Ruby, Python, Erlang and Scala?
8. Scheme – For whatever reason, this language refuses to go away and has even picked up some interest. Without decent job growth, we could be another year away from Scheme breaking out again, at least 30 years after it broke out the first time.
9. ActionScript – ActionScript is included in this list because of its high ranking on Tiobe and the Dataist Tier. However, the job trends do not point to good things for the language. It could be a temporary slump, so you should keep an eye on it next year.

• A is for Algol 60, which can be considered the father of structured programming languages.
• B is for BCPL, which we can blame for the travesty that is C.
• C is for Clipper, and we hope you never used it.
• D is for Dylan, which is like LISP without parentheses.
• E is for Eiffel, which has some cool features that still are not in Java.
• F is for Factor and Forth, because everyone loves stacks.
• G is for Go, as proof of what happens when Rob Pike and Ken Thompson get bored.
• H is for Haskell, one of a host of functional languages.
• I is for Inform, giving life to interactive fiction.
• J is for Java, because so few languages start with J.
• K is for KRL, a frame-based knowledge representation language.
• L is for LISP, because we love our silly parentheses.
• M is for Modula-2, mainly because you probably didn’t know there was a Modula or a successor named Modula-3.
• N is for NATURAL, which I have never actually seen used, just discussed.
• O is for Oberon, because Objective-C gets too much publicity already.
• P is for Prolog, progamming logic never seemed so fun.
• Q is for Qt, although it is more of an application framework.
• R is for REXX, an interpreted glue language inflicted upon us by IBM.
• S is for SNOBOL, one of the first string processing and manipulation languages.
• T is for Tcl, which eventually grew a Tk appendage.
• U is for UNITY, because parallelism is cool and flow control is for the weak.
• V is for Verilog, a hardware description language.
• W is for WebGL, bringing OpenGL to JavaScript.
• X is for XQuery, because even XML needs a programming language.
• Y is for Yorick, and all those graphs and simulations.
• Z is for Zsh, one of the many Unix shells.

Lastly, many thanks to Wikipedia for the “History of Programming Languages”, “List of Programming Languages”, “Timeline of Programming Languages” and much information about the languages themselves.

First, you need to figure out whether NoSQL fits your problem:

• Do your data needs include massive scalability in a system that supports a highly distributed set of nodes resilient to network outages and inconsistency? Then you might consider NoSql alternatives.
• Do you need a DBMS that doesn’t try to force you into static data schemas? Do you need the utmost of data model flexibility? Then you might consider NoSql alternatives.
• Is your database going to be filled with a truly massive number of objects with very simply query requirements? Is throughput an absolute priority down to the milliseconds? Then you might consider NoSql alternatives.
• Is your database going to be hit with a truly fantastic amount of write activity? Then you might consider NoSql alternatives.
• Would your solution benefit greatly from the utmost in maintenance and administration simplicity? Then you might consider NoSql alternatives.

If you talk to any traditional RDBMS developer, they will say that none of these points really require a NoSQL solution or that some of the issues are more related to design problems instead of data storage issues. Those talking points aside, there is some reason that these types of issues keep coming up. Traditional RDBMS systems that are being used at scale require significant administration and an administrator who is very good at their job. One of the reasons that people are using NoSQL solutions in these scenarios is that you do not need to be an experienced Oracle cluster DBA, you can just be a well-read software engineer.

One difference between RDBMS and NoSQL solutions is that you really need to understand how you are going to use the database. For an RDBMS, this was not a concern because they are meant as general data storage. The various NoSQL solutions have different purposes. Document stores are different than object stores which are different than the other storage models. The topic of choosing the appropriate type of solution is worthy of its own blog post, so I won’t cover it here. The important thing to note is that each storage model has advantages and disadvantages, so choosing the right solution can make your implementation much smoother.

However, there are other things you need to think about when researching NoSQL solutions. NoSQL is an immature market, so there are other issues that you need to be aware of. First, there is the anonymous rant about MongoDB that has been heavily talked about this week. The following is a condensed version of the issues in the rant:

• MongoDB issues writes in unsafe ways by default in order to win benchmarks: If you don’t issue getLastError(), MongoDB doesn’t wait for any confirmation from the database that the command was processed.
• MongoDB can lose data in many startling ways: Recovery on corrupt database was not successful, pre transaction log. Replication between master and slave had gaps in the oplogs, causing slaves to be missing records the master had. Yes, there is no checksum, and yes, the replication status had the slaves current
• MongoDB requires a global write lock to issue any write
• MongoDB’s sharding doesn’t work that well under load: Adding a shard under heavy load is a nightmare. Mongo either moves chunks between shards so quickly it DOSes the production traffic, or refuses to more chunks altogether.
• mongos is unreliable: The mongod/config server/mongos architecture is actually pretty reasonable and clever. Unfortunately, mongos is complete garbage. Under load, it crashed anywhere from every few hours to every few days.
• MongoDB actually once deleted the entire dataset: MongoDB 1.6, in replica set configuration, would sometimes determine the wrong node (often an empty node) was the freshest copy of the data available. It would then DELETE ALL THE DATA ON THE REPLICA (which may have been the 700GB of good data) AND REPLICATE THE EMPTY SET… They fixed this in 1.8.
• Things were shipped that should have never been shipped: Things with known, embarrassing bugs that could cause data problems were in “stable” releases—and often we weren’t told about these issues until after they bit us… The response was to send up a hot patch and that they were calling an RC internally, and then run that on our data.
• Replication was lackluster on busy servers: Replication would often, again, either DOS the master, or replicate so slowly that it would take far too long and the oplog would be exhausted (even with a 50G oplog).

Obviously, this is a long list of problems, but you will notice that the version numbers are varied, while MongoDB v2.0.1 has already been released and v1.8 was originally released in February 2011, which points out that some of this information could just be old. More than anything, the post seems like a list of issues over several versions. And that is part of the problem when reading posts like this. If you try to think what Oracle was like prior to v7, you probably don’t remember, but if you ask an experienced DBA they can tell you horror stories. Things were not all that rosy when RDBMS systems were trying to mature.

This is also the nature of software, it has defects and typically severe defects when the software is first released. NoSQL is still leading edge technology, so you have to assume you are taking some risks when you try to implement your storage solution with one of those products. To put this into more obvious terms, one of the most successful pieces of software sucked until it got past v3.1 and that was Microsoft Windows.

Michael Bolton has an interesting post regarding confusion as an oracle:

James peered over his glasses. “When you’re confused,” he said, “that’s a sign that there’s something confusing going on. I gave you a confusing product to test. Confusion might not be fun, but it’s a natural consequence when you’re dealing with a confusing product.” James was tacitly suggesting that Jon’s confusion cound be used as an oracle—a heuristic principle or mechanism by which we recognize a problem.

When the QA team is confused, that points to potential issues and should be used as a heuristic. The confusion could be from a few sources. First, the test script could be out of sync with the user interface in such a way that is not obvious how the tester should proceed. This can happen with any application that is evolving throughout the development lifecycle. Second, you could have someone that has not been trained on the application as the tester. This can quickly be remedied by providing the appropriate information on how to use the application. It could also point to an incomplete test script, meaning someone new cannot execute the test script without additional instruction.

Another reason the QA team could be confused is because the application is confusing. This is not a good sign and should be seen as a warning to the development team. Most likely there is a usability defect in the application. For some teams, usability defects do not exist and usability issues get added to the list of things to do. This is a big mistake when developing web applications. Almost a year ago I wrote about Krug’s usability rules:

The first two Krug rules of usability are very related:

1. Don’t make me think – as far as is humanly possible, when I look at a web page it should be self-evident, obvious, self-explanatory.
2. It doesn’t matter how many times I have to click, as long as each click is a mindless unambiguous choice.

I love the “don’t make me think” rule. If you design your application with this rule in mind, you will get past most usability problems. However, if you are a startup and developing for a large userbase, you may have slightly more concerns. Mark Evans wrote recently about a rule of thumb “I get it”:

But if you push aside the entrepreneurial enthusiasm, a startup’s success prospects depend on a compelling idea and, as important, the ability to quickly get potential users to say ”Yes, I get it”. This means being crystal clear what the service or product does, and the value propositions/benefits being delivered.

The product/service needs to fill a need or convince users it meets a need they didn’t know they had. Getting users on board has to be user-friendly and efficient. And the product/service has to delight.

If you are following these basic principles, your product should not be confusing. I am a big believer in making things simple for users, because it means they will enjoy (or at least not hate) using the system. This is obviously a good thing, but more importantly, users will look for other ways to use your application.

So, why should a “confusing” application have usability defects tracked? If an application is confusing, that means it is going to be difficult to use. When an application is difficult to use, people stop using it because they can not see the benefits to using the system.

Usability is also hard to define, but if you look at Krug’s rules you will see that the user should not have to find the right thing to do, it should be fairly obvious. But, what about prior to production? You don’t have typical users on the system, so how do you determine usability? One thing I have seen is that the length of the test script can be a good trigger for something being too difficult.

Let’s assume you have manual testing being completed. Ignoring the test case setup instructions, how many steps are required to test one feature? This is similar to the number of clicks heuristic, but it is the number of actions a user must take in order to complete a task. You could say the number is something like 7 but that is not entirely useful. I have used “Why” as my metric of choice. If you ask “why do I need to complete this step?” and there is no obvious or definable reason, then you likely are introducing unnecessary steps to the task. If you can eliminate these issues, your application usability should improve.

To really make your application simpler, make sure your QA team starts questioning things in the beginning of the process. Someone writes the test script, and it could be the QA tester themselves. The developer and the tester should go through the test script and ask “why” for each step. This will proactively remove any stumbling blocks in the plan and have a much more usable system after it passes QA testing.

Are there any tips or tricks you have for improving usability?