You are here

thinktime

Simon Lyall: Linux.conf.au 2017 – Thursday – Session 2

Planet Linux Australia - Thu 19th Jan 2017 15:01

Content as a driver of change: then and now – Lana Brindley

  • Humans have always told stories
  • Cave Drawings
    • Australian Indigenous art is the oldest continuous art in the world
    • Stories of extinct mega-fauna
    • Stories of morals but sometimes also funny
  • Early Written Manuals
    • We remember the Eureka
  • Religious Leaders
    • Gutenburg
    • Bible was only redistributed book, restricted to clergy
  • Fairy Tales
    • Charles Perrault versions.
    • Brother Grim
    • Cautionary tales for adults
    • Very gruesome in the originals and many versions
    • Easiest and entertaining way for illiterate people to share moral stories
  • Master and Apprentice
    • Cheap Labour and Learn a Trade
  • Journals and Letters
    • In the early 19th century letter writing started happoning
    • Recipe Books

 

  • Recently
  • Paper Manuals
    • Traditionally the proper method for technical docs
  • Whitepapers
    • Printed version will probably go away
    • Digital form may live on
  • Training Courses
    • Face to face training has it’s benifits
    • Online is where techical stuff is moving
  • Online Books
    • Online version of a printed book
    • Designed to be read from beginning to end, TOC, glossary, etc

 

  • Today
  • MOOCS
    • Quite common
  • Data Typing (DITA)
    • Break down the content into logical pices
    • Store in a database
    • Mix on the fly
    • Doing this sort of the since 1960s and 1970s
  • Single Sourcing
    • Walked away from old idea of telling a story
    • Look at how people consumed and learnt difficult concepts
    • Deliver the same content many ways (beginner user, advanced, reference)
    • Chunks of information we can deliver however we like
  • User-Side Content Curation
    • Organised like a wikipedia article
    • Imagine a side listing lots of cars for sale, the filters curate the content
  • What comes next?
    • Large datasets and let people filter
    • Power going from producers to consumers
    • Consumers want to filter themselves, not leave the producers to do this
  • References and further reading for talk

I am your user. Why do you hate me? Donna Benjamin

  • Free and open source software suffers from poor usability
  • We’ve struggled with open source software, heard devs talk about users with contempt
  • We define users by what they can’t do
  • How do I hate thee let I count the ways
    • Why were we being made to feel stupid when we used free software
    • Software is “made by me for me”, just for brainiac me
    • Lots of stories about stupid users. Should we be calling our users stupid?
    • We often talk/draw about users as faceless icons
    • Take pride in having prickly attitudes
  • Users
    • Whiney, entitled and demanding
    • We wouldn’t want some of them as friends
    • Not talk about those sort of users
  • Lets Chat about chat
    • Slack – used by OS projects, not the freest, propritory
    • Better in many ways less friction, in many ways
  • Steep Learning curves
    • How long to get to the level of (a) Stop hating it? (b) Are Kicking ass
    • How do we get people over that level as quickly as possible
    • They don’t want to be badass at using your tool. They want you to be badass at what using your tool allows them to do
    • Badass: Making Users Awesome – Kathy Sierra
  • Perfect is the enemy of the good
  • Understand who your users are; see them as people like your friends and colleagues; not faceless icons

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Thursday – Session 1

Planet Linux Australia - Thu 19th Jan 2017 13:01

The Vulkan Graphics API, what it means for Linux – David Airlie

  • What is Vulkan
    • Not OpenGL++
    • From Scratch, Low Level, Open Graphics API
    • Stack
      • Loader (Mostly just picks the driver)
      • Layers (sometimes optional) – Seperate from the drivers.
        • Validation
        • Application Bug fixing
        • Tracing
        • Default GPU selection
      • Drivers (ICDs)
    • Open Source test Suite. ( “throw it over the wall Open Source”)
  • Why a new 3D API
    • OpenGL is old, from 1992
    • OpenGL Design based on 1992 hardware model
    • State machine has grown a lot as hardware has changed
    • Lots of stuff in it that nobody uses anymore
    • Some ideas were not so good in retrospec
      • Single context makes multi-threading hard
      • Sharing context is not reliable
      • Orientated around windows, off-screen rendering is a bolt-on
      • GPU hardware has converged to just 3-5 vendors with similar hardware. Not as much need to hid things
    •  Vulkan moves a lot of stuff up to the application (or more likely the OS graphics layer like Unity)
    • Vulkan gives applications access to the queues if they want them.
    • Shading Language – SPIR-V
      • Binary formatted, seperate from Vulkan, also used by OpenGL
      • Write Shaders HSL or GLSL and they get converted to SPIR-V
    • Driver Development
      • Almost all Error checking needed since done on the validation layer
      • Simpler to explicitly build command stream and then submit
    • Linux Support
      • Closed source Drivers
        • Nvidia
        • AMD (amdgpu-pro) – promised open source “real soon now … a year ago”
      • Open Source
        • Intel Linux (anv) –
          • on release day. 3.5 people over 8 months
          • SPIR -> NIR
          • Vulkan X11/Wayland WSI
          • anv Vulkan <– Core driver, not sharable
          • NIR -> i965 gen
          • ISL Library (image layout/tiling)
        • radv (for AMD GPUs)
          • Dave has been working on it since early July 2016 with one other guy
          • End of September Doom worked.
          • One Benchmark faster than AMD Driver
          • Valve hired someone to work on the driver.
          • Similar model to Intel anv driver.
          • Works on the few Vulkan games, working on SteamVR

 

Building reliable Ceph clusters – Lars Marowsky-Brée

  • Ceph
    • Storage Project
    • Multiple front ends (S3, Swift, Block IO, iSCSI, CephFS)
    • Built on RADOS data store
    • Software Defined Storage
      • Commodity servers + ceph + OS + Mngt (eg Open Attic)
      • Makes sense at 4+ servers with 10 drives each
      • metadata servce
      • CRUSH algorithm to speread out the data, no centralised table (client goes directly to data)
    • Access Methods
      • Use only what you need
      • RADOS Block devices   <– most stable
      • S3 (or Swift) via RadosGW  <– Mature
      • CephFS  <— New and pretty stable , avoid stuff non meta-data intensive
    • Introducing Dependability
      • Availability
      • Reliability
        • Duribility
      • Safety
      • Maintainability
    • Most outages are caused by Humans
    • At Scale everything fails
      • The Distributed systems are still vulnerable to correlated failures (eg same batch of hard drives)
      • Advantages of Heterogeneity – Everything is broken different
      • Homogeneity is non-sustainable
    • Failure is inevitable; suffering is optional
      • Prepare for downtime
      • Test if system meets your SLA when under load and when degraded and during recovery
    • How much available do you need?
      • An extra nine will double your price
  • A Bag full of suggestions
    • Embrace diversity
      • Auto recovery requires a >50% majority
      • 3 suppliers?
      • Mix arch and stuff between racks/pods and geography
      • Maybe you just go with manually added recovery
    • Hardware Choices
      • Vendors have reference archetectures
      • Hard to get vendors to mix, they don’t like that and fewer docs.
      • Hardware certification reduces the risk
      • Small variations can have huge impact
        • Customer bought network card and switch one up from the ref architecture. 6 months of problems till firmware bug fixed.
    • How many monitors do I need?
      • Not performance critcal
      • 3 is usually enough as long as well distributed
      • Big envs maybe 5 or 7
      • Don’t coverge (VMs) these with other types of nodes
    • Storage
      • Avoid Desktop Disks and SSDs
    • Storage Node sizing
      • A single node should not be more than 10% of your capacity
      • You need space capacity at least as big as a single node (to recover after fail)
    • Durability
      • Erasure Encode more durabily and high percentage of disk used
      • But recovery a lot slower, high overhead, etc
      • Different strokes for different pools
    • Network cards, different types, cross connect, use last years cards
    • Gateways: tests okay under failure
    • Config drift: Use config mngt (puppet etc)
    • Monioring
      • Perf as system ages
      • SSD degradation
    • Updates
      • Latest software is always the best
      • Usually good to update
      • Can do rolling upgrades
      • But still test a little on a staging server first
      • Always test on your system
        • Don’t trust metrics from vendors
        • Test updates
        • test your processes
        • Use OS to avoid vendor lock in
    • Disaster will strike
      • Have backups and test them and recoveries
    • Avoid Complexity
      • Be aggressive in what you test
      • Be commiserative in what you deploy only what you need
    • Q: Minimum size?
    • A: Not if you can fit on a single server

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Thursday – Session 1

Planet Linux Australia - Thu 19th Jan 2017 13:01

The Vulkan Graphics API, what it means for Linux – David Airlie

  • What is Vulkan
    • Not OpenGL++
    • From Scratch, Low Level, Open Graphics API
    • Stack
      • Loader (Mostly just picks the driver)
      • Layers (sometimes optional) – Seperate from the drivers.
        • Validation
        • Application Bug fixing
        • Tracing
        • Default GPU selection
      • Drivers (ICDs)
    • Open Source test Suite. ( “throw it over the wall Open Source”)
  • Why a new 3D API
    • OpenGL is old, from 1992
    • OpenGL Design based on 1992 hardware model
    • State machine has grown a lot as hardware has changed
    • Lots of stuff in it that nobody uses anymore
    • Some ideas were not so good in retrospec
      • Single context makes multi-threading hard
      • Sharing context is not reliable
      • Orientated around windows, off-screen rendering is a bolt-on
      • GPU hardware has converged to just 3-5 vendors with similar hardware. Not as much need to hid things
    •  Vulkan moves a lot of stuff up to the application (or more likely the OS graphics layer like Unity)
    • Vulkan gives applications access to the queues if they want them.
    • Shading Language – SPIR-V
      • Binary formatted, seperate from Vulkan, also used by OpenGL
      • Write Shaders HSL or GLSL and they get converted to SPIR-V
    • Driver Development
      • Almost all Error checking needed since done on the validation layer
      • Simpler to explicitly build command stream and then submit
    • Linux Support
      • Closed source Drivers
        • Nvidia
        • AMD (amdgpu-pro) – promised open source “real soon now … a year ago”
      • Open Source
        • Intel Linux (anv) –
          • on release day. 3.5 people over 8 months
          • SPIR -> NIR
          • Vulkan X11/Wayland WSI
          • anv Vulkan <– Core driver, not sharable
          • NIR -> i965 gen
          • ISL Library (image layout/tiling)
        • radv (for AMD GPUs)
          • Dave has been working on it since early July 2016 with one other guy
          • End of September Doom worked.
          • One Benchmark faster than AMD Driver
          • Valve hired someone to work on the driver.
          • Similar model to Intel anv driver.
          • Works on the few Vulkan games, working on SteamVR

 

Building reliable Ceph clusters – Lars Marowsky-Brée

  • Ceph
    • Storage Project
    • Multiple front ends (S3, Swift, Block IO, iSCSI, CephFS)
    • Built on RADOS data store
    • Software Defined Storage
      • Commodity servers + ceph + OS + Mngt (eg Open Attic)
      • Makes sense at 4+ servers with 10 drives each
      • metadata servce
      • CRUSH algorithm to speread out the data, no centralised table (client goes directly to data)
    • Access Methods
      • Use only what you need
      • RADOS Block devices   <– most stable
      • S3 (or Swift) via RadosGW  <– Mature
      • CephFS  <— New and pretty stable , avoid stuff non meta-data intensive
    • Introducing Dependability
      • Availability
      • Reliability
        • Duribility
      • Safety
      • Maintainability
    • Most outages are caused by Humans
    • At Scale everything fails
      • The Distributed systems are still vulnerable to correlated failures (eg same batch of hard drives)
      • Advantages of Heterogeneity – Everything is broken different
      • Homogeneity is non-sustainable
    • Failure is inevitable; suffering is optional
      • Prepare for downtime
      • Test if system meets your SLA when under load and when degraded and during recovery
    • How much available do you need?
      • An extra nine will double your price
  • A Bag full of suggestions
    • Embrace diversity
      • Auto recovery requires a >50% majority
      • 3 suppliers?
      • Mix arch and stuff between racks/pods and geography
      • Maybe you just go with manually added recovery
    • Hardware Choices
      • Vendors have reference archetectures
      • Hard to get vendors to mix, they don’t like that and fewer docs.
      • Hardware certification reduces the risk
      • Small variations can have huge impact
        • Customer bought network card and switch one up from the ref architecture. 6 months of problems till firmware bug fixed.
    • How many monitors do I need?
      • Not performance critcal
      • 3 is usually enough as long as well distributed
      • Big envs maybe 5 or 7
      • Don’t coverge (VMs) these with other types of nodes
    • Storage
      • Avoid Desktop Disks and SSDs
    • Storage Node sizing
      • A single node should not be more than 10% of your capacity
      • You need space capacity at least as big as a single node (to recover after fail)
    • Durability
      • Erasure Encode more durabily and high percentage of disk used
      • But recovery a lot slower, high overhead, etc
      • Different strokes for different pools
    • Network cards, different types, cross connect, use last years cards
    • Gateways: tests okay under failure
    • Config drift: Use config mngt (puppet etc)
    • Monioring
      • Perf as system ages
      • SSD degradation
    • Updates
      • Latest software is always the best
      • Usually good to update
      • Can do rolling upgrades
      • But still test a little on a staging server first
      • Always test on your system
        • Don’t trust metrics from vendors
        • Test updates
        • test your processes
        • Use OS to avoid vendor lock in
    • Disaster will strike
      • Have backups and test them and recoveries
    • Avoid Complexity
      • Be aggressive in what you test
      • Be commiserative in what you deploy only what you need
    • Q: Minimum size?
    • A: Not if you can fit on a single server

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Thursday Keynote – Nadia Eghbal

Planet Linux Australia - Thu 19th Jan 2017 11:01

Consider the Maintainer

  • Is it alright to compromise or even deliberately ignore the happiness of maintainers so that we can enjoy free software?
  • Huge growth in usage and downloads of Open Source software
  • 2/3s of popular open source projects on github are maintained by one of two people
  • Why so few?
    • Style has changed, lots of smaller projects
    • Being a maintainer isn’t glamorous of fun most of the time
    • 1% are creating the content that 99% of people consume
  • “Rapid evolution [..] poses the risk of introducing errors faster than people can fix them”
  • Consumption scales for most thing, not for open source because it creates more work for the maintainer
  • “~80% of contributors on github don’t know how to solve a merge conflict”
  • People see themselves as users of OS software, not potential maintainers – examples of rants by users against maintainers and the software
  • “Need maintainers, not contributors”
  • “Helping people over their first pull request, not helping them triage issues”
  • Why are we not talking about this?
  • Lets take a trip back in History
    • Originally Stallman said Free software was about freedom, not popularity. eg “as is” disclaimer of warranty
    • Some people create software sometimes.
    • Debian Social Contract, 4 freedoms, etc places [OS / Free] software and users first, maintainers often not mentioned.
    • Orientated around the user not the producer
  • Four Freedoms of OS producers
    • Decide to participate
    • Say no to contributions or requests
    • Define the priorities and policies of the project
    • Step down or move on
  • Other Issues maintainers need help with
    • Community best practices
    • Project analytics
    • Tools and bots for maintainers (especially for human coordination)
    • Conveying support status ( for contributors, not just user support )
    • Finding funding
  • People have talked about this before, mostly they concentrated on a few big projects like Linux or Apache (and not much written since 2005)
    • Doesn’t reflect the ecosystem today, thousands of small projects, github, social media, etc
    • Open source today is not what open source was 20 years ago
  • Q&A
    • Q: What do you see as responsibly and potential for orgs like Github?
    • A: Joined github to help with this. Hopes that github can help with tools.
    • Q: How can we get metrics on real projects, no just plaything on github
    • A: People are using stars on github, which is useless. One idea is to look at dependencies. libraries.io is looking. Hope for better metrics.
    • Q: Is it all agile programmings fault?
    • A: Possibly, people this days are learning to code but average level is lower and they don’t know what is under the hood. Pretty good in general but. “Under the hood it is not just a hammer, it is a human being”
    • Q: Your background is in funding, how does transiticion work when a project or some people on it start getting money?
    • A: It is complicated, need some guidelines. Some projects have made it work well ( “jsmobile” I think she said ). Need best practice and to keep things transparent
    • Q: How to we get out to the public (even programmers/tech people at tech companies) what OS is really like these days?
    • A: Example of Rust. Maybe some outreach and general material
    • Q: Is Patreon or other crowd-funding a good way to fund projects?
    • A: Needs a good target, requires a huge following which is hard to people who are not good at marketing. Better for one-time vs recurring. Hard to decide exactly what money should be used for

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Thursday Keynote – Nadia Eghbal

Planet Linux Australia - Thu 19th Jan 2017 11:01

Consider the Maintainer

  • Is it alright to compromise or even deliberately ignore the happiness of maintainers so that we can enjoy free software?
  • Huge growth in usage and downloads of Open Source software
  • 2/3s of popular open source projects on github are maintained by one of two people
  • Why so few?
    • Style has changed, lots of smaller projects
    • Being a maintainer isn’t glamorous of fun most of the time
    • 1% are creating the content that 99% of people consume
  • “Rapid evolution [..] poses the risk of introducing errors faster than people can fix them”
  • Consumption scales for most thing, not for open source because it creates more work for the maintainer
  • “~80% of contributors on github don’t know how to solve a merge conflict”
  • People see themselves as users of OS software, not potential maintainers – examples of rants by users against maintainers and the software
  • “Need maintainers, not contributors”
  • “Helping people over their first pull request, not helping them triage issues”
  • Why are we not talking about this?
  • Lets take a trip back in History
    • Originally Stallman said Free software was about freedom, not popularity. eg “as is” disclaimer of warranty
    • Some people create software sometimes.
    • Debian Social Contract, 4 freedoms, etc places [OS / Free] software and users first, maintainers often not mentioned.
    • Orientated around the user not the producer
  • Four Freedoms of OS producers
    • Decide to participate
    • Say no to contributions or requests
    • Define the priorities and policies of the project
    • Step down or move on
  • Other Issues maintainers need help with
    • Community best practices
    • Project analytics
    • Tools and bots for maintainers (especially for human coordination)
    • Conveying support status ( for contributors, not just user support )
    • Finding funding
  • People have talked about this before, mostly they concentrated on a few big projects like Linux or Apache (and not much written since 2005)
    • Doesn’t reflect the ecosystem today, thousands of small projects, github, social media, etc
    • Open source today is not what open source was 20 years ago
  • Q&A
    • Q: What do you see as responsibly and potential for orgs like Github?
    • A: Joined github to help with this. Hopes that github can help with tools.
    • Q: How can we get metrics on real projects, no just plaything on github
    • A: People are using stars on github, which is useless. One idea is to look at dependencies. libraries.io is looking. Hope for better metrics.
    • Q: Is it all agile programmings fault?
    • A: Possibly, people this days are learning to code but average level is lower and they don’t know what is under the hood. Pretty good in general but. “Under the hood it is not just a hammer, it is a human being”
    • Q: Your background is in funding, how does transiticion work when a project or some people on it start getting money?
    • A: It is complicated, need some guidelines. Some projects have made it work well ( “jsmobile” I think she said ). Need best practice and to keep things transparent
    • Q: How to we get out to the public (even programmers/tech people at tech companies) what OS is really like these days?
    • A: Example of Rust. Maybe some outreach and general material
    • Q: Is Patreon or other crowd-funding a good way to fund projects?
    • A: Needs a good target, requires a huge following which is hard to people who are not good at marketing. Better for one-time vs recurring. Hard to decide exactly what money should be used for

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 3

Planet Linux Australia - Wed 18th Jan 2017 19:01

Handle Conflict, Like a Boss! – Deb Nicholson

  • Conflict is natural
  • “When they had no outfit for their conflict they turned into Reavers and ate people and stuff”
  • People get caught up in their area not the overall goal for their organisation
  • People associate with a role, don’t like when it gets changed or eliminated
  • Need to go deep, people don’t actually tell you the problem straight away
  • If things get too bad, then go to another project
  • Identify the causes of conflict
  • 3 Styles of handling conflict
    • Avoidance
      • Can let things fester
      • They come across as unconnected
      • Looks like support for the status quo
    • Accommodation
      • Compromise on everything
      • Looks like not taking seriously
    • Assertion
      • Going to wear down everyone else
      • People won’t tell you when things are wrong
  • Going a little deeper
    • People don’t understand history (and why things are weird)
      • go to historical motivations and get buy-in for the strategy that reflects the new reality
    • People are acting to motivations you don’t see
      • Ask about the other persons motivations
    • Fear (often of change)
      • “What is the worse that could happen?”
    • Right Place, wrong time
      • Stuff is going to the wrong person or group
    • Help everyone get perspective
      • Don’t do the same forum, method, people all the time if it always has conflict.
  • What do you do with the Info
    • Put yourself in other persons shoes
    • Find alignment
    • A Word about who is doing this conflict resolution
      • Shouldn’t be just a single person/role
      • Or only women
      • Should be everyone/anyone
      • But if it is within a big or then maybe hire someone
  • Planning for future conflicts
    • Assuming the best
    • No ad hominem (hard to go back)
  • Conflict resolution between groups
    • What could we accomplish if we worked together
    • Doesn’t look good to outsiders
    • More Face-to-Face between projects (towards a common goal)

 

Open Compute Project Down Under – Andrew Ruthven

  • What is Open Compute
    • Vanity free Computing ( remove pretty bits )
    • Stripped Down – we don’t need, no video, minimum extra posts)
    • Efficient and easy
      • Maintenance, Air flow, Electricity
    • Came out of Facebook, now a foundation
    • 1/10th the number of techs/server
  • Projects and Technologies
    • 9 main areas, over 4000 people working on it.
    • Design and Specs
  • Recent Hardware
    • Some comes in 19″ racks
    • HPE, Microsoft Project Olympus
  • In Aus / NZ
    • Telstra – 2 rack of OCP Decathleon, Open Networking using Hyper Scalers
    • Rackspace
    • Large Gaming site
    • Catalyst IT
  • Why OCP for Catalyst
    • Very Open source software orientated company
    • Have a Cloud Operation
    • Looking at for a while
    • Finally ordered first unit in 2016 (Winterfell)
    • Cumulus Linux switches from Penguin computing, works of 12volt in Open Rack
  • Issues for Aus / Nz
    • Very small scale, sometimes to small for vendors
    • Supply chain hard, ended up using an existing integrator
    • Hyper Scalers in Aus, will ship to NZ
    • Number of comapnies seee to NZ
  • Lessons
    • Scale is an issue for failures aswell as supply
    • Have >1 power shelf
    • Have at least 2 racks with 4 power sheleves
    • Too small for vendors to get certification
    • Trust in new hardware
  • Your Own deployment
    • Green field DC
      • Use DC Designs
      • Allow for 48U racks (2.5 metres tall)
      • 2x or 4x 3-phase circuits per rack
    • Existing DCs
      • Consider modifications
      • 19″ servers options
      • 48OU Open rack if you have enough height
      • 22OU is you don’t have enough height
      • Carefully check the specs
    • Open Networking
      • Run collectd etc directly on your switch
    • Supply Chain
    • Community Support
      • OCP has a Aus/NZ Mailing list (ocp-anz)
      • Discussion on what is a priority across Aus and NZ

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 3

Planet Linux Australia - Wed 18th Jan 2017 19:01

Handle Conflict, Like a Boss! – Deb Nicholson

  • Conflict is natural
  • “When they had no outfit for their conflict they turned into Reavers and ate people and stuff”
  • People get caught up in their area not the overall goal for their organisation
  • People associate with a role, don’t like when it gets changed or eliminated
  • Need to go deep, people don’t actually tell you the problem straight away
  • If things get too bad, then go to another project
  • Identify the causes of conflict
  • 3 Styles of handling conflict
    • Avoidance
      • Can let things fester
      • They come across as unconnected
      • Looks like support for the status quo
    • Accommodation
      • Compromise on everything
      • Looks like not taking seriously
    • Assertion
      • Going to wear down everyone else
      • People won’t tell you when things are wrong
  • Going a little deeper
    • People don’t understand history (and why things are weird)
      • go to historical motivations and get buy-in for the strategy that reflects the new reality
    • People are acting to motivations you don’t see
      • Ask about the other persons motivations
    • Fear (often of change)
      • “What is the worse that could happen?”
    • Right Place, wrong time
      • Stuff is going to the wrong person or group
    • Help everyone get perspective
      • Don’t do the same forum, method, people all the time if it always has conflict.
  • What do you do with the Info
    • Put yourself in other persons shoes
    • Find alignment
    • A Word about who is doing this conflict resolution
      • Shouldn’t be just a single person/role
      • Or only women
      • Should be everyone/anyone
      • But if it is within a big or then maybe hire someone
  • Planning for future conflicts
    • Assuming the best
    • No ad hominem (hard to go back)
  • Conflict resolution between groups
    • What could we accomplish if we worked together
    • Doesn’t look good to outsiders
    • More Face-to-Face between projects (towards a common goal)

 

Open Compute Project Down Under – Andrew Ruthven

  • What is Open Compute
    • Vanity free Computing ( remove pretty bits )
    • Stripped Down – we don’t need, no video, minimum extra posts)
    • Efficient and easy
      • Maintenance, Air flow, Electricity
    • Came out of Facebook, now a foundation
    • 1/10th the number of techs/server
  • Projects and Technologies
    • 9 main areas, over 4000 people working on it.
    • Design and Specs
  • Recent Hardware
    • Some comes in 19″ racks
    • HPE, Microsoft Project Olympus
  • In Aus / NZ
    • Telstra – 2 rack of OCP Decathleon, Open Networking using Hyper Scalers
    • Rackspace
    • Large Gaming site
    • Catalyst IT
  • Why OCP for Catalyst
    • Very Open source software orientated company
    • Have a Cloud Operation
    • Looking at for a while
    • Finally ordered first unit in 2016 (Winterfell)
    • Cumulus Linux switches from Penguin computing, works of 12volt in Open Rack
  • Issues for Aus / Nz
    • Very small scale, sometimes to small for vendors
    • Supply chain hard, ended up using an existing integrator
    • Hyper Scalers in Aus, will ship to NZ
    • Number of comapnies seee to NZ
  • Lessons
    • Scale is an issue for failures aswell as supply
    • Have >1 power shelf
    • Have at least 2 racks with 4 power sheleves
    • Too small for vendors to get certification
    • Trust in new hardware
  • Your Own deployment
    • Green field DC
      • Use DC Designs
      • Allow for 48U racks (2.5 metres tall)
      • 2x or 4x 3-phase circuits per rack
    • Existing DCs
      • Consider modifications
      • 19″ servers options
      • 48OU Open rack if you have enough height
      • 22OU is you don’t have enough height
      • Carefully check the specs
    • Open Networking
      • Run collectd etc directly on your switch
    • Supply Chain
    • Community Support
      • OCP has a Aus/NZ Mailing list (ocp-anz)
      • Discussion on what is a priority across Aus and NZ

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 2

Planet Linux Australia - Wed 18th Jan 2017 15:01

400,000 ephemeral containers: testing entire ecosystems with Docker – Daniel Axtens

  • A pretty interesting talk. It was largely a demo so I didn’t grab many notes

Community Building Beyond the Black Stump – Josh Simmons

  • How to build communities when you don’t live in a big city
  • Whats in a meetup?
  • Santa Rosa County, north of San Franscisco
    • Not easy to get to SF
    • SF meetups not always relevant
  • After meeting with one other person, created “North Bay web Professionals”, minimal existing groups
  • Multidisciplinary community worked better
    • Designers, Marketers, Web Devs, writers, etc
    • Hired each other
    • Seemed to work better, fewer toxic dynamics
    • Safe space for beginners
  • 23 People at first event (worked hard to tell people)
    • Told everyone that we knew even if not interested
    • Contacted the competitors
    • Contacting firms, schools
    • Co-working spaces (formal of de-facto like cafes)
    • Other meetup groups, even in unrelated areas.
  • Adapting to the needs of the community
    • You might have a vision
    • But you must adapt to who turns up and what they want/need
  • First meeting
    • Asked people to bring food
    • Fluffy start time so could greet people and mingle
    • Went round room and got people to introduce themselves
      • Intro ended up being a thing they always did
      • Helped people remember names
      • Got everyone to say a little
      • put people in a social mindset
    • Framework for events decided
    • Decided on next meeting date, some prep
    • Ended up going late
      • Format became. Social -> talk -> Social on each night.
  • Tools
    • Used facebook and meetup
    • 1/3 of people came just from meetup promoting automatically
    • Go where people already are
  • Renamed from “North Bay Web professions” to “North Bay Web and Interactive Media professionals”
  • “Ask a person, not a search engine”
  • Hosted over 169 events – Core was the monthly meeting
    • Tried to keep the topics a little broad
    • Often the talk was narrow but compensated with a broad Q&A afterwards
  • Thinking of people as “members” not “attendees” , have to work at getting them come back
  • Also hosted
    • Lunches, rotated all around the region so eventually near everywhere, Casual
    • Unconfernces
    • Topical meetups
    • Charity Hackathon, teamed up with students and non-profits to do website for non-profit. Student was an apprentice.
    • Hosted Ag+Tech mixers with local farmers groups
    • Helped local cities put out tech RFPs
  • Q: Success measures? A: Survey of member, things like Job referrals, what have learnt

 

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 2

Planet Linux Australia - Wed 18th Jan 2017 15:01

400,000 ephemeral containers: testing entire ecosystems with Docker – Daniel Axtens

  • A pretty interesting talk. It was largely a demo so I didn’t grab many notes

Community Building Beyond the Black Stump – Josh Simmons

  • How to build communities when you don’t live in a big city
  • Whats in a meetup?
  • Santa Rosa County, north of San Franscisco
    • Not easy to get to SF
    • SF meetups not always relevant
  • After meeting with one other person, created “North Bay web Professionals”, minimal existing groups
  • Multidisciplinary community worked better
    • Designers, Marketers, Web Devs, writers, etc
    • Hired each other
    • Seemed to work better, fewer toxic dynamics
    • Safe space for beginners
  • 23 People at first event (worked hard to tell people)
    • Told everyone that we knew even if not interested
    • Contacted the competitors
    • Contacting firms, schools
    • Co-working spaces (formal of de-facto like cafes)
    • Other meetup groups, even in unrelated areas.
  • Adapting to the needs of the community
    • You might have a vision
    • But you must adapt to who turns up and what they want/need
  • First meeting
    • Asked people to bring food
    • Fluffy start time so could greet people and mingle
    • Went round room and got people to introduce themselves
      • Intro ended up being a thing they always did
      • Helped people remember names
      • Got everyone to say a little
      • put people in a social mindset
    • Framework for events decided
    • Decided on next meeting date, some prep
    • Ended up going late
      • Format became. Social -> talk -> Social on each night.
  • Tools
    • Used facebook and meetup
    • 1/3 of people came just from meetup promoting automatically
    • Go where people already are
  • Renamed from “North Bay Web professions” to “North Bay Web and Interactive Media professionals”
  • “Ask a person, not a search engine”
  • Hosted over 169 events – Core was the monthly meeting
    • Tried to keep the topics a little broad
    • Often the talk was narrow but compensated with a broad Q&A afterwards
  • Thinking of people as “members” not “attendees” , have to work at getting them come back
  • Also hosted
    • Lunches, rotated all around the region so eventually near everywhere, Casual
    • Unconfernces
    • Topical meetups
    • Charity Hackathon, teamed up with students and non-profits to do website for non-profit. Student was an apprentice.
    • Hosted Ag+Tech mixers with local farmers groups
    • Helped local cities put out tech RFPs
  • Q: Success measures? A: Survey of member, things like Job referrals, what have learnt

 

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 1

Planet Linux Australia - Wed 18th Jan 2017 13:01

Servo Architecture: Safety and Performance – Jack Moffitt

  • History
    • 1994 Netscape Navigator
    • 2002 Mozilla Release
    • 2008 multi-core CPU stuff not making firefox faster
    • 2016 CPUs now have on-chip GPUs
    • Very hard to write multi-threaded C++ to allow mozilla to take advantage of many cores
  • How to make Servo Faster?
  • Constellation
    • In the past – Monolithic browser engines
      • Single browser engine handling multiple tabs
      • Two processes – Pool Content processes vs Chrome process
        • If one process dies on a page doesn’t take out whole browser
      • Sanboxing lets webpage copies have less privs
    • Threads
      • Less overhead than whole processes
      • Thread per page
      • More responsive
      • Sandboxing
      • More robust to failure
    • Is this the best we can do?
      • Run Javascript and layout simultaniously
      • Pipeline splitting them up
      • Child pipelines for inner iframes (eg ads)
  • Constellation
    • Rust can fail better
    • Most failures stop at thread boundaries
    • Still do sandbox and privledges
    • Option to still have some tabs in multiple processes
  • Webrender
    • Using the GPU
      • Frees up main CPU
      • Are VERY fast at some stuff
      • Easiest place to start is rendering
    • Don’t browsers already use the GPU?
      • Only in a limited way for compositing
    • Key ideas
      • Retain mode not immediate mode (put things in optimal order first)
      • Designed to render CSS content (CSS is actually pretty simple)
      • Draw the whole frame every frame (things are fast enough, simpler to not try to optimise)
    • Pipeline
      • Chop screen into 256×256 tiles
      • Tile assignment
      • Create a big tree
      • merge and assign render targets
      • create and execute batches
    • Text
      • Rasterize on CPU and upload glyth to GPU
      • Paste and shadow usign the GPU
  • Project Quantum
    •  Taking technology we made in servo and put it in gecko
  • Research in progress
    • Pathfinder – GPU font rasterizer – Now faster than everything else
    • Magic DOM
      • Wins in JS/DOM intergration
      • Fusing reflectors and DOM objects
      • Self hosted JS
    • External colaborations: ML, Power Mngt, WebBluetooth, etc
  • Get involved
    • Test nightlies
    • Curated bugs for new contributors
    • servo.org

In Case of Emergency: Break Glass – BCP, DRP, & Digital Legacy – David Bell

  • Definitions
    • BCP = Business continuity Plan
    • A process to prevent and recover from business continuity plans
    • BIP = Business interuptions plan
    • BRP = Recovery plan
    • RPO = Recovery point objective, targetted recovery point (when you last backed up)
    • RTO = Recovery time objective
  • Why?
    • Because things will go wrong
    • Because things should not go even more wrong
  • Create your BCP
    • Brainstorm
    • Identify events that may interrupt, loss access to physical site, loss of staff
    • Backups
      • 3 copies
      • 2 different media/formats
      • 1 offsite and online
      • Check how long it will take to download or fetch
    • Test
    • Who has the Authority
    • Communication chains, phone trees, contact details
    • Practice Early, Practice often
      • Real-world scenarios
      • Measure, measure, measure
      • Record your results
      • Convert your into an action item
      • Have different people on the tests
    • Each Biz Unit or team should have their own BCP
    • Recovery can be expensive, make sure you know what your insurance will cover
  • Breaking the Glass
    • Documentation is the Key
    • Secure credentials super important
    • Shamir secret sharing, need number of people to re-create the share
  • Digital Legacy
    • Do the same for your personal data
    • Document
      • Credentials
      • Services
        • What uses them
        • billing arrangments
        • Credentials
      • What are your wishes for the above.
    • Talk to your family and friends
    • Backups
    • Document backups and backup your documentation
    • Secret sharing, offer to do the same for your friends
  • Other / Questions
    • Think about 2-Facter devices
    • Google and some others companies can setup “Next of Kin” contacts

 

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday – Session 1

Planet Linux Australia - Wed 18th Jan 2017 13:01

Servo Architecture: Safety and Performance – Jack Moffitt

  • History
    • 1994 Netscape Navigator
    • 2002 Mozilla Release
    • 2008 multi-core CPU stuff not making firefox faster
    • 2016 CPUs now have on-chip GPUs
    • Very hard to write multi-threaded C++ to allow mozilla to take advantage of many cores
  • How to make Servo Faster?
  • Constellation
    • In the past – Monolithic browser engines
      • Single browser engine handling multiple tabs
      • Two processes – Pool Content processes vs Chrome process
        • If one process dies on a page doesn’t take out whole browser
      • Sanboxing lets webpage copies have less privs
    • Threads
      • Less overhead than whole processes
      • Thread per page
      • More responsive
      • Sandboxing
      • More robust to failure
    • Is this the best we can do?
      • Run Javascript and layout simultaniously
      • Pipeline splitting them up
      • Child pipelines for inner iframes (eg ads)
  • Constellation
    • Rust can fail better
    • Most failures stop at thread boundaries
    • Still do sandbox and privledges
    • Option to still have some tabs in multiple processes
  • Webrender
    • Using the GPU
      • Frees up main CPU
      • Are VERY fast at some stuff
      • Easiest place to start is rendering
    • Don’t browsers already use the GPU?
      • Only in a limited way for compositing
    • Key ideas
      • Retain mode not immediate mode (put things in optimal order first)
      • Designed to render CSS content (CSS is actually pretty simple)
      • Draw the whole frame every frame (things are fast enough, simpler to not try to optimise)
    • Pipeline
      • Chop screen into 256×256 tiles
      • Tile assignment
      • Create a big tree
      • merge and assign render targets
      • create and execute batches
    • Text
      • Rasterize on CPU and upload glyth to GPU
      • Paste and shadow usign the GPU
  • Project Quantum
    •  Taking technology we made in servo and put it in gecko
  • Research in progress
    • Pathfinder – GPU font rasterizer – Now faster than everything else
    • Magic DOM
      • Wins in JS/DOM intergration
      • Fusing reflectors and DOM objects
      • Self hosted JS
    • External colaborations: ML, Power Mngt, WebBluetooth, etc
  • Get involved
    • Test nightlies
    • Curated bugs for new contributors
    • servo.org

In Case of Emergency: Break Glass – BCP, DRP, & Digital Legacy – David Bell

  • Definitions
    • BCP = Business continuity Plan
    • A process to prevent and recover from business continuity plans
    • BIP = Business interuptions plan
    • BRP = Recovery plan
    • RPO = Recovery point objective, targetted recovery point (when you last backed up)
    • RTO = Recovery time objective
  • Why?
    • Because things will go wrong
    • Because things should not go even more wrong
  • Create your BCP
    • Brainstorm
    • Identify events that may interrupt, loss access to physical site, loss of staff
    • Backups
      • 3 copies
      • 2 different media/formats
      • 1 offsite and online
      • Check how long it will take to download or fetch
    • Test
    • Who has the Authority
    • Communication chains, phone trees, contact details
    • Practice Early, Practice often
      • Real-world scenarios
      • Measure, measure, measure
      • Record your results
      • Convert your into an action item
      • Have different people on the tests
    • Each Biz Unit or team should have their own BCP
    • Recovery can be expensive, make sure you know what your insurance will cover
  • Breaking the Glass
    • Documentation is the Key
    • Secure credentials super important
    • Shamir secret sharing, need number of people to re-create the share
  • Digital Legacy
    • Do the same for your personal data
    • Document
      • Credentials
      • Services
        • What uses them
        • billing arrangments
        • Credentials
      • What are your wishes for the above.
    • Talk to your family and friends
    • Backups
    • Document backups and backup your documentation
    • Secret sharing, offer to do the same for your friends
  • Other / Questions
    • Think about 2-Facter devices
    • Google and some others companies can setup “Next of Kin” contacts

 

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday Keynote – Dan Callahan

Planet Linux Australia - Wed 18th Jan 2017 11:01

Designing for failure: On the decommissioning of Persona

  • Worked for Mozilla on Persona
  • Persona did authentication on the web
    • You would go to a website
    • Type in your email address
    • Redirects via login page by your email provider
    • You login and redirect back
  • Started centralised, designed to be uncentralised as it is taken up
  • Some sites were only offering login via social media
    • Some didn’t offer traditional logins for emails or local usernames
    • Imposes 3rd party between you and your user.
    • Those 3rd parties have their own rules, eg real name requirements
  • Persona Failed
    • Traditional logins now more common
  • Cave Diving
    • Equipment and procedures designed to let you still survive if something fails
    • Training review deaths and determines how can be prevented
    • “5 rules of accident analysis” for cave diving
  • Three weeks ago switched off Persona
    • Encourage others to share mistakes

 

  • Just having a free license is not enough to succeed
  • Had a built in centralisation point
    • Protocol designed so browser could eventually natively implement but initially login.persona.com was using it.
    • Relay between provider and website went via Mozilla until browser natively implemented
    • No ability to fork the project
  • Bits rot more quickly online
    • Stuff that is online must be continually maintain (especially security)
    • Need a way to have software maintained without experts
  • Complexity Limits agency
    • Limits who can run project at all
    • Lots of work for those people who can run it
  • A free license don’t further my feeedom if we can’t run the software

 

  • Prolong Your Project’s Life
  • Bad ideas
    • We used popups and people reflexively closed them
    • API wasn’t great
  • Didn’t measure the right thing
    • Is persona product or infrastructure?
    • Treated like a product, not a good fit
  • Explicitly define and communicate your scope
    • “Solves authentication” or “Authenticate email addresses”
    • Broke some sites
    • Got used by FireFoxOS which was not a good fit
  • Ruthlessly oppose complexity
    • Tried to do too much mean’t it was overly complex
    • Complex hard to maintain and review and grow
    • Hard for newbies to join
    • If it is complex then it is hard to even test that is is working as expected
    • Focus and simplify
    • Almost no outside contributors, especially bad when mozilla dropped it.

 

  • Plan for Your Projects Failure
  • “Sometimes that [bus failure] is just a commuter bus that picks up that person and takes them to another job”
  • If you know you are dead say it
    • 3 years after we pulled people off project till officially killed
    • Might work for local software but services cost money to run
    • Sooner you admit you are dead the sooner people can plan to your departure
  • Ensure your users can recover without your involvement
    • Hard to do when you think your project is going to save the world
    • Example firefox sync has a copy of the data locally so even if it dies user will survive
  • Use standard data formats
    • eg OPML for RSS providers
  • Minimise the harm caused when your project goes away

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Wednesday Keynote – Dan Callahan

Planet Linux Australia - Wed 18th Jan 2017 11:01

Designing for failure: On the decommissioning of Persona

  • Worked for Mozilla on Persona
  • Persona did authentication on the web
    • You would go to a website
    • Type in your email address
    • Redirects via login page by your email provider
    • You login and redirect back
  • Started centralised, designed to be uncentralised as it is taken up
  • Some sites were only offering login via social media
    • Some didn’t offer traditional logins for emails or local usernames
    • Imposes 3rd party between you and your user.
    • Those 3rd parties have their own rules, eg real name requirements
  • Persona Failed
    • Traditional logins now more common
  • Cave Diving
    • Equipment and procedures designed to let you still survive if something fails
    • Training review deaths and determines how can be prevented
    • “5 rules of accident analysis” for cave diving
  • Three weeks ago switched off Persona
    • Encourage others to share mistakes

 

  • Just having a free license is not enough to succeed
  • Had a built in centralisation point
    • Protocol designed so browser could eventually natively implement but initially login.persona.com was using it.
    • Relay between provider and website went via Mozilla until browser natively implemented
    • No ability to fork the project
  • Bits rot more quickly online
    • Stuff that is online must be continually maintain (especially security)
    • Need a way to have software maintained without experts
  • Complexity Limits agency
    • Limits who can run project at all
    • Lots of work for those people who can run it
  • A free license don’t further my feeedom if we can’t run the software

 

  • Prolong Your Project’s Life
  • Bad ideas
    • We used popups and people reflexively closed them
    • API wasn’t great
  • Didn’t measure the right thing
    • Is persona product or infrastructure?
    • Treated like a product, not a good fit
  • Explicitly define and communicate your scope
    • “Solves authentication” or “Authenticate email addresses”
    • Broke some sites
    • Got used by FireFoxOS which was not a good fit
  • Ruthlessly oppose complexity
    • Tried to do too much mean’t it was overly complex
    • Complex hard to maintain and review and grow
    • Hard for newbies to join
    • If it is complex then it is hard to even test that is is working as expected
    • Focus and simplify
    • Almost no outside contributors, especially bad when mozilla dropped it.

 

  • Plan for Your Projects Failure
  • “Sometimes that [bus failure] is just a commuter bus that picks up that person and takes them to another job”
  • If you know you are dead say it
    • 3 years after we pulled people off project till officially killed
    • Might work for local software but services cost money to run
    • Sooner you admit you are dead the sooner people can plan to your departure
  • Ensure your users can recover without your involvement
    • Hard to do when you think your project is going to save the world
    • Example firefox sync has a copy of the data locally so even if it dies user will survive
  • Use standard data formats
    • eg OPML for RSS providers
  • Minimise the harm caused when your project goes away

 

Share

Categories: thinktime

Guerrilla Innovation

a list apart - Wed 18th Jan 2017 02:01

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing.

After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months.

So how do you push an idea through? How can you innovate if you work in a less-than-innovative place?

It takes more than a big idea

Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along?

You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting.

Your excitement is completely drained within five minutes.

“Seems like a lot of extra work.”

“Why would we create a prototype just to rewrite it all in code?”

“Let’s just build it Drupal.”

Knife. In. Heart.

You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company.

So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object.

Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics.

Frame the problem

The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea.

Coolness alone isn’t enough. And “cool” is always up for interpretation.

Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you.

By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing.

Start at the end

When your idea is implemented and everything goes as planned, what benefit will it provide?

Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them.

Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are looking for more easily; the content would therefore be more useful and usable for them.

If visitors have a better experience, that could result in a better conversion rate—which in turn would help your manager’s goals as web sales improve.

That benefit could extend to your team as a whole, too: a prototyping tool could improve communication between the marketing group and the development group. Using a prototyping tool would help quickly visualize ideas so that everyone can see how the site is evolving. Questions could be asked and addressed sooner. A prototyping tool could be just the thing you need to get everyone on the same page about content and identified goals.

Identify your target audience(s)

The top two audiences with the potential to get the most benefit from your innovative idea are your target audiences. If the end user of the website will receive the most benefit, then that is your primary target audience. If your manager receives a benefit as a result, then that is your secondary target audience.

Take some time to develop a persona around each of your top target audiences. A persona is a document that summarizes research trends and data that have been collected about a key audience segment. Although a persona depicts a single person, it should never be based on one real individual; rather, it’s an amalgam of characteristics from many people in the real world. A persona is usually one page and includes characteristics such as attitude, goals, skill level, occupation, and background. For more on developing personas to improve user experience, check out Usability.gov.

When you’re waist deep in this idea in the next six months and your coworkers are complaining about the extra workload, and you’re wondering why you ever decided to do this you will look at your white board where you have your personas displayed and you will remember they are your target audience, not you. All of this extra work is for their benefit.

As you implement a workflow using a prototyping tool and the decision gets made to only do only one round of user testing instead of the three rounds that were initially discussed, you can reference your personas and ask who stands to benefit from that decision. Are you just saving time for the developers and the stakeholders in an attempt to pump out websites faster? Or will this really benefit the target audience?

Do a pre-postmortem

Understanding the risks of innovation does not mean backing away from your idea and giving up. When you understand the obstacles in front of you, you can more easily identify them and develop solutions before potential failures take place.

One useful exercise is to do a postmortem report even before you begin. Start anticipating the reasons the tool or project will fail so you can avoid those pitfalls. Some questions you might ask in a postmortem:

  • Who was involved in the project?
  • What went well with the project?
  • What did not go well?
  • What can we do next time to improve our results?

With our prototyping example, a possible reason for failure might be the team not adopting the tool and it never gaining traction. You need the team to be on the same page and using the same workflow; lack of adoption could be detrimental to progress.

Analyze your current situation

What sorts of effects are you seeing right now because of this identified problem? Gather some data to prove there is an actual problem that needs to be addressed. If your help desk continually receives calls about users unable to find a specific button on your website, for example, then you have some evidence of a bad user experience.

Do some research

Ask your coworkers what they know about prototyping. Ask if they have ever experimented with any prototyping tools.

Ask your end users about the content on your site. Gather some information about just how bad the user experience really is.

This is not the time to pitch your idea. You are in complete listening/observation mode. Save the elevator pitch for later, when you have all the information and are confident this is the right solution to a very specific problem and you are prepared to answer the questions that will come.

Assess your tools

Are there any tools you use now that are similar to the tool you are proposing? If so, what are their benefits and downfalls?

Take the UXPin example. Does your team use paper to do prototypes right now? Does the graphic designer use Photoshop to start with wireframes/prototypes before doing a high-res layout?

Having a ready list of pros and cons for the tools you currently use will help you build a case around why your solution is superior and will show that you’ve done your homework.

Check your ego

Scrutinize your motivations for wanting to introduce a new tool. Do you want to try something new just to take control of a situation? If the graphic designer does a fine job using Photoshop to develop a prototype but you don’t know how to use Photoshop, that’s not a great reason to try a new tool.

However, if you have a team of six and only one person knows how to use Photoshop, choosing a more accessible tool with a shorter learning curve could be the right move.

Explore other solutions

Are there other tools out there that will solve the problem you discovered?
If you don’t yet have room in the budget for UXPin, can something else get you by while you prove the value of this type of tool? can you use paper prototypes for a few months while the team adjusts to this new part of their workflow?

Sometimes starting with something less complex can be beneficial. Anyone can use pen and paper, but learning new software can be daunting and time-consuming.

Still think this is an awesome idea?

You now understand the tangible benefits of implementing your innovative idea and you know who stands to gain from it. You can foresee both the rewards of implementing it and the potential risks of not implementing it.

Your motives are good, you’ve analyzed your current situation for similar tools or processes that may already be in place, and you’ve explored other potential solutions. You are well on your way to building a strong case around your innovative idea. At this point, you’ve put a lot of time and effort into developing it. Do you still think it’s a good idea, and are you as excited as you were when you started?

If you’ve lost your drive and excitement at this point, or have been unable to visualize any real benefit, the idea may not be worth implementing. That’s okay. The way you will land on a really great idea is by testing many not-so-great ideas until you find one that fits.

Your continued excitement and drive will be necessary as you start to implement your idea and work toward gaining supporters.

Start small and fail as soon as possible

Even if you’re still quite sure this idea is amazing, start small and keep an open mind. A thousand questions will come to mind as you begin using an actual product with real users.

As you start running a couple of tests, use language like “experiment” instead of “implementation.” This leaves room for error and growth. You want to know what’s not going to work as much as you want to know what is going to work. And if someone asks what you’re doing, it sounds way more innocent if you say you’re running a few experiments that you’re going to share with the team than if you say you’re implementing a prototyping tool into our web development process.

If you’re working on a current website project, try creating just one page using the prototyping tool on your own time, not as a part of the official project process. See how it goes building just one page for now. Even better, try making just one element of the page, like the header or navigation. By starting small you will have fewer variables to take into consideration. Remember, right now you’re evaluating the tool itself, not necessarily the user experience of your website.

Then take your prototype and see what kind of feedback you can get by testing it with real end users.

Is the prototype responsive? What URL did you need to use to access it? Was it easy to direct users to this URL? Can you record mouse movements or clicks, and do you need to? How are you documenting their feedback to the site? Were they able to use their own device, or did you need to provide it? What are you going to do with the feedback and observations you’ve gained?

Do several tiny experiments like this, making adjustments as you go, until you’re more comfortable with the tool, its features, and the results you get from it. Your confidence with the tool will give your team confidence with it as well.

Don’t get fired

Most companies don’t mind their employees doing research about their work on company time. Unfortunately, some do mind. Using your own device on your lunch hour or before and after work may be your only option.

Even if your job does allow you to research and learn on the clock, be respectful of time. Spending several months straight iterating on one idea might not be good for your next employee review. 3M designates 15 percent time for employees to focus on innovation; Google has famously allowed up to 20 percent of employee time to focus on new innovative ideas. Try to gauge what percentage of time you could reasonably spend on your research without neglecting your real job.

Be transparent about what you’re doing. Hiding it and sneaking around will give the wrong impression. Let your boss know you’re curious about a new tool and you’re just running a few experiments to explore it more. Curious, experiment, explore—as I suggested earlier, these are all safe words implying no level of commitment or pressure.

Win allies

Presumably you have a few friends in the office; take them out to lunch and toss them the idea. Let them know about the experiments you’re running and the results you’re getting. Ask if they want to see what you’ve been working on.

It might take a while for anyone to show some interest. Don’t give up if your excitement isn’t mirrored immediately and don’t be pushy. Remember, you want your colleagues to be in your corner.

Also, bouncing your idea off your coworkers is great practice for telling your boss. Your coworkers will definitely ask you a bunch of questions you haven’t thought of yet and will express viewpoints you haven’t considered.

Listen to their opposition and use their concerns to build your case. Do they think adding a new tool to the workflow will slow down the process? Explore that concern; next time you talk, offer some data and insight about how that assumption might not be true.

Having your team on your side will go a long way when presenting this to your boss, but it doesn’t have to be a deal-breaker if they’re not. Sometimes our coworkers are just so scared of change that no amount of data will make them comfortable. They will likely express their concerns when you bring your idea up in front of the boss; having a prepared response makes you look confident.

Get your boss’ support

Time to go up a level. Please do not put together a giant presentation, wear your best power suite, and pour your heart out onto the line. If your experience is anything like mine, you’ll just spend the rest of the day crying off and on in the bathroom.

A definitive, polished presentation can be offputting. It makes you look like you’ve already solved the whole problem. You want to appear open to suggestions—because you are.

The approach

You know your relationship with your boss, and how to approach them, better than anyone else. For me, the best way is to wait for the right opening and mention the new idea in passing. Be prepared to show all of your progress and make some sort of proposal right on the spot. Make it seem easy and low-risk, with clear next steps. I’ve found it beneficial to address the concerns of your team up front to show you value their opinion and input. Bosses love teamwork.

If there isn’t clear interest from your boss, ask them what other data or information they would like to see to help support this idea. What are their concerns or hesitations?

At this point, consider asking for permission to continue to experiment on a broader level. The word “implement” really freaks people out. Trying a prototyping tool in the web-development process for three months instead of implementing it forever sounds a lot less risky.

Persevere

If you can’t stick with your idea long enough to do some research and run some experiments, why should anyone else? If it truly matters to you and you can see your idea making a real change in your company or within your work environment, hang in there for the long haul.

When the graphic designers agree to use UXpin as a prototyping tool and the User Experience team (if you’re lucky enough to have a UX team, really I’m not jealous) says they will give it a try for end user testing, ask to be a part of their process. Ask them to invite you to the end-user testing sessions and the design reviews with the stakeholders.

Be in those sessions and meetings as the the idea is implemented so you can continue to reference your personas and make sure decisions are made for the right reasons. That way, you’ll be in the front row to see positive change happen as you guide your idea and hard work into something truly innovative.

As your idea starts to gain traction and your experiments turn into a real process—see things through. Don’t just hand off your idea and hope for the best like a child waiting for the school bus. Drive the damn bus.

 

Categories: thinktime

Guerrilla Innovation

a list apart - Wed 18th Jan 2017 02:01

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing.

After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months.

So how do you push an idea through? How can you innovate if you work in a less-than-innovative place?

It takes more than a big idea

Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along?

You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting.

Your excitement is completely drained within five minutes.

“Seems like a lot of extra work.”

“Why would we create a prototype just to rewrite it all in code?”

“Let’s just build it Drupal.”

Knife. In. Heart.

You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company.

So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object.

Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics.

Frame the problem

The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea.

Coolness alone isn’t enough. And “cool” is always up for interpretation.

Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you.

By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing.

Start at the end

When your idea is implemented and everything goes as planned, what benefit will it provide?

Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them.

Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are looking for more easily; the content would therefore be more useful and usable for them.

If visitors have a better experience, that could result in a better conversion rate—which in turn would help your manager’s goals as web sales improve.

That benefit could extend to your team as a whole, too: a prototyping tool could improve communication between the marketing group and the development group. Using a prototyping tool would help quickly visualize ideas so that everyone can see how the site is evolving. Questions could be asked and addressed sooner. A prototyping tool could be just the thing you need to get everyone on the same page about content and identified goals.

Identify your target audience(s)

The top two audiences with the potential to get the most benefit from your innovative idea are your target audiences. If the end user of the website will receive the most benefit, then that is your primary target audience. If your manager receives a benefit as a result, then that is your secondary target audience.

Take some time to develop a persona around each of your top target audiences. A persona is a document that summarizes research trends and data that have been collected about a key audience segment. Although a persona depicts a single person, it should never be based on one real individual; rather, it’s an amalgam of characteristics from many people in the real world. A persona is usually one page and includes characteristics such as attitude, goals, skill level, occupation, and background. For more on developing personas to improve user experience, check out Usability.gov.

When you’re waist deep in this idea in the next six months and your coworkers are complaining about the extra workload, and you’re wondering why you ever decided to do this you will look at your white board where you have your personas displayed and you will remember they are your target audience, not you. All of this extra work is for their benefit.

As you implement a workflow using a prototyping tool and the decision gets made to only do only one round of user testing instead of the three rounds that were initially discussed, you can reference your personas and ask who stands to benefit from that decision. Are you just saving time for the developers and the stakeholders in an attempt to pump out websites faster? Or will this really benefit the target audience?

Do a pre-postmortem

Understanding the risks of innovation does not mean backing away from your idea and giving up. When you understand the obstacles in front of you, you can more easily identify them and develop solutions before potential failures take place.

One useful exercise is to do a postmortem report even before you begin. Start anticipating the reasons the tool or project will fail so you can avoid those pitfalls. Some questions you might ask in a postmortem:

  • Who was involved in the project?
  • What went well with the project?
  • What did not go well?
  • What can we do next time to improve our results?

With our prototyping example, a possible reason for failure might be the team not adopting the tool and it never gaining traction. You need the team to be on the same page and using the same workflow; lack of adoption could be detrimental to progress.

Analyze your current situation

What sorts of effects are you seeing right now because of this identified problem? Gather some data to prove there is an actual problem that needs to be addressed. If your help desk continually receives calls about users unable to find a specific button on your website, for example, then you have some evidence of a bad user experience.

Do some research

Ask your coworkers what they know about prototyping. Ask if they have ever experimented with any prototyping tools.

Ask your end users about the content on your site. Gather some information about just how bad the user experience really is.

This is not the time to pitch your idea. You are in complete listening/observation mode. Save the elevator pitch for later, when you have all the information and are confident this is the right solution to a very specific problem and you are prepared to answer the questions that will come.

Assess your tools

Are there any tools you use now that are similar to the tool you are proposing? If so, what are their benefits and downfalls?

Take the UXPin example. Does your team use paper to do prototypes right now? Does the graphic designer use Photoshop to start with wireframes/prototypes before doing a high-res layout?

Having a ready list of pros and cons for the tools you currently use will help you build a case around why your solution is superior and will show that you’ve done your homework.

Check your ego

Scrutinize your motivations for wanting to introduce a new tool. Do you want to try something new just to take control of a situation? If the graphic designer does a fine job using Photoshop to develop a prototype but you don’t know how to use Photoshop, that’s not a great reason to try a new tool.

However, if you have a team of six and only one person knows how to use Photoshop, choosing a more accessible tool with a shorter learning curve could be the right move.

Explore other solutions

Are there other tools out there that will solve the problem you discovered?
If you don’t yet have room in the budget for UXPin, can something else get you by while you prove the value of this type of tool? can you use paper prototypes for a few months while the team adjusts to this new part of their workflow?

Sometimes starting with something less complex can be beneficial. Anyone can use pen and paper, but learning new software can be daunting and time-consuming.

Still think this is an awesome idea?

You now understand the tangible benefits of implementing your innovative idea and you know who stands to gain from it. You can foresee both the rewards of implementing it and the potential risks of not implementing it.

Your motives are good, you’ve analyzed your current situation for similar tools or processes that may already be in place, and you’ve explored other potential solutions. You are well on your way to building a strong case around your innovative idea. At this point, you’ve put a lot of time and effort into developing it. Do you still think it’s a good idea, and are you as excited as you were when you started?

If you’ve lost your drive and excitement at this point, or have been unable to visualize any real benefit, the idea may not be worth implementing. That’s okay. The way you will land on a really great idea is by testing many not-so-great ideas until you find one that fits.

Your continued excitement and drive will be necessary as you start to implement your idea and work toward gaining supporters.

Start small and fail as soon as possible

Even if you’re still quite sure this idea is amazing, start small and keep an open mind. A thousand questions will come to mind as you begin using an actual product with real users.

As you start running a couple of tests, use language like “experiment” instead of “implementation.” This leaves room for error and growth. You want to know what’s not going to work as much as you want to know what is going to work. And if someone asks what you’re doing, it sounds way more innocent if you say you’re running a few experiments that you’re going to share with the team than if you say you’re implementing a prototyping tool into our web development process.

If you’re working on a current website project, try creating just one page using the prototyping tool on your own time, not as a part of the official project process. See how it goes building just one page for now. Even better, try making just one element of the page, like the header or navigation. By starting small you will have fewer variables to take into consideration. Remember, right now you’re evaluating the tool itself, not necessarily the user experience of your website.

Then take your prototype and see what kind of feedback you can get by testing it with real end users.

Is the prototype responsive? What URL did you need to use to access it? Was it easy to direct users to this URL? Can you record mouse movements or clicks, and do you need to? How are you documenting their feedback to the site? Were they able to use their own device, or did you need to provide it? What are you going to do with the feedback and observations you’ve gained?

Do several tiny experiments like this, making adjustments as you go, until you’re more comfortable with the tool, its features, and the results you get from it. Your confidence with the tool will give your team confidence with it as well.

Don’t get fired

Most companies don’t mind their employees doing research about their work on company time. Unfortunately, some do mind. Using your own device on your lunch hour or before and after work may be your only option.

Even if your job does allow you to research and learn on the clock, be respectful of time. Spending several months straight iterating on one idea might not be good for your next employee review. 3M designates 15 percent time for employees to focus on innovation; Google has famously allowed up to 20 percent of employee time to focus on new innovative ideas. Try to gauge what percentage of time you could reasonably spend on your research without neglecting your real job.

Be transparent about what you’re doing. Hiding it and sneaking around will give the wrong impression. Let your boss know you’re curious about a new tool and you’re just running a few experiments to explore it more. Curious, experiment, explore—as I suggested earlier, these are all safe words implying no level of commitment or pressure.

Win allies

Presumably you have a few friends in the office; take them out to lunch and toss them the idea. Let them know about the experiments you’re running and the results you’re getting. Ask if they want to see what you’ve been working on.

It might take a while for anyone to show some interest. Don’t give up if your excitement isn’t mirrored immediately and don’t be pushy. Remember, you want your colleagues to be in your corner.

Also, bouncing your idea off your coworkers is great practice for telling your boss. Your coworkers will definitely ask you a bunch of questions you haven’t thought of yet and will express viewpoints you haven’t considered.

Listen to their opposition and use their concerns to build your case. Do they think adding a new tool to the workflow will slow down the process? Explore that concern; next time you talk, offer some data and insight about how that assumption might not be true.

Having your team on your side will go a long way when presenting this to your boss, but it doesn’t have to be a deal-breaker if they’re not. Sometimes our coworkers are just so scared of change that no amount of data will make them comfortable. They will likely express their concerns when you bring your idea up in front of the boss; having a prepared response makes you look confident.

Get your boss’ support

Time to go up a level. Please do not put together a giant presentation, wear your best power suite, and pour your heart out onto the line. If your experience is anything like mine, you’ll just spend the rest of the day crying off and on in the bathroom.

A definitive, polished presentation can be offputting. It makes you look like you’ve already solved the whole problem. You want to appear open to suggestions—because you are.

The approach

You know your relationship with your boss, and how to approach them, better than anyone else. For me, the best way is to wait for the right opening and mention the new idea in passing. Be prepared to show all of your progress and make some sort of proposal right on the spot. Make it seem easy and low-risk, with clear next steps. I’ve found it beneficial to address the concerns of your team up front to show you value their opinion and input. Bosses love teamwork.

If there isn’t clear interest from your boss, ask them what other data or information they would like to see to help support this idea. What are their concerns or hesitations?

At this point, consider asking for permission to continue to experiment on a broader level. The word “implement” really freaks people out. Trying a prototyping tool in the web-development process for three months instead of implementing it forever sounds a lot less risky.

Persevere

If you can’t stick with your idea long enough to do some research and run some experiments, why should anyone else? If it truly matters to you and you can see your idea making a real change in your company or within your work environment, hang in there for the long haul.

When the graphic designers agree to use UXpin as a prototyping tool and the User Experience team (if you’re lucky enough to have a UX team, really I’m not jealous) says they will give it a try for end user testing, ask to be a part of their process. Ask them to invite you to the end-user testing sessions and the design reviews with the stakeholders.

Be in those sessions and meetings as the the idea is implemented so you can continue to reference your personas and make sure decisions are made for the right reasons. That way, you’ll be in the front row to see positive change happen as you guide your idea and hard work into something truly innovative.

As your idea starts to gain traction and your experiments turn into a real process—see things through. Don’t just hand off your idea and hope for the best like a child waiting for the school bus. Drive the damn bus.

 

Categories: thinktime

Guerrilla Innovation

a list apart - Wed 18th Jan 2017 02:01

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing.

After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months.

So how do you push an idea through? How can you innovate if you work in a less-than-innovative place?

It takes more than a big idea

Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along?

You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting.

Your excitement is completely drained within five minutes.

“Seems like a lot of extra work.”

“Why would we create a prototype just to rewrite it all in code?”

“Let’s just build it Drupal.”

Knife. In. Heart.

You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company.

So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object.

Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics.

Frame the problem

The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea.

Coolness alone isn’t enough. And “cool” is always up for interpretation.

Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you.

By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing.

Start at the end

When your idea is implemented and everything goes as planned, what benefit will it provide?

Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them.

Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are looking for more easily; the content would therefore be more useful and usable for them.

If visitors have a better experience, that could result in a better conversion rate—which in turn would help your manager’s goals as web sales improve.

That benefit could extend to your team as a whole, too: a prototyping tool could improve communication between the marketing group and the development group. Using a prototyping tool would help quickly visualize ideas so that everyone can see how the site is evolving. Questions could be asked and addressed sooner. A prototyping tool could be just the thing you need to get everyone on the same page about content and identified goals.

Identify your target audience(s)

The top two audiences with the potential to get the most benefit from your innovative idea are your target audiences. If the end user of the website will receive the most benefit, then that is your primary target audience. If your manager receives a benefit as a result, then that is your secondary target audience.

Take some time to develop a persona around each of your top target audiences. A persona is a document that summarizes research trends and data that have been collected about a key audience segment. Although a persona depicts a single person, it should never be based on one real individual; rather, it’s an amalgam of characteristics from many people in the real world. A persona is usually one page and includes characteristics such as attitude, goals, skill level, occupation, and background. For more on developing personas to improve user experience, check out Usability.gov.

When you’re waist deep in this idea in the next six months and your coworkers are complaining about the extra workload, and you’re wondering why you ever decided to do this you will look at your white board where you have your personas displayed and you will remember they are your target audience, not you. All of this extra work is for their benefit.

As you implement a workflow using a prototyping tool and the decision gets made to only do only one round of user testing instead of the three rounds that were initially discussed, you can reference your personas and ask who stands to benefit from that decision. Are you just saving time for the developers and the stakeholders in an attempt to pump out websites faster? Or will this really benefit the target audience?

Do a pre-postmortem

Understanding the risks of innovation does not mean backing away from your idea and giving up. When you understand the obstacles in front of you, you can more easily identify them and develop solutions before potential failures take place.

One useful exercise is to do a postmortem report even before you begin. Start anticipating the reasons the tool or project will fail so you can avoid those pitfalls. Some questions you might ask in a postmortem:

  • Who was involved in the project?
  • What went well with the project?
  • What did not go well?
  • What can we do next time to improve our results?

With our prototyping example, a possible reason for failure might be the team not adopting the tool and it never gaining traction. You need the team to be on the same page and using the same workflow; lack of adoption could be detrimental to progress.

Analyze your current situation

What sorts of effects are you seeing right now because of this identified problem? Gather some data to prove there is an actual problem that needs to be addressed. If your help desk continually receives calls about users unable to find a specific button on your website, for example, then you have some evidence of a bad user experience.

Do some research

Ask your coworkers what they know about prototyping. Ask if they have ever experimented with any prototyping tools.

Ask your end users about the content on your site. Gather some information about just how bad the user experience really is.

This is not the time to pitch your idea. You are in complete listening/observation mode. Save the elevator pitch for later, when you have all the information and are confident this is the right solution to a very specific problem and you are prepared to answer the questions that will come.

Assess your tools

Are there any tools you use now that are similar to the tool you are proposing? If so, what are their benefits and downfalls?

Take the UXPin example. Does your team use paper to do prototypes right now? Does the graphic designer use Photoshop to start with wireframes/prototypes before doing a high-res layout?

Having a ready list of pros and cons for the tools you currently use will help you build a case around why your solution is superior and will show that you’ve done your homework.

Check your ego

Scrutinize your motivations for wanting to introduce a new tool. Do you want to try something new just to take control of a situation? If the graphic designer does a fine job using Photoshop to develop a prototype but you don’t know how to use Photoshop, that’s not a great reason to try a new tool.

However, if you have a team of six and only one person knows how to use Photoshop, choosing a more accessible tool with a shorter learning curve could be the right move.

Explore other solutions

Are there other tools out there that will solve the problem you discovered?
If you don’t yet have room in the budget for UXPin, can something else get you by while you prove the value of this type of tool? can you use paper prototypes for a few months while the team adjusts to this new part of their workflow?

Sometimes starting with something less complex can be beneficial. Anyone can use pen and paper, but learning new software can be daunting and time-consuming.

Still think this is an awesome idea?

You now understand the tangible benefits of implementing your innovative idea and you know who stands to gain from it. You can foresee both the rewards of implementing it and the potential risks of not implementing it.

Your motives are good, you’ve analyzed your current situation for similar tools or processes that may already be in place, and you’ve explored other potential solutions. You are well on your way to building a strong case around your innovative idea. At this point, you’ve put a lot of time and effort into developing it. Do you still think it’s a good idea, and are you as excited as you were when you started?

If you’ve lost your drive and excitement at this point, or have been unable to visualize any real benefit, the idea may not be worth implementing. That’s okay. The way you will land on a really great idea is by testing many not-so-great ideas until you find one that fits.

Your continued excitement and drive will be necessary as you start to implement your idea and work toward gaining supporters.

Start small and fail as soon as possible

Even if you’re still quite sure this idea is amazing, start small and keep an open mind. A thousand questions will come to mind as you begin using an actual product with real users.

As you start running a couple of tests, use language like “experiment” instead of “implementation.” This leaves room for error and growth. You want to know what’s not going to work as much as you want to know what is going to work. And if someone asks what you’re doing, it sounds way more innocent if you say you’re running a few experiments that you’re going to share with the team than if you say you’re implementing a prototyping tool into our web development process.

If you’re working on a current website project, try creating just one page using the prototyping tool on your own time, not as a part of the official project process. See how it goes building just one page for now. Even better, try making just one element of the page, like the header or navigation. By starting small you will have fewer variables to take into consideration. Remember, right now you’re evaluating the tool itself, not necessarily the user experience of your website.

Then take your prototype and see what kind of feedback you can get by testing it with real end users.

Is the prototype responsive? What URL did you need to use to access it? Was it easy to direct users to this URL? Can you record mouse movements or clicks, and do you need to? How are you documenting their feedback to the site? Were they able to use their own device, or did you need to provide it? What are you going to do with the feedback and observations you’ve gained?

Do several tiny experiments like this, making adjustments as you go, until you’re more comfortable with the tool, its features, and the results you get from it. Your confidence with the tool will give your team confidence with it as well.

Don’t get fired

Most companies don’t mind their employees doing research about their work on company time. Unfortunately, some do mind. Using your own device on your lunch hour or before and after work may be your only option.

Even if your job does allow you to research and learn on the clock, be respectful of time. Spending several months straight iterating on one idea might not be good for your next employee review. 3M designates 15 percent time for employees to focus on innovation; Google has famously allowed up to 20 percent of employee time to focus on new innovative ideas. Try to gauge what percentage of time you could reasonably spend on your research without neglecting your real job.

Be transparent about what you’re doing. Hiding it and sneaking around will give the wrong impression. Let your boss know you’re curious about a new tool and you’re just running a few experiments to explore it more. Curious, experiment, explore—as I suggested earlier, these are all safe words implying no level of commitment or pressure.

Win allies

Presumably you have a few friends in the office; take them out to lunch and toss them the idea. Let them know about the experiments you’re running and the results you’re getting. Ask if they want to see what you’ve been working on.

It might take a while for anyone to show some interest. Don’t give up if your excitement isn’t mirrored immediately and don’t be pushy. Remember, you want your colleagues to be in your corner.

Also, bouncing your idea off your coworkers is great practice for telling your boss. Your coworkers will definitely ask you a bunch of questions you haven’t thought of yet and will express viewpoints you haven’t considered.

Listen to their opposition and use their concerns to build your case. Do they think adding a new tool to the workflow will slow down the process? Explore that concern; next time you talk, offer some data and insight about how that assumption might not be true.

Having your team on your side will go a long way when presenting this to your boss, but it doesn’t have to be a deal-breaker if they’re not. Sometimes our coworkers are just so scared of change that no amount of data will make them comfortable. They will likely express their concerns when you bring your idea up in front of the boss; having a prepared response makes you look confident.

Get your boss’ support

Time to go up a level. Please do not put together a giant presentation, wear your best power suite, and pour your heart out onto the line. If your experience is anything like mine, you’ll just spend the rest of the day crying off and on in the bathroom.

A definitive, polished presentation can be offputting. It makes you look like you’ve already solved the whole problem. You want to appear open to suggestions—because you are.

The approach

You know your relationship with your boss, and how to approach them, better than anyone else. For me, the best way is to wait for the right opening and mention the new idea in passing. Be prepared to show all of your progress and make some sort of proposal right on the spot. Make it seem easy and low-risk, with clear next steps. I’ve found it beneficial to address the concerns of your team up front to show you value their opinion and input. Bosses love teamwork.

If there isn’t clear interest from your boss, ask them what other data or information they would like to see to help support this idea. What are their concerns or hesitations?

At this point, consider asking for permission to continue to experiment on a broader level. The word “implement” really freaks people out. Trying a prototyping tool in the web-development process for three months instead of implementing it forever sounds a lot less risky.

Persevere

If you can’t stick with your idea long enough to do some research and run some experiments, why should anyone else? If it truly matters to you and you can see your idea making a real change in your company or within your work environment, hang in there for the long haul.

When the graphic designers agree to use UXpin as a prototyping tool and the User Experience team (if you’re lucky enough to have a UX team, really I’m not jealous) says they will give it a try for end user testing, ask to be a part of their process. Ask them to invite you to the end-user testing sessions and the design reviews with the stakeholders.

Be in those sessions and meetings as the the idea is implemented so you can continue to reference your personas and make sure decisions are made for the right reasons. That way, you’ll be in the front row to see positive change happen as you guide your idea and hard work into something truly innovative.

As your idea starts to gain traction and your experiments turn into a real process—see things through. Don’t just hand off your idea and hope for the best like a child waiting for the school bus. Drive the damn bus.

 

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Tuesday – Session 3

Planet Linux Australia - Tue 17th Jan 2017 19:01

The Internet of Scary Things – tips to deploy and manage IoT safely Christopher Biggs

  • What you need to know about the Toaster Apocalypse
  • Late 2016 brought to prominence when major sites hit by DDOS from compromised devices
  • Risks present of grabbing images
    • Targeted intrusion
    • Indiscriminate harvesting of images
    • Drive-by pervs
    • State actors
  • Unorthorized control
    • Hit traffic lights, doorbells
  • Takeover of entire devices
    • Used for DDOS
    • Demanding payment for the owner to get control of them back.
  • “The firewall doesn’t divide the scary Internet from the safe LAN, the monsters are in the room”

 

  • Poor Security
    • Mostly just lazyness and bad practices
    • Hard for end-users to configure (especially non-techies)
    • Similar to how servers and Internet software, PCs were 20 years ago
  • Low Interop
    • Everyone uses own cloud services
    • Only just started getting common protocols and stds
  • Limited Maint
    • No support, no updates, no patches
  • Security is Hard
  • Laziness
    • Threat service is too large
    • Telnet is too easy for devs
    • Most things don’t need full Linux installs
  • No incentives
    • Owner might not even notice if compromised
    • No incentive for vendors to make them better

 

  • Examples
    • Cameras with telenet open, default passwords (that can not be changed)
    • exe to access
    • Send UDP to enable a telnet port
    • Bad Mobile apps

 

  • Selecting a device
    • Accept you will get bad ones, will have to return
    • Scan your own network, you might not know something is even wifi enabled
    • Port scan devices
    • Stick with the “Big 3” ramework ( Apple, Google, Amazon )
    • Make sure it supports open protocols (indicates serious vendor)
    • Check if open source firmward or clients exists
    • Check for reviews (especially nagative) or teardowns

 

  • Defensive arch
    • Put on it’s own network
    • Turn off or block uPNP opening firewall holes
    • Plan for breaches
      • Firewall rules, rate limited, recheck now and then
    • BYO cloud (dont use the vendor cloud)
      • HomeBridge
      • Node-RED (Alexa)
      • Zoneminder, Motion for cameras
  • Advice for devs
    • Apple HomeKit (or at least support for Homebridge for less commercial)
    • Amazon Alexa and AWS IoT
      • Protocols open but look nice
    • UCF uPnP and SNP profiles
      • Device discovery and self discovery
      • Ref implimentations availabel
    • NoApp setup as an alternative
      • Have an API
    • Support MQTT
    • Long Term support
      • Put copy of docs in device
      • Decide up from what and how long you will support and be up front
    • Limit what you put on the device
      • Don’t just ship a Unix PC
      • Take out debug stuff when you ship

 

  • Trends
    • Standards
      • BITAG
      • Open Connectivity founddation
      • Regulation?
    • Google Internet of things
    • Apple HomeHit
    • Amazon Alexa
      • Worry about privacy
    • Open Connectivity Foundation – IoTivity
    • Resin.io
      • Open source etc
      • Linux and Docket based
    • Consumer IDS – FingBox
  • Missing
    • Network access policy framework shipped
    • Initial network authentication
    • Vulnerbility alerting
    • Patch distribution

Rage Against the Ghost in the Machine – Lilly Ryan

  • What is a Ghost?
    • The split between the mind and the body (dualism)
    • The thing that makes you you, seperate to the meat of your body
  • Privacy
    • Privacy for information not physcial
    • The mind has been a private place
    • eg “you might have thought about robbing a bank”
    • The thoughts we express are what what is public.
    • Always been private since we never had technology to get in there
    • Companies and governments can look into your mind via things like your google queries
    • We can emulate the inner person not just the outer expression
  • How to Summon a Ghost
    • Digital re-creation of a person by a bot or another machine
    • Take information that post online
    • Likes on facebook, length of time between clicks
  • Ecto-meta-data
    • Take meta data and create something like you that interacts
  • The Smartphone
    • Collects meta-data that doesn’t get posted publicly
    • deleted documents
    • editing of stuff
    • search history
    • patten of jumping between apps
  • The Public meta-data that you don’t explicitly publish
    • Future could emulate you sum of oyu public bahavour
  • What do we do with a ghost?
    • Create chatbots or online profiles that emulate a person
    • Talk to a Ghost of yourself
    • Put a Ghost to work. They 3rd party owns the data
    • Customer service bot, PA
    • Chris Helmsworth could be your PA
    • Money will go to facebook or Google
  • Less legal stuff
    • Information can leak from big companies
  • How to Banish a Ghost
    • Option to donating to the future
    • currently no regulation or code of conduct
    • Restrict data you send out
      • Don’t use the Internet
      • Be anonymous
      • Hard to do when cookies match you across many sites
        • You can install cookie blocker
    • Which networks you connect to
      • eg list of Wifi networks match you with places and people
      • Mobile network streams location data
      • location data reveals not just where you go but what stores, houses or people you are near
      • Turn off wifi, bluetooth or data when you are not using. Use VPNs
    • Law
      • Lobby and push politicians
      • Push back on comapnies
    • For technologiest
      • Collect the minimum, not the maximum

FreeIPA project update (turbo talk) – Fraser Tweedale

  • Central Identity manager
  • Ldap + Kerberos, CA, DNS, admin tools, client. Hooks into AD
  • NAnage via web or client
  • Client SSSD. Used by various distros
  • What is in the next release
    • Sub-CAs
    • Can require 2FA for important serices
    • KDC Proxy
    • Network bound encryption. ie Needs to talk to local server to unencrypt a disk
    • User Session recording

 

Minimum viable magic

Politely socially engineering IRL using sneaky magician techniques – Alexander Hogue

  • Puttign things up your sleeve is actually hard
  • Minimum viable magic
  • Miss-direct the eyes
  • Eyes only move in a straight line
  • Exploit pattern recognition
  • Exploit the spot light
  • Your attention is a resource

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Tuesday – Session 3

Planet Linux Australia - Tue 17th Jan 2017 19:01

The Internet of Scary Things – tips to deploy and manage IoT safely Christopher Biggs

  • What you need to know about the Toaster Apocalypse
  • Late 2016 brought to prominence when major sites hit by DDOS from compromised devices
  • Risks present of grabbing images
    • Targeted intrusion
    • Indiscriminate harvesting of images
    • Drive-by pervs
    • State actors
  • Unorthorized control
    • Hit traffic lights, doorbells
  • Takeover of entire devices
    • Used for DDOS
    • Demanding payment for the owner to get control of them back.
  • “The firewall doesn’t divide the scary Internet from the safe LAN, the monsters are in the room”

 

  • Poor Security
    • Mostly just lazyness and bad practices
    • Hard for end-users to configure (especially non-techies)
    • Similar to how servers and Internet software, PCs were 20 years ago
  • Low Interop
    • Everyone uses own cloud services
    • Only just started getting common protocols and stds
  • Limited Maint
    • No support, no updates, no patches
  • Security is Hard
  • Laziness
    • Threat service is too large
    • Telnet is too easy for devs
    • Most things don’t need full Linux installs
  • No incentives
    • Owner might not even notice if compromised
    • No incentive for vendors to make them better

 

  • Examples
    • Cameras with telenet open, default passwords (that can not be changed)
    • exe to access
    • Send UDP to enable a telnet port
    • Bad Mobile apps

 

  • Selecting a device
    • Accept you will get bad ones, will have to return
    • Scan your own network, you might not know something is even wifi enabled
    • Port scan devices
    • Stick with the “Big 3” ramework ( Apple, Google, Amazon )
    • Make sure it supports open protocols (indicates serious vendor)
    • Check if open source firmward or clients exists
    • Check for reviews (especially nagative) or teardowns

 

  • Defensive arch
    • Put on it’s own network
    • Turn off or block uPNP opening firewall holes
    • Plan for breaches
      • Firewall rules, rate limited, recheck now and then
    • BYO cloud (dont use the vendor cloud)
      • HomeBridge
      • Node-RED (Alexa)
      • Zoneminder, Motion for cameras
  • Advice for devs
    • Apple HomeKit (or at least support for Homebridge for less commercial)
    • Amazon Alexa and AWS IoT
      • Protocols open but look nice
    • UCF uPnP and SNP profiles
      • Device discovery and self discovery
      • Ref implimentations availabel
    • NoApp setup as an alternative
      • Have an API
    • Support MQTT
    • Long Term support
      • Put copy of docs in device
      • Decide up from what and how long you will support and be up front
    • Limit what you put on the device
      • Don’t just ship a Unix PC
      • Take out debug stuff when you ship

 

  • Trends
    • Standards
      • BITAG
      • Open Connectivity founddation
      • Regulation?
    • Google Internet of things
    • Apple HomeHit
    • Amazon Alexa
      • Worry about privacy
    • Open Connectivity Foundation – IoTivity
    • Resin.io
      • Open source etc
      • Linux and Docket based
    • Consumer IDS – FingBox
  • Missing
    • Network access policy framework shipped
    • Initial network authentication
    • Vulnerbility alerting
    • Patch distribution

Rage Against the Ghost in the Machine – Lilly Ryan

  • What is a Ghost?
    • The split between the mind and the body (dualism)
    • The thing that makes you you, seperate to the meat of your body
  • Privacy
    • Privacy for information not physcial
    • The mind has been a private place
    • eg “you might have thought about robbing a bank”
    • The thoughts we express are what what is public.
    • Always been private since we never had technology to get in there
    • Companies and governments can look into your mind via things like your google queries
    • We can emulate the inner person not just the outer expression
  • How to Summon a Ghost
    • Digital re-creation of a person by a bot or another machine
    • Take information that post online
    • Likes on facebook, length of time between clicks
  • Ecto-meta-data
    • Take meta data and create something like you that interacts
  • The Smartphone
    • Collects meta-data that doesn’t get posted publicly
    • deleted documents
    • editing of stuff
    • search history
    • patten of jumping between apps
  • The Public meta-data that you don’t explicitly publish
    • Future could emulate you sum of oyu public bahavour
  • What do we do with a ghost?
    • Create chatbots or online profiles that emulate a person
    • Talk to a Ghost of yourself
    • Put a Ghost to work. They 3rd party owns the data
    • Customer service bot, PA
    • Chris Helmsworth could be your PA
    • Money will go to facebook or Google
  • Less legal stuff
    • Information can leak from big companies
  • How to Banish a Ghost
    • Option to donating to the future
    • currently no regulation or code of conduct
    • Restrict data you send out
      • Don’t use the Internet
      • Be anonymous
      • Hard to do when cookies match you across many sites
        • You can install cookie blocker
    • Which networks you connect to
      • eg list of Wifi networks match you with places and people
      • Mobile network streams location data
      • location data reveals not just where you go but what stores, houses or people you are near
      • Turn off wifi, bluetooth or data when you are not using. Use VPNs
    • Law
      • Lobby and push politicians
      • Push back on comapnies
    • For technologiest
      • Collect the minimum, not the maximum

FreeIPA project update (turbo talk) – Fraser Tweedale

  • Central Identity manager
  • Ldap + Kerberos, CA, DNS, admin tools, client. Hooks into AD
  • NAnage via web or client
  • Client SSSD. Used by various distros
  • What is in the next release
    • Sub-CAs
    • Can require 2FA for important serices
    • KDC Proxy
    • Network bound encryption. ie Needs to talk to local server to unencrypt a disk
    • User Session recording

 

Minimum viable magic

Politely socially engineering IRL using sneaky magician techniques – Alexander Hogue

  • Puttign things up your sleeve is actually hard
  • Minimum viable magic
  • Miss-direct the eyes
  • Eyes only move in a straight line
  • Exploit pattern recognition
  • Exploit the spot light
  • Your attention is a resource

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Tuesday – Session 2

Planet Linux Australia - Tue 17th Jan 2017 15:01

Stephen King’s practical advice for tech writers – Rikki Endsley

  • Example What and Whys
    • Blog post, press release, talk to managers, tell devs the process
    • 3 types of readers: Lay, Managerial, Experts
  • Resources:
    • Press: The care and Feeding of the Press – Esther Schindler
    • Documentation: RTFM? How to write a manual worth reading

 

  • “On Writing: A memoir of the craft” by Stephen King
  • Good writing requires reading
    • You need to read what others in your area or topic or competition are writing
  • Be clear on Expectations
    • See examples
    • Howto Articles by others
    • Writing an Excellent Post-Event Wrap Up report by Leslie Hawthorn
  • Writing for the Expert Audience
    • New Process for acceptance of new modules in Extras – Greg DeKoenigserg (Ansible)
    • vs Ansible Extras Modules + You – Robyn Bergeon
      • Defines audience in the intro

 

  • Invite the reader in
  • Opening Line should Invite the reader to begin the story
  • Put in an explitit outline at the start

 

  • Tell a story
  • That is the object of the exercise
  • Don’t do other stuff

 

  • Leave out the boring parts
  • Just provides links to the details
  • But sometimes if people not experts you need to provide more detail

 

  • Sample outline
    • Intro (invite reader in)
    • Brief background
    • Share the news (explain solution)
    • Conclude (include important dates)

 

  • Sample Outline: Technical articles
  • Include a “get technical” section after the news.
  • Too much stuff to copy all down, see slides

 

  • To edit is divine
  • Come back and look at it afterwards
  • Get somebody who will be honest to do this

 

  • Write for OpenSource.com
  • opensource.com/story

 

  • Q: How do you deal with skimmers?   A: Structure, headers
  • Q: Pet Peeves?  A: Strong intro, People using “very” or “some” , Leaving out import stuff

 

 

Share

Categories: thinktime

Simon Lyall: Linux.conf.au 2017 – Tuesday – Session 2

Planet Linux Australia - Tue 17th Jan 2017 15:01

Stephen King’s practical advice for tech writers – Rikki Endsley

  • Example What and Whys
    • Blog post, press release, talk to managers, tell devs the process
    • 3 types of readers: Lay, Managerial, Experts
  • Resources:
    • Press: The care and Feeding of the Press – Esther Schindler
    • Documentation: RTFM? How to write a manual worth reading

 

  • “On Writing: A memoir of the craft” by Stephen King
  • Good writing requires reading
    • You need to read what others in your area or topic or competition are writing
  • Be clear on Expectations
    • See examples
    • Howto Articles by others
    • Writing an Excellent Post-Event Wrap Up report by Leslie Hawthorn
  • Writing for the Expert Audience
    • New Process for acceptance of new modules in Extras – Greg DeKoenigserg (Ansible)
    • vs Ansible Extras Modules + You – Robyn Bergeon
      • Defines audience in the intro

 

  • Invite the reader in
  • Opening Line should Invite the reader to begin the story
  • Put in an explitit outline at the start

 

  • Tell a story
  • That is the object of the exercise
  • Don’t do other stuff

 

  • Leave out the boring parts
  • Just provides links to the details
  • But sometimes if people not experts you need to provide more detail

 

  • Sample outline
    • Intro (invite reader in)
    • Brief background
    • Share the news (explain solution)
    • Conclude (include important dates)

 

  • Sample Outline: Technical articles
  • Include a “get technical” section after the news.
  • Too much stuff to copy all down, see slides

 

  • To edit is divine
  • Come back and look at it afterwards
  • Get somebody who will be honest to do this

 

  • Write for OpenSource.com
  • opensource.com/story

 

  • Q: How do you deal with skimmers?   A: Structure, headers
  • Q: Pet Peeves?  A: Strong intro, People using “very” or “some” , Leaving out import stuff

 

 

Share

Categories: thinktime

Pages

Subscribe to kattekrab aggregator