Practice pitches. Second round (III)

The second round of practice pitches has completed last Monday. This time, it was the turn of Automaton, VisualScheduler, and G.E.R.A. I am going to discribe their pitches and my reactions, as well as the reactions from others in class (classmates and Professor Ackley):

- AUTOMATON

• They used 3 speakers again. I think they should cut it to 2.
• Good introduction, the slides flew smoothly...
• Basics of Automaton. From my point of view, the best improvement, because this time, the explanation about how the game works was much more accurate than in the first presentation. The slide they used to this part of the pitch was very clear.
• Live demo. Several examples (much better than the first round) and test, from the simplest to hardest ones.
• They had time enough to complete the pitch (1 minute before the time limit). In this sense, a classmate suggested speaking a little bit slower.
• Other classmate proposed comparing Automaton with other applications (if any).
• Ackley suggested not to read from hand cards when speaking, and avoid using pronouns to refer teammates (use their names instead, much more professional).

- VISUALSCHEDULER

• This time, they focused on comparing their application with the old method used on the UNM. 
• Good coordination in general, the slides flew well.
• They also explained how they will generate revenue of the project.
• Spreading the world: Basically Facebook and Twitter, fair enough in my opinion.
• Live demo: Some minor problems when trying to show an example. Anyway, they clearly explained how the schedule builder worked. They went through a real case for the next semester. Nice demo.
• The schedule generator is going to be a premium feature ($5/month)
• The website will be available on October.
• Their pitch fitted with the available time.
• A classmate suggested trying the application with volunteer students. Good point!
• Ackley liked the schedule generator and the presentation itself. I also believed that their second pitch was slightly better than the previous one.

- GLOBAL EMISSIONS REDUCTION ALLIANCE (G.E.R.A.)

• They changed the dark background on the handout. Much more legible this time.
• The problem: They used the Goldilocks Method to justify the creation of their app.
• Similar apps: Again, they went through two kinds of applications ("Pure game based" and "Pure data entry"), explaining their pros and cons. Then, they showed the advantages of Demigod, which gathers all of both approaches in the same app (Goldilocks).
• Approach: "A gamified of carbon emissions tracking" (good definition). It uses real data and it is focused on the real world impact by engaging stories or missions. Thanks to these missions, users can win spendable points as well as unlock badges.
• Live demo: The first time an user logs in, a "step by step" tutorial is displayed (I liked it!). They showed how the missions worked, and how users could create their own missions. In general, the demo was OK.
• Unfortunately, Ben forgot part of the pitch in the middle of the presentation. But this kind of things usually happens. 
• Ackley told them that they spent 5 minutes on the introduction. I agree, in fact, I think they should cut some time from the comparison between G.E.R.A. and other apps.
• I particularly liked the statistics page (nice charts).

Last team meeting

Yesterday morning, we met together in order to start preparing the final presentation. We checked again the classmate's feedback of our last practice pitch (both from the question time and some blog posts), as well as Professor Ackley comments.

In my last post, I wrote about our weaknesses during the last practice pitch. Our main goal was to fix all these things, trying to improve the slides in some way. Therefore, we spent two hours redesigning the slides by:

• Removing several facts and statistics (a cleaner design means easier to follow for the audience).
• Adding three new slides corresponding to each one of the stages of a Harvard study for changing to a healthy behavior (Preparation, Action and Maintenance).
• Removing the technology choices slide. Instead, Matt S. will talk about it during the demo.
• Searching other applications and websites that provide similar services as Demigod. 
• Based on the previous research, creating a slide named as "The Competition" in which we compare and contrast Demigod with other apps. We would like to justify the creation of our application, and the Goldilocks Method should be the easiest way.

Additionally, we made some changes on the footer of the website to adapt its size to the mobile version. Besides, we removed three small rounded buttons that we initially add to eventually link whatever we need, but finally we did not find anything to link, so we decided to cut them out.

As we had a lot of interesting stuff in our presentation slides, I suggested to use it in order to create a new Frequently Asked Question page in the website. This page will include different paragraphs with commonly asked questions and information about our website, so we will use some data from the slides, but we will have to add new things to complete the page (I created a new Google doc shared with all the team members, so that now we all are able to add new stuff.) 

On the other hand, I also proposed creating a new Contact section. Basically a simple form to provide users a way to contact us directly if they have any question or problem that needs support. In this sense, I think that put an email address instead of a form is obviously much simpler, but this may lead in spam issues. So if we have time enough, we will create this new section.

Practice pitches. Second round (II): Demigod

It is time to evaluate ourselves. This week we had a second chance to show our project to the rest of the class, and practice the final presentation, which is going to be held next May, 13.

We prepared a new handout, much more simple,  and including just a couple of keywords. This was one of the task I did last week, and I am think that the new design is much better than the first handout version. However, I made a grammatical mistake when writing the text on the handout: "Improve your health, fitness, and nutrition through challenges that help you build heathly habits and create the lifestyle you want"

A classmate noticed that there was a mistake on the text, and he told as where it was. So, I fixed the error (heathly" to "healthy) just after the Monday's class. I think it is always good to accept your own errors, and the handout was my responsibility.

Apart from the handout mistake, these are my reactions on the pitch itself:

- Matt S. spoke more fluent in general, but we still had too many facts in the first part of the pitch. We definitely have to cut down the number of facts and references about the current state of America.
- Despite testing the slides on Matt F's laptop before the pitch, we had problems (again) with the screen resolution.
- The demo was more interesting in general, because we change from a prerecorded video to a live demo.
- On the demo, we made another relevant mistake when Matt F. tried to login via Facebook using his account, and it did not work (his account was blocked). We should have tested it prior to the demo. Anyway, next time we are going to use my account, or the one of Natalie.
- We should deal somehow with the potential cheating made by the users.

Reactions from classmates and Professor Ackley:
- A classmate suggested speaking a little bit more about the intellectual challenges, because we talked too much about the nutritional/physical challenges (tons of studies and references about the body, nutrition, etc.)
- Ackley said that we spent a lot of time in the first slide.
- Compare our application with the competence. It could lead to the use of Goldilocks Method, which may be interesting in my opinion.
- Avoid using the "Our solution" slide.
- Hide Ubuntu's sidebar when displaying the slides (i.e., use fullscreen mode).
- Use short challenges on the demo, for example, a challenge that needs only 1 check-in along 1 week. This would allow us to show how a success challenge looks like.

Based on the mistakes we made, and especially on the feedback we got, we will try to prepare the final pitch. Only 15 days left...

Practice pitches. Second round (I)

Last Monday, we had another opportunity to show our project to the rest of the class and practice the final presentation, which will be held in just a couple of weeks. However, on this post, I would like to focus on the other two teams, leaving our own pitch comments to my next entry (maybe next Friday or Saturday).

So, these are my reactions and comments to second round of practice pitches (MechanApp and Powderade):

- MECHANAPP

• Again, a clear, clean and solid presentation. No major mistakes in general. I think they did the best pitch so far.
• They cut the number of speakers to 2 (there were 3 last time)
• The handout was pretty similar to the one of the first practice pitch (but it is good!)
• They started the pitch introducing themselves, and then, they went through a brief introduction, main goals of the app, and a justification (Why MechanApp? -> Basically do it yourself, saving money and improving your auto mechanical skills).
• Business model -> revenue: targeted advertising 
• The demo was again very good, perfect execution, slightly better than the first pitch. They chose a specific car, model, and year in order to give an example. The app guides you through different possible workarounds. This system reminded me to the Troubleshooting problems system of Windows.
• Awesome design. I believe it is actually the strongest point of this project.
• They also explained how the Greedy algorithm worked by showing a tree structure and using other real example at the same time. Key-point of the app: It statistically learns from previous problems, and intelligently selects most likely causes for the selected vehicle first to investigate.

- POWDERADE

• Major changes in the way they organized the pitch.
• This time, they only used the video to show the demo (much better!)
• The handout was not bad, but I believe that they can easily improve it (they should reduce the amount of text).
• They started comparing Powderade with other existing skiing and snowboarding apps such as Snocru (Goldilocks method).
• They talked about the different achievements (speed, GPS stuff, distance, etc.).
• They also mentioned a Facebook sharing feature, which will be available coming soon. In my opinion, they should not have said nothing about it...
• They made an important mistake when tried to play the demo video using Youtube (the movie did not load). Fortunately, they finally managed to play it, but it would be interesting to play a local copy of the video instead. Anyway, the video was focused only on the demo itself. It was OK, but I believe that they included images recorded with an on-board camera along too much time. In my opinion, these kind of images distracts the audience's attention, and besides, they do not match with the information they display in the demo.
• Technology choice justification was OK in general. However, Ackley suggested moving all the Technology choice stuff before playing the video (demo). I agree.
• The application will be available on Google Play for the next winter season.
• A classmate suggested (again) that the name of the app is quite similar to "Powerade" (the sports drink). It could be overlooked by the team, but in terms of marketing may be a trouble to promote the product, especially in online search engines. Anyway, I think it is too late to change the app's name...

Creating static pages on Rails

Recently, I had to create three new pages for Demigod's website. These pages had a common characteristic, because all of them were based on static content (i.e., no data or information collected from a database, user input, etc.). So, I needed three pages to write a description of one each of the categories that we use to classify our challenges (Nutritional, Physical, and Intellectual).

I started creating three separate actions in the home controller (/app/controllers/home_controller.rb):

class HomeController < ApplicationController
  (...)

  def nutritional
  end

  def physical
  end

  def intellectual
  end
end

Then, I added the corresponding routes for each one of the actions (/config/routes.rb):

get "/nutritional", to: "home#nutritional", as: "nutritional"
get "/physical", to: "home#physical", as: "physical"
get "/intellectual", to: "home#intellectual", as: "intellectual"

Finally, I generated three new views to display the content itself (app/views/home/category_x.html.haml). I wrote the static content (in this case, just text and a linked button above the text to the sign up form) using Haml, which is quite similar to HTML. In fact, the easiest way from my point of view is to write HTML code and use an online converter to get the Haml code.

After that, I was able to easily add links to the the new pages from the homepage (/app/views/home/index.html.haml), for example, this portion of code corresponds to the Nutritional link in the homepage:

(...)
%p
  = image_tag("nutritional_icon.jpg")
%h3{style: "text-align: center;"}
 %a{href: "nutritional"}
   Nutritional
%p{style: "text-align: justify;"}
 Keep your body healthy and follow a better diet thanks to several interesting challenges...
#more-btn
 %a.btn{href: "nutritional"}
   more

Eighth client meeting reactions

Less than a month to finish the Spring semester, so we have just a couple of weeks to complete our project. The last client meeting took place last Wednesday with Nikan. We basically focused this meeting on the demo, which covered the following topics:

- Homepage. New module with links/icons to categories descriptions.
- Three new static pages with full descriptions of each category (Nutritional, Physical and Intellectual).
- Profile page: New design features (icons, progress bar, stats simulation, Facebook progress sharing button, etc.). Now, the progress bar color fits with the color pattern.
- Challenges page. Design (color pattern), new popup with information about the selected challenge (design).
- "My Challenges" section. New label system and "Finished challenges" feature.
- Check-in: The number of check-ins you have already done, as well as the current week are now shown when you check-in (Good job Natalie!)
- Mobile version: some improvements regarding the functionality.

Nikan's reactions and questions:

- The default avatar picture was Ok, but she thought that it should be smaller, because its size was, for example, much bigger than the Demigod's main logo. This did not happen in the mobile version.
- She liked our mobile version: "It is a positive point of your project".
- Nikan also asked about the performance of our application. Matt S. was working hard to improve it, and now, the website runs faster.
- She asked about the sorting criteria to show the challenges list (it is random so far).
- Nikan suggested to add a challenge description into the progress bar (as a reminder of what you have to do).

Next action:

- Prepare the second practice pitch.
- Progress page
- Descriptions for all the challenges
- Beta tests (family & friends)
- Looking for bugs and fix them (if any)
- Start thinking about marketing...

Ubuntu on Virtualbox. Screen resolution optimization

As I explained in one of my first post about the CS 460 project, I was running Ruby on Rails a virtualized instance of Ubuntu 12.04 LTS x86 using VirtualBox. Matt S. recommended me to use Linux instead of Windows because the ROR installation was much easier, apart from the fact that all this software is free.

I have been working along more than two months with ROR on Ubuntu, especially focused on the functionality of the application. However, a problem came up when we moved to the design, because my virtual machine could only be set-up to a resolution of 1024 x 768 px., which was not good in terms of design tasks. For this reason, I had to figure out a way to improve the screen resolution of my Ubuntu installation, and I finally got it after a research on some Internet forums.

In fact, there exists a resource to easily get better graphic performance, which is named "Virtualbox Guest Additions". By default, VirtualBox provides graphics support through custom virtual graphics The Guest Additions is a package available for Windows, Linux, Solaris, OpenSolaris and OS/2 that includes a special video driver for increasing video performance and also includes additional features, such as automatically adjusting the guest resolution when resizing the VirtualBox window or selecting fullscreen mode.

The installation is quite easy. In Ubuntu, open a terminal and run:

> sudo apt-get update
> sudo apt-get upgrade
> sudo apt-get install dkms

Then, you have to reboot your guest system in order to activate the updates. Again, open a terminal and run:

> sudo apt-get install virtualbox-guest-additions-iso

Once I installed the VirtualBox Guest Additions, I rebooted the Virtual Machine and selected "Auto-resize guest display" on the "View" menu. This allowed to see an optimal resolution depending on your screen (anyway, higher than 1024 x 768 px.). Thanks to this package, now I am able to work with the Demigod's design properly; even use my laptop to display demos in client meetings.

Practice pitches. First round

Today, the last three teams have showed their projects to the rest of the class.  We presented our project the past week, because the fact of being volunteer for the first round of pitches seemed as a "professionalism" point. However, from my point of view, it is a significant advantage for the rest of the teams, because they saw other pitches before they prepare one. So, they realized the most common mistakes, the strongest points, the professor remarks, etc., and they could take into account  all of them when you face your own practice pitch.

Anyway, these are my reactions to the three projects presented today:

- AUTOMATON

• 3 speakers in total. I think they should cut it to 1 or 2.
• The handout was OK. Colorful and just a couple of words.
• Good description and goals.
• The demo was good in general (maybe slightly long).
• It seems like people did not understand how the game exactly worked.
• They should  probably add a detailed legend, and accurate explanations about the rules (tooltips).
• Nice design, especially dialog windows when success, stats and game selection (UX).
• They may consider hiding advanced options in the earliest levels.
• They did not stop the demo while they were answering questions. This may distract the audience's attention.
• Game already available on the Internet (good point!)

- VISUALSCHEDULER

• Good intro and problem definition
• They are focusing on the UNM current schedule system, but this system may be exported to other universities.
• The demo was OK, but they didn't handle the time properly because they finished their pitch 3 minutes before the minimum time (7 minutes). This produced an awkward silence...They finally improvised an example, but it looked like something unprofessional.
• The application seemed very useful for students. Some classmates suggested splitting the calendar and the search parts in a different way in order to be more clear for the user (now, they are using tabs).
• Too much text in the handout
• User accounts (save and edit schedules), to be implemented. They should try to do it as soon as possible because it is an important feature.
• It is going to be free, with premium accounts ($3/semester) that allow user to use some options like waitlists, etc.
• A classmate proposed the possibility of having records of previous semesters (like a user history). It sounds good in my opinion.

- GLOBAL EMISSIONS REDUCTION ALLIANCE (G.E.R.A.)

• Handout: too dark background color.
• They justified the creation of this app by using the Goldilocks Method. Initially, they set the problem, and then they said that nowadays there exists basically two kinds of applications related to global emissions: games and user-data based. G.E.R.A. is combines these two worlds in just one app.
• Goals well defined. They want to encourage users to help the environment in some way by taking part in different missions.
• The demo itself was good, but they made a relevant mistake when they chose the background for the website (too dark in my opinion, mostly because they chose a slightly "apocalyptic" picture as background). 
• The rest of the color pattern for the website did not help to improve the contrast. This fact was noticed by several classmates.
• They are planning to implement a Facebook sharing feature in the future (I believe they should include it in the first release if they have time enough).
• A classmate suggested not to use too many notes (small cards in this case) in the pitch.

Seventh client meeting reactions

Last Wednesday, our team had the seventh client meeting with Professor Ackley. As we were working on the practice pitch, this week we were not able to do as many improvements as we desired. Ackley asked us about the performance of the website, and Matt S. answered that we made some minor improvements and there are not important issues so far in terms of performance. Then, we started the meeting showing a demo with the last features by request of Ackley, who wanted to see a kind of "tour" through the Demigod's website.

Demo and client reactions:

- Homepage (Ackley asked about the reason for include a Greek soldier silhouette)
- Mobile version (especially the auto-resize feature that adapts the resolution to any device. It was one of the things Ackley liked the most)
- Signing up (Facebook and "standard" way)
- Profile page (stats, bars, levels, etc.). Ackley suggested making the levels more colorful and create challenges related to the website functionality, such as complete your first challenge or upload a new avatar picture (I believe this was a great idea!)
 - Challenges page (random list of ten challenges by category. It includes a "View all" button to show the full challenge list). Ackley told us that we could show the most taken challenges instead of a random list (I agree). He also suggested adding a description of the challenge in the progress bar (like a reminder). This page needs more design.
- Share on Facebook (successful challenges and current progress)
- Check-in (it included the confirmation popup when you check-in). Ackley proposed adding on the confirmation popup the number of check-ins you have already done (Good idea as well).
- Failed check-ins (how it works). Ackley asked us several things:

• What was the relation between check-ins and weeks? and 
• Can a user check-in more than once a day? (this is not allowed, because the website has been designed to accept a maximum of one check-in a day) 
• Is there something that tells users when they success a full week? Now, once the users complete all the check-ins of the current week,  they basically can not check-in again until the next week. It should be interesting to show a message like "You have already completed your X check-ins this week. Come back the next week!" (totally agree)

- Regarding the stats, Ackley recommended keeping Altruism and Diet, and get rid of Dexterity and Willpower.
- He also suggested looking for test users shortly (friends, family, etc.), because we have to get some feedback.

Next action:

- Challenges page design
- Profile page design and stats  progress bars functionality
- First user tests (by the next two weeks)

First practice pitch reactions

Last Monday we presented our Demigod project to the rest of the class. This was a kind of practice pitch, including a demo, in order to train our final presentation that will be held at the end of the semester.

We met the day before the pitch (Sunday), and we designed a Power Point presentation trying to keep in mind the recommendations that Professor Ackley commented in the last class, as well as taking some things from The Business Model Canvas. After several hours of work, we finally got a seven slides presentation. Additionally, Natalie created a brief handout that we distributed among the rest of the teams, and Matt F. recorded a short video (roughly 1 minute) to show as a demo of the website, because we did not want to take risks displaying the demo "on the fly".

Apart from some screen resolution problems when displayed the video, I think that the demo in general was good, and Matt S. made a great pitch. However, we made some important mistakes, most of them, prior to the practice pitch itself. During the questions time, we received some useful feedback from both the classmates and Professor Ackley:

- Too much text on both the slides and the handout (I think that this was our main weakness).
- Tons of background facts (We should have moved some of the facts to other sheet, and occasionally mention these facts during the pitch).
- Set-up issues in the pitch, because the screen did not fit properly.
- Video demo was Ok, because we needed to simulate a full challenge check-in process. As Matt F. edited the video by cutting the waiting times between check-ins, this helped us to reduce the demo time.
- Maybe more "success effects", something like "fireworks" when you achieve a challenge. This kind of things could help the keep users motivated.
- Do not use the word "Kickbacks" in a presentation...
- Professor Ackley and some classmates checked the online version of the website on their mobile phones. It seems that they like it.

Summarizing, we need to put much more attention (and more time) in the final pitch, because the practice one was good, but probably less professional than we expected. We should focus on improving the quality of the slides, as well as do not leave the pitch preparation to the day before the presentation. "Procrastination is the thief of time".

Demigod: Working on the design

Last Saturday, Natalie and I had a new coding session to continue working on the Demigod's design. The home page is not complete yet, but it seems that we finally found the color pattern for the whole website. This is going to be a mixture of black, dark red and a bright green. We needed a pattern which transmits "a sense of challenging" in some way, and fortunately all the team agreed with the color selection.

We also did some modifications in the Demigod's logo, because of a slightly lack of contrast with the background, but finally it looks fine, and we believe that it represents the challenging approach of the application. In this sense, we added a silhouette of a Greek soldier in the middle of the page, which, from my point of view, improves the design and fits somehow with the goals of the website.

Demigod's home page

Additionally, we worked on the profile page (this is the first page that users will see once they sign in), whose design is almost completed. We changed the default avatar picture by using the same silhouette as in the home page (with some minor changes). This kind of customizations usually do not take too much time and they improve considerably the User Experience, which is actually the main goal of a good design. Finally, Natalie and I worked on the progress bar by editing the style in order to match with the rest of the website. Moreover, we changed the color combination in the CSS file and adjusted some align parameters. I personally like the effect of the green color in the progress bar.

 Demigod's profile picture

Along this week, we will keep working on the design, as most of the functionality is already completed and we need to improve the User Experience. 

Sixth client meeting reactions

We are already more than half of the project, and last Wednesday we had our sixth client meeting, this time with Nikan. Since we arranged in class, in the rest of the meetings, our client will alternate between Nikan and Professor Ackley.

We started the meeting showing a new demo to Nikan. It included some features that we had already presented to Ackley in the last meeting, as well as new improvements in which  we were working the last week. More specifically, the demo contained the following features:

• Facebook login. Users will be able to sign in using either their Facebook credentials or their Demigod account (assuming they have signed up previously).
• Challenge simulation: Progress bar with check-ins per week constraint and 20 seconds per day simulation.
• Share on Facebook once the user success a challenge.
• Access to the online version through a purchased domain name.
• Drop-down menu labeled with the username. It is located on the top bar (top-right), and includes the following buttons: "Logout",  "Edit account" and "My challenges".
• Home page layout Beta design (We are currently working on the home page design and logo, so we actually showed just a Beta version with the color pattern chosen, font families and sizes, etc.).
• Home page demo (functionality)
• "My Challenges". New page where the users will be able to check their created challenges organized by category. Additionally, each row of the table displays the name, description and number of points of each challenge. This page is currently under construction, because we planned to display a random selection of 10 challenges for each category (physical, nutritional and intellectual) in order to avoid scrolling and low resolution issues. But there will be available a "View all" button to get the full list.
• Create a new challenge (showed in the previous meeting): Users can create their own challenges. They will have to add the name, description, number of check-ins per week, number of weeks (duration), stats affected (nowadays we have a provisional list of 6 dimensions, but we are going to review it), and finally the category. A 20 points score will be assigned automatically to the new user's challenges, and only the administrators will be able to select the number of points for any challenge. 
• Challenge completion: Once a challenge is completed, the stats indicators in the profile page are updated by adding an extra level to the affected stats. Thus, there is no way to increase more than one level per statistic when you success a challenge.

Client reactions:

• Nikan suggested using little progress bars instead of counters to display the stats.
• Share challenge points on Facebook? 
• Nikan also had the opportunity to try the demo. She noticed that there was a bug in the new drop-down menu , because it did not work properly in some point when refreshing the page (we need to find a workaround for this weird bug).
• Home page looked "proffessional", but the profile page needs more design. We have to implement the layout: clean design, as few words as possible, clean text, smart buttons, unifying styles.
• Add the avatar picture to Facebook sharing posts?
• She liked our demo, because it included all the functions we had on our timeline so far.
• Marketing should be an important part of our project.
• "Demigod is a very good application and the demo was right".

Next action: Basically three tasks:

• Improve performance (Matt S.)
• UX (Matt F.)
• Design (Fernando, Natalie & Matt F.)

Git: Pulling specific directories or files

Recently I had an issue when working on Demigod's project. I do not know the reason, but I did not have all the stylesheet files which should be included in the /app/assets/stylesheets/ folder. The first workaround I tried was to pull all the changes from our remote repository, just in case other member of the team would accidentally have  moved those files. The remote repository had all the files (I checked it through Bitbucket website), but no changes occurred on my local repository when I run a git pull command on the Rails console. I did not understand what was happening, but I needed those files on my local repository.

I did a quick research on the Internet, I found a solution to solve my issue. There exists a way to pull only specific directories or files. As I commented on my last post, git pull fetches and merges the remote branch, but we can use the "fetch" command, that also fetches the remote branch, but, additionally, extracts the directory or file you need from that branch by a checkout operation. Therefore, you actually need two operations, first a "fetch" to download the objects from the repository, and then, a "checkout" to update the files/directories in the working tree and match the version in the specified path:

> git fetch <remote> <branch>
> git checkout <remote>/<branch> -- relative_path_to_file_or_directory

In my case, we had to run the following code in order to update the "stylesheets" directory:

> git fetch origin master
> git checkout <remote>/master -- .app/assets/stylesheets

After running the previous commands, my local "stylesheets" directory was updated with all the files included in the same folder of the remote repository. If you need just a specific file, you can also select that file inside the folder, for example:

> git checkout <remote>/master -- .app/assets/stylesheets/home.css.scss

 Problem solved!