I beg you, if you are a developer of an open source app or program - add screenshots of your app to the README file. When looking for the perfect app, I had to install dozens of them just to see what the user interface looked like and whether it suits me. This will allow users to decide if the app they choose will suit them… Please, don’t think about it, just do it…
Removed by mod
Removed by mod
When the last big Twitter migration to Mastodon occurred there were a lot new users complaining about things like documentation, bugs, etc. Old users and FLOSS supporters kept pushing the “its open source, write a doc or fill out a bug ticket” and evem included documentation on how to do those tasks.
Most people just continued to complain. /facepalm
We just don’t live in a world where making the changes you want are encouraged. We have been thought to just accept whatever changes happen or at most file a suggestion that almost noone will listen to. Obviously open source is different but it’s still such a tiny minority compared to how the rest of the world functions
The big difference here is there is already this “learning curve” about the whole fediverse that people were struggling with that many of us wrote blog posts and had toot chains we’d forward explaining how this universe works. Adding in links and screen shots and templates for how to submit a bug…
…I hate saying this but the vast majority of people are just lazy. It’s not a culture issue or not something too difficult. People like to complain and not put in effort to things. People expect others to do things for them and don’t get that free comes with a cost.
FOSS isn’t really that small, it’s just that most people don’t do any type of investigation into what they use for technology. Much of what you use may have a for-profit company in front of it but huge parts of their products are open source andnyou can directly influence the products by actually engaging the projects themselves.
Yeah people are very much lazy and that’s fine, you just have to work around that and well culture is one way of getting people to do what should be done.
As you say Foss does impact quite a lot of those company products however what is the important part of the casual user is what and how they interact directly with the products and well at no point are they expected to directly impact the project, it’s just you use what you are given. That is why they have that people will do things for me mindset bc that is what happens with almost everything the use
I think this is interesting, certainly screenshots and giving an idea of how something works is important. It seems more important to many users rather than say developers. I guess developers have a different set of priorities, maybe it does make more sense for users to add screenshots or contribute as it is in their interest whereas maintaining and fixing critical bugs is more within the interest of the developer?
How would this even be communicated effectively to users? I find that most calls to support are vague and maybe if they were broken down by interest or skill set it would help people understand that they too could do something.
E.g. Having a headline that says contribute, and like a table with icons for different professions or areas people could contribute with different processes for each. I have friends who are good typesetters or editors, but they would not put in the effort to use github, they would prefer to use something closer to social media or word/docs at the most. It feels like github samples from only a subset of the population and is actively trying to ensure the comfort and curation of that community to the expense of others and collaborative work in general.
As both user and developer - user CAN contribute but the developer/maintainer SHOULD add the screenshots.
This mentality explains a lot of open source.
Yeah, and please have EASY setup instructions or complied binaries.
Why is your name red?
Site mod, I mostly do the infra tho ❤️
Removed by mod
There’s both an ignorance and fear barrier to that.
A lot of people don’t know they can, and don’t know how. And even the ones that do know, often worry their contributions would be shit.
And there’s folks that just don’t think the project would accept that kind of submission.
I’m not contradicting your suggestion! It’s a great thing to let people know that they can contribute without knowing how to code. Just adding in both an explanation as to why it’s so rare, and hopefully allaying some of those worries for passersby.
I think it depends on the project. Some projects are the author’s personal tools that they’ve put online in the off-chance it will be useful to others, not projects they are really trying to promote.
I don’t think we should expect that authors of repos go too out of their way in those cases as the alternative would just be not to publish them at all.
Totally agree
What if I do a PR for a program that isn’t even related to Linux and Linus still sniffs it out to tell me I’m a dingus :(
NGL I actually didn’t know that I can do such a thing. I do still kinda have a closed source mindset in that anything I use I cannot change or Influence. Like I knew that other people can do that but I didn’t know I can do that
Yeah, it’s a thing :)
I’ve only done it once, and it wasn’t pictures, it was rewriting a horrible section about how to install a program my cousin was trying to build. He abandoned it three months later, but still.
From what I’ve heard from people that code, it’s polite to approach whoever is maintaining the project before jumping in, and it makes sense so that nobody wastes resources on something that isn’t going to get used.
If the app sucks, few people will add the screenshots. Therefore, most apps without screenshots will suck. So new apps will need the developer to add screenshots, or people will assume it sucks.
And we’re back to square one. The developer has extra responsibility to highlight the features.
This is good advice, but having a screenie there in the first place might make someone more likely to try it out.
One thing though: I’m likely not to stop and consider looking closer at an app if I can’t judge if it’s going to be what I’m looking for. I’m not going to go over random GitHub repositories and create screenshots for their projects. So if the assumption is that the user contributes screenshots I don’t think it will ever change anything for the majority of projects.
While we’re at it, I love that you let me customize the settings via a config, but for the love of god make the default config the best it can possibly be
This. It should be the most sane configuration and fit most use cases and lead to an experience working out of the box.
I contribute to OS projects and work on one full time. EVERYBODY thinks that their obscure use case is the most common (not saying this is what you are doing).
We get users that are completely flabbergasted that our software doesn’t offer some feature that is totally specific to their industry and has never been requested even once by anyone else previously. We’ll show them our feature request form on our site where you can also view and upvote other requests, and point out that the feature they want has never been requested. They will literally come up with some bs excuse why that is and then insist that we get on it and build out this custom functionality that they need or else they’re going to slander us on social media.
Your app doesn’t integrate with “didLr”? OMG any decent app integrates with “didLr”!
I understand the developer POV too. It’s clear that getting the right config for most use cases is a UX problem, which may involve user studies, telemetry to be setup. Perhaps out of scope for most small scale individual projects.
Additionally, I also fully understand that many, if not most of these projects are hobby projects and expectations from users should align with the scope of the project and the resources committed. It’s so easy to feel entitled and deserving of high quality projects but they are so time consuming.
My comments were not for those projects but rather mature ones. And contributing to the projects is often the most appreciated way when proposing changes.
In all cases, for any free project, it is always acceptable to answer that something is out of scope, that resources don’t allow for the feature to be implemented or that additional help on implementing it are welcome.
People demanding something in exchange for nothing are obviously not the most welcome users :)
There’s a real problem here with backwards compatibility. If you add an option for something, it makes sense to make the default match the functionality of old versions, even if it’s not the best for general use cases. That way any tools built on top of it can safely update.
Ding ding ding!
That said, the solution is to set new defaults for new installations only and not change existing configs. Users lose their minds (rightfully so) if you modify their existing configs.
I prefer the simple, sane defaults that work for everyone with a heavily commented config file giving detailed information on what each value for each option does, personally. Like MPV’s config file.
I haven’t even touched MPVs config file because I just assumed it would be empty like so much other software I use. Looks like I know what I’m doing tonight.
Krita and not having hotkeys ಠ_ಠ
deleted by creator
Grnrrth is a FOSS native qualitivate built with the Jot framework. It comfortably handles 2NUT, xrr, .gif, and any other Banbo hierarchies in a windowed, cross-system integrated module.
It’s like I’m in the readme of every project I’ve stumbled across from Google to a forum to GitHub pathway…
And that’s what having a stroke sounds like
You’ve heard of adjective foods? Get ready for adjective software!
README.md TODOAdded a readme, boss
No, wait, it should be done according to https://github.com/matiassingers/awesome-readme
deleted by creator
Sometimes I’d settled for a simple description of what the tool even is. Sometimes the readme is just straight into compilation steps and I feel like we’re rushing into something.
Foreplay is important! Gotta get me excited for that app.
🛠️ Building
To build the app install the
gametedependencies and run the followingmake child
A lot of documentation is like that.
Its terrible when the software is called some random word that has nothing to do with the programs functionality
I also hate it when it has a name that is a super common word or phrase. Our last 3 records management prograns at work have been like this, and their help fires are terrible to non existent. Good like trying to search the internet for information on the software with those common names. Even adding terms relevant to what the software does, didn’t help much.
(Apologies if this is terribly typed, I’ve got an impending migraine aura that stayed right as I hit reply and have lost a good chunk of my vision. I can’t see most of what I’m saying.)
Unrelated, but I used to get them often. I found one article about vitamin D deficiency as a potential cause, and figured, “what what hell”. Started taking 5000IU every day of the Swanson’s brand. It took a month or so, but I’ve been aura migraine free for months (still get migraines sometimes, but they’re MUCH less severe than they used to be and no auras). Ask your doctor first, in case you can’t take vitamin D, but it’s worth a try if it’s safe for you.
I actually know what causes most of mine, there are some nerves in my neck that get pinched/aggravated and trigger them. And for some reason, if I have multiple days in a row where I don’t get much sleep, those nerves get extra cranky. They are extra cranky right now.
I’m so so sorry! I guess, at lease, you know why. That’s something, right? Not really, but :shrug: seriously, I’m so sorry you’re going through that!
Me, developing a headless component library:
To be that dick, a headless component library is still meant to do something, show an example of it being used!
What would the world even be like without people feeling the need to be a dick about an obvious joke 😘
deleted by creator
If you’ve written a “usage” section that showcases more than one uselessly simple example that doesn’t even work in the project’s current state, you’re already far ahead of the average.
This is how I generally write documentation for my projects: https://tybalt.org
Even for a CLI tool, there should be a real world example showing how it works and what the output looks like. Eg, for jq:
$ cat file.json {"field: "value"} $ jq '.field' file.json "value"And a few other examples.
I feel like maybe you don’t know what a headless component library is. A cli has a head – the terminal. Headless applications, by definition, have no visual portion. For instance, a headless browser is a browser where the web page renders in-memory, but never displays any content. A headless component library, then, is one where the implementor doesn’t provide anything visual, only behavior. For web dev, is very helpful – the library implementator writes all the js, but the css and html (the “head”) are left to the user for use. The best headless component libraries, then have nothing to screenshot without the user supplying some implementation.
Also please begin the Github page or whatever with a description of what the app is actually for or what it does. I know that sounds super obvious, but the number of times I’ve seen links that are like “I made this app from scratch for fun, let me know what you think!” and then you click through and the app is called Scrooblarr or something and it has no indication of what it actually does is… more than it should be.
It scroobles obviously!
That’s Sctooblerr. Scrooblarr is completely unrelated.
Wait what? I thought the read me file was to put as little info as possible to prove how awesome anyone was who can use the program.
Including the documentation link, which only has incomplete getting started section
Getting Started
- Clone the repo
- Install dependencies
- Compile the project: TODO
- Copy the executable to /bin
- Add your app.json config to ~/.config/app*
* IMPORTANT. APP WILL NOT RUN WITHOUT THIS
Oh hey, they have an
example.app.jsonfile. Let’s check that out!{}
TODO
Agree, I don’t know what’s so hard about a screenshot.
I imagine most single developer projects lack any design or UX so the screenshot would do little to encourage users to download.
I can only speak for myself and a handful of other people I know who are into FOSS, but for us we care more about it being functional than looking pretty. I just want to see what I’m getting into, a reference for what a successful install looks like, or just check to see if it’s got the buttons I want on it.
Is it better for someone to download it, see it, and uninstall it immediately? I’m not sure how they are tracking metrics or if they are at all.
Or at least a demo site if it’s a web site or self hosted web based app 🥲
I wish there was a way to give more props to open-source repos that do this.
I already star the project. But I’d love to say “Thanks for making a demo page it really helped!”
Donations = props
You should open a PR. 🙂
As a user, I completely agree. People often make decisions in a few seconds, and you’ve done all this work developing an app. That little extra step will allow you to make a difference to more people!
As a developer of a Lemmy web UI, I’ve been thinking about adding screenshots to my README for weeks but still haven’t done so 🙈
Get to it, mate! You can do it!
It’s easier said than done for sure
Yup, if I don’t see screenshots for a desktop applications, I don’t bother since the developer clearly doesn’t understand what they’re doing. It’s especially baffling when it’s a WM/DE. It’s really trivial effort too. If the devs don’t get this basic point, it’s going to reflect in their poorly designed UX/UI as well.
Also, installation instructions that don’t assume you’re already an expert.
deleted by creator
100% agree! I always get so frustrated when there are no screenshots in the README.md or on the site.
On github you can even paste your screenshot right from the clipboard. Zero excuses for not having a screenshot.
I think this ties in to the grander idea of: please provide information that is helpful on a nontechnical plane of thinking. It goes a very long way
