obvious, navigation methodology. Given that the whole point of user interfaces is to“elevate” information/knowledge about the underlying data/information on the server, web-designers 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.
Projects under the control of professional software managers would not likely commit to asignificant redesign of any software project without a clear specification on the part of themanagement, or client. If such a document exists for the re-design of the Palo Alto CityGovernment web-site, it does not seem to be referenced in the Splash Screen. Withoutsuch 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 CityManager made to NEVER start a large software project with adequate design documentsagain!It would also have been very helpful to have a menu tree as a part of the externaldocumentation for the site. The menu tree can be determined by “walking the tree”, butwhy should people have to do that, when the people in charge of the project could havemade this information available to all?
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 theexecution of the user’s input/requests. “Back-ends” tend to be more complicated, and ofteninterface to a database manager.This kind of “front-end”/”back-end” architecture also tends to reflect what we sometimescall a “client/server” architecture. This definition is very loose, but allows us to partitionthe responsibility of the code between different groups, if that proves beneficial. Thisability to partition large projects across different operating departments is convenient, butcan also result in a lot of “cohesiveness” across the product as a whole, unless there is astrong “product” manager who is able to determine that contributions of the variousoperating 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 meaningfulis not uniformly found throughout the site.