You are here

thinktime

Chris Samuel: ARM v8 (64-bit) developer boxes

Planet Linux Australia - Thu 08th Jan 2015 23:01

Looks like things are moving along in the world of 64-bit ARM, systems aimed at early adopting developers are now around. For instance APM have their X-C1 Development Kit Plus which has 8 x 2.4GHz ARMv8 cores, 16GB RAM, 500GB HDD, 1x10gigE, 3x1gigE for ~US$2,500 (or a steep discount if you qualify as a developer). Oh, and it ships with Linux by default of course.

Found via a blog post by Steve McIntyre about bringing up Debian Jessie on ARMv8 (it’ll be a release architecture for it) which has the interesting titbit that (before ARM had their Juno developer boxes):

Then Chen Baozi and the folks running the Tianhe-2 supercomputer project in Guangzhou, China contacted us to offer access to some arm64 hardware

So it looks like (I presume) NUDT are paying it some attention & building/acquiring their own ARMv8 systems.

This item originally posted here:



ARM v8 (64-bit) developer boxes

Categories: thinktime

Andrew Pollock: [life] Day 344: Lego Discovery Centre, shopping in the city

Planet Linux Australia - Thu 08th Jan 2015 22:01

We had a really nice, busy today, much more so than I'd envisaged when we set off in the morning.

Zoe woke up at 2am and ended up in bed with me. I forgot to open her bedroom door when I went to bed, so I have no idea if that was a contributing factor or not. Her room was 26°C, so she may have been too hot. She then proceeded to have a pretty decent sleep in in my bed and not wake up until around 7am.

The plan today had been to check out the Lego Discovery Centre. It's been something I've wanted to take Zoe to for some time now, and I finally got around to booking in for a 45 minute session at 10am.

We made a pretty quick departure after breakfast, and caught the bus in, and arrived with plenty of time up our sleeves. Zoe didn't have a particularly good breakfast, and was hungry, so we hunted around for a croissant nearby.

Zoe was initially apprehensive about me leaving her there (it was a parent-less activity), but once we browsed the store before it started, she quickly became excited.

I went for a bit of a wander through Southbank and ended up in a deck chair by the river watching the world go by for half an hour. It was nice.

I went back to collect Zoe, and found her playing with a little Duplo-style remote controlled car that she'd built, and having a ball. It turned out that there were three different 45 minute sessions, all back to back. They had capacity in the next two sessions, and Zoe was keen, so I figured she could do all three. I just wish I'd remembered to bring a book. I ended up wandering over to the art gallery to amuse myself.

I came back a bit before 12:45pm to pick her up. I managed to stay out of sight for a while and observe her without her seeing me. All the kids were playing happily with a massive amount of Lego. She definitely looked like she had a good time. For a total of $36, it definitely seemed worth it. Apparently they run the sessions every school holidays, and change the theme every time. The >10 year olds were doing full on robotics with Mindstorms, which seemed very cool. I'm really excited that Zoe seems into Lego. I'm looking forward to doing lots of it with her as she gets older.

We grabbed some lunch from a convenience store next door, and then walked over to Southbank. I wanted to do a spot of shopping in the city, and for something different, I thought we could take one of the bicycle taxis over to the city. Zoe thought that was pretty cool, and it was nice to not be the one pedalling her around for a change.

We did a spot of shopping in the Myer Centre, before heading back to the bus and going home.

By the time we got home, it was time for me start dinner. Zoe watched a bit of TV, and then it was bed time. And I'd been thinking we'd be scrounging for something to do by 11:45am.

Categories: thinktime

Donna Benjamin: The Great D8 Chook Raffle

Planet Linux Australia - Thu 08th Jan 2015 21:01
Thursday, January 8, 2015 - 21:06The Drupal Association board approved a new initiative to help get Drupal 8 done.  It's called the D8 Accelerate fund. We also agreed to personally help do fundraising to support the program.  So I'm running a chook raffle.  For those of you who don't know what that is, Wikipedia gives a decent introduction.   https://www.drupal.org/governance/d8accelerate   The Drupal Association is working with the Drupal 8 branch maintainers to provide Drupal 8 Acceleration Grants. The goal is to fund work that will positively impact the release date. Drupal 8 has had over 2,400 contributors to date, which is more than any release so far. We hope that this initiative will encourage even more people to join the effort to get D8 done.   I'm about to launch a pozible campaign.  Stay tuned!    
Categories: thinktime

The paradox of rising expectations

Seth Godin - Thu 08th Jan 2015 21:01
Perhaps this is what your organization desires: To be more trusted, to have people willing to pay more, choose you more often, expect more... Of course, over time, good work will lead to higher expectations. And the paradox is that...         Seth Godin
Categories: thinktime

Beer and bread yeast-eating gut bacteria aid human health

Teaser:  University of Melbourne researchers collaborating with scientists from the UK, USA Canada and Belgium have unravelled the process healthy gut bacteria use to degrade complex carbohydrates in the wall of yeast cells contained in fermented foods.

This article originally appeared on the Melbourne Newsroom on January 8. View the original here.

Human gut bacteria that feast on the yeast contained in fermented foods like bread and beer provides clues to new treatments for people suffering from bowel diseases.

read more

Categories: thinktime

Andrew Pollock: [life] Day 343: Yet another doctor visit and The Workshops Rail Museum

Planet Linux Australia - Wed 07th Jan 2015 23:01

I started the day with a 7.5 km run, the longest distance I've managed to run lately. I'm slowly clawing my way back to 10 km.

After Sarah dropped Zoe off, I prepared a take away lunch, and we headed over to the doctor for another round of freezing the wart on her hand. She's getting really good about it now. This is one persistent wart though.

I'd made plans with Mel to go to The Workshops Rail Museum with Matthew and his brother and sister. Matthew had wanted to ride in our car, so after the doctor, I swung by Mel's place to pick him up.

We had an uneventful drive out there, and it was lunchtime by the time we arrived, so we had lunch first.

Matthew's older brother brought a friend with him, so we had five kids in total, in three different age brackets, so it was somewhat challenging keeping them all together and interested. Zoe was used to getting to go where she wanted, when she wanted, so had to learn to compromise a bit.

She was dying to get to the Nipper's Railway section and also the dining car play area and do a heap of role playing, so once we finally made it over there, she was in her element. Matthew played well with her as well.

It turned out to be a great day for going, because it was grey and drizzly outside all day.

Matthew wanted to come back to our place for a bit of a play afterwards, so we drove directly home. Both kids fell asleep on the way home, so to stretch their naps out a bit, I swung by the Valley to clear my PO box.

By the time we got home, there was less than an hour before Mel was going to pick up Matthew, and they mostly just watched a bit of TV. I used the down time to prep dinner.

After Matthew left and we had dinner, we went for a walk around the block to pick up some fruit from the Hawthorne Garage and kill some time before bedtime.

It was a nice, if somewhat tiring, day.

Categories: thinktime

Michael Still: A quick walk to William Farrer's grave

Planet Linux Australia - Wed 07th Jan 2015 21:01
This was a Canberra Bushwalking Club walk lead by John Evans. Not very long, but I would never have found this site without John's leadership, so much appreciated.



           



Tags for this post: blog pictures 20150107-william_farrers_grave photo canberra tuggeranong bushwalk historical grave

Related posts: A walk around Mount Stranger; Urambi Trig; Walk up Tuggeranong Hill; A quick walk to Tuggeranong Trig; Wanniassa Trig; Two more weeks to go



Comment
Categories: thinktime

Logo vs. Brand

Seth Godin - Wed 07th Jan 2015 20:01
Spend 10,000 times as much time and money on your brand as you spend on your logo. Your logo is a referent, a symbol, a reminder of your brand. But your brand is a story, a set of emotions and...         Seth Godin
Categories: thinktime

Clinton Roy: clintonroy

Planet Linux Australia - Wed 07th Jan 2015 20:01

Walked to work.

Managed to finally start the Learning to Learn course! I’ve now done all the week one videos and quizzes, which I’m quite happy with. Unfortunately the first piece of assessment is due half way through LCA which is going to be..difficult.



Filed under: diary
Categories: thinktime

Prestigious US Bioengineering award to Professor Graeme Clark for Cochlear implant

Teaser:  Professor Graeme Clark AC from the University of Melbourne is the first Australian to receive the US Russ Prize for an outstanding achievement in bioengineering innovation that is in widespread use to improve health and well-being: the cochlear implant.

This article originally appeared on the Melbourne Newsroom on January 7. View the original here.

Professor Graeme Clark AC from the University of Melbourne is the first Australian to receive the US Russ Prize for an outstanding achievement in bioengineering innovation that is in widespread use to improve health and well-being: the cochlear implant.

read more

Categories: thinktime

Clinton Roy: clintonroy

Planet Linux Australia - Wed 07th Jan 2015 12:01

Work.

Finally Mitre Ten was open when I was going past, picked up some lumber so I had something to mount the tool rack to.

Caught up with a friend who had spent Christmas and new years down in Melbourne.

Spent most of the night mounting the took rack, it took much longer than it should have. I need to reorganise one of the bookshelves, and start using it as a storage rack I think.



Filed under: diary
Categories: thinktime

Healthier kids: Insights from twin research

Teaser:  Twin researchers gathered in Melbourne during December to share ways in which research with twins can advance science.

This article was originally published in The Age on January 7. View the article here.

Twin researchers gathered in Melbourne during December to share ways in which research with twins can advance science. By Lynette Walker.

read more

Categories: thinktime

Nanoscale tech for better drug delivery

Teaser:  Researchers will soon be able to revolutionise drug delivery by looking at it at the nanoscale.

This article was originally published in The Age on January 7. View the article here.

Ben Hibbs explains how researchers will be able to revolutionise drug delivery by looking at it at the nanoscale.

read more

Categories: thinktime

The Core Model: Designing Inside Out for Better Results

a list apart - Wed 07th Jan 2015 02:01

If you’ve worked on a website design with a large team or client, chances are good you’ve spent some time debating (arguing?) with each other about what the homepage should look like, or which department gets to be in the top-level navigation—perhaps forgetting that many of the site’s visitors might never even see the homepage if they land there via search.

Nobody comes to your website just to look at your homepage or navigate your information architecture. People come because they want to get something done.

All too often, we blame the client for falling short on user experience. They don’t get that the important thing is that the information architecture is easy to understand—something you will never achieve if every single department gets to have their own button on the homepage.

It’s about time we take more of that blame ourselves. Usually, no matter how much user research we do, or how meticulously we’ve treated the digital strategy, we start out in our interactions with clients by mapping the information architecture or sketching homepages. It’s no wonder clients believe these are the pillars of the entire website, if these are the first things we show them. In fact, very few users actually meet their goals right on the homepage of any given website, so it follows that very few organizations will reach their own objectives—much less their users’—by focusing only on the homepage.

Long before “mobile first” or “content-driven design” were even buzzwords, information architect Are Halland tried to solve this conundrum by introducing the core model, which he presented at IA Summit 2007. The presentation is still highly enjoyable and relevant, even seven years later. In short, websites must be designed from the inside out, with primary focus on the core tasks its users need to accomplish.

When we used the core model technique at Netlife Research to begin a mobile-first, content-driven website redesign with the Norwegian Cancer Society (NCS), we spent less time quibbling over the homepage contents, and more time trying to figure out how we could actually help the users and the NCS get what they needed out of the website—with great results.

The core model ensures that we’re thinking about user needs all the way through the website design process, thinking holistically about goals instead of hierarchically; instead of demanding “Where do you belong on the NCS website?” of our visitors, the core model prompts us to ask, more generously, “How can the NCS help you?”

A different starting point

Using the core model, we start the design process by mapping out all the content we have in order to find the pages with a clear overlap between objectives and user tasks.

To use the core model, you need:

  • Business objectives: Prioritized, measurable objectives and sub-objectives. What does the organization want to achieve?
  • User tasks: Actual, researched, prioritized user tasks. What is it that people want to get done? (We usually conduct top task surveys to identify the user tasks, which is a great tool if you want to align the organization.)

A good review of a website’s existing content can turn up some dusty corners that need clearing out. Typically, a website might have a lot of content that doesn’t help users meet their goals—such as press release archives and lengthy vision statements. A great deal of this content can usually be removed, simplified, or merged in some way.

When you have set aside the nonessential content, you are left with cores. These are pages or workflows whose content fulfills a clear overlap between business objectives and user tasks.

An example from the NCS is their page dedicated to information about lung cancer. Our user research identified a huge need for qualified and authoritative information on the many forms of cancer—and seeing that one of the objectives for the NCS is to educate Norwegians about cancer, this is a clear match of the users’ needs with the organization’s larger objective.

Which pages meet both business goals and user needs?

But what happens with pages like “Donate”? Our research showed that users did not typically search the site for information related to fundraising, but being able to receive donations online is essential if the NCS is going to raise more money for cancer research. This is where the core model truly shines: if you create good cores, you’ll also be able to create good pathways to other, less-requested pages on your website, regardless of where they are placed in the information architecture. A core page should never be a blind alley.

Who is the core model for?

The core model is first and foremost a thinking tool. It helps the content strategist identify the most important pages on the site. It helps the UX designer identify which modules she needs on a page. It helps the graphic designer know which are the most important elements to emphasize in the design. It helps include clients or stakeholders who are less web-savvy in your project strategy. It helps the copywriters and editors leave silo thinking behind and create better content.

And to get all these different disciplines to start thinking collaboratively, we’ve found success with organizing team workshops that introduce core model thinking to the whole group.

By the end of the workshop, the group will have a common understanding of user needs, business goals, and how different pages should be connected. Additionally, you have worksheets where stakeholders have given you a prioritized list of what kind of content and modules they believe are the most important on the page they have worked on, when considering both user needs and business objectives.

With a prioritized list of what kind of content and modules needs to be on the most important pages, it’s a lot easier for the team to get to work, regardless of whether they are UX designers, graphic designers, or content strategists. We start by creating the core pages; the homepage is usually the last page we design. (How can you design the wrapping before you know what’s inside?)

How to do a core model workshop

The core model workshop outlined here is the first stage of a bigger design process, which might look a little different from one team to the next. But when you work with clients through these initial worksheets, the end result will be a team that’s excited to see the new website take shape—and is agreed on which content is truly important.

Doing a core workshop is easy and low-tech. All you need is:

  • Handouts summarizing researched user tasks and identified business objectives (see above)
  • Handouts with the core model (e.g., A3 paper size) (to fill out)
  • Markers and Post-Its
  • Room with a projector
  • 3-4 hours per workshop
  • 1-3 participants from your team (e.g., designers, UX, content, developers, and so forth)
  • 6-14 stakeholders from relevant fields or departments in the organization
  • Snacks and lots of coffee!
The core model handout.

When inviting stakeholders, try to involve people…

  • who will work with the content
  • with strong opinions about the website
  • who should be collaborating, but aren’t

To take part in a core workshop, there is no need for drawing skills, design skills, or tech-savviness. The most important thing is that people understand their own respective fields.

All workshop participants should work in pairs to fill out their worksheets. Between each step in the workshop, they’ll present their ideas to the other pairs, which will usually generate questions or new ideas that the other pairs can incorporate into their worksheets.

Participants from the NCS in one of the core workshops included people from the departments of cancer care, cancer prevention, cancer research, rights, and fundraising, as well as their in-house designer and web editor. 1. Identify your cores

The first thing you need to do is to identify your core pages by matching the business objectives and the user tasks. You can do this in the workshop or beforehand. Let’s use the example of our cancer type template, e.g. “lung cancer,” where we matched the following tasks and objectives.

Business objectives:

  • Helping patients and their friends and family
  • Increasing knowledge about cancer and prevention

User tasks:

  • Learn about different forms of cancer
  • Identify symptoms of cancer
  • Get tips for preventing cancer
  • Find information about treating cancer (therapies, adverse effects, risks, prognosis)
The worksheet has been filled out with the relevant business goals and user tasks. 2. Plan for inward paths

Instead of jumping into content creation and detailing that page, the next step is to map out inward paths. This is where we’ll look carefully at any user research findings to help inform decisions. How might people find this page? How did they get here?

This approach is a simple way to prompt your client to think about the page from a user’s perspective. In our example of the page about lung cancer, plausible inward paths are things like:

  • Googling lung cancer
  • Googling symptoms
  • Clicking a link on the homepage
  • Finding a link in a printed brochure
3. Determine core content

After identifying inward paths, we begin talking about the core content. What content do we need on this page for it to achieve the goals of both the organization and the users? What kind of modules or elements do we need?

In this task, the participants are using all the information they have on their worksheets: the user tasks, the business objectives, and the inward paths. In light of this information, what are the most important things that need to go on to that page—and in what order? Having a solid user research foundation at hand will make this process much simpler. In the case of the NCS workshop, the user research had identified cancer prevention as a top user concern, which made it clear that we needed to say something about prevention—sometimes even for cancer types that cannot be prevented.

4. Set forward paths

This last field is key to the core model’s success. After visitors have gotten the answers to their questions, where do we want to send them next? At this point you can allow yourself to think more about business goals in a general sense.

In the case of the lung cancer page, it could be forward paths like:

  • Contacting the cancer help line (so they don’t diagnose themselves)
  • How to prevent all forms of cancer, not just this specific type of cancer
  • Patient rights, if they are reading about treatment
  • Telling users about the political work and lobby work NCS does (e.g. trying to reduce treatment waiting times)

This has to be done in the context of user tasks. If someone is visiting the website in a fearful state, hoping to find solid information about melanoma, do we really want to conclude their journey with a flashy “Donate!” message? Not really—that would just be rude and insensitive, and is unlikely to encourage donations anyway. However, many users do look for general information on cancer research, and in this context, we can frame it more specifically: “If you think cancer research is important, you can help us by donating.” (And in fact, this more considerate approach might end up increasing donations, as it did for us at the NCS.)

A filled-out core worksheet. 5. Think mobile to prioritize

After all these steps, participants are usually excited. Their worksheets are full of ideas for content, modules, and all sorts of functionality.

The enthusiasm is great—that’s something we want!—but a worksheet full of discursive ideas is difficult to work with. Are all these things equally important?

That is why the final step in the workshop is to use mobile-first thinking to prioritize all the elements. We give the participants a new sheet and ask them: if you had just a small screen available, in which order would you place the elements you’ve identified throughout the workshop? They’ll also need to place those forward paths they’ve written down in the context of the main content.

At the final step, participants get new worksheets with narrow columns representing a mobile screen. How would they prioritize their content on such a small screen? A finished mobile core worksheet from a workshop with the Norwegian Association of the Blind and Partially Sighted. From core sketches to a finished website

We rarely use wireframes, and you won’t see a photoshop sketch or prototype with lorem ipsum. Why not?

A wireframe says a lot about where something is placed on a page, but it rarely says anything about why it was put there. Because of this, wireframes imply a lot more about what the design could look like than you really want it to in the early stages of design.

The core sketches from our workshop, on the other hand, can be put to good use by any web discipline, because it tells you which elements need to be on which pages, and—just as importantly—why they are there. There really isn’t any web-related discipline I know of whose members shouldn’t care about what needs to be on the page and why.

With interdisciplinary teams, you’re more likely to come up with more innovative ways of solving the user tasks: should it just be text? A video? A quiz? Something completely different?

At Netlife Research, we usually work in close teams of two to four people with a broad combination of skills, such as user research, UX design, graphic design, front end development, and content strategy. At this stage we’re also typically in close collaboration with a work group from the client.

Together, we are able to identify what kind of modules and information we need on the core pages—but the visual design is still flexible at this stage.

The next step is to begin content workshops with the organization, using core model thinking and writing in pairs

Ultimately, we delivered an HTML and CSS prototype with actual content, which (in this case) a subcontractor then developed for the NCS, along with a custom CMS to manage the website and make changes. We also designed several modules tailor-made for common forward paths, which their website editors can place as needed on various pages.

One such forward path module is a box advertising the cancer helpline. This helps the NCS achieve its goal of increasing the use of its services for learning about cancer, and it helps users get answers to their questions.

The cancer helpline box as used on the page about breast cancer. See our presentation from Confab Central 2014 for more details about this and other forward path modules. Results The message gets out to more people

After launch in September 2012, the number of unique visitors on the NCS website has steadily increased each year, despite the fact that the project had no specific activities aimed at search engine optimization. User-focused content goes a long way.

Unique visitors to the Norwegian Cancer Society’s website. Wondering about those dips in the graph each year? That’s the effect of the (nearly) endless Norwegian summer holidays.

As a welcome side effect of restructuring the website and the content around user tasks, the Norwegian Cancer Society is also now being used as a source by news media more frequently than before.

Forward paths have a huge impact

One example of a forward path is the aforementioned cancer helpline. If you compare the number of cancer helpline conversations in 2013 with the number of conversations the previous seven years, the number of conversations is up 40 percent. Usually, organizations will be looking to decrease the number of calls, but when you’re in the business of informing, it’s a good thing when users reach out. More people at risk of cancer picked up the phone, or entered a chat, or sent an email, and talked to an oncology nurse.

And despite this increase in conversations on the support lines, the oncology nurses tell us they are actually receiving more informed and sophisticated questions than they used to, because more people have already found the answers to their most basic questions on the website.

The total number of cancer helpline conversations, including email, chat, and phone calls. Fewer banners, but more donations

The previous NCS homepage had several banners and menu items pointing to different ways of supporting the NCS. Today, there’s just the “Support us” item in the menu, and the banners are gone.

Despite this, the effect on the digital fundraising has been astounding. Comparing numbers from 2011 (a whole year with the old website) with 2013 (a whole year with the new website):

  • The number of one-time donations has tripled (up 198%)
  • The number of regular donors registering each year has quadrupled (up 288%)
  • The total sum from regular donors each year has quintupled(!) (up 382%)

This is not only due to core model thinking, but also continuous improvement of the forms.

Thanks to continuous improvements, by August 2014 the annual income from regular donors registering online in 2014 had already surpassed the annual income from 2013. People will do anything on mobile

For several years, we have advocated the idea that people will do anything on mobile, if you just let them. Our work with the NCS is great testament to this way of thinking.

Users spend roughly the same amount of time on the page about lung cancer regardless of which device they are using; while tablet and desktop users spend on average 3 minutes and 48 seconds, smartphone users spend 3 minutes and 57 seconds.

In some forms, conversion rates are actually higher on mobile; in a recent membership campaign, the conversion rate was 7.3 percent on mobile whilst only 2.5 percent on desktop.

To become a member, we need the person’s name, address, and birthday. That didn’t stop people from signing up on a smartphone. From homepage first to homepage last

By devoting your time to the core pages first, you’ll avoid a number of turf battles about menu bar real estate, and enjoy the benefits of getting the whole team united behind the same essential parts of the website. You’ll prove to the team that you care about their content and their users (and, sure, maybe convince them to care a little more about their users, too)—and the end result is a website that knows exactly what it’s about. Next time you’re faced with a compromise-riddled situation where you’re designing a website by committee, give the core model a shot. In my work, it’s been a great way to get down to business and stay on positive terms with the whole team.

Categories: thinktime

From Empathy to Advocacy

a list apart - Wed 07th Jan 2015 02:01

For the past several years, I’ve been privileged to work with a number of local advocacy organizations in my community. Doing so has made me keenly aware of the crucial role that advocates play. They operate on scales both large and small—from working with lawmakers to shape public policy, to helping a single parent fill out the paperwork to find child care that enables them to keep a job. But advocates have a few things in common:

  • They have a cause: in whatever context they work, there’s an existing pattern they’re not satisfied with.
  • They intervene when they perceive an imbalance of power.
  • They act as translators between “outsiders” and “insiders.”
  • They persuade others to care about their cause, using stories and hard data.

As people who make websites, we may find that thinking of ourselves as advocates for our users, rather than creators of a product or providers of a service, transforms the way we work.

The UX industry devotes considerable attention to the concept of empathy, and rightly so, as understanding our users and their needs is foundational to delivering quality experiences. Still, empathy and insights alone do not automatically create those experiences. What matters is how cultivating empathy alters our decisions and behaviors. My ability to understand the needs of another person does nothing to meet those needs until I take conscious action—becoming not just a listener, but an advocate.

Most of us probably feel that we practice user-centered design, but the work of web development doesn’t happen in a vacuum. It frequently means inheriting a legacy of past decisions and considering a multitude of business pressures. It’s messy, and users often suffer as a result. Advocacy is what we do to make it better. It’s how we navigate the complex world of business relationships and persuade others to care about the same principles we do. And by making the language of advocacy a part of our daily conversation, we’re constantly seeking to build a culture of respect for users, rather than waiting for a project that provides a convenient framework.

Imbalances of power

Advocacy can take many forms, but one way to think of it is that when any significant power imbalance exists between two parties, the risk of an injustice occurring is high. The greater the difference, the greater the risk.

A person can feel powerless for many reasons. Being a child is an obvious example, as are differences in social or economic status. I can be privileged in one context and powerless in another. We all feel powerless whenever someone else makes decisions for us. When I go to the doctor, I’m signing up for whatever procedures are ordered, often without knowing what the cost will be. When I file my taxes, the government decides whether I’ve gotten them right.

In the face of a large, complex system, someone who feels powerless needs an advocate, usually one who works within the system, to gain a hearing. Otherwise, it’s too easy for the privileged party to make every decision based on its own interests and preferences, even if unintentionally.

That’s why governments and large organizations sometimes employ ombudsmen, who operate outside the normal chain of command and elevate complaints that might otherwise go ignored. Other advocates wear the hat informally, simply as people who care.

In developing web applications, I might be tempted to think that ultimate power always lies in the user’s hands. After all, I assume, she controls the browser and can always take her business elsewhere. But in many cases, this is more of an abstract idea than a true lever of influence.

Will she really leave the social network that all her friends use? And if she did, would I, as a developer, ever know the reason? There are many applications that people are forced to use without a good alternative, like those provided by an employer. In many cases, the business offering a website holds much of the power in its interactions with users.

Even when choices do exist, users are still not the ones making design decisions—they can only react to decisions already made by developers and others, and hope that someone is listening. Voting for change by leaving a website is unlikely to mean much because it’s a passive statement.

Experiences can also be hard to quantify. For example, when language barriers are creating a UX problem, it’s hard to measure the resulting frustration or its cost in goodwill.

In a culture of advocacy, the conversation starts from an underlying value of respect for the user, rather than the balance sheet or even an abstract idea like “best practices.” We can’t always say that adding translation, or making our writing more accessible, will improve our customer satisfaction metric by a given percentage. But we can say, “We ought to be an organization that recognizes the diversity of our customers and respects their time. Let’s demonstrate that by…”

The most effective advocate is likely one who has direct experience in the user’s shoes. The bilingual team member is most likely to be sensitive to language barriers. This isn’t always the case—anyone can champion a cause—but it does mean that as developers, we need to pay extra attention to the people within our organizations who have such experience. We can encourage them to act as advocates in those areas, and to remind us of priorities that we might otherwise overlook.

We must put structures in place to give such advocates the power to be heard, though. Ombudsmen hold positional authority that, while not absolute, isn’t easily overruled. In the design or development process, that structure may be formalized as a specific role within the development team (“Eve is our user advocate on this project”), or an expression of shared values that says, “If anyone feels that a decision doesn’t demonstrate respect for our users, we stop what we’re doing and tackle the issue.”

Translating between insiders and outsiders

An advocate also serves as a translator, helping outsiders to navigate a complex system and helping insiders to understand an outsider’s position. Doing this effectively can be challenging and involves a mix of both technical and soft skills.

In web development, interviews and testing will, of course, yield insights into users’ needs. But users can’t be expected to articulate those needs in a way that makes sense to developers. A good advocate will listen, draw inferences, and re-interpret needs in ways that lead to practical application at a technical level, so they can negotiate effectively with developers or other business stakeholders.

An advocate’s analytical skills, and a level of impartiality, can be just as crucial. Users may ask for the moon. They may describe symptoms instead of the fundamental problem, or jump to conclusions about what the problem is. For example, when a user complains that “the system is slow,” it might mean that response time is poor, or that the system is confusing and accomplishing a task takes too long. The user might feel strongly that the solution is adding a search system, when in reality, a few IA improvements would be effective.

An advocate’s role is to distill core problems from the raw input of feelings, reactions, and data, and, just as a lawyer might, recognize the moments when a user asks for what is not in their best interest. What people like is not always what’s most effective (although this is not an excuse to simply replace their subjective preferences with our own).

Collective interests and individual stories

“Users” are a faceless and voiceless mass. Alice and Bob, on the other hand, are people. An advocate’s third task is to make the impersonal personal by articulating the interests of a group and helping decision-makers to see them as people rather than numbers.

One of the most persuasive presentations I’ve ever attended came from a Boys & Girls Club spokesperson describing their work. It was persuasive because she did a masterful job of combining big-picture data about the effectiveness of certain programs with specific stories of children she’d worked with. It’s one thing to advocate for early childhood programs based on economic data; it’s quite another to show how a particular child’s life was changed through a development program. Collective data represented through individual stories become compelling.

It’s easy enough to write off the experience of a group of people when we describe them with a label—“IE7 users,” for example. It’s even easier when the label describes a minority of our audience. But if I think about my friend Alice, who works in a healthcare setting where computers are difficult to upgrade because of regulatory concerns, it’s much harder to explain why she deserves to be marginalized.

Stories are persuasive because they humanize the subject matter and help us connect emotionally. That’s what makes personas a valuable tool. But when we encounter resistance, they’re also easy to dismiss as anecdotal unless they’re supported by harder data. If I want to make the point that we shouldn’t ignore the experience of IE7 users, I need to know how many of those users I have. The developer who really doesn’t want to deal with IE7 might say that they’re “less than 5% of the audience”—a purely quantitative argument that sounds reasonable. But perhaps that 5% represents thousands of individual people. When I tell Alice’s story, explaining that she’s powerless to change the browser her employer provides, and point out that we have thousands more customers just like her, the argument carries more weight.

Advocacy in practice

Design decisions always require that we balance competing interests, but as a user advocate, I believe that it’s the user’s interest that should generally carry the most weight. Likely, not everyone in a business will agree, at least not all the time. To build credibility in speaking on behalf of users, consider the following practical guidelines.

Affirm the legitimacy of other interests

Rarely is a business openly hostile to users, of course. But we all bring to the discussion a set of preferences and biases that stem from our experience and expertise. Executives have an interest in the financial performance of the organization. Security professionals have an interest in protecting systems from intrusion. Developers want maintainable code and database integrity. Marketers want a strong brand image.

These are perfectly valid goals, but each of them can easily find itself in tension with what the users of a web application care about. Users probably value things like a good price, a clear interface, and software that lets them complete a task quickly.

An advocate exercises empathy not only on behalf of the user, but also on behalf of the business. To be heard, I need to first understand and respect what decision-makers value. Over the years, I’ve had many discussions with security professionals about the inherent tradeoffs in balancing usability with security—the most secure system is always the least usable. The UX person’s “clear feedback” in a failed login interaction is the security person’s “information leakage,” for example. To strike that balance well, I have to respect the need for security and the very real threats that face modern web applications. If ease of use were my only priority, I could easily put an application at risk.

Frame the discussion in meaningful terms

Respecting the goals of business stakeholders enables us to make a case for user-first decisions in ways that command attention. UX considerations can often be framed as risk management, brand management, or other business values.

For example, imagine that a website is offering a survey to users to get background research for a potential new product. The data will drive critical decisions, so everyone believes it’s a user-first project. But the survey takes over the user’s screen about 10 seconds after page load, so it’s frustrating. The conversation could easily go like this:

UX person: We’ve got to do something about this survey. It’s driving people crazy.
Research person: We really need the data. And people want to have a voice in our design process, right?
UX person: We could make it less intrusive, though. It doesn’t have to take over the whole screen.
Research person: Then they won’t notice it, and we won’t get enough data. We have to make it obvious.
UX person: Our users are annoyed.
Research person: It’s worth it for a little while. They’ll benefit in the long run.

A more effective approach might be:

UX person: Can I talk to you about the new survey? I’m really glad that kind of research is going into the new product.
Research person: Yeah, it’s exciting.
UX person: We’re hearing some complaints about the timing, and the way it takes over people’s screens. Could we adjust that? I’m afraid that frustration could really bias your data.
Research person: Oh, I hadn’t thought about that. We really need it to be obvious, though. If we don’t get enough people clicking through, the whole thing will be useless.
UX person: Definitely. Can I show you a couple of design ideas?

To someone who lives and breathes UX, user frustration might be a sufficient reason to make a design change on its own. But to the analyst who needs that survey data, it might seem like an acceptable tradeoff. Articulating the risk that frustration poses to the business, like biasing the results of a survey, can make the argument far more persuasive. And proposing a workable alternative is always more effective than simply highlighting a problem.

Be pragmatic

If we recognize that other business interests have merit, we have to be prepared to lose UX arguments at times. A business is not a person, and the cold logic of operational calculus may determine that the cost of making a change to improve UX outweighs the benefit. Advocates learn to choose their battles and press for change where it matters the most.

In the case of language barriers, as much as I may like to see full translation of a website or application, it’s likely an expensive proposition many businesses won’t be prepared to accept. But perhaps there are a few key interactions where it could be especially helpful, and we can advocate for a limited expense there. And if that doesn’t fly, we can fall back to simplifying the writing as much as possible to make it accessible to non-native speakers. At each step, even though the solution isn’t ideal, it keeps the issue visible, and keeps people thinking about the needs of that group of users.

While a business may be an impersonal entity, it is also composed of people who, for better or worse, share a common culture. As web professionals who continually speak in the language of advocacy, we can cultivate an environment in which users are respected, even when we lose out on individual decisions.

Find a cause and start somewhere

The advocates that I’ve worked with recognize their limits. They are passionate about a cause, but they know they can’t change the world all at once. They tackle manageable problems while always watching for new opportunities. Start by finding the single UX issue that you care most about, and look for small ways to improve it and persuade others to care. It could be one of the big issues of our day, like front-end performance or the mobile experience, or something very specific, like the experience of a handful of internal users with a particular administrative interface (which are easy to neglect—and improving them is a terrific way to get buy-in for future efforts).

At the same time, just as solving major social problems depends on public policy, our industry can only improve when we advocate publicly—so it’s important to write, speak, and share our experiences, particularly those that may be unique or underrepresented.

But whether the scale is large or small, the key is to encourage, in ourselves and in others, a healthy level of dissatisfaction with the status quo and take daily actions that directly improve the experience of our users.

Categories: thinktime

Most people wait (for most people)

Seth Godin - Tue 06th Jan 2015 20:01
Most people can't go first, most people don't want to go last. Most people do what most people do. That's obvious. A tautology. The bell shape of product adoption is almost directly the opposite of what we'd guess based on...         Seth Godin
Categories: thinktime

Unveiling how the children’s tummy bug, rotavirus, causes infection

Teaser:  Researchers from the University of Melbourne and Griffith University’s Institute for Glycomics have significantly advanced understanding of a virus that kills up to half a million children each year.

This article originally appeared on the Melbourne Newsroom on January 6. View the original here.

Researchers from the University of Melbourne and Griffith University’s Institute for Glycomics have significantly advanced understanding of a virus that kills up to half a million children each year.

read more

Categories: thinktime

BlueHackers: BlueHackers at LCA 2015 (Auckland NZ)

Planet Linux Australia - Tue 06th Jan 2015 13:01

BlueHackers will have a presence at Linux.conf.au (this year in Auckland NZ, 12-16 Jan 2015), the awesome John Dalton is organising the BoF (Birds-of-a-Feather) session one evening, and he’ll also have a stash the little BlueHackers stickers that you can put on your laptop to show your support and understanding for mental health. Some stickers may also be available at the LCA registration desk.

Have an awesome time there – unfortunately I can’t make it this year.

Categories: thinktime

BlueHackers: Depression Doesn’t Make You Sad All the Time | Meloukhia.net

Planet Linux Australia - Tue 06th Jan 2015 12:01
One of the most popular, enduring, and irritating myths about depression is that it means depressed people are sad all the time — and that by extension, people who are happy can’t be experiencing depression, even if they say they are. Read S.E.Smith’s full article: http://meloukhia.net/2014/12/depression_doesnt_make_you_sad_all_the_time
Categories: thinktime

Tridge on UAVs: Embedded Linux Conference - submit a paper!

Planet Linux Australia - Tue 06th Jan 2015 12:01

There are only a few days left to submit a paper for the Embedded Linux Conference in San Jose in March. This is the first conference with a Drone specific track organised under DroneCode.org.

Lorenz Meier and myself will both be presenting at the conference, and it will be a great opportunity for technical discussions within the DroneCode community. I'm really looking forward to meeting other members of the ArduPilot and DroneCode community and hearing about their work.

Call for Papers

The CE Workgroup of the Linux Foundation would like to invite you to make a presentation at our upcoming Embedded Linux Conference.  The conference will be held March 23 - 25 in San Jose, California.  The theme for this year is "Drones, Things and Automobiles", and we're excited to discuss some new areas where embedded Linux is really taking

off! (pun intended)



For general information about the conference, See http://events.linuxfoundation.org/events/embedded-linux-conference/



For information about the call for participation, see http://events.linuxfoundation.org/events/embedded-linux-conference/cfp



Please note the guidelines on the CFP page.  It's usually pretty obvious when we're reviewing the abstracts, as a program committee, who has read the guidelines and who hasn't.



ELC is the premier vendor-neutral technical conference for embedded Linux developers. The conference is open to the public.



Guidelines



Presentations should be of a technical nature, covering topics related to use of Linux in embedded systems.  Topics related to consumer electronics are particularly encouraged, but any proposals about Linux that are of general relevance to most embedded developers are welcome.



Presentations that are commercial advertisements or sales pitches are not appropriate for this conference.



Especially encouraged this year are talks in the following areas:

  • Linux in Automotive
  • Drones and Robots
  • Linux in the Internet of Things



And we'd also love to hear your proposals in the following topic areas as well:



  • Audio, Video, Streaming Media, and Graphics
  • Security
  • System size, Boot speed, and Real-Time Performance
  • Flash Memory Devices and Filesystems
  • Build Systems, Embedded Distributions, and Development tools
  • Mobile Phones, DVRs, TVs, Cameras, etc.
  • Practical Experiences and War Stories
  • Standards



Most presentation slots will be 50 minutes long, including time for questions.



Tutorials, demos, and Birds-of-a-Feather sessions may also be proposed.



The deadline for submissions is midnight January 9, 2015 PDT.



To repeat, for additional info and details for making a proposal, see http://events.linuxfoundation.org/events/embedded-linux-conference/cfp



Categories: thinktime

Pages

Subscribe to KatteKrab aggregator