Markup rules

texteditterminalI like to use plain text when I can. Plain text is just text without any formatting, which you edit with an app called a text editor, like Notepad on Windows or TextWrangler on a Mac. It’s pretty much a universal format – it can be opened and edited on pretty much any system or hardware you can think of.

One of the things that makes a simple plain text file useful is the ability to ‘mark up’ text within the document.

Markup languages have been around a long time. Perhaps the most famous one is HTML, one of the foundations of the web. An HTML file in reality is just plain text, with the use of HTML tags to mark up how bits of the document should behave – such as formatting and linking to other pages, for example.

Another example and one I use a lot is Markdown, a simple markup language for use in creating documents of all kinds. By simply using characters such as the hash sign (#), asterisks (*) and so on, a document can be made to include italic and bold text, headings at various sizes and bulleted lists, for example.

The key thing is that the document format can be used on pretty much any device and in any application. It’s just plain text, after all. The use of the markup language however enables that document to do more interesting things.

What’s more, you don’t have to be a developer or anything to start your own markup based project. You just need to define a few rules, and get going.

todotxt-apps_lrgI’ve just started playing with another great example of this. It’s called todo.txt and is a way of managing a todo list in a plain text file.

The rules are straightforward. Each task exists on a single line of text. Markup in that line can add information about the task, so for instance a word following a + sign is the name of the project that task belongs to (allowing you to group tasks by project, for example). You can also add a context to a task by following the @ sign with a word. Priorities can be added to tasks by using (A), (B) and so on to the beginning of the line.

Here’s an example of what a todo list looks like:

(A) Call Mom @Phone +Family
(A) Schedule annual checkup +Health
(B) Outline chapter 5 +Novel @Computer
(C) Add cover sheets @Office +TPSReports
Plan backyard herb garden @Home
Pick up milk @GroceryStore
Research self-publishing services +Novel @Computer
x Download Todo.txt mobile app @Phone

You could just manage your list in the plain text file using an editor – and many people do. However, because of the open nature of the format, other options are possible.

First, saving your todo list text file in a service like Dropbox makes it available across the web, so you can pick it up and edit it across many devices, which is helpful.

Even better, there are apps for mobile devices to help you manage your todo list. These present your todo list as a more traditional task management app would – but all the time they are just updating the text file using the markup rules.

This means all your tasks aren’t locked up in some database you’ll never get access to. You can take your text file todo list away any time you like and manage it in a different way.

As well as being a neat hack, todo.txt makes me wonder what other applications could be based on the simplicity of a plain text file and a few markup rules.

Any suggestions?

Collaboration – 10 steps to success

collaborationDigital tools provide great ways to collaborate online. Whether working with a smallish team to co-create a document, or engaging the wisdom of the crowd to build a list of ideas, the net allows us to work with people at a previously impossible scale.

But how to do so effectively? There’s nothing more depressing than a collaborative project that nobody wants to collaborate with you on; or a popular collaboration that runs out of steam, or drifts off at tangents.

Here’s a ten step process I’ve come up with to help your project succeed.

1. Identify who might be interested

There’s no way you will pinpoint every person who might be interested in what you are collaborating on. However, you should be able to spot the people you are aware of who will definitely get things going. This might be because they have a track record of getting involved on this issue, or that they know their way around these kinds of processes. Either way, they are useful people to have around.

Reach out to these folk and let them know what you are planning to do. Keep the specifics around the tech side of things vague, but recommend they encourage others to get in touch, so you can use other people’s networks to create a bigger list of initial collaborators.

Also find out at this stage roughly what level of tech-savvyness there is among this initial gang. Find out how they like to communicate – do they prefer email, discussion forums, or are they happy getting their hands dirty with a wiki? This will help inform which platforms you choose.

2. Put a platform together

Bearing in mind what you found out in step 1, decide at this stage what system you want to use. The fundamental factor is to keep things as simple as you possibly can. Other issues include whether you want to host it yourself or are happy for the content to be sat on someone else’s server, and whether you need to restrict access.

On the first point, by and large hosted platforms are far easier to set up and use and often are more functionally rich than those which you manage yourself. On the second, make it as open as possible, so that there are few barriers for people to get involved.

Make sure your decision on platform and process matches the research you’ve done with your initial user group in terms of the way people collaborate. Are they happy editing other people’s work? Would they prefer commenting, or submitting ideas?

Getting this right is important, but it shouldn’t get in the way of starting your project. Pick something that will hopefully work, but be flexible to allow for change in the future.

3. Get the content on the platform

It’s very hard to begin a collaboration with a blank page. You do need some content to get people talking and give them something to work with.

This, depending on your starting point, can be a quick or a very labour-intensive job. Copying and pasting text from other documents is fine, but when it is from (say) a PDF some cleaning of the formatting is likely to be necessary. Make sure you factor the time in to get this done.

Don’t forget your users when adding content. Consider adding some consistent header text to the top of each page, explaining what the content is, how it can be edited or discussed, and how the project administrators can be contacted for help, etc. Ensure that you take into account what people told you at stage 1. If people say they like to respond by email, make sure there is an email address they can send comments to, and a process for getting those comments onto the platform.

Ensure that the navigation for the platform makes sense and that people will be able to find the bits they are interested in easily. Test it out on some of your initial group to get their thoughts. Maybe find a complete web-novice in your organisation to take a look and see how they get on with it.

4. Set the rules of engagement

Having rules is boring, but a lot of people like them. Part of this will come into the page heading text I mentioned in step 3, but it is probably worth explaining again on a separate page. Make it explicit who should have view and edit rights to the content and also how vandals will be dealt with.

It might also be worth explaining exactly what will happen to people’s content that they add, who it ‘belongs’ to and under what licence it is published online. These things shouldn’t matter to most people, but those that do care often do so loudly.

It probably is also a nice idea to explain what the aim of the whole exercise is – what is the eventual output likely to look like? And how will those who have collaborated on it be credited?

5. Invite and manage contributions

Now invite your initial group to come onto the platform to start collaborating on the content. Keep it to this gang as much as you can to start off with. Any problems in the structure of the site or the way content is made available will soon be spotted and fixed.

Other things will be bound to go wrong at some point. People will accidentally delete entire pages of content, for example, and panic about what to do about it. Make sure you and your team are keeping a constant online presence to monitor what’s happening so you can react quickly to a) calm down the person who has just ballsed things up and b) put things right so the project retains at least a veneer of professionalism.

6. Figure out some roles

As part of the initial work with the smaller group, take the opportunity to identify some roles on the project and fill them with some of your early volunteers.

Roles can include:

  • Community manager – someone to keep everyone engaged and motivated on the project
  • Social reporter – a content creator who
  • Curator – collecting relevant content and useful information from around the web and bringing it together into one place
  • Gardener – a person who likes to keep your project tidy, cleaning up formatting errors, ensuring links work, and navigation makes sense
  • Evangelist – someone willing to go out and recruit new people to come and collaborate on your project

7. Market it

To get people involved beyond your core group of volunteers, you need to get eyeballs. Post to relevant forums, blogs and mailing lists about what you are doing. Telephone other contacts and get them to sign up. Stick a link to the project in your email signature. Mention it in every letter you write.

Don’t forget that you are asking people to give up their time to help you out for nothing in return other than the kudos of actually being asked for their opinions. Some will jump at the chance, others will need more persuading.

8. Get everyone in a room

At the very least, have a party at the end of the exercise to thank everyone. But even better, have one towards the beginning too. Even online networking fanboys like me appreciate that to get trust in a community, you have to meet one another face to face first. OK, you don’t have to, but it really does help.

Maybe you could have a collaboration hack day – a big room with lots of laptops, wifi, flipcharts and post-its, where everyone does their best to get as many quality edits done as they can, chatting to each other and developing ideas in real life. Plenty of coffee and sandwiches would probably help too.

9. Let go

Involvement in any activity like this one will involve the acceptance of a significant loss of control and messiness in the way things develop. This is good, don’t try and fight it.

Do moderate offensive or stupid content – that does no-one any favours. But if things are developing in a direction you didn’t expect, or don’t like, let it. Have a conversation about it. Examine your own preconceptions and assumptions and see if things can be worked out another way. But don’t go round reverting pages because you don’t agree with them.

10. Get the output sorted

Finally, make sure there is a recognised output at the end. Hopefully this could be some sort of document that people who like documents can read. Make sure it is full of links back to the wiki so that people can see who developed what idea, and how that idea changed from the original.

Make sure that a description of the process is included in the final document, and that everyone who contributed is credited. Go back to those forums, blogs and mailing lists that you punted the idea around on and let them all know how it finished. Make a fuss about the fact that this stuff works!

Do you have any tips for making collaborative digital projects work?

Writing apps – the software I use to get words on a page

writingI probably think about this sort of thing far more than I should – after all, doesn’t everyone just use Word? – but I like playing with different tools for writing.

After all, for me, typing words into a computer makes up probably 75% of my job. That’s a lot of typing and so it’s worth making it as little of a painful experience as I can.

So here is a list of the different tools I use to write text with.

Byword

Byword is a ‘distraction free’ writing application which works on my Mac and iPad, syncing through Apple’s iCloud service. It’s a very simple editor, that pretty much just lets you type in text in plain text format. You can do some formatting with Markdown, which you can then export, but I tend to use it when I just want to bash some words down, without thinking too much about how it looks.

Find out more about Byword

MarsEdit

MarsEdit is the app I use to write my blog posts. It’s a bit of desktop software that lets me bash in the content for my posts offline, using a very simple plain text editor. I’m able to add tags and categories to my posts, which I then send up to my blog in draft, ready for a final check, adding images and hitting publish.

I don’t know why, but I just find writing posts in MarsEdit more comfortable than using the WordPress editor – hence why I class WordPress as a publishing tool rather than a writing one. A big part of it is probably down to the keyboard shortcuts I use to quickly enter and mark up content in MarsEdit, rather than having to constantly switch to the mouse to select icons.

Find out more about MarsEdit

Apple Mail

An awful lot of the words I write are emails, and so my email client has to feature in this list. I use Apple Mail mostly by default nowadays – previously I have used Gmail’s web based interface, but I do find using a desktop client helps me pace myself a bit and be a little more thoughtful. It’s basically ok – I have no complaints but then I’m not exactly a huge fan either. It works.

Find out more about Apple Mail

OmniOutliner

This is a seriously good outlining tool, which I mostly use for drafting pieces of writing or presentations. Outliners let you build up bullet style lists of content, indented at various levels of a hierarchy, which you can then drag around and reorder. It allow you to structure a document really well in the planning stage – to figure out your ideas and how they slot together.

Find out more about OmniOutliner

Google Docs

When I need to collaborate in the early stages of preparing a document, I usually turn to Google Docs. Due to the fact that it is online, it does tend to stress me out a bit – I prefer desktop apps with local copies of files when possible – but Docs is the best solution to working on something with others, particularly at the same time.

Find out more about Google Docs

Scrivener

I occasionally work on longer pieces of writing, although they almost never get published anywhere. Scrivener lets you write chunks of content for a larger work, which you can then reorder, drag around and so on. It also lets you save research notes in the same place as your draft document, which can be helpful. At the end, Scrivener spits out a rich text file that sticks all your chunks together, for a final edit, or formatting exercise in a word processor.

Find out more about Scrivener

Evernote

The writing I do in Evernote differs wildly, from meeting notes to pasting in web addressees to check out later, to

Find out more about Evernote

Pages

Pages is Apple’s own word processor, which I use occasionally for more graphical documents. It just has a more creative, desktop publishing type feel to me, which makes it ideal for that kind of work. It’s really easy to use, and I find it the best tool to work with when a document has a lot of graphical elements.

Find out more about Pages

Vesper

A super iPhone text editor. It does one thing very well, and that is writing short notes on my phone. It has a beautiful design and is incredibly easy to use and for when I just need to quickly write something without worrying about it syncing up anywhere else, Vesper is perfect.

Find out more about Vesper

Simplenote

Yet another cloud-syncing text editor. I use this to quickly get text onto my phone from another device. It’s fairly niche, but stuff like when I look up an address for a meeting on my laptop and want to get it to my phone – I’ll usually use Simplenote rather than creating something in Evernote.

Find out more about Simplenote

Word

OK, so I do use Word. Quite a lot, actually, in its various incarnations – Mac, Windows, online (via Office 365) and now, of course, on the iPad. When it comes to needing to share a document with others in a format they are likely to be able to edit, its still the best option.

Find out more about Word (really?)

What are your favourite writing tools? Do you use as many, or even more, than I do?

Five for Friday – 11 April 2014

linksFive for Friday is WorkSmart’s weekly roundup of interesting stuff from the week’s reading.

  1. Dancing Giants: How Cisco Innovates
  2. How to write an internal communication strategy
  3. How To Convince Your Boss To Try New Things
  4. Tips for starting a podcast
  5. The Ultimate Guide to Solving iOS Battery Drain
Did you know that WorkSmart has a Pinterest board where loads of cool stuff is shared?

We also now have a LinkyDink group which will automatically email you links to read everyday!

Why digital capability (or comfort) matters

keyboardI spend a lot of my time at the moment talking about digital capability. To my mind, this means the ability of people throughout an organisation to make the most of the opportunities offered by digital technology.

Capability is less about skills though, and more about confidence – or maybe comfort.

Sure, a certain amount of skill is involved. I sometimes refer to this as the ‘Alt-Tab’ test. If someone knows that Alt-Tab means to quickly flick between applications on a Windows based computer (it’s Command-Tab on a Mac), they are probably going to be ok in the new digital world.

To me though, digital capability is more about knowing where to look for the answers as it is knowing the answers in the first place. It’s about understanding why people might want to use a certain tool, rather than using it yourself. It’s about being curious, networked, agile, user centred and flexible rather than knowing how to use this app or that.

This matters because the landscape is changing. A few years ago, an average worker in an office might need to use four or five systems on a regular basis. Their email, the database for doing their jobs, Office, the intranet and perhaps an HR or other system.

These days though, people are being invited to Dropbox folders, Huddle projects, Asana task lists, Trello boards, Basecamps, Nings, Yammer networks, Google Docs and more. The numbers of different systems are growing and often the first people will have heard of them is when they are invited and expected to use them.

Nobody can learn in advance about systems they have never heard of! Instead, they need the confidence and comfort with digital tools that they can recognise how they probably work, and have the knowledge to know they are unlikely to break them just by having a go.

As I have written before, and will do again, the days of monolithic, one size fits all IT systems is over. As Euan Semple says in a recent blog post:

Building a technology ecology from small iterative deployments of specific tools, with a throw away mentality that allows more constant adaptation, driven by ongoing conversations with users is the only way to do technology efficiently.

In this new world, everyone needs to be comfortable with switching between apps, even when those apps are doing rather similar things, just in a slightly different way. This won’t come from learning each app one by one, but instead by understanding the principles of digital tools, and the underlying philosophy of how they work.

As is often the case, the online comic XKCD nails it:

tech_support_cheat_sheet

Load more posts!