SALT, Fine Arts App in PHP for online admissions

Date: 
Wednesday, August 11, 2010

Officers Present: Matt, Samrat

Announcements:

Presentation: SALT, Fine Arts App in PHP for online admissions

Presenters: Matt Munsey and Michael Gatto, College of Fine Arts

  • We'll discuss the development process of a PHP-web app for online admissions to SALT and Fine Arts, which began last May.
  • For general public for admission to SALT and CFA.
  • Q: Including people who don't have NetIDs?
  • A: Some do, some don't. It is independent of the NetID system.
  • The student creates an account, submits their information, and satisfies additional requirements including monologues, headshots, auditions.
  • People providing letters of recommendation receive an email from the system, are given limited access to submit their letter.
  • Allows schools to efficiently, quickly communicate with the student, build a relationship early.
  • It was a unique challenge having two systems, two clients, and two external skins. We built it modular, in object-oriented PHP, Zend framework.
  • We followed a few steps:
    • Determine client needs, sit down, "what can be done?", establish time frame, satisfy five schools (within CFA) with different needs, then the college, andSALT.
    • Establish "can we do this?" and "how long will it take?"
    • Refine, go back and forth, regular meetings with user group of admissions managers and business managers, up to 14 clients at any given meeting
    • Talk security, what info is collected, make sure contact information is collected up-front
    • "Meat and potatoes", do we just duplicate the paper app or add more content?
  • Q: Is there anything to verify users, prevent spam?
  • A: They can't post to the internet, so we're not too concerned. It does verify their email address, but it isn't a 2-step validation - fear it would turn people off. System is working well so far.
  • Cannot press "SUBMIT" until applicant has student ID number, though not required to start. It can be a long, involved application process.
  • The next step should have been to storyboard, to allow them to visualize, further define spec list.
  • Q: Using version control?
  • A: Oh, yeah.
  • Visuals would have managed expectations. The client didn't understand technical difficulties, so this would make it more efficient with less wasted changes.
  • The designer/programmer (Matt/Michael) relationship was important.
  • The story board 1) defines the user experience, 2) manages client expectations, and 3) provides a road map for development. It lets the designer step away and develop markup independently, while the developer creates the underlying functionality.
  • Moleskine makes a storyboarding notebook.
  • The development process requires leadership skills: hold firm, be diplomatic. People have different agendas.
  • Q: What did ou use to present mockups/visuals?
  • A: Gatto did quick markup - we should have storyboarded - just the HTML and CSS, borrowing styling from SALT redesign and the new CFA app look under development.
  • Q: I've used Visio, but maybe that isn't flexible enough for the web.
  • A: Storyboarding is helpful, but not a cure-all. You can get the final sign-off on spec and storyboard and protect against feature creep.
  • It is hard to resist the temptation to just start coding until the specs are clearly defined. If specs change too much, you might need to start over. Rapid prototypes lead to repetition of work. Storyboarding is better.
  • The developer and designer must sit down and really define the looks and functionality, collaborate on markup, start on the same page, extend the semantics through PHP and CSS, name variables together.
  • Q: Is the page HTML5 ready - in naming elements?
  • A: Not on this project. It wasn't available yet.
  • We did a lot of screen-sharing programming with Skype, GoogleTalk, in close collaboration.
  • We have to understand the admissions system, know their language, which comes through a defined speclist and storyboards.
  • We set up three servers - Development, Staging (for presentations, user group meetings), Production - trying to keep settings as consistent as possible across them. Don't try to develop on Windows, then switch to Linux, etc.
    • These were self-contained virtual machines.
    • We needed a shared subversion version control, but for now worked independently (one on Mac, one PC).
  • We conducted weekly client meetings to share progress made and address little issues immediately.
    • One such was a year format issue. SALT wanted YYYY-MM-DD, but this confused the others, so compromised on drop-downs for usability.
  • The code was organized very semantically. We used a modified Zend framework and added some Ruby on Rails. The website is broken into folders. For complex projects, a well-organized structure can be replicated for all projects.
    • App - holds models, controllers, most of the PHP code
    • Data
    • Documentation - Gatto began by writing help files for administrators, then switched to using inline references and making it more usable generally.
    • Library - frameworks, reusable code, etc. A loader handles customization, switching based on the current server.
    • Logs
    • Public - where the server hits the application, good for security, everything the public sees is in here
    • Scripts - serverside to mainline scripts
    • Temp
    • Tests - lots of automated tests for different modules
  • Lazarus is a Firefox add-on that autofills forms, a helpful plugin for testing.
  • Q: How difficult is it to verify emails?
  • A: Not hard. They can't check if the person picks up the email, but will check if the domain and username exist.
  • Q: Is there a password reset function?
  • A: We send out a temporary passwoord. We're still building the reset functionality. We do force them to login after registering so that they remember their password.
  • Q: Are the forms database-driven?
  • A: Yup, it knows children, tree, using JQuery (which we love). It also uses AJAX. To add many previous schools, it duplicates the form as many times as needed.
  • We tried not to weed out potential applicants through their technology skills, making it user friendly.
  • Q: Can you go back in the application?
  • A: If you pause, it will take you back to where you paused, but you can only go back once you've reached the dashboard page.
  • Q: Can students review submitted video?
  • A: No. They don't submit videos through the app, only photos and documents. DVDs are mailed. When student checks the appropriate box, an email is sent to the admins telling them to expect the DVD in the mail.
  • Q: Do you validate?
  • A: We validate everything. Validators are part of the Zend framework.
  • Q: Do the applicants go in to check their status?
  • A: Feedback from the department is not done through the system. Students aren't expected to log in to check emails. The faculty is only notified when the application is complete. The back-end has a separate NetID login for the administrators.
  • Q: The backend of who can access applications, how is that known?
  • A: It is not auto-populated from Mosaic. We set up roles manually for who has access to which steps.
    • A lot of that information is available through LDAP.
  • It was a long, arduous process, not even done now. The application will be used for Fall 2011 admissions, should be completed shortly.
  • Q: Any gotchas?
  • A: Documentation sucks! And getting feedback, getting people vested, politics can be tough.
  • Q: Who was the push to start the project?
  • A: Gatto was the push. We already had an admin portal but it was too hard to support, taking his full-time attention.
  • This one uses a modular, object-oriented codebase.
  • You can sign up for dance auditions online, but not for complete scheduling, just providing available times.
  • Q: Are the user accounts open indefinitely?
  • A: No. After acceptance, it is wiped. Things are archived after the semester. The form asks for a student ID number, which doesn't validate but probably deters pranksters.
  • Q: What about security?
  • A: Students provide limited health documentation to see if they qualify for SALT. It is competitive also. But the system doesn't accept super-sensitive information.