P. 1
Review Of City of Palo Alto (CA) Version 3 Web-Site

Review Of City of Palo Alto (CA) Version 3 Web-Site

|Views: 18|Likes:
Published by wmartin46
Review of the City of Palo Alto (CA) Version 3 web-site Beta.
Review of the City of Palo Alto (CA) Version 3 web-site Beta.

More info:

Published by: wmartin46 on Jun 27, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

06/06/2013

pdf

text

original

James Keene Palo Alto City Manager 250 Hamilton Avenue Palo Alto, CA 94301 Cc: City Council Subject

: Review of Beta Web-site City Manager Keene: This document contains a brief review of the so-called “Beta” web-site. The previously submitted bugs/suggestions are included for completeness. Wayne Martin Palo Alto, CA ----Palo Alto Web Site Design Critique Overview Since WEB-sites tend to incorporate elements of art, engineering and “usability”, it can be a little daunting to critique a WEB-site without the design specifications for the original work. If no such specifications exist, then we are left with what is more likely-than-not something that might seem “ad-hoc”, rather than “well designed”. Web-sites are supposed to provide information, in one form or another to interested parties. This requires that the site actually have the information people might be looking for, and that all information/data is “findable”. For an entity like a City government, web-site design should start with constructing a data dictionary, at least for the most important five hundred, or so, items of information that people are likely to be looking for. This data dictionary should be organized, according to some scheme. One approach would be to use the City’s Org Chart as the backbone for the navigation scheme. Even if some other scheme is adopted for navigating the site, the City’s Org Chart should be readily available. Clearly, “findability” and site navigation are interlinked. Without a City-provided data dictionary, evaluating a web-site for a entity with perhaps several hundred “major” services and perhaps several thousand “minor” services/data, is almost impossible. There simply is no obvious way to determine what is missing. In the case of the Beta Web-site, there doesn’t seem to be any evidence of a specification, or a data dictionary, that is available to the public to use in evaluating the site. We just don’t know what the City was trying to accomplish with the new site that was not being accomplished by the older site. Web-sites should be attractive to the eye, not overly “busy” (seemingly “stuffed” with too much information making it difficult to find things easily), and have a rational, and

obvious, navigation methodology. Given that the whole point of user interfaces is to “elevate” information/knowledge about the underlying data/information on the server, webdesigners should always be involved in trying to put as much information on the screen as possible, while avoiding the problem of making the presentation too “busy”, or distracting. Unfortunately, these two missions are always in opposition with each other. Redesign Goals Projects under the control of professional software managers would not likely commit to a significant redesign of any software project without a clear specification on the part of the management, or client. If such a document exists for the re-design of the Palo Alto City Government web-site, it does not seem to be referenced in the Splash Screen. Without such a design document, it is not clear what the people doing the re-design were thinking, and hence, how close this effort came from its putative goals. If design documents for this re-design do exist, it was a mistake not to make them public, via the CMR process, or “hanging” them on the Beta web-site for people to review/vett. If design documents do not exist, this failure should be noted and a commitment by the City Manager made to NEVER start a large software project with adequate design documents again! It would also have been very helpful to have a menu tree as a part of the external documentation for the site. The menu tree can be determined by “walking the tree”, but why should people have to do that, when the people in charge of the project could have made this information available to all? Web-site Internals Most large pieces of software generally are divided up into a “front-end” and a “back-end”. The “front-end” deals with data input/validation, and the “back-end” deals with the execution of the user’s input/requests. “Back-ends” tend to be more complicated, and often interface to a database manager. This kind of “front-end”/”back-end” architecture also tends to reflect what we sometimes call a “client/server” architecture. This definition is very loose, but allows us to partition the responsibility of the code between different groups, if that proves beneficial. This ability to partition large projects across different operating departments is convenient, but can also result in a lot of “cohesiveness” across the product as a whole, unless there is a strong “product” manager who is able to determine that contributions of the various operating departments are not designed/coded well enough to provide a meaning user experience for the site as a whole. After staring at the V.3 web-site, and trying to use some of the “content” that has obviously been contributed by the operating departments, it’s clear that there are many “rough edges” in this product, and that the level of commitment to making the user experience meaningful is not uniformly found throughout the site.

This is another of those places where a written specification would help to establish the goals of the site, and to help evaluate each of the components. Main Menu System Evaluation The following is the current level-1 horizontal menu options: Top/Horizontal Menu Bar (Left To Right) Visiting Doing Business Government Services Community Partners I Want To This set of choices seems reasonable. Not certain how useful tying up valuable screen realestate for “Community Partners” might be; hopefully, there is hard statistical use data that justifies these choices. The “Government”, “Community Partners” and “I Want To” menu items are not dropdown menu selectors like the “Doing Business” and “Services” menu. These three use most of the top of the screen, using multiple columns, to display level-2 menu items. This approach increases the number of items that can be offered, although the approach tends to break the paradigm of single-column menu selectors that is typical of this sort of interface. This is not a big deal, but it is a little psychologically disconcerting because so much of the screen is utilized. The User has to spend more time finding an item, but there are more items to find. If one of the goals of this re-design were to increase the “findability” of various items of service offered by the Palo Alto Government, then perhaps that goal was achieved. However, it’s not clear that that change could not have been effected on the V.2 web-site. Left Side Vertical Menu Most Popular Building Permits Open City Hall City Agendas and Minutes Libraries Beta Feedback Bidding On Projects

This set of choices hopefully has some statistical use data to justify the use of this prime screen real-estate. For instance, it’s hard to believe that “Bidding on Projects” is one of the most popular web-pages accessed by the general public. Having this frame’s menu choices adaptable, based on individual use would make this screen real-estate more valuable to each individual users, rather than the seemingly odd set of choices selected. Top Level Second Level Bidding on Projects->Left Side Vertical Menu (EXPLORE) Departments Home Administrative Services Budget Financial Reporting Purchasing/Contracting Current Solicitations Vendor Registration While “Bidding on Projects” is no doubt important to some, budget data and Financial Reporting is also important—and has nothing to do, logically, with “Bidding”. Given that all of the items on the “EXPLORE” second level menu are legitimately under the purview of Administrative Services, it would seem logical to have “Administrative Service” as the top-level menu item, rather than “Bidding”. This current menuing is not rational. Inclusion of “Budget” should be a top-level item, due to its importance to the political process here in Palo Alto. My Palo Alto Phonebook Adaptable Menu Item Positions The current menu items seem fixed by the site designers. Other sites, like the Yahoo client offer people the option to customize the positions of the main menu selectors, based on each person’s use of the site. Given how many different users that a City Government site needs to accommodate, and how different these uses are, it would make sense to provide this same sort of adaptability for the residents/businesses of Palo Alto—allowing people to customize their own client menu organization. “Usability Index” When attempting to compare two web-sites it might pay to define some metrics for measuring “usability”. We might come up with something which measures the amount of work, or time, that it takes to find something, or a “basket of somethings”. Then, comparing these two numbers would provide us with a reasonable metric for attempting to evaluate just how effective a web-site might be.

Measuring the time it takes to find an item, the number of “clicks” to locate the item, the number of first-level and second-level menu items in the interface, and whether the item actually exists, or not, would be a simple way to compute such a “usability index”. Properly instrumented, the web-site could provide the hard numbers for this data. Short of the instrumentation, then an observer with a stopwatch and a clipboard would then be needed to collect this information. The City should make an effort to create a “basket of items” and then collect the data ten, or so, random people trying to use each of these web-sites. Having this sort of quantitative results would be helpful in coming to some conclusion as if the new web-site is “better”, or it is meeting its design goals, what ever they may be. It would also be interesting to measure the “usability index” when people are allow to customize the positions of menu items on their clients. Missing State-of-the-Art Capabilities Given that the “state-of-the-art” is a moving target, it is always a little difficult to identify a given set of features that, if present, boost a given product/web-site from being “just ordinary” to “state-of-the-art”. That said, it’s clear that the following capabilities that are found in most web-sites these days are missing: • • • • • Instant Messenger/Chat VoIP Video Chat e-Government Features Business Transactions  Scheduling  On-line Bill Paying  Digital Signatures On-going Project Status Video FAQs User Adaptable Menus Embedded Spelling Checkers Interface to Discus, Facebook and Twitter for logging comments.

• • • • •

In general, the failure to use multi-media on this web-site demonstrates a clear lack of understanding of the shifts in web-based information delivery going on in the world today. While the inclusion of video technology to the current, or Beta web-site would not be particularly difficult—it does take a shift in the mindset of what the City’s web-site should provide its citizens, businesses and visitors. Conclusion

Without the instrumentation to easily determine the “usability index” for the V.2 and V.3 City of Palo Alto web-sites, it is difficult to be quantitative in one’s analysis of the two sites, or to be completely objective in the evaluation of either. It is clear that there are more items in the fist-level and second-level menus of the V.3 site—which would doubtless increase the “findability” and “usability” of the items that are in the V.3 menus, and not in the V.2 menus. However, without doing a structured test, this point is only offered as one that is “qualitative”, rather than “quantitative”. Once one has identified and separated the menu system from the “content” portion of the web-site, it seems that the V.3 web-site is depending heavily on the content of the V.2 system—which means that unless there are significant changes in the V.3 content planned by the operating departments, the V.3 web-site is not really all that much different, or better, than the V.2 web-site. (A number of “bug reports” have been previous generated to point out some of these V.2 “deficiencies”. In short, there seems to be no commitment on the part of the City to move the web-site into something that other government agencies have been calling e-Government for over a decade now.) So .. after a less-than-comprehensive analysis of the V.3 re-design effort, it’s clear that the V.3 web-site is different--but it’s not clear that it embraces any of the capabilities of a state-of-the-art web-site. Different, Yes. Better, Not really. Which leaves us with the troubling question—why did the City spend so much time and money and not actually achieve anything that increases people’s productivity, and/or allows them access to more on-line government services? Whatever the goal of the V.3 redesign might have been, it can only be considered as marginally successful. And of course, that calls into question--who was in charge of this project, and will this project be the approach for future web-site modifications/re-designs? Content and on-line services are important—“navigation” .. not so much. The City needs to understand that key point. Wayne Martin Palo Alto, CA Problems Sent to City of Palo Alto during Review of its Beta Web-site 06.10.2012—06.xx.2012 ---Problem: Dead Links Located. Using “resolutions” as a search key, I was surprised that this generated a short page with links (presumably) to other web-pages where the Resolutions of the City Council could be found, presumably ordered in some intelligent fashion-http://beta.cityofpaloalto.org/gov/depts/clk/resolutions.asp

City of Palo Alto Resolutions How to use this pageClick on the link correlating to the desired Resolution timeframe and it will take you to that Master List of Resolutions. Each list contains the titles of Resolutions from: January 07, 1991 to May 17, 2010; June 14, 2010 to December 13, 2010; January 01, 2011 to June 27, 2011; July 01, 2011 to December 19, 2011; and January 03, 2012 to May 30, 2012. The Resolutions have been linked to the list, they have a red border around the title. When you click on the Resolution (with a red border) it will bring you directly to that particular Resolution. If you wish to search for a specific topic, go to the top to Edit, then Find, type in the word. As time permits, we will be linking additional lists of Resolutions. If you have any questions please contact the City Clerk’s office at (650) 329-2571 Last Updated: May 3, 2012 However, when the first link was selected, the following error message was generated: Oops! Google Chrome could not connect to copa-web-v1109.civicasoft.com:8080 Problem: Long Email Address Generates A 500-Internal Error. Creating an account with the following email address: 1@2.2222222222->end-of-field (hold down key for auto-fill to work) Will generate the following error (when the other fields are appropriately filled in): 500-Internal Server Error Problem: Long Passwords Generate Error Message Entering long Passwords by holding down any key until the field provided is filled to capacity for both Password fields generates the following error message: Password Mismatch Problem: Password Entry Allows Blanks

During Account creation, black characters (“ “) seem to be accepted by the field input handler. Strictly speaking, this is not an error, but it is suggested that blanks should be considered as illegal characters for Passwords, based on experience in the real world. Problem: Cityofpaloalto.org accepted as a valid domain name. Accounts can be created which have “cityofpaloalto.org” domain names. This is not a good idea, since anyone can highjack City employee names. Best to filter out “cityofpaloalto.org” domains from any but secured IP_ADDRs. Problem: No Bug Report Form. Every public access installation should provide a bug reporting form. The current form, which forces the user to respond to a bunch of meaningless questions that have nothing to do with bugs needs to be augmented with another form that just deals with bug reports. Problem: Bad Line Break In Dialog Box Text In the current Feedback form, when the form is submitted without all of the required fields completed, a dialog box pops up and provides a simple direction to the user as to how to resolve the problem keeping the form from be complete, so that it can be submitted. The text describing the Actions/Speed to compete form has a line break problem which results in the text being hard to read. This is a simple thing to fix. Problem: To/From Fields Run Together In “Contact Admin” Field. The users email address runs into the support email address in the “Contact Admin” Form. This presents a minor readability issue. Problem: Account Update Does Not Validate Telephone Numbers Junk Numbers Can be entered into the telephone number fields in the “Account Update” screen. Problem: Zip Code Not Updated After Initially Set In “Account Update” Screen. In the “Account Update” screen, if the zip code is set, and then subsequently modified, the modification does not seem to be saved. Example:

1) Zip Code initially Blank: Set to 94306 2) Save seems to work. 3) Update Zip Code by holding “1” key down until field seems full. 4) Save does not seem to work. Suggest that zip code fields should be validated for correctness, which may, or may not, be going on. The current behavior is just odd. Problem: Input Handler Not Diagnosing Errors in “Update Account” Form. There are inconsistent behaviors being demonstrated by the input handler for the “Update Account” form. For instance, if the “Address” field is filed with all “----“, this is not diagnosed as an error, but the characters seem to have been filtered by the input handler, since this field is empty when the form is open to verify the previous update. The filtering of invalid characters makes sense, but a diagnostic to warn the User than invalid characters have been entered also makes sense. Leaving the User having to figure out that he/she may, or may not, have entered invalid characters is not good human interface design. Problem: City Charter Not Available As Simple .doc/.pdf file. The City Charter is not available as a simple, standalone, searchable, document, in .doc and/or .pdf format. The Charter has been presented to the public in this “packaged” application for some time now. However, this is not desirable as much as a simple, standalone document—which can be downloaded. ---Problem: Meter Self-reporting Form Not Available. The form that allows people to report their utility meter readings is missing. ---Problem: Link To Video Archive Is Not Well Placed. The link to the Media Center, where the video recordings of the City Council can be found, is placed in a very odd place. Suggest that this link be moved to the top layer of “services”. The videos need to be seen as “digital records”, just like CMRs, or City Council minutes. ---Problem: Large Drop-Down Menus Closing Too Quickly. The large drop-down menus are closing too fast (for my tastes, anyway). It is nice that these menus open up smartly, presenting all of the options without having any partial

window/pane “painting” problems. But the trigger for closing this menus is just a little too sensitive. Sometimes I find I move the cursor just a little in the wrong direction, and the menu closes before I can move the cursor back, indicating that I want to travel in this window/pane. I also have a slight negative “psychological” reaction to all of this material’s disappearing as quickly as it does. I would prefer it to disappear a little more slowly. Suggestion: If there are any timing parameters associated with these menus, experiment with the timing, in say, 50 ms intervals. ---Problem: Greek Character Set In Shuttle Schedule Display. Crosstown Shuttle Schedule (effective March 7, 2011) For more information, contact the Transportation Division: Call: 650-329-2520 Email: shuttle@cityofpaloalto.org The word Crosstown is in Greek. ---Problem: No Site Visitation Stats Provided. It would be highly desirable to have a page of site visitation statistics. The public would like to know, for instance: How many visits per day, week, month, year Number of searches Number of searches producing results Location of Visitors (Palo Alto, CA, outside CA, etc.) Use of each page. Number of “clicks” per visit Average length of time per visit. And so on. While these stats may well be collected by the new web-site, this data should be made available to the public. ----“Contact Us” Form Not That Useful. The purpose of a City’s web-site should be to facilitate communications between the City and individual. The “Contact Us” form is not at all inviting to use, and provides little in the way of encouraging people to use it. The form size is somewhat too small, and there is no selector to indicate whether the person trying to contact the City wants a reply, or follow-up. There are no fields for people to provide their contact information. It seems

that this form is telling the user—“you can use it if you want, but don’t expect anyone to read it, or do anything about the information you are trying to convey to us. Suggest: This form to be redesigned to be more “inviting” and to provide user contact information, as well as giving the user the opportunity to receive some sort of a response. If this user contact information is available via the user profile, then the contact form should be filled in with this information, allowing the User to accept this information, or to change it, prior to sending his/her “contact us” information. Problem: Missing Content Form Is Inadequate: The Missing Content Form, associated with the Search function: http://beta.cityofpaloalto.org/iwantto/contact/content_request.asp is far too small. All of the comments associated with the “Contact Us” Form apply here. Suggest: Update all text input windows to a usable, common, template. -----Problem: Date Range For Calendar Should Stop At Last Year Where Actual Calendar Exists. If one uses the Calendar function, going backwards one year at a time, there are actual calendars for about the previous years. After that, the calendars are blank. Suggest: That the range of years be bounded to the years (going backwards in time) where actual calendar data exists. ----Problem: Pictures On Main Screen Need Labels. The pictures that are rotated on the main screen of the new web-site need labels. People who don’t live here won’t have any idea what these pictures are about, or why they have been chosen. Moreover, it’s not clear that the collection of pictures are at all reflective of Palo Alto, or its City Government. Suggest: 1) Label (in some way) all pictures used on this site. 2) Revisit the selection of pictures. ----Problem: Video of City Manager “Shoved” Off Front Screen Too Soon.

Currently, when the Beta web-site is launched, there seems to be a 3 minute video of the City Manager that is occupying the center of the main screen. This video is almost immediately “shoved” off the screen by the image slide show. The video and the slide show are not “compatible”. Suggest that the Video of the City Manager be moved somewhere, perhaps to a page that offers videos of other officials, and/or topics around Palo Alto. Suggest: 1) Move City Manager Video from current location and launch sequence. 2) Create a videos page, for this video, and possibly others, to be located. ----06.11 Problem: Web-site Needs A “Complaint Page” People routinely complain about poor service, non-service, and rudeness on the part of City employees on the local web-sites/blogs. Yet, there is no place that they can routine come to on the City’s web-site and file a complaint. They can use one of the “Contact Us” forms, but this is not the same as having actual complaints logged, and being (presumably) available for public records requests. Suggest: Adding a “Complaint Page” that is designed to facilitate communicating problems with City services, or the less-than-professional actions of City employees. ----Problem: Web Site Needs A Straightforward Incoming Email Log. While the incoming email is collected and distributed to the public via the weekly Council “Packet”, there is not easy way to access the incoming email from the public, to the Council, at the moment. The City of Menlo Park seems to “get it”, when it comes to offering the public access to incoming public emails to the Council/Government-Menlo Park Council E-Mail Log: http://ccin.menlopark.org:81/ There is no reason that this sort of minimal access can not be provided with a few programs/scripts that take email from the government’s email server and creating the coding necessary to create these web-pages without involving any staff time, save periodically checking to see that every is working correctly. (And even most of that work can be done by other programs/scripts). Suggest: Something like the Menlo Park Email Log be added to the Palo Alto Web-site. ----Problem: Web-site Has “Findability” Problems. Given that the City has a fairly large number of documents that could be made available to the public, via its web-site, there is a general “findability” problem with the current website. While there is (supposedly) Google search engine at work on this web-site, it is still

difficult to find things. There are several reasons for this—ranging from not having very many documents on-line, to the documents being comprised of non-searchable, scanned images. Additionally, the Google engine is really rather poorly designed, from a humaninterfaces point-of-view. Google spews out anything that matches the Users requested “search string”. There is no ordering, based on common sense, or human “best practices”. Google does not seem to understand the idea of “volumes”, or even time-sequences of documents that are linked, somehow, if not by being numbered volumes of the same set. This is where an intelligent “value added” web-site design helps to bring order to the partially-ordered universe of “Google-style” searches (fully inverted searches). What is needed is something akin to the “finding aids” that large research libraries have developed, over the years. While there is not specific format for these “aids”, one can start by suggesting that a good “finding aid” has all of the holdings in the archive, made accessible by something that includes a “table of contents” and a multi-level index, that one might find in a high-end reference book. The exact format of such a “finding aid” is open for discussion. However, it would be reasonable to expect that it would include all of the documents produced by the City, indexed by date, author, project number, document title, project title, and so on. The idea that one would have to know that a document exists in order to look at it is simply an inexcusable position for an enlightened government agency to be in, now that we find ourselves in the 21st Century. BTW—most of the code for the document inventory pages can be generated by programs/scripts, reducing the cost-to-the-taxpayer for providing this information. Suggest: The whole area of “findability” be visited by people who know something about document management, full access e-government, and automatic code generation. ----06.12 Problem: Facility Use Scheduling Should Be On-line. The following link points to a page where a link to a .pdf file which contains a form needed to schedule a playing field can be found: http://beta.cityofpaloalto.org/gov/depts/csd/facilities/default.asp While all of this seems OK, the reality is that this is not how state-of-the-art web-interfaces work. What is desired, it is suggested, is a schedule for each field that is available via the City’s Community Services program, which can be scheduled on-line. Fees should be payable via any of the popular electronic funds transfer mechanism. There is simply no reason that people should have to print out a form, and take it physically (or mail it) in order to schedule a field. This is what people did in the 1970s.

Suggest: This, and all other locations on the web-site where forms are offered to residents/businesses, should be replaced with on-line scheduling capabilities. ---Problem: P/W Project Map Better Labeling: The following link points to an “interactive map”, which supposedly offers interested parties the location of all construction projects going on in the city: http://www.cityofpaloalto.org/depts/pwd/street_work/default.asp It is rather difficult to understand what is going on, construction wise, from just looking at the map. There is a clear lack of labeling, and/or “how to use” directions. At first glance, there is some evidence of some sort of construction project going on in South Palo Alto, but what/why/who is in charge is not obvious. After thinking about it for a bit, one might be inclined to put the Cursor on the red zone. At this point, a small box containing the word “Overlay” pops up. Clicking on this box, something perhaps best described as a “Project Description Record” appears. This record, in its own little box, seems to have most of the information needed to understand what this project is about, although the content of this project description could contain a little more information. The header of this “Project Description Record” is confusing. It may be missing a “:” separator. There are also bland data fields in this record. It would be best to never have blank fields, always providing an N/A for fields that are not relevant, or a TBD (To Be Determined) for fields awaiting data from the project engineer, or the outside contractor. The field name GID is not exactly clear. If this is some sort of project number, then it would be very nice to have this field linked to a project description, which would, hopefully, include the cost of the project. If the field name GID is not a project identifier, then some sort of legend is called for on the page, somewhere. Suggest: 1) Better labeling and clear use directions on this map, 2) Some increased information in the “Project Description Record” for each project. Problem: P/W Project Map Needs Update Date. The following link points to an “interactive map”, which supposedly offers interested parties the location of all construction projects going on in the city: http://www.cityofpaloalto.org/depts/pwd/street_work/default.asp This page needs a “page updated” field, so that users can understand how old this information might be. Suggest: Add “Page Updated” Field to this page (right frame at the bottom would be good) ------

Problem: No Instant Message Use Integrated In New Web Site. The Beta Web-site does not show any of the current state-of-the-art capabilities of the Internet. For instance, the following telephone assistance page from an HP customer support web-site shows that HP has integrated “chat windows” into their customer support: http://www8.hp.com/us/en/contact-hp/phone-assist.html On-line chat, and, VoIP, and video chat, are now generally accepted ways of increasing a company’s more-or-less instantaneous support to customers who might be “in a hurry” or who have very short questions that need not wait for a 8-12 hour turn around for email. It is difficult to understand why “Chat” is not being offered in this “revamp” of the “old” web-site. Suggest: Add “Chat” capabilities to appropriate locations in the areas where some sort of customer support is called for. ----Problem: Labels On Splash Screen Pictures Are Controlled By Cursor Position. It was previously reported that there are no labels on the slide-show pictures on the splashscreen. This is not actually true, as it turns out that if the Cursor is inside the window displaying the pictures, then labels pop up from the bottom of the window. While this behavior might not be totally “counter intuitive”, it is “not obvious”, to be sure. Making people figure out how the mechanics of the web-site displays work is not all that “friendly”. It is also very likely that unless someone is naturally curious, that he/she won’t take the time to investigate these mechanics, and the labeling (in this case) will simply be missed. Suggest: Adding labeling to the pictures, and removing the Cursor-position-sensitive behavior of the Slide Show on the Splash Screen. ------06.12.12 Problem: Web-site Needs Disclaimer That Documents On Site Not Certified. Some time back, a case involving a local “street person” made the news in a number of ways, including the somewhat amazing claim, made by an Assistant City Attorney, that documents found on the City’s web-site were “invalid” (or some such)-http://www.paloaltoonline.com/news/show_story.php?id=15315 Frost's attorneys presented copies of city staff documents, city manager's reports and transcripts of Palo Alto City Council meetings. The documents show the city's intent was to rid downtown of its homeless population, who often sat or lay on sidewalks outside stores,

the attorneys allege. Larkin said the documents amounted to hearsay and were invalid, since they were not certified as true copies from the city clerk. But Meghan Piano, Frost's other public defender, said she obtained the copies from the city's website. "This is a public website posted by a public agency," Piano said. At least some of the evidence was in PDF format, which does not allow any alteration, she said. ---If it is true, from a legal point-of-view, that no documents on the City’s web-site are valid for legal purposes, or for doing business with the City, then the public needs to be made aware of this fact, with a large message on the Splash Screen. If this Attorney’s claim is not true, then perhaps this issue should be dealt with in some way, with a message somewhere on the Site providing people confidence that the information on the site is valid, and will be accepted by the City for transacting business. Suggest: Some sort of statement about the validity of information on the City’s web-site be added to the site, somewhere that is not buried in the bowls of the site. ----Problem—Palo Alto Web-site Could Benefit From Test Automation. One of the problems submitted involved “dead links”. A representative of the organization responsible for this “content” contacted me claiming “we were unaware that these links were dead” (or words to that effect). This kind of answer suggests that the Palo Alto website is in dire need of site administration tools that can provide a reasonably quick detection of files that have gotten lost, or web-page changes that have been incorrectly coded. It would not be that difficult to code up a tool that would “read” (or parse) all of the .html/.xml files comprising the web-site, extracting the file names that provide the “content”, and then opening each of these files to determine if each file is present, and if it has changed since the last time the content archive was inventoried. Assuming that the number of files on the City’s web-site might be in the 100,000 to 500,000 at some point, this content inventory could be easily stored in a small MySQL data base, or the SAP data base management system, depending on IT department doctrine. It would even be possible for a tool set like the one being proposed to actually be able to “heal” certain kinds of damage, such as accidental removal of files by someone not fully aware that the files are referenced by the City’s web-site. It would be possible to replace the missing files with a master copy from the document management system—alerting the content owner by email that something might be amiss in a section of the web-site under that department’s care. Suggest: Better Site Management tools be included in the scope of the V.3 web-site Administrator’s scope of responsibility.

-----

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->