follow up from 8/16 meeting

In case you need them here are the sites we looked at in yesterday's meeting:

columns with color coding shown within subsequent pages:

http://www.library.gsu.edu/

http://www.lib.berkeley.edu/

http://www.bloomingtonlibrary.org/

We'll plan to meet on Tuesday at 11:00 a.m.

Thanks!
Donna

Agile Development and New Website

Hi folks,

First of all, thanks to you all for your patience and input during our last Thursday (6/14)meeting. It was a bit stressful but I think we broke through a log jam w.r.t. understanding our priorities and goals for the website redesign.

Nick and I met with Jim Fudge on Friday (6/15) to dicuss agile development practices and project management in an agile environment. Jim was very helpful and both Nick and I came away from that meeting feeling much more optimistic.

With that said, here's the key points of our new approach using the new homepage or landing page as our first mini-project as part of the overall website redesign:

• identify our "customer" - Gina as library rep
• define the project to be completed - new homepage (single page) with links to existing internal pages.
• define the scope - include content links defined by Gina in a sustainable framework (CSS and DHTML)
• assign roles and responsibilities - Gina is customer rep who defines content for new homepage with input from staff and Nick and Alice are the programmers.
• deadline for public release - end of July
• create prototype of homepage to start design iterations - first prototype available to show Gina on July 5.
• refine prototype with iterations - 2 weeks
• add link on current homepage to new homepage to let patrons and staff try it out - 4th week of July
• general release - end of July

Once we've completed this mini-project of the new landing page then we'll define additional mini-projects (reference pages, events calendar, childrens pages, etc...), prioritize them and then work through the steps outlined above.

Our goal with this approach is to have many releases of mini-projects with lots of opportunity for iteration and feedback from staff and patrons.

Thanks, Alice

Dreamweaver Templates & Mock-ups

I have been playing around at Dreamweaver Templates. I have a question about the two views--Adobe Photoshop and HTML. Can you tell me what impact these differences have for us? Is it just that one shows a template created using Photoshop and the other using HTML and we can use both of these I'm assuming--it's just how they were created?

Events Calendar Issues

Hi folks,

It is very important that we make a decision regarding an on-line events calendaring system.

The current on-line calendar system requires a disproportionate amount of computer services staff time to maintain. I use the word "disproportionate" to reflect what we see on the usage statistics of the web site each month. Based on these stats, it is clear that more staff effort needs to be spent addressing issues related to the use of the webOpac and the on-line databases. These are by far the most heavily used areas of the web site.

So, what are our options for reducing computer services staff time spent on maintaining the on-line events calendar while also providing our patrons with an easy-to-use and informative on-line calendar AND accomodating the needs of staff content providers AND allowing for an edit and approval process for content?

There are currently three options being considered:
1. III Program Registration product
2. custom built on-line events calendar
3. customized 3rd party events calendar

III Program Registration
The III product can be viewed on the Westerville Public Library site or the Scottsdale Public Library site.

Advantages:
1. integrated with the catalog so searchable in the webOpac
2. registration options for limited space availability
3. conflict resolution of event locations
4. approval and editing capability of event content through a Millennium client
5. product maintenance through III
6. option to enter events far into the future
7. known cost for product and maintenance
8. adheres to microformats standards for harvesting and formatting events outside of catalog

Disadvantage:
1. III proprietary product that is constrained by their license agreement

Custom built on-line calendar
A custom built on-line calendar would look and behave similar to the Arts Resource calendaring system. It would use a SQL server database backend with a ColdFusion and HTML programmed front end.

Advantage:
1. more control over functionality and requirements

Disadvantages:
1. more control means more responsibility
2. not integrated with the catalog so there cannot be a unified search
3. unknown hidden development and maintenance costs

Customized 3rd-party events calendar
A 3rd party solution would be something like the E.vanced product (http://www.e-vancedsolutions.com/) or the Trumba product (http://www.trumba.com/connect/default.aspx).

Advantage:
1. out-of-the-box functionality
2. maintainence and updates provided as part of license agreement

Disadvantages:
1. unknown level of customizability and control
2. non-integration with catalog search
3. out-of-the-box customization that may require a lot of additional computer staff time
4. upfront cost vs. unknown hidden customization costs

Please review these options and let me know your thoughts and if there are additional advantages/disadvantages that I overlooked.

I wanted to thank everybody for the meeting we had today.
A short recap is in order: please comment and correct.
I understand that the direction we are going to take is a hybrid of mock-up1 and mock-up2. Mock-up 2 is going to be the starting point, the main concept. The home page must capture and spell out all or almost all services that we provide.
The following features of mock-up 1 will be adopted for the main mock-up:
1. Horizontal navigation bar.
2. “How Do I…” box will be positioned in the third column of the main mock-up, currently called “Using Your Library”. It may not be available on all pages.
3. The Catalog Search box may still be available on all library pages on the top as it appears in mock-up 1. However, on the home page it was found to be rather distracting (too dominant) when kept above the main content. It may eventually stay in the leftmost column as it is currently in the main mock-up.
A point was made that it is not necessary to build the entire site based on the home page. The home page is special, it may and should have more navigation options, more navigable text than any other page, and it is not necessary to make all pages in the image of the home page. Obviously some stylistic unity must be maintained, but it is a different topic.
We entertained the idea of eliminating the banner (as it is now) in the main mock-up to save real estate. Please comment on this as well.
It was mentioned that the home page design does not have to be dominated by a consideration that some of our patrons are using large fonts and set their monitors at low resolution (800x600). In other words, we do not want to design with the lowest common denominator in mind. This decision will improve our ability to have a more graceful screen resizing, as well as to place everything above the fold.
Mock-up 3 turned out to be elegant but not practical. That design does not capture at a glance all the services the library offers. It was designed with a more hierarchical, less egalitarian approach to services that are “revealed” along the path of mouse-clicks. A meta-home page, with sub-home pages to follow. It was said, we're not ready for it.
Did I forget anything regarding home page discussion?
I would like to suggest that we start putting the requrements in writing. I would like to compile requirements into a rather formal list of what we want to have on the home page and where. It will help us to see tension points between the mission of the home page and some low level requirements.

A question of graceful resizing of web pages has no perfect answer. As the amount of information we display per page increases we realize that the virtual space is almost as limited as any physical space. When users resize a browser window, or increase text size (actions we have no control of and often have similar negative effect on the original page layout) they still hope to see a usable page. If there is no white space on the page to absorb the shrinkage, overlaps and truncations often render the page unusable.
Picture #1 shows how resizing of the browser window can push navigation links on the right column “under” the left column. In this picture, the size of the left column has been set in %, not in absolute values. There is a white gap between the picture and the footer indicating that when the browser window is being resized, the left column is accommodating the shrinkage. But it’s only half of the solution. The image does not resize, and the content of the right column is diving under the image. To make the image resize together with the left column, a magic CSS statement is needed:

#leftcolumn img{width:100%}

Picture #2 shows a more user-friendly outcome.
There is still one problem. What if we have two equally important columns? Or three, or four? In the example above we can sacrifice the left column and the image to keep the main content on the right usable even if the browser window is shrunk by more than 30%. And this is not an unusual use case. If you want to keep both the library site and Amazon.com up(without minimizing them, while you copy/paste from one window to the other) 30% is not that unusual.
It is a luxury to decide that everything goes above the fold in the web page. The requirement of having no vertical scrolling is the first victim of reality. But it is still considered a design faupax to make users scroll horizontally. If we have no horizontal scrolling, and all columns are important and “stuffed” with information to the brim, the solution introduced above, though technically possible, is no better than leaving the screen at the mercy of the user.

Welcome to Miss Vivian's Thoughts.