You are here

thinktime

Placing Australian adolescent health on the international stage

Teaser:  The World Health Organisation has named the University of Melbourne Centre for Adolescent Health as a WHO Collaborating Centre in adolescent health, the first outside of Europe.

The World Health Organisation has named the University of Melbourne Centre for Adolescent Health as a WHO Collaborating Centre in adolescent health, the first outside of Europe.

read more

Categories: thinktime

Sridhar Dhanapalan: Twitter posts: 2015-04-20 to 2015-04-26

Planet Linux Australia - 13 hours 34 min ago
Categories: thinktime

Russell Coker: Anti-Systemd People

Planet Linux Australia - Sun 26th Apr 2015 22:04
For the Technical People

This post isn’t really about technology, I’ll cover the technology briefly skip to the next section if you aren’t interested in Linux programming or system administration.

I’ve been using the Systemd init system for a long time, I first tested it in 2010 [1]. I use Systemd on most of my systems that run Debian/Wheezy (which means most of the Linux systems I run which aren’t embedded systems). Currently the only systems where I’m not running Systemd are some systems on which I don’t have console access, while Systemd works reasonably well it wasn’t a standard init system for Debian/Wheezy so I don’t run it everywhere. That said I haven’t had any problems with Systemd in Wheezy, so I might have been too paranoid.

I recently wrote a blog post about systemd, just some basic information on how to use it and why it’s not a big deal [2]. I’ve been playing with Systemd for almost 5 years and using it in production for almost 2 years and it’s performed well. The most serious bug I’ve found in systemd is Bug #774153 which causes a Wheezy->Jessie upgrade to hang until you run “systemctl daemon-reexec” [3].

I know that some people have had problems with systemd, but any piece of significant software will cause problems for some people, there are bugs in all software that is complex enough to be useful. However the fact that it has worked so well for me on so many systems suggests that it’s not going to cause huge problems, it should be covered in the routine testing that is needed for a significant deployment of any new version of a distribution.

I’ve been using Debian for a long time. The transitions from libc4 to libc5 and then libc6 were complex but didn’t break much. The use of devfs in Debian caused some issues and then the removal of devfs caused other issues. The introduction of udev probably caused problems for some people too. Doing major updates to Debian systems isn’t something that is new or which will necessarily cause significant problems, I don’t think that the change to systemd by default compares to changing from a.out binaries to ELF binaries (which required replacing all shared objects and executables).

The Social Issue of the Default Init

Recently the Debian technical committee determined that Systemd was the best choice for the default init system in Debian/Jessie (the next release of Debian which will come out soon). Decisions about which programs should be in the default install are made periodically and it’s usually not a big deal. Even when the choice is between options that directly involve the user (such as the KDE and GNOME desktop environments) it’s not really a big deal because you can just install a non-default option.

One of the strengths of Debian has always been the fact that any Debian Developer (DD) can just add any new package to the archive if they maintain it to a suitable technical standard and if copyright and all other relevant laws are respected. Any DD who doesn’t like any of the current init systems can just package a new one and upload it. Obviously the default option will get more testing, so the non-default options will need more testing by the maintainer. This is particularly difficult for programs that have significant interaction with other parts of the system, I’ve had difficulties with this over the course of 14 years of SE Linux development but I’ve also found that it’s not an impossible problem to solve.

It’s generally accepted that making demands of other people’s volunteer work is a bad thing, which to some extent is a reasonable position. There is a problem when this is taken to extremes, Debian has over 1000 developers who have to work together so sometimes it’s a question of who gets to do the extra work to make the parts of the distribution fit together. The issue of who gets to do the work is often based on what parts are the defaults or most commonly used options. For my work on SE Linux I often have to do a lot of extra work because it’s not part of the default install and I have to make my requests for changes to other packages be as small and simple as possible.

So part of the decision to make Systemd be the default init is essentially a decision to impose slightly more development effort on the people who maintain SysVInit if they are to provide the same level of support – of course given the lack of overall development on SysVInit the level of support provided may decrease. It also means slightly less development effort for the people who maintain Systemd as developers of daemon packages MUST make them work with it. Another part of this issue is the fact that DDs who maintain daemon packages need to maintain init.d scripts (for SysVInit) and systemd scripts, presumably most DDs will have a preference for one init system and do less testing for the other one. Therefore the choice of systemd as the default means that slightly less developer effort will go into init.d scripts. On average this will slightly increase the amount of sysadmin effort that will be required to run systems with SysVInit as the scripts will on average be less well tested. This isn’t going to be a problem in the short term as the current scripts are working reasonably well, but over the course of years bugs may creep in and a proposed solution to this is to have SysVInit scripts generated from systemd config files.

We did have a long debate within Debian about the issue of default init systems and many Debian Developers disagree about this. But there is a big difference between volunteers debating about their work and external people who don’t contribute but believe that they are entitled to tell us what to do. Especially when the non-contributors abuse the people who do the work.

The Crowd Reaction

In a world filled with reasonable people who aren’t assholes there wouldn’t be any more reaction to this than there has been to decisions such as which desktop environment should be the default (which has caused some debate but nothing serious). The issue of which desktop environment (or which version of a desktop environment) to support has a significant affect on users that can’t be avoided, I could understand people being a little upset about that. But the init system isn’t something that most users will notice – apart from the boot time.

For some reason the men in the Linux community who hate women the most seem to have taken a dislike to systemd. I understand that being “conservative” might mean not wanting changes to software as well as not wanting changes to inequality in society but even so this surprised me. My last blog post about systemd has probably set a personal record for the amount of misogynistic and homophobic abuse I received in the comments. More gender and sexuality related abuse than I usually receive when posting about the issues of gender and sexuality in the context of the FOSS community! For the record this doesn’t bother me, when I get such abuse I’m just going to write more about the topic in question.

While the issue of which init system to use by default in Debian was being discussed we had a lot of hostility from unimportant people who for some reason thought that they might get their way by being abusive and threatening people. As expected that didn’t give the result they desired, but it did result in a small trend towards people who are less concerned about the reactions of users taking on development work related to init systems.

The next thing that they did was to announce a “fork” of Debian. Forking software means maintaining a separate version due to a serious disagreement about how it should be maintained. Doing that requires a significant amount of work in compiling all the source code and testing the results. The sensible option would be to just maintain a separate repository of modified packages as has been done many times before. One of the most well known repositories was the Debian Multimedia repository, it was controversial due to flouting legal issues (the developer produced code that was legal where they lived) and due to confusion among users. But it demonstrated that you can make a repository containing many modified packages. In my work on SE Linux I’ve always had a repository of packages containing changes that haven’t been accepted into Debian, which included changes to SysVInit in about 2001.

The latest news on the fork-Debian front seems to be the call for donations [4]. Apparently most of the money that was spent went to accounting fees and buying a laptop for a developer. The amount of money involved is fairly small, Forbes has an article about how awful people can use “controversy” to get crowd-funding windfalls [5].

MikeeUSA is an evil person who hates systemd [6]. This isn’t any sort of evidence that systemd is great (I’m sure that evil people make reasonable choices about software on occasion). But it is a significant factor in support for non-systemd variants of Debian (and other Linux distributions). Decent people don’t want to be associated with people like MikeeUSA, the fact that the anti-systemd people seem happy to associate with him isn’t going to help their cause.

Conclusion

Forking Debian is not the correct technical solution to any problem you might have with a few packages. Filing bug reports and possibly forking those packages in an external repository is the right thing to do.

Sending homophobic and sexist abuse is going to make you as popular as the GamerGate and GodHatesAmerica.com people. It’s not going to convince anyone to change their mind about technical decisions.

Abusing volunteers who might consider donating some of their time to projects that you like is generally a bad idea. If you abuse them enough you might get them to volunteer less of their time, but the most likely result is that they just don’t volunteer on anything associated with you.

Abusing people who write technical blog posts isn’t going to convince them that they made an error. Abuse is evidence of the absence of technical errors.

Related posts:

  1. systemd – a Replacement for init etc The systemd projecct is an interesting concept for replacing init...
  2. Systemd Notes A few months ago I gave a lecture about systemd...
  3. more on anti-spam In response to my last entry about anti-spam measures and...
Categories: thinktime

To overcome an irrational fear...

Seth Godin - Sun 26th Apr 2015 19:04
replace it with a habit. If you're afraid to write, write a little, every day. Start with an anonymous blog, start with a sentence. Every day, drip, drip, drip, a habit. If you're afraid to speak up, speak up a...        Seth Godin
Categories: thinktime

Terroir

Seth Godin - Sat 25th Apr 2015 18:04
You can taste it. Heinz ketchup has no terroir. It always tastes like everywhere and nowhere and the same. A Dijon mustard from a small producer in France, though, you can taste where it came from. Foodies seek out this...        Seth Godin
Categories: thinktime

Chris Samuel: The True Meaning of Myki

Planet Linux Australia - Sat 25th Apr 2015 18:04

Those around Victoria will be familiar with our public transport payment system called “Myki” which has had, shall we say, some teething troubles. It appears this was well known to the Vikings over 1,000 years ago as this list of Old Norse words that made it into English has:

muck – myki (cow dung)

So there you go, Myki is actually Old Norse for bullshit.

This item originally posted here:



The True Meaning of Myki

Categories: thinktime

Michael Still: Tuggeranong Trig (again)

Planet Linux Australia - Sat 25th Apr 2015 11:04
The cubs at my local scout group are interested in walking to a trig, but have some interesting constraints around mobility for a couple of their members. I therefore offered to re-walk Tuggeranong Trig in Oxley with an eye out for terrain. I think this walk would be very doable for cubs -- its 650 meters with only about 25 meters of vertical change. The path is also ok for a wheelchair I think.



             



Interactive map for this route.



Tags for this post: blog pictures 20150415-tuggeranong_trig photo canberra bushwalk trig_point

Related posts: Goodwin trig; Big Monks; Narrabundah trig and 16 geocaches; Cooleman and Arawang Trigs; One Tree and Painter; A walk around Mount Stranger



Comment
Categories: thinktime

Donna Benjamin: Peace and Freedom

Planet Linux Australia - Sat 25th Apr 2015 09:04
Saturday, April 25, 2015 - 09:02

It's ANZAC day.

It's the 100 year anniversary of a particularly bad battle in Turkey, that has somehow come to represent the apex of Australian and NewZealand glorification of war. Sure, we say it's not glorifying war - but seriously how is this wall to wall coverage not glorification? The coverage in all media over the past week has numbed my senses. Not made me reflect on sacrifice.

All our focus on this one stupid battle? I'd like to put some focus on those efforts to stop the slaughter.

Gallipolli was ultimately a battle lost for the ANZACs.

So too was the attempt by over 1000 women who came together in 1915 to try to stop war. To call for resolutions for peace. To identify and disarm the causes of conflict. If only we could reflect more on that effort.

The Women's International League for Peace and Freedom - http://www.wilpf.org.au/centenary/100years

Image: Screengrab from http://honesthistory.net.au/wp/wp-content/uploads/WILPF_posters_72dpi-FI...

Text in the image says:

As the British army, including Anzacs, is invading Turkey more than 1000 women from both warring and neutral nations meet in The Hague for the International Congress of Women. They set out resolutions for ending all war and resolve to take them immediately to all heads of state in Europe and the USA. They name themselves the International Committee of Women for Permanent Peace.

"I know that the idea that lasting peace can be gained through war is nonsense" - Eleanor Moore

Categories: thinktime

Context Makes Our Devices

a list apart - Fri 24th Apr 2015 22:04

A few weeks ago, Josh Dzieza of The Verge had this to say about the Apple Watch, and really smartwatches as a whole:

That seems nice but doesn’t really answer the question of why you’d spend a few hundred dollars (or more) for a device that does the same things as the device in your pocket.

When smartphones were first gaining popularity, I could’ve expressed the exact same concern, swapping the word “pocket” for “backpack.” Why would I spend so much money on a phone when my laptop can already manage email, calendars, and notes?

Statements like that overlook the reason why certain device categories become successful: context. Smartphones gained popularity because they proved so useful in contexts where laptops or larger devices weren’t feasible.

New device categories often start out by doing the same tasks as existing devices, but history has shown that successful categories are those that bring an entirely new context and fundamentally change the way we use technology.

Those new contexts provide opportunities for applications, services, and experiences that wouldn’t have been possible in previous generations of technology. Instagram grew so quickly because phones with high-quality cameras and always-on internet connections became a commonplace in pockets across the world.

Podcasts came into their own because devices with large hard drives became portable enough to take anywhere. Highly-localized weather forecasting applications like Dark Sky, reading list services like Instapaper, and the entire industry of mobile gaming came into existence because of the contexts opened up by new device categories.

What will be this new, always-on-you context’s star? Healthcare seems like an early leader to answer that question—the upcoming generation of wearables are finally pushing the category beyond the “fancy pedometer” stage.

The Microsoft Band, Samsung Gear lineup, and Apple Watch all pack a heart rate sensor, which can help measure calorie burn, activity levels, and overall health through continuous monitoring. The upcoming Samsung Simband contains six sensors to monitor heart rate, blood pressure, skin temperature, oxygen levels, and displays a real-time electrocardiogram. Even though the strap looks like something out of Tron, it’s an impressive piece of technology.

Beyond fitness, this type of monitoring can improve the lives of many people living with certain health conditions today. From early warnings for those with asthma and respiratory illnesses, to glucose monitoring for those living with diabetes, there is a ton of potential for technology to assist people in truly meaningful ways.

Apple’s HealthKit and (recently-open sourced) ResearchKit are especially exciting when paired with these new devices. HealthKit enables the collation of a user’s data into a private, secure location, providing both high-level and detailed views of health statistics. ResearchKit is a way to use collected data to contribute to health studies around the world, and has already been making great progress.

Stanford University had more than 11,000 people sign up for a cardiovascular study using ResearchKit less than 24 hours after the framework was announced. Alan Yeung, the medical director of Stanford Cardiovascular Health, said, “To get 10,000 people enrolled in a medical study normally, it would take a year and 50 medical centers around the country. That’s the power of the phone.”

His last point is key—all of the current ResearchKit work has been done with iPhones—devices that sit in pockets, purses, and backpacks. Imagine what is possible when a non-trivial number of people involved in these studies have a device filled with sensors strapped to their wrist all day long. Participants around the world can wear these new devices to provide researchers a constant, holistic view of their health with precise and reliable data, enabling more accurate results.

The progress made in these studies won’t just benefit those fortunate enough to afford the devices in the first place—healthcare providers anywhere can take advantage of new discoveries.

Healthcare isn’t the only area with potential in this new context. If wearables are to be successful, communication patterns will change around them, the way we interact with services and tools in our lives will adapt to their use, and new things we haven’t yet experienced will be created.

It’s important to remember that new device categories rarely replace existing ones. They are merely one more device type on the web, waiting to be used to their fullest potential—and that’s where our fun begins.

 

Categories: thinktime

Reckless abandon (is neither)

Seth Godin - Fri 24th Apr 2015 19:04
It's not reckless, because when we leap, when we dive in, when we begin, only begin, we bring our true nature to the project, we make it personal and urgent. And it's not abandon, not in the sense that we've...        Seth Godin
Categories: thinktime

Thanks

Seth Godin - Fri 24th Apr 2015 00:04
In just two days, my new course for freelancers is the fastest-growing one of its kind in Udemy's history. I'm thrilled to see that so many of my readers are eager to dig in and make a difference. The course...         Seth Godin
Categories: thinktime

This week's sponsor: Beagle

a list apart - Thu 23rd Apr 2015 22:04

Thanks to Beagle​ for sponsoring A List Apart this week. Take a look at their tools to help you save time, collaborate with your team, and create more effective proposals.

Categories: thinktime

Andrew McDonnell: Why is the Arduino IDE so stupid?

Planet Linux Australia - Thu 23rd Apr 2015 22:04

If I perform the following actions:

  • File, New

    Opens a new editor window. Reasonable enough, although I would have preferred a default single-window GUI model like QtCreator or even gedit.
  • File, Save

    Opens a save as dialog. In spite of the Arduino ‘sketchbook’ directory, it opens in my home directory.
  • New Folder

    Creates a directory New Folder, but doesn’t shift the focus to it, leaving you confused when this is done in a directory with a lot of files…
  • Click on ‘New Folder’ and rename it, say, Test123
  • Navigate into Test123/
  • Type in a filename for the project, say, TestTest1
  • Hit save.

    So now Arduino IDE dutifully ignores what I typed and proceeds to create a tab called ‘Test123′.

    It will even do this if ‘Test123/’ already existed.

    What?
  • File, Save As.

    It forgets where you where in the hierarchy and starts in the home directory again(!)
  • Navigate to Test123/ intending to use it as a container for multiple projects
  • Type in a filename, say Hello, then hit Save
  • The sketch is _still_ called Test123.

    What?

So insanely enough, it seems you essentially create a director and thats where the sketch gets its name.  Within that directory it creates a file with the same name with the extension ‘.ino’

Lets try something else:

  • From the shell, create a directory, Test456 and create a readme.txt file, and a directory Test456a and a file Test456a/readme2.txt
  • File New
  • File save
  • Navigate into Test456
  • Type in helloworld for the name
  • Again, the project gets called Test456
  • But take a look in the directory Test456: the contents are now gone (all, including the sub directory Test456a) and replaced with Test123.ino

    Wait, what? THIS SHOULD NEVER EVER HAPPEN!!!!

Luckily I discovered this in a directory in a git working copy with no modifications so I didn’t lose anything important.

Testing done using Arduino1.5.8 amd64 for Digispark. So its a little out of date but not exactly the oldest either.

I have used Arduino before and to be honest I don’t recall it being this stupid, but maybe I just got lucky.

One difference is this time I got sick of the massive latency opening the windows and tried a few different Java JRE (openjdk6, openjdk7, gcc4.7-jre) before discovering that with gcc4.7-jre the menus are as snappy as the openbox right click menu, or even a (*sharp intake of breath*) brand new Windows 7 corporate desktop… maybe there is some API implementation difference between the JRE’s that affects the file save dialog functionality.

I don’t seem to have any issues opening projects.

So my workflow for creating a new project now consists of:

  • From the shell, create a directory in the relevant part of the git working copy I am using
  • Create a new empty .ino text file with the same name as the directory (or copy a template I made)
  • Open it with the IDE and start working

 

Categories: thinktime

People are real, but the crowd disappoints

Seth Godin - Thu 23rd Apr 2015 19:04
Every crowd, sooner or later, will let you down. The crowd contains a shoplifter, or a heckler, or an anonymous boor who leaves a snarky comment. The crowd loses interest, the crowd denigrates the work, the crowd isn't serious. Worst...         Seth Godin
Categories: thinktime

Rian van der Merwe on A View from a Different Valley: Why?

a list apart - Wed 22nd Apr 2015 22:04

My two-year-old daughter is going through a “Why?” phase. I’m not too worried about it, though. I had plenty of practice when my five-year-old went through the same thing, and through trial and error I figured out the best way to survive it.

So here it is: the only way to get a preschooler to stop asking why? is to out-why? them. Whenever they ask a question, answer it. Don’t get impatient, don’t sigh and say, “just because”—none of that stuff. Push right through those impulses. Instead, take it wherever it goes. Use Wikipedia if you need to. Never give in, never give up. If you answer every why? question with gusto, eventually your child will get bored and move on to another topic or game. It never fails.

Well, it almost never fails. I recently had an experience with my two-year-old where I had to deviate from this tried and tested path. One morning she asked me, “Daddy, why do you go to work?” My preprogrammed brain immediately switched to out-why? mode; I geared up for another long session, opened my mouth… and then closed it. I didn’t know what to say. I was speechless.

I didn’t want to say “To make money so we have food to eat.” That’s (part of) the truth, but I don’t want to teach her that we work only for material reasons. I couldn’t say “To make the world a better place,” because that just makes me sound ridiculous and it’s not the whole truth either (as much as I want it to be).

So there I was, stuck on what should have been a pretty simple question. Why do I go to work? Why is that so hard to explain? Do I even know why? The thing is, it does get complicated very quickly once you start playing out some of the scenarios. Here’s just one way it could have gone down with my daughter:

Emery, I go to work because it’s what society expects. So that we can have food and a place to live, and so that I can help pay for things we use every day like schools and roads. But I also work because I want to be creative and use my brain wisely—and preferably do that in a way that makes other people’s lives a little better or easier in some way.

What’s that? Oh, Mommy chooses not to work, not because she can’t or doesn’t want to, but because what she wants more right now is to be with you guys as much as possible while you’re still so young. Not everyone gets to decide that, so we’re very lucky. And when she decides to go back to work it won’t be because she doesn’t love you but because she also wants to do all those things I mentioned earlier.

Hmmm? Well, see, some people don’t work because they don’t want to, others because they can’t find a job—and that can be really hard for them and their families. Some people do jobs that they don’t want to do, but they have to because it’s all there is, and they don’t have a choice.

As I played this scenario out in my mind, further and further into the depths of tangled reasoning, I realized why I didn’t know what to say. It’s because I’ve increasingly become aware of the reasons I am where I am, and live where I live. And as much as we all want to believe that our successes happen because we’re so awesome, the truth is that where we’re from and how we grew up and what kind of opportunities we had as children play an enormous role in all of it.

When we water down work to pithy sayings like “do what you love” or “work is love made visible” we do the complexity of the topic an enormous disservice, and we ignore the huge role that—yes, I’m going to go there—privilege plays in all of it. You see, “do what you love” is only possible if you’re in a financial and social position to follow your passion wherever it goes. “Work is love made visible” is easier said than done when you have three jobs that you don’t like, and have to struggle to make it through the day.

I don’t have an answer for my daughter on the work question yet. But I do know that why we work—and what kind of work we do—is a function of our privilege and our history as much as it is a function of our choices and our dedication.

I do have a question for my daughter, though. A question we should probably explore together before we get into the work thing. I think I’ll go home tonight and ask her “why?” Why do we get to live here? Why does she get to go to school? What keeps some others from having the same opportunities? Is that fair? Can we become more conscious of our privilege? How can we shine a light on injustice all around us and get involved in our community in more helpful ways?

My daughter probably won’t like it if I turn the why? tables on her. But I think it’s important. I think we should place emphasis a little more on how we can help others who don’t have our privilege and history than on how to be happy and rich. If my daughter and I both learn that out of the exchange, I’d consider it a win not just for parenting, but for my own life as well.

Categories: thinktime

Demand higher standards

Seth Godin - Wed 22nd Apr 2015 19:04
On a long flight a little while ago, I saw two couples watch movies while they let their six kids run around like maniacs from take off to touchdown. A seven-year old actually punched me. (I didn't return the punch)....        Seth Godin
Categories: thinktime

What Really Matters: Focusing on Top Tasks

a list apart - Wed 22nd Apr 2015 00:04

Digital is a space of endless replication. It has never been easier to create—and create, and create. People love to publish, but they hate to remove, which leads to overloaded websites and constant, inevitable redesigns. The top layers get a shiny new coat of graphics and meaningless “we really care” content—but underneath, a teeming mass of out-of-date, badly organized information still swirls about.

The solution is to make hard choices using Top Tasks Management. Top tasks are the small set of tasks (usually less than 10, often less than five) that matter most to your customers. Make these tasks work well, and you’ll be on the right track. Get them wrong, and chances are you’ll lose the customer.

Top Tasks Management is a model that says: “Focus on what really matters (the top tasks) and defocus on what matters less (the tiny tasks).”

Tiny tasks are a nightmare for web teams. On their own, these tasks seem innocent enough. It’s just one more page, one more link, one more graphic. But gather them up, and many a web professional has found themselves nibbled to death.

Tiny tasks are also full of organizational ego. Often, the more important the task is to the customer, the less content is being produced for it; the less important the task is to the customer, the more content is being produced. This inverse relationship is very typical.

Identifying top tasks

The purpose of Top Tasks Management is to reduce complexity by identifying what really matters to customers. The following steps are involved in a task identification process:

  1. Comprehensively engage the organization in a process of gathering customer tasks.
  2. Work with key stakeholders to come up with a shortlist of these tasks.
  3. Get a representative sample of customers to vote.
  4. Create a league table of tasks from the one with the highest vote to the one with the lowest vote.
Step 1: Gathering the longlist of potential tasks

Use the process of gathering tasks to get outside of organization thinking and inside the customers’ mind and world. Actively engage the key stakeholders in this process. It can be a great way to get the whole organization thinking about what the customer wants to do, rather than what the organization wants the customer to do.

When gathering the list of customer tasks, use as much data as possible. Here are some common data sources for customer tasks:

  • Corporate philosophy: Strategy, mission and vision, and corporate objectives.
  • Customer feedback: Survey results, frequent help requests, insight from support or service teams.
  • Stakeholder reviews: Interview key stakeholders and ask them what they consider top customer tasks.
  • Competitor or peer websites: Review competitor or peer websites and see what sorts of tasks are cropping up.
  • Traditional and social media: What sorts of tasks are being mentioned by customers on social media? Are there specialist traditional media that cover your industry?
  • Site behavior analysis: Most visited pages, most popular downloads.
  • Search analysis: Top search terms on the website, as well as Google public search behavior for your industry.

Why go to all this bother? Why not just depend on the numbers for your most visited pages and top search terms? The truth is that these can be unreliable metrics:

  1. Page visits reflect what you have, not necessarily what customers want. There may be tasks that you don’t have content for—so it’s unlikely they will show up in search and site data. And analyses of page views often reflect an amalgam of tasks; it’s hard to separate the top tasks on these pages from the tiny tasks.
  2. Search is a window into customer behavior, but it doesn’t tell the whole story. For example, when we worked on the BBC intranet, we found they had a feature called “Top Searches” on their homepage. The problem was that once they published the top searches list, these terms no longer needed to be searched for, so in time a new list of top searches emerged! Similarly, top tasks tend to get bookmarked, so they don’t show up as much in search. And the better the navigation, the more likely the site search is to reflect tiny tasks.

Cisco recently undertook a project using Top Tasks Management. When we completed their research, we had over 600 tasks. (In a typical project, we tend to gather between 300 and 500.) Here is a small sample of what the initial tasks looked like for Cisco:

  • Add a network diagram
  • Annual reports
  • Attendant console
  • Benefits of product
  • Network engineer blogs
  • US forums and communities
  • Bug toolkit
  • Bugs, debugging
  • Certifications
  • Cisco MeetingPlace
  • Collaboration
  • Get pricing
  • How to configure
  • Discussion forums
  • Technical forums
  • Support community
  • RV082 installation
  • Network Magic
  • Self-service

There were duplicates, areas of overlap, branding words, and internal jargon. It needed a lot of cleaning up!

Step 2: Getting to a shortlist of tasks

The next step is to bring the longlist of tasks down to a shortlist of no more than 100. Getting a feel for the tasks takes time, which is why we recommend planning on four to six weeks to do the task research and get to the shortlist. Here are some guidelines for shortening your list:

  1. Don’t use brands, jargon, tools, or formats. Get to the essence of what the thing helps the customer do. Avoid specialized or vague phrases like “MeetingPlace,” “Network Magic,” or “Videos.” What is the essence of the task? Is it Pricing, Configuration, Troubleshooting, Training?
  2. Avoid product names or groups. Instead of “RV082 installation,” use “Installation,” as that covers all products. Don’t use “Collaboration” or “TelePresence,” as these are product groups.
  3. Eliminate overlap. “Bug toolkit” and “Bugs, debugging” are essentially the same thing, so you can bring them together into one task. There’s also a lot of overlap between “Technical forums,” “Support community,” “Forums and communities.” We probably only need one task here.
  4. Avoid lofty concepts and goals. A goal is wanting to spend more time with your family, but a web task is booking a vacation. All of the tasks on the list should be roughly at the same level. What do “Self-service” and “Knowledge Base” actually mean?
  5. Ignore audiences and demographics. Keep tasks universal. We don’t want “Network engineer blogs” or “US forums and communities.”
  6. Avoid verbs. The noun is the task. Only use verbs when they’re essential. The list becomes very difficult to scan when so many tasks begin with “find,” “get,” etc. We don’t need “Get Pricing”; the word “Pricing” is fine.
  7. Avoid phrase repetition. Try not to have more than four tasks in your final list begin with the same word. In the longlist, we had lots of tasks beginning with “Cisco.” In the final shortlist, we only used “Cisco” where we felt it was absolutely essential.
  8. Be concise. Use a maximum of seven words or 55 characters for any particular task.

Your tasks might also include subtasks in parentheses. Subtasks should not be exhaustive—typically just two or three examples—and we do not use “etc.” at the end (or else every task would have it).

At the end of the process with Cisco, they agreed on 67 tasks that reflected what customers wanted to do. It was the first time this organizational consensus had ever occurred. Here’s a sample of the list:

  • Troubleshooting (bug fixes, diagnostics, guides)
  • Blogs
  • Calculate return on investment (ROI)
  • Check product or service availability (lead times, back order, in stock, in my region)
  • Compare Cisco products, services and solutions to each other
  • Customer / user reviews and ratings
  • Download software, firmware, drivers, patches, updates
  • Follow Cisco on Twitter, Facebook, YouTube
  • Network design (tech guides, notes, examples)
  • Pricing for an individual product or service
  • Training (courses, calendar, locations)
  • Troubleshooting (bug fixes, diagnostics, guides)

Notice that we did include “Blogs,” despite our rule against including formats. Sometimes we leave in a word or phrase just to prove that it will not get a big vote. If there’s a buzzword that is all the rage internally, consider leaving it on the list just to see how customers react.

By far the most important part of the shortlisting process is involving as many key stakeholders as possible. We brought together people from Cisco’s marketing, support, communications, product, and other teams. It was a hugely enlightening process for everyone involved. They began to understand where there was overlap, and how they would need to collaborate on content and navigation.

Step 3: Getting customers to vote

The third step is to have customers weigh in on the shortlist. We usually send out a survey and ask each person to rank five tasks, giving 5 to the most important, 4 to the next-most important, and so on:


That’s a joke, right? Nobody would do that. It breaks all the rules of psychology and survey design. It’s simply not possible. Yet in the last 10 years, we have done over 400 similar surveys with close to 400,000 people voting. It’s crazy, but it works.

The voting survey needs to be designed this way because:

  1. We want to find out what really matters to people—what they do versus what they say they do. The very length and overload of the survey forces the gut instinct to kick in. You don’t “read” the list; rather, the tasks that really matter to you jump out.
  2. The core deliverable of the survey is a league table of tasks. You get to know not just the top tasks, but also the tiny tasks, and how each task ranks in relation to other tasks. It gives you a hierarchy of importance that will allow you to make design and content decisions—what to prioritize, what not to prioritize.
Step 4: Analyzing the results

Cisco is a complex world. The 67 tasks in the final task list were all seen as top tasks. They had been edited down from a list of more than 600. And yet, when the votes were counted, here’s what happened:

Three tasks got the first 25 percent of the vote. Six tasks got from 25–50 percent of the vote, 14 tasks got from 50–75 percent of the vote, and 44 tasks got from 75–100 percent. Yes, three tasks got as much of the vote as the bottom 44. In fact, the top task (“Download software”) got as much of the vote as the bottom 23 tasks.

We have done this process over 400 times and the same patterns emerge every single time.

This is Cisco’s league table of the top 20 tasks:

The top task (“Download software”) got 2,408 votes out of a total of 26,160 votes cast, representing 9.2 percent of the overall vote.

Here are the tasks at the bottom of the vote:


The bottom task (“Financing, leasing options”) got 29 votes. This is not to say that financing and leasing are unimportant; it’s just that people don’t go to Cisco.com for them. Also, notice how “Blogs” got just 76 votes out of 26,160 cast. People don’t care about the format. They care about the task of installing the RV082 router, for example. If they find a blog post about how best to install the RV082, then, sure, they’ll read that.

Using the results

The benefits of such an evidence-based, collaborative approach are worth the effort. For example, in 2010, downloading a typical piece of software could take 15 convoluted steps and an average of 280 seconds. Now, much of the software can be downloaded in four steps and an average of 45 seconds. Success rates have improved for many tasks by as much as 30 percent.

Every six months, Cisco does a formal test of its top tasks, giving real customers real examples of top tasks and measuring success rates and time on task. These “Task Performance Indicators” have become Key Performance Indicators for the Cisco web team.

Another key outcome of Top Tasks Management is a more collaborative work environment, where people come together to manage a task, rather than just manage a website or an app or publish content for a particular department. Cisco has embraced this approach; the Marketing and Support divisions are in regular contact, and employees from IT, usability, content, and experience design work closely and coordinate their efforts.

The essence of a great customer experience is to help people quickly and easily complete their tasks—but to do that, you need evidence of those tasks, not opinions. Top Tasks Management gives you the data to focus on what really matters: removing (or at least deemphasizing) a whole plethora of tiny tasks, and improving the small set of top tasks that your customers really want.

Categories: thinktime

Standardization and the Open Web

a list apart - Wed 22nd Apr 2015 00:04

We’re done arguing over the importance of web standards. Accessibility, stability, quality control, and ease-of-use all helped to settle the debate long ago. Advocacy websites created to promote web standards—such as Chris Heilmann’s Web Standards for Business and The Web Standards Project—haven’t needed to change at all since the mid-2000s.

What has changed, however, is the way standards are developed—an issue arguably as important as the standards themselves. The next community debate, then, isn’t about web standards; it’s about how web standards should be standardized.

What’s in a standard?

The idea that standardization is important is reflected in the language we use to describe our projects and communities. For example, the JSON API homepage states that it is a “Standard for building APIs in JSON.” The FAQ page describes JSON API as a specification, and developers are talking about its use in terms of compliance. A competing project, HAL, references the visual language of standardization on its website—the flow of the page reminiscent of a formal Request For Comment, before directing you to the actual Internet Engineering Task Force RFC.

These projects illustrate a conflation of ideas about standards, which, left unaddressed, can lead to confusion. Both the JSON API specification and the HAL specification are de facto standards—an idea for a best practice approach to a common-use problem that is spreading organically through the developer community.

The specifications we tend to think of more commonly, such as those for HTML and JavaScript, are voluntary consensus standards, meaning that international standards-setting bodies and industry consortia have agreed to work on and adopt these specifications, and create incentives for their implementation. But even in a voluntary consensus environment, differences of opinion can split a technology—JSON (not to be confused with JSON API) actually has two competing voluntary consensus specifications: one with the standards group Ecma, the other with IETF.

While the term “standard” is used here in all cases, all specifications are not created equal. We sometimes even see RFCs for technical specifications that will never become standards because they are theoretical ideas for how something might work; ergo, all standards will have specifications, but not all specifications are standards.

Making standards

“Official” standards are specifications that have gone through a process of voluntary consensus. There is potentially a clear path for projects to evolve from a de facto specification to one that is standardized through voluntary consensus:

  1. Developer identifies problem and proposes solution to peers;
  2. Peer community provides feedback and proposes potential alternate solutions in public channels like GitHub or Google Groups;
  3. Peer community reaches mass consensus and hands specification off to a standards body;
  4. Developers implement solution while the standards body formalizes and legalizes the standard.

Most developers I know are smart, resourceful, and prefer the path of least resistance; thanks to the all bugs are shallow mentality of the OSS community, they’re inclined to work together to solve issues of mutual concern. This is a fairly straightforward, not-at-all-new idea, and The Extensible Web Manifesto is essentially a call to action to implement more developer feedback on this very process.

It’s exciting to think that the next official web standards might come from the developer community, but in practice this path to official standardization has been obfuscated. The Responsive Images Community Group experienced this firsthand when it proposed a specification for the picture element—noting an issue with the way HTML handled responsive images, the RICG proposed a developer-built, de facto solution to the Web Hypertext Application Technology Working Group, maintainers of the “living” HTML standard. In a well-documented series of events, WHATWG practically dismissed the developer solution in favor of a vaguely specified solution they created over the course of a few days. If it weren’t for the passion and persistence of the community and of RICG leadership, the developer solution would’ve been defeated.

The RICG specification was ultimately accepted by WHATWG and the W3C, but the experience of the standardization process certainly left a bad taste in developers’ mouths. It would be easy enough to focus our attention on improving this process for community groups like RICG, and the web would certainly be a better place for developers if we did so—but wouldn’t it be nice if we could define standardization not as “a process that makes technology,” but as “a process that makes agreements about technology”?

In reality, open standardization is a fundamentally power-laden and political process, and it’s making its way into how we think about Open Source project and community governance. Put in the terms of Eric Raymond’s seminal essay, we’ve built web technologies in the bazaar-style of the open source development ethos, but standardizing those technologies is a cathedral-building activity.

As we seek to standardize technology, we need to recognize the tension inherent in building cathedrals that will later become central authorities for us to reject. Our challenge is to find the balance between capitalizing on the benefits of standardization processes without eroding our community ideals. Thankfully, there are long histories of standardization efforts in other industries and communities that can provide insight for standardizing the web.

Old models for modern standards

Open source communities can learn a lot from the histories and governance models of different standards organizations—indeed, web standards consortia like Ecma International and the W3C already have similar organizational structures, but it’s helpful to understand the prior art upon which we are laying our community standards-setting foundation. After all, the “keep what works” mentality only works in the long run if you understand why it works in the first place.

Good programmers know what to write. Great ones know what to rewrite (and reuse). Eric Raymond

The ideological origins of web standards bodies come from early efforts to standardize telegraphy and engineering in the 19th century, through committees such as the American Society of Civil Engineers, American Society of Mechanical Engineers, and American Institute of Electrical Engineers. Many hosted regular “congresses”—Victorian-era precursors to today’s web development conferences—that helped to create standards and to further define the identity of the professional engineer.

As engineering disciplines began to overlap, it became clear that cooperation between these industrial societies would be necessary, so in 1918 the American Engineering Standards Committee was formed to encourage cooperation and coordination of standards across groups. The resulting structure was an “organization of organizations” that facilitated consensus-building among multiple engineering organizations, each comprised of a diverse pool of engineers from a diverse set of companies.

Today, the AESC is known as the American National Standards Institute, but its 100-year-old model of governance—rife with community crises and ideals—is reflected in web standards groups. Then, as now, organizational disputes often arose between “shop culture” practitioners and “school culture” academics. A certain amount of tension between groups is healthy for moving ideas forward, and these early groups evolved organizational means for creating and releasing tension as necessary. Today’s default response to disputes in open-source software is to fork the specification in question, producing a network of rival camps who are incentivized to emphasize differences instead of areas of agreement.

When ideals compete

“Openness” is a core ideal in the Open Web community, as well as something of a polluted word. The rhetoric of openness is meant to communicate a favorable set of values, and those values often depend on the speaker and the audience. In his book Open Standards and the Digital Age, Professor Andrew Russell notes that “for individuals, ‘open’ is shorthand for transparent, welcoming, participatory, and entrepreneurial; for society at large, open signifies a vast increase in the flow of goods and information through a global, market-oriented system of exchange.” In the absence of a single definition that suits all parties, we tend to take “open” to mean “inclusive of everything.”

Standardization, on the other hand, is often a process that defines what something is in terms of what it is not. Russell notes that the broader societal goal of standardizing technology is to create a “cohesive and flexible network” that can sustain complex social and economic activity. Thus, the process of making standards means incorporating a wide range of practices and ideas with political, economic, and cultural dimensions—all of which may be of strategic importance to creators, implementors, end users, and the general public. Put this way, standards are technically-oriented instances of diplomacy.

In establishing the ISO subcommittee for developing open working standards in 1977, Charles Bachmann noted that “the adjective ‘open’ means to imply that all participants come to the system as equal partners.” In reality, participants don’t often come to the table as equal partners—the OSI’s own progress was stymied by organizational power plays and the growth of a competing technology, TCP/IP. But equality as an ideal of open standards-making has remained. This ideal is rooted in a deeply held opposition to centralized power, which, according to Russell, is reflected in the histories of many standards-setting organizations. Upholding this vision of equality and achieving successful implementation meant, at times, hiding conflicts and issues from those outside the meeting room—not exactly the transparent behavior one might expect from an “open” system. 

If standards really are agreements between equal parties, then the agreement is the controlling authority. And if standards-setting is a rejection of centralized control, then the standardization process becomes one of creative destruction. It’s the ideological circle of open-standards-making life: a group makes a consensus standard on some technology; as the standard circulates, a new party arises to point out a flaw or an unconsidered use case for the existing standard. The original group then has to make room for the new party and rework the standard, or else face rejection of the group and the standard. In rejecting the original group, the offended party forms a competing group and standard, and the cycle begins anew. 

It’s complicated

It’s a tangled web we weave standardizing the Open Web—political, economic, and social relationships between people, technologies, companies, and industry groups are difficult to ascertain at a glance. On closer inspection, one can see that these organizations and communities are complex systems forming a complex network—so complex that I was compelled to create this interactive Open Standards network graph to help keep it all straight as I researched.

Before we rush off to create a complex, decentralized network of open source standards groups, it probably warrants mentioning that complex systems fail 100% of the time. A decentralized network may let us fail smaller in most cases, but the key to longevity of the system is failing smart—and if the research has taught me anything, it’s that standardization fails on the human, not the technological, element. For better or worse, complexity is not viral—so to mitigate this, we need to make the complexity of the standardization system consumable without abstracting away meaningful parts of the process.

In the absence of community coordination, methodless enthusiasm will ensue—and caught somewhere in the Bermuda triangle of competing standards bodies, implementers, and OSS maintainers is the developer community. If we want our community-driven projects to become official, internationally recognized standards, we need to understand the impact of our governance processes as well as we understand the technical specifications for our technologies.

Categories: thinktime

The freelancer course is here

Seth Godin - Tue 21st Apr 2015 19:04
Each of us gets to choose the sort of freelance work we will do. This is a profound freedom, and one that we often ignore, wasting the opportunity. To provoke you to take advantage of this moment, my new course...         Seth Godin
Categories: thinktime

The difference between mass and banality

Seth Godin - Mon 20th Apr 2015 19:04
Something doesn't have to be trite and dreadful to be popular, but often, popular things get this way. In the 1980s, most of the cars made by General Motors were mediocre, unmemorable and poorly designed. They were also quite popular....         Seth Godin
Categories: thinktime

Pages

Subscribe to KatteKrab aggregator