Learning:Restore Focus after TextBox Automatic Postbacks

Restore Focus after TextBox Automatic Postbacks

Introduction

Postbacks triggered by a DropDownList or a Check Box are hardly noticeable. However it’s a different story when an UpdatePanel refreshes its content after a partial automatic postback. Specifically, two side-effects will occur. Loss of focus: None of the controls on the page will have the focus unless it is explicitly set in the server-side code. Loss of data: Any data changes made between the moment when the postback is triggered and the moment when the postback is finished are wiped out. For example, a user enters data in a Text Box and presses the Tab key to move to the next field and begins typing. Seconds later, the content in this text box disappears and the user is forced to reenter the data. In this article, I will show you how to save time and prevent the above scenario from happening.

Solution

The root cause of these issues is derived from the way an UpdatePanel is refreshed on partial postback. When an ASP.NET page receives the result of a partial postback, it clears out the current content on the UpdatePanel and resets the inner HTML to a newly received result. All of the DOM objects within the UpdatePanel are destroyed and recreated, resulting in the loss of focus and data. The best solution, of course, is to avoid postbacks in the first place. However, there are times when developers use postbacks for convenience instead of business logic. If the business logic of the postbacks requires no new data from database, (i.e., all information is already available on the client-side), then it can and should be handled with client-side JavaScript code. However, if new data is required, there is an alternative solution in PageMethods, which is used by Iron Speed Designer’s popup text and image. PageMethods sends to and receives from the server much less data than partial postbacks. They apply the results to existing DOM objects instead of destroying and recreating them, thus preserving the focus and data. If the two solutions above are not applicable to your page and postback is your only option, there is not much you can do to prevent data loss. The best you can do is to make the server process as fast as possible. However, you can prevent focus loss, or more precisely, restore focus with some JavaScript code.

Implementation

The following JavaScript code is modified from Yuriy Solodkyy’s blog.... Append it to the end of ~\ApplicationWebForm.js for existing projects. You may also append it to a code template in Iron Speed Designer’s installation folder here: \ProjectTemplates\vs200x\cs(vb)\ApplicationWebForm.js. This will ensure that changes are applied to future projects. JavaScript var lastFocusedControlId = ""; function focusHandler(e) {     document.activeElement = e.originalTarget; } function appInit() {     if (typeof (window.addEventListener) !== "undefined") {       window.addEventListener("focus", focusHandler, true);     }     Sys.WebForms.PageRequestManager.getInstance().add_pageLoading(pageLoadingHandler);     Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(pageLoadedHandler); } function pageLoadingHandler(sender, args) {     lastFocusedControlId = typeof (document.activeElement) === "undefined"                 ? "" : document.activeElement.id; } function focusControl(targetControl) {     if (Sys.Browser.agent === Sys.Browser.InternetExplorer) {       var focusTarget = targetControl;       if (focusTarget && (typeof (focusTarget.contentEditable) !== "undefined")) {         oldContentEditableSetting = focusTarget.contentEditable;         focusTarget.contentEditable = false;       }       else {         focusTarget = null; } try {           targetControl.focus();           } catch (err) {}       if (focusTarget) {         focusTarget.contentEditable = oldContentEditableSetting;       }     }     else {         targetControl.focus();     } } function pageLoadedHandler(sender, args) {     if (typeof (lastFocusedControlId) !== "undefined" && lastFocusedControlId != "") {       var newFocused = $get(lastFocusedControlId);         if (newFocused) {         focusControl(newFocused);         }     } } Next, in ~\App_Code\Shared\BaseApplicationPage.cs (vb), find the method Control_ClearControls_PreRender() and insert the commented code block “Register RestoreFocus.” C# protected void Control_ClearControls_PreRender(object sender, EventArgs e) {     this.ClearControlsFromSession();     // Register RestoreFocus     if(!IsPostBack)       ScriptManager.RegisterStartupScript(this, GetType(), "RestoreFocus",         "Sys.Application.add_init(appInit);", true); } VB .NET Protected Sub Control_ClearControls_PreRender(ByVal sender As Object, ByVal e As EventArgs) Me.ClearControlsFromSession()     ' Register RestoreFocus    If Not IsPostBack Then     ScriptManager.RegisterStartupScript(Me, [GetType](), "RestoreFocus", _         "Sys.Application.add_init(appInit);", True)    End If End Sub Now all pages will return the focus to the previous owner before postbacks.

Conclusion

Text Box automatic postbacks may cause loss of focus and data. The best solution is to avoid them. But if using automatic postbacks is necessary, try restoring focus with JavaScript code.

What Is ERP in 2010?

Introduction

When Gartner introduced the term "ERP" in 1990, it applied primarily to manufacturing, specifically the planning and management of the resources needed to produce particular goods. Today, however, every business decision maker realizes that his or her enterprise relies upon resources, and that planning is essential to optimize how those resources are acquired, allocated and used. This means that the definition of "ERP" is evolving and expanding to include multiple critical business functions. This dynamic has significant implications for every type and size of organization. Below, some observations and recommendations intended to aid navigation of this roiling evolution.

Analysis

"Another manager in my business asked me to define ERP today and I didn't really have a good answer for him," Focus contributor Patrick Mills posted recently to the Focus Finance Group. "How would you guys define ERP and what does it encompass?"
"The key word is 'enterprise' - software systems that can potentially address most, if not all, of the critical processes and functional areas in a company," replied Focus contributor Paul Sita. This varies, based on whether you are in manufacturing, distribution, services or other kinds of industry. But anything that can be considered [a true] ERP solution has to address the breadth of the organization. Most customers do not implement all that functionality, certainly not in the beginning. However, they grow into it, and the integrated nature of ERP systems, by definition, brings value to whatever sub-set of applications you do implement," Mr. Sita added.
However, Focus contributor Richard D. Cushing pointed out that reality often differs from the ideal. "Unfortunately, what I call 'traditional ERP' is often nothing more than an 'everything replacement project.' Enterprises of all sizes decide it's time to tear out their core systems and replace them with something that they believe - or have been told by their reseller or vendor - will make them faster, better or more efficient. Unfortunately, the results are often disappointing." Mr. Cushing added that "the new ERP" should focus on "'enhanced readiness for profit,' which is what companies doing traditional ERP are really looking for but all too frequently cannot find."
From a slightly more technically focused perspective, "ERP (formerly called MRP [for "manufacturing resource planning"] is about bringing standalone databases together," said Focus contributor Rick Rude. "From a financial perspective it would be bringing Accounting & Finance and pulling in Payroll," Mr. Rude offered as an example. "Historically, MRP was built for Manufacturing to track projects," Mr. Rude added.
Today, however, ERP embraces so much more than the tracking of manufacturing projects that many users have trouble deciding where ERP ends and related but different business functions begin. Among the most frequently mentioned of these other functions is CRM, according to Focus community members. Charlie Ellis, a member of the Focus Sales Group, recently asked, "If I buy an ERP system, do I have to purchase a separate CRM system? Is that [CRM] a module that can be included in an ERP system?
"These terms are becoming blurred so the answer depends upon which ERP or CRM system you buy," said Focus Expert Simon Gantley. "There are a lot of CRM systems that include a lot of ERP functionality, for example NetSuite, EnterpriseWizard and Siebel [which is now owned by Oracle]. There are also ERP systems with CRM modules such as SAP," Mr. Gantley added.
"Normally CRM is not included as part of ERP. An ERP system allows you to integrate engineering, customer service, planning, materials, manufacturing, finance, and human resources across a single facility or across multiple locations. However CRM systems help you track and manage your customer relations, said Focus contributor Betty Feng.
"CRM systems often provide 'pre-sales-to-order'-type capabilities to help land the sale/contract that then is processed and fulfilled in the ERP system modules," added Focus contributor Len Green. "CRM also can help with after sales service management and improved company-wide views of customer activity."
Beyond CRM, many decision-makers considering or pursuing ERP deployments seek guidance regarding specific ERP modules and features. For example, Focus Operations Group member and operations manager for a 250-person manufacturing company Todd Lang recently asked, "What are some top ERP modules to consider when buying?"
"The modules need to map directly to your needs and the solution that you purchase needs to allow you to unbundle unnecessary modules," affirmed Focus contributor Scott Priestley. "Understanding your quote-to-cash-flow [processes] is the first step" in making the right ERP feature, function and module choices, Mr. Priestley added. He then offered examples of specific questions Mr. Lang and any other decision-maker pursuing or considering ERP should ask before choosing a solution:

1. Do you need sophisticated financial integration between different businesses, locations, continents, etc?
2. How tightly is product design/engineering integrated into the quote-to-cash-flow [process]?
3. Is robust, integrated Quality/ISO functionality a requirement?
4. How do you do HR/Payroll?
5. Do you have a mature IT team that can support a modern system going forward?

Focus contributor Robert Israch offered some additional questions worth considering.

• Is sales, marketing, and support included or must [your ERP solution] be integrated with other applications?
• How do you manage customer renewals and up-sells?
• Do you have multiple locations and/or vendors/partners who need to access certain parts of the system and that you need to collaborate with across locations?
• Do you need access to the system 24/7 and from multiple locations and on the road?
• Would you like KPIs [key performance indicators] and dashboards built in to the applications? Should they be real-time?
• Do you want visibility across leads, sales, customer transactions, services issues, inventory, fulfillment, cash flow, payables and receivables, etc?
• Do you require having your systems managed on site or would you prefer to reduce software and hardware management and total cost of ownership by using a SaaS [software as a service] ERP vendor instead?"

 

Conclusion

Clearly, effective ERP solution selection and deployment relies heavily upon comprehensive assessment of specific business needs. This point was emphasized in the response to Mr. Lang's question offered by Focus Contributor Steve Christensen. "The first question would be why do you need an ERP [solution]? What systems do you currently use to track your business? What is missing in your business systems that lead you to consider a new ERP [system]? There are much more cost-effective, less disruptive and better systems [you can use] to run your business than going the route of a full ERP solution," Mr. Christensen said. He added that even SaaS-based ERP solutions can be "intolerably inflexible" in meeting business needs, if not chosen based on effective assessment and prioritization of those needs.
Clearly, ERP selection and deployment decisions can be daunting, and can have significant effects on how a business does business. Decision makers considering or pursuing ERP must begin by assessing specific business needs carefully, and ensuring that all candidate solutions and vendors are aligned with those needs. Such an approach can ease and speed the path to ERP success, while any other approach risks disappointment, inconsistent use and little or no business benefit. 

Ref: http://whitepapers.technologyevaluation.com

5 Steps to Successfully Conducting and Rating Software Demos

So, you’re the guy/gal who’s been put to the task of choosing your companies next enterprise software solution? Well, if you’re reading this, you’re most probably well on your way to choosing that software by now. You’ve made your proposal to your stakeholders; you’ve gathered your requirements and prioritized them; you’ve gotten a handful of software vendors to complete your RFI. So now what? Well, there’s still one very important step that needs to be taken: seeing the shortlisted products in action!
There are five important steps to successfully conducting and rating on-site software demos.
1.    It’s All in the Script: Developing a Demo Script
2.    Requesting a Product Demonstration
3.    Inviting Vendors On-site to Show Them Your Environment
4.    The Demo: Lights, Camera, Action!
5.    Rating the Demonstration, the Vendor, and the Product
General Information about On-site Demos
The on-site software demo is the ultimate opportunity for vendors to demonstrate the capabilities of their product(s) to potential clients—and let’s face it; one of the last things they’ll do to either make or break the deal (apart from the pricing proposal). A demo gives perspective software buyers—like you—a chance to see if your impression of what the vendor says it provides will hold true to its claims—and if the reality of those claims will be satisfactory for the needs you’ve outlined.
Vendors will demonstrate real-life scripted scenarios as described in your demonstration script and are usually presented over a span of several days (usually half a day to one full day per vendor).
#1 It’s All in the Script: Developing a Demo Script
Every great performance starts with a great script. A scripted demonstration is an essential part of your selection process, and providing vendors with your own unique demonstration script will help ensure that the vendor addresses every factor that is important to you, including

• the importance of a specific feature—relative to your business needs
• some of the risks involved in implementing their system
• the adaptability of their software to your changing business needs

The demo script should cover the following areas:

• company introduction
• system overview
• menus
• features
• system navigation
• customization capabilities
• report writer
• security features
• support
• and more…

If you request a demonstration but do not provide a script to follow, there’s no guarantee that the vendors will show you parallel functionality to compare. They may show you what they think are the most impressive features—which don’t necessarily cover the requirements that are most important to you. Ultimately, the demo script should be designed in such a way that enables vendors to show you how the software will increase your organization’s performance—in some visual and measurable way.
The script should be presented to only the top two or three vendors on your shortlist. Too many product demonstrations can lead to confusion—and leave your software selection team wondering which vendor had which features.
In order to give each vendor equal opportunity at the demonstration stage, it’s important to provide every vendor with the same detailed demonstration script. The script should be given to them at least 2 weeks prior to their scheduled demonstration date. This will allow them more than enough time to prepare.
Professionally written demonstration scripts can also be purchased online. They cover a variety of software systems and often focus on industry specific solutions. They provide an apples-to-apples comparison of criteria, which ensures consistency. A scoring system is already defined for you, which can save you time during the rating process.
#2 Requesting a Product Demonstration
To ensure the product demo goes as smoothly as possible, you’ll want to be sure that the shortlist of vendors are informed well in advance. The way to do is by

• sending them a letter requesting a product demonstration
• re-stating the scope of the software selection project and your business’ needs
• proposing a time frame for any requests for clarification of the script
• proposing a time frame for confirmations of demo with all pertinent details

Each vendor will be given the opportunity to clarify any terms that might seem ambiguous, or examples of business rules with your selection team prior to the demonstration.
Your selection team should not ask the vendor to customize the software any more than is necessary to demonstrate the real-life situations described in your scripted scenarios. However, to limit follow-up questions and subsequent demonstrations, each vendor should be encouraged to demonstrate all the items that you have listed.
#3 Inviting Vendors On-site to Show Them Your Environment
While it’s important for your company to see what a vendor’s product can do, it’s equally important for the vendor to know what type of environment it will be working with—if its software is chosen. Inviting vendors on-site to see your environment will give them a better understanding of what to prepare for the demo, as well as enable them to provide you with a more accurate proposal at the end.
This will also be the opportunity for the vendor to ask you specific questions about your current system, as well as the functional areas of the company. Having key staff present during these visits is recommended (thus, you may want to include staff from your IT department). Your public relations (PR) staff may also want to arrange a tour of the facilities so that the vendor can meet with the key users who will actually be using the system.
You have provided them with your demonstration script, and you’ve allowed them to see your environment. Now it’s up to them to wow you!
#4 The Demo: Lights, Camera, Action!
It’s show time! The time for the vendors to make their product(s) shine. Vendors often have very different ways of conducting their product demos. Some design theirs using PowerPoint slides with lots of bullet points and fancy fly-ins. They’ll often start by going over their company’s details, strategies, and future goals. Then, they’ll move on to discussing specific problems companies—like yours—may be having, and finally they’ll show you how their software can solve them all. Right!
This, my friend, is not a product demo. It’s a marketing piece—and it’s not showing you much of anything!
You shouldn’t have to endure a software demo. It should be conducted by the vendor in a way that makes it exciting for the audience. Using real data (preferably yours)—along with your demo script, the vendor must walk you through the demo like a finely crafted play. They’ll show you some fluff (they always do!), as well as a few of the cool and unique features. However, it’s important that they stick to your script. You’re the director, and they’re the actors—with a fine support cast (and a big bag of props!).
Crashes during the demo should be unacceptable. Think about it; if the software doesn’t work well in a demo environment, how’s it going to work in your real life environment? There may be a good reason why something went wrong during a demo; so don’t be afraid to ask.
You’ve put a lot of time and money into your software selection project already, so make sure that your selection team sees everything they need to during the on-site demo, in order to help you make an informed decision.
# 5 Rating the Demonstration, the Vendor, and the Product
Each person from your software selection team attending the on-site demo should participate in scoring the vendor’s scripted performance—for each factor demonstrated.
Breaking down the vendor’s demonstration into different sections (each of which represents a percentage of the overall evaluation score) will facilitate the scoring process.

• functionality or performance
• ease of use
• process and flow
• flexibility
• adherence to your script

The bidders are evaluated based on product functionality, ease of use, and process fit.
Product Functionality
The product functionality section is a list of features and functions for which the selection team would like a detailed product demonstration. Over and above these features and functions, vendors should provide a detailed description of the hardware, software, and networking configuration used during the demonstration.
Vendors should also provide a statement regarding the amount of effort and skills required to set up the demo as presented. Each member of the selection team should score the vendors’ script execution performance for each factor demonstrated. This can be done using a rating scale.
Sample rating scale


Ease of Use
For each process demonstrated, the selection team must rate the user friendliness of the software product.
Process Fit
Members of the selection team will rate the way they see the process demonstrated according to how it fits their business processes and whether that can be considered an improvement or not.
After all the demonstrations are completed, the scores from all members of the selection team will be consolidated as a single score for the performance of each vendor.
Conclusion
So, was it all that it was cracked up to be? Did the vendor’s performance and its product blow you away; or did they fail miserably? The fate of this sales opportunity now lies in the hands of you and your software selection team. Given all the information you have received from the vendor until now, including their RFI responses and the demo, are you confident that you can make a better informed decision about the software you want and need?

SOA technology changes integration

"We could have lived with one interface, but we really wanted about five different screens," Anderson said. "But the cost alone made us say, 'OK, we'll need to put up with whatever they produce for the first one.'"

Before settling, VP Buildings looked for alternatives and found New York-based iWay Software Inc. and its SOA middleware. IWay's enterprise service bus technology could expose PeopleSoft functions as Web services. VP Buildings had experience with SOA technology and Web services because it manages its sales and manufacturing activities using homegrown Microsoft .NET applications, Anderson explained. The team members decided to use iWay's technology for the project -- and discovered that the SOA technology offered more benefits than they had initially realized.
Solving old problems with new technology
The VP Buildings situation is not unusual, according to Steve Garone, an independent industry analyst who is currently establishing his own firm. Companies are increasingly turning to SOA technologies to solve classic application integration problems. A broad variety of tools and standards are emerging in the SOA market, Garone said, but vendors generally fall into three categories:

• Platform vendors, which are building SOA functions into broad platforms.
• Tools vendors, which focus specifically on SOA, Web services and enterprise service bus technology.
• Infrastructure vendors, which are building SOA and Web services functions into their technology suites.

Like many IT projects, the vendor choice depends on a company's specific requirements, goals and existing technology environment, Garone said. Solving a particular business or integration problem with Web services can be a good way for companies to jump-start the process of moving toward SOA technology. Getting started with SOA technology sooner rather than later may accelerate competitive advantages enabled by the architectural approach, he added. But companies need to think strategically.
"If you're going to migrate and grow the SOA presence in the organization up from that initial project, you need to take a global view of the breadth and variety of resources throughout your organization that are going to have to be integrated down the line," Garone said.
VP Buildings builds on its SOA
VP Buildings implemented iWay's SOA middleware, which exposes PeopleSoft functions as Web services to its .NET architecture. The team built the five new interfaces in a Microsoft Windows form business application, which uses the .NET architecture and iWay SOA middleware to write data to the PeopleSoft application. The entire process happens in near real time, with the customized interfaces designed exactly as VP Buildings wanted. They rolled out the new system in May.
"Now we have an interactive capability to query or supply data to PeopleSoft," Anderson said. "We'll do other things that we would have avoided in the past because they would have required a custom interface."

This article originally appeared on SearchDataManagement.com.

5 Best Practices for Ensuring a Smooth Software Implementation

You’ve gone through months (possibly years of preparation) and now you’re down to the final stages of your software implementation project. No matter how successfully you have executed the project to date, it can all fall apart if your service provider (software vendor or value added reseller [VAR]) can’t do its job properly!
As a stakeholder in charge of your company’s IT purchasing decisions, you’ll want to be sure that the service provider you choose will be the right one for your needs. It’s no secret that there’s a lot of time and money at stake in such an undertaking and you’ll want to do everything possible to ensure a smooth transition from your legacy system to your new system.
How will you manage change, resolve conflicts, and keep your implementation running as smoothly as your evaluation and selection? here are the five best practices that (I believe) will help ensure a successful and seamless implementation.
• Best Practice #1: Proper Planning
• Best Practice #2: Continuous Monitoring
• Best Practice #3: Updating your Stakeholder
• Best Practice #4: Preventing Scope Creep
• Best Practice #5: Negotiating Additional Products or Services

Software Implementation Best Practice #1: Proper Planning

Make sure that your implementation plan includes specific deliverables for each milestone, a clear definition of the scope of each step, and contingency plans that you can put into action should the schedule begin to slip. Remember, your implementation plan must extend beyond the go-live date. As the organization continues to change, the process must evolve with it.
Some areas of your implementation plan that need to be carefully thought out (but are not limited to) are:
• Data conversion: Conversion of data from the old software system to the new should begins early in the implementation process. Testing should be performed to ensure accurate data is transferred into the new system’s database. If inaccurate data is converted, the erroneous data may have a negative domino effect throughout the organization.
• Disruption of business: Even the most successful implementations can disrupt a company’s business and lead to a reduction in productivity that can temporarily affect the bottom line. Detailed project plans can also contribute to shorter implementation timeframes.
• Training: Every system user must be fully educated so they understand how the new system will be integrated into the overall company operation. All users must be trained to take full advantage of the system’s capabilities. Failure to educate and train all relevant personnel will guarantee implementation problems.

Software Implementation Best Practice #2 - Continuous Monitoring

Monitoring should be integrated into all stages of the implementation project. As the implementation progresses, a careful audit of each milestone will help you ensure that the service provider is providing all of the products and services specified in the contract, and the internal implementation team is performing as it should.
Failure to properly monitor the progress of the implementation can also lead to scope creep (see Best Practice #4)—among other things.

Software Implementation Best Practice #3 –Updating your Stakeholders

Your stakeholders have been part of the project since it first got off the ground (all those months ago), so don’t keep them in the dark at the implementation stage. Ensure that your project champions, subject matter experts (SMEs), and service provider work closely together throughout the implementation so that everyone is on the same page. A poorly managed and maintained project is often a factor in implementation failure. Communication is critical for its success. Audit each implementation milestone and provide detailed briefings and progress reports to your stakeholders on a regular basis.

Software Implementation Best Practice #4 - Preventing Scope Creep

If scope creep happens, it’s often because we’ve allowed it to. Tasks change, deliverables aren’t met, and before we know it, our go-live timeline is shot to hell. Sometimes, scope creep is inevitable, however; a project plan that provides a focused and well-defined scope, and includes the appropriate resources (both human and budgetary) will help keep your implementation project on track—reducing the risk of creep.

Software Implementation Best Practice #5 - Negotiating Additional Products or Services

Remember: The people involved in the original negotiations during a software selection are not the same people assigned to implementing it. Ideally, your goal should be to tie payments to the achievement of milestones in the implementation process, however; be prepared to negotiate the cost of additional products or services as the need arises. While most contracts state the obvious in terms of the license agreement, and ongoing support and maintenance requirements, they often say little about what service levels are to be met in order for the implementation to be considered complete. If you’re uncertain, have the service provider draw up a service level agreement (SLA) or statement of work (SOW) and attach it as an addendum to your contract.

ref:http://blog.technologyevaluation.com