Altabel Group's Blog

Archive for the ‘html5’ Category


Since the “flash crisis” (starting from the summer of 2013) a lot of game developers have collided with an issue of being crammed with outdated flash games with copyrights sold to various sponsors and game portals.

For the majority of the developers porting their old games to the new platforms could be an ideal option.

That is why I decided to write an article on how they could re-monetize old games with no great effort.

I suggest using HTML5 as this particular game platform allows making the porting without huge investments.

The article reveals the following questions:

  • What games are suitable for the porting to the HTML5?
  • How to make the porting qualitatively?
  • How to sell the renewed game wisely?

Briefly about HTML5:

Firstly a few words, why I suggest using HTML5 for porting flash games: HTML5 is a widely known technology that has such syntactic features as , and elements, as well as the integration of scalable vector graphics (SVG) content (replacing generic tags), and MathML for mathematical formulas. These features allow to make it easy to include and handle multimedia and graphical content on the web without having to resort to proprietary plugins and APIs.

I guess it does not require a lot introduction, still for more information feel free to visit:

Below I would like to point out the main benefits and some shortcomings of using HTML5 for porting a flash game.


  1. Cross-platform (the ability to launch a game on any platform);
  2. The development of HTML5 apps takes relatively little time;
  3. Saves resources (writing of the universal code for all platforms is less costly in comparison with developing native apps for each platform);
  4. Easy bug-fixing.


  1. Security;
  2. Possible productions issues;
  3. Some limitations of the mobile devices;
  4. Lack of the common standard for the browsers and devices (bug-fix could be quite time-consuming).

So, if you are concerned in porting you game to the web we could proceed to the first question:

What games are suitable for being ported to HTML5?

Not any game is suitable for being ported to HTML5. There are a few limitations that should be taken into account, for instance:

  • While porting your game under mobile HTML5 the attention should be paid to the control. If the control is managed through the keyboard it means that apparently you will have to port the control as well in order to gain the desired game experience. It is possible to develop tab sensor, still it is not often useful because the player’s fingers hedge the majority of the display what leads to the gameplay/ levels reconstruction or even to rejecting the idea of porting the game.
  • 3D games are not suitable for porting under the mobile web (WebGL technology is not supported by the majority of the mobile browsers).

The porting process is greatly depends on the HTML5 app building approach.

How to make the porting qualitatively?

While speaking about the games with Canvas rendering there would be a three- step approach:

  • Porting the graphics

Art is almost the only thing that we would take from the old game, as the code will be written from a scratch. Porting of the graphics is a complex procedure. Its complexity depends on the initial game format. In the end we should get the raster version of every element of the game starting from the background up to effect animation.

  • Porting the logics on JavaScript

This is the most significant and time-consuming process. It could take from 2 weeks to а couple of months depending on the particular game. Normally a game is developed with using a framework. The choice of the frame is not a simple question and deserves a separate article.

  • Testing and bug-fixing

Worth mentioning that to make the testing of the mobile- web app as effective as possible you should use a number of mobile devices, at least the most popular. Otherwise it is possible to refer to the company that provides QA and testing services.

When the testing is finished the question regarding the distribution arises as well as regarding licensing and it’s specific.

Despite the fact that lately the positive tendency of the HTML5 games is observed, for many developers the monetizing issue is on the agenda. Still in case of applying the wise business model your HTML5 game could become quite beneficial.

How to monetize your game?

  • Selling of the exclusive license

Basically the portal SpilGames bought the exclusive licenses and was a price leader for the developers. Still, recently a number of changes have been noticed in the company and it is quite unclear yet whether they will continue purchasing the content. In other cases, in order to sale an exclusive license you will have to make a good scouting.

  • Selling the site-locks

It is one of the most prevalent ways to monetize the game. In average you could get the profit of about 200-600 USD per game. Just find active customers. Actually there are plenty of portals. First of all this is in interest to the flash games portals owners to keep the constant user base. Generally the users get their mobile devices and returning to the favorite flash game portals and are not able to launch any flash game. The owner of the portal whether loses this user or suggests the alternative- a game that could be launched on the mobile device browser. Another variant is to sell the unexclusive license through auction-portals like FGL.

  • Revenue share scheme

In this case you give your game to be placed in a portal or a portal network and get a part of the revenue form the commercials that were shown in the game. The revenue is mostly depends on the customer, still do not expect huge profit. When it is about a good traffic and the customer is convinced in the profitability of the game, he usually will buy the site-locks.

  • Self-promotion and commercials revenue

The developer integrates the commercials right in the game and gives it free on the partner-site. The revenue is counted on the basis of the commercials shown directly in the game. Thought in comparison with the flash market prime-time, nowadays there are no automated channels of distribution in HTM5 game dev. So it is manual work so far.

It is also worth mentioning that the Google AdWords (the most effective advertisement) will not suit for distribution of such game as Google requires direct linking to the domains where the game will be shown. 

Some useful advice:

  • Obfuscate you HTML 5 games in order to secure them from piracy. Sure, it won’t provide a perfect security, still will become an obstacle to steal the game and will filter out a number of pirates.
  • Sell the game for a particular platform/ market. Reserve the title rights. HTM5 is a universal technology so you are able to convert your game to any platform market (HTML5, web, iOS, Android- these are three different licenses.)
  • While selling the site-locks assure that the name of the portal as well as its mirrors are stated in the contract.
  • Using the revenue share scheme request the access to the statistics.

Hope this tips would be useful. Also if you have any suggestions and better solutions, feel free to share in the comments!

Tatyana Ogneva

Tatyana Ogneva 
Skype ID: ognewatatyana
Business Development Manager (LI page)
Altabel Group – Professional Software Development


Responsive web design isn’t the future, it’s the present

In our humble opinion it’s late to debate whether responsive web design is the future because it’s already the present of everybody’s business represented online. Consumer/client behavior has been changing. According to statistics and analysts’ predictions, for instance, for the first time since 2001, PC sales are projected to be lower than they were in 2012; smartphone sales will double PC sales in 2014; tablet sales are expected to exceed 100 million this year and may top notebooks next year. So the shift to mobile is happening at an extraordinary speed, and tablets and smartphones are becoming extremely popular for business and pleasure matters. This means people view your content on thousands of oddly shaped and different sized screens. What’s more, according to Google research, mobile users “expect their mobile experience to be as good as their desktop experience” – this expectation poses a thorny challenge for both, business stakeholders and web designers and developers.

So this is no longer about “How do I make my website available to a smartphone or tablet?” – it’s “How do I make my business available in smartphone and tablet context?”. For some business it’s not important – it’s literally critical, for example: according to the Pew Research Center, 60% of tablet users prefer reading news on the mobile web than via an app; the same percentage is quite common for e-commerce sites according to Google Analytics and that’s why RWD has been listed in E-commerce marketing checklist for 2013. If you wish to identify the percentage of your audience that use mobile devices use the Google Analytics Mobile Overview report feature: if mobile users are more than 5% of your total audience you should consider catering for them too.

In general, there are three main approaches to providing information and interaction to mobile/tablet device users : responsive (and adaptive) web design, mobilized websites, and mobile apps. It’s important to understand that these are different marketing channels and their value proposition is very different. A mobile web site may do something very different from a mobile app – simply said, “if your goal is just to display and show content beautifully create a responsive or mobilized website; if your goal is to show productivity tools, build an app”. Which option is the best for your business will depend on your use case, your users’ habits and your budget.

Responsive web design vs mobile web development: advantages and challenges

To talk about advantages of responsive web design, let’s start from its definition. RWD is a front-end development approach aimed at crafting device agnostic sites. It uses “media queries” to figure out what resolution of device it’s being served on. Flexible images and fluid grids then size correctly to fit the screen. So responsive design provides easy reading and navigation with a minimum of resizing, panning, and scrolling, and eliminates the need for separate sites for different devices. Adaptive web design is either a subset of responsive design, or a related approach. “Responsive design will show more stuff or less, optimized for a mobile layout, but is likely to still provide access to the full desktop-view’s content. Adaptive design, by contrast, might show very different content, and also present a different UI, reflecting touchscreen’s tap/swipe/scroll versus desktop’s keyboard/mouse interaction.” In either case, responsive (and adaptive) web design will be based on the same code as a desktop site, and will locate on the same URL.

– In the definition above a couple of advantages of RWD are pointed out. Indeed, it improves user web browsing experience since a website adapts to the browser or device compatibility automatically and makes the content look good. For customers it shows that your business is receptive to changing technology and understanding of consumers’ needs.

– From business perspective, “one website – multiple devices” concept means that it’s easy to manage and focus on developing good content for your website. The same applies to analytics and strategy development and deployment since there is only one set of analytics to examine and a single strategy to develop and deploy. From maintenance standpoint, the technique is great too as one update affects all of your platforms.

– Additionally, responsive websites are easier for consumers to find than traditional or mobile web sites because they come up higher in search engines’ rankings. “In fact, Google recommends responsive web design because having a single URL for desktop and mobile sites makes it easier for Google to discover content and for Google’s algorithms to assign indexing properties to content.”

– One more advantage from the future perspective, as Resnick predicts, is: “As the internet transforms further into a platform of services and user interfaces that tie those services together, leveraging RWD technology in the future will allow companies to integrate a plethora of back-end services, such as Facebook, Twitter,, and Amazon Web Services, and then present the integrated data back out the front-end iad layer on a responsive design so the application looks great on all devices without custom coding needed for each device or screen size. No longer are expensive back-end solutions needed to integrate legacy systems with business partners.”

Actually responsive web design is quite immature so it faces many challenges too.

– Even though we might view a responsive website on a smaller screen and it displays less visible content or smaller-sized images, this does not mean that the site will load faster. The thing is that from one side responsive websites are not much smaller in download size when viewed on smaller devices or screen resolutions compared to when being viewed on a desktop browser jacked into a broadband internet service provider, on the other hand mobile internet speeds still lag much behind broadband internet ones. Thus responsive web sites need advanced optimization, such as serving smaller images and conditionally loading scripts, and much more. An alternative may be found in dedicated mobile web development solutions since they specifically address mobile devices.

– The related issue concerns complexity. Responsive web designs are inherently complex because they are trying to support many viewing experiences without necessarily optimizing the experience for one particular device (or genre of devices). Mobile browsers will have to deal with a big HTML file, and the site would need to carefully avoid running specific scripts, loading certain CSS and download large images. Perfect implementation is possible, still avoiding over-resourcing requires scripts or code and therefore additional complexity. Typical “m dot” site wins in this case and is simple. It usually has a small amount of HTML, limited scripts, CSS, and images (if at all) as it is built specifically for its intended small-screen, touchscreen mobile devices viewing experience.

– As for UI and UX, responsive websites have limitations here. Not only in screen size, they are also limited for utilizing or recognizing key mobile features such as user location, connectivity, device limitations, software potential, and user needs. Mobilized sites and mobile apps will provide broader opportunities and advantages here.

Information architecture can be an issue. It needs to be carefully considered and should be hierarchically structured before the design implementation.

Advertising is an issue. Ads will have to shift with the sites, something that will wreak havoc with advertisers who want guaranteed placements on sites.

So, which approach will or do you use to present your business online?

HTML5’s momentum and Best tools for responsive web design

Responsive web design is not a specific technology but a whole design approach. However, responsive design is enabled primarily by CSS3 and JavaScript, which fall under the banner of HTML5. HTML5 is really maturing in terms of its functionality and, more importantly, its speed. So now HTML5 is the backbone of the new and interactive features of responsive web design.

To achieve a smooth flow from a large screen to a small one it takes a lot of patience and perseverance. To reach a seamless result there are a number of tools that help you with it. Below you will find a list of best responsive design tools broadly recommended in the web as well as by Altabel’s dev team:

1. Gridset
A tool that helps you design, prototype and build any type of grid layout required – columnar grids, asymmetrical, fixed, fluid or responsive grids. It even lets you create a library of your own grids, with a variety of presets available. It will allow you to build responsive prototypes (without all the calculations) very quickly and easily, providing all the measurements and tools to integrate with your existing markup.
Alternatives: Frameless, Tiny Fluid Grid, Gridpak, SimpleGrid, Responsify,, Golden Grid System and Photoshop Grid for Responsive Design.

2. Bootstrap
An intuitive and powerful front-end framework from Twitter to start a responsive website fast and easy. It addresses the most popular user interface components and interactions, uses a 12-column responsive grid system with simple and flexible HTML, CSS, and Javascript and features dozens of components, styles and JavaScript plug-ins, with basic global display, typography and link styles all set. It also gives the option of customizing components of your website for instance by using the Customizer .
Alternatives: Skeleton, Foundation, Base, InuitCSS, LESS Framework, Gridless, 320 and Upand Gumby.

3. Wirefy
Clients wish to see how wireframes will adapt to different device sizes. Static wireframes aren’t particularly useful to show a client how responsive your design is, or what functionality is being suggested. But rapid prototyping by building flexible wireframes may. Wirefy is a collection of functional responsive HTML snippets and templates that scale as the browser is resized (working across multiple devices). It builds on tools such as the Frameless grid system and Bootstrap, and uses CSS media queries that adapt to different device resolutions. Wirefy focuses on key elements such as typography, tables, images, slideshow, forms, tab panel, paginator, menu, etc., focusing on the users.
Alternatives: Froont, Interactive Style Tiles, Responsive Sketch Sheets, Responsive Wireframe Template, Interface Sketch Templates, Responsive Device Diagrams, Wirify.

4. FlevNav
Navigation strategy is a really critical component of any responsive website design. FlexNav is a jQuery plugin that takes a device-agnostic approach to complex site navigation. It is a mobile-first concept using media queries and JavaScript to create a menu with drop downs. It features multiple nested sub-menus, with support for em units and tap targets to reveal sub-menus for touchscreens.
Alternatives: TinyNav.js, Navigation Patterns for Responsive Design, MeanMenu, Responsive Solutions for Menu Navigation, jPanelMenu.

5. Adaptive Images
Previously, making your website images responsive was tricky and usually meant using a “hack-around”. Now several tools may simplify this task. Using a one htaccess file, one php file and a single line of JavaScript, Adaptive Images detects screen size of browsing devices, cashes and delivers device appropriate re-scaled versions of your web page’s embedded HTML images without any mark-up changes. Also it is entirely non-destructive, and works on existing websites and markups — without the need to edit anything. Adaptive Images works on the premise that you are already using the highest-resolution images on your site, and also offers a ton of customization options.
Alternatives:, jQuery Picture, ResponsiveImg, Retina.js and Retina Images.

6. FitText
As content scales according to a user’s viewport, the text will naturally wrap as the container is narrowed; and this often causes widows, orphans or your headlines to look rather ugly, and can even break the entire layout. FitText is a jQuery plugin specifically for headlines and big text. It auto-updates the font size according to the width of the element wrapping it, so you can achieve scalable headlines and a non-broken layout that can be caused by font-sizing issues. FitText works perfectly with Lettering.js or any CSS3 property thrown at it. There are options to fine-tune the text, including the ability to set min-max sizes and the level of scaling. Still FitText is only for headlines, and shouldn’t be used with paragraph text.
Alternatives: BigText, Lettering.js, Kerning.js, Kern.js, Type Butter and Slabtext.

7. Responsive Slides
This lightweight plugin allows you to create a responsive slider using elements inside a container. The images have to be the same size and jQuery 1.6 and up should be used. You can keep captions and other non-HTML elements inside the slides, while also using CSS3 transitions with JavaScript fallback. It works in all major desktop and mobile browsers, can support multiple slide shows, have settings for transition and timeout durations, automatic and manual fade, and have options for customization.
Alternatives: Flex Slider, Slides.js, PhotoSwipe, Supersized, Camera, RefineSlide, BlueberrySequence.js and Galleria.

8. Responsive Tables
Data tables in responsive design can be troublesome: you want it to not break responsive layouts, not hide content, let you see entire rows and columns, not be too small to read easily or zoomed in too far requiring scrolling. Here ZURB comes out – a simple JavaScript/CSS combination containing two key files: responsive-tables.js and responsive-tables.css. It works by taking the first column, which is often the unique key for a table, and “pinning” it to the left of the table, allowing you to scroll the other columns under it.
Alternatives: Responsive Data Tables, Stackable.js, Footable, Responsive Tables, Responsive Tables, Responsive SEO Friendly Data Tables.

9. Responsive Design Testing
Building a responsive website means constantly testing how it displays across mobile and tablet devices. You could resize the browser yourself, or use a browser extension or tools within your IDE; but there is an extremely simple tool that allows you to see how a page displays on different screen sizes, in a single view. With Matt Kersley’s RWD testing tool you just have to enter your website’s URL into the address bar to test a specific page in different widths and device sizes. Also you can share the results of the test with others by adding any URL to the end of the testing page address. One major benefit of this tool is that it can be self-hosted (available on GitHub) by downloading and installing it on your own site. You can then navigate through the frames that your website appears in, testing the entire site effortlessly.
Alternatives: Screen Queries, Screenfly, Responsivepx, Responsinator, Responsive, and Resize My Browser.

10. Respond.js
The problem with media queries in responsive web design is that they are a part of CSS3 specifications so they do not work with older browser versions such as IE8 and lower. Respond.js comes to the rescue for browsers that don’t support media queries directly, translating any media queries it finds into equivalent JavaScript.The script itself is incredibly small and lightweight. It works unobtrusively, and doesn’t rely on any other scripts or frameworks to run.
Alternatives: Modernizer, Adapt, Categorizr, CSS3 Media Queries and Enquire.js.

The tools above are ultra useful for any RWD project from the planning and designing phase right through to testing, and what’re your favorites?

Welcome to share your view points.

Helen Boyarchuk

Helen Boyarchuk
Skype ID: helen_boyarchuk
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

The Web as we know it have been born and matured on computers, but as it turns out now, computers no longer have dominance in it. According to a recent report by analyst Mary Meeker, mobile devices running iOS and Android now account for 45 percent of browsing, compared to just 35 percent for Windows machines. Moreover, Android and iOS have essentially achieved their share in just five years and their share is getting tremendously larger.

According to some forecasts their worldwide number of mobile devices users should overtake the worldwide number of PC users next year. If forecasts come true, this shift will not only continue, but accelerate. Based on data from Morgan Stanley, Meeker estimates roughly 2.9 billion people around the world will be using smartphones and tablets by 2015.

What does it mean now that more people are accessing the Web through tablets and smartphones rather than laptops and desktops? And is it really a big deal? Anyway, Internet is intended to be accessed from anywhere and thus from any device. Well, it is quite a change at least in terms most people consider the Web and how it gradually adapts to be used on mobile devices.

Apps-like sites
As mobile devices take over, the use of today’s desktop browsers like Internet Explorer, Chrome, Firefox, and Safari will decline. Mobile browsers are already very capable and will increasingly adopt HTML5 and leading-edge Web technologies. As mobile devices naturally have less screen area, the sites need to function more like mobile apps and less like collections of links. So the sites are likely to look like apps.

Apps may rule
Native apps for smartphones and tablets almost always surpass websites designed for mobile devices because they can tap into devices’ native capabilities for a more responsive and seamless experience. This is most likely to change in the nearest future – most experts agree HTML5 is eventually the way of the future. This is already the status quo in social gaming: for example Angry Birds and Words with Friends. Some services won’t be available at all to traditional PCs — they won’t be worth developers’ time.

Less information at once
Web sites and publishers will no longer be able to display everything new for users and hoping something will catch the user’s eye. Smaller screens and lower information density means sites will need to adjust to user preferences and profiles to customize the information they present. Increasingly, the Internet will become unusable unless sites believe they know who you are. Some services will handle these tasks themselves, but the most likely contenders for supplying digital identity credentials are Facebook, Google, Amazon, Apple, Twitter, and mobile carriers.

Sharing by default
In a mobile-focused Internet, anonymity becomes rare. Virtually every mobile device can be definitively associated with a single person (or small group of people). Defaults to share information and experiences with social circles and followers will be increasingly common, along with increasing reliance on disclosure of personal information (like location, status, and activities, and social connections) to drive key functionality. As the Internet re-orients around mobile, opting out of sharing will increasingly mean opting out of the Internet.

Emphasis on destination
Internet-based sites and services will increasingly function as a combination of content and functionality reluctant to link out to other sites or drive traffic (and potential advertising revenue) elsewhere. These have long been factors in many sites’ designs but mobile devices amplify these considerations by making traditional Web navigation awkward and difficult. Still URLs are not going to die – people will still send links to their friends and Web search will remain most users primary means of finding information online.

Going light weight
As people rely on mobile, cloud, and broadband services, the necessity to do things like commute, store large volumes of records or media, or patronize physical businesses will decline. Businesses won’t need to save years of invoices, statements, and paperwork in file boxes and storage facilities – cloud storage comes as their rescue. Banks will become purely virtual institutions consumers deal with online via their phones. Distance learning and collaborative tools will let students take their coursework with them anywhere — and eliminate the need to worry about reselling enormous textbooks.

Going mobile is an obvious trend today. Experts envisage that nearly every service, business, and person who wants to use the Internet will be thinking mobile first and PC second, if they think about PCs at all. Do you agree? And what other related changes can you imagine?

Many thanks for sharing your thoughts :)

Aliona Kavalevich

Aliona Kavalevich
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

The IT world is constantly forging ahead. There already exist several dozens of programming languages and software technologies. At the same time to choose the right thing for a specific project is not an easy thing to do.

Every technology has its own advantages and disadvantages. Hence, if you want to choose a certain implementation, which will be effective for both-development and its further support, you need to consider following issues: project scalability, its tasks and timeframes.

Large-scale projects (high load systems)

For big and high load systems (more than 3000 queries per sec, beginning from 10000 database tables) it is necessary to choose the technologies very comprehensively, as it will influence the general project productivity and security.

There are 4 suitable languages for the backend: Java, NodeJS, PHP and ASP. Though it’s better to use Java, as it allows achieving effective work speed, and gives the possibility to support hyperthreading and refacoring. Moreover, Java is one of the best fit from the point of view of development speed – there are plenty of handy frameworks.
It is better to remember, that NodeJS is a bit difficult to use when it comes to complicated calculations. Nevertheless, it helps to provide an easy project scalability and processing speed.

For the frontend it is better to use JavaScript and HTML. JavaScript makes any calculations much faster, while Flash copes better only with rendering, and HTML5 is not supported by all tools yet. That is why standard (as it may seem for many developers) suite of HTML and JavaScript is the best option here.

When it comes to high load systems, one should remember about extensibility, because it is one of the problem developers face to most often. Hence, it is necessary to think over the work layout with a database in details. For big projects it is better to put away relational databases, and turn attention to non-relational models, such as MongoDB и Redis. It is possible to use CouchDB as well.

It is relational bases that place a limit on the projects and do not give an opportunity to be extended easily. Non-relational models have a completely different structure: instead of SQL-queries API are used.

Middle-scale projects

While working on middle-scale projects (1000-3000 queries per sec, 2000-10000 database tables), i.e. not too load, but not home pages either, it is possible to use Java and PHP. In this case NodeJS will not give such attractive results as in high load projects.

Besides HTML and JavaScript, for the frontend it is allowed to use HTML5 and Flash as well. Nevertheless, it is necessary to be very careful here. The notion of middle-scale project is quite vague, thus, one should to draw upon the project tasks. If the question is about a small graphic maintaining, then probably it will make sense to replace Flash by the last HTML version (HTML5) together with JavaScript. In case the project needs detailed rasterizing and full script of graphic action, then Flash would be the best solution.

Databases can be both relational and non-relational. Everything depends on the further project development. If it is planned to grow rapidly, it is better to use non-relational models MongoDB or Redis. If a too big scalability is not required, Oracle will perfectly fit. The point is that in spite of being relational, Oracle is used in many projects that have a potential to scalability. At the same time there no extension problem emerge, even if several servers are used.

Small projects

When the question is about small projects (less than 1000 queries per sec, 2000 databases), it is essential to put away all the complicated things, that present in high load systems. Consequently, PHP, Ruby on the Rails (this framework allows fast development), Erlang are best for development here. No doubt Java can fit as well, though it would be much faster and easier to use PHP or Ruby.

For the frontend it’s better to practice Javascript, HTML5, HTML, Flash/Flex. Most often small projects do no presuppose a big growth, that is why MySQL or PostgreSQL are better to be chosen as a database. Oracle may turn to be too bulky and unprofitable for the client, while MongoDB and Redis will not be effective. The thing is that despite growing popularity of non-relational databases, the smallest mistake in their usage can entail serious consequences. In this context relational models are much easier. Hence, while working on small projects it is better not to spend time and practice relational models, such as MySQL and PostgreSQL.

To sum up everything above said, Java, NodeJS, PHP, ASP + JavaScript and HTML + MongoDB or Redis are better to be used while developing high-load projects. For middle-scale projects- Java, PHP + JavaScrit, HTML, HTML5, Flash + Oracle, MongoDB, Redis. For small ones – PHP, Ruby on the Rails, Erlang + JavaScript, HTML, HTML5, Flash + MySQL, Postgre SQL.
Anyway, apart from the project scalability it is essential to consider its potential. The reason is that the problems start after the project growth, when developers face to inability of an adequate project transfer to other servers and workload distribution. Besides, it is important to keep in mind the project tasks. It is highly possible to turn out, that what is popular today will not be effective for a specific project.

You know that my opinion is not the ultimate truth :-) I would be glad to read about your experience of using languages, databases while working on different projects!

Kind regards,

Nadya Klim

Nadya Klim
Business Development Manager
Altabel Group – Professional Software Development

HTML5 brings a host of new elements and attributes to allow developers to make their documents more easily understood by other systems (especially search engines!), display data more uniquely, and take on some of the load that has required complex JavaScript or browser plug-ins like Flash and Silverlight to handle. Here are some new items in HTML5 that will make it easier for you to write your Web sites.

1: video and audio
One of the biggest uses for Flash, Silverlight, and similar technologies is to get a multimedia item to play. With HTML5 supporting the new video and audio controls, those technologies are now relegated to being used for fallback status. The browser can now natively display the controls, and the content can be manipulated through JavaScript. Don’t let the codec confusion scare you away. You can specify multiple sources for content, so you can make sure that your multimedia will play regardless of what codec the user’s browser supports.

2: input type attributes
The venerable input element now has a type attribute, and browsers do some pretty slick things depending on its value. For example, set type to “datetime” and browsers can show calendar/clock controls to pick the right time, a trick that used to require JavaScript. There is a wide variety of type attributes, and learning them (and the additional attributes that go with some of them) will eliminate the need for a lot of JavaScript work.

3: canvas
The canvas tag gives HTML a bitmapped surface to work with, much like what you would use with GDI+ or the .NET Image object. While canvas isn’t perfect (layers need to be replicated by using multiple canvas objects stacked on top of each other, for example), it is a great way to build charts and graphs, which have been a traditional weak spot in HTML, as well as custom graphics. And that is just a start!

4: header and footer
The header and footer tags are two of the new semantic tags available. These two tags do not get you anything above and beyond div for the actual display. But they will reap long-term rewards for your search engine efforts, since the search engines will be able to tell the difference between “content” and things that are important to the user but that aren’t the actual content.

5: article and section
The article and section tags are two more semantic tags that will boost your search engine visibility. Articles can be composed of multiple sections, and a section can have multiple articles. Confusing? Not really. An article represents a full block of content, and a section is a piece of a bigger whole. For example, if you are looking at a blog, the front page might have a section for the listing of all the posts, and each post would be an article with a section for the actual post and another for comments.

6: output
The new output tag is unique, in that it expects its content to be generated dynamically with JavaScript. It has a value attribute, which can be manipulated through the DOM with JavaScript to change what is displayed on the screen. This is much more convenient than the current ways of doing things.

7: details
It seems like every Web site needs to have an expanding/collapsing block of text. While this is easy enough to do with JavaScript or server-side code, the details tag makes it even easier. It does exactly what we’ve all been doing for years now: makes a simple block that expands and collapses the content when the header is clicked. The details tag does not have widespread support yet, but it will soon.

8: figure and figcaption
Figure is a container for content (typically images, but it can be anything), and figcaption (which gets put inside the figure tag) provides a caption or subtitle for the contents of the figure tag. For example, you could have four images representing charts of sales growth within a figure tag, and a figcaption with text like “Year-to-year sales growth, 1989 – 1993.” The images would be shown next to each other with the text running below all four.

9: progress and meter
Progress and meter are similar. You use progress for a task or a “measure how complete something is” scenario. It also has an indeterminate mode for something that has an unknown duration (like searching a database). The meter tag is for gauges and measurements of value (thermometers, quantity used, etc.). While they may look alike on the screen in many cases, they do have different semantic meanings.

10: datalist
The datalist tag acts like a combo box, where the system provides a pre-made list of suggestions, but users are free to type in their own input as well. There are tons of possible uses for this, such as a search box pre-populated with items based on the user’s history. This is another one of those things that currently requires a bunch of JavaScript (or JavaScript libraries) to handle but that can be done natively with HTML5.

What other new tags have you found especially useful? Share your HTML5 experiences in comments.

Kind Regards,
Lina Deveikyte
Altabel Group – Professional Software Development

Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route.

1. We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. In terms of app experience, native apps can do more.

2. It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap.

3. Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation. On the other hand Web is often easier to develop, especially if targeting multiple devices.

4. One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Platforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit.

5. App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.

It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.

Kind Regards,
Lina Deveikyte
Altabel Group – Professional Software Development

Seems like the world is pushed towards HTML5. Apple has been amongst those trying so hard to get Web developers out of the Flash domination, and judging by the latest news of Adobe becoming HTML5-religious Apple’s anti-Flash campaign was successful. Becoming stronger and better polished HTML5 looks to supplant not only Flash but also press back such mobile giants as Apple, Google and Windows.

Recently the popular prediction has become that HTML5 will kill mobile apps business. The logic is simple: better HTML5 => higher quality developer’s tools release => better Web apps => improved Web-browsing experience on mobile devices. All these make the native applications position pretty unsteady. So will it necessarily lead to the twilight of native mobile apps development? At first glance – all point to this supposition. Still let’s take a deeper dig.

1. All the look and feel.
Native apps are intended to look glossier and perform better than their browser-based counterparts. As they are developed separately for each mobile platform and therefore use advantage of being OS customized and smartphones’ hardware features advanced. But will native apps preserve this advantage for a long time? Sounds doubtful…due to several reasons.
First, because to the growing variety of mobile platforms and their sub/versions. Recently developers have to spend more and more efforts on versioning and support and this is indeed exhausting and expensive. So perhaps the biggest potential benefit of HTML5 is that it will enable app developers to focus on making one version of each app running smoothly in many kinds of browsers, thus freeing them to move on to bringing more and better apps to market. And that’s definitely good, especially keeping in mind that a well-designed Web app can be indistinguishable from a native application for the user, but not ideal in this terms as still HTML5 browser apps run differently from browser to browser and from device to device making it quite difficult for developers to ensure that all mobile consumers will enjoy the way an app works in their setup.
Another point of concern so far has been that, despite all HTML5 improvements, in real-life use cases native apps still run better, faster and more predictably than browser apps. It’s natural because mostly native apps run from the phone’s memory and rely less on the network. But that’s surmountable with time – with the advent of 4G networks users will be able to retrieve content from the network far faster and more reliably than in the past.

2. Visibility and promotion.
After creating a quality application your next step will be to make it visible and popular longest possible. Native apps published in an app store may receive very little notice as app stores have grown and become bloated with shoddy or useless apps and thus accessing apps has become more of a hassle. The main issue is poor organizing and categorizing that results in difficulties to find a proper app for user’s need even if it exists in the store. Still poor cataloging of apps at big app stores could be smoothed over by specialized app stores.
Browser-based mobile apps spare developers app stores addiction and lend themselves better to Web promotion via social media like Twitter and Google+. Still even if it seems easier at first glance isn’t it still a challenge in terms of making visibility better and longer but not seen for a fleeting moment? For those creating Web apps, there’s just no good way and even a good review of a Web app on a popular site has only a temporary impact.
The way to get your app in front of potential customers is to get it featured in an app store. And this is gained by building an app that highlights unique hardware capabilities, exactly the features the hardware company use to sell the product. [These will likely be features that you can’t access today or in the foreseeable future with a Web app. This isn’t because HTML5 won’t advance, but because the device and OS manufacturers will always do their best to keep their products somewhat ahead of the lower-common-denominator Web platform. It is how they sell products.] That’s business-justified. So HTML5 is good for many apps, enterprise and customer ones, but not for the core features or the main UI.
Basically relying on HTML5 to quickly get to broad compatibility across the mobile landscape could become a trap if you follow selective strategy in your product distribution and want to have the app perceived distinguishing. For instance, you might want to build apps that only work on the latest and greatest version of a phone, and intentionally not on previous models. Then fewer people will be able to use it but those with the newest toys. [The more your app makes the hot new hardware look good, the more it’ll get promoted by the hardware or OS manufacturer. That can give your app presence it could not otherwise get. Once your product is succeeding on the brand-new hardware, you can start adapting it to other platforms.] Doesn’t this strategy distributed strategy look the most attractive?

3. Distribution and revenue generating.
As you may predict here we will mostly speak of Apple and its revenue-sharing mechanisms that has been receiving so many claims. Apple takes a 30% cut of all app sales through its store – the only way for consumers to get apps. That’s much compared to an option to build a web app and putting the whole revenue in your own pocket. This is especially unfavorable for applications with subscriptions as surprisingly this 30% cut doesn’t just cover buying apps in the store, it also applies to in-app purchases including subscriptions that may remove all the profit. That’s why for instance you can already download HTML5 Financial Times :)

So many counterpoints but should there finally be an either/or decision? The truth is somewhere in between. And we believe for the majority there may be a place for both kinds of apps. Just an example – you can create a browser-based “lite” version of your app so that prospective buyers can try it out without having to visit an app store; and further if they like the game, they might decide to buy the full version as a native app.
Moreover, developers build many native apps in much the same way that they build browser apps, using the same tools, but then fit them with a native app “wrapper.” For this reason, native apps and browser apps sometimes aren’t as different as people may imagine.

And what do you think?
In your particular case what have you decided or are going to opt for?

Thanks for sharing your opinion,
Helen Boyarchuk
Altabel Group – professional software development

%d bloggers like this: