-
Notifications
You must be signed in to change notification settings - Fork 140
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
Dashboard Facelift #524
Dashboard Facelift #524
Conversation
Few months late, but thanks for sharing this! I like the dashboard styling, and the housekeeping and new worker routes on api.py are cool too. Similar motivations to you, I'm partial to keeping the JS within a framework I already sort-of know (Vue.js). I'm going to work on merging in a lot of this though. |
First pass at extracting just the API changes from #524
psiturk/dashboard/__init__.py
Outdated
'\nRefusing to start.' | ||
)) | ||
login_manager.init_app(app) | ||
with app.app_context(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is cool
psiturk/api/__init__.py
Outdated
|
||
# POST: Set the services manager mode | ||
# mode: live or sandbox, the desired mode | ||
def post(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm uncomfortable with this -- I think the api shouldn't have any inherent concept of a session. The dashboard, on the other hand, can conceptually know about a session.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, my argument above probably means that the api shouldn't know about any services_manager either.
This was mentioned in an issue so I figured I'd create a PR so more people are aware of a restyling of the dashboard I've been developing and using with my lab. It seeks to solve the overflowing layout problems and responsiveness that exist in the current dashboard, and bring web browser functionality up to par with the CLI's capabilities. It's been super useful so far, especially for our lab manager and members who are far more comfortable in a browser interface than in a shell.
Unlike the previous dashboard which used Vue.js, this one is pure vanilla JS, powered mostly by a data viewport module I built a couple years ago and revamped here in dbview.js and dbfilter.js. The central layout on each page is the database and filter viewport on which you can apply any column-based comparative filters you want, and then a more customized pane depending on the functionality of the page. Actions like approval and bonusing can either be performed individually or on the visible rows in the database viewport. Said actions are handled in modals, as seen in the screenshots attached.
It should be comfortably responsive, and has worked well on my phone, but I have yet to test on a higher resolution than my laptop.