Tag: UI

Getting Organised

I read some advice the other day that suggested that, instead of reading up on how best to be productive, you’d be better served actually doing the things you need to do rather than trying to figure out the best way to ‘be productive’.

I guess the premise being that many people spend a lot of time researching methodologies, trying out applications and processes when, for most of the tasks they are tracking, they would be better to just do the damn thing already.

I fall squarely into that group of people. I’m very guilty of spending too much time figuring out the ‘best’ way to keep myself organised, sometimes at the expense of just doing things.

So, why do I even need any kind of system?

Well, mostly to counteract my awful memory but also, partly, to keep track of random ideas that float through my head, things I don’t need to act on straight away but I know are good enough to log somewhere with a view of revisiting them later.

But what do I actually need?

Let’s break things down. Fundamentally I need to keep three types of things organised:

  • Tasks
  • Information
  • Schedule

For all of these I want to be able to access them all from any device I want, be it my laptops (work and personal), my iPhone or my iPad. Simple enough, right?

Tasks

There are tasks that I need to do and, broadly speaking, I can break them down across three categories: Work (capital W, day job), Personal, and work (lowercase w, side jobs).
Some of the tasks have a hard deadline (given to me, or driven by external forces), some of notional deadlines that I apply myself (or I won’t do them), and others fall into the ‘some time’ bucket (essentially these are the ideas that I need to follow up but which have no real urgency).

So I need categories, but I’m not fussed about sub-categories, and I need the ability to schedule repeating tasks because … well did I mention my awful memory?

Solution

Wunderlist. No, Any.do. No, Reminders. Dammit.

It’s here where I struggle to find an ideal solution but I can see light at the end of the tunnel.

For now, I’m sticking with Wunderlist.

I love the Any.do app but there is no website (or OSX app) to allow me more power and easier editing. No matter how hard I try, this is a must have for me so after a couple of months of Any.do I’ve switched back to Wunderlist (I considered Remember The Milk again but it’s user interface just doesn’t feel nice any more). Wunderlist has iOS apps and and an OSX app, allows for categories and repeating alarms.

The future development of Apple’s Reminders app may sway me away from Wunderlist. Tighter integration with the OS makes it very slick and (work proxy issues aside) the ability to sync my Reminders to iCloud (and so across all my devices) makes it very slick. If the UI improves I can see it being my go to app in the future. Add in tagging, something I’m keen to see in the upcoming Mavericks release of OSX, and the power of the Apple ecosystem, across apps becomes a different prospect again. But that’s for the future.

Information

There is also information I need to store. Be it documents of information, files to backup or share, lists of contacts, or other pieces of digital media that I need to keep organised.

Occasionally the information is snippets, not a full document, but the need is the same.

Solution

Dropbox – for file storage. Not just because I can access it from anywhere, and share folders with others if I need to, but because many iOS/OSX apps integrate with it, allowing me to use it for draft posts, for example, so I can work on them at any time. For the inquisitive, I’m using Byword on both OSes to write my blog posts these days.

Evernote deserves a mention here too. For shorter pieces of information, and particularly for clipping information from the web, it’s excellent. It means I can grab recipes, add to my Evernote powered wishlist, and just generally use it as a database of things that might be useful to me in the future.

I should also mention the Drafts app for iOS here. It’s a simple text based editor which has several ways to take what you’ve just typed and fire out an email, send it as a note to Evernote and more. It’s a good quick way ‘in’ to my information system.

Schedule

Finally there is my schedule/calendar.

Due to personal circumstance this area is a lot more critical than it used to be, as I need to be able to schedule my leisure activities based on the whereabouts and plans of three other people.

Solution

Google Calendar – which allows me to share my own calendar and view those of others, making planning a night with one or more (or all) of those people a lot easier.

Email

One item I’ve not included in this waffling ramble is email. Quite simply because I have an excellent solution.

Gmail + Mailbox

My personal email is all filtered into Gmail. I can access it anywhere I want on any device I have. Where the real bonus for me is that, by using Mailbox for iOS I can now manage my emails much better. If I can quickly reply, I will. If something needs followed up I can quickly schedule it to ‘reappear’ in my inbox.

And that’s where I am currently. I don’t stick to a productivity methodology, I try and just do things when I can, but for now I have a system that works for me and does get massively in the way of me actually doing things.

Why Fitbit is winning

My main aim for this year was to lose weight. Actually that’s not true. My main aim for this year was to be happy which involves changing my lifestyle and habits, mostly focussed around my fitness and weight.

Data helps me with this, tracking my weight loss lets me look back and see how I’ve been doing. To that end I invested in a set of Withings scales. They’ve been great and have really helped me keep focus, and given me that little spur I needed from time to time to get back on my bike, or go for a walk, anything to be a little more active. Aside from my happiness, losing weight is also something I must do as I’d really like to NOT be taking maximum dosage pills for my high blood pressure for the rest of my life. With that in mind I also invested in the Withings blood pressure cuff to let me do accurate readings at home.

Looking to accumulate all my ‘fitness’ related data I looked for ways to track my activities and, as I used it last year when I got my bike I re-installed CycleMeter to track that and looked into Fitocracy as a way to pull it all together.

It was about then I realised my system was a little flawed. CycleMeter only shares data with a single tracking service (Dailymile) which I don’t use… I remembered back to my running days (knee still gubbed so they remain in the past for now) and looked into RunKeeper. Built around an activity tracking service, it also has a GPS app for tracking runs and cycles… not as full featured as CycleMeter but all I really want is time and distance (and a map, that’s nice too).

I’ve spent a few weeks manually updating Runkeeper with the data captured by Cyclemeter (which I then need to manually pull into Fitocracy) and I’m a bit bored of it already. So it’s bye bye CycleMeter and Fitocracy, and hello Runkeeper.

It’s here I should also mention that I purchased a Fitbit a few weeks ago. It was more curiosity than anything but as a way to track, fairly accurately, who active you are throughout the day it’s been far more useful than I first thought. It also syncs with Withings (for my weigh-ins) and Runkeeper (for my activities). It’s also fair to say that it’s got the nicest interface/dashboard of any of the services I use. Withings is shockingly bad and slow to render, Runkeeper is somewhat dated already and really needs a UI designer overall.

So, Fitbit has fast become my hub, the central place where I track personal fitness data because it does what I need it to do and does a lot of that in the background with very little interaction from me.

The last piece falls into place as, thanks to the fact that Fitbit will sync data with MyFitnessPal which I’ve used in the past for logging what I eat and I have a good balance of automated data collection, all pulled together into one useful Dashboard.

It’s taken me a while to get to this point, not least because every single app or service I’ve tried has been good in some ways but bad in others. I prefer using CycleMeter but will put up with the deficiencies of Runkeeper to get the data sync’d automatically. I prefer interacting with Fitocracy than Runkeeper but it’s not quite there yet in terms of automated services (and is heavily geared towards weight pumping gym bunnies). Fitbit hits the sweet spot for me and given that I’ve dropped over two stones since January, it seems to be working!

Me on Fitbit

Design matters

Why would you choose to make something difficult to use? Are you deliberately putting barriers in the road? Or are you just forgetting the main reason why people pick up a document or manual?

Long ago, when I had just started out as a technical writer, I attended a course on designing for Print. It covered many things, from typography to layout and I still use some of the basic design rules I learned way back then.

Whitespace, choice of font, and hierarchical indentation can help make a document more readable. Clearly delineating the structure of a document without explicitly stating it as such, leaving visual clues to help the reader navigate the page (presuming you’ve covered the multiple navigation routes they’ll take to get to that page of information).

Such considerations will continue to become more important as more and more information is moved online, and is then available in a variety of media formats and devices. Structuring your content, and using visual clues to convey that structure clearly, will become ever more important.

At this point there starts to become an obvious overlap with usability, pushing technical writers to start thinking more in terms of the user experience than simple task analysis allows. Understanding the reasoning behind a user action will become equally important, and can be passed to development to influence the UI as well as directly impacting on how we present technical information in the future.

Beyond that I’m not sure where else this may take us but I do know that part of the reason I love this job is the cross-over we have with so many other professions/industries, and I can’t wait to see what is next over the horizon.

Usability sucks

I’m getting royally fedup with a lot of what I read that is written in the name of usability. Maybe it’s just a personal loathing of the overly academic, or perhaps I lean towards simplicity a little too heavily but SHEESH, some of the better known experts can’t half prattle on…

I’m a member of the usability team at work, largely because I made a lot of noise about it when I joined the company, but also because as a technical communicator who is passionate about the entire experience of using a product, I realise that the interface is THE most important part of communication between user and product.

I’ll let that one sink in, shall I?

Despite our own protestations, we all know that while good documentation is crucial to a product, it’s the user interface that carries the bulk of the load of communicating the capabilities of the application. With that in mind it makes sense to be as involved as possible with the design of the interface for, as I read somewhere many moons ago, we [technical communicators] are “the interface to the interface”. So, if nothing else, getting involved in usability and screen (UI) design for your application should make the job of documenting the software a lot easier.

Now, I’ll happily admit I’m still very much a novice in this area, but I’ve picked up enough knowledge over the years to be dangerous. I’m very aware that my advice tends towards what I would consider common sense, but generally speaking I base my UI design comments, and generally usability thoughts, on the following processes:

  • Simple task analysis – picking out the main usage of the application should be pretty straightforward, but sometimes narrowing that down into distinct tasks can be trickier, so I tend to mentally “step back” everytime I approach a new screen and ask myself what it is I would WANT to be able to achieve given where I am in the application. Often you will find that the flow of the UI isn’t quite right.
  • Narrow your view – the next step is to pick out each control to make sure the label, text or icon make sense. It’s very easy to get caught up in the overall task and presume too much.
  • Quick, write something! – this step can be done mentally, with pen and paper, or just start typing. I often find that it’s only when trying to “tell the story” of how to use an application that all the pieces finally fall into place… and then you realise that one is missing.

As I said, I’m no expert but my approach seems to give reasonable results. Yes with formal analysis, metrics and so on, you can always improve things but sometimes perhaps good enough is good enough?

I sometimes wonder if I’m actually doing more damage than good so I’m quite careful that my opinion isn’t the only one (ok ok, isn’t the LOUDEST one), and I try and keep up with things – Boxes and Arrows & Jakob Neilsen for example – and I’m convinced that there is a big enough overlap between the two professions that one day I’ll be hiring a “usability writer”. No… a “technical usabilitist”…

No Docs = No Product

What of agile documentation?

It seems like such an old argument that surely, SURELY, doesn’t need revisiting? Alas it seems that the world of software engineering still contains those who think that code = product. Thankfully, in my experience, the numbers are thinning as most practitioners of modern software practices are at least educationally aware of the need for product documentation, even if they don’t fully understand the reasons. However, there are still those who are happy to hack away, and then claim they have a product. If you are such a person let me make one thing clear, you are wrong.

Not only are you wrong but as time marches on, you get further and further from being correct, all the while creating further problems for you and your product.

Just over a year ago, in preparation for my new job, I spent sometime reading up on Agile development and in particular I focussed on Extreme Programming (XP). The more I read the more I came to realise that this was an area which was popular with developers, yet had little to no mention of product documentation as a fundamental part of the methodology.

Mention of unit and acceptance testing as fundamental parts of working in XP suggested there was at least an understanding of the importance of solid, well constructed tests to help make to a “better” application (test-driven development) but the more I read, the more I become slightly disconcerted at the lack of consideration given both to the production of product (end user) documentation or of the benefits and skills a technical writer can bring to a development team.

Truth be told, I’ve still to find more than a passing reference in any of the more recent publications and articles I’ve found but I’m happy to be proven wrong. Perhaps I’ve been reading the wrong things, and visiting the wrong websites? Or, more worryingly, perhaps there really isn’t anything out there.

Obviously, as a technical writer, the role of product documentation as part of the product is something that is at the forefront of my mind, and I’m not expecting any software engineer to have to worry about such things beyond understanding that we are a fundamental part of the product offering and hopefully agreeing that there is a level of expectation setting to be undertaken.

That said, I do expect a software engineer to understand that software without any support, be it formal documentation, training, or a dedicated support team, is NOT a product. If we can’t agree that fundamental trait then perhaps that problem requires a solution (thankfully, as I said earlier, I don’t think it’s a huge issue at present).

Quite simply, products include documentation, support and training, and tell a cohesive story to a potential buyer. A story that says, yes this product will do X, Y and Z, and if it breaks we’ll do our best to help fix it, and we’ll support you as you learn to use it throughout the lifetime of your relationship with the product (and, therefore, the company).

Admittedly the lines are blurring, with better UI design there is less need for the end user to head to the documentation for assistance but I’d argue that, conversely, as UI design improves and more people become aware of the basic principles of software applications (we all know cut and paste by now, right?) then the end users will start to stretch the applications in ways that hadn’t been considered and it is at this point that product documentation (information) becomes the key differentiator between products.

Of course it is possible to happily exist as a technical writer in an Agile world, but I think we need our voice to be louder.

So I guess my question is, who is willing to shout?

Note: I am aware of Agile Documentation, but I’ve yet to read it. It seems to be more focussed on a developer writing documentation though? I’ll post a review of the book soon.

Improve the experience

Recently, Tom suggested that:
if someone can figure out how to make help whallop the user with wonder and awe, it will be the creative innovation of the century. Once we begin to establish a standard and a precedence, people’s beliefs will change from feeling that “all help is useless and unimportant” to “the help at my company is exceptionally good and useful; I will explore it more often.”

And I completely agree.

But.

Whilst he goes on to list ways in which the future of online help may expand – personalized help, feedback options, audiovisual options and such like – I think that is only one side of the coin.

While, without a doubt I could work harder to improve the content offered as online help, I think technical communicators need to expand their view a little, step back and see a bigger picture. I’ve touched on this before, and it is by no means original, but ultimately we are at a point where it is beginning to be realised that the information provided with a product is a most valuable commodity. With that in mind, the time is ripe for what Tom suggests, a new way of presenting information is surely on the cards. However I think it’s wrong to limit it to online help or documentation alone.

I’m lucky that, presently, I’m part of a company that allows the Publications Team (MUST change that name!) to be part of the softare design process. As such I can see, from inception to release, the decisions and design thoughts that go into producing our software, and I influence them as much as I can. Making the on-screen text useful is one thing, the next step is to think “task task task” during any discussions on design. Developers, rightly, take a requirement and start thinking about how THEY can implement it, yet just by repeating the “task task task” mantra I was able to get them to start thinking about how it should end up, rather than the finite possibilities of how it could be implemented.

Just to clarify, I don’t sit at my desk and chant. Instead I tend to start discussions about our software with “OK, I’m [insert user type], what am I trying to do here?”.

I’m not ramming this down anyone’s throat, but my choice of language during discussions has started to rub off, resulting in some design decisions made because they were thinking about the task the user is trying to complete, not the fact that it would need to get info from database A and publish it to form B.

In response to Tom’s post, I said:

Perhaps the radical shift is helping to address issues without presuming that people will “end up in the help”. Instead of being the last resort we should be striving to stop people having to get to that point.

That said, if they do end up in the help then yes, it should have a sufficient “wow” factor without being useless. Ultimately, make sure the information they want is findable by whatever means they choose.

Being the customer respresentative, the interface to the interface, is part of that.

I once told a Technical Support Manager that, ultimately, the aim for my team was to put his out of a job. Obviously that will never happen as the myriad of platforms, hardware, and user issues that surround every software product couldn’t ever be documented (unless development of the software had ceased, in which case I wouldn’t be working for the company).

I guess the aim for a usability team, or anyone interested in improving the user experience, is to put the documentation team out of a job. If the interface is well enough designed that the user doesn’t get stuck, and if it includes enough information in the UI to help the user make decisions, then why would they ever need documentation? Of course, similarly to the Support team scenario, documentation will be required to support the less travelled paths through the UI, to help the user who wants to do things her own way.

And that is where Tom’s suggestions come in. If we can improve the information we provide, making sure the customer experience is maintained (bettered?), then they are more likely to come back.

Recently Read

Christmas looms large, and the days are “fair drawing in” as they say in these parts. I’m taking a couple of weeks off to relax and recharge, and no doubt to eat, drink and be (very) merry. As ever this time of year is pretty hectic, so here are few things that caught my eye over the past couple of weeks.

10 Word to avoid in your writing
A short list but the main point is to avoid gobbledygook. One of my pet peeves is the use of long words when a perfectly valid, shorter, word is available. The Plain English website has some excellent advice if you want to find out more.

No-one reads the help anyway

the next time you hear someone say, “No one reads the help anyway,” say, “Yah, no one uses Google either.”
This will lead to a puzzling follow-up question — What do you mean? I use Google all the time.
Then you say, What do you use Google for? To search for answers, solutions, and information when you have questions?

Like some of the commenters, I disagree with this a little. At a simple level it works, but there are flaws. However, as an opening gambit I think it’s a good one. It will make people stop and think, and once you have them thinking about it THEN you can explain the more subtle differences.

AuthorIT Yahoo Group Search
I’m listing this here so I don’t lose it again. Yahoo Groups are great but the search engine frequently falls over. MANY many thanks to Hamish for providing this resource, this is the kind of thing that makes the Internet great.

Building a successful web community

Do not assume that a community, particularly a successful web community, is easily built from the one ingredient of a shared interest – ensure there is also a goal or a purpose in the mix.

Very true. I know that some Technical Communicators are starting to thinking beyond user documentation, and the next step may well be to nurture online communities around your product. This article has some good tips, and I can vouch for them all having struggled to setup a Scottish Blogging site myself.

Technical Communicators and UI Design
Scott Nesbitt spotted an article about User Interface Design and a particular section caught his eye. It states that the documentation must be considered as part of the design, and Scott goes on to say:

“technical communicators need to get involved not only in the design and usability of an interface, but also how users will access documentation from within the interface.”

I couldn’t agree more with this, and recently I’ve been pushing my team to think along these lines, realising that we work with, and develop, “information” rather than “documents” meaning we need to have a greater sphere of influence.

To coin a phrase, we are the interface to the interface.

Who do you write for?

I started this blog to have a separate place to write about my “professional” thoughts and I guess I thought I could maybe add a little value to the cluttered world of technical communications, or at the very least raise my profile a little. Yes, I have an ego, but it’s kept in check for the most part.

However, like my other blog, the main reason this blog exists is to give me a place that I can consider and process my thoughts. I’ve always found writing things down helped me get a good sense of what they were, even if I didn’t necessarily start with a cohesive picture in mind. Sometimes the simplest issue, one that has eluded me for some time, leaps into focus when I start writing. I’m not sure if it’s always been that way or I’ve now trained myself into such a habit but I’m not complaining, it works for me and I’ll admit that I still get a little buzz when something “clicks”.

If I were in a cartoon a light-bulb would *plink* into existence above my head when that happens. Reality can be such a disappointment.

Today brought a good example of such a moment and rather than deleting my thoughts, I’d thought I’d post them here. Sharing is power after all (badly paraphrasing remains inexcusable).

One continuing theme on most of the mailing lists I follow and in various blog posts across the land, is that of knowing your audience. Knowing why you are writing, and who you are writing for are the fundamental tenets of our profession. They are so fundamental that, if I’m honest, the incessant reminders about them do start to grate somewhat. After all I’m a professional, how many times do I need to be told to consider my audience? How many times do we need to restate something we all know and understand.

I’m happy to admit that some will know more about their audience than others. Some will make do with a rough approximation of what their audience expects, whilst others will interview and analyse their customers and gather requirements and direction directly.

Regardless of your level of commitment to understanding them, anyone who is writing must (surely) consider their audience. Yet, at every turn, the answer to many questions all stem from that presumption, and are presented in simplistic terms. Know your audience they say. OK OK, I get it!

The thing is, after reading such a response for the umpteenth time it suddenly struck me that yes, we do need to be reminded of this basic fact, time and again.

We all have pressures on our work. Whether those pressures come from commitments made to others, from our own professional integrity, or directly from the customer, they all serve to focus us on the end goal and usually to start thinking in terms of quantity. We know we need to document the new interface to the ACME Widget and when pressure is exerted their is a temptation to take shortcuts, and the easiest shortcut is, by and large, to forget the audience.

The cardinal sin allows us to omit information on the presumption that they will “probably know it”, to structure the information according to UI rather than task, and ultimately to regress to a “if you can click it, document it” mentality. That may be a valid mode in certain circumstances but that will depend upon, yeah you guessed it, your audience.

Audience analysis, the use of personas, call it what you will, if you don’t have at least a rough idea of the type of person you are writing for then why bother? You won’t be structing the information correctly, you won’t be pitching the level of information appropriately, and you most certainly won’t be thinking around the various conceptual models your audience are likely to use and understand. The more you know, the better you can focus your documentation, drilling down into the tasks they need to complete and what they need to know before they begin. The better your knowledge of your audience the more likely it is you’ll produce documentation that they can use.

Put it this way, if you aren’t writing for a specific audience, who ARE you writing for?

Ooops.

I’ve gone and done exactly what I said annoyed me, lectured you all on knowing your audience when you already know that you need to know that. You know?

Next time I read yet another “Depends on your audience” response in a mailing list I’m going to try and remember that advice and apply it to my current work.

Addendum: Charles Cooper has been considering the same thing.

Jack of all trades Pt. 2

My name is Gordon McLean, I am a Technical Communicator* and I am proud to be a jack of all trades.

I recall once being asked to breakdown all the skills required to be a Technical Writer, and then to provide a list of daily work tasks. The list of skills was to be used as part of a skills/training matrix, and the work tasks were to be mapped to a timesheet system.

At first I concentrated solely on the Technical Writers role, but even then you need to wear a number of hats; researcher, analyst, information architect, publisher, indexer, illustrator, proof-reader, editor… ohh and writer. All of those are unique job roles in some places yet, as a Technical Writer, you need to be able to successfully take on those roles to some degree. In most software companies a large part of the job is learning the new features, and as you have access to early builds, you are frequently also playing the part of ad-hoc tester. Admittedly you are usually only testing one scenario, and that scenario is the happy path that will be documented, but a bug is a bug and that means being able to identify one, discuss it with a tester or developer, or both, and why not log it as well?

If you are documenting an API or developer toolkit then, in those instances, you frequently don the cap of novice developer, asking the questions you expect them to ask, before switching caps to presume the role of an experienced developer and wondering if the information you are providing is too simple for them to use or if, perhaps, the structure of the information needs altered.

You need to be able to talk to developers and so you need to know a little about whichever code language they are working with, that way when they mention methods, you can ask whether they mean static or instance.

None of these skills/roles are the core part of a Technical Writers job, but simply additional strings to your bow. The more you know about everything, the more value you can add, so long as you don’t let that detract from your core responsibility, to provide documentation. However, the more you know about everything, the better that documentation will be and the higher your value will soar.

Prompted by The Top 5 Reasons to be a Jack of all Trades

* Communicator/Writer/Author, pick one. I favour ‘communicator’ because I don’t always communicate through writing, sometimes through UI design, sometimes through infographics and diagrams. You get the picture (pun intended!).