Hey folks, I wanted to kick off an async discussion on a web UI so that we can start thinking about it more descriptively and hopefully get some functionality going.
TL;DR: Design a homepage for /, include Primer as a dep and encourage its use, document use cases for a Web UI with appropriate advise for (not) using it.
We've talked a bit about it before, but the goals of a web UI are to enable a certain amount of configuration and visualization without being inside of a repo (and making new branches/PRs/commits). I think its fair to say that ~80% of the time, a web UI is not necessary and adds an extra layer of complication for the developer. However, I think that folks will still find it useful in case they want to serve their app's doc/marketing/homepage as a web UI.
So, the points of discussion I think we should iron out:
Bouncing off of the ✨ work that @anglinb and @gr2m have been putting into the express functionality, what do you think about having a pre-made (by us) homepage that displays something like "Welcome to the Probot App homepage!" or more customized, "Welcome to the ${appName} homepage!" with an install link. If so, do we pull in something like pug or ejs as a dependencies? Or do we serve this basic homepage as a string (with res.send('<!DOCTYPE...))?
It would be great to include Primer somehow to empower developers to build UIs that can actually integrate with their apps with minimal effort. Examples being some kinds of visualization on the web UI of the app's activities. This big rock is a little held back by Primer's docs, which are currently unavailable but should be up real soon.
What I mean by that heading is that we should define best practices for when UIs should be used and what they should be used for (and importantly, when they don't need to be used). Similar to what we did with the persisting database discussion, it'll help us write documentation and functionality around this if we know what we _don't_ advise people do.
We also need to define what we want UIs to accomplish. I think we can surface more things that are happening within a Probot App (I'm thinking of something with web sockets affecting a UI during a webhook handler).
Looking forward to everyone's thoughts!
I'm 👍 👍 to explore UIs around Probot and form some collective opinions around best practices.
Any hesitancy I have with displaying data outside of GitHub is similar to my stance on persisting data outside of GitHub: I want people to to _try_ to figure out how to do it in GitHub before taking the "easy" way out and building something custom. This will make GitHub better, and will be easier for app developers to maintain (see https://github.com/probot/dco/pull/33 for an example of this).
…what do you think about having a pre-made (by us) homepage that displays something like "Welcome to the Probot App homepage!"
Huge :+1: from me on this. If only for developers to test out that their app is running and point them to resources to develop it, I think it would be worth doing _something_ for the default homepage.
Ruby on Rails renders a default static homepage for all apps in development mode, but if you either create your own public/index.html or map a route to /, it would serve that instead. I think that's a good pattern for this.
It would be great to include Primer somehow to empower developers to build UIs that can actually integrate with their apps with minimal effort.
I like this, but would love to see a few example apps that have UIs before we make it easy and add recommendations.
I want people to to try to figure out how to do it in GitHub before taking the "easy" way out and building something custom.
💯
if you either create your own
public/index.htmlor map a route to/, it would serve that instead
Makes sense to me. I know that there was some trouble going on in #254 for overwriting a path (so the latter option of mapping a route to /), but it seems like that'll get ironed out soon.
Something that would be really cool is to have the name of the Probot App in the homepage, rather than a completely generic page. I'm thinking that it could take the name field from package.json.
Also, on the topic of a public folder; we can use express.static() to have a static folder and make it real easy for people to add that in. Out of curiosity, I just tested it out and express.static() does in fact serve index.html on / by default 🎉Again, not sure how it would react when a route already exists; I know that express prioritizes routes based on when it registers them, so it could be tricky to implement.
would love to see a few example apps that have UIs before we make it easy and add recommendations.
Agreed. It's hard for us to guess what people want and will use. I do think that we should add a page to the docs so that folks at least know that it's possible, otherwise they just might not think of it and we'll never hear see these examples.
I would suggest that we leave the / root path for app-specific UI and provide a generic probot UI at /probot. If the app does not define a root path we can redirect to /probot
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
I would suggest that we leave the
/root path for app-specific UI and provide a generic probot UI at/probot. If the app does not define a root path we can redirect to/probot