Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a new doc page with links to 'third party' interfaces/plugins. #873

Closed
1 of 4 tasks
gravyboat opened this issue May 3, 2017 · 4 comments
Closed
1 of 4 tasks

Comments

@gravyboat
Copy link
Member

Checklist

  • This is a bug report.
  • This is a feature request.
  • This is a plugin (improvement) request.
  • I have read the contribution guidelines.

Description

We've been getting questions lately about where to share interfaces for Streamlink (#872 and #778) and it would be nice if we had a page in the docs so people could review those. I'm tagging @cirrusUK and @techmouse on this since they've both created some interesting interfaces.

@bastimeyer
Copy link
Member

There are a couple options we have here which should be discussed:

  1. How do we structure this in the main menu?
    1. Adding a "Graphical User Interface" entry directly below the "Command-Line Interface" entry.
      This would somehow divide the documentation from the remaining main menu entries. And third party CLI programs using Streamlink would not fit here.
    2. Adding a "Third Party Software" entry to the bottom.
      This solves the issue mention above.
  2. How do we list different kind of programs?
    1. Use one single list
      Can become confusing when there are many applications listed in no order. (See the livestreamer wiki page)
    2. Group by CLI and GUI applications
      Makes more sense for people who are looking for those kind of programs, but disadvantages programs not listed at the top.
    3. Split CLI and GUI applications and use sub menus
    4. Order applications by name or by popularity / usefulness / quality
      Who will decide this?
  3. What to display in these lists?
    • Name
    • URL
    • Short or long descriptions? (expandable?!)
    • Preview images?
  4. Do we want to build this page automatically (from a json file or so) or should it be static?
    Multiple PRs from different people with possibly different markup can make things inconsistent, so building this page would be better than using plain html.

@techmouse
Copy link

IMO one of the most important parts is the screenshots. They have the potential to convey a lot of information in a very short amount of time. The Livestreamer wiki suffers from a lack of screenshots, and makes choosing an interface a grueling affair, rather than the entertaining one it could be.

CLI (only) and GUI (which can be a mixture of both) should be separate sections. It would be frustrating as a user to sort through each one individually, like one would have to do for the Livestreamer wiki. Consider a site like Amazon. It would be exhausting to search for motherboards and keep finding dresses and fingernail clippers in the results.

Amongst the information that should be displayed, such as the name, url, screenshot and some kind of description, I think there should also be a section for what language it's written in, last time updated, and system requirements (such as supported OS's and any dependencies).

I also think the description should be one written by the community. When you develop something, you tend to see it as a developer, from the inside looking out. But the average person is seeing it from the outside looking in. They see only what their perception allows them to see. So an acuate description intended for the average user should be written by the average user.

I think the best approach to meet these needs is a table who's columns are sortable. So one could sort them by name, supported OS's (a separate column for each OS), last time updated, and even GUI or CLI. Would it be possible to generate this automatically?

@gravyboat
Copy link
Member Author

Hmm, I feel like the screenshots should be on the author of the front end interface to include in their readme. Doing that means we don't have to maintain the images (or more importantly) and store them in the repo so people have to pull them down to work on the project. Automated generation of those items would be pretty difficult unless we imposed some kind of standard and wrote code to pull it in. Right now everything is just 'part of the docs' and was written by hand.

@bastimeyer
Copy link
Member

Closing... #1092

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants