Footers

I was poking around the app some more yesterday morning and noticed that the footer was only appearing in the homepage when the user wasn't logged in. In most websites, the footer is part of the overall website template, so it almost always appears at the bottom of every page. Thus, I decided to move the footer code from the main page layout view to the application view so that it would be rendered on every page.

After moving the footer code and checking some pages on the app, I thought that everything was good. Then, I decided to sign out and then sign back in and discovered that the footer was not "sticky", i.e. if the content of the page was not tall enough to push the footer to the bottom, then the footer would just appear somewhere in the middle of the page. So I set about looking for solutions to this issue. I found several sites that listed out possibilities for getting the footer to work, but this site provided the best instructions. I had to adjust the margin padding to fit the smaller (84px) size of our footer, but other than that, the code worked pretty much as is. It is very important to add the CSS for having the height of the html and body set at 100% (I forgot to add this in the first time and nothing worked).

So, once again, I though I was done, but not so fast! I did more testing yesterday afternoon and found that the challenge category descriptions were still displaying the footer in the middle of the page. I looked through the views for these pages and discovered that the text had not been placed in a separate container. So, I wrapped the text in a new section and container and put some padding between the text and the title for each description page. I also changed all the line breaks to paragraphs, since this allows for cleaner and more flexible styling. Once these changes were complete, the footer "stuck" to the bottom of these pages as well.

Forgot password?

I was doing some more testing of our app yesterday--basically just trying sequences of actions that I could see a user doing. While doing this, I ran into an issue with the "Forgot Password" link that is displayed on the login form. When I clicked this link, it displayed a form where I could enter my email to have my password reset (which I had to restyle with CSS since it had accidentally been missed when I had redesigned the login and signup forms). However, when I clicked the button to have the application send an email to the provided address, the app blew up with an error message that said (in the true cryptic fashion of most error messages): "Missing host to link to! Please provide the :host parameter, set default_url_options[:host], or set :only_path to true". Essentially, this was telling me that the mailer for the application was not set up.

So I did some googling and found this blog post on mailer setup and this related blog post on environment variables. I was able to modify the instructions in the first blog post (with hard coded values for the mailer settings since at this point I just wanted to make sure it worked) and added these lines to the development.rb file (since I was just testing it locally):

  config.action_mailer.delivery_method = :smtp

  config.action_mailer.smtp_settings = {

    address: "smtp.gmail.com",

    port: 587,

    domain: "domain.com",

    authentication: "plain",

    enable_starttls_auto: true,

    user_name: "user@domain.com",

    password: "password123456"

  }

Obviously, the domain, user_name, and password fields are just filled in with nonsense values for the purposes of this example, but, for testing, I filled them in with my gmail account information so I could make sure everything was working. I also added this

  config.action_mailer.default_url_options = { :host => 'localhost:7777' }

to the development.rb file so that the mailer would work on the localhost setup (port 7777 is used instead of 3000 because we have Facebook authentication).

Once these changes have been made, the server needs to be restarted in order for the changes to take affect (which I forgot the first time and therefore spent several frustrating minutes trying to figure out what I did wrong).

Now, to ensure that the username and password for the mailer is not available for anyone with some computer skills to see, environment variables need to be used. This is where I need to discuss how to handle this with my teammates, since it appears that this requires setting up another gem called "foreman", which changes quite a few things about the app (including how the webserver is started) so we need to make sure that this will work without breaking other parts of the app. Fernando also has the same issue with code that he had added for a contact form so we need to figure out how to hide the username and password from the rest of world.

Presentation reactions

Today we had the final round of practice presentations before the final. Each of the groups showed improvements over their previous presentations, though there were still some a few issues to work out before the final. My reactions:

Automaton

• The explanation of the app was much clearer and easier to follow than last time. I liked that they had included a slide explaining the more important parts of the game.
• The demo itself was also a little easier to understand (and I noticed that they added tooltips over the icons that are dragged and dropped onto the main board). However, if I was someone who was using this app for the first time, I feel like I might really struggle to understand what is going on and what is expected to complete a certain level. My suggestion for them would be to include a demo tutorial on a simple level so the user can see how everything works before they start on their own.
• Handout is good, but I agree with Fernando that the blue is too dark. I looked back at their previous hand-out and the blue on that one was much lighter (maybe due to using a different printer) and was much easier to read.
• The presenters themselves did better than last time, though the demo did seem to go by really fast, so slowing down the talking will probably be good for the final presentation.
• They mentioned that a user can create and upload a level but didn't demo it...maybe this could be something they could include as well to add some time to the presentation.

VisualScheduler

• The slides had more of an impact this time, especially the one containing the ridiculous number of windows that you must click through just to find and register for once class on myUNM (though the sheer number of windows also made some of the text on the slide go out of the display zone, so this should probably be fixed).
• I noticed that they had moved the calendar feature to be below the list of classes. Personally, I'd prefer it in another tab as well since I hate scrolling, but this way does provide a quick way to check if your schedule has conflicts.
• Not related to the presentation, but I like their addition of the automated schedule generator. That is a pretty nice feature since I (and probably every other student at UNM) has to go through the agony of trying to determine how to create a "nice" schedule that includes all the classes you need to take.
• Also noticed that Zach kept looking up at the slides and turning his whole body away from the audience, which was distracting and seemed to imply that he was really relying on the slides for guidance instead of just turning to them to point something out, gesture to something, etc.

G.E.R.A

• Not sure exactly how to spell G.E.R.A. Is it is G.E.R.A or G.E.R.A. (with a period after the "A"?). The slides had both versions while the handout and the website only appears to have G.E.R.A (with no period after the A). I would assume that since it is an abbreviation, it would have the period after the A, but I'm not sure what they are going for.
• The handout was much easier to read, though they did include a pie chart on a dark background with tiny, dark grey text that was impossible to read. I think that this should either be removed entirely or the colors should be changed. 
• They mentioned spendable points during the presentation but didn't really explain what exactly these bought. I'm assuming that it would be buying things from the "Armory", but it wasn't really clear.
• The presentation itself was much improved. It appeared that Ben made a real effort to memorize his notecards, which helped a lot and made the presentation flow better and look more convincing. He did mess up on one slide, but if he can power through his mistakes instead of focusing on them, I think he will have a pretty good presentation.

Presentation meeting

Yesterday we met to finalize our presentation. We finished adding in information about the competition and some statistics on the decline of educational performance in America (related to the need for our Intellectual challenges). I also made a few changes to the CSS for the homepage, reducing the height of the footer so that it was not overly large in comparison with other elements on the page. Additionally, Matt S. noticed that the "Abandon" button (allowing the user to abandon a challenge) was disabled when the check-in button was disabled. This was because, originally, this button was meant to be the "Fail" button but we found that this really didn't serve a purpose in our application so we changed it to "Abandon." Given the new context of the button, the user should be allowed to abandon a challenge whenever they want, so the disabling was removed.

Fernando suggested integrating a FAQ into the website, which he created a Google doc for. I think this is a good idea since having a quick reference guide for the user can be quite helpful for improving the overall user experience. I have been adding to it (as have Fernando, Matt S., and Matt F.) so hopefully we can get this integrated into the website this week.

Over the next couple of weekends, we will probably meet to run through the presentation so that it is smoother than last time and so that we can work through any bugs (such as the Facebook fiasco during our last presentation). I do hope that we can get access to the room where our final presentation will be held prior to May 13th since this would be very helpful for making sure the presentation goes as smoothly as possible.

Regarding marketing, I have been posting to my Facebook page via Demigod, so maybe it will entice someone to check it out before our final demo. I also plan to giving the link to a few friends and family over the next few weeks so they can try it out. It might also be a good idea to post up a few flyers around campus...you never know who may bite!

Presentation and code fixes

I worked on the presentation a little today. I added information about Demigod's competition (Fitocracy, DailyBurn, etc.) so we can utilize the Goldilocks method to justify why Demigod is different. I also broke out the "three stages to implementing healthy behavior" into three separate slides and added information on how Demigod helps users move through these three stages and build healthy habits.

We still need to work on a conclusion slide, as well as adding "intelligence" statistics (i.e. justifying why we are incorporating an intelligence category of challenges into our website). We also need to reduce and/or condense the amount of facts that we were previously using since having too many just bores the listener and takes away time from other important areas, like the demo.

I also worked on fixing an issue with our app that had been annoying me for quite awhile. We had incorporated a drop-down menu in the right side of the navbar. This menu has the user's name on it (as you see in most websites) and, when clicked, it displays a list of links relevant to the user (their created challenges, their completed challenges, etc). However, if you clicked the user's name again to close the drop down and then moved the mouse so it was no longer hovering over the name, the text for the name would turn dark grey (instead of white, which is the color it is supposed to show when the mouse is not hovering over it). I spent a good thirty minutes going through the CSS for the navbar in the Chrome's Developer Tools panel, trying to figure out where this color was being set. After some trial and error (read, "playing around") I finally discovered that I had to set the color and background-color properties of the default navbar "hover" and "focus" properties for the navbar links. This solved the problem and now the link is white when the menu is closed and the mouse is no longer hovering over the user's name in the navbar.

Finally, I added some text to the current challenge partial which tells the user how many check-ins they have to do for a given week. To improve this, I might end up adding another Ajax call to get the time and date when the user can next check-in (since we restrict check-ins to once per 24-hours).

Facebook button mods and more javascript

Last night, I made some modifications to the Facebook button we had been using. When taking a challenge, the user has the option of sharing their current progress. This had been displayed originally as:

I had done this original styling of the Facebook button, but it was more a temporary fix than anything else and didn't really match up with the color palette or design of the rest of the site. Also the placement below the check-in and abandon buttons just made the current challenge display awkwardly large (vertically). I found a simple Facebook "f" symbol from the (thousands!) of FB images littering the web and then used Photoshop to add some text (using the default font for our app). The text was specific to our application so I felt it worked better than the generic "share on facebook". I also decided to move the button to be in-line with the check-in and abandon buttons rather than below it since this looked cleaner. The result:

I also feel that the darker blue fits better with the other colors. I used this same blue color for the "share to facebook" button that appears when the user finishes a challenge. Now the Facebook buttons are at least consistent.

I also added a simple check for these buttons to determine if they should be displayed. Obviously, if a user is not logged in through Facebook, then these buttons should not be displayed because they will not work (and will actually cause a server error if clicked). Hence by adding one line prior to each button display in the current challenge partial view:

-unless current_user.auth_token.blank?

I was able to determine whether or not the user had logged in with Facebook (if the auth_token was blank, then the user was not logged in with Facebook).

While modifying the Facebook buttons, I also added some more Javascript to the current challenge partial. This code checks if the user has finished a week and then displays the time and date when they can start checking in for the next week. This information is also displayed in the modal that pops up when a user finishes a week, but this only displays once for a given week so the user could easily forget when they can start their next round of check-ins. Adding this to the current challenge fixed this issue.

Modal styling

I finished up restyling the new challenge modal so the layout was a little more uniform. I decided to change the overall layout of this modal to be two columns since there is so much information to enter for a new challenge. If the elements are just arranged vertically, then the user has to scroll the modal a little to get to the bottom (unless they have a fairly large screen). However, I did add some extra CSS to ensure that this two column layout is not used for a mobile screen size. In this case, the layout defaults to vertical so horizontal scrolling is not necessary.

To actually change the modal width so that the two column format would display, I had to do some googling since it was not a straightforward process (i.e. you couldn't just change the width property for the modal and call it good). After some false starts, I eventually found a solution that worked:

.modal.modal-wide .modal-dialog {

  width: 62%;

}

.modal-wide .modal-body {

  overflow-y: auto;

}

This allowed the width to be scalable (since it is a percentage), without causing the modal to jump to one side of the screen (which is what happens if you just try to set the width for the modal instead of the modal dialog component). As I was reading on stackoverflow.com, apparently you used to be able to set the width property for just the modal prior to Bootstrap 3.0. In Bootstrap 3.0 and later, you have to set it for the modal-dialog property (though it wasn't clear exactly why they changed it). The overflow-y CSS property tells the modal how to behave if the content overflows the top and/or bottom of the modal's area. Setting this property to "auto" just says that the default behavior should be used, which in this case, is scrolling. So scrolling will be implemented in the content overflows in the vertical directions.