JcDent

A T-55 experience

Military history, video games and miniature wargaming.

RPGs, single player FPS, RTS and 4X, grog games.


Passionate about complaining about Warhammer.


Catholic, socialist, and an LGBT+ ally.


FORUM SIGNATURE:
THIS USER IS A GIRL KISSER

///

JUST POST


Fortified Niche: a podcast covering indie miniature wargames
www.anchor.fm/fortified-niche
Grognardia: the current place to order my t-shirt designs [until I find a better one]
www.zazzle.com/store/grognardia

srxl
@srxl

there is a difference between knowing computers, and knowing how people use computers. you'd do well as an engineer to understand this difference, and invest time into learning and educating about both. foss software will never be on the same playing field as the corporations who understand this distinction until it's contributors do too

(cont.)


srxl
@srxl

you'd think this would be an obvious statement but there is a certain, prominent breed of stembrain that does not understand this. the reduction of software development to pure engineering creates this massive blindspot in the vision of engineers that fall into this mindset. education material for new engineers is always focused on the technical aspects. what's the most efficient algorithm for a given use case? what's the new abstraction/library/framework of the day, and what's it's technical merits? what are the best strategies to ensure a clean, maintainable code base?

i cannot stress enough that the end user does not give a single flying fuck about any of this (well, maybe a little - only insofar as the software actually functions, and performs reasonably). whether you filter an array of search results by iterating over the array with a for loop, or a filter function means absolutely fucking nothing if the user doesn't even understand how to access the search functionality in the first place. there are established interaction patterns in use across applications - some good, some bad. but an engineer's education ignores this. it's not technical work. it's not engineering. it's design. that's not your concern. you're learning a STEM subject. not a creative one. you don't need to care about that. it's not your job, that's the job of other people you'll work alongside in the industry, so they'll take care of it. just focus on shipping production-ready code, that's all we need from you.

...you are learning so you can get a job in the industry, right?

the foss scene is made up almost exclusively of engineers. particularly, career engineers who contribute to foss as a hobby on the side, or as portfolio projects for their resumes, or even as part of their job sometimes. designers don't enter the picture very often (and we should really ask ourselves why that's the case sometime). what that leaves foss with is a bunch of engineers making software for no-one in particular. there is no target audience, there is no user research, there is no intentional design - only architectural decisions without enough ux consideration to keep the user a safe distance from the limb-crushing heavy machinery contained within. and we can't blame them - this is a skillset they were never taught, one they were taught they didn't need to care about.

we need to break this tradition, if we want foss to be viable for the everyday user. we cannot keep producing functional but unusable software (in the best case), and then putting it in front of users, expecting them to choose us over photoshop, or maya, or ableton, or <insert program here>. this is software built by companies who have hired people to fill the gaps that their engineers left - we can't compete if we can't fill those gaps. so please, if you are a software engineer, learn some ux design. learn some accessibility guidelines. learn who your users are, and what they need from your software. even better if you can learn them well enough to teach others. because again - we will never be on the same playing field as proprietary software funded by monopolistic corporations until we can give people software that they can look at, and want to use.


JcDent
@JcDent

As someone who keeps flirting with stuff like GIMP and Linux as well as a player of non-AAA games, I fully support the message of Start Giving A Shit About UX


You must log in to comment.

in reply to @srxl's post:

The sentiment is good but there's a lot of real functional problems with doing anything more than vibes-based design in FOSS, which a lot of designers who have tried to contribute have run into.

The biggest IMO is that most FOSS that isn't backed by a company doesn't want to collect analytics of any kind. Alternatively, they collect it but it's opt-in, which in practice is the same as not collecting it in the first place. Without even basic anonymized analytics (i.e. count how many people use your software, how many view the settings page, etc.) even knowing who your users are is a dice roll, let alone which parts of your software they do and do not use.

Without that, you rely on bug reports and feature requests, which already cuts out a majority of your users from your sight. Ironically this leads to overrepresentation of engineers as they already have experience using bug trackers and support forums.

I think you're spot on about a lot of FOSS software not even trying, but it's important to note that many projects have tried (some to success, more to failure) and found that designer (or design-minded-engineer) participation is only a prerequisite and one of the easier problems to solve.

there is a weird aversion to analytics in the foss space. i don't know if i'm missing something but like, the only argument i ever hear against it is like "but uhhhh that's like. tracking. and thats Bad. its not Privacy" which like... sure i guess, anonymizing analytics data is not always super easy. but like you said, it's valuable information that helps maintainers understand their userbase - there's a reason companies collect this shit. obviously there's a limit to what should be collected, and users should be made aware up front about that collection, but i think we should at least try and get used to the fact that if we want developers to be empowered to make software better, we have to know what users are doing with it, otherwise we're just endlessly stumbling in the dark trying to make things better without knowing what "better" even means

granted, this does unfortunately incur an infrastructure cost, there's not much that can be done about that. but if you've got a userbase big enough for analytics to actually show meaningful trends, surely it's worth putting some of the required effort and resources in to setting it up

Analytics are useful, sure, but UI/UX design existed before the internet and the ability to surveil users and there's a lot that can be done without those numbers. That's going to mean talking to people and getting to understand their workflows, both for users who currently use the fossjank product you want to improve and for users who use the big corp products.

Sure, but (relatively) reliable analytics existed before the internet too—Nielsen was founded in 1923.

My point was that it's not simply that designers aren't trying or devs are ignoring design, because they have tried. Many times. Both in standalone FOSS and in corporate-backed projects.

A lack of analytics is only the biggest problem I've seen, but it's not the only one. Resistance to change, adapting to the native UX of the OSes that your software is commonly used in, accommodating the needs of your open source contributors, etc. Design is really hard to do even when you have all the right tools. It's not simply a lack of trying, that's just the first of many gates to clear.

What i've seen is largely FOSS projects being hostile towards designers trying to offer their time. A big overhaul IS hard bc people are already using it and breaking their workflows is a big deal! Corps do it because they can and sometimes it might be for the better and sometimes it's just moving deckchairs around to justify the budget.