In case you want to find out more, or you want to run fast in the opposite direction, here is my presentation schedule:

Pre-conference 1: May 17, 9:00 AM - WebPAC Pro design and best practices
D13: Mon, May 18, 1:30 PM - Web Access Log Analysis
J13: Tue, May 19, 1:30 PM - Does Your WebPAC Really Represent Your Collection?
L13: Tue, May 19, 4:30 PM - Your Accessible WebPAC Pro

For more details, check out the program at-a-glance or full conference program (MyIUG password required).

See you there!

The iPhone offers a small puzzle and an exciting opportunity. The puzzle is that it is too pretty for users to be satisfied with the classic AirPAC, which condenses the entire catalog to about 12 lines of text. The iPhone is capable of displaying any website in crisp, clear color, including the library’s full web catalog. However, those catalogs are not designed to show well on a relatively narrow vertical screen. The opportunity is this: now we can use standard web technologies to reach a broad segment of mobile users with a new interface to the catalog.

Right now we are building this new catalog. It is at the stage where you can really see and feel how it is going to work on the iPhone. After being automatically recognized as an iPhone user when you connect, you’ll be redirected to our new, special iPhone page. There, you can use most WebPAC features, such as searching, placing holds, and renewing books, all without having to pinch or zoom your iPhone browser. Your results will even come back in RightResult™ order! Sure, it still needs a dose of interface polishing, but I’m looking forward to seeing this in our AirPAC libraries soon. Plus, The way we are deploying this catalog view requires no change to the existing AirPAC. If the iPhone work is successful, we’ll look at expanding to other smart phones. We think that this new generation of phone browsers may finally entice patrons to use their phones for more than just a quick look up, and, like Amazon and Google, want to be ready to offer something special to the iPhone users when they search their library catalogs.

• Firefox: Rapid previewing of html and style changes.
• Web Developers Toolbar: Editing styles and HTML on the fly.
• Fangs plug-in: Reality-check of accessibility for screen readers.
• Dreamweaver: Looking up style declarations and saving changes to files.
• Internet Explorer: Compatibility testing.

Here is my workflow for editing pages in the WebPAC. You can use this to make pretty significant modifications to an existing visual design. I would use a more structured design approach for a complete site redesign. However, this works well for most changes.

Set up a workspace

First I make sure I have the latest copy of the WebPAC screens directory on my computer. Then I make a copy for safe keeping in case I make a mess of things.

View the page you are changing

First, I open Firefox and browse to the page on my staging port that I want to change. Suppose I am adjusting the layout of a bibliographic record. I would do a search (I usually search for gnomes or trolls, just a preference). Then click on a bib record.

Once I have a page open I can start trying some changes right in the browser. I have installed Web Developer’s Toolbar, a plug-in for Firefox. I open the following two items from the toolbar:

• CSS -> Edit CSS
• Miscellaneous -> Edit HTML

These two editors open at the bottom of my browser window. I can rearrange divs in the html editor and apply all kinds of styles in the CSS editor. I will delete things from the html just to see what happens. The browser updates immediately so I can see the effect of my changes. You need to know that each attached CSS file is shown as a separate tab in the CSS editor. I always make sure I’m editing styles.css, since that is the customizable one, not ProStyles.css.

Of course these changes are not saved…

Make changes permanent in Dreamweaver

I open the same files in Dreamweaver as the ones I am playing with in Firefox. Just to be sure, I scroll to the bottom of the html source and find this:

<!--this is customized <screens/bib_display.html>-->

I open bib_display.html and styles.css from my local copy of the staging screens. Now, when I get something working the way I want in Web Developer Toolbar, I copy and paste it into the appropriate file in Dreamweaver. Since I have a safe copy, I save after every change, confident that I can always revert by copying from the original.

Another thing Dreamweaver helps with is code completion. That means I type the first letter of an attribute or tag and it pops up valid tags beginning with that letter. Dreamweaver helps if I can’t remember if I need “align,” “text-align,” or “align-text.” (Only one is correct.) It also gives you choices of what follows an attribute, such as “center,” or “middle.” Sometimes I will use Dreamweaver to rough out a css class definition, then paste it into Web Developer Toolbar to fine tune the size, margins, and padding.

Wash, rinse, repeat

Now I can copy my updated files to staging and view them again in the browser. I use FTP to move the files, then refresh the Web Developer Toolbar editors. Remember, the changes I was playing with are still in effect until I reload. Each editor has a Reset All button in its control bar. It looks like two green arrows circling each other. When I click that, the page goes back to the last version I loaded (not the one I just uploaded). That is important, because next I hit reload and my new version appears. Watching the page as it reloads lets me detect anything shifting around as a result of my changes.

Now I can repeat the process with other parts of the page, or other pages I want to change. There are several steps in the cycle, but they are quick and easy once you get used to them. The constant feedback of the Web Developer editors saves you the hassle of making a dozen changes, uploading, then trying to fine tune the ones that didn’t work.

Reality checks

Once I have things looking the way I want, I look again in Internet Explorer. I have not found a live edit preview for IE like Web Developer Toolbar, but by this point I’m usually just adjusting margins. It is simple enough to make an adjustment in Dreamweaver and upload it. Then I reload the page in IE and look again.

Another test I like to do is to render the page in Firefox with the Fangs plug-in. This creates a page of text representing what a screen reader would speak to a user who is blind or otherwise visually impaired. The tool is a reality check. For example, it helped me decide in the latest Example Set to replace vertical bar characters between top menu items with solid left borders. The vertical bars were being read as “vertical bar.” There are still barriers in some system generated parts of the WebPAC, but Fangs can help you work toward a fully accessible catalog.

FTP

I glossed over the FTP step. I use a separate FTP client called Winscp, because I need it for other tasks besides straight page editing. You can use a client of your choice, or Millennium Web Master. Or you can configure Dreamweaver. I have to confess I have not done the config in Dreamweaver. That sounds like a project for another blog post.

See you next time!

We have all heard this warning. You may have heard it just now for the first time, but you are sure to hear it again. And in fact, there is some truth to it. If you use Dreamweaver’s visual editor, it will write HTML its way. Often the result can be strangely indented code blocks or text on the wrong side of a tag.

Today I am going to give a few pointers on making Dreamweaver obey your commands without biting you (ambiguity intended.) I use Dreamweaver for 90% of my page and CSS editing. I have used it for nine years, and I can say it is reliable if used properly. Here is what works for me:

1. Start seeing code. If you don’t want Dreamweaver to put odd bits into your html, you need to be able to see the html. The first thing you should do when you open a file in Dreamweaver is select the split view:

View menu -> Code and Design

You get a visual preview at the bottom of your screen, and a nice, pure code pane on the top. Dreamweaver shows how smart and nice it is by remembering your view preferences for each file.

2. Edit the code, not the output. When you edit the code, you will not see changes in Design View until you refresh. Hit the F5 key to refresh. But before you type, edit, or delete anything, make sure the code pane is active. Not sure? If you have line numbers turned on, the left margin turns blue when the pane is active. But if you want to be sure, just click on the code pane before editing. I have gotten in the habit of clicking the scroll bar rather than the code itself. You’ll see why in a moment…

3. Make selections visually, edit textually. The Design View helps you navigate your document. This is one of the biggest time savers in Dreamweaver. You don’t have to pick through all those nested div tags (or worse, tables.) Go to the Design pane, and click the thing you want to edit. The tags representing this item are highlighted in the code. Now click on the scroll bar up in the code view, and you are ready to edit what you clicked. If you click the text of the code it will place the cursor where you clicked, and lose your selection. If you click the scroll bar, it keeps your selection.

4. Nesting instinct. One of the most tedious tasks in html editing is finding the proper start and end tags of nested containers. Even free of tables, a complex layout of divs can be confusing. Again, click inside an object in the Design View. At the bottom of the pane you will get a breadcrumb trail like this:

<div.pageNavColumn> <ul.leftCol> <li> <a>

You can read this right to left, from inner to outer container. This means you clicked on an anchor tag inside a list item inside an unordered list which is nestled in a div. Plus it tells you what class is applied to each element. To top it off, you can click any of these nested items to select it. And yes, if you then click on the scrollbar on the Code Pane, the html code representing the same element remains selected for you.

5. Make some personal space. Dreamweaver can seem cluttered, with palettes and toolbars crowding in from all sides. If all you are doing is typing code, you can make room by hiding all that extra stuff with a touch of your F4 key. Or:

View -> Hide Panels

Hit F4 again to bring it all back.

Now Dreamweaver is tame and docile. You can enjoy its many nice features, such as code completion as you type, a robust, multi-file find and replace, instant browser preview (F12), and of course, that contented purring sound it makes when happy. Or maybe only I can hear that.

http://csdirect.iii.com/documentation/cir/weblogs.shtm (password required)

Many people here at Innovative worked hard to make this a useful feature for analyzing visitor traffic to your catalogs. What I have tried to do is write an introduction to this feature, just to help people get over the initial learning curve. I would also like to thank the libraries that invested hours or days of time trying out the procedures. You have helped make the process easier for everybody!

I would love to hear how you are using your web access logs and I invite you to post your comments here. I also expect people to find new features within log analysis. If you want to share what you discover, we have a new for you WebPAC Wiki (password required).

Until later…