Select Web Frontend

[the-maldridge]

We need to select a web frontend. I personally am a fan of VueJS and Vuetify, since that gets us mobile versions for free, as well as native apps if we decided we ever wanted those. I've used VueJS in the past and been happy with it, but its only a suggestion. I have not tried to brand anything with it before.

This thread is to select what web frontend technology we should use.

[scauthen]

I am not familiar with VueJS though it looks very similar to AngularJS. I have been using AngularJS and Bootstrap on the past projects. I can study up on VueJS if that’s the way y’all want to go. I do already have the mobile responsive drop down menus built in Angular (on the apps section), if this format is what you all are thinking for the registration. Yalls opinion?

[scauthen]

I do believe the site needs to be responsive so it will work on any screen resolution (mobile, tablet, computer), especially the page(s) that list the events. So many people use mobile devices these days when searching, it would be good to support this from the get-go.

[gdyoung93]

I think what Stephen has done on Leaderboard with AngularJS has worked well. I don't know anything about anything so you guys can decide what is best. I don't know of any negatives of sticking with AngularJS.

[the-maldridge]

AngularJS is a pretty great framework, but unless you're referring to AngularJS-2 we are risking being marooned on an old version with no migration path. VueJS was designed by the same principal engineer as the original Angular, so it should feel very familiar, but it has a publicly stated maintenance policy. If you're instead referring to AngularJS-2 then this is a moot point, please disregard.

[scauthen]

I have used both 1.7.x and 2.x. I can do some learning on VueJS. I see it has an implementation of Bootstrap. I would prefer Bootstrap for the formatting as I’ve done quite a bit of responsive sites for mobile/pc with it. Yalls thoughts?

[scauthen]

Are we going to manage the front and backend in the same repo or separate ones?

[the-maldridge]

Lets do the same repo with whatever tech you feel most comfortable in. Please plan to put your files in web/.

[scauthen]

Sounds good. I will start some preliminary structures tomorrow.

[the-maldridge]

Please make sure that whatever you're using you have it configured in such a way that it can be made self contained. I've seen more than one "self contained" system bite the dust due to jquery not being available....

[scauthen]

I'll be sure all libraries are referenced locally. I've been looking into Vue this morning.

[the-maldridge]

Thanks! If you use something like webpack, we can probably have two different builds. An online copy that references CDNs for things we want, and an offline version that truly inlines everything.

[scauthen]

I realize phase 1 is the registration system, but as I started developing a general idea for the “theme” it occurred to me we have both consume and administrator pages which will be created. Per the discussion of the total replacement of the dashboard (later phase), are we also looking to revamp the consumer side of the site. The reason for addressing this is that it would affect the overall /web folder structure. I plan to have common headers, footers, etc for consistancy. If this is just for registration, these “theme” files can live in that directory. If a future goal is to theme the entire consumer site the same, these files really need to live in the root. You alls thoughts.

[gdyoung93]

Consumer (public facing) site will be done in Wordpress so it will be its own database. We will include dynamic code inside Wordpress where needed to pull data from backend. We were using mysql and have tested it. This is a good point, if we wind up with another database will we be able to populate dynamic pages in Wordpress. Need to make sure we can.

Greg

On Wed, Jan 23, 2019, 7:16 PM Stephen <notifications@github.com wrote:

I realize phase 1 is the registration system, but as I started developing a general idea for the “theme” it occurred to me we have both consume and administrator pages which will be created. Per the discussion of the total replacement of the dashboard (later phase), are we also looking to revamp the consumer side of the site. The reason for addressing this is that it would affect the overall /web folder structure. I plan to have common headers, footers, etc for consistancy. If this is just for registration, these “theme” files can live in that directory. If a future goal is to theme the entire consumer site the same, these files really need to live in the root. You alls thoughts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BESTRobotics/registry/issues/2#issuecomment-457028934, or mute the thread https://github.com/notifications/unsubscribe-auth/Aswa0OqWsM-h7guW-RFJoKk4HBnSUbR-ks5vGQlggaJpZM4aL1S7 .

[the-maldridge]

I'm not sure I follow your line of reasoning. web/ is the root for the web objects. Nothing above that is serve-able. Basically a release constitutes bundling that directory up into a squashfs, packing that onto the end of the executable, and having a single executable file that runs the entire site and contains the assets it needs to serve. Anything outside the web/ directory is a Go source code file.

Its also worth pointing out that this is a web application, not a web site, and as such I'm asserting that we can have a limited break of style from some other site that may or may not exist. When you go to this application, you're interacting with user data that you have chosen to send to BEST in the context of a screen oriented application, or if you're a hub director, you're doing things that have to do with your hub. This screen oriented UX is of course different from that of a traditional website, and lends itself to different design from that of the website.

I would also look carefully at the tooling that you're using. I am somewhat expecting that you are using webpack to bundle the artifacts from your work into something that can be more easily served (this is almost required for using a standards compliant bootstrap/vue environment). If you'd like, I can send you a compressed archive of another application that was built on this architecture.

[the-maldridge]

Looks like we both were typing at the same time @gdyoung93 Wordpress should access the data from the registry like any other unauthenticated consumer: by making a request and then formatting the data as necessary. Under no circumstances should we every try to sync these databases (I have a mountain of stories of breaking wordpress installs if you'd like to know why). Wordpress manages its own tables, and if we want to have this data on a wordpress page, we can do so with an API call and format it either with JS, or with a plugin that we will write for wordpress, but we MUST NOT attempt to sync the databases.

[gdyoung93]

Fyi I agree style can be different for this from public site. Greg

On Wed, Jan 23, 2019, 7:23 PM Michael Aldridge <notifications@github.com wrote:

I'm not sure I follow your line of reasoning. web/ is the root for the web objects. Nothing above that is serve-able. Basically a release constitutes bundling that directory up into a squashfs, packing that onto the end of the executable, and having a single executable file that runs the entire site and contains the assets it needs to serve. Anything outside the web/ directory is a Go source code file.

Its also worth pointing out that this is a web application, not a web site, and as such I'm asserting that we can have a limited break of style from some other site that may or may not exist. When you go to this application, you're interacting with user data that you have chosen to send to BEST in the context of a screen oriented application, or if you're a hub director, you're doing things that have to do with your hub. This screen oriented UX is of course different from that of a traditional website, and lends itself to different design from that of the website.

I would also look carefully at the tooling that you're using. I am somewhat expecting that you are using webpack to bundle the artifacts from your work into something that can be more easily served (this is almost required for using a standards compliant bootstrap/vue environment). If you'd like, I can send you a compressed archive of another application that was built on this architecture.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BESTRobotics/registry/issues/2#issuecomment-457030576, or mute the thread https://github.com/notifications/unsubscribe-auth/Aswa0DKdHKh5aomdsKc4THmzZ-3OxT7gks5vGQsugaJpZM4aL1S7 .

[gdyoung93]

Agree completely. No attempt to sync. There is no need. Data in Wordpress tables is not the same data as in this (or other) system. Greg

On Wed, Jan 23, 2019, 7:25 PM Michael Aldridge <notifications@github.com wrote:

Looks like we both were typing at the same time @gdyoung93 https://github.com/gdyoung93 Wordpress should access the data from the registry like any other unauthenticated consumer: by making a request and then formatting the data as necessary. Under no circumstances should we every try to sync these databases (I have a mountain of stories of breaking wordpress installs if you'd like to know why). Wordpress manages its own tables, and if we want to have this data on a wordpress page, we can do so with an API call and format it either with JS, or with a plugin that we will write for wordpress, but we MUST NOT attempt to sync the databases.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BESTRobotics/registry/issues/2#issuecomment-457030992, or mute the thread https://github.com/notifications/unsubscribe-auth/Aswa0IKo65J4YDY9NUkkQBhciJv7GkH9ks5vGQuigaJpZM4aL1S7 .

[the-maldridge]

Decision has been deferred to @m-wynn.

[m-wynn]

If nobody has any major concerns, I'm most familiar with React and Semantic UI. Possibly Redux if the front-end data model gets big. It'll optimize everything for a release build and webpack it up as well.

This would allow me to get something up super quickly without having to take time to learn a new technology, and also provides a pretty easy interface for custom theming.

[the-maldridge]

:shipit: