Category: Work

I’m still loving my iPhone, despite it’s foibles (why can’t I send a link of my current location from the Maps application to another iPhone user? Or even a weblink to Google maps? Or.. you get the point).

To capture my current usage I thought I’d jot down the apps I currently have installed. Because, you know, blogs, lists.. etc etc. So without further ado other than the default applications my iPhone runs:

• Twitterific – paid version – still a little buggy but easily the most used application other than the SMS and phone functionality.
• Mobile Fotos – after ditching my Windows Mobile phone a couple of years ago, one thing I missed was Shozu which allows you to upload your photos to Flickr. Shozu is available for the iPhone but Mobile Fotos is a more rounded application.
• Digital Clock – I have a dock, and can set this application running, set an alarm (turn on Airport mode) et voila, my own alarm clock. Oh yeah, you need to change the screen timeout as well. ONE app to do all of those settings would be worth money to me.
• Instapaper – paid version – a simple bookmarklet which I was already using to track articles to read later on. The iPhone app lets me read them when I get a few spare moments (yeah, on the loo!).
• Airsharing – free version (was only available free for a limited time) – lets me easily moves files to and from the iPhone meaning I can do away with my other USB drives.
• Zenbe – a list application that syncs from the iPhone app to my online Zenbe account and vice versa. Has replaced TaDa lists for me purely because of the iPhone app.
• Here I am – a simple app that emails your current location (long/lat). Haven’t used it much, kept ‘just in case’.
• Movies – to quickly find the latest movie times, not used often but v.useful.
• Palringo – a bit like Trillian, lets me log into multiple chat clients on my iPhone. Not used often.
• Light – cos sometimes you need a completely white screen when you don’t have a torch handy.
• VNC – so I can VNC to my computer. Works FAR better than you’d think!
• WeightTrack – in an effort to lose some weight I thought I’d gadget/geek up and use my iPhone. Had the application for 3 weeks and entered 2 weights so far. Must do better!
• iChoose – a coin flipper/decision maker type app. Silly but.. MAY be useful someday?
• Cube Runner – simple tilt based game. Navigate the ‘ship’ through the cubes as you fly through them.
• Lightsaber – ohhh shut up. I’m a geek and I like Star Wars, I can’t NOT have this on my phone!
• iPint – really should delete this…
• Monkey Ball – another tilt based game, guide the monkey in the ball through the courses. Simple, frustratingly hard!
• Brain Challenge – a nice diversion which has the added benefit of stimulating your brain, keeps track of your progress too.
• HoldEm – poker game which is curiously addictive and has helped me understand poker a LOT better.
• Oblique – an iPhone app of the Brian Eno Oblique Strategy cards designed to inspire you to think different.
• Last.fm – installed after a recommendation, have yet to do much with it.
• Simplify – iPhone app to hook into the Simplify Media server which runs on my home computer (primarily to let my PS3 see my ‘media’).
• TV Plus – tv listing application that can hook up to your Sky account and send remote record requests! VERY slick and waaaayyyy better than the sky website. In saying that I think my Sky box needs set up again or something as it’s not managed to work for me, yet.
• PhotoFrame – nice idea this, if you set the screen timeout to never turn off, run this app you get a digital clock, date and picture slideshow. Only 6 photos at present but looks good. Another app that would be way better if IT could change the settings for the screen timeout (if it’s docked and getting power, leave the screen on).
• Exposure – location based photo app (amongst other things) which I don’t really use. Can pull Flickr photos based on location… interesting but not hugely useful.
• Vicinity – location based app that will give you listings of useful numbers (restaurant, taxi and so on) depending on where you are. Not often used but COULD prove useful in the future.
• Google – quicker than firing up Safari and going to the search bar there, that’s the only reason I use it.

I also have home screen links to Google Reader and the new iPhone optimised Flickr webpages

Blimey, that’s more than I thought. There are a couple there I should remove and I’ve installed at least twice as many as listed here but ultimately these are the ones that currently work for me.

I know a few of you have iPhones (and yes I know a few of you think they are over-hyped) so do let me know if I’m missing out on the MUST HAVE application, won’t you?

Where does the ‘documentation manager’ fit in an organisation?

As our company grows and we push ourselves to be better it is envitable that some people will end up in slightly different roles than they envisaged. Thankfully my current company isn’t too bogged down on job titles and org charts, preferring to make sure that roles and responsibilities are defined and allow people to get on with getting things done.

So, I currently find myself conducting a mini content audit, across most of the company, in an effort to find the big gaps that may or may not exist (ok, that definitely do as every company has them) and working with a couple of other people in different areas of the company to make it happen.

It’s a switch away from concentrating on writing and managing the product documentation but it is an area I’ve long since considered something that someone in my position SHOULD be driving forward.

This exercise has given me the opportunity to touch base with most other areas of the company, and it’s telling that very few have a full product view. In fact I’d say it’s fair to say that none of them have (and rightly so) and so I often find myself pointing out that documentA is already in progress by teamB, so teamX doesn’t need to do write their own.

It also means that, once we have finished the audit and written up the missing information, we should have a cohesive and complete story through all the various touching points our customers have with our company. It should make our offering easier to sell, easier to understand and back up the fact that our product is excellent and our staff are a bunch of smart people!

I have a double interest at play here though, as I also have a developer community which I need to feed far more regularly than I have been, so any content is ‘good content’ as far as they are concerned.

An interesting time which, once again, reminds me why I love this profession of ours, after all who else gets to stick their finger in so many pies.

Tom Johnson has had a look at the survey recently published by the HATT matrix website on help authoring and, by pulling in the results of some other surveys in the same area, has extrapolated some good conclusions from them.

He rightly points out that surveys need to be taken with a pinch of salt (he goes into the detail of why this is so), and that whilst the numbers involved would seem to be high enough it’s likely that the questions themselves need further consideration in future.

That said, there are two things I took from his post.

1. Know the problem before picking the tool
You may not be in the position to switch authoring tools, but if you are and you have investigated the market then please make sure that you are buying a tool that addresses the problems you have.

The presumption here is that if you have a legacy tool (like we currently do, FrameMaker 7.1) and it still works and meets your requirements then there is no good reason to upgrade. I’ve been victim of buying into the ‘keeping up’ frenzy that software manufacturers like to generate but once a product is reasonably mature it is likely it has most of the features you need already.

I’d offer Microsoft Word as an example here, I could probably still use Word 2.0 for the few documents I maintain in that format as the newer versions add functionality I don’t need (and which has ended up intruding on my workflow at times!).

The X-Pubs conference a couple of years ago had a common, if not publicised theme. Almost all of the presentations included the advice to figure out what problems you had, before deciding IF single sourcing (using XML as the base format) will help and that’s even before you consider the tools themselves.

2. DITA is still a theory
Whilst it is true that the number of people leveraging DITA for their content is rising, the numbers remain low.

Partly that will be due to the fact that few organisations/teams/people are in a position to quickly switch just because a new technology has come along, but and I’ve said this before (in fact I’ve said that I’ve said this before!) rollout of DITA remains harder than rolling out a bespoke authoring tool.

When costing an implementation of a new tool there are various factors and it’s very easy to see that you can get MadCap Flare up and running quickly, where as a DITA based solution takes investment in developing the environment. This is beginning to change but, as yet, the phrase ‘DITA support’ really only means that you can output to a DITA formatted XML file. The tools aren’t constructed around the DITA concepts, so you immediately lose a lot of the benefits that DITA can bring.

Until there is a tool that fully leverages DITA, building it into the workflow of using the tool, and helping the concepts become part of your daily working practice then it will continue to be a marginal player.

Which, in a way, is how it should be. DITA is not a tool, it is a technology and methodology. It is there to support the toolset and the writer. It’s just a shame that tool vendors continue to believe that THEIR format is best, refusing to budge from that position and shoe-horning ‘DITA-esque’ features into their software.

Anyway, the rest of the survey write up is interesting and worth a read but, as Tom says:

“I do love these surveys, though; if for no other reason than they give us something to talk about”

Every company is unique. Every company has their own processes, their own documents and, of course, their own language. That language is part of the culture and if you don’t embrace the new language it’s likely that there will always be friction and, worse, misunderstanding in the future.

Take, for example, the process documents you work with. Regardless of industry there is usually some form of communication that contains the requirements of what you have been asked to build, and after that it is likely there will be a more detailed communication that outlines what it will take to meet those requirements.

Previous monikers for the former, that I’ve come across, include Market Requirement Document, Business Requirement Document, Request for Enhancement and so on. The latter I’ve seen referred to as Functional Specification, Software Requirement Specification and Build Plan.

Which means, culture/language wise, I’ve spent far too much time reading MRDs, RFEs, SRSs and so on.

But the key is that whilst most of these documents do, essentially, the same thing, I’ve happily switched my language to incorporate these new terms. It’s not a big switch but it’s a crucial one which helps me frame my work in the correct terms. These things are, by and large, considered a small deal by many, but getting the culture right and buying in to that culture is key to building a successful team.

We are nearing the end of a release cycle and will soon be starting the next set of workstreams and, excitingly, we’ve managed to push the involvement of the technical writers right up to the early design stages.

What does this mean?

Roughly speaking the process of creating the stories is one part of the scoping and planning stages of our development cycle. Each feature is broken down into a set of requirements, and those requirements are further broken down into one or more stories. The stories are then broken down into discrete work tasks (a few days work at maximum).

The stories are stated in terms of “the user would like to … ” and are used to help the developers understand what they need to do to meet the requirements. We are hoping that, by writing them, we can both be involved in the early design stages as well as gaining an early start on the product documentation. The stories will become the concepts for the documentation, and we can then flesh out the tasks and reference information as and when the development work is completed.

Be interesting to see how well it works, but hey it’s worth a try.

Last week we held a shortened Kaizen-style event in which we discussed the requirements capture part of our product lifecycle. It was an interesting couple of days which yielded a new process that we think is an improvement on the previous one. That makes it sound very simple, it certainly wasn’t, but it was a fascinating couple of days.

As I’m responsible for the technical information that comes out of the development group, I had a slightly different view of things and took away some ideas to discuss with my team of writers. One of which we have discussed a little but haven’t yet pushed too hard. I think that is about to change.

Going back to our requirements capture process, one part of the new process suggested some additional information that should be provided with the business case attached to a requirement. That got me thinking.

At present we (my team) face a backlog of information which was never previously considered nor written up (an oversight by my predecessors) and we’ve been trying to tackle the backlog as well as keep apace of the new features being added. Ultimately this has proved futile and we’ve discussed ways to get around this. More resource is one option, but another would be to work smarter and only provide documentation based on a priority basis or, for want of a better description, based on a viable business case.

The question I’m pondering is whether we go the whole hog and make documentation requests part of the requirements capture process, or use our own understanding and knowledge of what is required and build our own business case.

It’s, hopefully, a fairly unique situation but I’d still be keen to hear how you handle incoming requests for documentation?