While the Levi-Strauss explanation is attractive, there are other factors as well. The author seem to think that a kludge of things such as email, ms word, and screenshots is an inferior workflow, but it has virtues as well. Those tools are stable and reliable and have been around for 20 years, and can be expected to be around for 20 more. Nothing about them is going to fundamentally change, and the user can expect that everything about them is controllable by the user, and they they'll appear on any new platform that might emerge (smart phone, tablet) essentially unchanged.

Contrast this with something that the author sees as a better solution, say, Instapaper. It began as a paid app, then it was free but with a Pro version, then it was subscription-based... the whole situation just seems volatile - it could disappear tomorrow, and it stores the data god-only-knows-where. If you happened to go with Readability or Evernote Clearly then now you're back to square one and have to figure this stupid crap out all over again.

There are a lots of users who value stability and reliability over small efficiency gains, and who don't enjoy spending time navigating ever-changing marketplaces.

https://en.m.wikipedia.org/wiki/Seeing_Like_a_State

The efficiency gains are often theoretical, not real. This is the essence of why the qwerty keyboard remains the standard, though it was designed to be intentionally inefficient to slow people down. There is a very real cost involved in retraining yourself to do things differently.

It only makes sense to do so when any gains in efficiency will be quite substantial, obvious and will meaningfully pay off in a relatively short time frame. Most new tech fails to meet that standard for most people.

I'm not sure where you got that. I didn't get that at all from my reading.

When we went into analysis, a tension appeared between our findings and what we believed was being asked of us to report on. Our original charge was to find ways to improve and optimize users’ browser workflows following software and design-oriented assumptions. Instead, we saw that users were doing just fine with the tools they were already using.

...

Thinking back on this, it was evident to us that there was nothing to “improve” or “optimize” here as a standardized “workflow.” The participants’ solutions were already clever optimizations using the tools and paths that they understood.

To me that's a fairly clear admission that the bricolage approach has benefits in certain situations.

I have some recent experience deploying web-based administrative tools in my organization, which are meant to replace and supersede legacy, often informal, workflows.

Adoption rates are low and frustration among users is high, and my efforts at understanding this has focused on missing elements in the new workflows -- it seemed likely that, in formalizing the workflow in order to implement it computationally, we missed something, or got the order wrong. The unexamined assumption here is that there exists a correct, usable formal workflow, and that our task is just to find it and code it up, and then users will engage and frustration will recede.

But, as the article suggests, this may not be the case. If users are frustrated by the inability to use familiar tools, and to comprehend and execute the sub-parts of the workflow, then no "all-up" integrated workflow will ever feel right to them.

Somewhat embarrassingly, the "bricolage" approach also reflects the Unix philosophy, of which I am very fond -- users should be given a suite of powerful, comprehensible tools with narrow and very clear operational scopes, out of which they should build their own solutions.

A good example is my company's Mantis ticket usage. There's nothing wrong with Mantis, but if I file a ticket odds are it will never get looked at for hours or days, whereas if I walk over to our DevOps team and make the request person-to-person it will often get addressed immediately. It's also worth noting that it's less effort to just have a conversation with someone vs filling out a Mantis ticket which then has to be filed/processed/marked as done, etc. The ticketing system actually adds unnecessary overhead in our context.

If all formal workflows were as reliable as, say, Amazon shopping and customer service, I think we'd see mass adoption after some initial resistance. I have no knowledge of the organization you work for, but I'd look for problems in execution before seriously questioning the design. Most corporate leadership types consider (wrongly IMO) infrastructure to be a cost center, and that attitude tends to trickle down no matter how good the design.

I wish we made more allowance for bricolage in software. There are some great systems that enable bricolage, like Lisp or Unix or Emacs or Forth or Excel. They are toolboxes that you can use to cobble together some solution, perhaps not the best engineering solution, but it's quick and solves the problem.

Today, it seems, bricolage is out of fashion. All applications (and all devices in fact) must be made to be "perfect" and "easy to use", not to be combined and remixed as pieces of some "erector set".

Forever and a year ago I had to edit some photos and lay text on them. From the Camera Roll I was able to share it to another app and each of these apps did one little thing like change levels, apply filters, overlay text, cropping/aspect warping. But because each of these apps allowed me to use the share pane they could be chained together without storing it on the device in some intermediate form.

The first time I used it it clicked. It was just like pipes but for data types.

To a significant extent they expose built in apis to a basic style language. There's various programming language libraries that do similar for other languages.

This (the OP) may be insightful, but my first reaction is within the context of my ceasing to purchase Levi-Strauss products, because: First and primarily, they started wearing out very quickly -- I'm hardly the only one to have noticed this; and secondly, their unit size variations went way out of control -- e.g. taking 10 or more identical units into a dressing room, to find 3 or 4 that actually fit well, or at all.

Their office processes may have developed to some super-natural level. But I'm still not buying their actual products.

I mention this, because I run across it repeatedly, these days. All sort of internal "efficiencies and improvements", but no corresponding improvement in the actual product.

Towards the more dark pattern end, materials scientists and engineers closing in a particular lifespan to maximize revenue. It may be a very sophisticated process, but as the consumer, it's not doing me any good -- as I see it.

That said I am also kind of lost on the conclusion here.

> Using theory to support our research findings allowed the team to gain a greater sense of self-awareness into their assumptions and how others without those assumptions might think and behave differently.

While insights are fine, without concrete examples, this is just a hypothetical whether this really helped the engineering team.

A workflow designed by an engineer optimizes for some combination of time, resources, cost, etc. Most people don't want something that optimized as it is very brittle to change, so their own ad-hoc workflows are "better". At least for general users that don't have a very small selective set of tasks.

In software, we would probably call them "software engineering" and "hacking" approaches. For example, in the Linux Kernel init discussion, systemd is an engineering solution, while traditional init system is a bricolage solution.

If you break an engineered system down into its components and never consider all the ideas and fabric that link them together in an engineered system, you could reduce anything to bricoleur.

I disagree. Yes, Unix is deliberately engineered to allow for bricolage. But many (most) things aren't. Take for example classic PC and the iPhone. You cannot break down iPhone to it's components and remix them. You could do that with a PC, to some extent.

McGyver is a bricoleur - same goes for the vehicle building parts of an A-Team episode. Tony Stark is an Engineer.

Of course an Engineer can probably also work with make-shift conponents in an emergency, but it is not their preferred situation.

Bricoler is improvisation, adaptation, and creativity with a constricted set of materials and methods. Engineering is changing the set itself.

When you're on your back in the data-center in a tight spot trying to unscrew something but you don't happen to have a screwdriver, bricolage would be to use a knife-tip instead because that's just what you happen to have and can make do with. Engineering would be to crawl back out, head out to the store, find the proper screwdriver, buy it, come back, and crawl back down to unscrew it.

In a software sense: most people solve their problem of the moment (extracting data from a bunch of files) using bash, cat, grep, sed, and some quick regex editing in their favorite editor, copy-pasting as they go, etc. They're going to write a specific program for just this one particular problem. (This is related to whether it's worth the time [https://xkcd.com/1205/ ]). Or the stereotypical Grandma who sends a favorite picture by downloading it, inserting it into a Word document, printing that, scanning it, and then clicking on the "send via e-mail" button in the program, and looking up your e-mail address in her (physical) notebook.

so any larger application can become very easily 'overengineered' and of less value to the bricoleur.

there are some good examples of bricolage systems mentioned here, like unix shell commands etc.

but in a more application design-specific context targeted to 'normal' (non-technical) users i was wondering if flow-based programming (e.g. noflojs.org) could offer a better balance between well-engineered small (maybe even tiny) building blocks and bricolaging them based on personal preferences (e.g. visually) to bigger, useful apps.

flow-based programming had a good uptake initially, but i'm not hearing much about it of late..

any opinions or experiences?

https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss