Archive for February, 2006

Bloglines to the ++ del.icio.us thought tracking link dump why not

Bloglines to the ++ del.icio.us thought tracking link dump why not

I have a bunch of “Keep New” links getting old in Bloglines, cause like keeping there is one actionable step above *-tagging in del.icio.us (and I’m not the only one creating semi-ignorable actionables with yet another percolative tagging extension). But really my bloglines behavior is well adaptive to semi-conciously skipping these articles with just a subtle twinge of overloaded work anxiety. So I’ll dump, and maybe my thoughts and connections, if they actually exist (and aren’t that deep anyway) will come through in the spaces. Or maybe just write them anyway.

Comments

Small MGeocoder Update

Small MGeocoder Update

If you have been having any problems with MGeocoder, the Google Maps extension for geocoding, you may want to try updating mgeocoder.js.

Apparently there’s some weirdness with php5, or the curl libraries, and something to do with encoding of spaces. Nevermind, it should work after this update :).

Comments

Google Maps Hacks

Google Maps Hacks


Got a peak at Google Maps Hacks and both my contributions have been published. Cool-i-o.

They are Hack 40. The Ghost in Google Ride Finder
and Hack 49. Generate Geocoded RSS from Any Google Map

Both these hacks target the issue of Open Geo Data .. perhaps the Issue of 2006.

The Ghost is based on this post, and the Bookmarklet described in Hack 49 is posted here.

Comments

The Future of Web Apps

The Future of Web Apps

I’ll be at the Future of Web Apps Carson Workshop today, maybe meeting you?

Comments

Not presenting at Etech: Wiki Anarchy in the United Nations

Not presenting at Etech: Wiki Anarchy in the United Nations

Around the time proposals for this year’s Etech were due, I had just wrapped up the WaterWiki project at the UNDP, and I put together a quick submission. WaterWiki was a very very satisfying project, and it looks like the concept will soon start replicating through the UN. The etech proposal has been under consideration until just last week, when I got the word it wasn’t in. Ah well. There are some good, still relevant ideas in the original proposal, and the follow up response to the selection committee’s feedback, so here I share.

Original Proposal

The talk covers the first experience with Wiki technology in the UNDP (United Nations Development Programme).

The UNDP is an inter-governmental, not-for-profit organization. It’s highly decentralized, working on the basis of a global network of Country Offices, backstopped by regional service centers and one headquarters (in New York). There are untold amounts of knowledge and experience from project development, implementation, evaluations, etc., most of it stored in places difficult to access geographically and temporally – human brains. As common elsewhere, formalized knowledge management – a declared and explicit goal for the organization over the past couple of years – has not lived up to its potential in freeing individuals within the organization to either contribute to repositories of knowledge, not to access their colleagues worldwide and contribute through informal means.

An anarchic approach might be the answer, yet it needs to be properly designed. Wiki, despite its evident simplicity to geeks, is not a technology (and concept) that’s easy to grasp for laypersons. And in reality, the problem of introducing the benefits of Wiki into an organization is cultural. Practitioners suffer from technology and change fatique, and are already overburdened with procedures and substantive work. We learned many lessons in designing the cultural virus that is WaterWiki, like..

  • Start small and have a champion
  • Wiki text sucks
  • Structure and familiarity is essential for initial momentum
  • templates and adequate simplification of script, Maps, pretty pictures, and nice formatting make it all less scary
  • Grow nice carrots (ie make their job easier), cause the stick
    doesn’t work

Wiki turns information architecture into an anarchic activity.

Putting this tool into the hands of experts is the next challenge for technologists.

Follow Up

Two facets of WaterWiki stand out when thinking about usability and
attention in Wikis: Structure and Visualization.

Wkis are by nature amorphous, unstructured, open, adaptable. That’s
their greatest innovation. But as you say, it requires very active
manual gardening to focus a group of contributors, and often no one
takes that role. Simply getting started from the blank slate of a new
wiki is a challenge for any community.

Wikipedia has been such a success partially because an encyclopedia is
so unstructured, traditionally only an alphabetic list of mostly
standalone articles. It’s a model easily translated into a Wiki, and
provided a lot of initial inertia for Wikipedia.

At the other end of the software spectrum, large knowledge management
solutions attempt to beauracratically embody community processes, and
can end up expensive, barren places.

I think there is a middle ground.

In WaterWiki, we installed & implemented several MediaWiki hacks and
extensions to introduce just enough structure. New wiki pages are
selected from a group of user editable/creatable templates, each
defining a category. They consist of several sections, with pre-chosen
section headings. These pages can be rendered & styled in a variety of
ways. The fundamental unit in the wiki moves from a page to a section,
which are reusable throughout the wiki. For example, each country page
has a News section, which are all gathered into a single page, and RSS
feed.

We don’t have it entirely right, but I think WaterWiki is moving in the right direction. In a sense, it is an attempt to empower wiki users, to take on Information Architecture and even application building. There are many interesting takes on structured wikis — JotSpot, Twiki, WikiData, but still I find them complex and difficult. A strong current in the history of software has been self-obsolence by programmers — how can domain experts build software for themselves without worrying about all the innards and pecularities of computer. Higher level languages, spreadsheets, HyperCard, cgi scriping, Ning .. always balancing the trade off of abstraction and customizability.

Within the MediaWiki development community there are several sketches
and some small projects to introduce structure. But it does touch on
the 800 pound gorilla role of Wikipedia. It’s wide exposure provides
great conceptual leverage when discussing wikis in non-geeky forums.
MediaWiki has an active developer community and is definitely a proven
platform (even if the code would ‘go well with meatballs’). However,
the idea of what a wiki can be is becoming frozen, and idiosyncratic to the Wikipedia experience (does every wiki need ‘Talk’ page and edit
buttons for math formulas?)

WYSIWYG is not a silver bullet for that greatest offense, wikitext. We
really don’t want wikis to start looking like Word documents. Small use of WYSIWYG, along with more use of familiar feeling HTML forms build on simple structures, will make the wiki editing experience less
absolutely terrifying for the novice.

Data Visualization is the other major theme, particularly when thinking about attention. With a few exceptions like weighted lists,
visualization has been tremendously underutilized for comprehension in
every day use; its mostly the result of one time or occassional heavy
analysis. IBMs ‘history flow’ visualization of Wikipedia was
fascinating, but only a single study and possibly too complex for quick comprehension.

Spatial Visualization has become a phenomenon because its so
accessible. Maps are very familiar forms, and the required analysis can be straightforward (this is located here, happened here). The power of spatial visualization has motivated my work from World as a Blog, to worldKit, to OpenStreetmap.

In WaterWiki, the front page features an interactive map of the region. Each country contains mouseover content, from the news sections. These countries are assigned geographic polygons in the wiki, and a GeoRSS feed is produced for display in the map. This simple map has made the wiki much more inviting to new users.

There are many active projects combining wiki like factors in map
building, all with different takes, from Placeopedia to Wikiteer to
OpenStreetMap (which takes it to a whole new level).

Dynamic network visualization could by useful in some wiki situations.
I’m actually not aware of any network visualization applied to wikis,
perhaps due to the conception that they are always quite amorphous. I’m curious to try this out on WaterWiki; its structure could lead to a comprehensible, usable visual site map.

Yes, recently modified lists and alerts are crude tools for Attention.
Perhaps before visualization can be fully engaged, much more thought is needed in the analysis of Wiki activity. Determine the scope of the
change (small edit or major modification), how the change fits in the
history of the article (repeated reversion indicates conflict), who is
making the change (a long standing contributor, or newbie), how long
the edit took, the frequency of edits.There can be more focus paid to
individuals behavior on the wiki, to tailor attention to wiki activity.

On OpenStreetMap, we have just started looking at this issue. A small
step from the Recent Changes list to visualization was introduced last
week, by plotting the locations of edits on a dynamic, updating map —
http://brainoff.com/osm/change/.

Comments

MGeoRSS: Google Maps API Extension for GeoRSS

MGeoRSS: Google Maps API Extension for GeoRSS

I’ve reworked some code for parsing GeoRSS in Google Maps into a proper extension .. MGeoRSS. This can be quite useful for quickly building maps, like Node.London, and promotes an interoperable geospatial web based on a common data format.

With GeoRSS standardization in the works, its important to get the big map players on board to support. How bout it Google — are you ready to step up and promote GeoRSS directly in your API?

Comments