SVG Performance

There have been some complaints about the performance of our SVG-based apps (mostly from Mac users). I tried some basic things to see if I could tell where any kind of performance hit was coming from. First I tried an Atlas map that was simpler than the ones we've been using. This definitely made a difference in performance, but things were still not "speedy." Next I tried using some built-in SVG animation on the more complex map to see if it performed any better than scripting-based animation. It was not a pretty site with the normally "smooth" animation degrading to a jumpy, stuttery mess.

I've come to the decision that the main hinderance on performance is the SVG viewer itself. I don't know if the slowdown is due to the complexity of the maps produced by Illustrator or to the number of objects that have to be rendered. I'm working on producing a "cleaner" document in hopes that things will run a little smoother.

In the end, though, I think the calculations to produce and modify a complex vector-based graphic are too processor intensive with the current generation Adobe SVG viewer. Perhaps some better hooks into OS graphical subsystems would help, but that's certainly beyond my means. I'll be doing some research to determine if there are some document coding techniques that can be used to improve performance.

Scripting - form validation

I've made a decision regarding my automated form validation scripts. Previously I had set it up to not run server-side validation when client-side validation occurred. I'm reconsidering this decision, though. I've decided that the minor save in server load is not worth the potential problems caused by people circumventing both validations with little effort (at least for someone technically saavy). From now on I'll run both client and server-side validations.

At any rate, the real benefit to client-side validation is the immediate feedback provided to the user. On the applications and pages we produce server-based authentication barely registers a blip on server load thanks to low concurrent usage of pages that require it.

Components Prototype

FM wanted me to modify the components prototype so that each "tab" had a different color, tab mouseover/selected color change effect, and border around the content matching the selected tab's color. I had to make some modifications to the template to simplify the implementation. In the original the tabs were put in an editable region, which makes a mass change like this the same as if no template were used. I moved the tabs back to the templated region, removed some excess table code, and put the content in a div tag so that I could give it a border. I had originally thought of using template properties to select which tab should be selected, but I decided that it would be just as easy to use JS to do the job. I set up a script that checks the URL on page load and selects a tab based on the results of a search(). The "selected" state of the appropriate tab is set using the same Macromedia function that's used by the Dreamweaver "Navigation Bar" code. I modify the class of the div containing the content for the content border.

I'm using a dark shade for the mouseout state of tabs that are not selected. For tabs that are selected and for the mouseover state I'm using a light shade. This is the style we've used in past navigation. Looking at the result, however, I think I may have to change this. The non-selected tabs are too prominent, especially compared to the lighter shade used for the selected tab. I suspect this has to do with the fact that a different color is used for each tab. Taking this into consideration, I think it would work better to use a washed out color for the "unselected" state and a more saturated color for the "selected" state.

Update 2005-05-19:
Changed the color scheme as indcated above. I think it definitely looks better. The images could probably be even more washed out than they are now, but I'll wait for feedback.

Search help text

Had a meeting on Wednesday to discuss the site modifications, updates, and new content that's been in the works. One of the things that came out of the meeting is that there are people who are not aware enough of the site they're using to find the search box.

No doubt this is true. I don't doubt some people are incapable of "seeing" the search box, which is prominently located in the upper-left of the page. Personally I think we've done all we can. If someone is incapable of finding the search box even after it is described then they are probably also unlikely to understand how to perform a search at all.

The staff, however, felt that we should provide a bit more "direction" in conjunction with the description. Ideas were thrown around about how to do this, such as arrows popping up pointing in the direcition of the search tool. Or maybe a "guide" popping up and "leading" the user to the search tool. While these might have been interesting exercises in interactivity I think they'd prove to be of dubious value to the user.

As a compromise I set up a link that uses the ID as an anchor, focuses the input box, and flashes yellow behind the search tool. The ID as anchor and the flashing background only work for newer browsers. I did, however, make the input focus compatible with both new and old browsers (after initially ignoring those browsers, but that's not the way I should be coding). Hopefully those modifications will be sufficient to "highlight" the search.

Response.Redirect

I've been using the ASP Response.Redirect() function for a long while now without delving much into it's actual functionality. Recently I've been thinking about the various instances of where I've used the function and how it relates to page progression (particularly in web-based applications) and published HTTP standards.

Response.Redirect() produces a 302 HTTP status. Here's the relevant standard:

302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

This defines a 302 status as a temporary redirect. This is appropriate for many of the circumstances where I've used the redirect function. However, reading the range of possible 3xx status codes reveals others that are more appropriate in certain circumstances.

301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

This defines a 301 status as a permanent redirect, i.e. the page has been moved. This would probably be appropriate for my custom 404 script which redirects for certain URLs. It would probably also be a preferable response for search engine spiders, rather than the current 404.

303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

This defines a 303 status that indicates a response can be found at another page. Basically it tells the browser to fetch the indicated page automatically. The page that generates this status is not placed in the browser's history. I think this would be a better choice for web applications (such as IERI) than the Response.Redirect() function.

This response is new with HTTP 1.1, meaning that HTTP 1.0-compliant browsers will not treat this status in the way defined by the spec. Testing with Netscape Navigator 4.x bears out this fact. Rather than fetch the new page NN4 attempts to load the content. Body content redirecting to the new page is necessary for backwards compatibility.

The ASP to define a 3xx code other than that provided by Response.Reis as follows:

<%@ Language=VBScript %>

<%
Response.Status="3xx STATUS_MSG"
Response.AddHeader "Location", "NEW_LOCATION"
%>

<html>
<head>
<title>Object moved</title>
</head>
<body>
<h1>Object Moved</h1>
<p>This object may be found <a href="NEW_LOCATION">here</a>.</p>
</body>
</html>

Where 3xx is the status code, STATUS_MSG is the message, and NEW_LOCATION is the redirect URL.

Site reorganization II

A quick follow-up to my eariler post.

We've completed the help text for the AAAS search engine. I must admit I found the process of creating the text to be quite tedious. That's not to say that it wasn't worthwhile, though. Working with JBJ, who is probably the least technically inclined among the staff, proved to be most benefitial when refining the text. I believe we were able to produce something that is both clear and concise and will benefit our intended audience the most. I doubt I could have done as well with any other staff member. The combined talents of the techno-geek and the techno-novice appear to mesh fairly well for this type of project. As to whether or not we'll see any kind of return on the time investment is yet to be seen.

After a few meetings with JBJ and FM we decided to go ahead and make the page-level survey available on all pages rather than only a few, selected pages. The survey won't be presented every time a user loads a page, however, but randomly. We hope that random appearance of the survey will help prevent it from entering the user's "blind spot."

I'm controlling the appearance through a combination of cookies and javascript. SSI included files are not capable of setting a cookie, which is why I decided to use javascript. The only drawback to this method is that if the user does not have javascript enabled the survey will appear on every page.

I still need to go through and choose the pages that will not be included as part of the survey.

The site-level survey has changed little. The current thought is to link to it from the home page expando banner. I also provided a link from the page-level survey "thank you" message.

I'll need to spend part of this week documenting the survey code (my current policy for new development).

Checking the locks

There were quite a vulnerability exploit attempts on our server. Fortunately, the attempts failed for a number of reasons.

1. We do a fairly good job of maintaining the security of our server software and applications.
   
2. The attempts appeared to be the work of a worm that attacked a software program called ModernBill (which we do not use).
3. The exploit used a URL which, even if we had the application installed, would not have worked.
4. ModernBill is a PHP-based application and we do not have PHP installed.

All in all a pretty amateurish exploit attempt. I notified a few organizations from where the exploit attempts originated, but quickly realized that the source of the attempts seemed to be at ISPs and hosting companies that utilitzed the software. The likely response from the owner organizations (as determined based on either ARIN or domain regiatration) would be fairly innefective and I've all but given up on contacting larger companies.

Web Site Usage Analysis

One of the lines in the 2005/04/26 log file causes Webtreds to crash. Not sure why, but I've commented it out with a pound sign (#).

2005-04-26 15:18:19 200.201.0.30 - W3SVC12 PROJECT2061 198.151.218.130 80 GET /esp/tools/benchol/ch2/ch2.htm - 200 0 58973 582 0 HTTP/1.0 www.project2061.org Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+NT+4.0;+YComp+5.0.0.0) - http://www.google.com/search?hl=pt&q=tipos+de+problemas+matem%C3%A1ticos&btnG=Pesquisar&lr=

Mass Mailing

The Spring 2005 issue of 2061 Today was sent out Tuesday 3 May, 2005, at 4:33:17 PM EST to 1145 recipients.