Reader

welcome to gibberish.awful.systems, a platform for long-form writing and blogging hosted on awful.systems and running on WriteFreely. this is a place where users of our Lemmy instance can host text that would be clumsy as a Lemmy post, or which would benefit from the permanence of a blog.

if you're an awful.systems regular reading this and you don't have a gibberish account, contact me to get invited.

getting started

to get started, the WriteFreely writer's guide is ok. it covers some of the oddities of WriteFreely, like the first line of a post being the title (and also optional). another notable oddity is excerpt tagging by adding a <!--more--> HTML comment to your document. there's a slightly better-organized writer's guide available too, but some of the functionality it describes (like image uploads) only apply to WriteFreely's paid flagship instance.

blog visibility

blogs and their posts are unlisted by default on this instance, meaning they won't show up on the instance Reader or be pushed to ActivityPub until you change your blog's visibility in its Customize page. this can be confusing since there's nothing telling you this is the case otherwise; check there first if something isn't showing up where it should.

writing drafts

WriteFreely has a drafts feature. it works fine for basic drafts, but has a number of drawbacks; see this post for a summary of those drawbacks and a workaround. drafts can also be used to make anonymous public posts, because WriteFreely loves spam and thinks we should have more of it.

customizing the fuck out of this thing

our instance has a unique feature: PRs merged into this repository cause our deployment to pull the files that make up its frontend from that repo. this can let us rapidly change how our instance looks and functions and fix a lot of jank. since this is for the frontend only, most of the files in the repo are irrelevant and are only there so we can easily merge upstream's changes back in. the relevant files for us are:

• .woodpecker/push-to-prod.yaml: check this out to see how we push to prod, and which Less files get compiled.
• pages: this is a set of Go html/template files defining some of the pages that make up the WriteFreely frontend.
• templates: this is another set of Go html/template files that defines a set of reusable templates that make up other pages, and the rest of the pages that make up the frontend.
• less: these stylesheets are written in Less and get compiled by our CI before they get pushed to gibberish.
• static: these static files get exposed verbatim by WriteFreely; this is where the CSS, Javascript, fonts, images, and (on the deployment end) compiled Less stylesheets used by the frontend live.

it's janky (we'll be saying that a lot), but one trick WriteFreely instances do for image hosting is put them in static/img. we can do that within reason (our instance doesn't have a ton of disk space free, and eventually git will start to hate all the images), and maybe eventually just get a system working for uploading images to object storage.

the roadmap

being able to modify the frontend gives us quite a bit of flexibility. here are some ideas we can expand into if there's demand:

• full federation: WriteFreely itself only supports one-way federation, in that it knows how to push articles to ActivityPub but not how to pull in comments, boosts, or other events. there are a few somewhat easy ways to get full federation with just frontend changes to WriteFreely; one example is Hatsu.
• automatic dark/light theme switching
• less confusing navigation
• maybe some premade themes?
• your ideas here! no not really, go to the repo and put them there instead

A fundamental attribute of User Experience design is its inability to change the underlying product.

The concerns of a UX designer, or researcher, are limited to furthering the acceptance of a product by an intended audience, and all of the empathy postured by the role is directed within that context.

The empathy is limited to better understanding people to entice them to use the underlying product and—if it's a commercial product—pay for it.

User Experience Design and, to some extent, Product Design are considered software industry roles—in general—and rarely referred to in any specific product category.

“Software” is not a product category. It's a material, a means, for making products. “Enterprise Software” is also not a product category. It's a market category, particularly lucrative because the product is paid for by the ones who don't have to use it, and the ones who have to use it don't have a say in the matter.

Once the software part is ignored and a product is treated like any other product the actual category surfaces. This is where the incongruence of the product design and the intentions of designers emerges. There aren't many Spreadsheet User Experience designers.

The challenge is to consider the word “design” in its rawest form, the process of satisfying a purpose. In that context the origin stories of so many tech startups that tell a tale of disruption—or the discovery of an obscure problem that can be alleviated at scale with software—do not fit this model of design.

The stories don't fit because they don't tell the purpose behind the product. For example, Uber didn't disrupt the taxi industry to satisfy the purpose of helping people get around the city cheaper, safer, and more efficiently. Rather, Uber found that people wanting cheaper, safer, and more efficient taxis were a means to satisfy their purpose of making a lot of money.

To make money is the immutable purpose of a commercial business. It's not the only purpose a person may have while running a business and it's not always the purpose that creates the product that led to the business. This doesn't change the fact that from the moment a business is created, the immutable purpose to survive via income is in place.

This means that design—again, in its rawest form—has a key element, an undeliberatable purpose in every business. The deliberation proceeds in discovering the means to satisfy the purpose and the constraints and obstacles to work with, work against, avoid, or ignore.

Whenever an organisation promotes—internally or externally—its mission statement it is not promoting its purpose. It is promoting its bullshit, which many in the organisation will genuinely believe to be genuine.

This is the designed. The products of these organisations that User Experience designers design upon. Software doesn't get sold on shelves in stores any more, and rarely takes up space on our computers and, for enterprise software, our bank accounts.

The shedding of these constraints has made software a fluid product. Something that takes up so little space in our lives that we tend to ask less about why we need it, why we use it, or what they made it for.

In some cases it is designed by the founders—perhaps not initially—to be as profitable as possible regardless of any actual benefit to the people using it.

The User Experience designer in these organisations is constrained by their own title. Any subsequent design work on an underlying product, which is openly dedicated to furthering its profitability, is marketing. More so if it uses manipulative psychological techniques and relentless removal of friction to aid in that purpose.

This is the designer. The title binds the practitioner within it to either embracing the reality and being comfortable with the bullshit (or being honest about it), believing and embracing the bullshit, or being in a constant state of despair over their inability to do the things they believed User Experience design was for.

The purpose of Marketing is congruent to the purpose of the business. The User Experience is only congruent to the purpose of the business if it results in users either paying or not preventing their employers from paying.

In this sense, User Experience becomes the product. It is now the most important means to satisfying the purpose of making money. Now that software is free of all the shackles of the physical world of products, the constraint of having to justify space in our lives is all but gone.

Software has become less concrete in any specific purpose the organisation behind it is prepared to assert.

The software is a collection of existing useful products mashed together as features, where the usefulness of the whole is discovered by the people who find ways to make it useful for themselves.

Or, as we increasingly see, the software is built on a collection of potentially useful features mashed together, hoping for a “killer app” which will convert that potential into reality.

The consistent factor in these impotent software creations is how much effort goes into making them appear easy to use, fun, human-like, and intuitive. Because the real design is the means to the corporate ends. The UX designed thing is the product that distracts from it.