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…
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 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.
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.
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.
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.
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.
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?
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!
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.
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.
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.
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…
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.
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.
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.
Add comment