Hipster PDA: GTD Tiddly Wiki

Miguel Javier said:

GTD Tiddly Wiki is a GettingThingsDone adaptation of JeremyRuston’s
Open Source TiddlyWiki. The purpose of GTD Tiddly Wiki is to give
users a single repository for their GTD lists and support materials so
they can create/edit lists, and then print directly to 3×5 cards for
use with the HipsterPDA.

http://shared.snapgrid.com/gtd_tiddlywiki.html

No kidding. I wonder what we should do to get Planner to support 3×5
index cards sanely…

E-Mail from Miguel Javier

彼女は娘にパソコンを買ってやった。 She got her daughter a personal computer.

On Technorati: , , , , ,

Compulsive wikister

My research group sent me a whole bucketload of documents and
spreadsheets I need to read before the meeting on July 15. What’s the
first thing I do? Wikify it!

I can’t help it. I’m a compulsive wikister. I believe that a
well-maintained freely-editable website can give community depth
because the consequent culture of documentation encourages people to
think about making lasting contributions of knowledge. A wiki can be a
catalog of resources, a place for discussion, and even a venue for
light-hearted fun documenting strange things.

It’s 12:58 AM. The PLUG technical session is in 8 hours. My party is
in 12 hours. What am I doing? Wiki wiki wiki.

コンピューターは非常に複雑な仕事を瞬時にすることができる。 Computers are capable doing very complicated work in a split second.

On Technorati:

Call for participation: 2006 International Symposium on Wikis

This is totally, totally, totally sweet. I _must_ get into this.
Personal information management with wikis?

CALL FOR PARTICIPATION

2006 International Symposium on Wikis (WikiSym 2006)

August 21-23, 2006, Odense, Denmark
Co-located with ACM Hypertext 2006
Sponsored by ACM SIGWEB

See http://www.wikisym.org/ws2006

Research paper submission deadline: April 15, 2006



OVERVIEW

The 2006 International Symposium on Wikis brings
together wiki researchers, practitioners, and
users. The goal of the symposium is to explore
and extend our growing community. The symposium
has a rigorously reviewed research paper track as
well as plenty of space for practitioner reports,
demonstrations, and discussions. Anyone who is
involved in using, researching, or developing
wikis is invited to WikiSym 2006! To learn more
about the Wiki Symposium, feel free to browse
last year's program
(http://www.wikisym.org/ws2005/program.html), the
proceedings
(http://www.wikisym.org/ws2005/proceedings), and
its wiki (http://ws2005.wikisym.org). Information
about the 2006 program will be available at

http://www.wikisym.org/ws2006.

We are seeking submissions for

 - research papers
 - practitioner reports
 - demonstrations
 - workshops
 - panels

Research paper and practitioner report
submissions as well as workshop proposals are due

 - April 15, 2006

Panel and demonstration submissions are due

 - May 1, 2006

Topics of interest to the symposium include, but are not limited to:

 - wikis as social software
 - wiki user behavior, user dynamics
 - wiki user experiences, usability
 - information dynamics in wikis
 - work group processes, wiki-based collaboration
 - reputation systems, quality assurance processes
 - wiki implementation experiences and technology
 - wiki administration, processes, dealing with abuse
 - wiki scalability, social and technical
 - wikis and the semantic web/ontologies, semantic wikis
 - domain-specific/special-purpose wikis
 - wikis in education



SUBMISSION DETAILS

Research papers will be reviewed by the committee
to meet rigorous academic standards of
publication. Research papers are expected to
advance the state of the art by describing
substantiated new research or novel technical
results or by reporting on significant experience
or experimentation. They are reviewed both with
respect to conceptual quality and clarity of presentation.

Accepted research papers will be provided as part
of the conference proceedings. They will be put
into the ACM Digital Library and can be
referenced as papers that appeared in the
Proceedings of the 2006 International Symposium
on Wikis. At the symposium, the presenter will be
given a 25min + 5min Q&A presentation slot.
Research papers should not be longer than 10000
words and 20 pages and should meet the ACM SIG
Proceedings Format, see

http://www.acm.org/sigs/pubs/proceed/template.html.

Practitioner reports will be reviewed for
suitability of presentation to the community. The
primary evaluation criterion is the interest to
the community. Practitioner reports will be
provided as part of the conference proceedings
handed out at the symposium and can be referenced
as papers that appeared in the Proceedings of the
2006 International Symposium on Wikis as well.
Practitioner reports should not be longer than
6000 words and 12 pages and should meet the ACM SIG
Proceedings Format.

Demonstration, workshop, and panel submissions
will be reviewed for their interest to the
community. A submission should consist of two
pages describing what you intend to do and how
you meet this criterion. It should include a
100-word abstract and one-paragraph bios of all
people relevant to the submission. Demonstrations
will be presented in a joint demonstration
session, workshops will get a half-day or a
full-day and a room of their own (depending on
your request), and panels will get a 90min slot at the symposium.

Please submit your papers or proposals in PDF
format by the respective deadline through our
submission system, which will be available
through the WikiSym website. Questions should be
directed respectively at [email protected]
(research papers and practitioner reports),
[email protected] (workshops),
[email protected] (panels), or [email protected] (demonstrations).



SYMPOSIUM LOGISTICS

The 2006 International Symposium on Wikis will be
held at the Radisson SAS H.C. Andersen Hotel in
Odense, Denmark, August 21-23, 2006. A special
(reduced) hotel rate has been negotiated. WikiSym
2006 will be co-located with the ACM Hypertext
2006 conference (back-to-back), and participants
may register for the symposium alone, or may
jointly register for WikiSym and Hypertext 2006.
Registration is handled through the ACM Hypertext website.

If you have any questions, please contact Dirk
Riehle through [email protected]



SYMPOSIUM COMMITTEE

Dirk Riehle, Bayave Software GmbH, Germany (Symposium Chair)

Ward Cunningham, Eclipse Foundation, U.S.A.
Kouichirou Eto, AIST, Japan (Publicity Co-Chair)
Richard P. Gabriel, Sun Microsystems, U.S.A.
Beat Doebeli Honegger, UAS Northwestern Switzerland (Workshop
Chair) Matthias L. Jugel, Fraunhofer FIRST, Germany (Panel
Chair) Samuel J. Klein, Harvard University, U.S.A. Helmut
Leitner, HLS Software, Austria (Publicity Co-Chair) James
Noble, Victoria University of Wellington, New Zealand
(Program Chair) Sebastien Paquet, Socialtext, U.S.A.
(Demonstrations Chair) Sunir Shah, University of Toronto,
Canada (Publicity Co-Chair)



PROGRAM COMMITTEE

James Noble, Victoria University of Wellington, New Zealand
(Program Chair)

Ademar Aguiar, Universidade do Porto, Portugal
Robert Biddle, Carleton University, Canada
Amy Bruckman, Georgia Institute of Technology, U.S.A.
Alain Désilet, NRC, CNRC, Canada
Ann Majchrzak, University of Southern California, U.S.A.
Frank Fuchs-Kittowski, Fraunhofer ISST, Germany
Mark Guzdial, Georgia Institute of Technology, U.S.A.
Dirk Riehle, Bayave Software GmbH, Germany
Robert Tolksdorf, Freie Universität Berlin, Germany

E-Mail from Mark Chignell

On Technorati: , , ,

Information gardening tasks

A large part of my work involves capturing and organizing information. It takes a surprising lot of time and thought. Here are some of the things I do:

  • Capture and file information, relevant mail, work in progress, final output, etc.
  • Help people find information and improve the findability along the way
  • Create and refine navigation (links, new pages, etc.)
  • Move information from private spaces to public spaces
  • Facilitate and summarize online discussions
  • Coach people on tool use and answer support questions
  • Document and refine processes
  • Set up communities, discussions, and other sub-sites
  • Recommend processes and improvements
  • Correct obsolete links and assets

I do that across multiple tools (Wikis, Communities, TeamRooms, Activities, e-mail), with a team of mixed early, mainstream and late adopters and changing communities of learners.

I think of this as information gardening. I can’t architect a beautiful information structure from the beginning. I don’t know what the final result will look like. All I can do is support, organize, water, tie, and prune. I have to find out what paths people use, then pave them to make finding things a little easier.

It’s not easy. It’s less engaging or measurable than programming, where you can track your progress by the defects you close and the features you build. But it creates a lot of value and helps scale up the effect of our group’s work. Why do I do it?

  • I’m building an example of how social computing can support a team.
  • I’m learning more about emergent information architecture.
  • I’m developing and documenting practices that other people might find useful.

How am I learning about this? Mostly through inspiration, practice, and reflection. I collect examples of well-organized wikis and I talk to other teams who use combinations of tools. I handle my team members’ requests and questions, and I think about how we can organize things better.

If you want your team to get more value out of social tools and knowledge sharing, you’ll probably need someone doing work like this.

Anyone else doing this? Want to share notes?

Wiki information architecture thoughts

Even though a wiki is a free-form, unstructured, organic information repository, it needs to be organized so that users don’t get overwhelmed by information. So, how do you organize information on a wiki?

Wikipatterns is a great site for people and adoption patterns, but it doesn’t give tips on how to organize the information. So here are some tips to help you organize your wiki:

Visual identity

A banner, customized colour scheme, and a sidebar may seem unnecessary. When you’re creating lots of pages, it’s a pain to copy-and-paste the template. But a visual identity for your wiki helps people recognize when they’re looking at one of its pages and it gives them a consistent way to navigate to the major parts of your site. Tip: If your wiki allows you to include other wiki pages, put template segments on separate pages and then include them. This saves you from editing hundreds of pages whenever your navigation menu changes.

Homepage

Write the homepage content for a general audience instead of for specialized roles. Provide information about your team and about the wiki. Save the detailed links for other navigation pages that are linked to from the homepage. Link to other resources people might find useful, too.

Multiple navigation pages

Create multiple ways to navigate through the same information space. For example, if project managers need to access certain kinds of information quickly, create a page for them with shortcuts to the resources they need.

Contact information

Always have a contact person for the wiki. Encourage people to edit the wiki themselves if they feel comfortable, but provide a way for them to contact someone else with changes or new resources if they’re not comfortable working with the wiki themselves.

Related resources and the big picture

Link to other resources your team or community uses (other websites, file repositories, Lotus Notes teamrooms, communities, etc.). Show the big picture: when do people use the wiki, and when do people use other resources? What’s stored where?

Workspace

If you need to store information that doesn’t have a proper home yet, have a area on your wiki where you can store snippets that are still being worked on. That way, the rough drafts don’t confuse people browsing through the rest of the wiki. Use this space to store administrivia about the wiki as well, such as snippets for the sidebar.

Handling information requests

When people ask you for information that’s on the wiki, ask them where they looked for it and what they searched for. After you send them the resource, build the missing links so that people can find it easily.

Duplicate information

If you need to copy and paste information instead of including it, pick one place where the latest information will be, and provide links to that place when you paste the information into other pages. This will help you resolve conflicts in the future. If you can, provide backlinks to where the information has been copied, so that you know where you need to update it.

Meta-information

Document what you need to do in order to update the wiki, where things are, and how information is organized. This helps you teach other people how to use the wiki.

Automatic lists

Many wikis can automatically list the children of a page, pages in a given category, or pages with a given label. Use this feature to save you from manually updating lists of pages.

Pretty vs. editable

Pretty layouts tend to be difficult to edit without breaking. Simple layouts tend to be plain. Depending on your target audience, decide where your wiki will be. Do you expect lots of participation? Keep the page layout simple and avoid advanced macros. Do you work with a finicky group that will only use polished resources? Invest in styling, and accept that you might be the only one adding to the wiki.

Internal vs. external links

When linking to other pages in the wiki, try to use internal wiki links instead of copying and pasting the URLs. Most wikis indicate external links with icons. If you use internal wiki links, you avoid the visual clutter and show people that they can expect to have the same navigation when they click through.

—-

There are more things to share, but this braindump is a good start! Have you come across something like this (preferably with more detail)? I’d love to learn from what other people are doing.

Wiki organization challenge – thinking out loud

I’m working on organizing the training material for three workshops that we’re bringing together. Our goals are to share common practices and tips, while making it easy for people to find workshop-specific information. I should store the information in a Lotus Connections community wiki, as WikiCentral is deprecated. Lotus Connections wikis don’t have the {include} macro yet, so I can’t reuse chunks of material easily. My challenge is: how can I organize the information so that people can easily find what they need?

Here are a few options I’m considering:

  • Create lots of individual pages with links. I can create pages for common information and other pages for workshop-specific information, tying them all together with links. I can create multiple pathways through the information by using links, and I can create navigation pages too. Colour-coding the links makes it easier for people to pick out which link they want to follow. When Lotus Connections adds support for includes, I can use that to create master pages that include all the relevant information. Advantages: Each page is simple and short. Editing is easy. Linking between pages is easy. Disadvantages: People have to view at least two pages in order to get the information they need for a single workshop. Browsing will require a lot of clicking.
  • Organize information by common steps, and put workshop-specific information in sections or tabs. The main organization would be the common steps in the process, which works best if there are lots of common steps. Each page would start with common tips, followed by hyperlinks to sections on the page with the workshop-specific information. Advantages: People see both the common tips and workshop-specific information on one page. They can browse through steps in chronological order. Disadvantages: Including all three workshops on a page makes the page longer. Navigating to the right section still requires more clicks.
  • Organize information by workshop, and provide links to common tips. There would be one page per workshop, with links to additional information and common resources. Advantages: It’s easy for people to see all the workshop-related information. Disadvantages: The pages will get really, really long. People don’t like scrolling.

Fortunately, I don’t have to do things correctly the first time around. I think I’ll experiment with creating lots of individual pages with links. It feels more wiki-like for me. It also makes it easier to grow the wiki as we add more material. If we find that this involves too much clicking, then we’ll have a good idea of which pages we need to combine.