Wednesday, February 23, 2005
IERI Utility
The change I made to the utility to allow multiple instances of the same enacted activity sequence (EAS) had a flaw. When a new EAS instance was added the utility wasn't associating the activities of that sequence correctly. Instead of associating the activities based on the EAS plus instance the processing script was associating them with the first EAS returned. The script has been updated so that the activities are associated correctly. I also went in and corrected the EASes KM had created before we discovered the problem.
Friday, February 18, 2005
IERI Utility
Created some screen shots for KM. Eight shots total of five different screens.
Made a modification to the utility so that multiple instances of a teacher/activity sequence could be made. KM needs this so that multiple testers can timecode the same enacted activity sequence (EAS) . The changes were fairly simple:
One final change ... I added a teacher filter to the EAS timecoding list. Previously, when an administrator accessed this list every available EAS was shown. The list could grow to unmanagable size quickly. The full list is still shown initially, but now the user has the ability to limit the list to the EASes for a specific teacher.
This feature is also available to less-priveledged users. However, the reason for the change does not have as serious an affect on these users.
Made a modification to the utility so that multiple instances of a teacher/activity sequence could be made. KM needs this so that multiple testers can timecode the same enacted activity sequence (EAS) . The changes were fairly simple:
- I modified the database to add a new field to store the instance number. The instance number is stored in the enSequence table in the field instance.
- I modified the processing script (process.asp) so that when a new activity is added it no longer checks for a previous instance. Now it counts the number of previous instances and adds a new one with an incremented instance value.
- I added a new column to the EAS timecoding listing table. The column displays the value of the instance field. An additional sort is done on this field so that the instances are displayed in order (1, 2, ...).
One final change ... I added a teacher filter to the EAS timecoding list. Previously, when an administrator accessed this list every available EAS was shown. The list could grow to unmanagable size quickly. The full list is still shown initially, but now the user has the ability to limit the list to the EASes for a specific teacher.
This feature is also available to less-priveledged users. However, the reason for the change does not have as serious an affect on these users.
Thursday, February 17, 2005
RSL:PD Online
I've completed all changes and updates to RSL:PD so that it can be posted to our Web site. In truth, it requires a great deal more work in order to really bring it up-to-date in regards to both content and code. Unfotunately the lack of time allocated pretty much required that the updates be kept to the bare necessities.
Some notes:
1) I was able to use search/replace to set up the templates, significantly reducing the amount of time required to templatize (is that a word) the entirety of RSL:PD. I have found, however, that using page-level templates on a project of this size can be a bit burdensome for development. While it eases development of common interface elements, every minor change requires each file to which the template has been applied to be checked out. Since DW doesn't have very intelligent check-in/check-out management (doesn't ignore non-checked-out items when checking in whole directories) it either expends too much time checking in files or requires too much work on the part of the end user to ensure that only check-out files are checked in.
A better method when dealing with common interface elements may be to use server-side includes (similar to the main Web site template). If any changes have to be made to these elements in the future then only the one item needs to be checked out.
2) Applying a template to a page removed all body attributes. This isn't in and of itself a major problem; some of the background images could present a readability problem and a number of the attributes for link and vlink colors were redundant with the norm. However, I had to go back and redo the Flash-based help and re-do the screen shots based on the modified pages.
3) Though the navigation is the top-level element in the body of every document it shifts slightly between some of the pages. I'm not sure why this is the case, but believe it may be do to the fact that I floated the container div rather than absolutely position it. More time permitting I may fix it, but the result is not serious enough to warrant immediate attention.
4) There were a number of bad links and missing files. The code quality was on par with what a beginning HTML coder might acheive (lots of overlapping tags). Apparently some grammar and spelling problems as well. A lot of the information could probably be discarded and much of it should be updated. I cringe at some of the interface choices, but I must also admit that it was created at a different time when different design options and challenges presented themselves. All considered, though, I have a hard time believing that this product ever went out the door.
Some notes:
1) I was able to use search/replace to set up the templates, significantly reducing the amount of time required to templatize (is that a word) the entirety of RSL:PD. I have found, however, that using page-level templates on a project of this size can be a bit burdensome for development. While it eases development of common interface elements, every minor change requires each file to which the template has been applied to be checked out. Since DW doesn't have very intelligent check-in/check-out management (doesn't ignore non-checked-out items when checking in whole directories) it either expends too much time checking in files or requires too much work on the part of the end user to ensure that only check-out files are checked in.
A better method when dealing with common interface elements may be to use server-side includes (similar to the main Web site template). If any changes have to be made to these elements in the future then only the one item needs to be checked out.
2) Applying a template to a page removed all body attributes. This isn't in and of itself a major problem; some of the background images could present a readability problem and a number of the attributes for link and vlink colors were redundant with the norm. However, I had to go back and redo the Flash-based help and re-do the screen shots based on the modified pages.
3) Though the navigation is the top-level element in the body of every document it shifts slightly between some of the pages. I'm not sure why this is the case, but believe it may be do to the fact that I floated the container div rather than absolutely position it. More time permitting I may fix it, but the result is not serious enough to warrant immediate attention.
4) There were a number of bad links and missing files. The code quality was on par with what a beginning HTML coder might acheive (lots of overlapping tags). Apparently some grammar and spelling problems as well. A lot of the information could probably be discarded and much of it should be updated. I cringe at some of the interface choices, but I must also admit that it was created at a different time when different design options and challenges presented themselves. All considered, though, I have a hard time believing that this product ever went out the door.
Thursday, February 10, 2005
Web Site Updates
Had a meetings with JBJ and FM about the future of the site. There's a lot that needs to be done. There are a number of problems: finding content can be difficult; documents need to have their titles, keywords, and desciptions updated; alternate language versions need to be improved; the coding of the site needs to be updated;
We're going to develop a site survey to try and get a feel for how people use the site and if they're able to find what they're looking for. I'm pretty ambivalent about surveys, and in the past they haven't proven to be very effective for us. JBJ suggested that maybe we could use a raffle to encourage people to complete the survey. I think that'll probably give us a little bump, but in the end we'll probably still not get very many responses.
JBJ and FM think that we can temporarily improve the ability of finding things by highlighting the AAAS search engine. It's a fairly simple solution to implement. The idea at this point is to develop a help page describing the search and how it works and also provide a few examples. This should be able to be implemented in a couple of weeks (after editing, etc.).
As I see it one of our biggest problems with the site is that we went through the effort to come up with this category structure, but then didn't take the time to fully develop it. As it stands we kind of say "we're working in this area ... here's a few links." This isn't sufficient at all and I had always hoped we would spend some more time developing the content for these categories. It looks like some people on staff are starting to think that the current navigation scheme isn't working and they want to try something else (probably partly due to the complaints of JR).
I don't really have a problem figuring out something new, but at this point I'd rather see us spend some time bringing our current scheme up to par. I feel it still has the ability to suit our and our visitors' needs. Plus moving to a new scheme will require as much, if not more, work than improving our current site. Either way I think I'm going to have to take a more active role in determining the future of our site. I think many of the problems we're having with the site could have been taken care of if I had taken the initiative rather than waiting for others to work on things. I've been too passive in implementation and allowed myself to get distracted by other projects.
I've got some ideas for an intermediate update to the site that should help somewhat with the general inability to find things. I'm going to go ahead and start working on developing the categories, filling them out as I think they need to be. One of the problems I see with the site right now is that it doesn't directly address what we're doing or the finding from our research. I'm going to spend some time filling in some of this information for one of the categories, then work with JBJ to refine the approach. I'll also need to adjust the directory structure and content location in that structure to better reflect it's relation to our research. Up until now I had been working towards more of a document type kind of organization, but I think a content organization will work better (though we'll probably still need indexes of doctype content).
Once that first category is finished I think it'll be easier to set up the rest of the site. This intermediate reorganization should help in development of a more useful site map for our content, which will provide another method of accessing information quickly.
I also need to spend some time figuring out how to improve the home page. The current page is, well, bland and confusing. Too much of the information falls "below the fold." And it really doesn't provide the user much direction or information.
A lot to think about, but it needs to be done and I haven't been doing my part. Nobody else has, either, but if I don't take the lead on something like this no one will.
We're going to develop a site survey to try and get a feel for how people use the site and if they're able to find what they're looking for. I'm pretty ambivalent about surveys, and in the past they haven't proven to be very effective for us. JBJ suggested that maybe we could use a raffle to encourage people to complete the survey. I think that'll probably give us a little bump, but in the end we'll probably still not get very many responses.
JBJ and FM think that we can temporarily improve the ability of finding things by highlighting the AAAS search engine. It's a fairly simple solution to implement. The idea at this point is to develop a help page describing the search and how it works and also provide a few examples. This should be able to be implemented in a couple of weeks (after editing, etc.).
As I see it one of our biggest problems with the site is that we went through the effort to come up with this category structure, but then didn't take the time to fully develop it. As it stands we kind of say "we're working in this area ... here's a few links." This isn't sufficient at all and I had always hoped we would spend some more time developing the content for these categories. It looks like some people on staff are starting to think that the current navigation scheme isn't working and they want to try something else (probably partly due to the complaints of JR).
I don't really have a problem figuring out something new, but at this point I'd rather see us spend some time bringing our current scheme up to par. I feel it still has the ability to suit our and our visitors' needs. Plus moving to a new scheme will require as much, if not more, work than improving our current site. Either way I think I'm going to have to take a more active role in determining the future of our site. I think many of the problems we're having with the site could have been taken care of if I had taken the initiative rather than waiting for others to work on things. I've been too passive in implementation and allowed myself to get distracted by other projects.
I've got some ideas for an intermediate update to the site that should help somewhat with the general inability to find things. I'm going to go ahead and start working on developing the categories, filling them out as I think they need to be. One of the problems I see with the site right now is that it doesn't directly address what we're doing or the finding from our research. I'm going to spend some time filling in some of this information for one of the categories, then work with JBJ to refine the approach. I'll also need to adjust the directory structure and content location in that structure to better reflect it's relation to our research. Up until now I had been working towards more of a document type kind of organization, but I think a content organization will work better (though we'll probably still need indexes of doctype content).
Once that first category is finished I think it'll be easier to set up the rest of the site. This intermediate reorganization should help in development of a more useful site map for our content, which will provide another method of accessing information quickly.
I also need to spend some time figuring out how to improve the home page. The current page is, well, bland and confusing. Too much of the information falls "below the fold." And it really doesn't provide the user much direction or information.
A lot to think about, but it needs to be done and I haven't been doing my part. Nobody else has, either, but if I don't take the lead on something like this no one will.
RSL:PD Online
I spent the past two days working on the tradebooks section. Initially we had thought to remove the ordering information, but decided after discussion that it would probably be worthwhile to update these pages to link directly to the Barnes&Noble Web site. I removed the intermediate page that lists all the books with a button combo for order/publisher. These buttons have been relocated to the book page and now link directly to the pertinent information. The benefit of linking directly to B&N is that we no longer need to track when books are out of print. B&N indicates this on the book info page and also provides the option to purchase used copies. I also linked to the B&N image of the book cover where available since B&N provides one that is significantly better than what we had on the CD-ROM.
This work was pretty tedious, but I think any improvement in the content of RSL:PD is worthwhile. It really needs to be completely redone and updated (for content and coding), but that's something we have neither the funding or desire to do.
Next I need to tackle the frameset used for navigation, etc. That will also be fairly tedious. But I'm hoping that I can simplify the process using templates and search/replace.
This work was pretty tedious, but I think any improvement in the content of RSL:PD is worthwhile. It really needs to be completely redone and updated (for content and coding), but that's something we have neither the funding or desire to do.
Next I need to tackle the frameset used for navigation, etc. That will also be fairly tedious. But I'm hoping that I can simplify the process using templates and search/replace.
Tuesday, February 08, 2005
Mass Mailing
I've finished modifying the mass mailer script in response to last week's error. Now, prior to generating the e-mail, the script checks all image references to internal objects within the HTML version of an e-mail. The script performs this check by searching for the following text: src="cid:. If the text is found the script returns an error.
I haven't done extensive testing, though the limited testing I did was successful. I'll know better whether or not this will work as I use the script in the future. For the next few e-mails I'll be double-checking the output to make sure no problems are encountered.
I haven't done extensive testing, though the limited testing I did was successful. I'll know better whether or not this will work as I use the script in the future. For the next few e-mails I'll be double-checking the output to make sure no problems are encountered.
Friday, February 04, 2005
Mass Mailing
2061 Connections was sent today. The list is up to 3634 recipients. Unfortunately there was a problem with the send. The internal reference for the header image in the HTML version of the e-mail was incorrect. I'm not entirely sure how it happened, I should probably spend some time figuring out what sequence of events will lead to such an occurrence.
It appears that if I send the document, use the browser's back button, and send the document again the attachment ID can change and thus the internal CID reference will be incorrect. I'm not sure if that's really how it's happening, though, because initial tests on the development server haven't yielded the same results.
Whether or not I spend time figuring out why this happened, I am going to spend some time modifying the code of the mail creation function to check all internal CID references against the attachment IDs to ensure they are valid.
Communications decided that the best course of action was to claim a technical error during transmission and resend the e-mail. Personally I think we'd be better off leaving well enough alone. People receive more than enough e-mail these days (valid or not) and don't need us pushing one more on them because we made a mistake.
It appears that if I send the document, use the browser's back button, and send the document again the attachment ID can change and thus the internal CID reference will be incorrect. I'm not sure if that's really how it's happening, though, because initial tests on the development server haven't yielded the same results.
Whether or not I spend time figuring out why this happened, I am going to spend some time modifying the code of the mail creation function to check all internal CID references against the attachment IDs to ensure they are valid.
Communications decided that the best course of action was to claim a technical error during transmission and resend the e-mail. Personally I think we'd be better off leaving well enough alone. People receive more than enough e-mail these days (valid or not) and don't need us pushing one more on them because we made a mistake.
404 Script
Found a problem with the 404 script in dealing with redirection. Not sure how long this problem has been dogging the script, but it pretty much broke the functionality. Basically, when the script parses the incoming URL it was starting in the wrong position of the URL string. I saw where I had made the mistake and corrected the script. It appears to be working fine now, but I'll need to keep an eye on it to make sure no further problems are encountered.
The sections of code dealing with determining where to begin when parsing the incoming URL had to be changed from:
The sections of code dealing with determining where to begin when parsing the incoming URL had to be changed from:
If Left(txtURI, 1) = "~" Then
intBegin = 1
Else
intBegin = InStr(8, txtURI, "/")
End IfIf Left(txtURI, 1) = "~" Then
intBegin = 2
ElseIf Left(txtURI, 4) = "http" Then
intBegin = InStr(8, txtURI, "/")
Else
intBegin = InStr(txtURI, "/")
End IfThursday, February 03, 2005
RSL:PD Online
I've completed modifications to the Flash demo files that are part of help documentation. Not the best Flash work I've ever done. A better plan would be to create the help from scratch. Of course, that would require a significant amount of time compared to the retrofit. Plus I don't have a lot of the original files (such as the narration) that would make such a project feasable. A few more modifications might have to be made, depending on what happens with the rest of the content.
One area that might prove particularly problematic with regard to the Flash representation is removing the frameset. I'll need to take a closer look at the files to determine exactly what we can/should do with the frames. I think it would be a good idea to remove the frames. They're not really used as best as they could be and could cause problems in some instances (such as search and direct linking).
One area that might prove particularly problematic with regard to the Flash representation is removing the frameset. I'll need to take a closer look at the files to determine exactly what we can/should do with the frames. I think it would be a good idea to remove the frames. They're not really used as best as they could be and could cause problems in some instances (such as search and direct linking).
Wednesday, February 02, 2005
HS Bio Textbook Report
In the process of documenting the project. It'll probably take me a few days longer than I expected, but I think it's worth it to start getting into the mindset where I provide this kind of information. I'd hate to be stuck with some of my current projects and have no documentation.
I ran across an oddity on a page that was getting a final edit. CT had made a change to the page and I was going back to clean it up and add one last item. Somehow the non-editable regions of the template were given inline styles that are only used by Contribute (the tech staff usually generally uses classes). The code in question was
I ran across an oddity on a page that was getting a final edit. CT had made a change to the page and I was going back to clean it up and add one last item. Somehow the non-editable regions of the template were given inline styles that are only used by Contribute (the tech staff usually generally uses classes). The code in question was
style="margin-bottom: 0em;". I'm a little unhappy that Contribute appears to have modified the non-editable region of a template. I haven't seen this anywhere else, though, so I can't say one way or another exactly how it happened. I'll just have to keep an eye on things to see if the problem crops up again.
Tuesday, February 01, 2005
IERI Utility
If a user accidentally adds a space before or after the name of the file when entering the movie information in the database it can cause the utility to not recognize the movie as valid. I've modified the scripts so that the movie file is trimmed prior to insertion in the database. It's also trimmed when pulled from the database for comparison. This should prevent any future problems.
Subscribe to:
Posts (Atom)