Category: Technology

Food safety- how much does this factor affect you while having food that are not made at home? Not much? Let’s see some facts then;
Centers for Disease Control and Prevention (CDC) estimates that every year, 48 million people (equal to one in every 6 Americans) get sick from the food they consume. Of that, 128,000 wind up in hospitals and close to 3,000 die!
Now you probably see the need for ensuring the safety and quality of food that you give your children. That is not all, if you are still sitting back and relaxing that the Government regulates the food safety through regular inspections and acts to make sure that the safest food reaches you, see some more figures below:
“To speak only of food inspections: the United States currently imports 80% of its seafood, 32% of its fruits and nuts, 13% of its vegetables, and 10% of its meat. In 2007, these arrived in 25,000 shipments a day from about 100 countries. The FDA was able to inspect about 1% of these shipments, down from 8% in 1992. In contrast, the USDA is able to inspect 16% of the food under its purview. By one assessment, the FDA has become so short-staffed that it would take the agency 1,900 years to inspect every foreign plant that exports food to the United States.”
― Marion Nestle, Pet Food Politics: The Chihuahua in the Coal Mine
As you can see, FDA has long been incapable of ensuring food safety standards for a vast number of food-processing facilities out there, shows the report. The overall number of FDA inspected facilities decreased from 17000 in 2004 to 15900 in 2009. In 2009 FDA contracted with 41 states to conduct inspections and about 59% of FDA’s inspections were carried out by them. Lack of enough personnel to carry out the investigations, ineffectiveness of the current systems, poor technology adoption in auditing, lack of proper software or applications that automate work etc. have contributed to this ineffectiveness. The report concludes that serious steps should be taken to ensure that contract inspections are effective and food given to citizens are safe. Yes, of course, but how can FDA fix this?
Business Process Automation
Will an increase in funding, or hiring and training more inspectors to carry out the inspections change the situation? Is it going to help in the long run? Maybe not. Surviving in the world of food business will need a lot of planning, intelligence, automation, attention to details and as many industry leaders say, a smart and latest auditing technology that reduces the overheads of manual processes and speeds up the processes efficiently through automation.
Auditing is indispensable to ensure the processes and procedures in food manufacturing, processing and transportation occur safely and correctly. Yet the system has long been inefficient in terms of accuracy and time management. In an era where technology permeates in skyrocketing speed in every aspect of business, the food companies should very well understand its capabilities and take maximum advantage of it. Technology should be applied to automate the regulation of quality and safety assurance programs to yield improved data accuracy, better time savings, corrective action tracking, reliable validation, real-time reporting, customizable data collection, and management. The amount of manual work going into inspections should decrease and technology should enable fast, easy and reliable food audits.
Any new food safety auditing technology should include the following basic features:

• The system should be able to standardize and centralize all food regulation records in a single place, so that it is easy to create, approve and distribute documents. Document/ record control must be made easy and convenient.
•  Should manage internal and external food compliance audits including tasks like scheduling, reporting and corrective action follow-up.
•  Should provide a flexible configurable platform to manage, define, track and report on changing business practices to support food safety.
•  The audit trails should have facilities for electronic signatures to eliminate the inefficiencies of paper and pen based reporting systems.
•  Transparency of supplier’s quality processes.
•  The system should be able to integrate document systems for single/multiple locations, such that information needed is easily accessible to participants, anywhere, anytime.
•  Should allow better visibility over activities and processes internally and externally.
•  The system should be able to output different visual representations for data. For instance, numeric data collected by representatives should be made available in graphs or charts.
•  Users should be able to see histories and data collected over a period of time to view the trends in the readings collected, enabling better decision making.
•  Ability to collect pictures, videos and documents as evidence.
•  Provision for responsibility assignment.
•  Fast generation of automated reports and documents to demonstrate compliance.
•  Ability to make any module mobile through mobile apps.

The benefits of using such auditing software are:

•  It standardizes workflows into simple processes that repeat over time.
•  Quality remains consistent and will improve the overall efficiency.
•  All related information is available in a central place.
•  No jobs or duties are left unattended or forgotten.
•  Easy to assign responsibility at each stage.
•  Increased integration and timely interaction helps for better collaboration between you and your suppliers.

It’s only when the entire industry streamlines its processes, and communicates via a streamlined, efficient and accurate technology can we expect a progress in the quality of food we consume outside. Our own product, Reachout allows authorities to create and manage the audit work orders and track the trends of audit compliance. It might be tough to change existing processes but the key to transition is selecting software that can be customized according to your unique auditing processes and needs. Choosing software which can easily integrate into the current processes and procedures without the need to make major revamps to existing systems will be ideal for a start. Talk to our experts to know what kind of software will work best for your business needs.

Image courtesy: Canadian Food Safety

Last spring, we found ourselves working with a global media giant,  to understand why their new high tech enterprise information sharing IT system was not being used by employees. As we plowed through the usual rigors of analyzing feedback from front-line staff, department managers and BU heads, we discovered something puzzling. While the new state-of-the-art system was hardly being used by anybody, few departments and teams used alternate custom-built IT systems to automate their processes. Most of these custom-built systems were rudimentary and offered poor user experience, and yet, every team member had adopted and used their system every day! Digging deeper, we discovered something even more surprising – The development and deployment of these systems were managed by the Line Manager (s) of these departments, who had little to no knowledge of IT or Software Development!

Why did an expensive, cutting-edge digital information system fail miserably, where a less sophisticated, custom built software succeeded with aplomb? How did non-technical line managers succeed in deploying technology effectively, where senior IT specialists failed?

Sure, deploying a new, large, complex, and organization-wide system across different locations is fraught with enormous technical challenges, but the real answer to these questions lies elsewhere.

The IT department, was attempting to solve a technology problem. However, none of the users had a technology problem. They had business problems.

Problems about information availability, sharing and communication in the context of how they got work done. Divisional, middle and operational managers, i.e. the Line Manager was in a much better position to understand these problems, since he knows the people in his teams and how they get work done. Direct involvement of the Line Manager enabled the building of IT tools which solved business problems that his/her teams faced.

In hindsight, the centralized top-down approach of IT system deployment was a mistake. The IT department never stood a chance.

Understanding the processes, practices, people and nuances of every team in a 6000 person global organization was an unrealistic expectation, especially under a tight budget and timeline. A decentralized approach to technology development and deployment, where the Line Manager was empowered to take technology decisions for his or her team, would have yielded better results.

Decentralization, as a management concept, has been around for a while. William B. Given Jr.’s book Bottom-Up Management, 1949 was probably the first to talk about Decentralization, while Drucker’s works over the last 50 years have often made the case for giving front-line managers greater control. However, it is only in the last decade that we saw an increased devolution of formerly centralized responsibilities (like human resource management, risk management, and strategic planning) to the Line Manager.
In this context, the decentralization of IT decisions is a natural step forward. Looking at our own portfolio of projects at Fingent, we see a steady increase in Line Managers successfully creating, customizing and deploying technology solutions for their departments. I believe that there are three key reasons why the Line Manager is successful in independently managing core information technology needs of his/her teams:

• Line Managers, especially those who are hands-on, are able to derive a good understanding of information architecture requirements
• A Line Manager understands of how the team gets work done, and
• A Line Manager’s ability to lead and manage changes to the ways of working.

The right information, at the right time

In relatively flat, multi-functional organizations, workers at every level have decision-making responsibilities. For such a knowledge worker, the ability to assimilate, interpret, arrange, sift and process relevant information is critical for the successful execution of day to day tasks.
Take the case of the failed digital-information IT system; asked to identify the single most important cause of failure, users across departments answered that the information necessary for work was either unavailable in the system, or was not available at the right time or in the right format. Each of the smaller systems that they were using daily was tailored to meet the specific needs of the team, providing different roles in these teams with the information they required to operate efficiently and effectively. Information was shared in the context of the tasks and stage of work, ensuring that it was available to the right person at the right time. These systems thus organized and structured information in a manner best suited to the team’s objectives. Or in other words, they had good information architectures.
Different departments/teams adding value to the organization in different ways need radically different information architectures. Information required for software developers to execute their day to day tasks is usually different from information necessary for a hardware engineer, HR personnel or Sales personnel. The IT department, which led the deployment of the failed solution, tried to create a system of compromises, and in doing so, compromised the critical needs of almost every department. This flawed approach resulted in a significant wastage of money and time.

A good information architecture secures that the right information is available to users; enabling a good technology system to use this information architecture for delivering the right information to the employee at the right time.Creating a good information architecture requires: the allocation of the right resources, interfacing with supplier and customer teams ( internal or external), a good understanding of current and desired processes, and a good understanding of the strategic and tactical objectives of the department. The Line Manager for the team/department is in the best position to take ownership of this activity and to use his resources to drive the creation of a good information architecture for his team or department.

There is one specific aspect of the information architecture where the Manager must be hands-on; performance measurement. Early measurement systems were top down, with KPIs being set by Senior Executives cascading down to the teams. However, with the greater empowerment of teams, we now see teams, designing their own measurement systems, in line with corporate strategy and measurement systems, to gauge own progress. The manager of a team is often responsible for the KPIs, its methodology and also the measurement. He should determine the level of access that different roles in his team, have to these measures.
Providing the right information, to the right person at the right time often provides the base for realizing the value added by technology. This “right information” is realized using the Information Architecture used by a team. Technology can then be deployed to use this Information Architecture to deliver information to employees in the context of their day to day work. The Line manager is in the best position to drive the creation of the information architecture for his team, while securing that it is aligned with organizational strategic goals and the team’s tactical objectives.

Processes and Practice: A Line Manager knows the difference between theory and application

In addition to a good information architecture, technology must also be aligned to systems used by the department, to add value to the organization. These systems are deployed via processes, and these days almost all self-respecting departments and teams of knowledge workers have documented processes. Whether the documented process meets practice is another story entirely. In the case of knowledge work, especially work that requires moderate to high degree of autonomous and creative thinking, tacit knowledge and improvisation trumps documented processes in practice.

When automating the change management system for the pharma enterprise, we discovered that different project coordinators had different approaches, planning, reporting, risk management and interdepartmental cooperation, which often resulted in significant deviations from the documented processes. For such a department to realize the benefits of automation, documented processes alone are insufficient. It is vital to consider the entire system as practiced and applied by the users, and in doing so, prioritizing the creation of tools to automate the desirable aspects of the system. It is the promise of predictability and stability in the way things get done using a system that often determines the effectiveness of deploying the software application. The Line Manager of the Department has a good view of the overall picture, people and the operational details; all of which are critical inputs to good decisions about balancing process and practice to achieve a stable system.

In the case of the pharma company, the Line/Department Manager was able to obtain the necessary strategic, operational and tactical perspective to determine specific processes and practices which were important to automate. Only he had sufficient authority and responsibility to ratify and take responsibility for these decisions. The IT department, or a 3rd party consultant, or even most people in his team would not be able to provide the unique perspective necessary to take these decisions.

The software solution we deployed for this department not only provides the benefits of automation, but also helps the team identify process deviations, enabling good decisions about the acceptance and mitigation of these deviations in day to day operations.

Often, the development of new tools and technologies is a trigger for teams to introspect and overhaul their existing systems. One of our clients, a property acquisition department at a national property management firm, re-architected their processes to take advantage of the benefits that a custom-built software application could provide. Their old system was built around the tools of pen-paper and a commodity desktop solution available then. During our early stages of pre-development analysis discussions, they realized that a custom software application, could free the department from the constraints of the commodity software, and open the doors to add value in new and innovative ways. Through mobile devices, real-time updates, and improved reporting, they could realize benefits that were not accessible to them before. They reinvented their property acquisition processes, providing significantly greater value and increasing the department’s strategic value to the organization. Such successful change was possible because the Line Manager was able to allocate a good team to work with the core process changes and technology upgrade, while he also worked with his peers and governance board, to plan and manage the delivery of business benefits.

 Providing change leadership: Who better than the Line Manager?

Like any other change program, the deployment of new software technology invariably runs into resistance from employees; often the biggest challenge to software deployment.

IT deployment often makes some previously subjective measures objective and visible to all. Employees may be nervous to reveal more information than they used to do before. Then there is inertia, the reluctance to shift from comfortable routines and practices to a different way of working.

Supporting the team to see the change brought about by technology deployment is a leadership challenge. The Line Manager is in the best position to take up this challenge.

Leading such a change requires the active, consistent and continuous engagement of all employees who will ultimately be impacted by the change. It requires the creation of trust, so issues and concerns can be discussed and evaluated freely, together with the perceptions of value and benefits of the new system. This is an undertaking that requires significant effort, often at an interpersonal level. The Line Manager is the ideal candidate to lead such an effort. As organizations become flatter, the manager is a coach and a mentor to the individuals in his/her team. Alongside tactical directives, a Line Manager can use one-to-one meetings, coffee machine conversations and other informal discussions to evangelize the need for the new system and reinforce the benefits: a better work profile, reduced workload, skill upgrades and much more.

Leading such an effort also means assembling the right people, from the very start of the technology development initiative. These are people with the right skill set, organizational credibility and influence. Assembling such a team, and providing them with purpose, while leveraging their strengths and abilities at the right time can make a big difference to the progress and the success of a technology deployment project. Some team members may be good with early phase visioning, while others may be simulated by the challenges of training and change management. Choosing the right people for the right task, and giving them the ownership of creating and deploying the new system can increase interest levels in the entire team. This also leads to  greater participation, and mitigating resistance during deployment. The Line Manager knows the strengths and weaknesses, the goals and aspirations of the individuals in his team. This enables him or her to make good decisions about mobilizing the right people for the project.

Leading this change, requires the management of day to day operations, while resources are devoted to the deployment of the new system, and while the department migrates from the old way of working to the new system. The Line Manager can secure minimal impact on ongoing operations, by allocating the necessary time (and backups) for those involved. And also providing the necessary time and support for the entire team to learn and use the new system. He can use his resources and forums to identify potential deployment blockers and mitigate such risks early. For example, staff meetings provide good opportunities to build cohesion and agreement about the new system and the deployment plan. It is also an effective way to source ideas and motivate volunteers for beta testing.

Conclusion

The choice of tools to execute a task requires combination of strategic, operational and tactical knowledge to make informed choices. The IT department in an organization, which services many lines, sections and departments, cannot be expected to have such an in-depth understanding.

The Line Manager is best positioned to have such an intimate understanding of the business and its operations. The Line Manager understands the formal and the informal processes, which gets the work done within his team. He/She knows the measures and indicators on his department’s scorecard, the data required for these and the processes which define these. He/She knows and often owns the processes that detail how his team interacts with other teams, within and outside the organization. The Line Manager understands a team’s suppliers and customers. And most importantly, the Line Manager understands the team today – the people who work for him today, their capability, their skillset and he/she understands the team required for business tomorrow – the capabilities and skill set required to keep up with a changing business environment. From an organizational perspective, giving ownership of technology to the people who will use it, empowers them with greater control and responsibility towards the outcomes expected from them.

There have been major changes in the way software and applications are built in software companies. Enterprises have moved beyond the conventional waterfall development model to more flexible Agile development environments. The whole idea of agile development methodology is to manage change incrementally and effectively in software and external functionality, and to speed up the development of quality software. And a major challenge here is to provide quick feedback on the change introduced in the software and the impact of it. The cornerstones of a proper agile approach to software development are early testing, rapid feedback, and effective communication.

Load testing in agile environment
Load testing is feeding the system with largest/ toughest tasks it can operate with, to see if the system can endure the stress. Historically, in waterfall development model, load testing gets pushed to the end of the project, assuming that only minor tweaks will be required to meet the performance criteria. With agile, load testing should be carried out often, and incrementally. But due to lack of adequate, trained and dedicated testing resources, lack of flexibility of load testing tools, lack of proper criteria, or due to infrastructure limitations or the common misconceptions among people around what’s possible with load testing and performance testing, these often get pushed to the end of agile development process.
Unless employees get beyond the following testing myths and delve deeper into the process, and realize what all is possible with today’s performance testing capabilities, we can’t do justice to the fully agile concept. So, here are the common misconceptions that employees should get rid of, to drive their testing initiatives deeper into the agile environment.

Myth #1: Load testing is all about breaking the system, so, unless the system is fully developed, load testing can’t be attempted.
Load testing is like a full-throttle, threshold limit or peak-usage stress test. Thus, in a way, people think of it as forcing the entire system to its breaking point. So, unless the entire system is built, how can you break it? Naturally load testing can’t be fitted into the small, iterative batch of Agile; thinks most of them.
You can help dispel this myth by creating a suite of modular performance test scenarios for common queries and crucial transactions. Performance test can be carried out in individual modules as easily as functional tests are done. Performance tests should work alongside functional tests with every sprint. This will prove that there’s lot more to performance testing than its objective mentioned previously, and will unveil the different ways it can fit into the usual Dev-Test-Ops cycle.

Myth #2: It’s risky
Load testing might sound risky, but, it is always safe to run a controlled test than to let the system fail under scenarios which were easily preventable and thereby avoid putting your reputation, revenue and users in jeopardy because of it.

Myth #3: It takes a long time in Agile
This can be a valid excuse if you push the load testing towards the end of the project, but in agile environment, the process of creating and executing the test at scale needn’t be that complex and time consuming. Think about the requirements upfront and put performance SLAs (Service Level Agreements) on the task board. This will help to automate basic testing processes. In fact small, iterative tests with incremental objectives allow testing in equal or much less time.

Myth #4: Developers needn’t concentrate on Performance until Functionality is complete
One of the key ideas of Agile programming is to find issues early and fix them fast and at lower costs, which is why we find a lot of testers learning to code, and adopting trends like automated tests and test-driven programming. This helps them run tests alongside development. The same is expected from load testing. Isn’t it always better to find errors or issues right when the code is written than to skim through the entire program to find a tiny line of problematic code at the end of development? Many back end interfaces like, Web services or SOAP open up opportunities for testing performance along various application paths even before the app functionality is completed.

Myth #5: Load Testing Doesn’t Involve the Whole Team like in Functional Testing
Earlier, we had a single individual or a group dedicated to conduct specific tests like the performance testing, but in an agile environment, everyone is a Tester (or developer) and all members contribute in every phase of software development to achieve the quality end product. Though there are testing experts and QA specialists, developers are still made to write their own test cases and similarly, operation specialists can identify issues and work to fix them.

Myth #6: Load testing is unnecessary if we do thorough testing in lab
Testing in a lab environment is good for testing the app, but it doesn’t cover the broader infrastructure. Many a times, we have seen serious, unexpected issues cropping up outside of the apps. Load testing in production can’t replace lab testing, but it reveals issues that other tests can’t, like, Database issues, Network bandwidth issues, unbalanced web servers, App server issues, DNS routing problems and Firewall capacity issues.

Myth number #7: The right load test tool will do everything for me
You can’t trust on tools to do every task perfectly, however smart the tool may be. You will have to do certain basic tasks yourselves like, setting up meaningful KPIs, realistic master data, creating valid, repeatable test cases, realistic master data, analyze the results, etc. Eliminating the human involvement completely during the test might reduce the confidence in the code you deliver.

Myth number #8: Load testing is too manual
From the previous point, it’s sure that you have tools to automate certain aspects of Load testing, so that the test isn’t completely manual. There are so many ways you can automate load testing, it’s just about choosing the right processes to automate.

Load testing can reveal functional problems in the code that can’t be otherwise detected using single-user tests. However, unless you make load testing an integrated part of the development process, you can’t completely say that you have an agile development methodology, nor can you extract its benefits.

In conclusion, there are several myths about load testing in an agile environment, which can impede the delivery of high-quality software. To overcome these challenges, partnering with a custom software development company is essential. With their expertise, they can help organizations implement load testing strategies that align with agile principles, ensuring that software meets performance and scalability requirements.

Data visualization and dashboards. The perfect means for communicating ideas and complicated information easily. However difficult it is to explain your ideas, if you use interesting and interactive graphics for it with the help of user-friendly data visualization tools, you can create beautiful presentations and put forth your thoughts easily. But is just making interesting dashboards enough, to make your audience understand and engage with your content?

Along with putting a lot of thought into making graphical presentations, you also need to spend time on getting it across to your audience. It’s a combination of strategies while making presentations as well as marketing them, that make them effective. Here are some quick tips on how to make your dashboards or presentations go viral:

While creating them…

• The right data – While creating your presentations, take a little bit of effort to do research and find out what your target audience is like, and what they might find interesting. For example, if you have numbers, create a context with which the target audience can relate rather than simply giving out the numbers.
• The right graphics – As an extension of the previous tip, the research will do good in case of graphics as well. For example, whether to use complex charts or simple infographics.
• A good story – The data in your presentations can be made more effective if presented in the form of a narrative. The story supported by the numbers will be perfect for emotionally appealing with the audience.
• Interactivity – One of the best ways to engage with your audience is to make your charts interactive. Average charts are no more in the picture these days. You can make your presentation stand out if you make them feel that they are personally part of the discussion.
• Data accuracy – It goes without saying how important it is to present accurate and reliable data to the audience. If by any chance they feel that your data is not credible or unreliable, then they might not come back to you.

While marketing them….

• Buy-ins – Make sure that you display the apt Key Performance Indicators (KPIs) and gain buy-ins from the audience. This is significant from a future perspective as well, as the value of your data will spread around through word-of-mouth, when people discuss your presentation.
• Use social media platforms – Using social media platforms such as Facebook and Twitter, and also the corporate versions of these like, SalesForce Chatter to push your content is a very effective strategy. You can create groups in these channels and post regular updates to keep your audience engaged.
• Round-the-clock accessibility – Make your content accessible from anywhere, from any device and at anytime. The audience should be able to get to your data in a few seconds and with just a few clicks. Or else, you are likely to lose them.
• Fast loading – Just like being able to access your data in seconds, it is also important that you make sure your content page loads quickly. It also shouldn’t crash after a while. These are some of the major reasons why people quit a page or an app.
• Internet platforms – Just like social networking sites, there are many platforms or forums on the internet where you can go live and post your content. Being live, it enables fast responses and results.

Apart from these if you do sufficient research, you will be able to find places where data enthusiasts often meet or discuss data relevant to your business. You can use those channels as well to push out your content.

Data visualization is undoubtedly one of the most effective ways to reach out to your clients or customers. If done properly, with the right tools and in the right methods, it will improve your efficiency and reliability by a large margin. Are you looking to create leverage data visualization for your business challenges? We can help you with it!

Ok, so we’re all very well acquainted with our friend, the web browser. It has helped us with so many things in life, answered so many of our questions (well, technically it is Google, but nevertheless), and kept us entertained. It simply became a huge part of our lives. And how?
Through its well-built web applications. Our web browsing experience is influenced a great deal by these two factors, the web application and the web browser. And over the years, we have seen a hell lot of improvements in our browsing. The kind of browsing experience we have now is not something we imagined a few years back. To explain how it has changed, let’s take a quick look at how web apps used to be in the past.

While growing up

Ever since the introduction of the web, browsing worked something like this; when you type in the address for a web page, the browser requests for the page, say for example “Fingent.com”, which causes a server somewhere on the internet to find and create an HTML page and send it back to the browser. Back then, browsers weren’t all that powerful and HTML pages were basically just static and independent documents, so this set up in the back end worked well. Later on, Javascript (the programming language) came to be used, which allowed web pages to be more dynamic. Even then, web pages used nothing more than image slideshows and date picker widgets.
After several years of technological advancements in computing, the web and the web browser have evolved so much that, it has become a platform for fully featured and rich applications. With the introduction of HTML5 standards, put together with fast JavaScript runtimes, developers have been able to create richer apps that used to be possible only with native platforms.

Single page apps

Much later on, developers started building full-fledged applications on the browser using JavaScript and its advanced capabilities. Single page apps (like Gmail for example), were able to react or respond immediately to user actions without having to go to the server to bring up a new page. Such applications used libraries like Backbone.js, Ember.js, and Angular.js, all of which come under the client-side Model View Controller (MVC) architecture model.
In this case, the mass of the application logic (like views, controllers, templates etc.) lies in the client side and communicates with an API for data. The server, which may be in any language like, Ruby or Python, handles the creation and serving of an initial bleak HTML page. Javascript was the basic and traditional language of the web browser, and computations were directly performed on the user’s machine. This was called “client-side processing”.

Such apps were actually very good for the user as all they needed was the initial loading time. Once that was done, then navigation between the pages would become pretty easy and smooth without refreshing the page and it even supported offline browsing if everything was done right. Even for the developer, such apps were perfect, as there was a clear cut division between client and the server and there was not much sharing of logic required between the two (which are often in different programming languages), which facilitated the smooth workflow.

However, there were a few flaws in this perfect approach for web applications:

Trouble for the spiders

An application that works only on the client side is not capable of serving the web spiders or web crawlers. Web spiders are automated programs or scripts that run to search the web in an automated and systematic manner. The process is called web spidering. A lot of search engines and even sites use this process as a way to provide up-to-date data. What they basically do is request the server for a page and interpret the results. If however the result is a blank page or an undefined page, then it is of no use. Now, as such apps cannot support web spidering, their SEO (Search Engine Optimization) will be poor or not up to the mark by default.

Slow applications

If the application is requested for by the user, and if the server is unable to provide the full HTML page and hence waits for the JavaScript on the client-side to do so, then it causes a delay in loading the page by a few seconds, which could actually cause huge losses. There are several statistics that prove how drastically sales get affected as a result of a slow web application. Need I say more.

Apart from these, there were several other minor limitations like for example, as there was a clear distinction between the client and server sides, there were chances for duplication of application logic and data, such as formatting of date and the like. Such things were more problematic in case of huge and complex applications.

THE SOLUTION

With all the above-mentioned limitations, there was a need to find a solution that surpassed these issues and yet maintained the efficiency and smoothness of client-side application logic. Thus emerged Isomorphic web applications developed using React.js.
A word about React.js first – It is basically an open source JavaScript library used for creating user interfaces for web applications. It intends to overcome the issues in developing single page applications and is maintained by Facebook, Instagram and similar communities of individual developers.

An Isomorphic application is one that can run on both the client side as well as the server side. The code for an isomorphic application can be used or shared by the front end and the back end. A major difference in such applications that make them much better than other applications is the way they process requests. An initial request made by the web browser is processed by the server and all other subsequent requests are processed by the client side.

Now there are a number of benefits associated with Isomorphic applications due to which they are rising in popularity and becoming a huge hit among developers as well as users. Let’s take a look at some of these benefits:

• Speedy– Isomorphic apps are faster to provide HTML content, as the request is not always handled by the server-side. Only the initial ones reach the server whereas subsequent requests are handled by the client-side. This makes browsing faster and more efficient. Moreover, as opposed to common Single Page Applications, where the first request is used majorly for loading the application and then further steps to gather the required data, Isomorphic apps have fast first page processing and even faster further processing.
• Versatile – New devices, as well as old devices, can browse Isomorphic apps, as they return HTML which is compatible with every device, irrespective of features. Single Page Applications returned tags that contained JavaScript which proved to be a problem with older devices.
• SEO Friendly – Isomorphic apps are supportive of web crawling and hence contribute to better SEO. And from 2014, Google can crawl JavaScript applications as well.
• Less Code – As the code is shared between the client side and the server side, there is much less code required as against Single Page applications. This makes it a lot easier to develop as well.

Another major factor is the fact that Isomorphic apps can be easily maintained. As there is no need for duplication of application logic between the front end and the back end, it makes handling of even complex applications much easier.

A lot of these benefits make Isomorphic apps very popular among developers, as they all point in one direction – that is, making development easier. They also give the expected results, and that put together with less coding, makes it a favorite among developers.

As for the users, speed and efficiency are the essential drivers. If you have an application that loads fast and gives excellent features, what more do you need?

The future

Node.js seems to be becoming mainstream with most organizations around the globe. This means that it is slowly becoming inevitable that web apps share code between the front end and the back end. Isomorphic JavaScript is essentially an array that may start with simple sharing of templates and then go on to even handle an entire application’s logic. Applications that live on the traditional back end can also use Isomorphic JavaScript by creating sensible APIs and making it exist along with Node.js. Thus, “Isomorphism” is slowly but surely taking over browsing and soon, there will be a time when not a single advanced web app exists, that does not make use of some JavaScript running on the server.

Tiny flaws

Just like any application, there happens to be a little flaw with Isomorphic apps as well. It’s just that debugging is a bit of a problem for such apps. There is probably a need to use separate debuggers for the server side and client side of the application. Like for example, for the server side, a node.js debugger would be sufficient while for the client side, maybe the web browser’s debugger would do. It depends on the kind of application as well.
Another possible difficulty could be in managing the settings on both sides. For example, the setting for the server side such as API keys and for the client side like the hostname of resources used such as CouchDB, could vary according to the production environments and it could be quite a task managing them.

Conclusion

Just like any other application, Isomorphic applications have their own share of advantages and disadvantages. In spite of the minor flaws, these apps are definitely increasing in popularity with each passing year because of its ease in development and speed. It is an exciting technology that comes with the option of various isomorphic libraries available, that can be chosen according to the scenario. What do you think about Isomorphic applications? Share with us in the comments below.

What is the first thing that comes to your mind on hearing the term, Virtual Reality? Do you get images of Neo and Morpheus strolling about in “The Matrix” or is it that of Johnny Quest with his father fighting it out in their “other world”. Either way, you are about in the right track. To think that these were characters created as part of the fantasy world in the past.
Virtual reality is a concept that is fast becoming common and popular these days. It opens a whole new range of exciting opportunities with it as well, especially in the world of gaming. Leading techs are already in the game, with their much-anticipated products such as Facebook’s Oculus Rift, Microsoft’s HoloLens, Sony’s Project Morpheus and a comparatively low-cost entry into this field, the Google Cardboard.
A lot of these devices are already being used in a number of industries across the world, as virtual reality is one of the most versatile technologies ever to be innovated in the recent past. To know what the hype is all about, let’s take a detour to find out what virtual reality is.

What is virtual reality

Virtual Reality is basically a concept in which computer technology is used for creating a simulated three-dimensional world. One in which the user can manipulate, maneuver and explore stuff while experiencing a feeling of actually being in that world. Nowadays, it is also known as Virtual Environment. Though there are different theories and opinions on what exactly comprises a virtual reality experience, the basic constituents are:

• three-dimensional, life-size images from the user’s point of view
• the power to monitor the user’s movements and change the images and features in the virtual display to reflect the changes in perspective

There are several devices and applications these days that have been created solely to achieve these goals.

A peek into how it works

The user feels a sense of “immersion” on being in a virtual reality environment. Immersion refers to a feeling of being inside or part of a particular world. Once the user starts interacting with the environment, he gets into state of “Telepresence”. Telepresence is a combination of the sense of immersion and interaction with the environment.
A proper Virtual Reality environment will actually make one feel detached from the real world or real surroundings and get you to focus only on your existence in the virtual environment. Computer Scientist Jonathan Steuer says, “Telepresence is the extent to which one feels present in the mediated environment, rather than in the immediate physical environment.”
Devices are designed by the developers with the help of technology to create these feelings among the users and provide rich virtual reality experiences.

The future

The two main custodians of larger-than-life experiences – the gaming industry and the film industry are the pioneers in using virtual reality for business. They are likely to take virtual reality to new heights and set the pace for other industries as well.
For example, the 700 billion dollars worth glamour industry in the United States, Hollywood uses virtual reality to make amazing movies. Nokia’s new Camera Ozo, is likely to become a huge hit in this regard. With the ability to capture audio and video in 360 degrees, Ozo has been reported to give the most amazing experience with surround sound and images. Users actually felt the voices in their surroundings and were able to turn around and see the characters talking.
There are a number of other companies also looking to invade the film industry like Samsung.

The gaming industry too has a fairly large amount of loyal followers who are highly enthusiastic and encouraging about new innovations. For example, Rebellion, the leading game makers are looking to launch a virtual reality integrated version of their old 1980s classic Battlezone. There are also other companies yet to set their feet into this huge wonder.

Tourism is also another industry which is starting to make use of virtual reality with the South-African tourism being the pioneers. Their shark diving experience is something that is likely to become the next big thing leveraging virtual reality.

From the looks of it, this is already starting to be a revolution which is not going to stop with the present day. Into the future, maybe we’ll have people watching pyramids being built in the early days of Egypt or maybe how the Empire State building was set up in America or watch a play in the original Globe theatre. Books could also be made into jaw-dropping movies or even games with virtual reality supported cameras. We have tons of talented developers waiting, with all the skills to ideate, conceptualize and produce amazing worlds for us to explore and experience. All we need to do is wait for it.

As the reign of mobile applications and mobile devices continue, we, as part of this revolutionary trend, have to keep ourselves updated about everything latest in the mobile world, don’t we? Of course we do. We also have to be aware of everything we need to in this regard. I’m talking about mobile applications and their making. Continuing my endeavour to make you guys acquainted about the many processes and resources that go into making a mobile application, here I’m going to give you some more information on mobile application testing.
In one of my previous articles, A winning mobile testing strategy: The Way to Go, I had explained the various steps involved in the process of testing and the article, and Mobile Application Testing: Challenges and the Solution had the major challenges faced by testers.
Now, for those of you who read through the testing process, in case you are wondering “what other kinds of testing are there?”….

Here is a list of the most commonly used kinds of mobile application testing. Do keep in mind that all of these tests are conducted to perfect different aspects of an application. Hence, ideally a combination of some of these would probably be the best way to go.

• Functionality testing – This is actually the most basic kind of testing for any application, as it ensures that the basic functions of the app work as intended. As is the case with any user interface based application, mobile applications work on the basis of several human interactions as well. All of these functions need to be tested for their accuracy. Considering the challenges faced by testers, like the wide range of mobile devices for example, functionality testing is usually a time-consuming and intensive process if it is done manually. However, there are various automation tools available in the market for functional testing as well.
• Usability testing – This is conducted in order to ensure that the mobile app is easy to use and provides a good user experience to the customers. It basically tests the app from three angles:
  Satisfactory user experience – The user acceptability level or comfort level of the application and also others affected by its use.
  Effectiveness – The level of benefits achieved through the app in comparison to the level of resources expended for it.
  Efficiency – The accuracy of the application in terms of its ability to achieve specific goals in specific environments.
• Performance testing – This covers testing of performance of the application from the client side, server side as well as network. The client side will focus more on things like, responsiveness of the application, user interface elements etc. It also involves testing with different types of data connections, WIFI, levels of battery consumption etc. There are again a number of tools available to carry out testing in these areas.
• Compatibility testing – This is conducted to see whether the application works as intended in different devices, Operating systems and their different versions, browsers and screen sizes.
• Security testing – This is carried out to test whether the application is capable of storing and protecting information.
• Memory testing – This is important to ensure that the application maintains optimum memory usage throughout its life. Mobile devices usually tend to have very limited memory and the operating systems also have a tendency to stop applications that use too much memory, which might lead to problems with user experience.
• Regression testing – This is done in order to bring to light any bugs or errors that may exist in already built modules of a project after making changes such as improvements, enhancements or configuration changes and the like.

There are also other kinds of testing, like services testing, user interfaces testing, operational testing etc. which are also done in some cases depending on the kind of mobile application. Apart from that, the most commonly used tests are listed above. As a general rule, functional testing is often conducted first followed by performance testing and the rest. Like i said before, not all of these tests might always be conducted in order. It all depends on the application. The basic point is that testing is a huge and significant part of mobile application development, and at no cost can this be avoided.

We’ve all had a thousand stories to tell about our clients, haven’t we? From the “oh-so-understanding” perfect clients to the most adamant perfectionists, each client gives us a unique experience to talk about or even learn from, sometimes. Now, how often do we think about the client’s perspective of things; like, what kind of stories would they have to share about us – the designers, or maybe are already discussing now?

Yes, they do that too. This is the part where you can probably think of the times you’ve lost your temper trying to convince the client about something, or the times you’ve messed up things, just because you needed an extended deadline to finish something perfectly.

Its OK. We’ve all been there. Just like clients, designers too have their own unique characteristics and ways of dealing with things.
However, there are some who may be too eager to finish the project, have a million doubts at every stage of the project, and some may know just what clicks, hey, perfectionists exist among designers too. From a client’s point of view, some of these kinds of designers are ones that they should probably keep away from.

So, this is for the clients. Here we list 5 types of designers who can do no good for you or your project. Make sure you steer clear of these people and as for the designers, make sure you don’t fall into any of these categories.

1. The “Mr. Know-it-all” frauds – These kinds of designers are the ones that think that they know everything about everything. They will probably portray themselves as experts in their field and get you to believe that they are the most experienced designers (which they could be, in terms of years of experience alone) and how they are the best for the job. But later on, you will probably realize that your project looks like the latest collection of the free design templates available online and that there is absolutely nothing worth the money you just paid them. They probably think of themselves to be right all the time and others wrong, so they tend to avoid anyone else’s ideas. What’s more, they might just disappear with the money, once the project is delivered to you, and never be heard of again. Try telling him an opinion of yours. If he smilingly rejects it or turns it around to make it his own, then this is probably it.
2. The “perfectionists” – These are the ones that spend hours at length trying to perfect a tiny little aspect of the project and finally end up not being able to deliver the project on time. They might have the most organized way of doing things and often cannot stand the thought of something being out of place. Even though the project might be the epitome of perfect, you probably won’t get it when you want it. Also, they might tend to ignore a lot of instructions because it’s just not their way of doing things and they might not even pay attention to any other ideas because they are just not perfect. Maybe you can try giving him a trial work for which you have a proper deadline and also have a clear idea of the time needed to complete and see if he can do it with full perfection. If he can, then you can go ahead and hire him, but if not don’t hire even if his so far is perfect.
3. The “multi-taskers” – These kinds of designers often take up a number of projects to work on simultaneously and have no priorities set. They will probably also have a couple of ongoing freelance and personal projects too at the same time. As a result, they have absolutely no track of time and hence no track of due dates. The quality of their work on all of these projects also gets affected because they are focusing on numerous projects at the same time. In the end, you will probably be left with a completely off the schedule and substandard quality product, plus a whole lot of wasted time, effort, and money. Try getting a clear picture of the kind of work he already has on his plate before you hire a designer.
4. The “clever foxes” – These are the ones that keep you updated on the advances of the project and keep telling you their bright ideas, which you probably might have nodded along with, because you thought your designer is the best. By the end, you will probably find yourself nodding yes to including something that they made you believe, the project cannot do without and end up spending twice the cost that you had planned and taking twice as much time as what you had initially planned for your project. If you hear a “Your project is almost done, but…..” then you probably have chosen the wrong designer.
5. The “copy machines” – These kinds of designers often search the web for inspiration and new ideas, and finally end up literally stealing the design styles that they’ve browsed through. You don’t want your project website looking just like another one, do you? You certainly don’t want to be accused of copying the design of another website, right? Then you should probably stay away from these unoriginal copiers. They often have a history of similar looking websites and designs to their credit, so if you do your research before signing up with a designer, you can probably spot this one out pretty easily.

There are many other kinds of designers out there who have their own unique traits, like for example, ones who finish off projects ahead of the deadline, but with substandard quality, ones who are the opposite, that is extremely lazy and keep putting off deadlines and ones who like to work alone. The truth is that all kinds of designers have their negatives and positives. The real challenge is to find the one that is best for your project and how will you get there? Research, research and more research.

What other kinds of designers have you come across in your professional life that you think you should avoid? Share with us in the comments below.

Developers and Testers: Two people from two different planets working together to deliver a quality product to an “Alien”! Funny isn’t it?! The story is more or less the same in every software firm. A developer works hard to develop a product, which he handles with so much care and gentleness; a tester works hard to break this code handling it in the worst possible cases and scenarios to test its defects, resistance power, and strength.
So, when a developer finally hands over his much-nurtured sprint to the merciless team of testers, ready to execute the ‘out of the box’ testing, this is what happens:
o User Interface element alignment?                                                      Off!
o Inputting special characters instead of string?                                Unknown result!
o Putting 01 for a range from 1-10?                                                           Crash!
o Entering a date in the past?                                                                    Crash!
o Working with special characters in names like, Neil ’O?                Nope!

And there they silently demolish the code….

Sandpapers scrape and scratch, but to create polished surfaces!
So, there is this formidable wall between developers and testers most of the time, which stops them from having a sustained smooth association. There are many reasons attributed to this silent difference in opinions. For instance, developers are often seen to possess parental attachment to the stuff they create. It’s more like; “I know my kid, he wouldn’t do that”, when the reality is, the kid actually did just that! It might sound silly, but a good programmer should learn to be more objective and accept the fact that they have to do terrible things to their code. Because, if they don’t, others will!

Another problem is, developers have little or no idea how their code is going to be handled at the other end of the boundary wall, and thus they aren’t ready for the million bugs that testers backfire at them. Being in the developing environment, which usually revolves around positive scenarios of how to make things work efficiently, they often lack the ability to switch to ‘what can go wrong’ mind state.
Programmers are pros at breaking down complex scenarios into small programmable chunks; ‘The Computers’! – What can be a better example to support that statement! Can you imagine, the computers do all their work with just 0 & 1, the binary numbers and some operations on these, like OR, AND, NOR, NAND, NOT, XOR and XNOR! On the other hand, testers are experts in finding complex scenarios, where they can probably uncover a glitch to break the system!
Thus, the million justifications, silent cursing, and muted murmurs before finally reaching “The end product”! Though these are the situations, the product keeps gaining value from the combined efforts of programmers and testers. And that is how self-resistant codes are born; after all, testers care for their end product, you see! And it’s for developers to realize how their application can flunk in million ways, any time!

Developers with Testers- the perfect wedding!
Though organizations often make efforts to improve the communication between developers and testers, this is often not enough. If only their thoughts cross these barriers and start thinking somewhat within the same boundaries, can we expect super conflict-free Apps! (Pun intended)
It’s always a good idea for programmers to sit through some training/seminars that test engineers attend. A Developer who has attended such seminars is found to avoid making silly (yet common) errors and is often more vigilant. Moreover, a programmer’s awareness of testing tools, methods and processes goes a long way in enabling smooth and fast testing practices. He learns to stand in tester’s shoes while writing codes, to understand what in his code can probably be a tester’s target, what changes he makes will give testers a tough time and what makes it easy, thus making the entire process productive. For instance, any coder might not find it an issue to change a button label from, say, “Clear” to Reset”, but a developer who has sat through the testers’ seminar/ training can probably understand why this silly button label change affects the testing and how it can be frustrating to his colleagues in Testing.
The developer can thus create applications keeping in mind the worst cases that his code can go through, or gets tested in. He will eventually learn to make discipline around testing (or breaking) his own creation- his own code, which indeed makes him a better programmer. So an out of the box thinking is always good! Also, testers need to understand that everything changes with time, and so are the cases with software development too. It doesn’t make sense to change/ rebuild the code every time there’s a change, but the efficient solution is to encourage programmers to make wise changes in their code than to frequently change it.

One team- One goal
In hybrid agile development environment like ours, we handpick Engineers from departments, to form a dedicated team working together throughout the lifecycle of a particular project, with the single goal- the final release! I say ‘Engineers’ and not testers, designers or Business Analysts (BAs), because everyone in this team is a developer, and contributes to the development. This ensures that there are no separate groups (like developing group, testing group, BA, etc.) coming into play at various stages of developing a product, but a single team dedicated to every phase of the product development- from day 1, Sprint 0 to the Release of the End Product! This practice guarantees that the resources and their time are fully and efficiently utilized at every phase.
For instance, with the beginning of a new project, from day one, that is, the initial product backlog creation stage, you have a team in place, consisting of testers, QA experts, developers, UI designers, DBAs and analysts gathering at every SCRUM meetings, to discuss and contribute to everything they may not be directly involved in. Even before the development of the product starts, that is, at the programming estimation phase, testers start writing test cases, estimations etc. for features that will be developed, BAs do the requirement analysis and stuff, Developers plan and decide on features, and so on. At each SCRUM meeting, the team determines how it shall accomplish the work that needs to be done. This way, not only everyone has tasks throughout the sprint, but also knows and understands the roles, responsibilities, hard work and effort taken by each member. Thus, they learn to respect, understand and get on well together to work as a REAL POWERFUL TEAM!
Ultimately, we know the entire team has one single goal- “A Quality product”! It’s just that the developers and testers take entirely different paths to get there, just as in the much-admired Love stories!

Several statistics prove that almost 75% of website users judge the efficiency and credibility of a company by its website design. That pretty much shows how important it is for a company to have a well-designed website. They are undoubtedly one of the main factors in improving business. However, it is also one of the most overlooked aspects of a business. Managers and Chief Executive Officers (CEOs), often do not spend much time on their company’s website. Even though they realize how important it is for their business, all they do is simply hand over the job to the designers and forget about it.

What people seldom notice is that there are a lot of misconceptions around how websites are built these days. Some of these can even cost the company their relation with designers when the final design is a mess and doesn’t attract people. In turn, the company might just lose its prospective clients.
Here are 5 of the most common misconceptions that companies should probably watch out while designing their website. And if you are a designer, these points will definitely teach you what not to do while working on your new project.

1. ‘Fancy is better’ – Most often client companies feel that their newly designed website is not good enough, or not worth their money when their designers submit a minimalistic design. The truth is that minimalism is actually the “in thing”. White spaces in websites are often considered to be the signs of a poorly designed website, but the fact is that users find such websites more appealing and beautiful. It is as a matter of fact, quite OK to have white spaces in a website as long as everything necessary has been included. Instead of including extravagant icons and elements, designers need to focus more on making websites simple and perceptive. Moreover, simple designs contribute to a lesser load time, which adds to the effectiveness, as most people tend to leave a web page if it does not load in 4 to 5 seconds.
2. ‘What the client likes is what the users will like’ – Most website designers, finalize on the design by taking into consideration the client’s preferences. However, what they like might not always seem appealing to the actual website users. Again, if the company finds a particular design not good enough, then the website as a whole is said to be of bad quality. This too is not good practice, because of the same reason – what the company likes might not be what the users like, and vice versa. Companies need to hire designers that do thorough market research and trust them in providing effective designs.
3. ‘Content just needs to have the keywords and can be recycled easily’ – The content of a website is supposed to have the right keywords. True. But these keywords shouldn’t be stuffed into the content for the sake of Search Engine Optimization (SEO). The content should be relevant, reliable, engaging and original. It should also contain the keywords. Also, most designers think it is ok to use already existing content, from the same website. That again is something that affects the credibility of a business. Whether it is from the same company’s website or from some other website, recycled content makes the users bored and also affects the search engine ranking.
4. ‘Mobile websites are not necessary’ – A lot of designers focus only on, or more on the desktop version of a website. This practice is no longer a wise move, especially today, when the world seems to be under the reign of smartphones. People need to focus on building mobile responsive websites instead, and make it possible for the users to access the site from anywhere in the world, regardless of the device. Several surveys show that over half of the website users are less likely to become customers of a company that doesn’t have a mobile site or if they have a poorly designed mobile site.
5. Bigger logos are better’ – Logos are meant to add brand value and help customers identify unique brands. They are not meant to fill web pages. Adding huge logos to a website, in the hope of being able to grab attention, is a big mistake. It is important to properly design the size of the various elements in a web page in order to make it appealing to users. Having the essential elements in a bigger font and the rest in a slightly smaller font is probably a good way to go.

A good website design is one that will not only be useful and attractive for the users but also conforms to SEO specifications. It will have relevant and original content and shall appear seamless on any mobile device. Companies need to hire designers who know all these and are well aware of the future trends in website design as well.
What other strange website design misconceptions have caught hold of your associates? Let us know in the comments below.