Regarding Productivity

Tweaking Workflows

16th December 2014

Only a few days ago Workflow launched and whilst I’ve never really bought into Editorial, Pythonista or Launch Center Pro (though I’m aware of their collective existences) after creating a simple script to tweak the output of Overcasts tweet URL scheme I decided to solve another problem that’s annoyed me for some time.

One of the problems with Pragmatic is that it takes a considerable amount of effort to research and collect all the links I want to use during the course of most episodes. In some cases I’ve had a page full of links that I traditionally saved using the Safari Bookmark sync.

During the dark period of non-synchronicity between the iOS8 Betas, Yosemite and iCloud Drive (I insanely participated in the Public Beta of Yosemite ignoring in-part my own advice not to) Safari bookmark sync worked intermittently. I resorted to saving links and messaging them to myself, or being stuck to bookmarking items from the desktop only. Whichever way I chose it was inevitable that I would have to export my bookmarks then convert them from HTML into Markdown.

Why Markdown? Well when you blog in tech circles of late, apparently you should use some kind of markup language that isn’t HTML because you know, HTML sucks for some reason and reading raw text in Markdown is easier on your eyes. Apparently. I use Statamic as my CMS which uses Markdown as an option and I decided, one in, all in and converted every last bit of text into Markdown on the whole website.

Tools to convert HTML into Markdown exist in the form of scripts but honestly I had trouble making them work on Mavericks at the time and never bothered to revisit them. Seemed like too much work for little return benefit at the time. I’d rather just start and end in Markdown if I can and never go HTML.

Hence I just shrugged and copied and pasted text and URLs back and forth between HTML and Markdown raw text files while I was listening back to the audio as I edited.

But it still bugged me.

Enter Workflow for iPhone and iPad

Then Workflow happened and after reading Federico Viticcis War and Peace on it I threw cash in the ring and tried it out. In so doing I saw something that caught my eye: "Append to Dropbox File". I was already using DropBox as my backed-up local filestore for this website (amongst many other things) and figured I should try to append the links to a text file directly in Markdown rather than bother with the potentially problematic Safari bookmark sync. After not a great deal of work I came up with a very simple, single (iPhone 6+ screen sized) workflow to solve my highly specific use-case:

Workflow

Sharing this with my iPad I now could easily add the URLs I needed in Markdown directly as text for use in the show Markdown file later. But what about the Mac?

Mac

Using the Sharesheets is out on the Mac unless there’s an app that already does what you need. Bookmarklets could probably work but an Automator workflow should be fine, and using AppleScript is something I’ve dabbled with before. A few searches around the place and I set up a simple Automator Service workflow that takes no input, is available in Safari and whose AppleScript looks like this:

on run {input, parameters}

    tell application "Safari" to set currentTabURL to URL of the front document
    tell application "Safari" to set currentTabTitle to name of the front document

    set theFile to (((path to home folder) as text) & "dropbox:links.txt") as alias
    set N to open for access theFile with write permission

    get eof N
    if result > 0 then
        set theText to read N
        set eof N to 0
        write theText & return & "- [" & currentTabTitle & "](" & currentTabURL & ")" to N
    end if

    close access N

    tell application "Play Sound"
        play(((path to desktop) as text) & "Laser")
    end tell

    return input
end run

Play Sound is an app that accepts a scripted play/stop/pause and a filename and just plays it. Just to prove the concept I threw a Laser sound effect on the Desktop but you know, use whatever sound, wherever you like. It’s a free filesystem. Even if it is HFS+.

Conclusion

Yes this assumes you use Dropbox to glue it all together but this set up now allows me to keep all the links in the one place for easy addition into the show notes with a single quick copy and paste and no more HTML->Markdown conversion scripts that frankly, seemed a bit inverted anyway.

Attribution

Four Quadrants

14th November 2014

All designs consist of components. They can be broken down into smaller and smaller components/elements to the point at which they can be classified in two key aspects (all measures are relative to the overall project cost):

  • Straightforward (Small number of hours to implement and test)
  • Complex (A significant number of hours to implement and test)

Additionally design components and elements can be either:

  • Independent (Element is essentially standalone and does not impact/affect other design components)
  • Interdependent (Impacts one or more other design components)

Think of it like a matrix:

Four Quadrants

1st Quadrant Straightforward & Independent

This is where we the developer/design want to be: The "Yes" Quadrant. It won’t take long to implement it and it won’t really affect anything else we’re trying to achieve on the project.

2nd Quadrant Straightforward & Interdependent

It’s great these features are straight-forward to implement however we need to be mindful of the interactions with other system components before we jump in and start implementing otherwise the implementation could cause a ripple effect of additional retesting and modifications to other design aspects.

3rd Quadrant Complex & Independent

In this Quadrant it comes back to schedule, cost and prioritization issues. Ultimately if there’s enough time and money to implement these sorts of features at least they’re independent enough to not affect other aspects of the product.

4th Quadrant Complex & Interdependent

No matter how you slice it, the answer to these should be either A) we need more time and money to implement this or B) No. No - no - NO!

Key Points

  • Be clear who exactly your customer is
  • Be clear in your feature classifications
  • Be honest about how much effort is required to implement a feature
  • Be Brutal in saying no to the 4th quadrant activities

I also talk about this on Episode 45 of Pragmatic.

Cloning Success

5th August 2013

A group of people (and sometimes just one person) see a problem and create something to fix it. The product or service they create is a huge success and then everyone starts to ask the obvious question: why didn’t I think of that? The same person(s) do it again and again with new and different products and people start to ask the next question: how do they keep doing that?

We humans are a strange lot. Where there is a problem we feel the need to solve it. Where there is a problem solver we feel the need to explain how they solved it. Countless cumulative years of some peoples lives are spent arguing about the how and why of successful people and successful companies. This company puts their customer first and that one doesn’t; this customer has an inverted boab-tree management structure and this one looks more like a watermelon and clearly THAT’S why they were successful. Recently I’ve read theories that Apple was successful because of one man: Steve Jobs. Steve Jobs sadly passed away recently and now some theorists state that Apple is ‘doomed’ without him, whilst others now say his company and it’s design process are the reason for their success all along. On that note, process is for nought without talented people to execute on that process.

This effect is not unique to technology and certainly not just Apple. Many years have seen many different processes evolve around successful companies and many companies have copied them with several becoming very mainstream like 6-Sigma (from Motorola in the mid-80s). Centralised vs Decentralised management; Matrix management and so on. When one company is having market success, their processes are cloned in an attempt to replicate that success. It seldom results in anything significantly positive for the cloning company and the desire to clone what they think makes that other company so successful wastes thousands and even millions of corporate dollars every year.

Trying to understand and clone success isn’t just a company level pursuit: another example is productivity "gurus" that are analysed and torn apart and then put back together as people try to understand what makes THEM successful or efficient1. Stephen Covey and David Allen are two popular examples and whilst their techniques and suggestions benefit some people the inevitable truth however is that exactly what works for any one individual is unique to THAT individual. No one set of notebooks, software or habits can make everyone more efficient: some will benefit and some will not. Each answer is unique.

No matter if it was Steve Jobs or Apples design processes that produced the Macintosh, iPod, iPhone and iPad; no matter what system made the Sony Walkman, Discman and Stereos so sought after, no matter what made the Motorola Pagers so successful; attempting to clone their successes has not produced any subsequent successes for cloning companies around the world. And yet, they still try.

The quest for an answer, a solution, a method, a process or a reason (any reason) for others success drives many people mad. The truth is that success in any path of life can not be copied from another. Success can’t be bottled or transferred it must be created uniquely. Too many people waste their lives over-thinking the success of others when they should be thinking about their own successes. Following another companies design processes won’t automatically make your own products better. Stop trying to replicate the success of others and get on with making your own success in your own way.


  1. usually in the hopes that the individual can learn something from them 

Not All Design Churn Is Bad

25th July 2013

It is generally accepted in design that design churn is the enemy. For those unfamiliar with the term, unlike design iteration whereby a common set of requirements is agreed upon and during development new ideas are added and redesign occurs to improve the end result, churn is normally driven by an external influence which is usually requirements changes. Sometimes this is referred to as scope creep, however churn needn’t be about additional new features that are ‘nice to haves’ but can be simply about what the design team originally missed or neglected as requirements.

The ways to avoid churn and creep are also generally accepted and perhaps obvious: The lead designer responsible for developing the requirements specification has a great deal of experience in the area the product is developed in and key knowledgable stakeholders from all affected end-users are involved in the development of the requirements. Once the requirements are set many lead designers are loathed to change them to keep their churn in check and reduce any potential scope creep. Unfortunately this rigid approach ignores the fact that not all design churn is bad.

In addition to the initial requirements definition phase, in Engineering there are special detailed design reviews referred to as HAZOPs that are intended to flush out the finer details of what happens to a design if/when specific things go wrong. They are intended to be thorough and run by an independent third party and can take days to perform for even a simple system. This represents a significant investment in peoples time and hence the projects money and once designs pass through a HAZOP they are often felt to be ‘set in stone’. If significant design changes are required post-HAZOP then technically the HAZOP needs to be revisited (not redone from scratch as is often touted by nervous design leads) which becomes a strong obstacle to change.

The problem with the reactionary approaches to requirements change, especially post-HAZOP, is that they ignore the very real possibility that the requirements gap is real and will cause operational or safety issues for the end user(s) upon completion. There is an implicit assumption made every time someone responds with "A HAZOP was performed" or "We had end user input" that those persons involved at those times were A) knowledgeable on all aspects of the subject and B) infallible. We are all human and we all know that people make mistakes including lapses in concentration and judgement, but the odds of obtaining the best requirements input early on is most highly influenced by the persons involved.

There are two stages to consider. During the initial requirements specifications stage, teams are often quite small consisting of a bare minimum of design staff and those staff are predominantly senior staff that, whilst they may have some field/end use experience in the past, sit in management positions and have done for some time. In my experience this assertion is not too much of a stretch as I’ve observed this to be the case in at least half of projects I’ve been involved with in my career. Remembering that age does not equal wisdom or quality and that what actually matters is recent, relevant experience then this effect should be a cause for concern.

The second stage is the detailed design review stage which in engineering usually includes a HAZOP or similar detailed design workshop/study activity. The length of these reviews is often seen as a reason to keep the numbers down - too many people means too many opinions which makes the reviews even longer. Often there are strict requirements to have only 1 representative from each stakeholder group present and those that are sent can sometimes be chosen because the more experienced designers are just too busy with other deliverables and can’t dedicate a solid week to a HAZOP review. The way in which HAZOPs are run also plays a big part with holes in requirements that are found often thrown out the window on the pretext that the current design is being HAZOPed, not what the design could or should be. Such ‘off-topic’ input is supposed to be recorded and resolved outside the HAZOP however if this leads to a design change then the requirement to re-HAZOP the resulting changes is cited as being an expensive and unnecessary exercise and those comments end up ignored.

The customer MOSTLY gets what they want

The end user or customer that is paying for the design to be done for them should be the highest authority on design requirements. There does need to be some restriction on scope creep once the initial requirements are set but the wrong way to handle it is to uncategorically say, "Requirements are set, can’t be changed now," or "It’s too late, it’s been HAZOPed." Both statements are ridiculous and ignore the very real possibility that omissions and mistakes were made earlier on and that ultimately the end user will suffer from a difficult to use or under-performing product.

The right thing to do is to assess the true cost of the potential design change. Be honest with how much time a HAZOP revisit would really take (if applicable) and be thorough with the number of design documents and deliverables that would require modification. Once this figure is known a rational debate can take place that factors in schedule as well as the risk to the end user(s) of NOT implementing the changes. Far too often in my industry the design team shuts out the end user from design requirements changes and forces them to spend additional money themselves further down the road (after the project is ‘finished’) to correct the mistakes they found during the project. This ends up costing the customer more money in the end and will hurt future business between the designers and the customer in question.

Everyone should care about customer satisfaction and yet the transitory nature of employment in the engineering space (about 18 months per position) leads to a culture of apathy and rigidity where customer satisfaction is seldom a big factor. Continuity in projects matters and being honest with your customer about the cost of change will help you to both succeed. Shutting down design requirements changes without thought or consideration leads to bitterness, frustration and is ultimately is bad for business.