Open source devs: please, please add screenshots...
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.
As both user and developer - user CAN contribute but the developer/maintainer SHOULD add the screenshots.
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.
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 :(
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"!
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 เฒ _เฒ
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 TODO
Added a readme, boss
No, wait, it should be done according to https://github.com/matiassingers/awesome-readme
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.
To build the app install the gamete dependencies and run the following
make 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.)
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.
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.
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.
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
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:
md
Just like obsidian.md
Not just a text file, a markdown file. And markdown has supported images since forever
README.txt will be a text file, README.md can be much more
no pics no clicks, as they used to say
There's an awful lot of comments in this post from people complaining that developers aren't making their projects attractive and user friendly enough, or the READMEs descriptive enough.
Can I just say, as a developer with some open source projects on github, I don't care; you're not my intended audience.
I find this unnecessarily derisive. There are good reasons for a UI or README not being user-friendly, the top-most one being (imo) that it is really, really hard to get right, takes a lot of time and doesn't primarily solve the problem the project was started for.
You mean you think I'm being derisive? I think it's important to remind people that not every open source dev shares their priorities, or indeed any interest whatsoever in whether other people use their code.
This whole post is filled with a really disappointing amount of entitlement and lack of self-awareness.
Don't forget to assume what works on macOS also will work fine on a Linux server deployment.
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.
I think that doesn't work for most smaller projects. That'll work for something like Firefox, but there's little reason for random, unheard of tools to have an image on the web. Plus the naming of some projects is super generic, which can make it hard to find correct images.
Some software changes appearance often, too, and google is bad at knowing what up to date is. It can be really easy to find wildly out of date images as the top results.
TURE...๐
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!
Please don't use a external image host, have it live with your code in /docs
Where: In the repository, most projects seem to use media or screenshots as 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.
As an example, an old Android project of mine: https://github.com/moritzruth/JamRSS
I showed one screen in both the light and the dark variant to demonstrate that the app generally has support for dark mode.
Yes. Git can store binary files fine. It's not the most efficient for storing them, but it works, especially for a small number of screenshots. For updating and theme, that's entirely up to you. It's all a judgement call. If you want to show off your functionality (like a dark mode), I encourage you to include screenshots of it. If you substantially change your UI, update the images.
You don't have to update for every new button you add. It's more about giving a general impression of the UI. Is it minimalist? Is it a chaotic mess? Does it look like it fits in naturally with whatever OS appears to have been used? Does it look like any thought was put into UI and UX? Those are the kinds of things you're trying to answer.
A README file is usually comprised of text.
Other than that - usually if it has a webpage, it has some screenshots.
README markdown files allow for inline image links to be "expanded"
I prefer install instructions. Not everything is in AUR.
Anyone know of good Gitlab CI or GitHub actions for auto generating GUI screenshots and links them in the README? I only barely know testing tool and frameworks like OpenQA and Robot for GUI. Even better if we can get AVIF/GIF linked in there to see an app in motion.
Honestly though, documenting is a pain enough, I really don't want to be doing screenshot walk throughs on anything I'm not paid to do.
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.
For a lot of open source at the moment the root level readme is fundamentally the homepage too. It absolutely should include screenshots, maybe even a gif. If your software has a GUI or TUI it should follow that a concise visual will do more to explain it's usage than a text document
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)
Hey, all you folks ought to get together and publish a guide to writing good FOSS documentation,
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.
I mean, it's just a suggestion. The utility depends on the goal of the project. Am I being lazy? Don't care. Do I want maximum user engagement/feedback; well, the suggestion is sound.
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.
I mean, yes, it's a little more effort, but I think you're over playing how much effort is required. Writing a half decent readme is vastly easier than frankly any feature or bug fix. Taking a couple of notable screenshots is super easy. Writing docs is hard (I've written tons for large and complicated projects), but readmes are the easiest and including screenshots is really quite easy.
Everywhere supports markdown in readmes now. Literally everywhere I've ever hosted code. And markdown with links to images is perfectly fine even if viewed in plain text mode. They'll just click the link and view the image standalone. I've done that plenty of times, too. Every editor (plus in-browser code hosts in plain text mode) makes it easy.
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.
Nice! I can say i read important readmeโs then :)
Bless you!
Lots of projects are on GitHub or similar repositories and the landing page is usually the readme file as rendered markdown.
I appreciate your joke, I totally got if.
Mainly because my dad would do exactly that if he ever had to use github lol. I grew up watching him literally throw manuals aside, only to have me or my sister bring them back when he screwed up lol.
Too lazy to just look the UI up and you want others to waste their time giving you numerous UI screenshots. Hypocrite
a.) I'm not convinced you know what the word hypocrite means.
b.) More importantly, they didn't ask for "numerous," they asked for one.
c.) Searching for the UI on, say Google, can have, at best, mixed results. Ive done this, then DLed and tried out the program only to find a completely different UI.
d.) The dev adding one screenshot to their readme.md and a /media folder takes them only slightly longer than it takes potential users to look one up and maybe get a good result. Multiply that time by the number of potential users, and it's obviously more efficient, and effective, for the dev to do it.
Stop being defensive. No one's attacking you or any other dev. They're making a request. Don't like it? Don't do it. Stop calling people names and trying to stir up drama.
Edit: formatting
A. When one makes a claim like that when nothing indicated such things, its accepted in the community of behavioral analysis that it was a projection
B. Its implied that there will be multiple and that's irrelevant
C. That's never happened Lol
D. Only takes you slightly longer to Google it too bitch. Don't like what I'm saying you can also stfu hypocrite. You also admit its an attack, as is all criticism right after you deny it. I'm not defending anything, just pointimg out hypocrisy which seems to anger lazy fucks like you who want to leech from good developers like myself and can't be arsed to Google a singe thing