One of the things that the Web Oversight Committee (WOC) decided we needed to work on is a redesign of the home page. The eternal question on our mind has been whether we need to target our audience that uses the site on a regular basis or cater more to those unfamiliar with 2061. With our limited working area it's really an either/or proposition. To complicate this decision, a number of our most vocal regulars seem incapable of using methods that could get them to the content they want quicker (bookmarking the exact pages/sections, searching, using the left-side navigation).
The survey we posted seems to indicate that we get a lot of return users. Or, I should say the people most likely to participate in the survey were return users. The survey (when considered along-side monthly usage statistics) also seems to indicate that our users visit the site at best once a month. Finally, most repondents seem to indicate that they liked our site they way it is.
Considering this data (which is not scientific by any means) I'm of the mind that we should continue to cater to new users on the home page. I think this tactic will help all our users (new & old) find the content they're seeking. The specific design of our top-level pages needs to be improved, but I think the category method we've chosen is a good way to guide users to the information they need. I think that by updating the home page interface while maintaining the current scheme, removing the "New & Popular" page by relocating content to the relevant category pages, and building out the category pages so that relevant content can actually be found would do a lot more for site usability than just changing the style of the home page.
The category pages present the biggest problem in our current setup. As I've mentioned before, we don't really do a good job of presenting information that relevant, useful, and important to our research on these pages. My current thinking is that we could use these pages to list a few groupings of information: a general overview, what projects we're working on, and relevant tools and findings. Project pages would provide a good place to link to project descriptions/proposals, findings, and relevant tools. A lot of the article pages on our site relate to specific projects, so I think we could link to these from the project pages as well.
I think that kind of redesign would greatly help our users. After that we could even start looking at a customizable home page again.
The WOC seems to think we can make the site better by "fixing" the home page. The fix we're now looking at is to stop using the categories and change the home page into something resembling the current "New & Popular" page. This, even after pointing out that we don't generate enough new content and that our regular users only visit once a month at best. I probably didn't help my case by helping recommend methods of generating "new" content more often. I don't really expect this will do much for our site traffic or usability.
I guess I never made my point strongly enough. I've always been too willing to let people have their own way (even if I think another way would be better for them). Beyond that, though, I think some people are paying too much attention to the proverbial (and clichéd) squeeky wheel. I don't think this is the solution we need.
So much else I could say (on how better content and better use of current content would improve site usability better than more links, on how site traffic has to be in the context of our content and users, on how it's better to address the underlaying problems with the site rather than shuffle the deck) but I'm running out of steam and my thoughts are starting to jumble. Besides, the course of action has been chosen.
I've got a mock-up ready and will hopefully get feedback early next week. I should have a working page in the next week or two.
Once that's done I'm going to return to working on the category pages. If those turn out the way I'm envisioning them I should be able to start talking again about catering to all users rather than those noisy ones.
Thursday, July 28, 2005
CCMS Web Site
There have been a number of content updates to the CCMS site the past few weeks. Once I make a little more progress on the 2061 site mini redesign I need to get together with communications and discuss how to improve the structural design and navigation of the CCMS site.
Productivity (or lack thereof)
I haven't been getting nearly as much done as I'd like lately. Not sure what's going on but I'm having trouble focusing on my work. Normally I wouldn't mention this on my work journal, but I'd have to say that right now I'm producing about 25% of what I should be able to produce in a normal week. And it's been going on for at least a month now.
I don't have a plan in mind to get back on track, but I'll need to figure out something. Next month I intend to start spending a lot more time working on the next version of IERI (no, really ... I mean it this time!). If I don't get my head back in the game I'm not going to get very far on that project.
I'm hoping my funk is a sleep and exercise problem. I'm need to work a little harder at getting to bed at a decent hour.
I don't have a plan in mind to get back on track, but I'll need to figure out something. Next month I intend to start spending a lot more time working on the next version of IERI (no, really ... I mean it this time!). If I don't get my head back in the game I'm not going to get very far on that project.
I'm hoping my funk is a sleep and exercise problem. I'm need to work a little harder at getting to bed at a decent hour.
Tuesday, July 12, 2005
Quotation/citation
I've come to realize that I have been mis-using the cite tag (i.e. for the title of a book that isn't actually being cited). The name of the tag itself leads to the obvious usage scenario and yet I've managed to mangle it. The structurally friendly method of marking up a title is, apparently, to use CSS (and I suppose a span tag). I find the span/css method to be somewhat unappealing, but I suppose if the W3C intended it to be that way then I guess I'll live with it.
My research into the cite tag has also led me to the blockquote tag. I've been wondering how the citation for a blockquote should be marked up. Apprently the correct method is to reference a URI in the cite attribute of the tag. I find this somewhat unappealing as well. Most browsers do nothing with the attribute, leaving no visual indicator of the source of a quotation. Obviously the citation is not part of the quote and so the cite should not be contained within the blockquote tag, but the natural relationship between the two is lost otherwise (at least structurally).
This also brings up the nature of the cite attribute. It should contain a URI referencing the source. Some of our sources are web-based, some are not. The URI set has subsets of URL and URN. The URL subset is well-known to me. The URN subset is not. Based on brief research the URN is a unique identifier maintained by discreet organizations (e.g. the ISBN). The URN appears to be preferable thanks to it's universal (i.e. web, print, multimedia) and persistent nature.
I've decided to mark up quotations in a way that is likely incorrect and redundant (at least for the time being). I'll use the q and blockquote tags along with the cite attribute, but I'll also include the cite tag inside the quotation for visual reference. I'd like to use URNs for the citation attribute, but may find it to be a bit difficult to implement at this point since most of our citations are papers. Also, URNs could be problematic since browsers don't currently have URN addressing capabilities.
Even if I stick with URLs, most of the pages on the P2061 site (and elsewhere for that matter) aren't permanently located. I sometimes wonder if I'll ever hit on the right structure. Since we're not likely to implement a CMS anytime soon I'd like to develop some kind of permalink setup using document IDs and a site scanning script that locates the current location of a document. This would allow permanent references.
At some point after I'm done correcting the document title and quotation/citation markup I'll go back and do further research on the quotation/citation question. In the end I'll probably remove the cite tag and use progressive enhancement (read JS) to implement a visual reference.
Source of information for this post:
My research into the cite tag has also led me to the blockquote tag. I've been wondering how the citation for a blockquote should be marked up. Apprently the correct method is to reference a URI in the cite attribute of the tag. I find this somewhat unappealing as well. Most browsers do nothing with the attribute, leaving no visual indicator of the source of a quotation. Obviously the citation is not part of the quote and so the cite should not be contained within the blockquote tag, but the natural relationship between the two is lost otherwise (at least structurally).
This also brings up the nature of the cite attribute. It should contain a URI referencing the source. Some of our sources are web-based, some are not. The URI set has subsets of URL and URN. The URL subset is well-known to me. The URN subset is not. Based on brief research the URN is a unique identifier maintained by discreet organizations (e.g. the ISBN). The URN appears to be preferable thanks to it's universal (i.e. web, print, multimedia) and persistent nature.
I've decided to mark up quotations in a way that is likely incorrect and redundant (at least for the time being). I'll use the q and blockquote tags along with the cite attribute, but I'll also include the cite tag inside the quotation for visual reference. I'd like to use URNs for the citation attribute, but may find it to be a bit difficult to implement at this point since most of our citations are papers. Also, URNs could be problematic since browsers don't currently have URN addressing capabilities.
Even if I stick with URLs, most of the pages on the P2061 site (and elsewhere for that matter) aren't permanently located. I sometimes wonder if I'll ever hit on the right structure. Since we're not likely to implement a CMS anytime soon I'd like to develop some kind of permalink setup using document IDs and a site scanning script that locates the current location of a document. This would allow permanent references.
At some point after I'm done correcting the document title and quotation/citation markup I'll go back and do further research on the quotation/citation question. In the end I'll probably remove the cite tag and use progressive enhancement (read JS) to implement a visual reference.
Source of information for this post:
Thursday, June 30, 2005
Intranet - File Search
FM wanted me to update the file search so that it was easier to use some of the advanced search capabilities like limiting the results based on file name, file location, and modification date. It took me a few days to work out all the details ... there doesn't seem to be quite as much useful information on Index Server (IS) as there are for other MS products (though I did find enough to help me work out what I needed to do).
First I modified the form so that new fields were available for the above-mentioned limiters. The fields are in a shContent div so that they aren't always shown. When the user clicks an "advanced options" link the new fields are shown. Second, I added some conditionals to the query builder so that the new fields are processed.
For the modification date fields I included a JavaScript date picker that I scarfed from http://www.howtocreate.co.uk/jslibs. I had to make a few changes to the script to get it to work more like I wanted. I think it looks pretty good, though it could definitely use some updating. Of course, some of the updates I have in mind could break it for Nav4. Not a problem in this particular instance, but perhaps a bit of a hassle for further usage.
There's a good amount of information stored in the IS catalog (beyond the content index) that can be searched using catalog field references. With this in mind I could have provided even more options for search parameters, but I didn't feel like taking the time to investigate what was available to search and what syntax would have to be used. The changes I've made are really just for FM anyway because nobody else (as far as I know) really uses the file search.
Index server provides a couple of different ways by which to search the information in the catalog. I used a single search method to make it easier to code and use. The file name and modification date are searched via catalog field reference (e.g.
The field search provides a lot of flexibility when used with wildcards. I've been having some trouble figuring out the various syntax options, but I think I'm starting to get a bit of a handle on things. Still, some of the syntax options throw me off a bit so I would need to do a bit more reading before I felt comfortable using them.
I think the search syntax would be good information to provide were I to develop some kind of help documentation. With that information the user could perform more advanced searches without me having to cook up more options. That's very low priority, though, and I don't expect to ever get something like that done. For the time being I've tried to use what I think are the most generic search parameters so that the user does not have to really know much about the search syntax in order to get useful results. No doubt I'll hear feedback if things don't really work out that way.
First I modified the form so that new fields were available for the above-mentioned limiters. The fields are in a shContent div so that they aren't always shown. When the user clicks an "advanced options" link the new fields are shown. Second, I added some conditionals to the query builder so that the new fields are processed.
For the modification date fields I included a JavaScript date picker that I scarfed from http://www.howtocreate.co.uk/jslibs. I had to make a few changes to the script to get it to work more like I wanted. I think it looks pretty good, though it could definitely use some updating. Of course, some of the updates I have in mind could break it for Nav4. Not a problem in this particular instance, but perhaps a bit of a hassle for further usage.
There's a good amount of information stored in the IS catalog (beyond the content index) that can be searched using catalog field references. With this in mind I could have provided even more options for search parameters, but I didn't feel like taking the time to investigate what was available to search and what syntax would have to be used. The changes I've made are really just for FM anyway because nobody else (as far as I know) really uses the file search.
Index server provides a couple of different ways by which to search the information in the catalog. I used a single search method to make it easier to code and use. The file name and modification date are searched via catalog field reference (e.g.
@filename index.htm and @write > 2005/06/01). The path is limited using the query utility's scope function rather than searching on the path field.The field search provides a lot of flexibility when used with wildcards. I've been having some trouble figuring out the various syntax options, but I think I'm starting to get a bit of a handle on things. Still, some of the syntax options throw me off a bit so I would need to do a bit more reading before I felt comfortable using them.
I think the search syntax would be good information to provide were I to develop some kind of help documentation. With that information the user could perform more advanced searches without me having to cook up more options. That's very low priority, though, and I don't expect to ever get something like that done. For the time being I've tried to use what I think are the most generic search parameters so that the user does not have to really know much about the search syntax in order to get useful results. No doubt I'll hear feedback if things don't really work out that way.
Wednesday, June 29, 2005
IERI Utility
KM was having a problem with some of the timecoding she had done disappearing. Luckily there was no need to panic about data loss this time. After our last major data loss I started a daily backup that maintains three months worth of database copies.
The source of the data loss was my own carelessness. When I implemented the sighting-level timecode inside the sightings summary table I copied a lot of the code from the acitivity-level process. In the activity-level process the code checks the timecoding against all activities in the sequence. If an activity does not have a numeric timecode then it is reset to null. The modified code for the sightings did the same. The problem is that when you're working on a particular activity, the sightings for the other activities are not represented. Since no timecoding was passed to the script for those other sightings it assumed they were supposed to be set to null. This is obviously not correct. I addressed the problem by limiting which sightings were reviewed to those in the current activity.
The source of the data loss was my own carelessness. When I implemented the sighting-level timecode inside the sightings summary table I copied a lot of the code from the acitivity-level process. In the activity-level process the code checks the timecoding against all activities in the sequence. If an activity does not have a numeric timecode then it is reset to null. The modified code for the sightings did the same. The problem is that when you're working on a particular activity, the sightings for the other activities are not represented. Since no timecoding was passed to the script for those other sightings it assumed they were supposed to be set to null. This is obviously not correct. I addressed the problem by limiting which sightings were reviewed to those in the current activity.
Wednesday, June 22, 2005
IE Border bug, again
Working on the Instructional Components Prototype I've run into yet another IE bug. This seems to be related to a bug I dealt with recently, but I don't know of a work-around. Then again, I didn't do as much research this time. The bug, in this particular instance, appears to occur when a block object with a border contains another block object with a negative margin set via CSS. IE appears to have trouble rendering the containing object correctly. The border appears to break and re-render.
Limited testing done with IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Code to produce the bug (see sample page):
Limited testing done with IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Code to produce the bug (see sample page):
<html>
<head>
<title>IE Border Bug</title>
</head>
<style>
.container {
border: 5px solid #000000;
padding: 10px;
}
.content {
margin: -5px;
}
</style>
<body>
<div class="container">
<p class="content">Questions</p>
<p>blah</p>
</div>
</body>
</html>
Subscribe to:
Posts (Atom)