Movable Type on the iPhone

I don’t write much on this blog, one of the reasons being lack of time. Since I spend a couple of hours a day on the train, I wondered if there was an iPhone app which would enable me to write and upload blog entries reasonably easily while on the move.

Unfortunately MT don’t have an app of their own, unlike several of the competitors such as WordPress and Blogger, therefore I tried several third party alternatives and report on their effectiveness here.


The first app I tried was BlogPress, which claims to offer connections to most of the leading blogging software, both online and offline editing and storage, and support for draft and published entries.

Connection to my MT installation was straightforward, and it managed to find all the current entries. Unfortunately it couldn’t distinguish the draft entries, and doesn’t get it right when you try to upload as draft, but that isn’t a show stopper since I’m happy to keep my drafts on the phone.

What let it down was a simple inability to handle newlines. I use Markdown for my editing, and BlogPress has two problems – it insists on replacing newlines with <br /> tags, and worse it compresses multiple newlines (i.e. paragraphs) into one, losing my formatting.

I’ve raised this as a bug with the developer, but currently it makes an otherwise decent solution unusable for me.

Oh, and it also kept claiming network issues, even on a reliable WiFi connection.

Movable Manager

I then tried Movable Manager, a MT specific application which also supports many of the additional fields specific to MT such as excerpts and keywords.

Connection to my MT installation was also straightforward, and it found all the current entries with operation being extremely fast. Unfortunately it has no concept of a draft entry, either offline or online, anything sent to the server is immediately published.

Editing is good, with the content kept exactly as you type it, perfect for Markdown although there is no preview which makes the immediate publishing a bit of a leap of faith. It also has the ability to upload photos, but a word of warning – it silently overwrites existing files of the same name!

On the whole, simpler and more reliable than BlogPress, but lack of offline editing doesn’t fulfil my needs.

Nocs combination

I’d already been using Nocs as a Markdown enabled notepad to edit blog entries and other files, so I wondered if this could be used to solve my requirements.

The big advantage with Nocs is that it is designed for Markdown from the start, and it supports CSS controlled preview, so it’s possible to get a reasonable approximation of what it will look like on the real blog. Unfortunately it doesn’t directly connect to MT, only supporting local storage and Dropbox.

To get the entries from the phone onto the blog I added the iMT plugin to my MT installation to give me a usable control interface on the iPhone. This is a pretty good solution, although at time of writing the part handling comment management is giving an error.

Recommended Solution

At the moment my recommended solution is Nocs + iMT, with Movable Manager useful if you want to upload photos easily.

One thing about iMT is that there’s no option to jump into the full web interface. If this is a problem for you then Nocs + Movable Manager may be more appropriate.

BlogPress iPhone App

This is a quick post to try out the iPhone app BlogPress that I’ve just installed.
Connecting to my Movable Type installation worked fine, and it finds all the existing posts although it doesn’t seem to correctly recognise the drafts.
Writing in the app is OK, the basic option to insert italic or bold text is a bit primitive but it does make adding hyperlinks easier. Support for something like Markdown would be good.
Saving an online draft still doesn’t seem to recognise the result as a draft, and loses some of the line feeds. Also the editor window doesn’t always scroll up in time when typing reaches the bottom, so the insertion point ends up under the keyboard.
Posting on an Edge network also doesn’t seem to work, just giving a network error even though direct access to the site works albeit slowly. Possibly the timeout is set too low, but it can’t be configured.

Strangely saving remotely as a draft, then reinserting the missing line breaks before publishing seems to work, but then they’re gone again when reopening 🙁

Update: The line compression problem is significant enough to make the app unusable for me. I’ve raised a bug report with the developer, maybe they’ll provide an update.

Start at the Beginning

One of the hardest parts of my role is getting projects started, and it sometimes feels exacerbated by poor attempts to use Agile mindsets.

The fact is that a project needs a reasonably clear set of targets and plans in order to start successfully, with a defined order and a some idea of timelines. This is especially important where multiple applications and owners are involved and need to coordinate their work.

From an Agile viewpoint, I’m quite happy to adjust the plans based on experience and refine the details as the project progresses. The one thing I believe very strongly though is that you must start at the beginning.

Of course your beginning depends on your methodology, you can pick requirements, epics, acceptance criteria, data, test cases, etc etc. It doesn’t really matter, although I suspect it helps if each application area chooses the same option (I’ve never done a mixed methodology project of any size, I’d be interested to hear what happens if you run requirements driven and test driven parts in one project).

In several recent projects I’ve found that people are diving right in to the middle of the analysis, with no agreement on useful things like goals, ownership or basic timescales. The culprits are often recent Agile adopters who haven’t done anything big yet outside waterfall, and just throw away all the planning steps and hope they can adjust later.

The problem is that the analysis never seems to finish – how can it with no definition of done… Instead, people jump from one analysis task to the next and we end up with a load of 80% complete parts that don’t add up to anything useful.

I believe Agile planning and analysis can be done successfully, but as with anything in software development you need to follow some basic rules which I would suggest are:

  1. Prioritise – some analysis has a fundamental impact on the project, some is detail or tweaking. Do the big stuff first, or you end up throwing away a lot of work from options later dropped.
  2. Have a definition of done. Nothing is ever analysed 100%, nor should it be. Define how much certainty is needed, and make sure it is sensible and consistent across all tasks.
  3. Write it down and Sign it off. Do it Agile if you can (stories in Jira, great), but make sure everyone is doing the same project!
  4. Timebox and Review. Make sure you are getting somewhere and doing so efficiently, using sprints and retrospectives or something similar.

Of course it isn’t easy to influence this in big projects where no one person is fully responsible, but I have found that by pushing these principles you can move things in the right direction. Retrospectives are particularly powerful in this regard if you can get good open participation.

Mixed Messages


In the IT industry, this classic BIOS message is a byword for unhelpful responses and nonsense requests:

But even now, with usability experts around every corner and end-to-end user testing the norm, I still see some subtle and not so subtle examples…

UBS eBanking – Wrong Password

Put in the wrong password to UBS Quotes and you get this. So if I repeat my entry, will it accept the wrong password? Hopefully not…


Less Haste, More Speed


My team is part onshore, next to the business users, part offshore outsourced where the two scrum teams are. Naturally in an Agile methodology this is a no-no, but rules are meant to be broken and given a choice of remote Agile or no Agile then it’s a no-brainer.

However, one thing we have found is that shorter sprints (two weeks) are actually less efficient and less Agile than slightly longer three week sprints. With overheads like planning and retrospective, the efficiency gain isn’t that surprising, but the Agility improvement is.

I put it all down to the communication lag.

Because the scrum teams are remote, there’s an inevitable delay in communication (although they are at least in virtually the same timezone). In a two week sprint there just isn’t enough time to respond, so ironically the close communication of Agile reverts to the guesses and assumptions of waterfall. In a three week sprint, as long as developers work on tasks in parallel, they have some scope to wait for responses.

It seems that in Agile the old adage of less haste more speed also applies.