AMY update #2

19 Jun 2015

Today’s the deadline for AMY v0.4. It contains a bunch of usability fixes, so all our admins should be happy :-)

New features

Filtering!: I couldn’t get DataTables to work properly with our backend, but thankfully I found out about django-filter. It’s basically what DataTables is, but works without JavaScript (which in case of our huge data sets is a good thing!). A wide, fluid view was adapted for pages with listings (so that we can put filters in the sidebar). I must admit that I like it.
“New” name: As you might have noticed, we’re switching from “Amy” to “AMY”, to not confuse people with software.
Reports: Thanks to Greg’s work, we now are able to simply report which events are missing attendance figures, as well as display how many workshops, learners or instructors we have over time.
Success/error messages: Each successful form save, or each errorneous action will result in adequate message displayed on top of the page.
Horizontal layout of Find Instructors page: You won’t have to scroll half of the page to get the results, because now the skills take way less vertical space than before.
Search improvements: You can now search through airports, and search for events by their site name. Also, events ordering was changed: soonest show first.
Deleting objects: It’s possible to delete almost any object we have in the database.
Improvements to bulk-upload: Greg made the person-bulk-upload useful! And Giacomo used it recently.
Pagination on airports list: Clicking through our stored airports is now possible.
Fixes to workshop selection for the debrief: Only events that started and ended in the specific period are going to show up.
View/edit icons in object listings: Two icons now make it possible for admins to view object details or go right ahead to editing it.
Event fields ordering: We reorganized fields on the event detail/edit page. Now the slug is on top.
Line wrapping for fields with notes: Some notes had very long lines, but thanks to CSS3 goodness we can now break-up the words inside <pre> tag.
Username visible: Person details page displays the person’s username.
Link to event’s repository and it’s website: If either is provided, we display the other link too. For example, the admin submits only the link to the repository. We parse it and display the link to the event’s website (because it’s way easier to fact-check the website than the repo).

Update 19.06.2015: I forgot to mention that we moved servers! We’re now using Rackspace VPS and have a very clean deployment, plus we’re SSL-only!

You’re gonna miss it

Event “published”: Greg simplified the logic for marking events as published. So now “published” field is gone!
Breadcrumbs: We decided to drop the breadcrumbs. They proved to not be as useful as I hoped.
DataTables: Our listings were pretty big (for example if you wanted to load all persons at once, you’d be waiting for about 10-20s for the site to come up), so to maximize usability we’d have to turn DataTables into “server-side processing” mode. Basically, we’d have to do all filtering and sorting on our end, and that would mean no benefit for us. So instead we switched to django-filter.
Django Admin: We were not using it at all.

What did not land

I’m trying to figure out a way to automate Eventbrite for admins, but from what I can tell it’s going to be impossible unless Eventbrite changes the way it’s working. So I’m holding off with creating Eventbrite events, at least for now.

Features for v0.5

From Greg’s ticket we can gather that most important feature for v0.5 is completing user’s preferred lessons and knowledge domains.