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…

  • @TCB13@lemmy.world
    link
    fedilink
    English
    1742 years ago

    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.

    • @TCB13@lemmy.world
      link
      fedilink
      572 years ago

      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.

      • jecxjo
        link
        fedilink
        English
        172 years ago

        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

      • urshanabi [he/they]
        link
        fedilink
        22 years ago

        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.

    • @s20@lemmy.ml
      link
      fedilink
      32 years ago

      This is good advice, but having a screenie there in the first place might make someone more likely to try it out.

    • southsamurai
      link
      fedilink
      12 years ago

      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.

    • @KevonLooney@lemm.ee
      link
      fedilink
      02 years ago

      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.