Archive for the ‘html5’ Category
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 
Kind regards,
Aliona Kavalevich – Business Development Manager (LI page)
Aliona.Kavalevich@altabel.com
Altabel Group – Professional Software Development
Which language to choose?
Posted on: June 8, 2012
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
Business Development Manager
Altabel Group – Professional Software Development
- In: html5 | Mobile
- 9 Comments
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
- In: html5 | Mobile
- 2 Comments
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
