Disruptive Library Technology Jester » usability

Charleston, SC Visitor’s Center A/V Display

Peter Murray — Wed, 31 Mar 2010 01:27:39 +0000

First, sorry about this getting posted prematurely through the DLTJ blog. I was trying the post-from-Flickr function, and it was telling me that the posting wasn’t working. So, it got posted here twice. And it got posted before I was ready; I was hoping it would land in the draft queue so I could edit it with further commentary. Oh, well; live and learn.

Charleston, SC Visitor's Center A/V Display

I’m visiting Charleston, South Carolina, and was struck — from a technical perspective — on the welcome display at the entrance to the visitor’s center. If you click through to the picture on Flickr, you can see the notes associated with the various parts of the display. But, basically, it consists of a data projector back-lighting a floating screen in front of a pedestal. Mounted on the pedestal is a trackball and button that control the interactive system displaying graphics on the data projector. Mounted above the pedestal is a sound dome directing the audio to just the people below the pedestal. There are four of these at the corners of a map of historic Charleston embedded in below the surface of the floor. The result is a very airy feeling with a high degree of technical usability without the technology getting in the way.

Tweaking the New FriendFeed Interface

Peter Murray — Thu, 30 Apr 2009 20:15:59 +0000

FriendFeed went live yesterday with changes to the user interface and back-end systems. The changes were moderately positive, taken as a whole, but there are aspects of the new user interface that I don’t like — the color scheme, the removal of the service icons, and the (over)-use of whitespace. Fortunately, with Firefox plus a few extensions as my primary browser, I’m able to tweak the interface to be closer to my liking. If your tastes resemble mine, I both feel sorry for you and want to help you improve your view of FriendFeed.

FriendFeed interface before and after changes via Greasemonkey and Stylish

The primary tool to help with the user interface changes, in addition to using Firefox, is the Greasemonkey extension. After installing this extension, you can use “scripts” to tell the browser to change the HTML markup of any arbitrary web page as it is being loaded. A secondary tool is the Stylish extension. Stylish does to a pages CSS code what Greasemonkey does to the HTML — it overrides the page author’s styles and substitutes your own. Stylish is actually optional because you can use Greasemonkey to load a form of Stylish scripts to accomplish the same outcome. (Some Greasemonkey scripts also work in the Opera browser; I haven’t tried the scripts listed here, so your mileage may vary.)

The first thing we want to do is bring back the service icons. These are the 16×16 pixel graphics that show the source of the entry in the FriendFeed stream. I haven’t heard a good explanation from the FriendFeed developers as to why they took this out, but I find it to be a key factor in how I scan through the FriendFeed stream. Fortunately, Chris Peoples wrote a Greasemonkey script to bring them back. Simply install the script and reload the FriendFeed page; the service icons will be back for public entries. (As Chris notes, it doesn’t work on private feed entries.)

The second thing we want to do is clean up the color scheme: remove the grey background, de-emphasis the functional areas on the right, and rebalance the font sizes. AJ Batac wrote a Stylish script that does that and more. You can load this script into Stylish or apply the Greasemonkey version; as far as I know, they are equivalent. In addition to the color schemes, this script adds new functionality: highlighting friend comments in a light yellow background and highlighting your comments with a light blue background. The latter is particularly useful for rescanning a conversation where you have made a comment; the light blue background tells you exactly where your comment is in the conversation and the new comments that followed.

There is a third script that removes the large avatars that came with the new interface design. Personally, the avatar graphics don’t bother me, but if you want to remove those, you have that option, too.

Fronting Tomcat with Apache HTTPD to Remove Ports and Context Paths

Peter Murray — Thu, 20 Sep 2007 02:31:33 +0000

In this How-To guide, I show a combination of software and configuration to clean up URLs by removing the port numbers of the Java servlet engine (Tomcat) and the context path of the application. The goal is to create “cool URLs” that are are short (removing the unnecessary context path) and follow conventions (using the default port “80″ rather than “8080″). OhioLINK also uses a custom access control module — built for Apache HTTPD — which makes the fronting of Apache HTTPD for Tomcat even more desirable.

Requirement

We’re making use of the latest line of development for the Apache HTTPD series: version 2.2.x. The inclusion of mod_proxy_ajp — replacing the custom “mod_jk” with a module that extends the httpd proxy engine — in the latest major release of HTTPD makes our task much easier. This solution also uses HTTPD’s mod_rewrite and an add-on module called mod_proxy_html. No additions or changes are needed to the stock Tomcat installation.

The Plan

There are two overall tasks that we’re going to ask the HTTPD server to do. First, receive the incoming HTTP request and proxy it to the Tomcat servlet engine using the AJP protocol. Second, rewrite the URL paths of the headers and the X/HTML body from the Tomcat servlet engine to eliminate any instances of the context path. In a visual sense, what we are trying to is rewrite the path so it can be processed by Tomcat (the green box) then remove the extraneous parts of the path in the resulting headers and X/HTML (the red box):

Public Request URLs:	http://e.com		/remaining/path?and=params
URLs sent to Tomcat:	http://e.com	:8080	/context_path	/remaining/path?and=params
URLs as output by Tomcat:	http://e.com	:8080	/context_path	/next/page
URLs as seen by browser:	http://e.com		/next/page

The first half of this problem, modifying a request as they come into the Apache HTTPD server, will be handled by a mod_rewrite rule that rewrites the request to something Tomcat can understand then internally redirects it Tomcat via the AJP proxy. (Note that we are not using simply ProxyPass here because we want to send the request through the AJP interface to the Tomcat server, and RewriteRule allows us to do that with a [P] flag at the end of the RewriteRule line.) The second uses a combination of ProxyPassReverse (a part of Apache-supplied mod_proxy extension that adjusts the URL in the Location, Content-Location and URI headers), ProxyPassReverseCookiePath (also a part of the Apache-supplied mod_proxy extension; it rewrites the path string in Set-Cookie headers), and ProxyHTMLURLMap (from mod_proxy_html, a third-party extension that rewrites URLs inside X/HTML documents).

Preparations

The ‘mod_proxy_html’ extension is likely new to your Apache HTTPD installation, so we need to download the source, compile it, and move it into the proper directory. Fortunately, this is rather straight forward:

wget 'http://apache.webthing.com/mod_proxy_html/mod_proxy_html-2.5.2.c'
apxs -c -I/usr/include/libxml2 -i mod_proxy_html-2.5.2.c

Note that we are not using the mod_proxy_html author’s 3.0 version here. In my set-up, the 3.0 version was causing Apache HTTPD to dump core on every request (whether proxied or not), and the prior release works just fine for our purposes. The apxs line will compile, link, and copy the resulting library to the Apache modules directory for us.

The Configuration

This is the contents a ‘tomcat-proxy.conf’ file that is placed in the ‘conf.d’ directory of the Apache HTTPD configuration directory (most likely /etc/httpd/conf.d/tomcat-proxy.conf, although your installation may vary).

#
#  Information about 'mod_proxy_html' can be found at 
#   http://apache.webthing.com/mod_proxy_html/
LoadFile    /usr/lib/libxml2.so
LoadModule  proxy_html_module    modules/mod_proxy_html-2.5.2.so
 
# DON'T TURN ProxyRequests ON!  Bad things will happen
# http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#access
# http://www.akadia.com/services/prevent_abuse_proxy.html
ProxyRequests off
 
# Necessary to have mod_proxy_html do the rewriting
RequestHeader      unset  Accept-Encoding
 
# Rewrite the URLs to proxy ("[P]") into the Tomcat server
RewriteEngine     on
RewriteRule ^(/.*)      ajp://localhost:8009/context_path/$1    [P]
 
# Be prepared to rewrite the HTML/CSS files as they come back
# from Tomcat
SetOutputFilter proxy-html
 
# Rewrite JavaScript and CSS files in addition to HTML files
ProxyHTMLExtended on
 
# Output Strict XHTML (add "Legacy" to the end of the line below
# to output Transitional XHTML)
ProxyHTMLDoctype XHTML 
 
# Rewrite HTTP headers and HTML/CSS links for everything else
ProxyPassReverse /context_path/ /
ProxyPassReverseCookiePath /context_path/ /
ProxyHTMLURLMap /context_path/ /

That’s pretty much all there is to it. You should note that mod_proxy_html, like any HTML scraper, requires modestly well-formed X/HTML. If the markup is bad, the output from mod_proxy_html is likely to be unpredictable.