Rolandt

It’s a secret to everyone! This post is for RSS subscribers only. Read more about RSS Club.

See the Pen Prompts Prototype by Dave Rupert (@davatron5000) on CodePen.

This week I built a prototype for a brand new drawing app idea. I’m calling it “Prompts”, it already leaked on CodePen (sorry!) but I wanted to give you, Dear Reader, a behind the scenes look at the progress so far.

For a couple years now, I’ve wanted an Inktober-inspired app that would present a random drawing prompt and would work on any touchscreen device with finger or stylus input. I’d love to make drawing (even digital, which goes against the spirit of Inktober) a daily practice in my life. After reading about this years’ Inktober before it actually started (I usually think of this on October 10th), I was inspired to finally go for it. On Thursday evening, I began development by breaking the app into its core features:

1. A drawing surface
2. A prompt mechanism
3. A little bit of UI

Simple enough. Let’s do each piece.

A drawing surface

I’ve done enough canvas work to know I didn’t want to do this from scratch so I searched though npm and came a cross Signature Pad from Szymon Nowak. As evident by the project name, this is a little utility for capturing signatures on official documents. What’s novel about this particular solution is that it samples points (like an SVG) at a regular interval and then creates Bézier curves between them. The result is an ink-like feel where faster strokes have thinner, stretchier lines. It’s not the most sophisticated drawing app, but it fits nicely with the ethos.

It was kind of a pain in the ass to get <canvas> to be responsive because it behaves more like PNG once painted. Thankfully, because Signature Pad keeps an array of x,y points on hand, when resizing so I can wipe out the entire canvas and restore the data on resize. 🙌

Testing on real touchscreen devices I experienced some performance issues where the pixels were trailing behind your finger and stylus a bit. I did a mini-dive on low-latency canvas performance I was pleased to find out about a new feature in Chrome 75 for low-latency canvas rendering using desynchronized. Latency in drawing applications is specifically mentioned in the first paragraph:

Stylus-based drawing applications built for the web have long suffered from latency issues because a web page has to synchronize graphics updates with the DOM. In any drawing application, latencies longer than 50 milliseconds can interfere with a user’s hand-eye coordination, making applications difficult to use.

Fifty milliseconds is a tough threshold to hit. Watching Brad Colbow’s drawing app reviews on YouTube I’m keenly aware of the importance of this latency issue. Most of his device and app reviews make or break it based on that. Here’s an older 2012 video from Microsoft about the impact of 100ms, 50ms, 10ms, and even 1ms of touch input latency.

I started diving into the source of Signature Pad to see if I could maybe make a contribution to add this new progressively enhanced feature. However, the core of Signature Pad is written in Typescript so that sort of shut down that exploration. Not because I don’t necessarily want to work with Typescript, but mostly because it would pull me out of CodePen and force me to build out some intensive local environment with a Typescript build pipeline and then some deployment strategy to test on actual devices just to validate my idea.

Stalling progress here is actually the opposite of what I want to do when prototyping. Knowing that I can potentially fix it later is good enough for right now. It’s important not to get bogged down here, because I want to get to First Playable.

A prompt mechanism

The prompt mechanism was pretty simple, just an array of words. I “borrowed” the actual 2019 Inktober rules but that’s only temporary as I test things out.

Simple enough. On larger landscape devices (tablet/desktop), I actually used CSS Grid and the golden ratio to do the layout. That’s lolzy but actually fit better than all the fixed values I tried.

In the future I could probably make some service that gets a Word of the Day or a random word… I’ll sit and think on that for a bit, I don’t need to know now.

A little bit of UI

The UI is pretty simple enough. I decided I wanted a couple of core actions as features:

1. Undo
2. Erase
3. Left-handed mode

The first two are self-explanatory on a drawing app, but the third one was something I felt was an important bit of accessibility to have the UI be “flippable”. This is currently just flipping direction: rtl in the CSS. That’s maybe not the best choice, but again, getting to First Playable is what I’m after here.

Next steps

It’s important I don’t get ahead of myself, but I think there’s a few next immediate steps:

1. Move this to my own domain and make it a proper PWA
2. Create icons and whatnot for homescreen launching

After those somewhat simple fixes I have a few ideas but I’d like those features to be informed by actual user testing:

1. Add a sharing function so I can go viral on social media?
2. Save a drawing history and add authentication in something like Firebase?
3. Do I need an instructional modal on first launch?
4. Do I need to improve the latency still?
5. Should I put this on an app store with ads?

The latency issue may be a lot less critical than I originally thought it was. I realized once I fixed up some of my CSS issues the drawing performance got a lot better. What I thought was latency was really a weird max-width issue. Which goes to show, I was right to not “over-solve” the latency issue when I first encountered it. It may not be an issue at all.

What I really need to do next is get some real world feedback. If you’re able to head over to the super-secret debug URL, try it out on your devices, and let me know how it works for you! Is it neat? Would you pay money for it? Would your cousin play money for it? I’d love to hear your thoughts. Thanks.

Rumours have been circulating for weeks that Apple has plans to release its own tiny Bluetooth tracking device.

Apart from likely featuring the standard sleek Apple aesthetic, a new report courtesy of notable Apple analyst Ming-Chi Kuo, as first covered by MacRumors, indicates that the company’s upcoming circular tags will be capable of more precise tracking than current Bluetooth-powered devices thanks to ‘ultra-wideband technology’ (UWB).

In comparison, devices from Tile and other companies utilize Bluetooth low-energy technology for tracking.

Kuo goes on to state that he expects all three 2019 iPhones to feature UWB. Given this would result in the trackers only being compatible with a limited number of Apple’s devices, it’s likely the rumoured tags will also work over Bluetooth low-energy in order to be compatible with older iPhones, iPads and Macs.

Apple’s new Bluetooth tracker is expected to be integrated into the company’s upcoming iOS 13 ‘Find My’ app that combines the current ‘Find My iPhone’ and ‘Find My Friends’ apps.

The tech giant’s upcoming fall hardware event is just around the corner, so we won’t have to wait much longer to learn more about Apple’s rumoured tracking device.

Source: MacRumors

The post ‘Apple Tags’ will reportedly be more precise than current Bluetooth trackers appeared first on MobileSyrup.

While it's been called a mindset, method, methodology, umbrella term for lightweight methods, manifesto, process or framework, agile is an adjective (an agile dancer, an agile team, an agile dog). It means "characterized by a ready ability to move with quick easy grace" or "having a quick, resourceful and adaptable character." If you're interested in continuously improving, this adjective sets a high bar. For me, the definitions of agile come before any agile principles or practices. They are our starting point:

The principles I list in the above image come from modernagile. You could easily substitute Heart of Agile. At a recent client, they selected their own agile principles.

The above image is also inspired from the original by Ahmed Sidkey:

Ahmed's image describes agile as a mindset and says that the mindset is described by the values and principles of the Manifesto for Agile Software Development. This is a useful view as well. So why did I chose to make a derivative version?

I like the word mindset. It's defined as "a mental attitude or inclination." An agile attitude or inclination is good, yet I see agile as more of a skill, something we need to develop. The adjective conveys that well.

I find the Manifesto for Agile Software Development to be enormously helpful and yet it's not something I show to non-technical people, like the good folks developing new medicines at a recent Industrial Logic client. They need agile language that applies to their world, not software development. This means that the four values (including "Working software over comprehensive documentation") and twelve principles aren't quite a good fit. Of course, there are values and principles that are not associated with software, yet the mere mention of software to non-software people can often turn them off.

So that's it. Agile is an adjective, guided by principles and realized in unlimited ways. I hope the graphic is helpful. As always, I'd love to hear your thoughts and comments, suggestions for improvement, etc.

The post Agile is an Adjective appeared first on Industrial Logic.

Looking back over the year so far, by far and away the most profound experience I’ve had came at the closing supper of Crafting {:} a Life, where my friend Elmine read a story, fresh that day from her intensely creative mind, titled The Oodlanders.

I am not one to break down in tears. And I am certainly not one to break down in tears in public.

But I did that night as Elmine read.

I’m still gutted where I listen to it now, on this web page where she’s posted an updated reading, along with the downloadable text.

In the afterword, Elmine wrote:

Though real life events may have been the inspiration for writing this story, it is of course a work of fiction. Any resemblance of its characters to people known to me is purely accidental. Or not.

Or not.

Indeed.

I’ve always been a quiet person who prefers to observe and slowly think things through. At Eyeo this year, I talked about how these tendencies led to FlowingData.

Be sure to check out the other talks. There’s a lot of inspiration and information to absorb.

Tags: eyeo, talk

Take-away: a Sonos Play One would be able to use AirPlay 2, if it was built after the 2017 silent refresh.

An intensive week, so I’m keeping this short:

• Spent a day working for a province
• Spent a day for another province doing an impact assessment of the implementation a data register, as first step of a procurement path we are assisting with
• Wednesday I left for Copenhagen where the Techfestival was taking place until Saturday evening. I went seeking inspiration, in search of putting words to a certain sense of urgency I suppose. As part of that I
  • Took part in a full day ‘public data summit’ where we dived deeper into how to use open data for urgent societal topics, such as climate adaptation
  • Met up with various people, some I hadn’t seen in years. It was good to just hang out, share food, experiences, and thoughts
  • Took lots of notes, thousands of words, still in need of some processing
  • Listened to a very good key-note by Aza Raskin
  • Enjoyed an excellent on-stage conversation between Marietje Schaake (former MEP, now at Stanford) and Casper Klynge, the world’s first and Danish Ambassador to the tech industry, of which I hope a video will be available soon. I didn’t take notes, as I wanted to listen, not in that moment reflect or take observational distance
  • Participated 20 out of 24 hours in the think tank Copenhagen 150. An intensive and fun experience, with a wide variety of highly fascinating people, under the Chatham House rule. More on this and the other things later. Results to be announced.
  • Saturday afternoon I left Techfestival and the Copenhagen 150 early. This to get to Sittard, 2.5 hours to the south-east of Schiphol airport in Limburg, just before 19:00
• Saturday evening we celebrated our dear friend M’s 50th birthday in a restaurant in Sittard‘s 14th century city center. None of the 11 of us around the table live anywhere near Sittard, E and I live closest having come 170kms, and half came all the way from Switzerland including M herself. M and H used to live in Sittard, and we all returned for once. We all go back at least 25 years, from when we were all at university, and room mates in various constellations. M said she felt privileged to have all of us around the table last night. She’s right, and all of us realised it.

36 by Andy Maguire, license CC-BY

Grainry, Granville Island

(For full image, click on title.)

Pan flutes by Edgar Manuela, Granville Island.

The sound of Muenala`s pan flutes vibrating in the reverberating spaces of the Granville Bridge will always be the sound of Granville Island for many. The Ecuadorian has been playing those spaces below the bridge for … how long?

(For full image, click on title.)

The Blue Parrot, Granville Island

A fall afternoon in 1979; Granville Island had recently opened.  A year earlier I had arrived from Victoria.

Sitting exactly here with an unexpected view, sipping one of my first espressos, looking out on to a still-industrial creek False Creek, watching boats and people, I thought: Yup, this is the right place.

(For full image, click on title.)

Last Christmas, having decided to act on last year’s Summer resolution and gotten myself a new MIDI keyboard, I also started wading through the Mac and iOS DAW ecosystems. With a year gone by since the whole thing began, and with my vacation mere hours away from ending, I guess it’s time for a little status update.

So let’s step out from the realm of cloud infrastructure and applications and coding and whatnot for a bit. As usual, it’s been a learning experience for me, and I’m not even going to say much about the actual music and the way I’ve had to tackle a fundamentally different skill, because that’s still ongoing.

Instead, like any engineer, I’m going to rant on about hardware and tools for a bit as I try to put together in my mind what sort of new processes I need for “solving” this…

Throwing Hardware at a Skills Problem

As a sort of quasi-Christmas present, I splurged on a ROLI Songmaker Kit. It was both a way to commit myself to getting into music through an actual investment (the thing is reasonably expensive, and I would likely not have taken the plunge if it were not on sale) and a cathartic release due to my long fascination for the hardware itself.

Even though it’s trivial to get velocity-sensitive keyboards these days, I wanted to experience the physicality of it in much the same way I savor the difference between plastic keys and the lovely weighted keyboard of our Clavinova, and I can tell you right away that from a hardware perspective, it did not disappoint–not only is the Seaboard two-octave keyboard extremely expressive and pretty amazing, but the Lightpad block turned out to be surprisingly entertaining in its own right.

The modular approach works perfectly, and being able to plug in a bunch of separate modules via a single cable (or Bluetooth connection) is great, to the point where their Lumi Kickstarter will eventually be making its way to my desktop setup.

But after a while I realised I needed to step back focus a bit more on the basics. Let’s see if I can explain why:

The Trouble With ROLI

What I eventually figured out was that physical (and family) context matters. Since I have a home office and work regularly from it, spending my evenings there has become less and less appealing over the years, to the point where I prefer to sit around the house with an iPad for writing and doing personal e-mail rather than bask in the glory of my 27” iMac, its satellite displays and sprawling desk lint of assorted electronics.

And yet I found I can only really get the best out of the SongMaker Kit with a Mac, and on a desk.

Yes, the form factor and carrying case are great for (theoretically) using it on the go, but in practice the full SongMaker Kit is a tad too heavy to carry around without qualms (especially when compared to what an iPad weighs).

But the biggest drawback for me so far is that ROLI’s iOS software support is depressingly limited. Even though Noise is a lot of fun, it all works better on macOS: GarageBand integration, their Equator synth (which has no iOS equivalent) and even the configuration apps all target macOS, which means that you’re somewhat on your own if you want to use the kit on iOS.

And I’d rather spend most of my evening leisure time (all of two hours at most) on a couch instead of at a desk, which in turn means using my iMac or my laptop to run GarageBand is a rare event (except on weekends, which are crowded enough). During that time, I really like using my iPad instead, and ROLI’s software simply isn’t there, not in a meaningful way.

I did find an excellent third-party app called Block Dashboard that I use to configure the Lightpad block. But it is precisely the kind of essential tool I would expect ROLI to have shipped by now.

Instead, like most other software on iOS, their apps seem focused on selling content packs via in-app purchases (which is likely to be a sustainable way to drive up revenue atop hardware sales), and even though ROLI is ahead of its time where it regards MPE (which is poorly supported on iOS software), in the end I decided I needed something that was a better fit for my daily rhythm and decided try a different tack.

KORG nanoKEY Studio

After looking at simpler controllers like the AKAI Mini MKII series (which are very popular but lack Bluetooth variants), I eventually went for the time-honored (and frequently discounted) KORG nanoKEY Studio, which is “unapologetically plastic”, incredibly lightweight and can be left unattended on a couch without qualms.

It is also well-supported by a lot of iOS software, which includes mapping the eight knobs and X/Y controller to synth controls on many iOS apps that support MIDI automation. But the important thing is that I can sit on the couch and noodle away on it without much hassle, so it’s become my go-to piece of kit.

The Software Side

Despite my qualms about spending even more time squirrelled away in my home office, I did manage to fool around with GarageBand and Ableton Live Lite on my 27” iMac, which really makes a difference when I want to play around with audio processing (especially since my iPad is still the long-suffering mini 4, and tends to choke when doing anything very CPU-intensive).

I’m not far along this road yet, but right now I have no real ability to move anything but the most basic stuff between iOS and macOS. GarageBand is still borderline unhelpful (since you can move your projects “up” to macOS, and you do get prompts that certain software instruments won’t be available in iOS), but otherwise you have to move raw audio and MIDI around manually.

I’m not especially fond of Live either at this point (largely because overall I have only managed to scrounge together the equivalent of a few full afternoons with it), but I am getting used to the differences in philosophy and workflows, and things like the Ableton Push Controller now make a lot more sense to me.

I don’t think I will be investing heavily in Live since I am rather more likely to go for Logic if I ever need a “pro” desktop DAW, and having access to most of its patches with MainStage I have little incentive to throw more money at what is still a (very) time-constrained hobby, but mastering a completely new skill that has zero relationship to what I do daily is the entire point here, so it’s all good.

iOS DAWs

The one thing that I have learned over the past year or so is that the iOS digital audio ecosystem is still steadily in the post-explosion stage, with hundreds of pieces of software vying for attention, and it takes a long time to sort through all of them–time that is much better spent studying music theory and practising.

But it is so much fun. For instance, if you want one fun piece of iOS software to try, I strongly suggest Xynthesiser, which is an absolutely amazing all-in-one sequencer/synth combo that has taken some of the dreariness out of my long train trips on the job.

On a broader note, there are a few interesting trends I’ve noticed ever since I started paying attention:

• There is a huge long tail of outdated and unmaintained software out there (especially standalone synths)
• Most DAWs (Cubasis, Gadget, etc.) have cyclic price cuts for the core software that they appear to be offsetting with more in-app purchases
• There is a complementary trend towards everything becoming an Audio Unit (be it synths or effects units), which means you’re not limited to those aforesaid in-app purchases (since DAWs are increasingly moving to support AUv3)
• Besides AUv3, things like MIDI learn and MPE (MIDI Poliphonic Expression) support are now de rigueur for new software, even if the latter is still a bit thin on the ground.

But picking up where I left off at the end of the last installment, I spent a while trying out other iOS DAWs (as well as a bunch of synths, but I won’t bore you with those this time around):

KORG Gadget

I was naturally drawn to Gadget via the nanoKEY Studio, and even bought a couple of the add-on engines. However, I soon realized that Korg has no intention of playing nice with the rest of the ecosystem, since there was no way I could re-use those synths in other apps and it has zero support for third-party plugins or Audio Units.

I haven’t tried Korg Gadget on macOS, so I don’t know if there’s any interop, but their iOS applications despite being excellent synths all appear to lack Audio Unit support and only integrate with Gadget–so I eventually got refunds for most of them, since I don’t see any point in investing in music software that isn’t future-proof.

Not being able to use extras like Synth One and VOLT (as well as a couple of classic Moog synth emulators I got on sale¹) makes no sense to me, so I moved on.

NanoStudio 2

In contrast, NanoStudio 2 is amazing, especially considering it ships with a very nice built-in synthesiser (Obsidian) and that it integrates even better with the nanoKEY Studio than Gadget, including mapping knobs to individual synth controls (even if that’s squirreled away inside the mixer, of all places, it works and even allows for multiple profiles).

The only real shortcoming I’ve found so far is that NanoStudio 2 does not appear to support MPE by itself–its Obsidian synthesiser doesn’t play nice with the ROLI hardware, but Audio Units like the Moog synths do accept MPE input.

GarageBand

Even though I’m growing quite fond of NanoStudio 2, I keep going back to GarageBand. Partly for the high quality presets and macOS interoperability, and partly because it’s fun to explore it on iOS with my kids (it’s one of the few applications that are completely unrestricted on ScreenTime on their iPads).

It having moderately decent audio processing (including a nice visual EQ) for free doesn’t hurt either, and my only wish is that it had a less modal UI, since constantly switching between instruments and timeline views gets really tiring after a while.

However, I do have two annoying gripes with GarageBand on iOS: it seems to have absolutely zero MIDI learning capabilities, and its MPE support is pretty buggy, especially with guitars and string instruments (i.e., you simply cannot play some notes on those instruments via any of the ROLI devices in MPE mode).

Without MIDI learning, the nanoKEY Studio‘s knobs are useless, so I can’t really make full use of it, and I can’t make full use of the ROLI kit on iOS, so… we’ve come full circle, I think.

In short, nothing’s perfect–but I’m spolit for choice, really, and out of all the above issues I think Apple fixing the guitars for MPE in GarageBand is the most unlikely, simply because I don’t think it’s high on their priorities.

Everything else is only likely to improve, except for the amount of free time I’m likely to get.

The good news is that more and more organisations are embracing research in product teams. Whether it is product managers doing customer interviews or designers doing usability tests, and everything in between – it is now fairly simple to come up with a compelling argument that research is a thing we should probably be doing.

So we move on to the second generation question. How do we scale this user centred behaviour?

Depending on where in the world you are – and your access to resources – your answer is usually to hire more researchers and/or to have other people in the team (often designers and product managers) to do the research. This is often known as ‘democratising research’.

Almost certainly this is the time that an organisation starts looking to hire designers and product managers with a ‘background in research’ and to establish some research training programs, interview and report templates and common ways of working.

This all sounds eminently sensible, but there are some fairly structural issues in how we work that can undermine our best intentions. At best, it can render our research wasteful and inefficient, and at worst it can introduce significant risks in the decision making that our teams make.

Each of these are systemic issues and anyone doing research is likely to be impacted when working as part of a cross functional product team.

So, let’s assume that people doing research have had adequate training on basic generative and evaluative research methods – here are five common dysfunctions that we will need to contend with.

1. Teams are incentivised to move quickly and ship, care less about reliable and valid research
2. Researching within our silos leads to false positives
3. Research as a weapon (validate or die)
4. Quantitative fallacies
5. Stunted capability

Here we will start with the first, which is one that many will find familiar.

Dysfunction #1.
Teams are incentivised to move quickly and ship, care less about reliable and valid research

The most popular research tools are not the ones that promise the most reliable or valid research outcomes, but those that promise the fastest turnaround. One well known solution promises:

Make high-confidence decisions based on real customer insight, without delaying the project. You don’t have to be a trained researcher, and there’s no need to watch hours of video.

It sounds so appealing and it is a promise that a lot of teams want to buy. Speed to ship or velocity is often a key performance indicator for teams. It’s not a coincidence that people usually start with ‘build’ and rushing to MVP when talking about the ‘learn, build, measure’ cycle.

Recruitment trades offs made for speed

The challenge is that doing research at pace requires us to trade off characteristics  are important to the reliability and validity of research.

One of the most time consuming aspects of research is to recruit participants who represent the different attributes that are important for understanding user needs the product seeks to meet. The validity of the research is constrained by the quality of the participant recruitment.

What do we mean by validity? In the simplest terms, it is the measure of how well our research understands what we intend for it to understand.

Most of the speedy research methods – whether that’s guerrilla research at the coffee shop or using an online tool – tend to compromise on participant recruitment. Either you just take whoever you can get from the coffee shop that morning, or you recruit from a panel of participants online and trust that they are who they say they are and that they won’t just tell you nice things so you don’t give them a low star rating and they get to keep this income source.

There are many kinds of shortcuts to be taken around recruiting – diversity of participants, ‘realistic-ness’ of participants or number of participants being a few. Expect to see some or all of these short cuts in operation in product teams where speed to ship is the primary goal.

Being fast and scrappy can be a great way to do some research work, but in many teams the only kind of research they are doing is whatever is fastest. This is like eating McDonalds for every meal because you’re optimising for speed… and we all know how that works out.

Teams are trading off research validity for speed every day. Everyone in the organisation understands the value of getting something shipped, and this is often measured and rewarded. Not so many people understand risks associated with making speed related trade offs in research.

What is the risk?

Misleading insights from the research work can send a team in the wrong direction. That can direct a team to spend time creating and shipping work that does not improve their users experience or meet their users needs. That does not increase the desirability or necessity of their product, and thereby negatively impacts their productivity and the profitability of their organisation.

Does this mean that speed to ship is bad? Should all research be of an ‘academic standard’?

No.

Testing to identify some of the larger usability issues can often be done with small participant numbers and less care to find ‘realistic’ respondents. But if the work that results from your research findings is going to take more than one person more than a week to implement, it might be worth increasing the robustness of your research methodology to increase confidence that this effort is well spent.

People doing research need to be clear with their teams about the level of confidence they have in the research findings (it is fine for some research to result in hunches rather than certainty as long as it is clearly communicated). And teams should plan to ensure they are using a healthy diet of  both fast and more robust research approaches.

Organisations need to ensure they have someone sufficiently senior asking questions (and understanding how to critique the answers)  about not just the existence of data from user research but also looking under the hood to evaluate the trade offs being made, and as a result the level of confidence and trust we should place in the insights and claims made.

You can read about the second dysfunction here.

• Adactio: Journal—Getting started
  Notes from Jeremy Keith on starting out in front-end circa 2019. Really useful for [Longridge], because I never have a good answer to where to start any more, and lots of these resources look great.
  (tags: programming css html web markup development learning resources jeremykeith )

PureOS was originally conceived as a rolling release.

A rolling release receives periodic updates in a “rolling” fashion–they just keep rolling in. This is good, as you get the latest cutting edge changes to applications and system libraries. But unfortunately there is a side effect to rolling releases: they are bad for stability, because the changes they bring are often not yet widely used, or tested, in real world situations. This issue is inherent to any fast moving body of code, and PureOS is no different; we attempt to solve it by putting the user at the center of our design choices. With this in mind, we polled our forum and worked internally to devise a pragmatic solution that follows best practices, while continuing to provide options for users.

Our solution is straightforward; we’re making our PureOS release a stable release, and creating a new rolling release. In addition to this stable release, we’re adding two complementary suites–amber-security and amber-updates–which work together to bring a rock solid release. We will also build and release a rolling release just like the one our users are used to, meant for those who are willing to use, and test, the latest software from upstream. Both releases will receive security updates, of course, but the rolling release will lack real-world testing, by design.

How do I get the new stable release?

You likely already have the new stable release. We’ve tested it for a while, and are now adding it as a normal update to PureOS base files. It should be an uneventful update–but if there are any issues at all, please let us know via bug report in our tracker system. We’ll announce our new rolling release in the near future. We will continue working on it, and during the period where our upstream has moved from stable to a new testing release there will likely be a bit of churn. Waiting for that to settle will likely benefit the quality of the new rolling release.

The post PureOS Rolls On as Stable appeared first on Purism.

Markos Charatzas writes about his excitement in joining the Apple developer world in 2009 to his eventual disillusionment today.

Years ago when I was a online political community admin, a member of our community invented a form of blog post to spawn discussion that was less about capturing fully formed thoughts and more about opening questions. He called it nine comments, and it was (I think) one of the best innovations of Blue Hampshire front-paging. (Actually, second-best. The best innovation was the Citizen Whip Count we ran for marriage equality legislation which so stressed the state party apparatus out they back-channeled numerous time to tell us to cut it out. But I digress.)

Anyway, 9 comments for the week on Ring video and news coverage, in no particular order.

One: News Is Not Prepared for Doorbell Video

This person’s doorbell caught the moment their house was destroyed by a tornado. There’s a way in which this is educational, and could save lives — showing people how quickly a weather event like this can sneak up on you. But it’s also a reminder that news is not prepared for a doorbell video world. I know that there are codes in place for the use of citizen video, and surveillance cam video. But scale makes a difference. And the scale of this is going to be huge.

Two: Push vs. Pull Video

In network design we often talk about push and pull architectures. In a pull architecture, you go out and request something. A push architecture finds things relevant to you and pushes them to you without a request.

The technical meanings of these terms are narrow, but I often think of these as information-seeking modes. So when a robbery happens and people check to see if there is video that’s pull. You go looking for the vid you need. A video like the Philando Castile video was push — pushed out to people even before they know there’s an event. In that case, the push event was also newsworthy, so it’s not entirely about newsworthiness. But these are different modes. (Network terminology purists go ahead and hate, I’m over it).

Three: Push video and SHAREABLE RING CONTENT

Some Ring content is pull: something happens and we review the tape, or send it to reporters. Some is push: the event itself is important because it was captured on camera. The doorbell video creates the event.

Four: It’s the Push Video that concerns me

This particular news event would be noteworthy no matter what. It’s a tornado hitting a house, and that’s news. My worry though is the number of things that become news stories simply because video captures them.

Five: Easy availability of content shapes coverage, coverage warps reality

Yeah, yeah, yeah, McLuhan etc. But this basic principle isn’t really in doubt. The cost of acquiring Ring video is going to be trivial compared to putting people on the ground. But what is this video best set up to capture? What does engaging content look like on this platform? Because that’s where news might be going.

Six: The genres of Ring video are being constructed as we speak and we have little idea of what they will be

Weather videos. Hassle daughter’s date videos. Hassle garbage picker videos. Package thief videos. Cryptic event videos. Suspicious person videos. And news organizations are looking for new angles on SHAREABLE RING CONTENT, different places they can slot it into their existing coverage. Lifestyle, Crime, Weather.

Seven: Again, it’s push that’s the shift

It’s not even just that it’s push in terms of spread, but even filming. No one is seeing something and deciding to pull out a camera. The decision is after its captured.

It’s worth thinking about how the easy availability of Ring videos to newsrooms is going to shape coverage (especially local coverage, but also national). Is this where we want to go?

Eight: You don’t need an Amazon editor for a Ring News Dystopia

There is rightly a lot of focus on the sort of “communities” Amazon is looking to build around doorbell video. They could do a lot of harm. But news can be shaped dramatically by Ring video availability without the platforms becoming involved. Ring video is showing up on local broadcasts and news sites already. Some of that video is probably useful, but much of it creates a world that is even more paranoid and divorced from reality than your average local broadcast, and that’s saying something.

Nine: Viscerality of Doorbell Video Crime

The vaguest thought, but I’m stuck by the viscerality of these Ring crime videos. How they feel when you are watching vs. even traditional sensationalist coverage. I don’t think we’re psychologically prepared for this, individually or as a country.

For many years I have been teaching Cynefin as a foundational framework in complexity and participatory leadership workshops and retreats. For me it’s the best and most accessible way to explain the differences between complex problems and other kinds of problems and why we need to make complexity-based interventions in complex systems.

And while there are great ways to start learning about ontology in a lecture format, or using te examples of a children’s birthday party, I’m rather inclined to playing games as a way of understanding different types of systems before we do any teaching at all. Especially when you are teaching Cynefin by referring to constraints, games are super useful because a game is really just a constrained system.

My go to games involve movement and various challenges inspired by theatre exercises, and I’ve documented them before. This morning I needed to create a new suite of games for a context in which free movement was itself constrained (two participants in wheelchairs and a room that was not big enough for good and open movement.) I went to my arsenal of improvisation games and came up with these three games. We did these in groups of about 6-7 people.

1. In your group, recite the English alphabet in order one letter at a time. Go around the circle, with each person saying one letter at a time.
2. In your group, this time you will construct a 26 word story by each person contributing a word that starts with the next letter in the alphabet. Go in order around the circle, one word from each person. The theme of the story is “Our journey to the retreat centre.”
3. In your group you have 3 minutes to tell a one word story about a mythical and legendary community event. Each person contributes one word at a time and you go clockwise around the circle. I will let you know when you have 30 seconds left to wrap up your story.

You can see that these three games map on to the Obvious, Complicated and Complex domains of Cynefin and although they are variations of the same process, the way we use constraints is what dictates the nature of the game.

In the first game, there is a rule: recite the alphabet in order, one person at a time. There is no room for creativity and in fact a best practice – singing The Alphabet Song – help you to do it. If anyone in the group doesn’t know the alphabet, it’s easy enough to google it and show them so they don’t lose their place.

In the second game, there was more latitude for participants to ad something, but they were still constrained by the alphabet scheme and the rule of one word at a time, going in a circle. Again, expertise helps here, as people can remind others that they skipped a letter for example, but increasingly the story is emergent and there is more unpredictability in the exercise. It’s also worth pointing out how people game the system by schoosing words that fit the rules rather than words that contribute to the story. The rules are far more influential constraints than the purpose of the exercise. This leads to all kinds of discussion about why it’s easy in large system to justify your work by just doing your part rather than by what you added to the whole. This is a good example of governing constraints.

In the third game we free the participants from all constraints except one word at a time, in a circle. The theme of the story becomes more important, because word choice is ENABLED by the theme which constraints options. Enabling constraints are at play, and I offered people a couple of heuristics from the improve world in order to hep them if they were stuck:

• Accept the offer and be changed by it
• Make your partner look good by building on the offer
• Don’t be afraid to fail

One word at a time stories can sometimes be very powerful and moving as they emerge from people co-creating something together. You can see how small changes cause the story to go in a radically different direction and participants can often feel their desire to control the narrative dashed on the rocks of different offers. With fewer GOVERNING constraints in place, people feel freer to make mistakes and fail, especially knowing that others may be waiting to work with their material anyway.

So there you go: a new way to experientially learn ontology before diving into Cynefin to explain and make sense of what we just did.

I looked back and it was March when I first wrote about House Hunting (or as Theo would say, House Huntin’ as he currently leaves the ‘g’ off of every ‘ing’). I thought I would give an update. We aren’t much closer to finding a new place than we were in March. We’ve been to multiple open houses and I have alerts set up for anything in our budget. We even fell in love with one place in a perfect neighbourhood that ended up being out of our budget.

Here’s what I’ve learned from looking at other places…. it all comes back to perspective and gratitude. Every place we look at has trade offs…. the neighbourhood is not quite right, or there are no closets, there’s a big living room but no outdoor space, the flooring is awful or it’s north facing and dark. It’s been easy for me to find things wrong with a new home. And the more I look the more, I realize we get so many things we want/need from our current space. And there’s also weighing the benefit of extra space against the added expenses that could result in more financial stress for our family.

As of right now, our kids are still not asking for privacy on a regular basis. Trevor and I have managed to find a rhythm to allow each other space and alone time despite our close quarters. Funny story, recently in the evenings, Trevor has been sitting on the patio or quickly putting headphones in once the kids were in bed. I was a bit hurt so I asked him if something was wrong or if I had done something to offend him? He said that he had listened to my podcast interview on Upbringing and hadn’t realized that as an introvert I needed more time alone so he was trying to be better at giving that to me (sob! You can find the episode here).

I realized that part of my reason for looking for a new home was external pressure to do so. Or maybe not external pressure but my own internal pressure for change, for new, for that next thing. Which is exactly what I’m always writing about not needing. And here I am feeling that our one bedroom is not good enough. When I mention to friends or acquaintances that we are shopping around, I get this knowing nod and look, like of course you are looking for a new place. And this helps confirm for me that deep down everyone thinks we are a little bit crazy for how we live. And maybe we are bit crazy but I think it’s a good crazy.

So I’m going to keep looking for that perfect two bedroom that is within a reasonable budget (hahaha nothing in Vancouver is reasonable by the way) but more so I am going to focus on all that we do have in our current small apartment. And redirect my energy to the small things I can do to improve our space; our closets always come to mind first. I know there will come a time where we will decidedly outgrow this apartment but that time isn’t quite here.

Campgrounds across the country will soon get a little more electric vehicle-friendly because Tesla is donating chargers to multiple Parks Canada locations.

A Parks Canada tweet mentions that the charging stations, which aren’t Superchargers, are going to be installed at 50 locations across the country.

Great news! To help us meet our greening objectives, @Tesla is donating EV charging stations (with both Tesla and J1772 connectors ) which will be installed at more than 50 #ParksCanada places across the country! pic.twitter.com/S5b1Upnsxs

— Parks Canada (@ParksCanada) September 6, 2019

Tesla says that it will donate more than 50 chargers as there will be more than one charger per location. MobileSyrup has reached out to Parks Canada for more information.

While these chargers aren’t Tesla Superchargers for fast charging, they are going to be capable of charging both Tesla vehicles and electric cars that support the J1772 charging standard.

Source: Parks Canada

The post Tesla is donating EV chargers to more than 50 Parks Canada locations appeared first on MobileSyrup.