July 11, 2014
Teamstudio Build Manager is a tool for the comprehensive control of the movement of Notes database templates from one environment to another. It improves efficiency by automating the steps necessary to make a template ready for the next environment, and mitigates risk by ensuring all necessary steps are completed as specified, thus reducing the risk of human error. It assists with compliance to regulatory standards by ensuring the enforcement of segregation of roles, all at the push of a single button! Whether you’re an IBM Notes Administrator or Developer, it makes your life easier with one-click builds.
The Promotion Process
Build Manager allows you to create promotion path documents, which automatically create a template from your design database and promote it through the process to production.
The time to promote varies and is contingent upon the size of the design being promoted, and the network bandwidth. The promotion process starts with creating a backup copy of the existing code to be used as a rollback if the promotion fails.
A Technical Look at Teamstudio Build Manager
There are four .NSF components to Teamstudio Build Manager, an executable file, and a DLL file. The code is run from a Notes client, so only the database is installed on the server. The executable and DLL files are installed on each PC that’s being used for Build Manager for promotions. Build Manager users need to be able to write to the Notes and Notes/data folders. The four .NSF components include the following.
- The Build Manager Configuration Database is required and holds all configuration and build documents.
- The Template Registry Database is optional, stores all versions of code promoted out of development, and is the staging area for promotions to QA/UAT/TEST and production environments.
- The Workflow Approvals Database is optional and is used to configure approval workflows when approvals are needed to promote code to the next environment.
- The Agent Parameters Database is optional and is used for the run agent step that is described below. It takes information from the configuration documents and provides them as easy to access variables to be used in LotusScript agents as part of the build.
The actions you can automate using Build Manager are detailed below.
- Build Path: This step allows you to define the template registry the template will be stored in.
- Promotion Path: This step allows you to define where the template will be placed so the target application can have the design automatically refreshed/replaced.
- Make Version: Uses details from the CIAO! configuration document (if you have licensed a copy) to create new versions of the application.
- Design Audit: Uses Teamstudio Analyzer auditor (if you have licensed a copy) to search for design issues and report on them relative to failure thresholds.
- Search and Replace: Uses Teamstudio Configurator (if you have licensed a copy) to perform an automated search and replace on the target database to identify and change text in the promoted template.
- Database Properties: Automatically changes the following database properties: Title, Categories, Inherit From, Template Name, TemplateBuild.
- ACL: Automatically sets ACL properties and roles using values either defined in this step or derived from a Stored ACL.
- ACL Entry: Automatically adds ACL entries (people and/or groups) to existing ACLs.
- Copy Database: Automatically copies the target database to another location.
- Compile LotusScript: Automatically compiles all or specified LotusScript in the design.
- Element Properties: Automatically changes the following design element properties: Prohibit Design Refresh, Propagate Prohibition, Design Element Inheritance, Design Element Comment.
- Enable Agents: Automatically enables or disables the selected scheduled agents.
- Set Agent Server: Automatically sets the server on which the agent runs for the selected scheduled agent(s).
- Set Agent on Behalf of: Automatically sets the user the scheduled agent will run under.
- Refresh Design: Automatically refreshes/replaces the design of one or more databases. There is an option to ignore any prohibit flags in the database to be refreshed so you can ensure the design in the target is what passed testing.
- Run Agent: Automatically runs any agent in any database. This step allows for custom promotion processes that include steps not defined as standard in Build Manager.
- Sign Database: Automatically signs the database from a stored or attached ID. The options are the same as if using the Administration Client.
- Email Notification: Automatically sends an email to one or more individuals or groups when the build is successful.
These steps are configured to match your existing processes, so all of them may not be necessary. But using this tool is the perfect time to update your processes to be in line with environment best practices.
-John Coolidge, Technical Director
July 9, 2014
Today’s mobile marketplace is characterized by ceaseless innovations, rapid changes, and endless updates. It’s an explosive environment that requires mobile applications to be quickly delivered to users who have multiple demands ranging from various screen sizes, operating systems, bandwidths, device capabilities, and user experiences.
These characteristics present challenges for mobile developers, especially with today’s advances in handheld devices and mobile application frameworks: software that aides developers in creating mobile apps such as jQuery Mobile, Kendo UI, and Apache Flex. Each of the vast number of frameworks support varying versions of platforms such as iOS and Android, development languages such as Java and C++, and user interface features such as widgets and customization. Add to these decisions about whether the framework should support certain hardware features, be free or open source, support SDK or encryption, and whether it should support the mobile Web, hybrid, or native app architecture, or all of these, and it’s easy to see the challenges developers face.
Along with the framework decision, should developers use the wrong client architecture – the mobile Web app, the hybrid app, and the native app that differ significantly – it can lead to poor user experience and adoption. As a result, great care should be taken when choosing the appropriate mobile app architecture.
Here’s a breakdown of the three architectures and why you would or wouldn’t use each.
The Mobile Web Application Architecture
Apps using the mobile Web app architecture run on a mobile browser. The browser hosts the app’s presentation layer that’s created using HTML5. Because of this, the interface looks and behaves like a traditional website, but is designed for the mobile device.
The Hybrid Application Architecture
The hybrid app architecture addresses the mobile Web app architecture’s inability to access device sensors such as Bluetooth, GPS, accelerometers, and cameras. It also enables cross-platform support, building HTML5-based applications that run in the browser window, mimicking the look and feel of a native app.
With the hybrid app architecture, developers can reuse existing code with minimal tweaking, and there is access to all native features. Using the native components also results in a richer user experience. Some issues to consider include that the UI is the lowest common denominator between platforms, and performance varies between platforms.
The Native Application Architecture
With the native app architecture, the application is custom built for a targeted device’s operating system and its Application Programming Interfaces (APIs) and Software Development Kit (SDK). The developer can use standard Graphical User Interface (GUI) components from that platform’s SDK. As a result, users receive a richer overall experience, along with excellent performance, and native look and feel.
From a development standpoint, the native app architecture makes it possible to build complex, rich, responsive applications that supply excellent performance with no need for mobile programming skills. The native app architecture provides users with a high quality user experience and user interface design with very few slowness or lagging issues. However, the native app architecture may need installation, upgrading, and uninstallation, and it’s device and platform-specific. Additionally, some businesses have reported somewhat higher costs due to development time.
In conclusion, a mobile Web app architecture is appropriate for creating a simple mobile-optimized version of an existing website. The hybrid app architecture works well for business mobile applications and content applications, and apps with a basic user interface and functionality requirements. The native app architecture works well for applications that can’t compromise on the user experience or performance, and where cost savings and productivity gains from cross platform code sharing is not a goal. Which mobile app architecture is best depends on your specific needs. Considering the above benefits and issues will begin to point you in the direction that’s best suited for your company.
July 4, 2014
IBM Notes is easy to use and allows rapid application development, but very few organizations know how many applications are in place, where they are, or what they do. Further, changes to applications are made ad-hoc and many times directly in production with no accountability and no change management process.
The result of this lack of control is far-reaching, including:
- Lack of automated processes leading to errors and bottlenecks
- Poor end user satisfaction from the application
- Slow turn-around of change requests by development
- Costly downtime happens more often
- Difficulties in functioning as a development team with no version control system
- Disruptive, time-consuming, costly and labor intensive regulatory audits
- Lack of global visibility into security and auditing of ACL settings across the entire enterprise increases risk
This leads to wasted resources, wasted space, and wasted opportunity for business benefits. Ultimately, the potential ROI from Notes will not be achieved, which sadly has the effect of causing management to consider other platforms. However, given the cost of “rip and replace” strategies, the only sensible option is to establish a set of fresh policies for your IBM assets.
To effectively manage your IBM Notes infrastructure, you need to develop a strategy with policies, processes, and tools necessary to address your governance requirements. It’s important to consider the human element in managing these processes. You have to be able to track “effective” application access and have the ability to create an audit trail of application access and changes. Automation is the best way to implement control, deliver compliance, and to manage risk.
We’ve broken the process down into the five traditional areas of the application lifecycle: Requirements, Design, Development, Test, and Production. You begin by auditing your existing policies and practices in these areas. Only then can you consider how to implement Application Lifecycle Management (ALM) for Notes. The following information describes the five key areas you should be concerned about when it comes to managing your IBM Notes applications.
IBM Notes Requirements Policies
Requirements policies are those tasks that go into determining the needs or conditions for a new or altered application. Requirements can start out as just requests, which can come from almost anywhere across the organization. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for application design.
Design policies are where the technical blueprint of the system is created. This is done by designing the technical architecture, and choosing among the architectural designs of software, hardware, and infrastructure that will best suit the organization’s current and future needs. This includes designing the systems model, graphically creating a model from a graphical user interface (GUI), GUI screen design and databases, to placement of objects on the screen.
Development policies transform the design into a physical system by building the technical architecture, database and programs that will be used in the system.
Test policies provide processes for testing the developed system. Test conditions were created during the Design phase, and are conducted by comparing expected outcomes to actual outcomes. If these differ, a defect is generated and you have to back-track to the development stage.
Production policies address moving the applications to the users of the system. Training is provided to the users of the system prior to “going live”. These policies also include keeping the system up to date with changes in the organization and ensuring it meets the goals of the organization by building a Help Desk to support system users.
Understanding where your organization is with regard to these policies and practices is essential. It’s also necessary to understand how you might begin to implement an ALM framework using these policies within your IBM Notes environment.
All Notes professionals need to start somewhere. Whether you are at the start of your journey to change a simple existing set up or you are making sophisticated tweaks to a mature environment, understanding these application areas will help you grasp the steps needed to achieve effective governing of your Notes environment.
July 2, 2014
Having a documented business continuity plan is an essential part of planning and preparing for serious data breaches and unavoidable natural disasters. Fortunately, according to AT&T's 2012 Business Continuity Study, 86% of companies with revenues of at least $25 million have a business continuity plan in place. However, testing your plan is just as important as having a plan in the first place. In order for your business continuity plan to be effective, it must be tested. Whether your company conducts full-scale tests once a year or more frequently, the following best practices will help your drill run smoothly and will help you report positive results.
Have a BCM Plan
If your company falls under the 14% of those reported above who don’t have a Business Continuity Plan (BCP), this paragraph is for you. The first and most important way to pass your business continuity drill is to have a solid plan in the first place. Before your organization ever suffers a disaster, you must have put in the work to develop a business impact analysis and risk assessment, and shared your plan to necessary personnel. By having a researched and well-communicated plan, you will have taken the first step toward successfully passing your drill.
Test your BCP Frequently
According to Symantec, a shocking 22% of businesses never actually test their continuity plan, or only test it after an emergency takes place. Another 22% say they only test their plan once a year. Running a full-scale test once a year or more gives a business the opportunity to understand how their BCP will do in various crisis scenarios, and gives the BCM professionals the opportunity to address any problems encountered. Testing is the best way to ensure your business is ready for a disaster.
Communicate: “This is Only a Test”
As another important measure, it’s a best practice to label all drill materials clearly with a phrase like "This is only a test." It's important to do so to ensure that if any non-staff or unaffiliated parties accidentally get their hands on the material, they will be fully aware that a real disaster has not taken place.
Get All Hands on Deck
When you’re testing your business continuity plan, it's vital that everyone in the organization has a "hands on" experience. Since a disaster would affect everyone in the organization, everyone in the organization should understand what to do in the event of a disaster. The best way to ensure participation is to communicate the planned drill details and objectives to every department. This way, no one is left in the dark about the importance or significance of the test.
Hire Outside Help
If your company isn’t large enough to house a dedicated business continuity team, or if you need expertise in a specific area, it could be worth hiring an independent consultant or project manager to make sure the test process goes as smoothly as possible. Independent professionals can bring a wealth of industry best practices and methodologies, and can facilitate the drill for you. They can make suggestions based on what is best for your business in terms of things like BCM products and recovery sites, as well as steps to take after the drill is complete.
Incorporate a Mobile Solution
When the unexpected occurs, your company needs a business continuity plan that can be accessed quickly and easily so you can restore operations. Business continuity software brings BCM into the 21st century in such ways as providing a uniform look to your plan’s documents, universally applying personnel record updates, and generating reports, but a mobile solution takes BCM even further. With a mobile solution, you gain access to data anywhere, anytime, even when offline.
Undoubtedly, natural disasters, security breaches, and other catastrophic events will occur. Although that reality may be unavoidable, the repercussions of these events don’t have to be devastating. By exercising these best practices around your business continuity plan, you can ensure your organization will be able to continue operations after a worst-case scenario.
Watch a demo of our mobile BCM solution!
June 26, 2014
If you read our recent blog post on Dojo Mobile, you know that users are becoming less and less tied to their PC in the office and are turning to their mobile devices to access applications. There are a vast number of options Domino developers have to choose from when it comes to XPages mobile app development frameworks. While the previous post focused on Dojo Mobile, this post will explore a different option: the Unplugged XPages Mobile Controls.
A brief history
Throughout their development experiences, Rich Sharpe and Matt White looked at mobile app development frameworks such as the jQuery and Dojo Mobile Controls to see if they could use these frameworks for the mobile applications they wanted to create. In 2012 they came to the conclusion that there were too many issues with these, so they began creating their own set of controls.
Under the direction of Teamstudio, Rich Sharpe, Matt White, Mark Leusink, Jack Herbert, and various others created the Unplugged Mobile Controls as a set of open source development tools. The Controls are available on OpenNTF and are specifically designed for creating either Web or native mobile applications to run equally well in a mobile browser like Safari or Chrome, or on the Teamstudio Unplugged mobile application platform. There are currently 18 controls that include headers, footers, form viewers, and form editors, and the development team is always adding more.
How to use the Unplugged Controls
To use the Controls, download the latest release from OpenNTF that contains one template database (an NTF) and two sample applications (two NSFs) that you can use as a guide. Once downloaded, copy the required XPages, Custom Controls, and resources from the template database into your application database. Then, like any other XPages application, create a single custom control that will handle the layout. You’ll add two stylesheets to this control: Unplugged.css and font-awesome.css. Begin dragging and dropping controls from the Unplugged Controls set to the layout custom control you created, and customize the properties as you like. After you’ve configured the controls, save and preview the XPage. The application you create will work in mobile Web browsers, and on the Teamstudio Unplugged platform once synced with Unplugged devices. Detailed documentation is available on the GitHub site by Unplugged Controls version number.
The pros of the Unplugged Controls
If you’re an XPages developer, the Controls are written in a language you already understand. These Controls can create both simple and complex mobile apps very quickly with very little coding. Use of the Controls is not difficult, so you shouldn't need massive experience with mobile or Web development to be able to create an application.
When it comes to UI, you’ll see three themes right out of the box: Light, Dark, and iOS7. While these give you options, the Unplugged Restyler gives you even more flexibility. Use the Restyler website to create your own custom theme to easily match your corporate branding. User Experience is also crucial. Unlike the Dojo and jQuery Mobile Controls, the Unplugged Controls work well with both tablets and phones on both iOS and Android devices.
It’s also easy to add offline capability to applications by using the Teamstudio Unplugged platform. You can sync down Domino data to the device in an encrypted manner, then use it remotely when you don't have network connectivity.
The limitations of the Unplugged Controls
Unlike the Dojo Controls, the Unplugged Controls framework has to be added manually to Domino Designer. In order to use the Controls, you must manually copy and paste the custom controls, script libraries, and CSS and image files into your NSF inside Domino Designer.
At the moment, the project is very targeted toward XPages. You won’t be able to use the Unplugged Controls if you use other server technologies besides XPages.
Compared to other XPages mobile controls frameworks, the Unplugged Controls team is small and currently consists of two developers, one graphic designer, one tester, and one project manager. Despite its small size, the team actively pushes development updates for the Controls.
Whether or not the Unplugged Controls are your best option depends on the specific needs of your organization and the nature of your applications. A few other frameworks for creating XPages mobile Web applications include:
Stay tuned to this blog series on XPages mobile options for Domino developers for the next post on jQuery Mobile.
Read more about the Unplugged Controls at the GitHub website.
June 19, 2014
Undoubtedly, the growing number of IT security breaches is one of the top concerns of any business in the private or public sector. According to the Government Accountability Office, in 2013 there were more than 3,000 more information security incidents than in 2012. With the growing number of IT security breaches across every sector, IT Managers and business continuity employees alike should understand why breaches happen and how to prevent them.
What is a Security Breach?
A security breach can be defined as the unauthorized access of private services, data, networks, applications, or devices. Either insiders or outsiders gain access through the manipulation of an organization's security mechanisms. Also called security violations, breaches are an early stage of an attack by an intruder, hacker, or rogue application.
In the event that an organization's policies or procedures have been violated following a security breach, the organization must fall back on an effective disaster recovery plan in order for the business to recuperate quickly. Although a security breach can vary from low risk to highly critical, any security breach has the potential to damage an organization’s image and be extremely costly. In addition to outlining recovery steps, the best disaster recovery plan should include the following ways to prevent security breaches before they happen.
1. Educate your Employees
If you institute an effective security awareness training program, you can reduce the likelihood of using your disaster recovery plan. When you train the employees and stakeholders of your company, you educate them about how to recognize questionable behavior by those with malicious intentions. A training program will also help reduce simple mistakes employees make that can lead to security breaches.
2. Institute an Encryption Policy
While a tenth of laptops will eventually be stolen, it doesn't mean the data stored on the device has to be stolen as well. Instead, institute an encryption policy for employee laptops to protect the data stored on them. Moreover in today's age of BYOD, you should also institute the same policy on employee handheld devices, including any tablet or phone used for business.
3. Deploy an Intrusion Detection and Prevention System
Simply put, any device that has access to the Internet should be protected by a system that watches activity behind a firewall. While an intrusion detection system passively watches for suspicious behavior, an intrusion prevention system actively protects a device by initiating such activities as blocking an IP address. When you deploy intrusion detection and prevention, you add another layer between your data and the bad guys.
4. Prevent Drive-By Downloads
One of the most simple and common ways hackers cause security breaches is through drive-by downloads. Drive-by downloads are used by compromised or malicious websites to exploit your device when it accesses the site by installing spyware and viruses. Instead, help your employees from accessing certain sites that may contain drive-by downloads by educating them about what not to click on and by keeping software up to date.
5. Conduct Vulnerability Assessments Often
As a functioning contributor to your company’s disaster recovery plan, you should conduct regular IT vulnerability assessments. While most businesses perform assessments once a quarter, IT vulnerability assessments should be done much more often. To be effective, vulnerability scans must be conducted for all internal and external systems connected to the network.
6. Apply Patches Frequently
Even though most IT professionals are aware of patching, most fail to patch networks comprehensively. Allowing updates to run automatically isn't sufficient. Instead, you should consider patches for every operating system in your network, and pay special attention to third party applications.
7. Monitor Employees Showing Questionable Behavior
Although employees may aide in preventing an external attack, they could also pose a threat for an internal security breach. Utilizing a system where your compliance officer or HR person could replay or monitor the behavior of insiders can be invaluable. In addition, you can combine this system with a data loss prevention (DLP) technology as mentioned above, which can effectively block the content or data you don’t want to leave the network.
Having an effective disaster recovery plan that addresses IT security breaches is essential. At the same time, you must take the appropriate steps to prevent the violation of your IT security policy. Using strong passwords, a trustworthy firewall and anti-virus software, and the above tips are all key to preventing a breach. Are there any we missed? Let us know in the comments section below.
June 17, 2014
One of the key things we’ve learned over and over again when developing a mobile app is that performance is one of the most important aspects. If an app doesn’t perform well, users simply won’t use it. Performance can mean different things for different people, but for the purposes of this article, performance refers to both how your mobile application is perceived by the user - the user experience, and real world statistics such as how quickly pages download. As with Domino applications, the best solution for good mobile application performance is actually spending time at the very beginning designing your application. Consider the following basic tips before you start writing code to fine-tune your application’s performance, and create an app that users will like to use.
1. Know your Audience
You need to understand what your users are going to be doing with your app, including whether they use phones or tablets, iOS or Android, or all of these. You also have to decide whether you’re going to offer an app that works offline. If you decide to offer offline support, you have to start looking at using HTML5 to do offline data caching, or start using a platform like Teamstudio Unplugged that supports native apps with offline access. Once this decision is made, you need to plan for a way to test your app after it’s built. Have multiple iOS and Android devices available so you can fully understand how the app will perform on each.
2. Know your Application
A mobile application doesn’t need to provide every bit of functionality that a desktop application provides, and there just isn’t room on a mobile device’s screen. You have to identify the key features you’re going to offer your users and make sure they’re the features that are available on your mobile app. Rationalize what data is being captured with the app and how much you expect users to type on a mobile device. One option is progressive disclosure, or disclosing information progressively in a wizard-style interface where you only present users with 3-4 fields at a time.
3. Weigh Initial Page Load Against In-app Performance
Decide whether initial page load time or in-app performance is more important for your users. If getting the app up and running quickly is important, you can always defer loading some things until later on as the user requires them. Or, if the user is willing to wait for the initial application to load, you can provide a much more snappy, responsive experience once the user is inside the app. One element that can help you with this balancing act is the choice to load pages via Ajax. jQuery Mobile, Dojo Mobile, and the Teamstudio Unplugged Mobile Controls all use the single page application framework. With these frameworks, pages are loaded via Ajax rather than doing full page loads, making performance appear faster.
4. Optimize your Code
When you’re trying to meet a deadline, it’s very easy to write code that just works but not spend time optimizing it. Because you spend a lot of time getting close to the code, it’s easy to overlook obvious things. Having a third party review your work can help catch mistakes, improve performance, and dramatically improve load times.
5. Define Specific Targets
From the outset of your project, define specifically what your targets are. It’s very easy to say “we want things to load fast,” but that’s not going to result in the best performance when you’re actually doing load testing at the end of the project. Instead, define, for example, that you’re going to test displaying 20 records on the screen against a database of 1000 records. Be specific. Understand load times for each specific device, and the network conditions your users are going to be operating with, whether they be Wi-Fi, 3G, or 4G.
All of these things can make an impact on the real-world and perceived performance of your mobile application. Putting time into your application’s design will be worth the effort and yield a high performance application that people enjoy using.
June 12, 2014
Your business has decided to enter the mobile application arena with a mobile business app, but is it beneficial to build an app that has the ability to work without a network connection? Mobile apps with offline capability solve significant problems that have plagued mobile computing.
How a Native Offline Mobile Solution Works
Native mobile applications act as an interface between a user and their files and data. Typically, a native app with offline capability stores both the mobile app software and app data locally on the mobile device. When the device is connected to the network, this locally stored data is synced with the main database on a remote server.
Freedom to Move Around
One of the biggest problems with traditional mobile apps is the need to have uninterrupted connectivity to the network in order to be used. This problem never presents itself in an office or home where a network connection is readily available, but anytime a user steps onto an airplane, into a hospital, or goes through the subway, an app without offline capability stops working. An offline mobile solution allows a user the ability to run the app regardless of network availability. Business apps that work when offline or when signal strength is weak are practical for many scenarios, including the on-the-go salesperson that would save time entering data into a CRM app while out of the office, or the business continuity manager who needs access to their business continuity plan after a natural disaster shuts down the network.
Ability to Develop Freely
Advanced HTML5 capabilities now give developers the freedom to choose whether they want their app to be a native app or mobile Web app without compromising on offline functionality. A mobile app built with the native application architecture not only allows for offline capabilities with generous storage limits, but also allows access to tools on the user's device. Because the app is installed directly onto the device rather than accessed over the Web, features such as the camera, GPS, user contacts, and notifications are available. A mobile offline solution built as a native app enables users to take and store pictures, access their contact information, and provide geographically targeted information. At the same time, mobile Web apps can also provide offline functionality thanks to browser caching and local storage, but are best for apps that don’t require lots of offline data storage.
Flexible Synchronization and Updates
Data transmission can be expensive, especially when the device user is roaming. Why should a user sync their data when nothing has changed in the database? An offline capable mobile app can be programmed to sync with remote data sources only when necessary. The app can also use new push technology to update itself when upgrades become available. The user doesn’t need to monitor these functions. The app can handle them automatically. This flexibility makes the app easier to use and reduces data transmission costs.
Even if your workforce spends the majority of their time in a place with a network connection, an offline mobile solution gives users the ability to stay productive when a network connection is poor or lost due to travel or unforeseen circumstances. A variety of different mobile business apps can benefit from offline functionality including CRM and business continuity systems, and note-taking apps. Along with the above, consider the individual possibilities an offline mobile solution can bring to your business. Leave a comment to let us know how you already take advantage of the offline functionality of your favorite mobile business apps.
Teamstudio Unplugged makes offline access easy. Learn more:
June 11, 2014
Earlier this week we released version 3.3 of the Unplugged Controls project on OpenNTF. We've added a couple of new controls that we hope will be very useful: the calendar and the alert.
The Calendar Control uses a very popular calendar plugin called Full Calendar, but wraps it up so that it works with XPages, and is very quick and easy for you to implement alongside the rest of the Unplugged Controls. The images below show a couple of screenshots of the calendar running on an iPhone and an iPad:
Calendar Control on an iPad
Calendar Control on an iPhone
As you can see, we adapt to the different screen sizes and display slightly different formats: full month on the tablet, week on the phone. But, as ever, we've made this configurable by you, the developer, so you can choose what the user will see without having to write any code yourself. The calendar also supports the opening of event documents, all day event, timed events, conditionally highlighted events, and many more settings.
The Alert Control, in contrast, is a lot simpler. We already had a dialog control, but the alert just takes that and makes it even simpler for when you just want to display a message to a user.
Alert Control on an iPad
Of course there are also a whole bunch of smaller changes and bug fixes. You can see the full release notes on the OpenNTF site, or for even more detail, you can see the actual issues on our Github project.
Take the Unplugged Controls for a spin.
June 4, 2014
Every mobile enterprise should have a plan mapped out for mobile technology that complements their overall business strategy. Why is a mobile strategy necessary? The smartphone market is continuing to grow and many companies are accepting the reality that apps provide business benefits, both internally for their employees and externally for their customers. These benefits include significantly increased productivity, improved data accuracy, better customer service, and convenience.
However, these benefits don’t come without challenges. Enterprises must determine how to overcome the following common challenges in order to achieve enterprise mobility in its most productive form.
1. Endless updates
Our mobile market is still in its infancy. This means ceaseless innovations bring on new mobile devices and required operating systems upgrades on a regular basis. Apple, Google, and Microsoft continue releasing updates multiple times a year. Although innovation advances technology, these rapid changes put strenuous demands on IT departments and developers and require them to prioritize projects.
2. A fragmented device market
The mobile market remains highly fragmented. In addition to multiple versions of every operating system, some people still own older phones because they only need a device with limited features like SMS. This, along with various screen sizes and a greater number of devices overall, creates a challenge for IT departments faced with expanding a mobile enterprise.
3. Which application architecture to use
Once a company decides to build an app for their mobile enterprise, developers are faced with the decision of whether to build an app that runs natively on the device, the mobile Web browser, or a combination of the two. The answer for which application architecture is best depends on the needs of the user. Frequent users of apps who require lots of data will want a native app experience, which tends to be expensive to develop. The Web browser will remain as a fallback for users with the more occasional need. Tip: With any app architecture, the app has to look good, perform well, and be easy to use. Users have zero patience for figuring out a poorly designed app.
4. User security and user interfacing
Like with Cloud computing, the main concern for mobile adoption is security. Addressing security adds another layer of complexity to developing mobile apps because it’s costly. Mobile banking developers report security-related issues drive development costs up three or four times compared to apps that have less sensitive data. If last year’s numerous high-profile security breaches are any indication of the future, IT security is a warranted concern and should be a priority.
5. Connectivity for enterprise software like CRM
A primary opportunity for internal mobile usage in a mobile enterprise is the ability to make day-to-day business activity easier with a mobile app. However, many companies find it difficult to translate enterprise software, such as a CRM system, into a mobile app. Some CRM enterprise software solutions lack the functionality for communication with mobile apps, but mobile CRM software exists, and the convenience it provides is worth the effort.
6. Deficiencies in developer skills
Despite the prevalence of mobile apps, there’s still a lack of developer availability in the mobile market, making mobile developers with the required skill-sets in high demand. The result of this scenario is that many businesses choose to outsource mobile application development rather than build a dedicated in-house team for meeting mobile enterprise needs. This could put added stress to an already tight IT budget.
7. Working with a limited or disconnected Internet signal
Mobile tools such as GPS, camera integration, and voice recognition capabilities are enabling users to work from almost anywhere while remaining just as, or even more, productive as when they’re in the office. This work-from-anywhere reality has resulted in users requiring reliable access to real-time data when they’re on the move. For some mobile apps that don’t work in a limited or disconnected state, this could be troublesome. However, offline capable mobile app technology does exist and should be considered in a mobile strategy.
Regardless of how you choose to approach your mobile strategy, the benefits of mobile technology are undeniable. The solutions to these challenges will be different for every company, but they are within reach. What mobile enterprise challenges are you facing? Leave us a comment below.