Communicate
This is essentially a glossary entry for Communicate. I often write about Communicate's development in the blog and thought a quick overview would be useful.
Communicate is a desktop application that Watershed staff use to administer the data that is used in the creation of the Web site. Communicate is also used to control display aspects of the web site. Communicate runs on Apple Macintosh computers running MacOS X 10.3 or later and is written in Cocoa by Watershed's Communications department.
Watershed's Web site contains constantly changing content and it was decided to build a desktop application to administer the data. A desktop application has many advantages of a web application, especially in 2002 when there was no AJAX, widget toolkits, Javascript libraries… etc. A desktop application has speed, ease of use and a familiar interface. The disadvantages include platform dependence, version concurrency and development time. Work began on Communicate at the beginning of January 2003.
Communicate is a reasonably modular construction. The application itself uses a number of plug-ins and bundles to provide functionality and sits on frameworks that provide the data and ensure it is available to the Web site. Essentially, Communicate is just a collection of user interface elements.
Database Libraries
The OpenBase frameworks and MySQL C libraries are used in database plug-in modules that provide network access to the databases. The plug-ins are relatively simple and just read and write data over the wire to the database. Currently we have written just the two for accessing OpenBase and MySQL databases, but adding more database plug-ins is relatively straight forward.
FBTFPersistentObjects Framework
The FBTFPersistentObjects framework provides object persistence for business objects. It handles archiving and unarchiving objects to a data store, caching and uniquing. The persistence framework can be thought of an EOF lite, similar to Ruby on Rails' Active Record or other ORM libraries.
WSHDCoreData Framework
When starting the project, I decided to model Watershed's operations in a business logic framework rather than just build another Content Management System. By modelling the organisation's data and operations we get a framework that accurately describes Watershed but ,more importantly, is reusable. The WSHDCoreData framework can be used in any application Watershed needs to develop, such as a cinema audience tracking, exhibition planning… etc. WSHDCoreData contains the classes that describe Watershed: Events, Exhibits, Media, StaffPositions , Locations and the XML mapping file used by FBTFPersistentObjects to map to the persistence database. There is a companion framework WSWOCoreData, written in Java, that is used by server based web applications. WSHDCoreData has nothing to do with Apple's CoreData persistence technologies. It was named to describe it's purpose at Watershed before we were aware of , and Apple demonstrated CoreData.
Communicate
On top of the frameworks is the desktop application Communicate. Communicate provides access to the data through a series of list windows. Staff can add, edit and remove items from Watershed's programme.
Communicate will load plug-ins, from inside its own bundle, at launch time to provide control over the Web applications which generate the site data. In effect, these Communicate Site Plug-ins just save their changes into a shared preference database. An abstract plug-in class makes writing these plug-ins a quick and simple task. For most plug-ins, almost all the work can be accomplished in Interface Builder using Cocoa Bindings.
Further Development
Communicate is being developed and extended and this will continue into the future. This includes new features to support new site and Web application features, UI and workflow enhancements and performance optimisations We learnt in the past that creating a new shiny site and just sitting back is guaranteed way to create lots of work in the future and a repetition of the process in an endless loop. We have made an internal commitment to constantly improve the watershed.co.uk sites, gradually over time, for an indefinite period. Some of the features we would like to add to Communicate in the near future are:
- Comprehensive Applescript support.
- A plug-in architecture for import, export and actions. Probably allowing plug-ins to be Cocoa bundles or AppleScript files.
- XML Import & Export plug-ins.
- A more user friendly and intuitive UI centred around a publishing paradigm and not requiring the user to have a knowledge of the underlying frameworks data structure.
Scriptable Applications
AppleScript is thought of as an 'added extra' for desktop applications but for internal tools it should be an essential on the 1.0 feature list.
Many shrink-wrapped, commercial applications do not add AppleScript support until later versions and with internal tools developed in-house it is an even lower priority. Many of these internal tools have a quick and dirty UI and none, or little, online help so being scriptable is not very likely.
With Cocoa applications adding AppleScript support is relatively easy and quick to implement. This is certainly the case in applications that are strongly based around a business logic model with data objects, as many internal tools are, and are already Key Value Coding compliant. Cocoa AppleScript support will do lots of the work for you.
So why should an in-house developer make their applications scriptable?
AppleScript support will free up developer time. If I write a scriptable application, the staff members who use the app or Oliver, Alex or Paddy of our ICT department can add new features or work around bugs without waiting for me to deploy the next version. I can spend my time implementing features that really need to be done rather than a feature to 'duplicate every cinema screening in Cinema One on every second Wednesday in the month'.
Watershed will gain from increased productivity from a scripted workflow. We could save so much time with a script that created the web data from the brochure:
tell application "Quark XPress"repeat with every text box in the front documenttell application "Communicate"set newExhibit to make new Exhibitset the title of newExhibit to the first line of text boxsave newExhibitend tellend repeatend tell
AppleScript support is a springboard or stepping stone to an Automator Action that even more users can make use of with even less training. Actions can be built by the users or by our ICT department.
If I ever left the Watershed, being able to implement some new features using AppleScript would give the users and ICT a breathing gap before a new developer could be employed and was up to speed with the application.
There are many other reasons to make any application scriptable that are often just applied to commercial development. These are just some reasons to add AppleScript support to internal tools.
Web Horizontal Layout
After a gap of some time away, it's time for another horizontally scrolling site for an artist's residency.
I've just started work on a quick, small site for Jackie who needs something for her residency at Pontypridd railway station. The site just needs to provide an online diary and some brief background information. So Jackie can update the diary quickly and easily I've decided to make her a RapidWeaver template.
It's been three years since I last worked on a horizontal layout for the Digest project and obviously the memories have faded enough for me to start work on another.
I do like the way the horizontal layout forces the content to be broken up into small, neat chunks and reading large amounts of text appears easier. A reader doesn't 'loose their place' quite so many times.
There are plenty of reasons not to use a horizontal layout:
- Not many sites are designed in this way and the user could become confused or not notice the horizontal scroll bars at the bottom of the window.
- Web browser support for content to the right of the viewport is lacking. Browsers will happily scroll the page vertically to follow a fragment link but many do not alter the horizontal scroll position.
- Using CSS to position elements on the page is particularly irksome for this layout. All the content columns need a parent container with a fixed width to force the browser to extend the right side of the box past the window's edge. As the content varies from page to page, Javascript is needed to adjust the width of the page after it has loaded.
My head is telling me to stay well away from this layout but my heart is telling me to persevere and continue. I think it's too late now anyway.