Alexadex
February 2, 2006 | 1 Comment
Alexadex is like a stock exchange for web sites. You start off with $10,000 to play with and you can buy shares of any website that is ranked by Alexa. The price you pay per share is based on reach. This is built using the Alexa API or AWIS.
Some examples:
DirectTrack.com - $565/share (bought 16 shares)
Maisonbisson.com - $70/share
Plymouth.edu - $50/share
SpiralBound.net - $4/share (bought 183 shares)
NoSheep.net - $2/share (bought 114 shares)
Yahoo - $288,000/share
OK, so my choices were based on friends and not any real strategy, but oh well, maybe I’ll get lucky.
Tags: alexa, alexa api, alexadex, api, awis, Fun Whatnot, game, games, stock exchange, web, web sites
Scriptaculous
January 6, 2006 | 1 Comment
Matt recently came across and got very excited about Script.aculo.us for doing DHTML effects and AJAX.
From Matt’s post: Script.aculo.us Is My New Best Friend:
Script.aculo.us is a Javascript Effects and Control framework developed by Thomas Fuchs, a software architect living in Vienna, Austria who, like me, was disappointed by current web application frameworks that made no sense to him. His framework is 3 things: Easy to Use, Simple, and Easy to Use. His libraries - built off of the AJAX framework, Prototype - blow SAJAX out of the water!
One of the things that makes script.aculo.us especially great is the detailed and well written documentation/apis. Arguably, this is why I first loved Java and eventually became addicted to PHP. The Java API was great, but PHP.net is unmatched. Like PHP.net, the script.aculo.us wiki allows users to contribute back knowledge easily.
Tags: AJAX, api, apis, dhtml, java, php, programming, prototype, SAJAX, scriptaculous, web, web application, web development, wiki
ecto for Windows Still Blows
December 1, 2005 | 6 Comments
Alex, the lead developer for ecto for Windows, has commented a few times on my ecto for Windows Blows post. I figured they’ve been through a few versions and it was time for me to give them another shot. Alex seems to be putting a lot of care into the product, and as a developer myself, I know how frustrating it can be to get either useful feedback or overly generalized complaints (a la something “blows”). I hadn’t looked at it since August, so why not.
I downloaded it again. Which itself was somewhat difficult. Have you Google searched “ecto windows” lately? The first promising link is misleading as it leads to an old version (1.0.3) which in itself has a link to a broken download. Anyway, I found my way to the homepage and grabbed 1.8.7
On first glance, I’m not satisfied with the spell check, I’d prefer if it checked constantly, sorta Word style. Also, a quick trial on the new keyword feature didn’t actually work, but that is likely because of Wordpress not explicitly supporting it, not necessarily their fault. Another annoyance at this point is that the ping action threw me a non-descript error about “Internal Server Error” no clue why, or how to fix… One last comment, a lot of my posts have relative links to images in the posts. Anyway these could be rewritten to take account of my blogs hostname so they don’t all show broken? On that note, why do none of these previews use my site’s template somehow? Maybe that’s configurable and I just didn’t look deep enough.
Oh crap, I just noticed a final straw to break the camel’s back. My posts in the system that are drafts are showing up in ecto as “Published”. That won’t fly.
I guess I still can’t commit to using ecto for windows (in fact I’m not using it on the mac anymore either) The built in Wordpress interface is simple, and for now that continues to win. Truthfully many of the problems I’m experiencing may be attributed more to Wordpress or the underlying APIs, but either way I still can’t use the product. Nor will I be recommending it on campus as we roll out potentially 30,000 blogs…
Tags: api, apis, blog, blogging, blogs, desktop blogging, ecto, google, movabletype api, review, software review, windows, wordpress
Google Maps API: Risk
November 12, 2005 | 2 Comments
Mike D recently pointed me at GMRisk by TehDiplomat. This interesting use of the Google Maps API created a fully playable version of the game of Risk played on top of the satellite view of the world provided by Google’s Maps.
Unfortunately, you cannot play this multiplayer across multiple computers. If you want to play an actual game here, you need to huddle a pile of friends around a single computer for hours to play. With this in mind, I find the idea interesting, but the implementation short of actual fun. There’s no AI available, so you can’t play by yourself either…
I’m also not sure what playing on an interactive actual map gains you other than novelty. There isn’t any real great reason for zooming in or panning around. If there were new innovative features that too this into account that would again make this a lot cooler.
Tags: api, boardgame, games, gmrisk, google, google maps, google maps api, map, maps api, risk
Library Metasearching and Digital Collections
July 13, 2005 | Leave a Comment
Last week I attended two vendor demos in response to a University System of NH RFP. The two vendors were exLibris and Endeavor. In short, USNH is looking for two things: a solution for managing digital collections at the various schools in the university system and a utility for doing metasearching to give one-stop access to the various resources in the library’s many digital collections. Now I am not a librarian, nor all that familiar with library technology or processes. I was participating here purely from a technology standpoint, so in turn, anything I state here is from that angle.
One of our biggest needs is the ability to integrate the products with our existing university portal, SunGardSCT Luminis. By integration we really have three distinct pieces to this: Single Sign On (SSO), look and feel customization, and data exchange. From my perspective, those are listed in order of descending importance. I also care about APIs so the product can be extended and reused in ways the original company did not imagine. Last but not least, I care about usability. If untrained users cannot pick up the product and feel successful using it, they won’t.
Endeavor
The first vendor was Endeavor. Their two products are ENCompass and LinkFinderPlus.
LinkFinderPlus has great ability to allow for interface customization due to its use of XSLT. Basically you change the XSLT and you can make the interface look and act however you want. There is currently no built-in way to support SSO, but they believe it would not be difficult to build an extension. Additionally, they intend on supporting Shibboleth within the year. Depending on how they implement Shib, it could be good or bad… LinkFinderPlus doesn’t have any data per se, so data exchange is not necessary.
They do have APIs, sort of. Basically, if you don’t apply an XSLT, then you have straight XML and can interpret it like you would REST. As far as I’m concerned this is a great solution, even if it does seem like a “happy coincidence” feature.
ENCompass does have data, but no clear way to exchange it cleanly, not that I can imagine a need for this. The web interface again is XSLT customizable. The “archivers” interface is client side, which seems to work out quite nicely. I thought I’d be opposed to this, but recently my use of utilities like ecto and the Gallery plugins has me thinking differently. It does not yet support JPEG 2000, which is really important for archiving things like maps or murals which need to exist in extremely high resolutions to be able to see any of the useful details. It is also passing of the responsibility of all role and user identification to a directory or your ILS. This is a great step in the realm of identity management.
As a final note on Endeavor, all their products claim to be usability tested in their entirety. The interfaces are simple, could use a bit of work, but are adequate.
Final Grades:
Portal Integration: D
APIs: B
Usability: B
exLibris
My main impression of exLibris is that there are more bells and whistles. They seem to be a technology centered company and like most, suffer a bit from feature creep. Many of their interfaces have a lot of options that could leave users wondering what they are doing and feeling lost. Their two products are called MetaLib (with SFX) and DigiTool.
MetaLib (with SFX) is where the bells and whistles are really obvious. There are varying degrees of increased complexity in the interface depending on how deep you go. This is great for the librarians, but unlikely that students would use it. In fact Casey at MaisonBisson, also in attendance with me, states that “only 0.0067% (YES, less than a hundredth of a percent!) of the searches on our OPAC get “limitedâ€? to specific languages, locations, dates, or material types” in his article The High Cost Of Metasearch For Libraries. The interface seems to be minimally customizable, limited to headers, footers, and CSSS. However, there are “real” APIs for MetaLib, a separate product they call XServer. It is well documented and seems to be just the right amount of useful, but more cumbersome than a mere REST-like interface.
As for SSO, they currently support Shib, but it is unclear if that is as a destination or origin. On a much more degrading note, they had never heard of SunGardSCT Luminis or UPortal, so their knowledge of the portal space, specifically in higher-ed is limited at best.
DigiTool is purely web based and looks and functions adequately. Once again customization is limited. They do have JPEG 2000 support though, so thats a big plus. They claim to authenticate against an LDAP, but other than that, the identity management opportunities are limited at best. Usability seems low all around on these applications.
Final Grades:
Portal Integration: C
APIs: B
Usability: D
From the grades I gave, none of these are ideal. Read Casey’s assessment for more detail about where the metasearching falls down. I just wish the could make it more like Google Scholar or A9. My major question is how do these digital archives provide a solution better than DSpace? Check out the many existing, live, DSpace instances. DSpace is free and in turn has not got an equal seat at the table. It is scary how money often corrupts decisions like this.
Tags: a9, api, digital archive, endeavor, exlibris, google scholar, identity management, integration, jpeg2000, libraries, library, library systems, metasearch, metasearching, portal, REST, search technology, shibboleth, shibbolith, usability
Google Maps API
July 10, 2005 | 65 Comments
Casey turned me on to the Google Maps API and I’ve been looking for an excuse to play.
On Friday I went to UNH in the morning, back to Plymouth late in the day, and then drove up to Waterville, ME that night. Basically 7.5 hours of driving. I was curious how far apart these points would look when plotted on a map. Check it out below:
I would really like if they had a feature in the API allowing me to draw lines along the route I took. Maybe version 2.
The other mildly annoying thing about the API is having no really easy way to get longitude and latitude points when you need them. I ended up writing a little alert(point.x); alert(point.y); on points I was setting on click (based off a simple mod to an example. The other solution is to use something like geocoder.us
As for Casey’s annoyance about the specifics of the license key to a directory, I just registered a key generically for nosheep.net, assuming I could use it anywhere, simple solution. Unfortunately, that didn’t work out, couldn’t put API pages in any subfolders… So, iframe solution for me as well.
Update: It turns out this isn’t working in IE. I guess I need to fix that… On a lighter note Safari loves it!
Update 2: A-ha! I had a line break in my key code and apparently IE couldn’t handle that… fixed now, good to go as best I can tell.
Update 3: I’ve been getting a lot of incoming traffic looking for Google Earth, for more actually about that, Google Earth, an Eye on Katrina
Tags: api, google, google maps, google maps api, mapping, maps