Recently I’ve been toying with some software tools to try and focus my writing a little better, stumbling across an application called Q10. A full-screen text editor which is, according to the website, “a simple but powerful text editor designed and built with writers in mind.”

Whenever I start a new piece of work I tend to write up notes in text files first, before moving them into FrameMaker for formatting and publishing. This was largely borne from limitations in Structured FrameMaker, and sits well with our usage of an internal Wiki for content collaboration. Q10 helps with this approach by doing one thing very well.

Like most well-designed products, the features are usable out of the box, but there is enough scope for tweaking things to get a system that suits you. The full-screen aspect of Q10 is the most important, blacking out the rest of the screen and leaving you with a blank slate on which to focus your thoughts. There is no menubar, with options only available through keyboard shortcuts, including one to turn off the typewriter noises which I’ve left on as they are somewhat soothing… oddly.

You can set the file encoding, a target number of words (handy if you are writing an article), change the font and colour settings, and it supports quick text allowing you to replace given character combinations with whatever you specify (I use this for product names, although you have to search and replace on the underlying text file if the name changes).

At first I was only really using Q10 for writing blog posts and articles, but I’ve started to extend it into my set of ‘work’ tools and it’s proving very useful. Sure it gets some odd looks as people glance at your screen but I certainly seem to be more capable of focusing on my writing these days.

I’ve tried a few other full-screen text editors (for Mac and Windows) but as the bulk of my writing time is spent on Windows machines, Q10 is proving very useful. Best of all it’s free!

The tool is not important. The tool is not important. The tool is not important.

I have been repeating this mantra in my head for the past week or so, over and over, like a broken record. I’m in the middle of pulling together the requirements and scope for a new technical community website for our users, which will become the key focus of our technical information. The more traditional product documentation set will be maintained as we move forward, so there is some thought to be given towards how we manage the information as well as how it is published, or rather where.

I must stop considering the how. The tool is not important.

At present I have a list of requirements, all of which I’m thinking through from the point of view of how the process will work as far as creating and maintaining the information. Who will be access the source, who will be viewing the published information, who can edit what, how will the information be used by the audience? All the while there is a part of my brain dragging me towards HOW this will work. What tool will be able to handle our requirements?

The tool is not important.

I enjoy a challenge, and this is most certainly a new venture for me, but the basic foundations of this idea are rooted in things I know well, single sourcing content, developing online communities (I run a website for Scottish Bloggers (currently dead after our hosting service disappeared)). As such I’m confident I can get this off the ground, but even so I’m being careful to properly gather requirements, and fully understand the impact of changing our publishing model. Note I said “model”.

The tool is not important.

So with a list of requirements, and a full understanding of the processes that will be involved both to maintain the main documentation set and the development of other supporting information (culled from internal Wikis, mailing lists and anywhere else we stumble across something useful) one change is the way in which we plan, design and write product documentation.

As I’ve said, this is all about the processes that support the way we work. I’m being quite deliberate in how I pull together the requirements, focussing discussions on the audience, the expectations, the information and processes, with no mention of the technology which will need to support the new website.

The tool is not important.

Last year’s X-Pubs conference drilled this message home, and it’s good to be able to draw on the information and knowledge gained there. Get your requirements sorted out and agreed, understand the impact of changing the way people access information, and the impact of changing how people work, figure out how best to handle the reaction to change and agree the expectations and limitations of your system. Decide which models you will follow, how the processes will hang together and outline the various roles that will be required, and make sure they understand what is required of them.

Then and only then should you consider what tools you require and make sure they are serving you.

Deliverables are dead. Long live multi-format, anytime, anywhere delivery of information!

The more I think about it, the more I am beginning to see that creating content, writing and styling and planning, for “print” is no longer valid.

Quick caveat: Know your audience and the requirements. Many places mandate printed documentation in one format or another. I am purely talking about my own experience in a software environment.

I’m the first to admit that whenever I start thinking about updating a manual I think in print terms. I think of entire chapters of information, I think of how the user will be able to navigate and understand the layout and construction of the document. Changing those habits is proving hard but I’m slowly getting there.

Part of that change has come about by focussing on the information types we are going to be using as the building blocks of our single source system. Making each topic unique and complete within itself requires some thought and planning, and with that planning being focused on tasks, you soon get a simple outline of the required documentation including the type of information that you’ll be writing for each chunk.

As that realisation begins to sink in, the possibilities of re-use suddenly make themselves clear. It becomes a simple matter of drag and drop to create an entirely new manual, and a new delivery method becomes a simple matter of publishing to a new format.

The latter fits nicely with some current thoughts around how we get our technical information to our customers. Whilst I don’t think Author-IT would be the best solution, or at least the complete solution, I can see us focussing more on a web-based delivery of information, pulling other available content (from mailing lists and wiki pages) into an MSDN-like community website. Add in a blog and some interaction and it could very well be the shape of things to come.

As I’ve mentioned before, for a lot of people in the software industry, the internet is THE source of information. So rather than try and force how we want the information to be delivered (maintaining legacy documentation) I’m looking at how we can deliver something our customers will use, without succumbing to the Web 2.0 crazies. Yes it could have a blog, but does it need one? Yes we could use Twitter to provide ‘from the floor’ thoughts from the development group but who would sanitise them first!

Wikifying the doc set (to borrow a phrase) is a possibility of course, but that would only be part of this solution, and would have to include the ability to package it up as a different deliverable (PDF for example) so the information can be accessed when the internet isn’t available, a requirement of our documentation.

There are other considerations of course, all of which are still being thought through and will need discussion and buy-in.

Exciting times ahead I think. More on this as it develops.

How do you do it?

I’ve conducted a fair number of interviews over the past few years, not a huge amount but definitely into double figures. Some have been good, some not so good, and some just embarassing.

I recently read about an interview that was more like a planning meeting, outlining the job in terms of the issue that was being addressed, discussing requirements and asking for ideas. As a way to evaluate how a prospective employee works, and how they would fit into your organisation or team, it makes some sense. I’d still use the more traditional question and response session as well, but this has gotten me thinking.

Are there other, better ways, to conduct an interview?

Just for kicks, here is my typical interview routine:

1. Meet and greet with a firm handshake and set the tone with a friendly enquiry. Check that the formalities have been dealt with (interviewee has signed in and has a pass).
2. Take them to the location of the interview, usually one of our meeting rooms.
3. Outline the interview process to them.
4. Give them a tour of the building, and talk a little about the history of the company, and point out some ‘how we work’ stuff.
5. Back to the interview room, offer them a drink (coffee, tea and water will already be there).
6. Then chat with them through their CV, asking them to explain and expand on certain points. I do ask for examples of work as well.
7. I’ll then expand a little on the role they are interviewing for, and go over some of the employment terms.
8. Then it’s final questions and we’re done.

It’s point 7 that could be expanded to be more of a scenario based discussion, and whilst I do use that approach on a small scale when I’m asking them questions, it might be interesting to outline a larger scenario and see how they handle that.

I’m always looking for better ways to do these things, as interviews can be hit or miss for both participants, so anything that would help keep it interesting and engaging would be beneficial.

Do you interview when hiring new staff? Any favoured approaches?

As I mentioned before, we are planning to migrate content from FrameMaker to AuthorIT, staging the migration across two different product sets (and no small amount of time!). I’m in the process of evaluating AuthorIT for, despite having used it before, it has recently been overhauled with a spiffy new UI and some new features.

AuthorIT is a single source system, with content stored in a central database, which can publish to most (all?) of the formats that anyone would ever need. It includes an editor, supports multiple users, and has some additional add-ons for localisation and so on. Their website is very good if you want more information on their product.

After downloading and installing the trial version, which limits your import and publishing but otherwise has all the features available for use, I fired it up and was greeted with the new interface. Based on the ribbons used in the latest version of Microsoft Office, it is quite a shift away from the previous version and it took me a while to get to grips with. However it is a huge improvement over the old version and once you are used to it, like anything, it’s very nice to use. Yes I know there are still issues being dealt with, but I didn’t run across that many during my testing, so I’m happy.

During my evaluation I spoke to their Business Development Manager who was very helpful in delving into some of the issues I had around versioning and set my mind at rest. I’ll outline how we are going to handle maintaining multiple versions of documents in another post, once I’ve given it a dry run or two.

One issue that cropped up was the location and format of the supporting database. You can run AuthorIT on a Jet database either locally or on a network drive although that is particularly performant, or run it on a SQL Server. As we are a small team I did consider the Jet database but our situation suggests a server database would be better. Which introduced another problem, price. SQL Server isn’t the cheapest and we don’t have an installation in-house. Thankfully one of our IT guys suggested SQL Express (a limited free version of SQL Server) as a possibility, and after a quick check on the AuthorIT Yahoo Group, I’ve found that it will run quite happily on that database.

There is a limit of 4GB on the database size but as long as we keep our images elsewhere there is little chance we’ll hit that limit. Our total content at present, including images, tops out under 500MB for one version of the documentation. So we’ll actually be saving space on a server as we won’t be maintaining multiple versions of entire documents. Must remember to point that out to our IT guys!

Aside from versioning the only feature I was unfamiliar with was the batch runner, which allows you to run a batch file (.bat) as a scheduled task. Our current system runs at night, using Webworks to create a Javahelp file which is then included in the software build and AuthorIT will give us similar functionality.

Why AuthorIT? Well, quite simply it gives us what we need.

I spent some time at the X-Pubs conference last year, and throughout the presentations the underlying message was “get your requirements sorted before hunting for a system”. The premise is obvious enough, if you decide on a system first, you end up shoe-horning your processes around how it works rather than getting a system that works you way YOU work.

I also spent some time considering DITA but ultimately switching to an XML-based system is still too cost-prohibitive. AuthorIT is a compromise, allowing us to work how we want to work, whilst giving us single source benefits. We will use DITA as a framework for how we plan and write the content, but the simple fact is that AuthorIT is a much better value proposition than a bespoke system, both in monetary and resource terms. This makes the business case much easier to sell.

If you are considering single sourcing your content, then I’d strongly suggest you investigate AuthorIT as a possibility. It has limitations, including the oft-cited reliance on Word as a publishing engine, but for me the advantages outweight those.

And no, I am not being paid to endorse AuthorIT.

Working with text, and graphics, can be a time consuming job. If you are like me you’ll know many keyboard shortcuts, some of which will be used repeatedly throughout your working day.

For example:

• CTRL+C
• ALT+TAB
• CTRL+V

Go on, who can hit that oft repeated key combination without even looking at the keyboard (you touch-typists can shush).

Cut and paste is so frequently used that it is often overlooked, yet it does warrant some thinking. I’ve tried adapting the way I work in the past but it turns out that I use a variety of different tools for a variety of different, yet very similar, tasks and the tool chosen largely depends on my mood.

I sometimes take text from an email into a Word document, sometimes I’ll start in Notepad (Notepad2 actually) and go from there, and other times I’ll just be moving things from one place to another in a FrameMaker document. The process is the same, cut and paste, cut and paste.

The flaw comes when you need to multiple items in multiple locations, leaving you flicking between windows and trying to remember what you last CUT so you PASTE the correct thing… how many times has that gone wrong for you?

Clipboard managers, as such pieces of software are known, have been around for a while, but I’ve never managed to work one into my workflow. Typically they are only need now and again but as that is the case how do they know WHEN they are needed, and when not?

I think I’ve found the answer, and it goes by the name of ClipX (yeah, the title of the post was a bit of a giveaway). It is a light-weight, unobtrusive clipboard manager that, with a little tweak to the default settings, makes it very easy to have the ability to go back through the previously copied items, without getting in the road of the more regular, one-to-one copy/paste activities.

If you download and install the application, you need to change one of the Popup settings. Right-click the icon in the system notification area, select Configure and then, on the left of the Configuration dialog, select Popup. Change the Default item setting to Last clipboard and you are good to go. I’ve also turned off the search and limited the number of items.

The really smart thing about ClipX is that it also handles graphics. I’ve been doing some web design work recently, hacking away and creating some basic graphics for the site. This is what my current CTRL+V action looks like (hitting Enter pastes the selected item, with the top-most, or most recent, item selected by default):

Smart, isn’t it.

Admittedly my infatuation with this little application may be because I’ve finally adjust the way I work to accomodate such a tool, but I like to think it’s also because it is an application that takes something simple and makes it work.