I have a couple questions that were submitted to me by one of our users.  These have to do with the way the Web screens are displayed and filled.  I thought I would come to this forum first, rather than enter a Support Case, to see if anyone has an idea to resolve these issues.

Let me make sure I understand your first question - you're saying that you open an item detail window while the main window is still loading, then focus is changed back to the main window until the load is complete at which point focus is set back to the detail window.  And you suspect the remaining page load in the main window is due to image files on the page?  You might want to open a support case on this one.  The main page itself is genearlly pretty lean - there aren't a lot of graphics to draw, so the biggest performance issue would be the amount of data being returned and your connection speed/network traffic.  Either way, I wouldn't expect it to change focus in this manner.

As for the popup window, there currently is not way to alter the reuse of an existing window.  This avoids opening a bunch of windows that get pushed to the background and never closed or saved if in edit mode.  However, please submit a product enhancement suggestion if this is something you'd like considered for modification.

I have experienced the situation described by the original poster.  The timesheet's little red, yellow or green icon and the adjacent "balloon" icon seem to be the last part of the page that struggles to paint.  At least that's what it appears to be doing... 

I did run my timesheet page though Fiddler (an http analysis tool).  Of about 822,000 bytes received, only 1% (about 8,700) were related to graphics (i.e icons).  However, Fiddler did reveal that none of these icons are cached.  It's a no-brainer that these items should be cached so I'm wondering if the Daptiv web server management folks are either unaware that caching is available for these items (seems unlikely) or if there's some underlying reason (session architecture?) why it can't be used.

If you feel adventurous, you might check your browser settings to see how caching is configured locally:  On the Tools menu, select Internet Options.  On the General tab, click the Settings button in the Temporary Internet Files group.  If Automatically is not selected, you might try selecting it to see if this alleviates the situation.  Make sure you allocate a couple hundred MB for your page cache via the slider at the bottom of the dialog. 

Remember, this will affect all you browser sessions so if you start seeing general wierdness, you may wish to revert back to your old setting.  As I mentioned above, this behavior should be controlled on the server-side (i.e. Daptiv) so you may want to get their opinion on this.

Good luck.

\cbf 

Sorry for the delay in response.  Our problem is particularly with pop-up windows, such as those for Task or Issue entry/editing.  The window opens and displays all the fields for entry and a cursor appears in the first field.  However, the screen is not done painting.  If you begin entering a value into the field, the first portion of the entry is taken, but you are likely to suddenly be typing for no purpose, because the screen has been reset and none of your most-recent keystrokes have been recognized. 

I have now learned to watch the status bar at the bottom of the screen to wait until ALL the "items remaining" have been loaded and the green-bar thermometer has filled and disappeared.  It happened on this very screen.  Two sets of "items remaining" have to load before anything I type in the Message area is accepted, even though the screen appears ready for entry immediately.

Thanks for the additional info!  If you haven't already, I recommend you open a support case for this so we can properly document and investigate what's going on with the page load in these cases.  It may be an annoyance at this point, but it may also be something we are able to remedy fairly easily.

The description from JGross@DIB is spot on.  I usually enter my task notes into Notepad and then update the appropriate Daptiv task at various intervals throughout the day.  My first instinct is to paste the text into the Update Notes listbox when it first appears - only to have the entry blown away as the page finishes rendering.  I have now learned to wait until the page has been loaded in its entirety.

I'll direct the following comment to Erik only because as he appears to be the only Daptiv employee in this thread:  I hope you don't take this as mean-spirited as it is not my intention but why is it OUR responsibility to open a support case?  I ask this question because there is overhead to having to open a support task - entry of the problem, conversation with the support rep, follow-up and maybe demonstration of the problem, etc. 

This is a Daptiv-sponsored forum and the title is "Product Feedback".  Clearly Daptiv folks, such as yourself, review it somewhat regularly.  Why then is the extra time and effort required?

\cbf

That's a fair question, one I can hopefully answer by giving some insight as to how we manage product issues:

When a customer contacts our support team, we are able to immediately evaluate the issue: is it a simple question or configuration issue that can be addressed right away, a known issue that has a workaround or fix timeline that can be communicated, or is it a new issue that requires investigation?

The community forums are a great way for people to bounce ideas and questions off other users and Daptiv employees, but are only intended for the first two kinds of issues.  If it's not a configuration question or workaround/fix that can be easily assessed and communicated in this medium, the issue needs to be properly documented and triaged by our support team so it can be escalated appropriately.

As you point out, this is a feedback forum.  It is not a support forum.  In this case, the assessment of the issue is that there may be something that requires additional investigation in order to arrive at a satisfactory resolution, and that is when a support case needs to be created.  The community is not the appropriate medium for this kind of interaction, which may include conversation with a support rep, follow up, and demonstration of the problem.  Once the support agent has conducted their due dilligence in assessing the problem, it is properly documented and escalated as appropriate.  If someone here were to open a support case on your behalf from this forum, you're still going to have to assist the support rep with the rest of the process, and there you're probably going to have to start from the beginning because they have some basic things they need to ask in order to understand the situation that simply can't be adequately captured or communicated here.

Finally, one of the things that helps us to prioritize fixes and enhancements is being able to quantify the potential impact of the feature.  One of the primary ways we are able to do this is pretty easy: how many support cases are related to the request?  When we plan our development cycles, this is one of the tools to help us figure what needs to be fixed or how to design new features.  While we might be able to mine the Community for enhancement ideas related to a functional area, it's simply not intended to track this kind of data.

The Community forums are a great way to share best practices, seek advice from other users or subject matter experts, and generally discuss the Daptiv application and related/supported processes and practices.  It is not the appropriate place to report defects or assess application issues, although that may result from a forum discussion.  Raising an application issue here can generate awareness, but it can't be managed via our established support/triage/development processes.

Hope that adequately answers your question - "Why is the extra time and effort required?"  We can't put in the time and effort required to fix something if we aren't able to verify what needs to be fixed, and the community forums is not intended to help us do that.

I have submitted it as an issue and look forward to the response.