* mod_speling is better even than the original red squiggly line spelling error code because it’s client-server

•  WYSIWYG
  • UI is so important.  TinyMCE isn’t a complete solution but it gets a lot closer.
• Presentation
  • Wikitext actually does pretty much everything that is required for most business documents but printing from a wiki doesn’t give you the same result as printing from Word.
  • Similarly, exporting to PDF or DOC doesn’t have the same utility as creating it in Word from the start.
• Sharing
  • Strange that this is a problem with a wiki, isn’t it? In real business, wikis are locked down to prevent access from outside the company, yet often revisions to documents come from partners, customers or suppliers.  These people are not going to get access to the entire wiki but there is no mechanism to provide access to only one page either.
  • Part of this problem could be solved if it were possible to import & export versions of a page.  If a document was exported to RTF, edited in Word (or some other standard business tool), saved and re-imported, many of the benefits of a wiki could be maintained and users that don’t have access could still contribute.
• Versioning
  • One of the biggest advantages to me in a wiki is being able to see the changes that someone else has made and this is generally held to be one of the real strengths of a wiki.  Yet my standard Word Processor shows me the changes others have made in a document much better than any wiki. This is an area in which a wiki should shine.
  • Suggested UI inspiration:
    • Time Machine
    • Word
• Using Data
  • Tables in a wiki are painful.  They are painful to create, painful to edit and they don’t really do a lot.  With the addition of a WYSIWYG editor, things improve a great deal but they are still static. We can import a near-infinite number of templates, yet we can’t add up the numbers in a column?
  • Maybe I’m overloading the concept of a wiki to include a spreadsheet; perhaps a wiki should just be for text and there is a better tool for numbers. Really?

My feature list (in no particular order):

• Integrated publishing and knowledgebase with transclusion from/to and tight integration within:
  • Web-facing publishing framework for internal and external publishing of static and mostly-static documents featuring
    • Workflow, versioning, i18n, smart folders or collections, pervasive RSS
  • Multi-author shared knowledge store (wiki)
  • Timelined journal/commenting system for team members (blogs)
• File repository with native & web interface, able to cope elegantly and securely with a distributed architecture
• Remote partner/client/conrtactor file delivery & collection system
• Shared calendar system that links to published material and provides freebusy
• Email with simple yet powerful server-side filtering and cross-platform compatibility
• Contact database
• VPN
• Voice, Video & Text IM
• Bug/issue/task tracking
• Asset tracking
• Accounting & ERP
• CRM

• First-up, we’re dogfooding, which requires that we keep things reasonably usable at all times but it also means that we are going to focus on those areas that we use most internally, at least during the initial development period.
• We intend to release early and to release often, especially during the development and beta process.  Once we have production-ready code, we anticipate forking development into stable and head branches, with stable only receiving bug-fixes and a much more predictable feature upgrade path.
• During the early phase, we are very heavily focussing on getting things working in broad strokes and will almost certainly go down technological dead ends.  In these cases we will attempt to provide a migration path but watch for announcements that we consider the suite ready for testing and that we will be supporting migration issues.
• We value working code over theories.  Although my 5 pillars may be a good basis for the ongoing development of the project, if we have to make a choice between code that works right now and missing the feature, in early versions we will probably include the feature, document the implications and work to resolve them in the drive toward V1.
• It’s collaborative; we are creating a package that helps us to create culture, so we hope to encourage a culture that helps us create good code.  Please give feedback, patches and suggestions as we go.

This topic deserves more than this quick visit but I needed to get that off my chest quickly so that we could move on to the features!

However, as I alluded before, the same software is intended for use at much larger shops, not only as the smaller teams inevitably grow to work on larger projects but through direct adoption by enterprise.

We see this suite as being the most integrated and genuinely useful software of its type in the world and are working to provide enterprise-grade availability, sophistication and utility into the hands of content creators worldwide.

Simplicity does not infer a lack of power, although it is often achieved by paring down the base options for an end-user to reduce potential for confusion and then relying on extensions or modules to add these options only when needed (as has famously been achieved with Firefox).  We will aim to achieve a very similar outcome by identifying the absolute core requirements and then having additional modules that expand the offering.

However, the focus is on harmonising the user experience, keeping common UI concepts throughout the suite and requiring minimal configuration to achieve complex goals.  We may use wizards and other configuration tools but the emphasis is on keeping the default configuration useful.

One of the ways we’re working on this is to get a list of requirements from other companies nearby that might consider using the bundle and rolling it out to other early-adoptors as quickly as possible. The sooner we get a wider usage range, the sooner we uncover the problems that might limit us. Also, if you’re on the lookout for this software, please let us know how you want to use it, what features you think are most important and how you would evaluate the package. This feedback is invaluable to us.

By selecting the components of this suite to be best-of-breed, with active extension communities, we support maximum flexiblity because users can take advantage of these communities, multipling our own efforts.

It’s actually pretty easy to create a nearly perfectly secure computer; just cut all of the cables leading to or from it and encase it in a couple of tons of concrete. It’s not especially useful but it is very secure.

This problem is worse in a modern content business. Creative people are notoriously intolerant of security and will work around almost any system that gets in their way, so it’s especially important that the system be designed in such a way as to work seamlessly with the workflow of the business.

We want the security profile to fully support the complex business relationships that are often found in large content businesses and traditionally have been impossible to securely maintain in smaller shops. External contractors, vendors, clients & partners all want/need to have access at different levels to your network. Perhaps a contractor or vendor just needs to upload a completed asset or download some concepts; this should be managed as a part of a complete security framework that supports this kind of usage. Trusted partners may have the ability to access, perhaps even to contribute, to your knowledgebase; read notes on various aspects of a project, review work that has been done, file or resolve bugs. This type of system is almost a prerequisite for effective outsourcing. When you have simple control over the level and type of access that is provided and it is done in a structured, secure and auditable manner, great productivity benefits are only a few clicks away.

This does not mean that you “open the Kimono” to partners, in fact, entirely the opposite. With a modern security and permissions system in place partners only have access to the information that they are supposed to, instead of using whatever horrible kludges and workarounds are in place at the moment, unaudited, not even verified and probably not authorised.

There is no panacea and we will have to work hard at ensuring our codebase and processes remain stable, resiliant and well supported.

• Stability
• Security
• Flexibility
• Simplicity
• Scalability

All of these issues are critical; the software must be rock solid because it is the very heart of our users’ businesses. It must (always) have no exploitable bugs and be highly secure while allowing powerful interactions and enabling users. We cannot imagine all of the ways that games and digital media companies will want or need to use the software so it must be sufficiently flexible that they can make it work for them. It must be simple to use and “just work” without the UI or usability concepts getting in the way. Finally, the software must be cheap and able to run reasonably with modest hardware and low overhead for small groups yet also scale up to support large companies with studios in several cities.

None of this is easy and we all know that it will be a journey not a destination, yet it’s important that these five pillars remain uppermost in our minds as development continues.