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…
Dear open source app user: feel free to improve the README file of the projects you come across by adding a few screenshots you believe are relevant.
Although I understand the OP’s perspective open-source is a community effort and people should have a more proactive attitude and contribute when they feel things aren’t okay. Most open-source developers aren’t focused / don’t have time for how things look (or at least not on the beginning). If you’re a regular user and you can spend an hour taking a bunch of screenshots and improving a readme you’ll be making more for the future the project that you might think.
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
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.
This is good advice, but having a screenie there in the first place might make someone more likely to try it out.
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.
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 mentality explains a lot of open source.
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
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.
Krita and not having hotkeys ಠ_ಠ
deleted by creator
README.md TODOAdded a readme, boss
deleted by creator
Me, developing a headless component library:
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.
To be that dick, a headless component library is still meant to do something, show an example of it being used!
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.
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 🙈
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.
TODO
Also, installation instructions that don’t assume you’re already an expert.
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
no pics no clicks, as they used to say
To be fair, most of time you can just Google %appname% screenshot. I understand that this is not as convenient as having screenshots in the readme, but eh, it’s not as big of a problem when you realize this.
P.S. I do actually add at least one screenshot for my software. Maybe because sometimes UI is one of the main focus, idk. I just feel like it.
TURE…👍
Don’t forget to assume what works on macOS also will work fine on a Linux server deployment.
I totally agree that screenshots and a proper description of the app in the README are a must-have for all foss apps, but as a developer I know that most of the times you prefer use your time to add new features to your app rather then documenting existing ones…
Personally I’ll try to add them to all my future projects but what I would suggest to everyone who use and love a foss app is to check out its README and, if needed, submit a pull request with an updated version of it with screenshot etc (You don’t need to be a developer to do that and it can be really appreciated)
