View source

''Wiquila – an extensible rich client for high-productivity, integration-friendly Wikis''

Wiquila is a rich client able to provide comfortable Wiki authoring either for “legacy” Wiki engines, or for the knowledge base we develop in the same project. Wiquila allows easy insertion of dynamically updated references to internal and external resources. 

== Download and test drive ==
* Watch the screencast of an older release at http://www.teamweaver.org/downloads/media/screencasts/2007-12-10_wiquila_screencast/index.html (Demo starts at 6:40)
* Download from here: http://www.teamweaver.org/downloads/binaries/wiquila/
* unZip to local drive
* refer to readme.txt for further instructions for your environment
* by default, you will be able to access our public Wiki instance

== Challenges of using today's Wiki in an Enterprise context ==
A survey with our partners, some of whom have had extensive, enterprise-wide Wiki installations for years, as well as our own experience indicate that enterprises struggle with the following issues when using today’s Wikis:
Usability. The appearance of text completely changes between viewing and editing. Learning Wikisyntax is a slow process. No direct feedback is given, making errors more likely. 

=== Productivity ===
Even those users who know Wikisyntax perfectly well lose time because common operations are more complicated than they need be (e.g. find&replace), and their attention is drawn away from the content itself to technicalities. This may be acceptable for a volunteer project like Wikipedia, where these difficulties may provide an element of identification of its members with “Wiki culture”, but it must be a real concern for enterprises whose goal is not the Wiki itself.

=== Rampant growth and other quality issues===
Large Wikis can quickly become poorly structured, if there are not volunteer “Wiki gardeners” who engage in cleaning up and direct communication with users. It is quite difficult to see the real structure of a Wiki from a distance, and to get an overview of all the available content, and the part that is still applicable, as a new user.  
==== Integration ====
A Wiki today is, in a way, a silo of its own, whereas many large enterprises currently seek to reduce the number of applications and increase their integration. The only integration Wikis provide is being able to insert hyperlinks to other resources in the Enterprise which can be accessed via a browser, but even this process is fraught with difficulties, since URLs may contain session IDs. It can be often seen that information that is already available in other sources is manually replicated in the Wiki (in our specific case: phone numbers of employees).

=== Crossing company borders=== 
It is very hard to find satisfactory solutions when companies want to collaborate for some time. If only one partner hosts the solution, the other partners may be reluctant to contribute because they may not be able to access their contributions later. Single sign-on for several partners is hard to realize.

=== Offline access ===
Sales and management spend a lot of time on the road, and therefore need offline access and offline authoring capabilities, otherwise they will always stick with e-mail.

== Goals for Wiquila's design ==

Early in the project, we found it legitimate to look beyond pure browser-based interfaces, towards a more comfortable client. First, most other groupware (e-mail, IM) and document creation applications are installed on Desktops. Second, several Rich Internet Client technologies now exist which combine the Web’s ease of deployment with the Desktops richness of interaction.

The design goals for the Wiquila client were:
* Easy editing of formatted text
* Easy (assisted) insertion of links to Wiki pages and existing information objects
* High productivity for power users – no need to switch from the keyboard to the mouse for common actions
* Desktop integration (Drag&Drop, Copy&Paste)
* Built-in tools for quality analysis and improvement
* Extensibility to account for today’s heterogeneous environment
* Ability to be integrated as a component into Eclipse, and perhaps the Web browser
* Support for cross-company scenarios
* Possibility to access “legacy” wikis
* Scalability and performance
* Security
* Protocols can be accessed from similar clients which are based on different technology (.NET, AJAX)
* Robustness – the client works even if some of the integrated backend systems are not running

One of several driving use cases was the Meeting Minutes use case: A project team meets, at an early stage in the project, and meeting minutes are entered in the Wiki. These minutes contain some free-form text as well as “items”: Todos, Dates, Requirements, etc. We want to make it as easy as possible to create these structured items while entering the minutes, and also allow post-processing of minutes that where entered as a draft, perhaps offline. As the project matures, one may want to add additional structure and links to the minutes, to improve traceability of decisions.