Two bastions of technology reporting are now available online: WIRED Magazine and Popular Science.

Popular science recently added it’s entire 137-year archive to the web, including an article from 1962 about jetpacks.

A fan of WIRED is scanning and posting articles and advertisements from past editions. Remember Microsoft Bob from this 1995 ad?

On February 29, 2008 I signed a petition (#5724) asking Google to add bicycling directions to their popular maps product. Public transit directions had recently been added, thanks in part to my brother Chris, the tech lead on Google Transit. While bus, train and walking directions are great, but as a cyclist I wanted something just for the bike.

Two years later, the Google Seattle team adds support for biking directions. It sounds like this was a lot more than simply flipping a switch and adding a new option in a drop down. A post on the Google LatLong blog describes some of the data and algorithms that go into great biking directions.

• Bike trails: Our maps contain over twelve thousand of miles of biking trails. First, we had to figure out where trails are…

• Bike lanes: For more than 150 cities in the US, we know which streets have dedicated bicycle lanes…

• Recommended routes: For many cities we also provide information on streets that have been designated as good for cyclists, so we them into account in our algorithm…

• Uphill slopes: … Our biking directions are based on a physical model of the amount of power your body has to exert given the slope of the road you’re biking on… Sometimes the model will determine that it’s far more efficient to make you ride several extra blocks than to have to deal with a massive hill. My teammates in San Francisco were relieved to see that this does indeed work!

• Downhill slopes: Many cyclists will tell you that going downhill is annoying for a different reason: you may have to ride your brakes all the way down…

• Busy roads: Cyclists often tend to prefer to stay off of fast roads, and not even cross them unless it’s necessary…

• Busy intersections: We try to avoid making you cross busy streets with a lot of car traffic and long wait times.

I tested out the new feature and it works great for my neck of the woods. True to form, I plotted directions from a brew pub in San Ramon to another in Walnut Creek. I’m not recommending that you ride your bike after sipping a few pints of Pliny, but it’s certainly better than driving. Google correctly plotted a route along the wonderful Iron Horse Trail, taking into account the various hops onto local roads as need.

Inspired by Bicycling’s feature on Brews and Bikes, here’s five bike themed beer labels.

I’m starting the design of a new iPhone app. It’s intended to help users follow a live event, so the app will regularly be downloading data to refresh screens with the most current state. I’d like to avoid the use of a “refresh” button for numerous reasons that I’m not going to get into, mostly because it’s boring.

Taking away the users’ ability to manually force an update is tricky. We like to feel in control and it’s hard to trust that a piece of technology is working as it says it will without our intervention. For example, software designers have learned that although automatically saving a document (or progress in a web app) is a better overall experience, it also gives anxiety to users. Users feel that they know they won’t lose work after clicking on a button labeled “save”. Harvest, the time tracking tool used by Adaptive Path deals with this by including a prominent “save” button near the “last saved” message although clicking the button is not needed. Google Docs uses a different approach, labeling the button “saved” and making it non-functional…. the user goes to click save and see that it’s already taken care of. It appears that Google is attempting to train us to stop worrying about ever saving documents.

With these thoughts in my mind, I started designing a status indicator that will appease users’ innate desire for control. On a regular interval, probably every 10 seconds, the app will connect over the network and check for new data. If found, that data will be downloaded and the screen will refresh with the latest status from the live event. It is possible that multiple refresh cycles could pass with no new data, in which case the indicator will need to reflect an increased time since the last update.

Here is my current design for the indicator:

Likely this strip will go at the very top or the very bottom of the app.

There’s two sections, the last update time and a countdown to the next refresh. The last update time reflects the time since new data was found. It’s likely that several refresh cycles will pass without new data. As this occurs the last update time will increase by the 10 second interval length. Once new data is found, the last update time is reset to zero, represented by the friendly “just now” text.

The countdown bar is a simple visual element that over the 10 second interval animates to give the appearance of emptying. Once the 10 second time has lapsed, the countdown bar is replaced by text that reads “updating” along with an animated spinner. Once the refresh is complete, the bar resets to full.

Overall, I think that this design solution works. The biggest question I have is whether users will quickly understand that the last update time is not necessarily the same as the last refresh time.

I am living in the future. Andrew just sold me Girl Scout Cookies and he accepted a credit card payment with the Square app on his iPhone. It worked flawlessly was a joy to interact with. I do wish that the photo we took of the cookies appeared on the receipt.