• A Django site. •
• •
November 12, 2008

Christer Edwards
nonic
Ubuntu Tutorials : Dapper - Gutsy - Hardy - Intrepid
» Wiki Editing With Your Favorite Editor

Recently I was tasked with doing a bunch of documentation work here at the office, and I decided to put together a wiki for the job.  After a few hours of editing directly into the browser I was about to blow my brains out.  I quickly decided that if I’m going to be working with a lot of text I need a real editor, like vim.

I set out to find some solutions and quickly ran into a Firefox addon that allows you to edit most forms, including wiki pages, with your editor of choice.

You can install the addon directly from Mozilla or you can get it from the Ubuntu repository.  Links for each below:

It’s All Text!

sudo aptitude install itsalltext

Once you have it installed you’ll need to, of course, restart the browser and then you can configure it.  You can configure it via Tools > It’s All Text > Preferences, or from within your Addons Management Window.

It's All Text Preferences Window

As you see here my prefered editor is gvim, which I can select using the “Browse” button.  Note: if you don’t have gvim installed you’ll want to add the vim-full package:

sudo aptitude install vim-full

Now that you have this configured you can simply edit most forms on the web by right-clicking within the form and selecting “It’s All Text”, or by clicking the “Edit” button that you’ll now see to the lower right (based on my configuration) of the input field.

For all of you that spend hours and hours editing wikis and other online forms I hope this helps out.  I know it saved me from wanting to throw myself out the window!

Other Points of Interest

by Christer Edwards at 3:58 PM under addon , firefox , its all text , web development , wiki (Comments)
February 28, 2008

Clint Savage
herlo
Sexy Sexy Penguins » Tech
» POW: Gobby, the little engine that could! (collaborate)

Its been a very long time since I’ve done the Product of the Week, so I am going to change the name to Product of Whenever. This suits me better.

In July of 2001, I was introduced to a little editing tool many of us now know fondly, the wiki. I was travelling to New Zealand looking for work. During my month’s stay, the fellow I traveled with showed me his wiki-wiki. He explained how collaboration could work and the simplicity of the system made it even great for a one person quick web page. Immediately, I was hooked. When I returned from New Zealand and enrolled in school, my mind quickly went back to this funky wiki-editor thing I’d seen. Being a geek even back then, I promptly installed one.

Fast-forward almost 7 years. We’ve seen the wiki evolve from a little app that could be used to make an entire website of information so grand that even the largest collectors of physical data can’t compete. We’ve seen tools like DocuWiki - the documentation wiki, MediaWiki - which needs no introduction and Tomboy - the little desktop wiki. Many other wiki’s emerged to help people collaborate all around the world. How great a time it was…

This article isn’t about wiki’s, rather it is about collaboration. This article is about a different type of collaboration, one that’s more real-time than a wiki can be. In some ways its more limiting and in others, much less. The feature I’m referring to is real-time collaboration. And the tool that enables this, gobby, and its closely related cousins, sobby and obby.

INTRODUCING GOBBY

The Gobby Editor

Gobby is a collaborative text editor, with a bunch of cool features. While gobby is still young and not quite feature-full, its quite amazing what it can do out of the box. The collaboration abilities of gobby come straight out of the box. One can choose to create a session on the local network, or create a server version, with sobby, where everyone can connect to a centralized server to collaborate. I’d like to also point out this application can also run in Windows according to the authors’ website, though I’ve heard rumors that it doesn’t work as I’ve not personally tried.

To get started with gobby, its easily installed:

# yum install gobby
.. snip ...

Once its installed, gobby will easily load from Applications -> Internet -> Gobby Collaborative Editor. Up pops the window we showed you above, albeit a little more bare. The toolbar is the most important piece here.

Gobby is disconnected at initial start. Click create or join a session

There are two distinct features here, plus the ability of a regular text editor. On the left, are the connection buttons, one can join or create a session. On the right hand side, are user and document lists, and a chat button. The left hand side controls how to connect, the right controls once you are connected. Of course, the middle does have tools of a normal editor.

Clicking the Create session button provides this dialog, allowing for a local session to be created and maintained.

gobby-create.png

This session can be just one person, but is definitely better with at least two. Notice that you’ll need to pick a colour. This feature is what makes it easy to tell who’s edited what parts of every document in gobby.

The other option is to join a session. Joining a session also lists any local sessions currently available.

gobby-join.png

Once the session is created and/or joined, its just a matter of using gobby like an editor. The fun part about gobby though, is when the collaboration begins. When working on a document, others can work on it as well, at the same time. Which can be confusing, and troublesome the first time you play with this tool. Give it some time and you’ll be hooked.

In addition to creating an obby session with the gobby application, its also possible to create a persistent connection with the sobby server. Unfortunately, sobby doesn’t have features that let it run as a SYSV service, but it is possible to get a server up and running quite easily even still. The organization I run, UTOSF, has one currently up and running at gobby.utos.org. If you want to join up, please let me know and we’ll get you connected.

Take the time to get to know this awesome collaboration tool, and start working with your friends who code, or document or even just for simple brainstorming sessions.  The possibilities are endless.

Cheers,

Herlo

by herlo at 7:29 AM under collaboration , editors , fedora , gobby , pow , tech , tools , utosf , wiki (Comments)
November 19, 2007

Hans Fugal
no nic
The Fugue :
» Documentation Wiki

"Documentation Wiki"—two words to strike fear into the hearts of men. I've been around the block a few times, and seen all kinds of documentation, ranging from excellent to nonexistent. Any documentation is better than no documentation, but of existing documentation nothing is quite as bad as wiki documentation.

Whenever I see one I catch myself rationalizing, "Oh, another wiki documentation site. I think that means it's supposed to be excellent documentation. Buck up and get excited, man! You're such a pessimist." But in the end, my initial nauseous premonition was right.

I'm not sure why this is. Wikis were supposed to be a godsend to documentation efforts everywhere. The community would keep everything perfectly up to date, and the project leaders could focus on the code.

I do have a couple theories. I think my theories boil down to "people are lazy". In fact, a lot of my theories boil down to that. I'd put some thought into whether all of my theories boil down to that, but I'm too lazy. If a project has a wiki for its documentation, then right off that tells you the people that should be writing the documentation are too lazy and are trying to pawn it off on the community. The community just wants to use the software to get things done, with rare exception (usually big projects that are a livelihood to its users, e.g. Asterisk). The people in the community that aren't too lazy to make an account, evade spam protection, and do enough research to (attempt to) write a quality snippet of documenation are too lazy to come back and update that documentation at every new release. They might not even use a new release for months or years after it's released, because they keep using the version that's working fine. Or maybe they're on the other end of the spectrum and they follow the bleeding edge religiously and update the wiki with vigor. Oops, now the stable dinosaurs don't have any documentation for the version they are running. Oh, and those lazy devs spend more time cleaning up spam in the long run than they would have in writing quality documentation which would have been better for everyone in the first place.

Unless your project is very important and your community is very vibrant, forget the wiki. Just bite the bullet and write some docs. Or, ask someone in the community to head up the effort (the slightest bit of organization will go a long way here). For the best of both worlds, write the documentation and put it in a wiki where people will update it as they notice it is needed. The laziness threshold for fixing a small problem in an existing documentation page is small enough (unless you require registration and spam hurdling).

by Hans Fugal at 12:34 AM under documentation , wiki