mattxwang / fair-chair Goto Github PK

Not sure how I'd do this (probably involves squirrel) but have the application auto-update, on Windows, OSX, and Linux.

• AutoUpdate on Windows
• AutoUpdate on OSX
• AutoUpdate on Linux

There will eventually be a website that describes what Fair-Chair does, has screenshots, etc. Not a huge priority, but it'll be ready for a 1.0.0 release.

Eventually, using a CI to deploy + publish would be significantly easier, more convenient, and would help with bug-fixing. Probably going to use Travis for this.

I technically have access to both Windows and Linux machines, but I haven't created distributable on them.

• working Windows distributable
• working Linux distributable

It'd be nice to have some sort of mechanism to save the state of the timers and speakers lists, so the program can be used across different committee sessions. My plan right now is to export the list and timer data in a JSON file, and have the user load in a JSON file if they want to, which will replace the current data in the program. In addition, there'd be an export button somewhere.

The Travis Build Script doesn't work: it runs npm start, which in turn runs electron .. Unfortunately, electron isn't being recognized as a command in my $PATH on Travis build, so hopefully I'll figure out a solution to that sooner or later.

I'm not entirely sure how I want to do this (probably needs some more component-ing of each element), but a few things I want to accomplish in regards to manipulating the list view elements:

• Allow the toggling on/off of list view elements
• Have the rest of the elements fill the entire space
• Allow the dragging and repositioning of elements
• Allow custom sizing

Currently, when building the app using electron-packager, the custom Mac app icon doesn't load (and as a result, the distributed .app uses the default electron icon). I'll try to figure out what's wrong, and hopefully have a nice icon for dist!

When I originally wrote this app, I did it very quickly and haphazardly - as a result, it isn't coded as how an Angular web app should be (or how any web app should be coded). So, the first order should be to split up main app into several (reusable) components.

I'm not sure what each of those components will be, but off the top of my head this is what they probably will be:

• Nav Component
• Nav Item Component
• Generic View Component
• Generic Button Component (likely from Angular Material)
• Generic Modal Component
• List Card Component
• Timer Component
• Header Component
• Delegate List Component w/ subcomponents as needed
• Guide Card Component (collapsible)
• Some stuff w/ settings (this might be reimagined)

As an example, when in a GA, a dialog box could show up below the delegate field that shows 3 items (for example) that best fit the currently entered text. This could serve as an aid when entering many countries quickly is needed, i.e.: all the time. Additionally, flag icons could be loaded next to the autocomplete as a visual aid. Another option is allowing the loading of CSVs that contain the delegate name, and an optional image. This could allow pre-configured autocomplete options for crises, or other specialized committees which could use names instead (for example).

Just to remove some inconsistencies and make contribution easier-- some possibilities:

• Standard, through https://standardjs.com/#typescript, to remove bikeshedding
• ESLint, through https://www.npmjs.com/package/typescript-eslint-parser, to configure things to your liking (used by standardjs, but already configured), or use a pre-existing configuration
  • https://github.com/airbnb/javascript
  • https://github.com/gajus/eslint-config-canonical

It would also make sense to create an npm lint phase that runs on CI to ensure code quality in pull requests.

Right now, we load in Bootstrap and jQuery, but we probably shouldn't (both performance and code complexity reasons). As @meme suggested, I think it'd be better if we used Angular Material.

(for myself) Explore the options for UI testing in Angular apps

Create a testing suite that is composed of unit tests for internal application logic, then UI tests for the actual Angular front-end. This would be vastly superior to re-running the app every time a feature is being developed (can also be used to triage issues)

I'd like to work on this project a little more, yet some ideas do not warrant a GitHub issue or they are just spitball ideas, so to speak. Perhaps it would be a good idea to have a chat room that allows contributors and users to discuss the software. Some options:

• https://gitter.im/, just log in with your GitHub and make a chat for fair-chair
• https://discordapp.com/, create a Discord account and a Discord server (preferred option)
• https://telegram.org/, not everyone has an account for this
• https://slack.com/, it is quite terrible for open-source communities in my opinion, due to the difficulty of having people join