8 Reasons Why Your Web Apps Need to Use AngularJS

 

 

Developers love AngularJS. They just really really love it. Don’t believe us? Look at the GitHub activity. AngularJS probably has the highest number of contributions than any other competing JavaScript framework. Check out Google searches or even StackOverflow mentions – AngularJS is all over.

Job trends on Indeed.com, a developer jobs site, also show a strong bias towards AngularJS than any other framework.
angular job trends graph
So what are the reasons behind this popularity? Why is this the self-proclaimed “superheroic JavaScript framework” gaining so much attention and traction? Why is the popularity of AnugularJS exploding? I have also heard that hundreds of tickets for ng-conf, one of the first AngularJS conferences, were sold out in just a few minutes!

Let’s take a look at what makes AngularJS so popular –

1. The Google Power :-
The very fact that AngularJS is built and maintained by a dedicated and talented team of Google Engineers, assures that you are working with reliable and efficient code which can offer you the required scalability for your project. Along with the solid foundation, the Google team brings in the required knowledge and support. So along with the vast open community, you have the Google engineers available to answer your questions and help you use AngularJS optimally.

2. Faster Page Loading :-
AngularJS is massively popular amongst single page sites or web applications. One of the popular reasons behind this could be the faster page loading. By saving the templates (which is essentially the HTML content) in the cache, AngularJS cuts the server reload time and removes the need to hit the server each time to retrieve the template. This makes the page loading faster.

Developers can architect the front-end application in such a way that the coupling on the back-end is minimized, which further improves the page loading performance.

3. Rapid Development :-
AngularJS on front-end along with Node.js in the backend can help the developers in rapid development by automating the repetitive tasks. This frees up the developers time for the actual development and building of business logic. With the use of data binding and Dependency Injection of AngularJS, developers can eliminate much of the code that has to be written. The two-way data binding reduces the amount of code which has to be written to maintain cohesive agreement between the model and view.

Some of the tools which help in faster development are –

  • ng-annotate – This helps in maintaining Angular dependency injection while minifying the JS files.
  • JSLint – Helps in validating the JS Code.
  • Sass/Less compiler – Helps in CSS compilation.
  •  Bower – It is a very good Package Manager for AngularJS third party components (For example: Nuget and NPM, a NodeJS package manager)

4. Flexibility in Development :-
Most of the other frameworks require you to first split your app into MVC components and then bind those components using the code. This increases the amount of coding. In case of AnugularJS, all you need to do is just split your app into MVC components – the rest is taken care by AnugularJS itself. It manages the components on its own and acts as the pipeline to connect them. Since the connection is handled by AngularJS, developers cannot write incorrect code that breaks abstractions just to make the components fit easier.

5. Collaboration :-
For projects where there are multiple developers working on the project, there are often issues about managing dependencies. AngularJS makes it relatively easy to manage the dependencies. It allows you to break down various actions into their own services and sub-controllers. Developers can independently code and test without messing with each other’s code. This is a bliss in the case of larger projects. It automatically introduces a nice workflow and processes which allow frictionless collaboration.

6. Mobility:-
AngularJS is extremely useful in building hybrid mobile applications. Before AngularJS, developers needed to use JQuery mobile framework for building hybrid mobile applications. However, JQuery mobile framework makes the code complex and it is also not very efficient for multi-page applications. AngularJS makes the code less complex and helps in creating highly efficient mobile apps. Some of the advantages of using AngularJS in mobile development are –

  • Reduced DOM manipulation
  • In-built routes provider
  • Seamless gesture handling
  • In-built transition animations
  • Performance improvement through the use of saving of templates in cache
  • Access to local storage

7. Testability:-
AngularJS is known as unit testing ready. It has been written keeping testability in mind. AngularJS links the whole application together using Dependency Injection or DI. The DI manages the controllers and scopes of the application.

Since all the information to the controllers is passed through DI, the unit tests can be performed by injecting mock data into the controller and measuring the output and behavior.

AngularJS also offers a mock HTTP provider for injecting fake server responses into controllers for unit testing. This is anytime faster than the traditional way of web application testing where individual test pages had to be created to invoke one component and check the interactions with it.

8. Less Coding:-
AngularJS requires considerably less coding as compared to other frameworks. Because of less coding, it becomes easier for the developers to keep a systematic track of the functions.

Here are some of the cases where AngularJS requires less code –

  • Views are defined using HTML to make them more concise.
  • Developers do not need to write their own pipeline – it is offered readymade through Dependency Injection.
  • With no need of getter/setter functions, the Data model is simple.
  • Developers don’t need to provide data manually to the view – it is facilitated by the data-binding feature.
  • Directives are written separately from the application code – this allows parallel development without any worries of integration issues.
  • Without changing the controllers, data on the view level can be manipulated using filters.

AngularJS encourages object oriented design thinking on the client-side which makes the application more maintainable. And the icing on the cake is that one can be proficient in AnugularJS in a reasonably less time!

The Mobile Choices You Have To Make

By Rajiv Jain (CEO, ThinkSys)

“The future of mobile is the future of online. It is how people access online content now.” – David Murphy, Founder and Editor of Mobile Marketing Daily

Earlier this year a major shift in the balance of power took place – almost unnoticed. Statista reports that now 52.7 of all internet access is now from the mobile. They further say that by 2017 over 63% of all mobile users worldwide would be accessing the internet from their mobiles. It seems clear that for those businesses that are web based the battleground is shifting from the large screen to the small screen, from the desktop to the phone or the tablet. Many have foreseen this and put in place robust mobile strategies and the rest are probably thinking it’s time to do so. In either case, though, there are some difficult choices to be made along the way. Let me take this chance to try to bring some order to the big decisions you will have to take initially.

Q1. Mobile App or Mobile enabled site?

Do you need to build an app and get it added to the App store of your choice or is it enough to have a site that renders well on the mobile? In Google’s dispensation of the day, a mobile friendly site is anyway mandatory to avoid site ranking penalties. That apart if your site is more likely to be used for information dissemination than for active transactions or actions then a mobile friendly website is likely the way to go. Among the other considerations is how frequently is an individual user likely to have to access the site – if the frequency is generally likely to be high, say public transport route and schedule info of social networking, then an app that is downloaded and installed on the phone may work better.

Q2. If you choose a site then what next?

What’s the design approach to pick? There are 3 that are the most common now Responsive, Adaptive and Blended Web Design. Without getting too much into gory details here are the broad differences:

  1. Responsive is a client-side approach. That’s to say the technology “resides” on the device on which the site is consumed so the experience is very seamless as far as the size and resolution capabilities of the device go. The downside is that traditionally this is tougher, more effort & skill intensive and takes longer to pull off well.
  2. The Adaptive approach, on the other hand, focuses the technology on the server side and adapts to whatever device the “connection” comes from by serving them the version of the content most appropriate to them. While this is usually easier to get off the ground the ongoing coordination and maintenance are a far greater coordination and execution challenge.
  3. A convenient, recent, middle ground has been arrived at with the Blended approach. This has been called Responsive with Service Side components – so the site being served may be the same, but there may be elements like the headers that may be specific to the device. The approach is still settling in but seems promising.

Q3. If App then Native Or Mobile web?

Essentially the thinking was that at one time if you wanted to reach out to as large a cross section of users as possible across devices, operating systems and so on you had to follow the Mobile Web approach utilising the powers of languages like HTML5.

The native approach tied itself much more closely to the operating system (& hence the device family) – if you wanted to target customers who were likely to be iPhone and iPad fans and wanted to use the capabilities of those devices much more fully then you picked iOS as your operating system of choice. The app would be built in accordance with the App Store specs and that was your little (or big) universe. If you thought your customer base was in the wider Samsung, LG, Motorola universe then you picked Android as your platform and that then decided all further choices.

Hybrid platforms like PhoneGap have been around for a while and these seem to be gaining ground. This an argument where the contours are changing even as we speak – maybe in a few months we will talk only about a Hybrid approach driven by people like ReactJS.

The prediction is that by 2018 half of the world’s mobile users will have smartphones. If your business has to be ready for that day you have some choices to make now. You will likely have to start with the answers to these questions.

Key Considerations In Localization Testing

The spectacular growth of the software industry and globalization has made it easy for software vendors to target the non-English speaking geographies, reach out to a wider audience, and spread their footprint. With wider coverage, software product companies are increasing their chances of capturing a larger market share. Such fantastic plans also come with their own set of challenges. Launching the product in multiple geographies means that the product needs to work flawlessly in various regions from the day of the launch.
Localization testing is the process which enables testing of the software product for adoption and use by the users using different languages and from different regions. It also means testing and ensuring that the product is suitable for use in the particular language as per the local culture and look-and-feel.

Key consideration in Localization testing

Only great translation does not make the product local-ready. In addition to perfect translation, it requires attention to the locale details such as date and time formats, numerical, currency, keyboard usage, symbols, icons, suitable graphics, and other such legal requirements. The primary focus of localization testing is on testing of the features, ensuring accurate rendering of the content, making sure that the user interface is fine, cultural awareness, and country-specific changes such as currency, taxation etc. and data storage. Localization testing is always tricky because while the translators have a great mastery over language, they are not necessarily product experts or testing experts. At the same time, the testers are not language experts.

In this post, let us have a look at some of the key considerations in localization testing.

  1. Testing Scope:

    It is important that the complete scope of testing is rightly identified – this includes the main focus, target languages, required platforms, and more importantly, what is not to be tested. The test case development and testing execution depends on the testing scope and, therefore, it is important to have finality on this.

  2. Test Case Development:

    Test case development needs to be done based on the features to be tested as a part of location testing. The test cases should typically include testing of installation/ uninstallation (for desktop-based applications), user interface testing (checking for missing icons, broken text, missing text etc.), and documentation consistency (including online help, manuals, multimedia etc.). The test cases should also include checking of issues which could arise in the product functionality because of localization. For example: the currency symbol placement is different for different currencies, the date and time formats are different, the use of fonts vary as per the language, the use of colors and images change as per the regions, or the keyword usage patterns change as per the regions. The localization testing needs to test for all such aspects so that the users get a feel that the software has been created for them to address their specific needs.

  3. Test Case Management and Defect Reporting:

    To ensure that each team testing for different languages does not reinvent the wheel, it is important the test cases and testing data are managed through a centralized platform.
    While reporting the defects, the testing team should categorize the bugs as localization bugs or global bugs. Localization bugs are the errors which occur during or because of localization process whereas; the global bugs are reproducible on multiple languages and need to be resolved in the core code.

  4. Role of Automation:

    Test automation can be tricky for localization testing and, therefore, it is not always feasible to consider it. However, for legacy software where there is a lot of legacy feature testing required for each release, automation works well from the perspective of cost and time saving. Keyword driven framework, also called as a table-driven framework, is one of the popular methods for automating localization testing. While these frameworks take longer to build, they are automation tool and programming language independent, easy to read and maintain, and scalable.

  5. Mobile App Localization Testing:

    The localization testing of mobile apps is more complex than that of standard web applications. Web applications typically work through standard browsers and use keyboard or mouse as input methods. Whereas; for mobile apps, there are multiple operating systems, screen sizes and different input methods like keyboard and touch. Because of the limited screen size, the mobile apps need to make use of the best font in different languages so that the text does not get truncated or misaligned. Most of the languages require around 30% more space than English, and, therefore, user interface testing is very critical. The rules for spelling, upper and lower case conversions are also different based on locale and culture and the app needs to provide a support for those.
    Because of the vast number of mobile players in the market, the test bed creation itself is a huge task. For example: In Switzerland, primarily French, German and Italian languages are spoken. The three most widely used mobile operating systems are Android, iOS, and blackberry. Swisscom, Sunrise, and Orange are three main service providers. Considering all these parameters, the localization testing needs to be done for 27 combinations for this one country alone!

Conclusion

As we see, while translation is one of the important aspects of localization, localization testing goes much beyond that. It requires a well-thought out strategy and timely and flawless execution to ensure speedy time-to-market at reduced costs and no defects.

Test Automation May Not Be Right For You

The wonderful book, “Implementing Automated Software Testing” authored by Elfriede Dustin, Thom Garrett, and Bernie Gauf, mentions a worldwide survey they conducted on the subject. The online survey got over 700 responses and among a host of interesting results they included in their book was a startling finding. They reported that 72% of the survey respondents believed that automation was useful and even that their management agreed but despite that they either had not implemented it at all or had had only limited success.

The book came out in 2009 and how things seem to have changed since then. Anecdotal evidence, at the very least, would seem to show that most software development efforts today consider automation initiatives somewhere along the way. Much has been written about why one should choose to automate testing – there are great technical as well as commercial arguments. That being said, though, as a testing and test automation company every so often we come across a situation when we recommend to the client that test automation may not be the best bet for them or for that specific development effort. Let’s look at what these situations are where test automation may not be the best fit?

  1. Very less or almost no regression testing: Don’t be surprised – there are a lot of situations where future iterations add on to what has gone before without really touching the old code base in any significant way. For example, remember the waterfall model – it’s still very pertinent in many situations. There are many small, self-contained software projects or projects where the requirements are extremely clearly defined where this model plays well. Here since the development for each phase is completed and then accepted after testing, conventional wisdom is that the regression effort is reduced. In such situations, there is not much value in automating the testing since you are unlikely to gain any significant advantage of time once you factor in the effort of developing the test suite.
  2. Tests that will be run only once: In some ways, this is an extension of the earlier thought. Like everything else, there are choices to be made while automating your testing. If there are tests that are likely to be run on only 1 iteration or very few times in the overall effort then save your time, energy and money – don’t automate them. Instead, prioritize those test cases that are likely to come up time and again in the development cycle.
  3. GUI is not yet frozen or there are frequently functional changes: In many ways, this is the opposite of the first condition. Here the requirements are very dynamic. The fact is that building the test automation suite is an effort and once the suite is built making tweaks to it to allow for changes that have crept into the project scope is neither easy nor advisable. Our advice is always to get the test automation team involved at an early enough stage in the project to be able to design, plan for and build an effective test automation suite – if such planning is not possible then chances are high that the test automation suite will be incomplete or ineffective. In that case, why do it at all?
  4. No skilled resources: We know, this is obvious. That being said you would be surprised how many test teams struggle to provision the right kind of people on test automation teams. Chances are for a test automation effort to be successful, developers will have to join the team – in the end, your automation suite is also a product and hence developing it is like any other product development effort. And it’s not just developing it either, consider that this “product” will need support and maintenance over its lifecycle. If you cannot find the resources with the right skills for this then you may be better off not automating.
  5. Seeking 100% Automation: There has been enough said about this. If you are seeking to automate your testing in quest of the mythical “100% Automated” one-horned beast, then just don’t. It’s not possible, not desirable and just plain wrong to start with inflated expectations. Set out on the automation path with tempered expectations or not at all.

In closing let us just say there is a time and a place for automated testing – just not every time and place. Brad Siims, co-founder of SandVine, explains the value of automated testing elegantly, “With manual testing you can’t reproduce problems as readily and the breadth of test-case coverage isn’t as high. With more automation, you can focus your QA team on making a difference, versus manual re-cabling to run nightly tests.” Do you agree?

The Economic Argument For Test Automation

“If you automate a mess, you get an automated mess.” (Rod Michael)

Virtually all software development projects today contain an element of test automation. If an initiative is not already underway chances are there is one under consideration. The software engineering groups are generally convinced of the benefits – greater test coverage achieved faster being the most apparent. That being said as the business owner how does the economic argument in favour of test automation stack up?
The Economic Argument For Test Automation
Before that- is there any value, though, in getting into ROI discussions? The point being that in all software development, testing is a given. Despite that has there ever been any meaningful attempt to try & define the ROI of the testing effort? The fact is that the risk of sending an untested product into the market is just too great for the business to bear so an ROI argument is generally not necessary. So let us start with the base assumption that a certain cost for testing is inevitable – this would likely be the cost allocation made towards the efforts the testers put in to achieve the desired quality standards before the product or software release.

Let us consider the various cost elements of a test automation initiative.

  • You will likely have to spend for the software that you use to build your test automation suite or framework. Since we are talking about the lifetime cost of ownership, even assuming you choose to go open-source there will likely be a cost associated with ongoing support, maintenance, and possible customization.
  • Then there will be an allocation towards the effort it takes to use these tools and build your test automation suite. The skills needed to build test automation are generally different and in many cases more expensive, than those needed for doing manual testing so there is that to consider as well.
  •  Remember that the automation suite is also a product that will need ongoing maintenance and support – the cost for that effort should also be factored into the total cost of ownership.
  • Some effort will also be expended in running the test automation suite and that has a cost too.

The cost of the automation effort is a combination of all of these and the cost to be considered in any, even notional, ROI discussions would be that, less the cost allocation that would have been made towards a traditional manual testing effort. Are you with us so far?

Having dealt with the, I in ROI let’s move towards the R. We spoke of the principal benefits from automating your software testing – more coverage and faster testing. What are the possible economic benefits that can accrue from these, though?

First, let’s look at the greater coverage. The conventional wisdom is that greater code coverage will uncover more defects and potentially earlier in the development cycle.

  • The earlier in the cycle defects are detected, theoretically, the easier they are to fix. There are less things to check for in previous versions, regressions are simpler and so on. There are models out there that show how much more it costs to correct defects later in development cycles – that is a good place to start if you want to find how much money you are saving.
  • Can you put a cost to a better quality product reaching the customer? Perhaps not but there are possible ways to allocate notional costs to when the reverse happens. Customer-found defects cost money in replacements, recalls and under-warrantee fixes not to mention the loss of reputation and potential loss of costumers and market share. Greater coverage that catches such defects before such an eventuality occurs is a well-made argument.

What is the value of testing faster? It seems reasonable to assume that faster testing will shorten development cycle time and, therefore, allow for faster releases, more product iterations within a shorter time and so on. How does that look on the balance sheet?

  • A faster release translates into a faster market entry. Addressing the available market opportunity on or before schedule has undeniable business benefit – first-mover advantage, early market validation or feedback and an opportunity to occupy unoccupied market positions can all be achieved and models exist to allocate, in one way or the other, monetary values to these benefits.
  • Automation would allow software development teams to spend less time on testing – effort saved is money earned of-course. Then there is the opportunity cost – potentially the time saved on testing could be spent profitably doing something else of value.

One way to look at this argument is that it is too complex to look at purely from a “cash in, cash out” kind of viewpoint so you should consider only the engineering value. The variables are many but isn’t that in many ways true of software testing in general. Remember the words of James Bach,

“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.”

Can we Automate UI Testing?

Most testers consider UI testing as the Achilles’ hell of automated testing and often just stick to manual testing for UI. There is no doubt that UI testing does have its challenges. It has complex workflows, is relatively much slower than Unit Tests and also is more brittle. This is mainly because UI testing has too many touch points and, depending on what is being tested, hit the file system, the database and sometimes the network services. They have to cross process and class boundaries and involve constantly changing UI elements such as JavaScript, HTML etc. Even if any one of these sections does not play along perfectly with the testing process you have a ‘broken test’ in your hand. So yes, UI testing is challenging. Having said that, we also want to emphasize that no other test will give you as much coverage as a UI Test.


Owing to this, most testers believe that automating UI testing will be more time consuming, brittle and expensive. So, is manual testing the only way ahead with UI Testing? Not necessarily but to make sure that your automated UI Testing efforts do not go in vain, it is essential to lay the right groundwork. In this blog, we talk about the best approach you can take to automate UI testing.

  1. Setting the right expectations:
    To get your UI Test Automation plan rolling start by setting the right expectation, both with your team and your leadership. Since UI is a software development task, obviously it has a time impact. The leadership needs to be aware of the fact that some of the schedules and the delivery might be impacted while you evaluate tools to use, implement the tooling set up, get the team up to speed with the new tooling and then adjust your development process. While the initial set up does take a little additional time, there are some clear wins as well. You avoid wasting time on repetitive manual tests and also have clear and updates information on the system’s risk to the business value apart from having stronger faith in the automation safety net.
    It is also essential to get the testing team involved in the initial testing set up process and ensure that the developers and testers work together to determine how the automation process has to be set up for work sets, decide where to place static or pattern based ID values, create backing API’s for setting up as well as tearing down test data etc.
  2. Automate key business scenarios:
    While 100% of the UI test cannot be, and indeed should not be, automated, certain parts of the test definitely can leverage automation. Most UI Test Automation cases fail not because of lack of execution knowledge but the lack of knowledge on ‘what’ to test. Since the UI Tests build several layers around the business domain code, breaking down these layers to automate them can be a Herculean task in itself. To test business rules through user interface normally require a host of smaller tests to be conducted with small workflow differences. However, test maintenance for such scenarios is harder especially when business rules change. Thus, it makes sense to not test the whole application through the UI. Having said this, automating key business scenarios and testing them end-to-end on almost a daily basis will ensure that the basic workflows are getting completed correctly without additional effort.
  3. Tools Selection:
    Along with everything else, selecting the right tools for automation also plays a crucial role in UI Test Automation success. Though an ill-fitting tools set might not essentially mean failure, it does involve spending copious amounts of time on setting up the automation suite, learning, writing and running the tests, fixing the broken tests and then again adapting the test to system changes. By getting the toolset right, you can actually focus on testing the system, provide better information to stakeholders and give your testing team more time to actually ‘test’ what they are supposed to and not waste your time in the mechanics of testing set up. There are some really great open source testing tools, such as Selenium that can help make your UI Test Automation effort a success.

Conclusion

The ability to find regression errors is one of the biggest advantages of automating UI testing. Since automated UI tests are supposed to ensure that the newly written code does not break or change the existing functionality, it works phenomenally well to spot regression errors and can easily become one of the best elements of your regression suite.
There’s still a lot of ground to be covered when it comes to UI Test Automation. Keep watching this space for more on what can be done.

Business Considerations Behind Your Web Technology.

“Information technology and business are becoming inextricably interwoven. I don’t think anybody can talk meaningfully about one without talking about the other” – Bill Gates

Gates’ statement has never been truer than it is today. So much of business strategy today is dictated by what is possible to do with the technology of the day. Business owners are being forced to make technology choices every day and there is a genuine fear that the wrong choice could negatively impact their web application, portal or site deeply enough to cause active business disruption. This then suggests that the choice of the technology platform for your web application or website is no longer a purely technology decision. What, then, are the business considerations that should go into the technology decisions related to your web application?
Business Considerations Behind Your Web Technology.
This is in some ways the old “make or buy” decision. Does your business strategy require a site / app that can go live quickly with a reasonably standard set of features – in which case a ready template could be the answer? On the other hand, if you need a unique look and feel and features that are not commonplace then you may have no choice but to consider a completely custom development. What you lose in development time you gain in flexibility in this particular game of choice.

Need for Features:
Your business may demand that the app / site be capable of performing some very specific activities or at some very specific capability level. Is real-time updating required? Is the effort likely to be calculation intensive? Is performance important? Or is it important to achieve scale? How fast does your business need that scale to be achieved? Answers to these questions will help you pick from the technology platforms out there – if the platform addresses your business need squarely then that’s the right choice.

Time-to-market:
How fast do you need to get your offering in front of your customers? Is the timeline set in stone, as it were, or is there scope for some flex? Different technology platforms behave differently. If what you value are easy and fast development and a predictable effort then maybe a more established technology platform that has been well documented may be what you need. Driven by the business needs you may be tempted to consider a relatively newer technology that promises much but may carry with it the risk of unforeseen pitfalls if your timelines are more flexible.

The economic argument:
Cost is a primary factor in the choice of technology. It is important to take into account the total cost of ownership of the technology platform under consideration – not only the initial outlay but also appropriate allocations for the cost of maintenance and support and if need be a charge for the effort involved at your end over the development lifecycle. An Open Source platform may involve lower upfront investment but could cost more in the long run once you factor in ongoing maintenance and the cost of support from a loosely formed community. Proprietary technologies will likely cost more to start with but may end up being less expensive to maintain and with, perhaps, more dependable support.

Market Support to the technology:
The technology landscape is littered with stories of technologies that died a sudden death after an initial meteoric rise. Sometimes the hype cycle becomes so dominant that organizations make technology choices because they feel they have to rather than because they need to. As Stewart Brand said so eloquently, “Once a new technology rolls over you if you’re not part of the steamroller, you’re part of the road.” The problem with such choices is that you could be stuck with a technology platform that vanishes midway through your development effort. The support for the technology in the marketplace, their reviews, and their heartfelt acceptance matters a lot when you look around to make your choice because it makes the longevity of the technology more likely and this has to be a key consideration in any technology choice you make.

Carrie Snow said, “Technology… is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other.” You would do well to remember that in the end the technology is just a tool – it’s up to you to make it work for you.

9 Enterprise App Ideas For Your Business

Gartner predicts that by the end of the year 2017, market demand for mobile app development services will grow at least five times faster than internal IT organizations’ capacity to deliver them. With the increase in the demand and sale of mobile phones, the demand for enterprise apps which match the high performance and usability of consumer apps is only going to increase.

9 Enterprise App Ideas For Your Business

Gone are the days when the office workstation was the only device which the knowledge workers used to use. Today, on an average, a knowledge worker uses at least three different devices and with the proliferation of the Internet of Things (IoT), very soon it is going to increase to five or six devices. The number of devices managed in the enterprise increased 72% from 2014 to 2015 (Source).

Organizations are realizing the importance of offering the employees the option to select the device and apps of their choice to complete a particular task. This obviously is putting a high pressure on IT to develop a larger variety of mobile apps.
When a majority of the organizations are still evaluating the tools, vendors, technology, and vendors for the development of enterprise apps, here we provide some of the app ideas which businesses can use while developing their enterprise apps –
1. Product Training and Knowledge Apps: Sales representatives need to be always on top of the latest products and services. To achieve this objective, enterprises can build an app which can simulate a “pre-call” planning with a customer. Through right answers, the reps can get badges or more up in the level. This can be a very engaging way of updating the sales reps about the latest offerings.
Every company has a ton of documents and presentations about the product and services information, best practices, whitepapers, case studies and so on. But not all the employees are always aware of those or make use of those. Having a ready access to the resource library which can be easily searched can be of tremendous value for everyone in the company.
2. Real-time Inventory App: For Sales reps who often visit the off-site clients, a real-time inventory information is of great benefit. It can save a considerable amount of administrative effort and can also help the sales reps in making a great impression in front of the customer by offering the real-time demand details.
3. Quoting Apps: Sales Reps who are on the move need an easy way to generate accurate quotes instantly. Apps which help them to select the products and price and configure the quote can greatly help in the faster closing of the deals. There are quite a few readymade apps for this purpose which can be used by the enterprises.
4. Support Apps: When any customer submits a support ticket or makes any request for assistance, an internal support app can alert the appropriate department or team to take quick action on the ticket to quickly resolve the issue and attain greater customer satisfaction.
5. Marketing Apps:Marketing teams usually run many campaigns, but the results are not always visible to the rest of the business stakeholders. An app which provides a complete overview of various campaigns in a visual way can help all the stakeholders in getting a better understanding of the marketing initiatives.
6. Authorization and Approval Apps: Long approval cycles can delay the sales cycles if the approvals need to be given by a particular person from a particular machine. Secured apps which can allow employees to provide approvals from anywhere, anytime can tremendously save a lot of time.
7. Broadcast Apps: Keeping all the employees updated about what is happening in the company can be a difficult task if it is done only through emails or newsletters. Having an app to display the announcements and news can be an effective way to keep everyone informed and also engaged.
8. Collaboration Apps: Collaboration apps help in keeping the employees connected, help them in collaborating across borders, and maintain a people-oriented culture in the company. Such apps help in providing a better visibility of activities across departments and also foster the spirit of innovation in the teams. A collaboration mobile app helps the on-the-field teams to be connected with the business on a regular basis.
9. HR Apps: Every employee regularly interacts with the Human Resources department for requests like leaves, health claims or policies. A mobile app which can allow the HR teams in providing this information quickly and easily and also allow the employees to access it from anywhere can save a lot of time for both and also improve the employee satisfaction.
While these ideas are a good place to get thinking, organizations need to remember that the apps which are designed and developed considering the needs of the business and the existing workflows tend to work well in terms of adoption as well as the use.

Myths About Usability Testing

It is somewhat strange that while usability testing has been around for over two decades, it is still shrouded by a number of myths and misconceptions. Over the years usability testing, a very important part of software development, has become much simpler, faster and cheaper – there’s really no good reason to NOT do usability testing. In this blog, we try to bust a few myths about usability testing to convert the non-believers into believers.

Usability testing Myths
Myth #1 – Usability testing has to be done by experts:-
While ‘anyone’ can actually do usability testing, not everyone will do it ‘well’. Usability testing requires a fair amount of work, testing expertise and analytical capabilities to observe and understand the demands of the product. That being said you might not need a testing ‘expert’ or someone who is a Human Computer Interaction Designer, anyone with some knowledge of the basics of web and testing can manage usability testing quite well provided the plans are clearly laid out and test strategy clearly defined.

Myth #2 – Usability testing process is time-consuming and very expensive:-
While this was true even a decade ago, with the dawn of the age of high-speed internet and hi definition web cameras and great quality screen recorders, usability study can be conducted at a minuscule expense and also can be done remotely. You do not need an expensively equipped lab and a large number of participants to conduct your usability testing. For many projects, you can easily use remote and unmoderated tests and later collect and analyse the remote usability sessions that in a cost effective and efficient manner negating this myth.
Myth #3 – Usability testing is the same as focus groups
No, it is not! Just because both collect feedback does not mean they are the same as their goals are completely different. While focus groups assess what users ‘say’, usability testing observes how people ‘use’ a product by first assigning tasks to the users and then assessing their performance and user experience.
Myth #4 – Usability Testing can only be done when the design/development is complete
Again, not true! It is essential to gather user feedback and integrate it the development system right from the word ‘go’ so that the design can be changed according to feedback. While some might not want to implement usability testing at all stages of development, it makes sense to get users to test basic items like the menu, wireframes or prototypes in the initial stages of development and then have them test the complete and developed products in the end.
Myth #5 – Usability Testing and User Acceptance testing are the same things
In Usability Testing people who are representative of the users participate in the testing process. Their testing focuses solely on the user experience and has no bearing what-so-ever on whether the user interface meets the business requirement making is absolutely different from User Acceptance Testing.
Myth #6 – Analytic’s trumps Usability testing
Yes, analytics are definitely important since they point out what went wrong with volumes of data and numbers. However, analytics won’t be able to answer the question of ‘why’ something went wrong in the first place – Usability testing reports will. Once you know exactly what the problem is fixing it becomes much easier when compared to sifting through vast volumes of analytical data and drawing, sometimes perhaps one too many, incorrect conclusions.
Myth #7 – You don’t need to test what you redesign
When redesigning a user interface it becomes all the more essential to check the strengths and weaknesses of the current version. Since future designs will be built on this current redesigned version, Usability Testing becomes all the more important.

While Usability Testing is one of the many testing methods to identifying specific problems with an existing design, it is a very important part of the testing process since it provides some very valuable insights in terms of context and product requirements. In today’s environment of agile development, usability testing becomes even more important so that problems can be identified and fixed in time and the time –to-market becomes shorter.

Building A Solid Test Automation Strategy

“Without strategy execution is aimless. Without execution, strategy is useless.” Morris Chang CEO of Taiwan Semiconductor Manufacturing Co.

In this agile age, more organizations than ever before are looking at making Test Automation a core part of their product development efforts. That being said, anecdotal evidence would suggest that a surprisingly large number of these test automation efforts don’t deliver the desired results. As a company focused on testing and test automation we have encountered our fair share of client relationships that start on this kind of a note. Clearly there is no lack of great tools and technologies out there and it’s also fair to say that the test automation skills are scarce but available – what then is behind the lower than desired success rate? Over time, we have come to believe that chief among the many reasons test automation “experiments” fail is a poorly defined automation strategy. This post is our attempt to outline, what we believe to be, six critical considerations while devising a solid test automation strategy.
1. Business Buy-in: In many ways this is the most critical piece. Test Automation has to be core and not just a vanity project. The automation strategy has to be aligned with the business objectives and should have the active buy-in of the business to ultimately be successful. This is even more critical in the context of the Agile and Continuous Delivery models of product development. Given the shorter time windows between releases, it becomes essential for the automation strategy to plug into the business and product strategy at a very early stage in order to be effective over the entire product development life cycle.

test strategy

 

2. Defined Outcomes: It’s been said in the context of planning to “start with the end in mind”. The call is to make sure that the end objectives are kept in view at every stage of the journey. In the context of a test automation strategy, the need is to have clearly defined objectives that the test automation effort should achieve when done. These goals need to be very specific – “test faster” is not a goal. “Achieve 25% greater test coverage” and “20% faster time to market” are examples of specific goals to aim for.

test automation

3. Tool Selection: There is a variety of tools, technologies and platforms out there. Making the right choice is an absolutely key part of the test automation strategy. The tool you pick has to suit your business needs and be appropriate for the achievement of your “defined objectives”. There is also the question of skills – if a synergy can be built with the technology skills already available in the organization then it may be a good idea to pick a test automation tool that allows such synergy.

tool selection criteria

4. Assigned Stakeholders: Our suggestion is that the test automation effort should not be an “add-on” responsibility of the manual testing team. It is important that this effort be helmed by a defined set of stakeholders with the means and the authority to take decisions and in turn tasked with its ultimate success or failure.

5. Expectation Setting: Walmart founder Sam Walton said, “High expectations are the key to everything.” While that may be true in most fields of human endeavor, in the context of test automation we suggest tempering the expectations to prevent setting unrealistic goals. It’s unlikely you will ever be able to achieve 100% automation and anyway some conditions will always be tested better manually. That being the case we suggest carefully picking the test cases that you would like to automate so the effort can deliver the maximum bang for the automation buck.

high expectations

6. Evolution: The test automation roadmap is a clearly defined path of growth. It is important to remember that the product will keep evolving and hence room should be made in the test automation strategy for similar evolution. Agile implies faster releases and more iterations of the product under test – the test automation roadmap should be able to deliver RoI at each such stage to be truly successful.

Winston Churchill is reported to have said, “However beautiful the strategy, you should occasionally look at the results.” Our view is that for the right results the strategy has to not only be beautiful but also well thought out!

What Should an Ideal Test Automation Team Look Like?

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” (Mosher’s Law of Software Engineering)
As long as there is software programming there will be software testing.

In today’s Agile and Continuous Integration world I guess we could add automated software testing to the list of perennial must haves. While this is generally acknowledged it is sometimes not as widely appreciated that the test automation suite is also a product in itself. This “test automation” product demands a different approach all the way through and not treating it as such could invite the risk of failure. Among the early indicators that the effort may be “at risk” is the composition of the test automation team. Here’s what we think an ideal test automation team should look like – taking the product approach into consideration.

product approach for an Ideal Test Automation Team

  1. Get the business involved: A key input into the early planning and design of the test automation suite (or test automation framework) should be the business need. What is the product under test trying to achieve, how it is slated to evolve, the features and the use cases are all critical pieces of the puzzle that will reveal the shape and size of the automation framework when put together. This is especially important in the context of Agile since the sprints are so short. Thus one key member of the crack test automation team should be a representative of the product or the business.
  2. Designing it: There is the software architect who will design the core of the automation framework – as we have mentioned the need is to look at this as a product in itself and design the architecture keeping scalability, agility and maintainability in mind. Given what the framework has to achieve a key member of the team will be the test architect – what tests to automate and at what stage they should come into play is all within the wheelhouse of the test architect.
  3. Technology talent: There is a significant technology element to the automation suite and this means the team should ideally have an expert on the platform / technology of choice. Your choice may be Selenium or it may be QTP or something else. In each case understanding what can be achieved with the technology is essential and perhaps even more essential is knowing the limits of the technology of choice and building a “Plan B”.
  4. Build it: Developing the test automation suite is a job for, well, developers. That being the case it is essential to staff your team with developers capable of translating the vision of the architect into a working suite using the technology available.
  5. Maintaining it: Like we’ve mentioned a few times – the automation suite is a product. That implies it needs to be supported and maintained over its useful life cycle. The need, therefore, is to make adequate provision for bandwidth of resources for these tasks even after the initial suite has been created and deployed.
  6. Putting it to work: What good an automation suite that doesn’t get fully utilised right? Last but definitely not the least among the members of your test automation SWAT team are the testers who will actually put the suite through its paces in the real world. The aim is to test more, test faster and go-to-market faster – it’s the testers who will achieve that.

Conclusion:

It’s important to know that each member of the team has a key role to play but in the end none of them can do the task alone. Like legendary basketball coach Phil Jackson said, “The strength of the team is each individual member. The strength of each member is the team.” He may have been talking about the idea test automation team actually.

Krypton, an Innovative Open Source Test Automation Tool

ThinkSys recently launched its innovative open source test automation tool Krypton at the STARWEST Techwell event in California. STARWEST Techwell is the premier event for software testers and quality assurance professionals.
Built on top of Selenium, Krypton is a free automation solution for testing websites, web-based applications, mobile websites and mobile native apps.


ThinkSys has built the Krypton Framework based on its experience of helping several Enterprises and ISVs across the world in building quality software while reducing the cost of quality.
On the occasion of the launch of this Framework, we got in touch with Rajiv Jain, the CEO of ThinkSys and the innovator of Krypton. Here is an excerpt of the conversation –

Question #1: What is the idea behind Krypton?

[Rajiv Jain]:

For the past several years, we have been providing testing and quality assurance services to our worldwide customers. Krypton was actually born out of necessity. For one of our large customers we had to automate more than 8000 test cases in a very short time. Although the customer had access to QTP licenses, looking at the project scope, we decided to build a framework on top of Selenium. The Framework, later rechristened as Krypton, allowed us to create the test cases within a matter of few months with a very small team of non-developers.
Later on, we improved the Framework to make it a Regression Automation Testing Framework for testing websites, web-based applications, mobile websites and mobile native apps.

Question #2: How was the response for Krypton at STARWEST?

[Rajiv Jain]:

It was brilliant – to say the least?. The companies to whom we demonstrated the framework appreciated its ease of use and the fact that non-programmers can also use it. I am personally overwhelmed with the response which we received from the testing community – there was a lot of response for contributions to the framework. That’s the beauty of Krypton being an open source framework built on the already popular Selenium.


Question #3: There are many test automation tools in the market? How is Krypton different?

[Rajiv Jain]:

Good question. Let me first clarify that Krypton is not a tool but it’s a framework that is built on top of Selenium. I agree that there are several frameworks that have been built on top of Selenium but the idea behind Krypton is that it helps manual testers become experts in Test Automation within a short span of 4-6 weeks and then have the abilities to build complex automation scripts for both Web and Mobile.

We have used Krypton ourselves for many of our existing customers at ThinkSys. With modular scripts and easy maintenance of code, it helps in quick creation of automation strategies for complex projects. Our customers especially like the way the test results are displayed in simple HTML format offering easy customization.
If I have to pick one feature which is one of the key differentiators, then I would say that Krypton solves browser idiosyncrasies and the age old issue of handling “Sleep” in automation.


Question #4: Why did you decide to launch Krypton as open source Framework and not a licensed product?

[Rajiv Jain]:

I think this is where our experience of working in this QA domain played a crucial role. We have worked with several proprietary test automation tools for our clients. We understand and know the frustrations of the QA engineers as well as the customers because of the limitations of such tools. Today, technology is rapidly evolving and nobody has the patience to wait for the new versions of the proprietary tools. Customers want a fully functional product with the source code and they want to build features on top of it as per their needs. There is definitely great value in having many people participate in creating a great product that is better for the industry.


Question #5: What skillset or experience do the QA engineers need to possess to be able to use Krypton?

[Rajiv Jain]:

Well, as less as 4 to 6 weeks – and I am saying this time for a Manual Testers and not even the Automation Testers. Anyone with logical thinking can become a good Krypton user if he/she knows simple scripting.


Question #6: What type of organizations can truly benefit from Krypton – small, mid-size or large?

[Rajiv Jain]:

Krypton is useful for all sizes of organizations. I would especially recommend Krypton to those organizations which have large teams of manual testers with good domain or product knowledge and they would like those teams to contribute in automation testing – Krypton can help them become automation experts in no time!


Question #7: Mobile testing has become very crucial in today’s time and age. Does Krypton help in that?

[Rajiv Jain]:

Oh yes! Krypton does help in Mobile Automation.


Question #8: Who all contributed to the making of Krypton?

[Rajiv Jain]:

Krypton has received valuable contributions from various teams. First of all, the ThinkSys team of QA Engineers, who saw the need for a Framework like this, based on their experience of observing the pain points and providing solutions to our customers. Secondly, our customers who agreed to be the beta users of Krypton and gave us continuous feedback. Thirdly, our partners who provided practical suggestions based on their in-depth knowledge of industry demands and the gaps in the existing solutions.


What are the future plans for Krypton?

[Rajiv Jain]:

We plan to continue to invest in the framework to make it more intuitive and also add more features to it. We are keenly looking forward to contributions from the developer community to make it richer in functionality.

ThinkSys Releases Krypton As An Open Source Automation Testing Framework

30/9/2015 September
ThinkSys, a boutique company delivering excellent, cost-effective and efficient IT solutions and testing services, has today announced the release of their successful Krypton product to the Open Source community. Krypton, built on top of Selenium, is an automation solution for testing websites, web-based applications, mobile websites and mobile native apps which is JavaScript and Spreadsheets based.

Over the past few years, ThinkSys has helped several Enterprises, ISVs, and Fortune 1000 companies build quality test automation suites while reducing the cost of quality by leveraging the Krypton framework. Now it is releasing Krypton to the Open Source community. ThinkSys is also launching a new website www.kryptonqa.com for Krypton information, downloads and to create the Krypton Open Source community.

“While we will continue to invest in Krypton Framework to add more features, we are looking forward to the developer community to take it forward in a positive direction. That was the whole idea of launching it as an Open Source Framework. Since Krypton is based on top of Selenium, I am looking forward to a great participation from the Selenium community”, said Rajiv Jain, CEO of ThinkSys.

Krypton helps companies in improving time to market as well as offers ease of maintenance. With Krypton, QA engineers can write the test cases in Spread Sheets in an ‘easy to understand’ script. The automation test cases are written as a set of commands in Test Management. During automation execution, Krypton’s “Execution Engine” reads the test cases and executes these commands.

“Having tools like this helps to level the playing field”, said Ryan Clark, CEO of ProActive Budget, a ThinkSys customer. “I applaud ThinkSys in making this available to the OpenSource community. It’s a huge win for start-ups like mine. Our time to market will be reduced while still delivering high quality apps.” he adds.

“Open source tools such as Appium and Selenium have made a huge impact on automated testing, and we’re excited to see ThinkSys make their Krypton framework available to the community”, said Lubos Parobek, vice president of product at Sauce Labs. “We are looking forward to seeing an increase in adoption and contributions to this project”.

About ThinkSys Inc
ThinkSys, a global technology products & services company, helps customers improve and grow their business and e-commerce initiatives across the Web and mobile channels. ThinkSys develops, tests and implements high-quality, cost-effective solutions running in the cloud or onpremise. As a leader in web and mobile manual and test automation, performance and monitoring solutions, using its Krypton framework or other Industry tools, ThinkSys enables developers, QA Professionals and management to help reduce time to market. ThinkSys is privately held and is headquartered in Sunnyvale, CA.

For more information, visit www.thinksys.com

For more information on Krypton, visit www.kryptonqa.com

About ProActive Budget
FinTech start-up ProActive Budget, uses new patented technology which, for the first time ever, allows a user to budget and spend with real money via a spending card and phone app. ProActive accomplishes what other budgeting and financial tracking systems have failed to achieve with their reactionary systems. Currently the system is in Beta testing pending a tentative launch towards the end of the year.

About Sauce Labs
Sauce Labs is the leading cloud-based web and mobile application automated testing platform. Its secure and reliable testing infrastructure enables users to run JavaScript unit and functional tests written with Selenium and Appium, eliminating the time and expense of maintaining a test grid. With Sauce Labs, organizations can achieve success with continuous integration and delivery, increase developer productivity and reduce infrastructure costs for software teams of all sizes.

Sauce Labs is a privately-held company funded by Toba Capital, Salesforce Ventures, Triage Ventures and the Contrarian Group.

Contact Details:
For more information about this press release please contact [email protected]

Top 7 Challenges in Mobile App Testing

According to Statista, it is projected that the Mobile app store revenues worldwide will grow to US $76.5 billion in the year 2017. A Marin Software study reveals that in the UK, mobile devices now account for 44.8% of ad impressions, 50% of clicks, 46% of spend and 43% of conversions. People’s obsessions with smartphones have enticed businesses to innovate and build interesting applications and also think of ways to improve their relationships with their customers through such apps.
Designing a user-friendly and killer mobile app is undoubtedly a difficult task but surprisingly, that’s a lesser problem for businesses today. With availability of many tools, technologies, and easy access to good talent, developing a mobile app has become relatively easy. But businesses are concerned about the testing of their mobile apps.
With millions and millions of options available on the app stores, users have become unforgiving – they uninstall the apps if they find those to be non-user-friendly, not serving the purpose, or worse, have errors.
The issues with mobile app testing –

Let’s analyze some of the key challenges of mobile app testing:

1. Usability and User Experience:

Stellar user experience is a must-have for mobile apps. The app testing needs to ensure that the apps are absolutely easy to use and the features do not confuse the users. The obvious features should be easily accessible on the screen and should provide the highest value for the users’ time. The user experience needs to be similar across all smartphones and platforms. App QA engineers need to ensure that they design and develop separate test cases for testing mobile apps because obviously the user experience is completely different than the desktop usage. Testers need to always remember and ensure the thumb rule of mobile usability – the user should be able to perform the desired task in less than 3 seconds!

2. Operating Systems:

As the usage of smartphones is growing, the users are also becoming smarter with the phone usage. They are using their phones to download newer apps, view websites, be active on social networking sites, make purchases, and also maintain business communications. As the phone demands are increasing and usage patterns are changing, the expectations from mobile operating systems are also growing. There are many mobile operating systems in the market today and each operating system has multiple versions. The complexity of supported platforms has gone to new level. When you make your app compatible with KitKat, Lollipop is already there and you start hearing the news about Marshmallow (you know what I mean!). Businesses need to make sure that their apps are truly device agnostic and work well on various operating systems and their versions. This problem becomes bigger when there are multiple mobile browsers and their versions to be tested.

 

mobile platforms

This Image is available courtesy of tech.dbagus.com

 

3. Screen Sizes:

In March 2015, Tim Cook announced that Apple has sold over 700 million iPhones in total. It is estimated that by the end of 2014 3 billion Android smartphones are sold. Then there are Windows phones and Blackberry too. While we have the numbers for the popular brands, there is also no dearth of many local players who are continuously launching new phones. Every new version of the phone possibly comes with a new screen size. Thanks to the changing mobile behaviors, consumers are adapting to and responding positively to the screen size changes. Businesses today have no choice but to tweak their mobile apps design and the behavior to adapt to the new phones and continue to offer exceptional user experience to all the users across various smartphones and screen sizes.
For every geography, the preferred choice of devices is different and therefore you might be able to cover 90% of your app users through a variety of 5-6 phones. However, if you need to test multiple mobile apps catering to a variety of audience in different geographical locations, if your mobile app testing lab has only 7-8 devices, looking at the vast smartphone market, you are probably covering only 25% of your customers.

4. Variety of Carrier Networks:

The apps which are supported across multiple geographical locations and are available in multiple languages need to be tested with various operators across multiple countries. This is very crucial because for many apps, the user experience and usability depends a lot on the performance of the available carrier’s network. The app testing challenges increase with such increased complexity.

 

carrier networks

This Image is available courtesy of ebay.ie

 

5. Battery Life:

Battery life has been biggest complaint of smartphone users and mobile users are very sensitive about the phone battery life. Every smartphone manufacturer is struggling to enable faster performance, better gaming, video viewing etc. while providing a long battery life. On top of this, if any app further drains the battery, then the users don’t hesitate to uninstall such apps. While app developers need to take care of battery consumption, it is also the responsibility of the testers to ensure that apart from the app features, usability, and stability, they test the apps for power consumption as well.

6. Security:

We all keep reading the stories about site hacking and data leaks. Businesses are also struggling to ensure apps security. Stats suggest that more than 50% of the apps don’t take enough precautions while revealing the secured information about the application or users and many apps don’t even have proper encryption methods. Mobile app testers need to have deep understanding of security testing.

7. Performance:

Mobile apps must account for limited and variable network bandwidth. Even a shared mobile network can have a significant impact on the performance of the app. The mobile apps users are very impatient with slow performance. A research by The Aberdeen Group has revealed that around 25 percent of app users abandon a mobile app if they experience a delay of more than three seconds. The performance testing is a fairly technical job which involves testing of numerous aspects such as CPU utilization, memory utilization, cache size availability, memory leakage by the app, internet data usage, offline data usage, caching, and number of round trips etc.

Conclusion:

Mobile apps testing is a more complicated and different ballgame. It requires a thorough knowledge of testing and QA methodologies, deep understanding of mobile apps space and also the understanding of multiple areas like technology, hardware, usability, user experience. The testers also need access to test labs to ensure maximum test coverage. It can be practically impossible as well as costly to create a test labs with multiple physical devices but testing only on simulators is not 100% reliable. Don’t rely on anyone who is not experienced in this field.

Will Windows 10 Change Application Development ?

In about 4 weeks Windows 10 has now been installed in over 75 Million PCs. Despite predicting a slow and sure adoption the estimates now are that roughly 358 Million PCs will move to Windows 10 in 12 months. Microsoft itself has set aim at 1 Billion devices running Windows 10 within 3 years. There is no mistaking Microsoft’s focus on Windows 10 – its preferred revenue platform for the future. Microsoft has publicly stated that they intend to use services and apps to generate revenue from their customers over their entire computing life cycle. The adoption rate in enterprises, as expected, is slower but even that is expected to pick up as support for the current favorite OS, Windows 7, starts drying up. Microsoft is also ramping up the Enterprise focus with IT Department friendly Windows 10 features like easier management and automatic configuration of devices and security improvements. With Windows 10 clearly here to stay what impact will be felt in the Application Development world?
window 10 image

This Image is available courtesy of msdn.microsoft.com

The major change seems to be driven the unified platform strategy. In many ways Windows 10 is the final step in Microsoft’s strategy to bring all its device platforms together into one, united Windows core. The objective is that every device, PC, Tablet, phone, game console and everything to come in the IoT world, should be able to run the same app- thus creating a universal app platform. In the official MSDN Blog introducing this “Universal App Platform” Microsoft’s Kevin Gallo laid out the goals for the platform as:

 

Universal app platform

This Image is available courtesy of blogs.windows.com

  • Driving scale through reach across device type.
  • Delivering unique experiences
  • Maximizing developer investments.

Let’s talk about Mobile OS’ -this platform independence will mean that apps developed by developers working on other operating systems like Android and iOS to Windows can be moved to universal apps seamlessly. This will help increase the number of Apps available to Windows mobile users and presumably drive up usage.

Then there are screen sizes – with so many form factors out there one of the big App Development challenges has traditionally been designing for different screen sizes. Windows 10 provides the ability to use a single UI that can adapt to large and small screen sizes making this task just that little bit easier.

Microsoft has highlighted unique experiences as a platform goal. One way Windows 10 hopes to create such experiences is through the many UI controls that have been provided. Users interface with the apps in several different ways. These controls have the capability to figure out just how and deliver an appropriate user experience. As an example a user using a laptop with a touch screen would get larger icons to select from than a more precise interface like say a mouse or a touchpad.

What about all those PCs out there, many of them in slower moving enterprises that are still on Windows 7 or 8 flavors? The good news for those developers developing desktop apps for these versions is they can now harmonize their existing .NET and Win32 content with Windows universal apps.

universal window platform

This Image is available courtesy of blogs.windows.com

How have the concerns about developer investments in time and effort been addressed? A significant step in the Windows 10 universal app is the inherent ability of websites to run within the Windows 10 Universal app and thus make the most of the system services. Website developers are saved the hassle of having to learn new languages and find it easier to get their apps on the Windows store.