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
This mentality explains a lot of open source.
As both user and developer - user CAN contribute but the developer/maintainer SHOULD add the screenshots.
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”!
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.
Krita and not having hotkeys ಠ_ಠ
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 😘
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 start the project. But I’d love to say “Thanks for making a demo page it really helped!”
Donations = props
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!
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.
UI is always the main focus for the user. Because it’s the “User Interface”.
Searching the web for screenshots is an added hassle and something that makes me avoid most FOSS software, because sometimes there’s not enough screenshots and not even the developer cared to show what the app is about.
Well that’s what FOSS is. You can always contribute and add screenshots if you’d like.
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 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
README is usually a text file. While some platforms can now use markdown, that is nowhere near universal. So it might be better to ask for screenshots to be put on the website / wiki.
GitHub and GitLab both support inserting images into your README.md. Here’s the syntax:
Dear Open source devs: Do something I’m too lazy to contribute.
Unironically yes. Asking someone that doesn’t use your project, isn’t part of the development, and quite possibly doesn’t even want anything to do with your project to do work for you project is silly.
Where should I store the screenshots? In a screenshots folder in the repo? Should I update them at some time? Should I screenshot both light and dark theme?
That’s one option, or use imgur.
Update them if your UI has significantly changed or does not adequately represent the final product.
If having a light/dark theme is an important feature or highly requested feature for your project, it would be nice to show it off.
Screenshots can, most of the time, get away with showing just the default configuration. Share what a user would see when opening your project for the first time, and assume they used the default configuration. Optionally, if you offer a lot of customization, show what it could look like if someone spent a good amount of time personalizing things!
Where: In the repository, most projects seem to use
mediaorscreenshotsas the name of the directory.How often: Whenever a big change happened or many small changes have accumulated.
What: Light theme suffices. I only care about the general look and feel, not about specific colors.
That’s how I would do it for my own projects.
No. ReadMe files should be concise, explicit, and text only. UI/UX screenshots can be part of the repo, wiki, or associated website but they shouldn’t be in the ReadMe.
If you don’t understand the software you’re installing from some rando stranger’s git repo then you shouldn’t install it. Period. Take the opportunity to learn more or use another tool.
Git repos are not app stores. The devs don’t owe you anything.
The vast majority of software in publicly accessible git repos are personal projects, hobbies, and one-off experiments.
Your relationship with the software and the devs that create and maintain it is your responsibility. Try talking to the devs, ask them questions, attempt to understand why they constructed their project in whatever specific way they have. You might make some new friends, or learn something really interesting. And if you encounter rudeness, hostility, or incompetence you’re free to move on, such is the nature of our ever-evolving open-source community.
We bring a lot of preconceived notions into the open-source / foss / software development space as we embark on our own journey of personal development. I try to always remember it’s the journey of discovery and the relationships we curate along the way that is the real prize.
While I get the sentiment, historically, readmes have been text only, and should predominately focus on usage options, not a sales pitch. Today in GitHub, these files support markdown, but the level of effort is probably two orders of magnitude higher than a text readme alone.
Think of a readme file on GitHub/distributed with the binary more as a man page than a proper website.
So why not add a ‘Screenshots’ section with hyperlinks to PNG files?
Or, hell, just add a “screenshots” folder to the repo and mention its existence in the readme.
The best solution is to create an issue and attach the pictures there. You can then link in README and not bloat the repository.
Who reads README’s anyway? Aren’t they like instruction manuals? You only read them once its broken? :) Or maybe i should start reading instruction manuals…
it’s the very first thing you see when you visit any project’s github page.
Lots of projects are on GitHub or similar repositories and the landing page is usually the readme file as rendered markdown.
Too lazy to just look the UI up and you want others to waste their time giving you numerous UI screenshots. Hypocrite
