Via Om Malik’s Broadband Blog, “The New Office Space“:
“No office space was rented, communication was primarily through email lists and a private wiki, and meetings were held at cafes with free internet, with notes and ideas quickly disseminated to those who couldn’t attend. When a contact was needed to help out with services such as advertising, sponsorships or donations, cell phones came out and calls were made, and issues were often resolved before the meeting was even over.”
I enjoyed this discussion of using a café as office space, which links to the notion I’ve mentioned before about contingent spaces, spaces for a life style based on contingency.
Delicious Monster, source for the Delicious Library application, started by Shipley, formerly of Seattle’s Omnigroup, is another example of this style of work. They’ve been profiled in the Seattle Times specifically mentioning that the office was a café. Almost a violent reaction to a pervasive cubical culture, the unstructuring of what is called an office.
Of course, this further connects to discussions about third places, and the absent commons. Both Habermas and Oldenburg talk about this very thing.
Something that I learned when I visited Yorkminster was that the cathedral was a commons for the mideval populations, where all kinds of public meetings would take place, sometimes all at the same time. I wonder if any cathedrals have thought to offer free WiFi? Maybe someone should get a router installed into the national cathedral?
In Olympia, the maps of wifi locations would be a useful thing to consult, but not many of these really seem to offer comfortable office space. Even Batdorf & Bronson, which is a great space, really isn’t ideal. And, the library now offers wifi, but they are really very unfriendly about technical issues and, apparently, there’s a 5 user limit on their dhcp/router device.
Which reminds me, that, for some reason Safari doesn’t get the redirect that the library’s WAP uses to point to the login page, so if you’re using a Mac, you may need to open up Camino or Firefox first to set the cookie used by the device. The actual login page is: http://192.168.47.190/loginpages/login.shtml (and use the login and password of the day that they distribute on little scraps of paper.) However, it appears that if one navigates directly to the login page, the WAP complains that it is not able to read a cookie. That cookie is apparently only set when a browser is redirected to the login page. That means the only way to log in to the device is to navigate to somewhere first, and be redirected. Once the login is successfully completed, the browser is redirected to the TRL homepage. If that’s by design, that’s poorly designed from a user perspective.
It also appears that Safari and the device do not work well together. The library staff say, “If it’s not working with Safari, that’s because you need to use Internet Explorer.” I told them, “That’s like saying that the phone only works in english, not french.” Turns out we’re both correct. The problem is that the operator, through which all out going calls are routed only speaks english. Apparently, Safari doesn’t speak the same dialect as the WAP, so they are at a loss.
Safari will not redirect to the login page. So, one must use another browser, say, Firefox or Camino, since IE is not only evil but essentially a lost cause on the Mac. I used Camino. Camino accepts the redirect fine, and as long as the browser accepts cookies, the login appears to work correctly.
Once Camino has been used to log in, all other browser, including Safari work fine. However, I’ve noticed that, although the library staff claims there’s a 3 hour limit and made no mention of a timeout, if one is not browsing the web, the cookie appears to time out and need to be refreshed. So, if you’re doing anything other than browsing, you may need to go through the login again, or find a page with a refresh.
The library uses a D-link Airspot DSA-3100. Macworld has a review which is really just a press release from the company that provides some interesting information.
The DSA-3100 incorporates a firewall, DHCP server and router, and can support up to 50 logged-in users simultaneously and up to 10 guest accounts. The device provides audit trails and the ability to authenticate and authorize users, how long they can connect for, how much bandwidth each user can utilize, and where they visit on the Internet. Administrators can limit access by MAC address, direct users to custom-designed Web pages and more.
Administration and private use is managed behind the DSA-3100’s firewall, to make sure that public users can’t access confidential info. The gateway tracks and stores user traffic, and produces lists of IP addresses visited and login times. [Emphasis added]
Well, it has built in traffic shaping, which means that there’s really no excuse for the statement by the tech person that the network is slow during peak use except that it’s either not configured correctly or they have a very anemic pipe.
Both Macworld and MacNN have the press release verbatim, with no additional information, so they don’t mention the problem that the D-link has with Safari. I wonder if the redirect/cookie fails with other KHTML based browsers. It clearly works with Gecko.